#613 Issue `closed`: No code to has been generated to restore fs:/ Debian 8 jessie systemd root on LVM¶

Labels: documentation, support / question

rpasche opened issue at 2015-07-07 11:42:¶

Hi,

just found another issue. When / is on an LVM (this might also affect /usr), then systemd (systemd-remount-fs) does a "remount" on those 2 mountpoints, which seem to cause both mountpoints to be remounted with the kernel devices names and not the symlinks from /dev/mapper/....Because of this, a recovery fails totally!

This leeds to something like this (diskdeps.conf)

root@debian8:# cat diskdeps.conf
/dev/sda1 /dev/sda
/dev/sda2 /dev/sda
/dev/sda5 /dev/sda
/dev/debian8-vg pv:/dev/sda5
pv:/dev/sda5 /dev/sda5
/dev/mapper/debian8--vg-root /dev/debian8-vg
/dev/mapper/debian8--vg-swap_1 /dev/debian8-vg
fs:/ /dev/dm-0     <<= fault here
fs:/boot /dev/sda1
fs:/boot /dev/sda1
fs:/boot /fs:/
swap:/dev/mapper/debian8--vg-swap_1 /dev/mapper/debian8--vg-swap_1
root@debian8:#
root@debian8:# cat /etc/fstab
...
/dev/mapper/debian8--vg-root /     ext4     errors=remount-ro
...

root@debian8:# mount
...
/dev/mapper/debian8--vg-root on / ext4 (rw,reltime.....)
...

root@debian8:# df -h /
/dev/dm-0             7.2G          3,2G    3,7G      47% /

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784105 for additional info

gdha commented at 2015-07-07 12:26:¶

@rpasche could you run a rear -vD savelayout to see where it goes wrong? And, I'm not yet convinced this is a rear bug, if Debian decides to do it different to avoid confusing then it gets confusing...to others.

rpasche commented at 2015-07-07 12:39:¶

I did not say, this is a rear bug. Just telling that there is an issue in this constelation ;-)

What files do you want?

gdha commented at 2015-07-07 12:45:¶

@rpasche the rear.log, and the files under /var/lib/rear/layout - thanks - perhaps use gist to link to this issue

rpasche commented at 2015-07-07 12:55:¶

https://gist.github.com/rpasche/ae4511bbf29e829db682

rpasche commented at 2015-07-08 06:21:¶

I think I found the error. It is within the initrd (maybe only within Debian). There is a function, that, given a device path for / filesystem (e.g. /dev/mapper/vg_lv-root), that resolves the links to get the real device (e.g. /dev/dm-0) for an LVM device.

This happens for /, /usr and /etc if these are separate mountpoints within /etc/fstab.

Grmpf....meanwhile, I'm sick of debian 8.

rpasche commented at 2015-07-08 09:32:¶

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791754. Just sent a patch for the function "resolve_device", that - for me - works very well. Patch is - not yet - on the list.

rpasche commented at 2015-07-08 09:43:¶

After I patched my initrd function and rebuilt the initrd, rear recover works as expected.

gdha commented at 2015-07-09 07:10:¶

@rpasche thank you for sharing your comments - please add any update as follow-up - could be interesting for other Debian8 victims.

gdha commented at 2015-08-06 11:42:¶

@rpasche could you share a few lines of your incident to add to our FAQ web page?

rpasche commented at 2015-08-06 20:11:¶

I'm not sure, what else I should tell, that wasn't mentioned in the bug report on Debian? When / is located on an LVM, then within initrd, this filesystem will be mounted with the "real" kernel device name and this gets written to /proc/mounts.

To fix this, you can use the patch that I have added to the bug report, update the initrd afterwards and pin the "initramfs-tools" package until this gets fixed upstream.

gdha commented at 2015-08-11 11:56:¶

Added it to the release notes.

pexus commented at 2016-01-01 16:40:¶

I am still having this issue when restoring a backup created on Debian Jessie. I did apply the patch to initramfs - shell script file functions as explained here (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791754) before creating the backup image. Anyone successfully did a backup restore on Debian Jessie (8.x) ?. Error received when restoring:
No code has been generated to restore device fs:/

Here is my steps to create backup and restore:

Patched the file functions in /usr/share/initramfs-tools/scripts/functions
formatted USB disk with rear format
Did rear backup - rear -v mkbackup
Restoring with - rear recover

Error : No code has been generated to restore device fs:/ (fs)
Please add code to /var/lib/rear/layout/diskrestore.sh to manually it or choose abort.

Any pointers is greatly appreciated.
Thanks
Pradeep

pexus commented at 2016-01-01 16:42:¶

I am reading the issue resolution again, I think I have to re-build initrd ? I will try that.
Any other way to resolve this without rebuilding initrd ?

pexus commented at 2016-01-01 17:33:¶

I wanted to update - after I updated the initrd using command ( update-initramfs -u ), then then taking a backup, the recover seem to be proceeding.

I did notice that during the recovery process, I see the following on the console that displays the decrypting archive key. Can this be disabled or masked. Showing the decrypting key is not a best practice from security.

"Decrypting archive with key: XXXXXX"

Thanks

rpasche commented at 2016-01-02 10:31:¶

I think this is another issue and should be opened separately. And just a note. The bug has been "closed" in "unstable" on debian. So you do not have to "pin" the initramfs-tools package on debian systems, when they are running "unstable".

Regards,
Robert

[Export of Github issue for rear/rear.]

#613 Issue closed: No code to has been generated to restore fs:/ Debian 8 jessie systemd root on LVM¶