How do I eliminate UUID dependence?

English Install/Boot/Login
#1

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

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

# 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

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

 mount -o remount /dev/mapper/<VGname>-<LVname> /

and

 mount -o remount /dev/dm-1 /

or

 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

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/03/13/uuids-and-linux-everything-you-ever-need-to-know/



# 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

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


sudo hwinfo --block

or


sudo hwinfo --block | grep 'Device Files'

.

#4

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

LABEL=

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.

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

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/manual/grub/grub.html#Configuration
and the os-prober can be disabled with the following set in /etc/default/grub using…

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/GRUB#Generate_the_main_configuration_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

Wrong. BIOS device order has absolutely no relation to Linux device order.

#7

On Fri, 09 Feb 2018 20:06:01 +0000, r widell wrote:

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

I’m actually going through something like this right now as part of my
upgrade from 42.2 to 42.3. Hard drive started showing signs of failure,
so I bought a new one (a bigger one, at that).

Here’s what I’ve done:

  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

The only issues I saw after this was done were that the old swap
partition tried to mount (it timed out, and I removed it from fstab when
the system booted up; I could have done that in the emergency shell as
well), and the root partition entry in fstab pointed to the old
(disconnected) drive, but the system did actually boot anyways. I
manually fixed the fstab so it reflected the actual device name instead.

Before cloning the drive, I could as easily have made those changes to
fstab and the grub device.map - but device.map was fixed during the
upgrade anyways.

Jim

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

#8

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

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
}
#9

