Re: Breaking out of menu on "live disk", repairing grub

[Simon Hobson]

Felix Miata wrote:
>My guess is the trouble you had may have stemmed from use of UUIDs in Grub 
>stanzas and/or initrds. If you prepped the new disk prior to restoration of 
>files rather than restoring via a partition cloning process, UUIDs would have 
>changed, meaning root= would need to be different on the cmdline(s) on the 
>new disk, and likely for fstab entries as well. "couldn't mount root 
>filesystem" is a common giveaway that root= is wrong.

Indeed. However in this case I'd dealt with those - the system wasn't starting 
raid before trying to mount the root volume off it. Once I found that you can 
fix the missing root (in this case, just "mdadm --assemble --scan"), exit the 
shell, and it will retry ... well it then booted and I was able to build an 
initrd that worked. Clearly there is something different between the chroot 
environment and the real environment.

>I use volume labels for root= and fstab, which avoids the UUID change 
>problem, but suffers from the same duplication problem as when having cloned 
>and then rebooting without removing the source first, leaving identical twins 
>to confuse the kernel and init.

Yes, I use labels as well, much simpler to manage - and typable for a mere 
human as well ! Annoying when you forget to label the new filesystem though.
More normally I just use partition labels (ie sda1 etc) - most of what I use 
doesn't have the problem of drives changing letters, so it's not a problem. I 
have hit that problem in the past, so I do know first hand what the problem is 
that UUIDs are addressing.

Thanks to those that have given assistance here. Much appreciated.