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!



  • Ha! Thank you Ianabc, I switched to use Single Disk (Resizable), and it keeps the swap partition’s UUID, which means it’s working!!!
    Have a good weekend!


  • Testers

    Since 1.2.0 it supports linux and (as far as I know) dual boot. I haven’t tested the dual boot myself but the linux resizable works for me. The key seems to be to stick to ext4 filesystems.

    I’ll try to take a look to see if we could retain swap UUIDs for multiple partition image types.



  • Will sigle disk resizable work with Linux & dual boot systems?



  • Yes, I upload the image with 1.2.0, but the image type is Multiple Partition Image - Single Disk (Not Resizable).


  • Testers

    hmm…Did you create that image with an older version of fog? On fog 1.2.0 uploading a linux image gives me the following

    
    drwxrwxrwx.  2 root root      4096 Jul 22 15:03 .
    drwxrwxrwx. 56 fog  root      4096 Jul 22 15:03 ..
    -rwxrwxrwx.  1 root root          4 Jul 22 14:48 d1.fixed_size_partitions
    -rwxrwxrwx.  1 root root          0 Jul 22 14:49 d1.has_grub
    -rwxrwxrwx.  1 root root    1048576 Jul 22 14:49 d1.mbr
    -rwxrwxrwx.  1 root root        310 Jul 22 14:49 d1.minimum.partitions
    -rwxrwxrwx.  1 root root        80 Jul 22 14:49 d1.original.fstypes
    -rwxrwxrwx.  1 root root        310 Jul 22 14:48 d1.original.partitions
    -rwxrwxrwx.  1 root root        47 Jul 22 15:03 d1.original.swapuuids
    -rwxrwxrwx.  1 root root  84480518 Jul 22 14:49 d1p1.img
    -rwxrwxrwx.  1 root root 1944498680 Jul 22 14:53 d1p2.img
    -rwxrwxrwx.  1 root root 6416223022 Jul 22 15:03 d1p3.img
     
    -rwxrwxrwx.  1 root root        125 Jul 22 15:03 d1p4.img
    
    

    Did you try [B]uploading[/B] the image with 1.2.0 and then deploying it again. N.B. This is for a “Resizeable” image, it looks like the code for “Multiple partition” images might need to be updated to match.



  • [root@foggy henn205mageia4]# cat d1.partitions

    partition table of /dev/sda

    unit: sectors

    /dev/sda1 : start= 2048, size=960572497, Id=83, bootable
    /dev/sda2 : start=960577506, size= 16190559, Id= 5
    /dev/sda3 : start= 0, size= 0, Id= 0
    /dev/sda4 : start= 0, size= 0, Id= 0
    /dev/sda5 : start=960577536, size= 16190529, Id=82



  • [root@foggy henn205mageia4]# ls -la
    total 1659936
    drwxrwxrwx. 2 root root 4096 Jul 25 10:29 .
    drwxrwxrwx. 39 fog fog 4096 Jul 25 11:56 …
    -rwxrwxrwx. 1 root root 0 Jul 25 10:16 d1.has_grub
    -rwxrwxrwx. 1 root root 1048576 Jul 25 10:16 d1.mbr
    -rwxrwxrwx. 1 root root 1698702304 Jul 25 10:29 d1p1.img
    -rwxrwxrwx. 1 root root 1131 Jul 25 10:29 d1p2.img
    -rwxrwxrwx. 1 root root 310 Jul 25 10:16 d1.partitions

    That’s everything I got on the server image folder.


  • Testers

    Could you take a look in /images/NAMEOFYOURIMAGE and see if you can find a file similar to “d1.original.swapuuids”. Here is one of mine

    
      $ cat /images/RHL7x64PIMS50GBResizeable/d1.original.swapuuids
        /dev/sda5 7f6a8920-bab3-444d-8e3f-acca4c76e3cd
    
    

    When I deploy that image to a machine the UUID of the swap partition matches

    
      $ blkid /dev/sda5 UUID="7f6a8920-bab3-444d-8e3f-acca4c76e3cd"
    
    

    Obviously, change /dev/sda5 to wherever your swap partition is.


  • Testers

    Actually it looks like mageia (and some fedora) might have an issue with swap UUIDs. Somebody thought that putting UUIDs into initramfs was a good idea. There are some workarounds, but I don’t have any machines to work with to try them out.

    https://forums.mageia.org/en/viewtopic.php?f=7&t=7093
    http://forums.fedoraforum.org/showthread.php?t=292088

    Additionally, when an instructor - or anyone for that matter - asks for a specific distribution, it is a good idea to ask them what they are intending to do with it. Unless they are working with the package manager(s) day to day it generally doesn’t matter. Usually they have conflated a specific set of applications and versions with an distribution.


  • Testers

    From the image you showed above, are you sure that swap is the problem? what filesystems are your other partitions on? swap problems shouldn’t stop a system from booting in general - as I might have said above, it’s just swap!



  • @ianabc, post: 34153, member: 24548 said:

    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!
    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:(


  • Testers

    @Hongyun, post: 34129, member: 1117 said:

    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.

    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!



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



  • Yes, I reuploaded the image after the upgrade yesterday, and redeployed the computer today.


  • Senior Developer

    Did you reupload the image or just try redeploying?



  • Hi Tom,
    I tried the new version, result is the same :( any other suggestions?

    Thanks,
    Hongyun



  • 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 :)



  • I just upgrade the FOG server, you have a 1.2.0 now? That was fast, I will try the new version. Thanks!


  • Senior Developer

    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?


Log in to reply
 

325
Online

38729
Users

10555
Topics

99937
Posts

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