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

dholtz-docbox

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

Wayne Workman

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.

dholtz-docbox

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.

Wayne Workman

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.

dholtz-docbox

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.

george1421

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

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.

dholtz-docbox

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

Thanks again Wayne and Thiago!

Wayne Workman

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

Tom Elliott

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

Wayne Workman

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

Sebastian Roth

@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

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

167

11.7k

17.2k

154.7k