Copy of system disk won't boot -- bad methodology, or USB attach problem?

English Install/Boot/Login
1

All the following edited for brevity/clarity. The basic concept should match the slightly more complicated reality.

I currently have a system with a single 500 MB drive which has small 32-bit openSUSE 13.2 and swap partitions, and a large user data partition. I want to install a second, small drive with 13.2+swap and reformat the entire large drive for data. I wanted to try copying the 13.2 partition rather than doing a full reinstall, partly as a learning exercise. Because the old and new 13.2 partitions’ sizes are different this would not be a block-by-block, dd[FONT=arial], copy.

I attached the new drive with an IDE/PATA-to-USB adapter, created a linux and a swap partition with [FONT=courier new]fdisk[FONT=arial] (leaving 1MB for an MBR and bootloader at the beginning of the drive), and formatted them with mkfs.ext4[/FONT] and **mkswap ** respectively. I then copied the running 13.2 system from the old drive to the new with:

rsync --verbose \
      --archive \
      --xattrs \
      --acls \
      --hard-links \
      --sparse \
      --one-file-system \
      --numeric-ids \
      --exclude=lost+found \
      --exclude=proc/\* \
      --exclude=sys/\* \
      --exclude=mnt/\* \
      --exclude=media/\* \
      --exclude=dev/pts\* \
      --exclude=tmp/\* \
      /{*,.*} \
      /mnt/sdb1

Then:

  • Edited **/mnt/sdb1/{etc/fstab,boot/grub2/grub.cfg} **
    and changed all UUIDs from the old disk’s to the new one’s (and changed a menuentry string to confirm that the new grub.cfg was being used at boot time). - Ran grub2-install --boot-directory=/mnt/sdb1/boot /dev/sdb
  • Checked and saw that **sdb **
    [FONT=arial]had bootloader code following the MBR which also had the 13.2 partition’s boot flag set[/FONT]

[FONT=arial]With the BIOS set to the USB drive, the copied system is definitely trying to boot – the modified GRUB menu entry shows up. I get “loading system” and “loading initial ramdisk” and a brief flash of the green “splat” (Plymouth?) screen.

But it immediately returns to a text virtual terminal with:

  OK  ] Reached target System Initialization.
  OK  ] Started Show Plymouth Boot Screen.
  OK  ] Reached target Paths.
  OK  ] Reached target Basic System.

[/FONT][/FONT][/FONT]and hangs there for 5 minutes before dumping into a “dracut” rescue shell.

The critical line in dracut’s /run/initramfs/rdsosreport.txt seems to be:

  313.618838] ffcat dracut-initqueue[191]: Warning: /dev/disk/by-uuid/049cad3c-0724-4a10-a5ad-1ee7eef88157 does not exist

That’s the correct UUID of the new disk’s root partition. But checking /dev/disk/by-uuid in the running dracut shell shows only the UUIDs of the old disk. It’s also clear from earlier in *rdsosreport.txt [FONT=arial]that only the old disk is being detected and having [FONT=courier new]/dev/sd **[FONT=arial]entries created – nothing for the new disk

Three possible problems (probably more):

  1. There’s a fatal flaw in my methodology. (I was afraid of the [FONT=courier new]rsync
    [FONT=arial] copy from a running system, but the boot is failing long before that.)[/FONT] 1. [FONT=arial]The old UUIDs are baked into [FONT=courier new]/boot/initrd*
    [FONT=arial] (which was copied unchanged from the old disk) and GRUB isn’t or can’t pass new parameters to it.[/FONT][/FONT][/FONT] 1. [FONT=arial][FONT=courier new][FONT=arial]Some combination of [/FONT][/FONT][/FONT][FONT=arial][FONT=courier new][FONT=arial][FONT=courier new][FONT=arial][FONT=courier new]initrd
    [FONT=arial] and/or this BIOS can’t scan a USB-attached drive (works fine with an already running system).[/FONT][/FONT][/FONT][/FONT][/FONT][/FONT][/FONT]

[FONT=arial][FONT=courier new][FONT=arial][FONT=courier new][FONT=arial][FONT=courier new][FONT=arial]Any suggestions, particularly critiques of #1, welcome.
[/FONT][/FONT][/FONT][/FONT][/FONT][/FONT][/FONT]
[/FONT][/FONT][/FONT][/FONT]

