FOG 1.3 RC8 - Fails to Apply 'swap' UUID on Image Deploy



  • I am new to FOG, and when I installed everything it was as of v1.3.0 RC8.

    Upon successfully installing the FOG server on my local machine, I noticed that each image deployment would result in the ‘swap’ HDD UUID changing each time. This causes the /etc/fstab file to become invalid as a result - even when using ‘Single Disk - Resizable’.

    I then proceeded to try v1.2.0, as it was stated as the most recent stable version. However, upon setting it up, I receive TFTP ARP and connection issues left-and-right. Unfortunately no particular resource helped me with this, and I have tried configuring the dhcpd.conf, turning on/off various firewall settings, and restarting services. I am also unable to invoke “tftp x.x.x.x -c get unidonly.kpxe” this way too - it times out.

    I guess my question is, should I go ahead and use the latest v1.3.x RCx builds and is there another method for handling the imaging such that the fstab isn’t out of date (or that the swap doesn’t get assigned a new UUID).

    Anyway, thank you for any input provided.

    -Dustin


  • Developer

    @Wayne-Workman If you look at the scripts you see that it makes perfectly sense what Tom is saying. In capture we usually create a text file called d1.original.swapuuids where we store the UUID of the original SWAP partition. In deploy we generate a new SWAP partition on the target system using the saved UUID. So there shouldn’t be a need to modify /etc/fstab at all!

    I haven’t tested this in a while as I am too busy with other things. Just saying that this is how I think FOG is behaving. Same as Tom does. Anyone keen to try this and see if we have an issue in the scripts?

    https://github.com/FOGProject/fogproject/blob/dev-branch/src/buildroot/package/fog/scripts/usr/share/fog/lib/partition-funcs.sh#L309
    https://github.com/FOGProject/fogproject/blob/dev-branch/src/buildroot/package/fog/scripts/usr/share/fog/lib/partition-funcs.sh#L377


  • Moderator

    @Sebastian-Roth What do you think about this topic?


  • Senior Developer

    @Wayne-Workman we don’t change the uuid of the swap partitions. We don’t do anything with swap except reset to the same uuid that the image was captured from. If the swap uuid file is removed or didn’t exist there is no way to ensure the original captured image will behave properly from FOGs standpoint.


  • Moderator

    @Tom-Elliott @Sebastian-Roth @george1421 I think @Thiago’s script could be reworked and put in the inits for linux images. Somehow detect the swap partition after imaging, and generate a new UUID and put it in fstab. Thoughts?



  • I was caught up on a few independent tasks and am just coming back to these. @Thiago Thanks so much! That’s awesome! I wrote one up the other day, but this is a lot clearer in its implementation.

    On to my next task; determining if I can kick FOG off with HTTP commands :P

    Thanks again Wayne and Thiago!



  • @dholtz-docbox
    Looking at my old scripts ( i am not using at moment) i found one that changes linux hostname and swap uuid:

    /images/postdownloadscripts/fog.hosts
    
    
    #the file contents
    -----------------------
    #/bin/sh
    . /usr/share/fog/lib/funcs.sh;
    
    partition=`lsblk -o KNAME,FSTYPE,LABEL /dev/sda? | grep -v -E "swap|KNAME" | awk '{print $1}'`
    mountpoint="/test"
    linuxhostname="$mountpoint/etc/hostname"
    
    comandomount="mount"
    swappart=`blkid | grep swap | awk -F"\"" '{print $2}'`
    
    dots "Creating mount point" 
    mkdir -p $mountpoint 2>/dev/null && echo "OK" || echo "Error"
    
    
    for i in $partition
    do
       tipopart=`lsblk -o FSTYPE /dev/$i | grep -v FSTYPE`
       if [ $tipopart = "ext4" ]
       then
           comandomount="mount -t $tipopart"
       fi
       dots "Mounting Partition /dev/$i"
       $comandomount /dev/$i $mountpoint && status="OK" || status="Error"
       
       if [ $status = "OK" ]
       then
           echo "OK"
           if [ -e $linuxhostname ]; then
               dots "Changing hostname on Linux"
               echo $hostname > $linuxhostname && echo "OK" || echo "Error"
           fi
          dots "Changing swap UUID inside fstab file"
          fstabpart=`cat $mountpoint/etc/fstab | grep swap | grep UUID | cut -d"=" -f2| awk '{print $1}'`
          sed -i "s/$fstabpart/$swappart/g" $mountpoint/etc/fstab && echo "OK" || echo "Error"
          umount $mountpoint
       else
           echo "Error mounting partition $partition"
       fi
    done
    

    don’t forget to put directive calling this script inside /images/postdownloadscripts/fog.postdownload

    It was used many times and works, but i don’t know if this is the final version put at production.
    some ideas.


  • Moderator

    @dholtz-docbox Sorry I’m not following this (maybe).

    Let me restate what I think your saying in my words.

    I’m attempting to deploy a linux image to a target computer. The image deploys correctly but when the target goes to boot I get an error in that the HDD UUID has changed because of deployment. If that is the case, the easy fix is to remove all references to the uuid in the reference image and just make physical partition references. Then you don’t really care about the uuid.

    Do I understand this correctly?

    For the other questions, fog 1.3.0-rc10 (as of this post) is the correct version to be on.



  • I see! Thank you for all this information - it’s incredibly useful and just what I was looking for. I will go back to 1.3 and look into setting up FOS to handle a post script as you suggested. That DEFINTIELY sounds like what I want.

    I was even telling a team member of a similar idea, so it’s awesome that FOG already handles this. You guys did an amazing job with this by the way. Before I started, I laid out a set of criteria for how I would like to handle remote imaging. When I came across FOG’s solution, I was like, wow, this is exactly where I was wanting to go, and it does it and more! Again, stellar implementation.


  • Moderator

    So, to follow up on the other question I had, there should be no concern in using 1.3 then? Do you think the issues I am having with 1.2 are a result of some artifact from 1.3 when I “downgraded” to 1.2?

    1.3.0 RC has issues that come and go - it’s more stable and safe than 1.2.0 in my opinion. 1.2 was prone to many, many issues that were difficult to solve. 1.3 doesn’t have these things, supports more hardware that you will absolutely need supported, and has very large performance improvements, and more refined features. There’s no reason not to use it.

    I will look at the postinstall scripts solution - is this something PXE would handle after imaging?

    I wouldn’t call it something “PXE” handles, this is something that FOS can do (fog operating system). FOS is what does the imaging per computer, and other tasks. It’s just a small custom linux environment with the things needed for imaging.

    Or are you just suggesting that I write an init script that always corrects the fstab?

    This is the idea behind postinstallscripts. You can write BASH scripts that run each time a computer images, runs locally on that computer in FOS itself just after imaging is done. The only limits here are your imagination. For example, @george1421 had to be a rockstar and use postinstallscripts to edit the image’s unattend file so that it gets setup to name itself correctly on first-boot during post-sysprep processes. Other people use the postinstallscripts to deploy drivers to computers. Others simply to places files they need on the image without re-uploading what might be 50 images. Your imagination is your limit. Modifying /etc/fstab should be quite trivial.



  • The /etc/fstab within the image.

    So, to follow up on the other question I had, there should be no concern in using 1.3 then? Do you think the issues I am having with 1.2 are a result of some artifact from 1.3 when I “downgraded” to 1.2?

    I will look at the postinstall scripts solution - is this something PXE would handle after imaging? Or are you just suggesting that I write an init script that always corrects the fstab?

    Thanks, again; I know these are easy questions, but finding the answers have been more difficult than I was expected - perhaps, just a result of ignorance on the topic though.


  • Moderator

    Are you refering to the /etc/fstab that is inside of the image, or your fog server’s ?

    If it’s in the image, the UUID on the swap partition changing is expected. You can use what’s called postinstallscripts to simply change it to be correct on the laid-image before the machine even boots.


Log in to reply
 

467
Online

39.4k
Users

11.1k
Topics

105.4k
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.