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. _______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
