Skip to content
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

How to mount USB device during recover (but not during mkbackup)? #3140

Closed
robertdahlem opened this issue Jan 26, 2024 · 4 comments
Closed

Comments

@robertdahlem
Copy link
Contributor

  • ReaR version ("/usr/sbin/rear -V"): Relax-and-Recover 2.6 / Git

  • If your ReaR version is not the current version, explain why you can't upgrade: First trying to run Ubuntu out of the box. Will happily try 2.7 or master when asked to.

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

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

OUTPUT=USB
USB_DEVICE=/dev/disk/by-label/REAR-000
BACKUP=NETFS
BACKUP_URL=file:///media/myuser/EXT-PLATTE-1TB/rear
AUTOEXCLUDE_AUTOFS=y
  • Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR): KVM guest

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

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

  • Description of the issue (ideally so that others can reproduce it):

Ubuntu out of the box automounts any USB storage that gets attached under /media/myuser/$LABEL_OF_DEVICE_OR_PARTITION.

I can prevent that with LABEL=REAR-000 none none noauto 0 0 in /etc/fstab for the USB stick to create the ISO. But I do not wish to prevent this for the backup device because it holds other stuff too that shall stay visible to the (non-enlightened) user.

ReaR shall just use /media/myuser/EXT-PLATTE-1TB/rear during mkbackup but needs to mount /dev/disk/by-label/EXT-PLATTE-1TB to /media/myuser/EXT-PLATTE-1TB of whatever suitable path during recover.

Using BACKUP_MOUNTCMD fails at start of mkbackup with "already mounted".
Using BACKUP_URL=usb:///dev/disk/by-label/EXT-PLATTE-1TB also fails with "already mounted".

So my question is: how do I get ReaR to accept a mounted path as BACKUP_URL during mkbackup but to mount it by itself during mkrescue?

@jsmeix
Copy link
Member

jsmeix commented Feb 9, 2024

Offhandedly (i.e. without any testing)
I would try to use bash scripting in etc/rear/local.conf
to make things behave different when you run ReaR
on the original system versus on the replacement system, cf.
https://github.com/rear/rear/blob/rear-2.7/etc/rear/local.conf

In the recovery system /etc/rear-release is unique
(it does not exist otherwise) and usr/sbin/rear does

test -e "/etc/rear-release" && RECOVERY_MODE="y"

so you can test for RECOVERY_MODE preferably via

is_true "$RECOVERY_MODE"

to find out whether or not you are in the recovery system.

What I do not know is how to make ReaR accept
an already mounted path as BACKUP_URL
without trying to mount it.
I fear you have to modify certain scripts.

@robertdahlem
Copy link
Contributor Author

@jsmeix I ended up with writing a wrapper script around "rear mkbackup" which does several checks (USB stuff actually attached) and does the necessary umount.

@jsmeix
Copy link
Member

jsmeix commented Feb 12, 2024

@robertdahlem
thank you for your feedback how you solved it in your case
so others can see what a possible solution could be.

@robertdahlem
Copy link
Contributor Author

@jsmeix I added my wrappper script so it can be used as an example by others. Unfortunately, GitHub only accepts several extension, so one has to remove the ".txt" suffixes.
rear_wrapper.sh.txt
site.conf.txt

jsmeix referenced this issue Feb 26, 2024
This code probably has not worked since commit 0022063 (PR #2633),
because rescue.conf is sourced only when the build area has been
already created by invoking mktemp. It is also unneeded, because since
that commit, setting TMPDIR in local.conf (which was the initial concern
that motivated this code) does not work anyway, as discussed in #2654.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants