Page 1 of 2 12 LastLast
Results 1 to 10 of 20

Thread: How do I eliminate UUID dependence?

  1. #1
    Join Date
    Dec 2008
    Location
    Buffalo, MN USA
    Posts
    82

    Arrow How do I eliminate UUID dependence?

    While mounting by UUID has some value for storage that is transient/mobile in nature (e.g., storage attached via USB, firewire, Lightning, perhaps even SCSI, eSATA or FibreChannel) it is IMHO the WORST POSSIBLE way to mount storage used to boot a system. UUID makes it IMPOSSIBLE to migrate a system and replace the boot drive without jumping through extraordinary hoops.

    If there is ANY reasonable way to eliminate this rabid infatuation of UUID from an openSUSE system, please let me know,

    I am particularly interested in eliminating UUID dependence in grub2-mkconfig and mkinitrd(dracut).

    Even though i have
    Code:
    GRUB_DISABLE_LINUX_UUID=true
    in /etc/default/grub, grub2-mkconfig insists on using UUID to figure out where grub.cfg exists. Which means that grub fails when the system is migrated to a different drive, it goes into a recovery console mode that writes characters temporarily in the middle of the screen before over-writing them with whatever was already being displayed. In effect, it's useless.

    the grub.cfg file gets loaded with lines like this
    Code:
    # grep uuid /boot/grub2/grub.cfg 
      search --no-floppy --fs-uuid --set=root --hint='lvmid/IAs7dd-2SVj-zCIo-eHYB-7vxV-Mt7H-dq05OR/MMh1yb-2vvI-Xcdf-wT6J-Y7at-6qwd-Xb5vFm'  6de884c2-d5cb-45a4-9e66-1e34ccaa3b19
      search --no-floppy --fs-uuid --set=root 6de884c2-d5cb-45a4-9e66-1e34ccaa3b19
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  14edeeda-cb10-4467-9993-126da8b63626
      search --no-floppy --fs-uuid --set=root 14edeeda-cb10-4467-9993-126da8b63626
              search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  14edeeda-cb10-4467-9993-126da8b63626
              search --no-floppy --fs-uuid --set=root 14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root 14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root 14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root 14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root 14edeeda-cb10-4467-9993-126da8b63626
              search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  7EB1-87B3
              search --no-floppy --fs-uuid --set=root 7EB1-87B3
    So I have to boot from a liveCD to edit the file, replacing all instances of --fs-uuid with -l and the uuids of the old drive with the labels of the respective file systems.

    While that allows grub to function, we're not home yet. Mkinitrd(dracut) also insists on using uuid, so booting fails after grub passes control to the kernel. The reason is fails is because the uuid of the root filesystem is different on the new drive than on the old drive, so it can't mount the root filesystem. I could use tune2fs to change the uuid if I was using a drive partition for a singe filesystem, such that formatting .e.g. /dev/sda3 to ext4 yiels a single filesystem. That doesn't work so well if a single disk partition encompasses multiple logical volumes. The user has no controll over the uuid applied to either a VG nor an LV. The result is entries in the initrd which look like
    Code:
    drwxr-xr-x   2 root     root            0 Jan 21 08:30 etc/systemd/system/dev-disk-by\\x2duuid-14edeeda\\x2dcb10\\x2d4467\\x2d9993\\x2d126da8b63626.device.d
    -rw-r--r--   2 root     root            0 Jan 21 08:30 etc/systemd/system/dev-disk-by\\x2duuid-14edeeda\\x2dcb10\\x2d4467\\x2d9993\\x2d126da8b63626.device.d/timeout.conf
    drwxr-xr-x   2 root     root            0 Jan 21 08:30 etc/systemd/system/dev-disk-by\\x2duuid-7EB1\\x2d87B3.device.d
    -rw-r--r--   2 root     root           23 Jan 21 08:30 etc/systemd/system/dev-disk-by\\x2duuid-7EB1\\x2d87B3.device.d/timeout.conf
    drwxr-xr-x   2 root     root            0 Jan 21 08:30 etc/systemd/system/initrd.target.wants
    lrwxrwxrwx   1 root     root           78 Jan 21 08:30 etc/systemd/system/initrd.target.wants/dev-disk-by\\x2duuid-14edeeda\\x2dcb10\\x2d4467\\x2d9993\\x2d126da8b63626.device -> ../dev-disk-by\\x2duuid-14edeeda\\x2dcb10\\x2d4467\\x2d9993\\x2d126da8b63626.device
    lrwxrwxrwx   1 root     root           42 Jan 21 08:30 etc/systemd/system/initrd.target.wants/dev-disk-by\\x2duuid-7EB1\\x2d87B3.device -> ../dev-disk-by\\x2duuid-7EB1\\x2d87B3.device
    So the kernel halts at a dracut recovery prompt because it can't find the root filesystem. Unfortunately, my attempts to mount the real filesystem fail. I've been trying
    Code:
     mount -o remount /dev/mapper/<VGname>-<LVname> /
    and
    Code:
     mount -o remount /dev/dm-1 /
    or
    Code:
     mount -o remount /dev/disk/by-label/<root-volume-label> /
    but they all fail to mount the root filesystem.

    I'd really like to get the new drive installed in the system before the old drive fails completely, but UUID is making this VERY difficult. The only way I can see to make the system less flexible and useable would be to apply UUID to the keyboard, mouse, monitor and memory as well as the storage. I wonder when that's coming.

    If there's any way out of this UUID-hell, I'd sure appreciate learning about it.

    Thanks,
    ron

  2. #2
    Join Date
    Jun 2008
    Location
    Rural Australia
    Posts
    301

    Default Re: How do I eliminate UUID dependence?

    BTW am NON-Technical... am not sure you can eliminate the UUID as it appears important for usage and security... to where eliminating it will be a lot more complicated than learning how to set things to read them easier.

    YaST enables choice of select what you will see including older /dev/sda or the newer standard UUID.



    Find helps self to save a copy of changes to my file /boot/grub2/grub.cfg

    Your details hd0 am guessing shows your hard drive root partition sda .

    Your details hd0,gpt1 am guessing with
    7EB1-87B3 is sda2 an EFI boot partition, BTW may be a 'BIOS boot' partition.



    Self found reading this useful https://liquidat.wordpress.com/2013/...-need-to-know/




    Code:
    # grep uuid /boot/grub2/grub.cfg 
      search --no-floppy --fs-uuid --set=root --hint='lvmid/IAs7dd-2SVj-zCIo-eHYB-7vxV-Mt7H-dq05OR/MMh1yb-2vvI-Xcdf-wT6J-Y7at-6qwd-Xb5vFm'  6de884c2-d5cb-45a4-9e66-1e34ccaa3b19
      search --no-floppy --fs-uuid --set=root 6de884c2-d5cb-45a4-9e66-1e34ccaa3b19
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  14edeeda-cb10-4467-9993-126da8b63626
      search --no-floppy --fs-uuid --set=root 14edeeda-cb10-4467-9993-126da8b63626
              search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  14edeeda-cb10-4467-9993-126da8b63626
              search --no-floppy --fs-uuid --set=root 14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root 14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root 14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root 14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt3 --hint-efi=hd0,gpt3 --hint-baremetal=ahci0,gpt3  14edeeda-cb10-4467-9993-126da8b63626
                      search --no-floppy --fs-uuid --set=root 14edeeda-cb10-4467-9993-126da8b63626
              search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  7EB1-87B3
              search --no-floppy --fs-uuid --set=root 7EB1-87B3

  3. #3
    Join Date
    Jun 2008
    Location
    Rural Australia
    Posts
    301

    Default Re: How do I eliminate UUID dependence?

    Also found useful for checking, and saving, the various Device and Partition names:

    Code:
    sudo hwinfo --block
    or

    Code:
    sudo hwinfo --block | grep 'Device Files'


    .

  4. #4
    Join Date
    Dec 2008
    Location
    Buffalo, MN USA
    Posts
    82

    Default Re: How do I eliminate UUID dependence?

    Quote Originally Posted by paulparker View Post
    BTW am NON-Technical... am not sure you can eliminate the UUID as it appears important for usage and security... to where eliminating it will be a lot more complicated than learning how to set things to read them easier.

    YaST enables choice of select what you will see including older /dev/sda or the newer standard UUID.

    In addition to trying to disable UUID in grub(2), I have also set the "mount-by" in YAST to "LABEL". All entries in /etc/fstab referencing local file systems start with
    Code:
    LABEL=

    Quote Originally Posted by paulparker View Post
    Your details hd0 am guessing shows your hard drive root partition sda .

    Your details hd0,gpt1 am guessing with 7EB1-87B3 is sda2 an EFI boot partition, BTW may be a 'BIOS boot' partition.

    Close. It is a GPT-formatted drive in a system that starts grub(2) from the EFI System Partition, but the only "normal" partition is /dev/sda3, which is mounted at /boot. All of the other linux partitions are logical volumes located in a single LVM2 physical volume at /dev/sda4. The root partition is at /dev/dm-0.

    Quote Originally Posted by paulparker View Post


    I appreciate your efforts, but even your reference acknowledges that there are situations where UUID is not appropriate.

    IMO a boot drive is one of those situations. (unless, of course, you can guarantee that there will NEVER be a hard drive failure).

    As near as I can tell, If you use UUID, don't bother backing up. The backup is useless anyway.

    ron

  5. #5
    Join Date
    Jun 2008
    Location
    Auckland, NZ
    Posts
    23,710
    Blog Entries
    1

    Default Re: How do I eliminate UUID dependence?

    UUID makes it IMPOSSIBLE to migrate a system and replace the boot drive without jumping through extraordinary hoops.

    If there is ANY reasonable way to eliminate this rabid infatuation of UUID from an openSUSE system, please let me know,

    I am particularly interested in eliminating UUID dependence in grub2-mkconfig and mkinitrd(dracut).
    It is possible to create your own grub.cfg manually
    https://www.gnu.org/software/grub/ma...#Configuration
    and the os-prober can be disabled with the following set in /etc/default/grub using....
    Code:
    GRUB_DISABLE_OS_PROBER=true
    More information here about inhibiting some of the automatic generation (which reads like what you need for system migration purposes)
    https://wiki.archlinux.org/index.php...iguration_file

    For dracut, 'man dracut' is your friend
    Specifying the root Device
    This is the only option dracut really needs to boot from your root partition. Because your root partition can live in various
    environments, there are a lot of formats for the root= option. The most basic one is root=<path to device node>:

    root=/dev/sda2

    Because device node names can change, dependent on the drive ordering, you are encouraged to use the filesystem identifier
    (UUID) or filesystem label (LABEL) to specify your root partition:

    root=UUID=19e9dda3-5a38-484d-a9b0-fa6b067d0331

    or

    root=LABEL=myrootpartitionlabel

    To see all UUIDs or LABELs on your system, do:

    # ls -l /dev/disk/by-uuid

    or

    # ls -l /dev/disk/by-label

    If your root partition is on the network see the section called “Network Boot”.

  6. #6
    Join Date
    Sep 2012
    Posts
    7,106

    Default Re: How do I eliminate UUID dependence?

    Quote Originally Posted by paulparker View Post

    Your details hd0 am guessing shows your hard drive root partition sda .
    Wrong. BIOS device order has absolutely no relation to Linux device order.

  7. #7
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    3,388
    Blog Entries
    1

    Default Re: How do I eliminate UUID dependence?

    You might try what I do (though I don't use LVM), and let the defaults create and use their bloat without getting in your way:

    1-ln, cp or mv /etc/grub.d/40_custom to 07_custom. # (places your stanzas ahead of mkconfig's in the Grub runtime menu)

    2-build a /boot/grub2/custom.cfg that works without so much clutter, e.g.:
    Code:
    menuentry "openSUSE TW defkernel" {
    	search --no-floppy --set=root --hint-bios=hd0,gpt6 --label ostw
    	linuxefi /boot/vmlinuz root=LABEL=ostw noresume foo bar baz
    	initrdefi /boot/initrd
    }
    menuentry "openSUSE 150 defkernel" {
    	search --no-floppy --set=root --hint-efi=hd0,gpt7 --label os150
    	linuxefi /boot/vmlinuz root=LABEL=os150 noresume foo bar baz
    	initrdefi /boot/initrd
    }
    menuentry "Debian 9 Stretch defkernel" {
    	search --no-floppy --set=root --hint-baremetal=ahci0,gpt8 --label deb9
    	linuxefi /boot/vmlinuz root=LABEL=deb9 noresume dfoo dbar dbaz
    	initrdefi /boot/initrd
    }
    menuentry "openSUSE 423 defkernel" {
    	search --no-floppy --set=root --hint-efi=hd0,gpt9 --label os423
    	linuxefi /boot/vmlinuz root=LABEL=os423 noresume foo bar baz
    	initrdefi /boot/initrd
    }

  8. #8
    Join Date
    Dec 2008
    Location
    Buffalo, MN USA
    Posts
    82

    Cool Re: How do I eliminate UUID dependence?

    Quote Originally Posted by deano_ferrari View Post
    It is possible to create your own grub.cfg manually
    https://www.gnu.org/software/grub/ma...#Configuration
    and the os-prober can be disabled with the following set in /etc/default/grub using....
    Code:
    GRUB_DISABLE_OS_PROBER=true
    OS_PROBER is actually pretty handy (at least for the first run), since this is a multi-boot system.

    Quote Originally Posted by deano_ferrari View Post
    More information here about inhibiting some of the automatic generation (which reads like what you need for system migration purposes)
    https://wiki.archlinux.org/index.php...iguration_file


    Thanks for that link. While most of it is a rehash of info obtained by entering
    Code:
    info:grub2
    into the address bar of Konqueror, I discovered some new info by expanded reading and following the links. I now have e.g. a better understanding of the limitations of the rescue console. And I also know why, when I first installed openSUSE (as the first Linux distro) onto this machine, I had to copy <ESP>/EFI/opensuse/grubx64.efi to <ESP>/EFI/Boot/bootx64.efi in order to boot into something other than Windows.

    Quote Originally Posted by deano_ferrari View Post
    For dracut, 'man dracut' is your friend
    Code:
    Specifying the root Device
               This is the only option dracut really needs to boot from your  root partition. Because your root partition can live in various
               environments, there are a lot of formats for the root=  option. The most basic one is root=<path to device node>:
    Actually, specifying the URI man:dracut.conf (again, in the address bar of Konqueror) was the key. It was there that I learned that I needed to look in /usr/lib/dracut/dracut.conf.d/ to find the file with the openSUSE customization which appeared to prevent dracut from creating an initrd that worked.

    I had been trying multiple invocations of dracut, always specifying root=LABEL=<root-fs-label>. none of them worked. Moreover, I couldn't save /run/initramfs/rdsosreport.txt. I couldn't figure out how to mount a USB thumb drive from within the dracut shell, and it wouldn't let me mount the /boot partition because it claimed to know nothing about ext4. After editing /usr/lib/dracut/dracut.conf.d/01-dist.conf, I tried dracut once again. Once again it failed to produce a useable initrd. So I tried mkinitrd. That worked. I got a large (~48 MB) initrd image that was using labels, not uuid to search for filesystems. I copied that over to the new drive and sucessfully booted using the new initrd.

    I haven't yet discovered the location where openSUSE tells grub to insist on using uuids, so I'll probably follow the suggestion by mrmazda:
    Quote Originally Posted by mrmazda View Post
    You might try what I do (though I don't use LVM), and let the defaults create and use their bloat without getting in your way:

    1-ln, cp or mv /etc/grub.d/40_custom to 07_custom. # (places your stanzas ahead of mkconfig's in the Grub runtime menu)

    2-build a /boot/grub2/custom.cfg that works without so much clutter,
    That's something I hadn't considered, but it sounds like a good idea.

    Thanks to all for your help,
    ron

  9. #9
    Join Date
    Jul 2008
    Location
    Seattle, WA
    Posts
    17,317

    Default Re: How do I eliminate UUID dependence?

    Over the weekend, I did a hard drive replacement/clone with an upgrade to
    42.3. Overall, it worked well, other than trying to convert the root
    partition to btrfs (that part failed miserably and led to a reinstall of
    the OS).

    But basically, here's what I did:

    1. Use Clonezilla to copy the partitions to the new drive.
    2. Use gdisk to change the partition table from MBR to GPT (it's on the
    Clonezilla live image)
    3. Use Gparted to resize/move the partitions. At this point the device
    was totally unbootable - not even the Windows partition would boot (not
    that I care about that at all - it's Win7, and just there for firmware
    updates).
    4. Run the openSUSE upgrade. The only thing I had to do differently was
    "show all partitions" and then tell it where the home partition actually
    was (because the ID was different).
    5. Wait for the upgrade to complete.
    6. Let the system boot up - it failed to mount /home (but / did mount)
    7. Enter emergency shell
    8. Run YaST and enter the partitioner
    9. Change the partition entries for /home and swap to the new drive
    10. Reboot

    At that point, there seemed to just be a residual entry that was causing
    it to try to mount the old swap partition.

    You can head this off by going into the YaST partitioner and changing
    each mount point to "by device" prior to doing the clone, and then switch
    it back afterwards (I'd recommend by-id at a minimum - since modern Linux
    kernels don't guarantee device names are consistent from boot to boot).

    The only thing that failed, as mentioned above, was my attempt to convert
    ext4 to btrfs (which isn't related to the mounting issues). That caused
    system lockups and some weird corruption in the extents table - and was
    probably just due to my lack of familiarity with doing that "properly".
    It's not as simple as booting from the installation media and running
    'btrfs convert' (which IIRC is what I did) on the partition.

    Jim

    --
    Jim Henderson
    openSUSE Forums Administrator
    Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

  10. #10
    Join Date
    Dec 2008
    Location
    Buffalo, MN USA
    Posts
    82

    Default Re: How do I eliminate UUID dependence?

    Quote Originally Posted by hendersj View Post
    Over the weekend, I did a hard drive replacement/clone with an upgrade to
    42.3. Overall, it worked well, other than trying to convert the root
    partition to btrfs (that part failed miserably and led to a reinstall of
    the OS).

    But basically, here's what I did:

    1. Use Clonezilla to copy the partitions to the new drive.
    I have used Clonezilla multiple times with great success. It's a real godsend.

    I chose to not use it in this instance because the replacement drive was double the size of the old one and I wanted more control over the partition sizes on the new drive. (Actually, I DID use Clonezilla too, to save and restore the partitions used by Windows 10) I also wanted to add an additional LV in the PV and thought it would be easier to create the LVs in the size I wanted, rather the resizing everything after the migration.

    Moreover, I've gotten in the habit of doing tar backups on any machine using LVM after discovering that one of the downsides of LVM across multiple drives is that it's VERY difficult to accurately determine exactly which of the drives is failing and restore that drive. Even when using Clonezilla.

    I assumed (silly me) that since the original LEAP 42.1 (now 42.2) install had specified by-label for the mount points, that the uuid scourge had been bypassed. Oops.

    Thanks,
    ron

Page 1 of 2 12 LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •