New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
rpasche opened this Issue Jul 7, 2015 · 15 comments

Comments

Projects
None yet
3 participants
@rpasche
Contributor

rpasche commented Jul 7, 2015

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 gdha self-assigned this Jul 7, 2015

@gdha

This comment has been minimized.

Show comment
Hide comment
@gdha

gdha Jul 7, 2015

Member

@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.

Member

gdha commented Jul 7, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@rpasche

rpasche Jul 7, 2015

Contributor

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

What files do you want?

Contributor

rpasche commented Jul 7, 2015

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

This comment has been minimized.

Show comment
Hide comment
@gdha

gdha Jul 7, 2015

Member

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

Member

gdha commented Jul 7, 2015

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

@rpasche

This comment has been minimized.

Show comment
Hide comment
Contributor

rpasche commented Jul 7, 2015

@rpasche

This comment has been minimized.

Show comment
Hide comment
@rpasche

rpasche Jul 8, 2015

Contributor

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.

Contributor

rpasche commented Jul 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rpasche

rpasche Jul 8, 2015

Contributor

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.

Contributor

rpasche commented Jul 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rpasche

rpasche Jul 8, 2015

Contributor

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

Contributor

rpasche commented Jul 8, 2015

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

@gdha

This comment has been minimized.

Show comment
Hide comment
@gdha

gdha Jul 9, 2015

Member

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

Member

gdha commented Jul 9, 2015

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

@gdha

This comment has been minimized.

Show comment
Hide comment
@gdha

gdha Aug 6, 2015

Member

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

Member

gdha commented Aug 6, 2015

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

@rpasche

This comment has been minimized.

Show comment
Hide comment
@rpasche

rpasche Aug 6, 2015

Contributor

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.

Contributor

rpasche commented Aug 6, 2015

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 gdha added documentation and removed waiting for info labels Aug 11, 2015

@gdha gdha added this to the 1.17.2 milestone Aug 11, 2015

@gdha

This comment has been minimized.

Show comment
Hide comment
@gdha

gdha Aug 11, 2015

Member

Added it to the release notes.

Member

gdha commented Aug 11, 2015

Added it to the release notes.

@gdha gdha closed this Aug 11, 2015

@pexus

This comment has been minimized.

Show comment
Hide comment
@pexus

pexus Jan 1, 2016

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:

  1. Patched the file functions in /usr/share/initramfs-tools/scripts/functions
  2. formatted USB disk with rear format
  3. Did rear backup - rear -v mkbackup
  4. 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 Jan 1, 2016

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:

  1. Patched the file functions in /usr/share/initramfs-tools/scripts/functions
  2. formatted USB disk with rear format
  3. Did rear backup - rear -v mkbackup
  4. 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

This comment has been minimized.

Show comment
Hide comment
@pexus

pexus Jan 1, 2016

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 Jan 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@pexus

pexus Jan 1, 2016

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

pexus commented Jan 1, 2016

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

This comment has been minimized.

Show comment
Hide comment
@rpasche

rpasche Jan 2, 2016

Contributor

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

Contributor

rpasche commented Jan 2, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment