Changes to grub.conf (=menu.lst?) get lost.

[veelo]

If you have a SATA drive that shows as /dev/sda in your distribution but as /dev/hda during recovery, you have likely edited the mountlist to use hda. After your data has been restored, you are given the opportunity to edit fstab and grub.conf. Fstab was changed by grub to use hda, so you change it back to sda because that is what it will look like on next boot. I do not know any file by the name grub.conf, but I recognise the contents as being /boot/grub/menu.lst. If it contains root=UUID=... on kernel rows, you will want to change that to root=/dev/sda1 because after recovery the UUIDs seem to have been regenerated and different (Great fun. What is the point of partition IDs that keep changing like this?!)

The problem is that changes made to that file do not show up in /boot/grub/menu.lst. So the system will not boot as it should.

There is a way out of it: to select a recovery mode kernel from the boot menu (which has no "quiet" or "splash" options), wait 4 minutes while it tries to mount the root filesystem (why that long??) and enter the shell. Then make a mount point, mount /dev/sda1, chroot in it, use your favorite editor to edit /boot/grub/menu.lst to use /dev/sda1 instead of UUIDs and reboot.

Now you can boot the normal way.

Note that one call to update-grub (happens when you install a new kernel) puts the UUIDs back in there, but this time they correspond to the UUIDs in /dev/disk/by-uuid/. Oh and do not try the short-cut of calling update-grub in the shell above, as the UUIDs will be wrong.

UUIDs are a pain in the neck, but the point of this ticket is that changes to "grub.conf" during recovery do not persist.

[Bruno Cornec]

That should be fixed in the current beta version. Will be in 2.2.5

[Bruno Cornec]

Please test and report with the versions under ​ftp://ftp.mondorescue.org/ubuntu/7.10/test

[Bruno Cornec]

Should be fixed with official 2.2.5. If not, please reopen the bug report.