2

Did you remake the “initrd”?

If not, that’s probably what you need to do.

Boot a 32-bit rescue system (or the old hard drive).

Mount your new partition at “/mnt”. Mount any other needed partitions (you probably don’t have any, since you didn’t mention them).


# mount --bind /dev /mnt/dev
# mount --bind /sys /mnt/sys
# mount --bind /proc /mnt/proc
# chroot /mnt
#### you should now be in a "chroot" shell
# mkinitrd
# exit

You are booting from a USB. That requires that the “initrd” has loaded USB drivers before it tries to mount the root file system. My guess is that they are not loaded, which is why that UUID is not being found. Hopefully, rebuilding the “initrd” will fix that.

3

THANK YOU!!!

Yes, that was the problem. I followed your recipe and the new disk now boots from its USB attachment!

The remaining thing I don’t understand (one of many, I’m sure) is in the grub.cfg that mkinitrd created (didn’t know it was going to do that, too). Like I said before, I had edited grub.cfg to change all the old UUIDs to the new ones. The mkinitrd got those right, due to the chroot, but it mistakenly put in a bunch of resume=/dev/disk/by-uuid/<an_old_disk_uuid>, where the “old_disk_uuid” was the current running disk’s swap, in spite of the chroot. This is understandable.

In my hand-edited grub.cfg I had not changed all the GRUB-style disk IDs like in set root=‘hd0,msdos3’ because the disk will moved off USB and into the machine’s case and directly attached to the motherboard in the final system – the USB thing was all for testing. As an experiment I restored my grub.cfg and booted, USB-attached, with the USB-enabled initrd. It worked.

So are the GRUB-style IDs ignored? I’ve been trying for a long time to understand how to make drives/DVDs/USB_sticks that work regardless of what IDE/master/slave/SATA/USB port they’re attached to, and thought that UUIDs were the answer. (They seem to be in fstab, for example.) BTW, why do partitions always say “msdos” in GRUB2? The partition’s Id/Type is always “83 Linux” in fdisk, and there’s never been a Microsoft-sourced byte anywhere on the drive.

Again, thanks for the quick and accurate fix for my immediate problem. And if it’s not obvious, I really do appreciate the education.

4

It got that swap information from “/etc/default/grub”. You will need to edit that file to change the UUID used.

The "set root=‘hd0,msdos3’ should not matter. That sets a temporary value that is normally overridden by a search for UUID.

With the system booted from the USB, you can edit “/etc/default/grub”, and then:

# grub2-mkconfig -o /boot/grub2/grub.cfg

and it should now generate a correct grub.cfg.

And yes, I took it that you were wanting to learn stuff. You had most of it right.

5

A couple of points that I missed.

A typical “grub.cfg” might contain:


set root='hd0,msdos3'
search --set=root --fs-uuid 049cad3c-0724-4a10-a5ad-1ee7eef8815

(I simplified it a little).

That initially sets “root” to the indicated partition, but then changes it to the partition with the given UUID if the search is successful.

BTW, why do partitions always say “msdos” in GRUB2?

That indicates an “msdos” style partition table, sometimes called “MBR partitioning” or “Legacy partitioning”.

On the computer where I am writing this, I see

set root='hd1,gpt3'

and that’s because I have a GPT partition table.

6

Good/useful info, as you always give. Thanks.

I’d seen the ‘hd1,msdos1’ style partitions in the grub.cfg “search” commands,like** --hint-bios=hd1,msdos1**. That I got – it says “hint” right there. Didn’t realize the standalone set root=‘hd1,msdos1’ was also “hint-like” in that the search would override. Makes sense now.

Likewise with “msdos” == “MBR” in GRUB’s partition naming scheme. I’ve never had an UEFI/GPT box, although my next one certainly will be. More to read up on. If GRUB called it something like hd1,BIOS I’d have understood. But I guess that since the birth of Microsoft was synchronous with the PC/x86/BIOS architecture they get to have their name on it. :wink:

7

MS more or less invented the DOS partitioning scheme. Should be obvious from it’s limitations :stuck_out_tongue: