Linux doesn’t find root file system when booting

bootgrubopensusessd

I bought an SSD and to try the speed improvement while leaving the current system intact, I cloned my old root partition (/dev/sda1) onto the SSD (/dev/sdb1) and added a new Grub boot entry:

title Desktop (SSD)
    root (hd1,0)
    kernel /boot/vmlinuz-3.11.10-11-desktop root=/dev/disk/by-uuid/1ba4ffc9-2783-4b16-8276-63e8f087fada
    initrd /boot/initrd-3.11.10-11-desktop

I want to keep Grub on the first HD and let it boot the root partition from the 2nd HD.

When I boot the new entry, the kernel starts to load, but complains that it can't mount the root file system and puts me into single user mode, where I can see /dev/sdb1 under /dev/disk/by-uuid/....

I also changed the root partition in /etc/fstab on the cloned partition, but I don't think the boot process goes that far, yet.

I tried different versions for the root= parameter, like /dev/sdb1 and UUID=…, but its always the same result.

Is there somthing fundametally flawed with my approach ?

How can I debug this best ?

Update: I had formated the new root partition as ext4 while the old root partition was ext3 and it seems my kernel wasn't ready to boot from ext4. Now it works nicely. Thanks for the tip to use GParted!

Best Answer

Had the same issue and was too tired to determine why and decided to learn it later but had to get backup and running.

http://sourceforge.net/projects/boot-repair-cd/

It required two runs but repaired a hard drive installed distro the end user tweaked and retweaked but couldn't remember how they got a non UEFI linux distro working SxS a UEFI win8 box and right before he used the linux GPART to reclaim that odd 20MB boot partition.

Read the reviews at sourceforge, people swear by it and I'd bet real money it can fix yours assuming you have time to download an atrociously large 500MB ISO.

Related Question