#2247 Issue closed: Add new 'mountonly' workflow

Labels: enhancement, documentation, fixed / solved / done

petroniusniger opened issue at 2019-10-04 15:43:

  • ReaR version ("/usr/sbin/rear -V"): latest

  • OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"): all

  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"): n/a

  • Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR): all

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device): all

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot): all

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe): all

  • Description of the issue (ideally so that others can reproduce it): Not an issue but an improvement suggestion.

I propose the addition of a new workflow called 'mountonly' whose goal would be, based on the system layout created during 'mkrescue' or 'mkbackup', to simply mount the filesystems of a possibly broken but repairable system without altering them in any way, the ReaR rescue image being used as a mini "live distribution" in this case. This would then give the administrator an ideal starting place to try and repair that system manually, either by editing files from the ReaR rescue media, or by chrooting into the now mounted system.

This 'mountonly' workflow would, in essence, mimic a functionality provided inside the "MondoRescue" suite of tools by the mount-mescript (only better, of course ;-) ).

This proposal had already been discussed on the mailing list with @jsmeix back in March.

A working draft implementation of this feature is already available, that among others successfully mounts LUKS-encrypted filesystems as well as the most important virtual filesystems, allowing for immediate chroot into the target system if needed.

I'll now create a branch for it based on this issue, so that everyone can review it.

Please note: workflow name was initially proposed repair but later renamed to mountonly at @jsmeix suggestion.

gdha commented at 2019-10-05 09:48:

@petroniusniger Thank you - looking forward to the PR already ;-)

jsmeix commented at 2019-10-05 11:50:

What had been discussed on the rear-users mailing list back in March
was the ReaR rescue ISO as "live distribution"? mail thread on
http://lists.relax-and-recover.org/pipermail/rear-users/2019-March/thread.html

Therein see in particular my mail
http://lists.relax-and-recover.org/pipermail/rear-users/2019-March/003669.html
which mentiones the related GitHub issues
https://github.com/rear/rear/issues/987
and
https://github.com/rear/rear/pull/1091#issuecomment-263819775

@petroniusniger
I look forward to your contribution to ReaR!

Perhaps - if time permits - I can reuse parts of your code
to get the tree of filesystems mounted at /mnt/local
as the main missing piece to implement a backup restore workflow
that can work on its own:
https://github.com/rear/rear/issues/987

jsmeix commented at 2019-11-26 08:23:

With https://github.com/rear/rear/pull/2269 merged
this issue is done.

[Export of Github issue for rear/rear.]