Urbackup changing root device even after uninstall

client
1

Urbackup changes your root device to a DM device of its own creation, even after uninstalling, here are the offending lines:

 /usr/share/initramfs-tools/scripts/local-top/urbackup-setup-snapshot:34:echo "0 $RBD_SIZE linear $RBD 0" | dmsetup create root-98d1f8b1f435 2> /dev/kmsg
/usr/share/initramfs-tools/scripts/local-top/urbackup-setup-snapshot:36:echo "export ROOT=/dev/mapper/root-98d1f8b1f435" > /conf/param.conf

This had me going crazy. I couldn’t for the life of me figure out what was changing my root device mid-boot. It kept coming back after I removed the offending lines in the initrd and other boot scripts. I had to grep my whole boot volume looking for it. Especially confusing since I uninstalled the urbackup client from this computer months ago. This screws up the ubuntu update-grup script which sets the root volume in grub.cfg to the mapped volume, that doesn’t get mapped till after root is mounted, which causes boot to fail.

Edit: This was on Ubuntu 19.04

2

Sry, yeah, I ran into that update-grub on kernel update problem myself as well (and improved the error somewhat in that case, but wasn’t able to make grub discover the real device).

Will definitely add a remove on uninstall…

I think the only proper solution is to have the whole thing integrated in grub and/or Debian/Ubuntu.

3

It would be nice to maybe throw a “UrBackup setting root device to $devicename” or something like that into the system log so that if things do go screwy they’re easier to track down.

4

@nixcamic @uroni How exactly did you end up fixing the issue with your root device. I seem to have run into the same thing on linux mint and i really dont know enough about the boot system to figure out how to fix it.

1 Like
5

@PrimevalGod @nixcamic Did you guys get a solutin to this issue. I m stuck on this

6

@Andile_Simelane I never got an answer to this. I did manage to fix my laptop unfortunately I don’t really know how.

1 Like
7

Ran into this exact issue and am here to pay it forward with my at least partial solution. I still have not figured out how to remove whatever is creating the script in local-top so I’m going to have to run these steps every time until i can find a way to fix my update-grub… but I’ve found a way to help people get back into their device if they were stuck at initramfs like I was all day:

During boot, when grub appears, press c to access the grub command line.
If you’re somehow exactly like me and your root filesystem is on (hd0,1) and are running Linux image 6.1.0-8 on an AMD chip then type these lines exactly:

set setup-snapshot=0
set root=(hd0,1)
linux /boot/vmlinuz-6.1.0-8-amd64 root=/dev/sda1
initrd /boot/initrd.img-6.1.0-8-amd64
boot

and that should get you into your OS,
If you’re in any way different, consult below:

If you’re multibooting and want to determine what drive to use, type ls to list drive options in grub. Then you may type cat (hd0,1)/etc/issue , substituting the (hd0,1) for whatever option you’re checking. If you get something that reads similar to “Debian GNU/Linux 12 \n \l” (I’m running Debian so thats what mine says) its the right one.

If you’re not on (hd0,1) then you’ll need to change the root= value off of /dev/sda1, that value can be extrapolated from the hd value.
hd1,1 is sdb1
hd1,2 is sdb2
hd2,2 is sdc2 and so on

Find your /boot/vmlinuz by tabbing to autocomplete whatever you have in the /boot directory, same for the initrd file.

If anyone finds a way to get rid of the local-top scripts please let me know

8

Remove the scripts then run update-initramfs -u. But this should now be happening on uninstall: