Centos 7.2 UUID for swap wrong

[finvader]

Server

• FOG Version: 1.2.0
• OS: centos 7.2

Client

• Service Version:
• OS: centos 7.2

Description

We image our centos 7.2 system which is using UUID in /etc/sftab. Once imaging is complete, the new machines show “No swap found”. I look at /e/tc/fstab and the UUID of the swap partition is the same as the imaged machine and does not match the new system.

I dont mind using UUID , I just want to know why FOG is not swapping this out.

We are using a new fog from 2 days ago, 1.2.0

V/R

Derek

[finvader]

The FOG server is actually running CENTOS 6.8
The Fog machine being imaged is running CENTOS 7.2

[Sebastian Roth]

Most current FOG release candidate version is definitely storing SWAP UUID information from the original machine and does create SWAP on the new machine with he same UUID. There should be no need to fiddle with /etc/fstab. Although I am not absolutely sure about FOG 1.2.0 I think it should be the same way in this version?!

[Wayne Workman]

Sebastian is correct, and if you want to move to FOG 1.3.0 RC, here are the steps to do so: https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk

[finvader]

Thanks for the quick reply fellas. I love this forum and the software. Updating now and will report back.

[Wayne Workman]

@finvader Any word on this issue?

[finvader]

I did load 1.3.0 RC23 and the swap issue is there a problem. The UUID is carried over from the imaged to the deployed machine. I must change fstab to put in the correct UUID.

[george1421]

@finvader can you post what your fstab looks like for one of these systems?

I don’t have a solution for you, just documenting my thoughts…
just for reference the following command will display the output uuid of the swap partition from a running system.

# blkid -t TYPE=swap
/dev/block/253:1: UUID="7603189e-c4b0-4958-b443-e2aebdc9a4b6" TYPE="swap"

The issue doing this with FOS is that I can see this returning the running swap space for the FOS (operating system) not the target disk image.

<edit>
Ah, ok from FOS one might use

# blkid /dev/sda1
/dev/sda1: UUID="fc5dae66-d8d4-4481-a7b0-3238ab0dbbb7" TYPE="xfs"

FOS would know about the disk and partition at the time of imaging.

[Quazz]

@finvader Just to confirm: Did you upload the image to the server (overwriting the old data) after upgrading to RC23?

[Wayne Workman]

@george1421 I guess the UUID of swap could be fixed in postdownloadscripts. I think some people have already worked that out.

My question I suppose is why even have FOG store the swap UUID if it’s going to just make a swap partition who’s UUID doesn’t match? Why not generate a UUID for the new swap partition and then stick that into /etc/fstab wouldn’t it be a basic replace command? Especially if you know the old swap UUID. Almost exactly as how fog handles early hostname change for windows? Just mount every single linux partition and look for an /etc/fstab file and do the replace on every file found. It’d only fix the right one if your command uses the already existing UUID in the file.

[finvader]

@Quazz yes

[michalm]

Hi! I have the same problem. I imaged mbr based ssd drive with three partitions:
/dev/sda1 (/)
/dev/sda2 (swap)
/dev/sda3 (/var)

Installed OS is Debian 9. Image type is set to “Single disk - resizable”.

After deploying, swap partition has different uuid, altough that this in d1.original.swapuuids file is correct.

I notice in source code (makeSwapSystem function) that uuid from d1.original.swapuuids file is read, only in case when we have gpt based disk layout:

  case $hasgpt in
        1)
            uuid=$(awk "$pat{print \$2}" $file)
            [[ -n $uuid ]] && parttype=82
            ;;
        0)
            parttype=$(sfdisk -d $disk 2>/dev/null | awk -F[,=] "/^$escape_part/{print \$6}")
            ;;
    esac

Is this correct behaviour?

When I move uuid variable assignment outside (above) case statement, swap partition uuid is set correctly.

I’m using FOG 1.5.0 RC 10.

[george1421]

@Developers I know this is an old thread, but please review @michalm post since this is a current internal topic.

[Wayne Workman]

@michalm This is great, I think you’ve found and solved a known-bug. Can you submit a pull request with the changes to the FOG working branch on github please? https://github.com/FOGProject/fogproject/tree/working

[Sebastian Roth]

This is still open, we are working on it. See here…

[Sebastian Roth]

This is fixed in working branch.