You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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: #987
Initial draft implementation of the new 'mountonly' workflow
to use ReaR as rescue system, therein mount the filesystems
of the target system so that one can manually repair it
(see #2247).
This is described in doc/user-guide/04-scenarios.adoc
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
chroot
ing into the now mounted system.This 'mountonly' workflow would, in essence, mimic a functionality provided inside the "MondoRescue" suite of tools by the
mount-me
script (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 tomountonly
at @jsmeix suggestion.The text was updated successfully, but these errors were encountered: