Swap UUID does not match after deploy
NIoSaT last edited by
I am currently trying to capture and deploy a Dual-Boot System (Debian 9 + Win10), but I am having trouble with some UUIDs.
I am using FOG Version 1.5.7
Dell Optiplex 3060
Capture and deploy generally work, and I can even boot the Debian System. But the swap partition does not work correctly.
I narrowed it down to a missing UUID.
All other Partitions get a correct UUID, Lable and PARTUUID that match the
/etc/fstab. The Swap Partition only gets a PARTUUID (even the same as the original system, so that works) but nothing else. So Debian can’t find the partition while booting.
I already tried “Single Disk - resizable” and “Multiple Partition Image - Single Disk (not resizable)” as Image Type, both with the same problem.
When I check the
d1.original.swapuuidsin the image on the Fog server, there is the correct UUID but it does not get written during the deploy.
I did some research and as far as I understand this should work in 1.5.7?
I still pushed the fix but I’d hope that people help us testing things more!!
@NIoSaT Any news one this?
@NIoSaT Please help us with the FOG project and test things as we fix it to confirm this is working with your setup!
Rename the original
/var/www/html/fog/service/ipxe/on your FOG server and put the newly downloaded as
init.xzin that same directory.
Please test a straight deploy using the old
d1.original.swapuuidsthat has the wrong device names in it as well as a re-capture (generates a slightly different swapuuids file now) and deploy. Thanks in advance!
@NIoSaT Thanks for testing! I will see if I can still fix this issue in the init scripts.
NIoSaT last edited by NIoSaT
I just did the debug deploy.
On the target system all partitions are called
mkswapwith the old uuid and the
/dev/nvmeXXXXdevice name gave an error (device not found).
I then tried
mkswapwith the old uuid and with the
/dev/sdaXdevice name and it worked!
Debian now boots correctly and finds the swap!
I will now try your fix and edit the
d1.original.swapuuidsto match the
/dev/sdaXname to test if the deploy will work automatically again.
It is still strange to me that the two systems use different names for the devices, since both use nvme drives.
But I guess this problem will solve itself once I use 100% identical hardware.
— UPDATE —
I updated the
d1.original.swapuuids, it works!
One thing I also noticed is that the original system that I capture from uses paths like /dev/nvmeXXXX when I look at the comments in /etc/fstab.
But the system I deploy to shows paths like /dev/sdaX when using lsblk.
I am fairly sure this is where things go wrong… While we do handle the switch form NVMe to SSD and vice versa in most cases it seems like we fail to do so for the SWAP UUIDs. I can think of a fix here (using just the partition numbers instead of full partition device names in
d1.original.swapuuids) but for now I’d suggest you manually adjust
d1.original.swapuuidsto match your target system device names…
NIoSaT last edited by
Thanks for the quick answer!
Yes I am capturing from and deploying to an NVMe drive.
The content of the
d1.original.swapuuidsis as follows
One thing I also noticed is that the original system that I capture from uses paths like
/dev/nvmeXXXXwhen I look at the comments in
But the system I deploy to shows paths like
/dev/sdaXwhen using lsblk.
I think I saw the same differences in the naming scheme during the imaging/writing process of Partclone.
Both systems have NVMe drives but are not 100% identical hardware (two different Version of the Dell OptiPlex platform). I will get 100% identical systems soon (this is were the real deployment will happen).
I will do the debug deploy and see if the manual mkswap will work.
@NIoSaT You’ve done some great research on this from what I read. Well done. I am too wondering what could be causing it to not properly set the SWAP UUID if you have the right one in
d1.original.swapuuids. Can you posts the contents of that file here, please?
Are you deploying to a NVMe drive by any chance? Just asking because we had some script code issues with the naming of NVMe device names here and there and I can imagine this being just another case we haven’t stumbled upon yet.
Other than that I may ask you to schedule a debug deploy job to that machine (just as you normally schedule tasks in the web UI but just before you hit the button there is a checkbox to do it in debug mode). Boot up the machine as usual and hit ENTER twice to get to the shell. Here you start the task by running the command
fog. Now step through the whole thing and when it’s done you are thrown back to the shell. Here try running
mkswap -U uuid234-.../dev/sdaXmanually. Make sure you use the UUID and device name found in