Swap UUID does not match after deploy

[NIoSaT]

Hello,
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
GPT partitioning

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.swapuuids in 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?

[Sebastian Roth]

@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/sdaX manually. Make sure you use the UUID and device name found in d1.original.swapuuids!

[NIoSaT]

Thanks for the quick answer!

Yes I am capturing from and deploying to an NVMe drive.

The content of the d1.original.swapuuids is as follows

/dev/nvme0n1p6 ed7ca9e8-1c85-4321-9e59-9e5b1414a8fc

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 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.

[Sebastian Roth]

@NIoSaT said in Swap UUID does not match after deploy:

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.swapuuids to match your target system device names…

[NIoSaT]

@Sebastian-Roth
I just did the debug deploy.

On the target system all partitions are called /dev/sdaX.

The manual mkswap with the old uuid and the /dev/nvmeXXXX device name gave an error (device not found).

I then tried mkswap with the old uuid and with the /dev/sdaX device name and it worked!
Debian now boots correctly and finds the swap!

I will now try your fix and edit the d1.original.swapuuids to match the /dev/sdaX name 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!

[Sebastian Roth]

@NIoSaT Thanks for testing! I will see if I can still fix this issue in the init scripts.

[Sebastian Roth]

@NIoSaT Would be really great if you could test the new init I just compiled to hopefully fix this issue: http://fogproject.org/inits/init_fix-swap.xz

Rename the original init.xz in /var/www/html/fog/service/ipxe/ on your FOG server and put the newly downloaded as init.xz in that same directory.

Please test a straight deploy using the old d1.original.swapuuids that 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!

[Sebastian Roth]

@NIoSaT Please help us with the FOG project and test things as we fix it to confirm this is working with your setup!

[Sebastian Roth]

@NIoSaT Any news one this?

[Sebastian Roth]

I still pushed the fix but I’d hope that people help us testing things more!!