OS_PROBER is actually pretty handy (at least for the first run), since this is a multi-boot system.

](https://wiki.archlinux.org/index.php/GRUB#Generate_the_main_configuration_file)
Thanks for that link. While most of it is a rehash of info obtained by entering

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 /EFI/opensuse/grubx64.efi to /EFI/Boot/bootx64.efi in order to boot into something other than Windows.

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:

That’s something I hadn’t considered, but it sounds like a good idea.

Thanks to all for your help,
ron

#10

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

#11

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

#12

There are downsides to all things. by-label means you can not have two partitions with the same label strings attached to the machine at the same time. UUID is a random string created when the partition is created. and you only need to correct in /etc/fstab to make things boot.

#13

Actually you can have two attached at the same time, as long as appropriate care is utilized, such as (ideally) not having source or target mounted, or not accessing either source or target filesystem. All my Linux native filesystem mounting and booting is done with LABEL=. As soon as a cloning operation is complete, I change label(s) and UUID(s) on the target(s), then use the Grub shell as appropriate on the target(s). Hardly a month goes by that I don’t clone something. Last night I cloned twice 42.3 in order to upgrade to 15.0 (first one I forgot to first set locks needed for unavailable 15.0 packages before upgrading, which the first dup dutifully removed, eliminating KDM3).

#14

Agree wrt limits on labels.
Disagree wrt “simplicity” of booting by changing /erc/fstab entry. If the new uuid isn’t identical to the old one, booting will fail since the uuid for the root fs in initrd is for the old entry.

Regards,
ron

#15

Yes, changing fstab is not enough. Note too that when initrds are built using dracut, cmdline parameters are 100% optional. Yet, boot stanzas prepared by the OEM scripts include several, one of which is root=. When included, as they customarily are, they override the initrd content. If you correctly edit or otherwise rebuild the bootloader menu to include an appropriate root=, then the fallback initrd content won’t matter either, and boot will not fail on account of the filesystem UUID or label changes.

#16

Close, but no cigar. You seem to be confusing the various root= definitions in grub2 with the root= definition to mkinitrd(dracut).

The

set root=

command in grub2 sets the environment variable “root” for grub, not linux. In the case of /etc/grub.d/00_header it defines the location of (normally) grub.cfg, in addition to vmlinuz and initrd. Later, when passed as an argument to the linux(16) command root= defines the location of the root-fs to the kernel.

Neither of those have ANY influence on the definition of root in the pre-existing initrd (the one invoked by grub2 with the initrd command). That definition is determined when the initrd is built, and is immutable. Subsequent, more careful reading of the dracut(8) man page leads me to believe that it’s possible to do a temporary override from within the (emergency) dracut shell. Creating a symlink to /dev/root from the REAL root-fs and exiting the dracut shell is supposed to permit the boot process to continue (mount the root-fs as rw, mount the remaining fs as specified in /etc/fstab, remainder of initialization steps). It’s not something I’ve tried yet, as my more brute-force workaround was successful and I have higher priority items to work on.

N.B. man dracut(8) yields

Create an initramfs <image> for the kernel with the version <kernel version>. If <kernel version> is omitted, then the version of the actual running kernel is used. If <image> is omitted or empty, then the default location /boot/initramfs-<kernel version>.img is used.

dracut creates an initial image used by the kernel for preloading the block device modules (such as IDE, SCSI or RAID) which are needed to access the root filesystem, mounting the root filesystem and booting into the real system.
implied to me that modules used by the kernel at the time of dracut invocation are included in the initrd created by dracut, since I couldn’t find any configuration file entries which would override the inclusion of said modules. My attempts at invoking dracut directly, and subsequent failure to boot using the resulting initrd, lead me to believe that I’m either not reading that passage correctly or that passage is incorrect. The mkinitrd shell script goes through great pains to ensure that all necessary modules get loaded. And I can boot using initrds created using that script.

Regards,
ron

#17

Sure, boot will fail, but you may edit /boot/grub2/grub.cfg. Replace the old uuid by the new one and you are done!

erlangen:~ # cat /run/media/karl/USB-Tumbleweed/etc/fstab 
**UUID=1ba335f4-9595-4fa1-9036-eccbe05b300d /                    ext4       acl,user_xattr        1 1**
erlangen:~ # 


erlangen:~ # cat /etc/fstab
UUID=8b190950-c141-4351-9198-7a9592b4fb34  /                ext4  noatime,acl                  1  1
UUID=704621ef-9b45-4e96-ba7f-1becd3924f08  /home            ext4  noatime,acl                  1  2
UUID=f5177cae-4082-44ed-9471-b99030f06866  /home-HDD        ext4  noatime,acl                  0  0
UUID=dbc33c75-0fbb-4619-add6-d204ecf63a43  /Tumbleweed-HDD  ext4  ro,noatime,acl,data=ordered  0  0
UUID=aa065695-b637-4d5d-bb2a-4ad459c9556a  swap             swap  defaults                     0  0
**UUID=28d31dc0-d570-417b-9b41-9afb2150bcce  /Tumbleweed-SSD  ext4  ro,noatime,acl,data=journal  0  0**
erlangen:~ #

I had an emergency system on an USB stick and found that impractical. I moved the system to an old SSD no longer needed elsewhere:

  • ran rsync -a --delete /run/media/karl/USB-Tumbleweed/ /Tumbleweed-SSD/
  • installed GRUB on /Tumbleweed-SSD/
  • changed /Tumbleweed-SSD/etc/fstab
  • replaced 1ba335f4-9595-4fa1-9036-eccbe05b300d
    by 28d31dc0-d570-417b-9b41-9afb2150bcce in file /Tumbleweed-SSD/boot/grub2/grub.cfg - booted successfully from 28d31dc0-d570-417b-9b41-9afb2150bcce
#18

Well, color me baffled.
I have never been able to migrate a system that boots and/or mounts via uuid.

Getting past grub has never been the problem.

Getting the REAL root-fs to mount rw has always been the problem. I’ve never been able to get past the point where it tries to mount the root-fs by UUID, and the UUID it’s looking for is the UUID of the previous root-fs. That UUID has been hard-coded into the initrd and can’t be changed (by me).

I’m glad that UUID works for you, it doesn’t work for me – and never has.

ron

#19

Install of Grub 2 was done straight forward:

mount /dev/sdb1 /Tumbleweed-SSD
mount -o bind /sys /Tumbleweed-SSD/sys
mount -o bind /dev /Tumbleweed-SSD/dev
mount -t proc /proc /Tumbleweed-SSD/proc
chroot /Tumbleweed-SSD /bin/bash
grub2-install /dev/sdb
grub2-mkconfig
Ctrl-D

fstab is now (I add /home later manually):

erlangen:~ # cat /Tumbleweed-SSD/etc/fstab
UUID=28d31dc0-d570-417b-9b41-9afb2150bcce  /      ext4  acl,user_xattr               1  1
UUID=704621ef-9b45-4e96-ba7f-1becd3924f08  /home  ext4  data=ordered,acl,user_xattr  0  0
erlangen:~ #

On the first boot the system performed normal:

erlangen:~ # journalctl -b -7 -u systemd-fsck-root.service --directory /Tumbleweed-SSD/var/log/journal/d99a35bad8159be52445db8759b3c9b0/
-- Logs begin at Sat 2017-09-09 13:33:30 CEST, end at Sun 2018-02-18 08:41:01 CET. --
Feb 17 08:04:39 localhost systemd[1]: Starting File System Check on /dev/disk/by-uuid/28d31dc0-d570-417b-9b41-9afb2150bcce...
Feb 17 08:04:39 localhost systemd-fsck[322]: /dev/sdb1: clean, 237492/1835008 files, 2247551/7340032 blocks
Feb 17 08:04:39 localhost systemd[1]: Started File System Check on /dev/disk/by-uuid/28d31dc0-d570-417b-9b41-9afb2150bcce.
erlangen:~ #
#20

Executive Summary:

  1. I will confirm that this works.
  2. I need to vigorously reexamine numerous assumptions, especially wrt grub2 tools.

Detailed response:
I tried to replicate the process Karl described.

  1. Install old, small (80GB), SATA HDD as only drive in a spare computer
  • 3 partitions-- 40 GB (ext4) /, 6 GB (swap) swap, remainder (ext4) /home.
  • clean install of openSUSE LEAP 42.3.
  1. Create migration target
  • 64 GB USB thumb drive
  • 3 partitions-- 30 GB (ext4), 6 GB (swap), remainder (ext4) /home.
  1. Reboot system from Partition Magic LiveCD
  2. Mount root & /home partitions of HDD & USB thumb drive at separate mountpoints.
  3. Invoke “rsync -a --delete” to copy data on HDD-root to USB-root and HDD-home to USB-home filesystems.
  4. Reboot from HDD (now running openSUSE LEAP 42.3).
  5. Mount root-fs of USB thumb drive and chroot to that mountpoint.
  6. Edit /etc/fstab so UUIDs of /, swap and /home reflect UUIDs of USB thumb drive partitions.
  7. Invoke “grub2-install” to install grub2 to USB thumb drive.
  8. invoke grub2-mkconfig and watch output stream by.
  9. Shutdown, remove HDD & reboot from US thumb drive.
  10. Grub2 launches and presents menu
  • Select default option
  • Boot hangs forever waiting for UUID of HDD to appear.

Well, that didn’t work.
Why?
A: Because grub2-mkconfig output was not redirected to /boot/grub2/grub.cfg of USB thumb drive.

So either manually edit /boot/grub2/grub.cfg of USB thumb drive, or reinvoke grub2-mkconfig using -o option to direct output.
I chose the latter:

  1. Reinstall HDD and boot from it.
  2. Mount rootfs of USB thumb drive and chroot to that mountpoint.
# grub2-mkconfig -o /boot/grub2/grub.cfg
  1. Shutdown. And remove HDD
  2. Reboot from USB thumb drive.

SUCCESS!!

Subsequent investigation shows that enabling GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub is ineffective. While it does eliminate the uuid= statements, it doesn’t eliminate other means of defining root as uuid. E.g.

set=root <value>

will also assign the uuid of <value> to root. There are 8 of these statements in the grub.cfg of a machine with both GRUB_DISABLE_LINUX_UUID and GRUB_DISABLE_OS_PROBER set to true.

So I apologize for my ignorant obstinance. I really thought that I had eliminated all instances of uuid in grub.cfg, so the definition of root=<uuid-value> “HAD” to be defined in the initrd. I was wrong. I will try to do better.

Thanks again,
ron