sunrat wrote:Yeah it's pretty straightforward once you work out how trailing slashes behave.
p.H wrote:Did you check that the new partition is actually mounted as / ?
p.H wrote:Did you check that the new partition is actually mounted as / ?
p.H wrote:As I wrote in my previous message:
- mount and chroot the new partition with /dev/, /sys and /proc
- run update-grub
- exit the chroot and unmount the above
- run update-grub
Or you can edit /boot/grub/grub.cfg on both partitions and replace the UUID of the original partition with the one of the new partition in the root= options of the menu entries for the system on the new partition.
ticojohn wrote:my brain is not getting it
Head_on_a_Stick wrote:ticojohn wrote:my brain is not getting it
The stretch release notes have a nice section about recovery:
https://www.debian.org/releases/stretch ... 07.html.en
ticojohn wrote:It appears that it is NOT working as expected.
p.H wrote:ticojohn wrote:It appears that it is NOT working as expected.
It was just working as I expected, not as you expected.
Sorry for bringing bad news and extra work.
A bit of explaination :
When update-grub/grub-mkconfig detects another Linux installation into the GRUB menu and builds a menu entry for it, it looks for a grub.cfg file in this installation. If it finds the file, it copies the kernel command line parameters, including the root= parameter. I guess this is a rather unknow feature of update-grub.
Since the "other" system is a backup copy of the original system, its grub.cfg file contains root= with the UUID of the original root partition. So, even though GRUB loads the kernel and initramfs from the backup partition, they mount the orginal partition as root.
Running update-grub from the backup system would update its grub.cfg with the backup partition UUID. Then running update-grub from the original system would update its grub.cfg with the UUID present in the grub.cfg on the backup partition.
Users browsing this forum: No registered users and 6 guests