SOLVED Centos 7.2 UUID for swap wrong

  • Server
    • FOG Version: 1.2.0
    • OS: centos 7.2
    • Service Version:
    • OS: centos 7.2

    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



  • Moderator

    This is fixed in working branch.

  • Moderator

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

  • @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?

  • Moderator

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

  • 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
                uuid=$(awk "$pat{print \$2}" $file)
                [[ -n $uuid ]] && parttype=82
                parttype=$(sfdisk -d $disk 2>/dev/null | awk -F[,=] "/^$escape_part/{print \$6}")

    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.

  • @Quazz yes

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

  • Moderator

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

  • Moderator

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

    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.

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

  • @finvader Any word on this issue?

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

  • Sebastian is correct, and if you want to move to FOG 1.3.0 RC, here are the steps to do so:

  • Moderator

    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?!

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