Finally learned how to use rsync

[ticojohn]

After years of using Grsync to backup just /home, I decided it was time to learn how to use rsync. The main motivation was that I am thinking about upgrading Jessie (i386) to Stretch, and I thought it would be a good time to make a working backup of Jessie. After a bunch of on line searching, and a few missteps, I was finally able to rsync Jessie to an empty partition on my hard drive (Jessie is on a SSD). After changing the entries in fstab, and then updating grub, I now have a working duplicate of Jessie. rsync is COOL!

[sunrat]

Yeah it's pretty straightforward once you work out how trailing slashes behave.

[p.H]

Did you check that the new partition is actually mounted as / ?

In, my experience, updating fstab on the backup system and running update-grub on the original system is not enough and results in the new menu entry mounting the original partition as / ; you need to run update-grub from the backup system (in chroot) before doing it on the original system.

[ticojohn]

Yeah it's pretty straightforward once you work out how trailing slashes behave.

Yep! That caused a few missteps but I finally got there.

[ticojohn]

Did you check that the new partition is actually mounted as / ?

I am still pretty much a noob when it comes to Linux, even though I have been using it for about 7 years, so I'm not sure I understand the question nor how to verify that the partition is mounted as /. I am able to select and load the new partition (sdb1). When I open pcmanfm and look at the file system the top level appears to be /. I will do some further checking but everything is functioning as desired.

[ticojohn]

Did you check that the new partition is actually mounted as / ?

OOOPPPS ! It appears that it is NOT working as expected. When I select the new partition (sdb1) in the grub menu, it is actually booting the original partition (sda1). So what do I need to do?

[p.H]

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]

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.

Okay. Not sure editing the /boot/grub/grub.cfg files is a good idea. WOuldn't it get changed when I do update-grub? And my brain is not getting it with your instructions. I will do some research, unless you want to give me detailed instructions. Thanks for the help.

[Head_on_a_Stick]

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]

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

Thanks HOAS. What's the worst that can happen?

[ticojohn]

HOAS, if you're there, I do not see a menu option for 'rescue'. I see a recovery mode, but not 'rescue'. Am I being stupid?

[Head_on_a_Stick]

There's an entry on the Debian ISO image GRUB menu, I think.

If not, we've recently added that option to the BunsenLabs Helium-dev ISO image so you could use that:

https://mirror.vinzv.space/bunsenlabs/helium/beta/

[ticojohn]

Okay. I followed the advice from p.H and edited the /boot/grub/grub.cfg on both sda1 and sdb1. After verifying that I could boot as desired I then did update-grub on both sda1 and sdb1. Everything now appears to be working as desired. I know that this probably was NOT the best practice but it got the results I wanted.

Thanks to HOAS and p.H for their help and advice.

[p.H]

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 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, in the menu entry, including the root= parameter instead of using the actual root location. 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.

[ticojohn]

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.

Thanks for that explanation. It makes things a lot more clear to me. Good to know info. Thanks a lot. Eventually I may get around to learning how to use chroot. Probably come in handy.