Custom Query (684 matches)
Results (151 - 153 of 684)
| Ticket | Owner | Reporter | Resolution | Summary |
|---|---|---|---|---|
| #190 | fixed | mondo-restore = mondorestore | ||
| Description |
On a generated boot CD, in /README and /mondo/ISO and probably other places, the command mondo-restore is used. This should be mondorestore. |
|||
| #191 | fixed | compare does not detect changed mountlist. | ||
| Description |
We have a machine in which the HD (a SATA) appears as /dev/sda when it runs off the HD, but when it runs off a mondo CD it appears as /dev/hda. If you do "nuke" then the change in the mountlist is detected and you have the opportunity to change "sda" into "hda". But if you do "compare" you do not, and you can either abort or continue, in which case of course the complete contents seem to differ. |
|||
| #192 | fixed | Changes to grub.conf (=menu.lst?) get lost. | ||
| Description |
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. |
|||
