Imaging Linux systems, UUID for swap not matching on deployed systems. Eh?
-
Hello friends. I’m imaging some Linux systems (Xubuntu 14.04) using an Ubuntu 14.04 system as the server. When I deploy the images, everything works flawlessly, but I notice on the deployed systems they boot up citing a UUID error for JUST a split second at boot. It’s quick enough I can hardly catch anything it says. I checked via terminal and saw that while my UUID for the EXT4 root partition matches on each deployment, the UUID for the swap partition is different on each and every single one.
I have not noticed this with my previous imaging solution, Clonezilla Live, so it makes me wonder what is different that’s happening under FOG. Is there a way to counter-act this from happening?
Thanks for any and all assistance!
-
UUIDs are supposed to be unique, the simplest way around is to use a device name rather than a UUID in /etc/fstab. To find the device names you could do something like
[CODE]
$ blkid
/dev/sdb1: UUID=“b5383030-0990-4386-a694-288f1f67cb5c” TYPE=“ext4”/dev/sdb2: UUID="4349ed6e-d556-4ba8-a7b6-31dcfb46c0bf" TYPE="swap"[/CODE]
Then fire up your favourite editor and replace
[CODE]
UUID=4349ed6e-d556-4ba8-a7b6-31dcfb46c0bf swap swap defaults 0 0
[/CODE]
with
[CODE]
/dev/sdb2 swap swap defaults 0 0
[/CODE]
replacing /dev/sdb2 with /dev/sda2 or whatever you find in the output of blkid.In general I replace the UUIDs with the device names when making a new linux image (for all partitions not just swap). When I’m about to upload I boot my linux image one last time and…
[LIST=1]
[]fsck all the filesystems
[]adjust the fstab as above
[]stash the ssh_host_ keys
[]remove any persistent device names under /etc/udev/rules.d
[]yum clean all or apt-get clean
[*]…
[/LIST]
It makes the linux images a bit more portable. I’ve never run into problems adjusting the fstab, but in principal if you use /dev/sda and the next client system enumerates the disks differently you could. It wouldn’t be hard to fix though - just boot a rescue CD and edit fstab again. -
Hi there. Thanks for your response. I guess I’m just not understanding ‘why’ it’s changing the UUID of swap in particular, but not root. I duplicated these efforts with Clonezilla, but when I deploy an image with Clonezilla, both UUIDs of swap and root (as seen via blkid) match what is in fstab. This is not the case for FOG.
On one hand I’m just thankful it’s swap and not root. If it was doing this to the root partition, we would have an instant road block until the UUIDs were manually (and tediously) changed. It makes me wonder if the mismatched UUID of swap thereby makes that partition useless, as if the system won’t know what to do with swap since it’s not ‘mounted’ properly as per the UUID it’s looking for not being available.
I’ll try what you mentioned above and see if it makes a difference. Have you personally witnessed this? Or has this process you explain at the end been something you’ve always done since day one?
-
Hi Jason, I use device names rather than UUIDs in all of my linux images but I’ve never actually had to use the instructions at the end - I gave it as a worst case scenario.
For ext4 filesystems, they stash the UUID in the superblock so I think that i why they still work - you could probably continue to use UUIDs for ext filesystems, I just choose not to.
The other thing is, swap is just swap. You can blow it away and recreate it with pretty much no system impact.
-
The only question about that would be… is swap still usable by the system if the UUID of the swap partition did not match to ‘mount’ it? I look at it like this… if swap is just swap (which I believe), then why even bother fstab’ing it? Since the system automatically adds swap to fstab I can’t help but to think there’s a reason for that.
Thanks for your response!
-
Hi Jason, bear with me, I’m not really sure I understand the question. The system doesn’t add swap automatically, installers sometimes do, but it is a reversible or modifiable choice at your discretion. The swapon and swapoff commands will let you turn any of your swap files/partitions on and off.
If the UUID of the swap partition doesn’t match the fstab it won’t be used. To get around that, you would either need to modify the fstab or modify the swap partition (swaplabel will let you change the UUID).
What I was suggesting at the top of the thread was that if your client systems don’t vary too much, then the device names will not change (i.e. /dev/sda will always be /dev/sda) and you can put the device names in fstab instead of UUIDs - this avoids the need for editing the fstab or the swap uuid in the future.
Does that help?
-
Hey there. Yes - it does. More than anything I just wanted confirmation that the UUID did need to match in fstab in order for swap to be used, as I simply couldn’t wrap my brain around how swap WOULD work with mismatched UUIDs. So that clarifies things a bit.
I could use the device ID, but I guess I’m just a believer in sticking to UUIDs due to their accuracy. The systems can vary wildly, I’m talking from a desktop made in the very early XP era to a two year old laptop, all running from the same image.
I still can’t really understand how the UUID is changing, though. What I do is I built the image on a 40 GB HDD, the smallest HDD I deal with. I blast that to the drives and expand the EXT4 partition to utilize the entirety of the space on the disk. To give you a little feedback as to what I’m doing, this is the basic jist. I work for a large public school district in the IT department. While the vast majority of our systems are Ubuntu, we do indeed use FOG for imaging the handful of Windows systems that are in-house. I’ve used FOG at my last district I worked at (all Windows based) with flying success. It felt like a natural course of action since FOG is, well, pretty much awesome. Our district is quite large, and spans a huge geographical area. A decent portion of the district is of lesser income individuals. As a result, I accept older computers from the XP generation and newer from pretty much anybody who wants to get rid of them. After using DBAN on the drives, or FOG’s full disk wipe, I put Xubuntu fully loaded with a lot of software, including educational software, on the computers for these people. All in all, I basically repurpose old computers and donate them to families who can utilize them, all free of cost, all running free and open source software. The point is to ensure that no families are left out unable to have a computer for their kids to do homework on; something that’s growing increasingly common (do I dare say, important) given the level of dependency with technology that districts are growing towards. Point of this story is to highlight exactly why (and how much) the systems I deal with can vary in hardware.
Given that Clonezilla does not change the UUID, it makes me wonder what process under the hood is operating differently versus FOG. I ‘thought’ FOG and Clonezilla were both built on a lot of the same core fundamental technologies. Since I am not imaging thousands of these systems at the same time, Clonezilla Live might be more suitable for a predictable image deployment, as I can simply house the image on my server and pull it over my gigabit LAN via SSH or SMB. I’d like to get FOG to work though in the event that we want to utilize it for our Linux systems, despite the fact we’re running our own imaging platform that was largely built by some of our HS tech interns (hosted on github, known as FLDT). But hey, options are nice, so it’d be nice to use FOG at home and know how to work around this in the event we ever want to put FOG to use at work.
I do have to wonder if FOG is being a bit fussy with the UUIDs in regard to how I’m imaging the drives. I have a spare tower on my desk with multiple IDE and SATA ports, so I drop the drives in that tower and PXE boot that tower to handle the images via FOG, or USB boot via Clonezilla Live. So the system that is running with the drives is not the system that the drive sees when it’s 100% packaged up and ready to go. Perhaps this is where FOG is getting miffed? Hard to say, but given an image is an image is an image, it would confuse me if this was the culprit.
At any rate, just some rambling thoughts and whatnot. Thanks again for your assistance - it’s appreciated!
-
Hi Jason, the fog script fog.download does an “mkswap” on the partition during the restore. I think that will change the UUID. The alternative would be to just dd the entire swap space which is probably what Clonezilla is doing (though I’m guessing :)).
Reading what you are doing (congratulations by the way - a very laudable project!) there are a couple of ways you could solve this. They all come in at the time you are expanding the ext4 filesystem. At the same time you would update either the fstab or the UUID in the swap partition. After the next reboot (or after a swapon/swapoff) your swap partition would show up.
To edit the fstab I might do something like
[CODE]
#!/bin/shOLDUID=
grep swap /etc/fstab |cut -d' ' -f1
NEWUID=blkid | grep swap | cut -d' ' -f2sed “s/$OLDUID/$NEWUID/” /etc/fstab
[/CODE]
before I expand the ext4fs.If you wanted to modify the swap UUID instead, then something like
[CODE]
#!/bin/shTARGETUID=
grep swap /etc/fstab |cut -d' ' -f1 | cut -d'=' -f2
DEVICE=blkid | grep swap | cut -d':' -f1swaplabel -U “$TARGETUID” $DEVICE
swapon -a
[/CODE]A third alternative is to use labels rather than UUIDs or device names.
-
I’m having the same problem with Mageia 4 system. Attached image is what’s show up after deployed a computer. It only complaints about the swap partition UUID.
And before I upload the image, I’ve already changed the fstab file to use either the disk name /dev/sda5, or the label of the swap partition LABEL=SWAP, in both cases, I get the same result.
Any idea how to fix this?
Thanks,
Hongyun[url=“/_imported_xf_attachments/1/1210_dracut_error.JPG?:”]dracut_error.JPG[/url]
-
[quote=“Hongyun, post: 34056, member: 1117”]I’m having the same problem with Mageia 4 system. Attached image is what’s show up after deployed a computer. It only complaints about the swap partition UUID.
And before I upload the image, I’ve already changed the fstab file to use either the disk name /dev/sda5, or the label of the swap partition LABEL=SWAP, in both cases, I get the same result.
Any idea how to fix this?
Thanks,
Hongyun[/quote]What version of FOG are you running?
-
The newest version 1.1.2
-
Chances are that’s the majority of the problem. I don’t think it did the correct things for the UUID.
Can you upgrade to 1.2.0 and reupload the original image and test again?
-
I just upgrade the FOG server, you have a 1.2.0 now? That was fast, I will try the new version. Thanks!
-
I found each time after I upgrade FOG, the /etc/exports file got overwritten, I have to re-enter all my storage nodes again to make it work. Is it possible you can keep that file in your next version? Just some thoughts
-
Hi Tom,
I tried the new version, result is the same
any other suggestions?Thanks,
Hongyun -
Did you reupload the image or just try redeploying?
-
Yes, I reuploaded the image after the upgrade yesterday, and redeployed the computer today.
-
I think it has something to do with the OS. I tried reupload a working image and then download it again, it still works. But this Mageia 4.1 OS doesn’t work properly. I will try to reinstall it with ext3 partition to see if it works.
-
[quote=“Hongyun, post: 34129, member: 1117”]I think it has something to do with the OS. I tried reupload a working image and then download it again, it still works. But this Mageia 4.1 OS doesn’t work properly. I will try to reinstall it with ext3 partition to see if it works.[/quote]
UUIDs work for ext3 and ext4 filesystems because the UUID is part of the filesystem itself, it is written into the superblock. Since Fog 1.2.0 fog also seems to allow UUIDs in /etc/fstab for swap partitions. For other filesystems, I’m not sure, I haven’t noticed any problems with xfs, but I haven’t looked too close. Incidentally, there are some other reasons to use ext4 - fog 1.2.0 can resize ext4 filesystems automatically!
-
[quote=“ianabc, post: 34153, member: 24548”]UUIDs work for ext3 and ext4 filesystems because the UUID is part of the filesystem itself, it is written into the superblock. Since Fog 1.2.0 fog also seems to allow UUIDs in /etc/fstab for swap partitions. For other filesystems, I’m not sure, I haven’t noticed any problems with xfs, but I haven’t looked too close. Incidentally, there are some other reasons to use ext4 - fog 1.2.0 can resize ext4 filesystems automatically![/quote]
But I think the problem now is that after downloading the FOG image, the swap partition’s UUID got changed, even when I download the image to the same computer where I uploaded the image from. Our instructor prefer the Mageia 4.1, I’m still trying to make this work with FOG, a month left before the term starts, feeling the pressure now:(
