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
OUTPUT=USB: add a check that OUTPUT_URL is mounted #3102
Conversation
I made the same kind of non-fail-safe code in
because it reports a bug in ReaR when
fails for all arbitrary reasons, for example as in |
@pcahyna |
@pcahyna I think I would only implement one check that I think I would implement that directly in |
For OUTPUT=USB, having a block device is a pretty basic requirement. For this reason, I prefer to have the check for block device mandatory and let it error out when it fails.
Since this is a basic requirement of OUTPUT=USB, I prefer to have the check as early as possible. I could even rename |
This are all scripts in usr/share/rear/output/
I would recommend to leave at least one free number |
On what older Linux systems
works as expected: I test with
SLES10-SP4:
SLES11-SP3:
SLES12-SP5:
SLES15-SP3:
So it seems (at least for the above tested systems) Note the test on SLES15-SP3
Of course a mounted filesystem on USB device for ReaR |
This would be problematic - we would have to revisit this if we want to support formatting the USB as btrfs. |
On SLES15-SP3:
so
does what we need |
RHEL 6 supports it:
for some reason, it is useful even with NFS. |
On what older Linux systems SLES12-SP5:
SLES15-SP3
So it seems (at least for the above tested systems) |
I can add |
@pcahyna
prefix so that prefix could also get in the way? |
... which is what I want. I want the check to fail with NFS mounts. |
@pcahyna |
I was wondering whether or not bash 3 versus bash 4 So I tested SLES11-SP4 (above I had tested SLES11-SP3). SLES11-SP4:
SLES11 and older have bash 3. So if we would make bash 4 mandatory for next ReaR version 2.8 |
@jsmeix I will leave it out, but if you want to test with btrfs-formatted USB, and you find that the check is the only thing that prevents this case from working, I will add it. |
Now it may error out with only those texts:
or
But this could be too little context for the user Therefore I would like to suggest code like
If you like you may downgrade those LogPrintError to DebugPrint. By the way: |
@jsmeix done, thanks for the suggestion. While testing, I discovered a bigger issue: |
@pcahyna Better merge it sooner than later now FYI:
and |
In output/USB/Linux-i386/850_make_USB_bootable.sh replaced the BugError "Filesystem where the booting related files are on $RAW_USB_DEVICE could not be found" which is in most cases not a bug in ReaR but an error (e.g. a user configuration error for OUTPUT=UEB) with more explanatory LogPrintError plus Error what the actual reason is, similar as in the related #3102
thanks for the offer, cleanup of this area is certainly welcome. Not sure if it has the highest priority given we have not had many bug reports about that, though (and I don't have any immediate use for it ATM). Some remarks on what would IMO need to be cleaned up:
This should be unified and USB_DEVICE determined always from OUTPUT_URL since it represents the location of boot files, nto of the backup.
|
thank you @jsmeix for the review, I am going to merge it. |
093202a
to
0806963
Compare
If OUTPUT_URL uses the file:// scheme, ReaR aborts with a weird error message "BUG: Filesystem where the booting related files are on ... could not be found" in output/USB/Linux-i386/850_make_USB_bootable.sh. Check if OUTPUT_URL got actually mounted at the right place ($BUILD_DIR/outputfs) by output/default/100_mount_output_path.sh and abort earlier with a meaningful error message if not. Don't pretend that OUTPUT_URL=file: works with USB, document what would be needed to support this.
0806963
to
b56abb2
Compare
In output/USB/Linux-i386/850_make_USB_bootable.sh replaced the BugError "Filesystem ... on $RAW_USB_DEVICE could not be found" with explanatory LogPrintError plus Error what the actual reason is, similar as in the related #3102 because in most cases this is not a bug in ReaR but an error like a user configuration error for OUTPUT=USB e.g. see #1571 and #3098 Use first LogPrintError for an additional info message and then Error for the actual error message. In those LogPrintError plus Error message pairs show both $BUILD_DIR/outputfs and $RAW_USB_DEVICE because $BUILD_DIR/outputfs is a meaningless directory of the form /var/tmp/rear.XXXXXXXXXXXXXXX/outputfs so $RAW_USB_DEVICE provides some context to the user that those two messages are about his USB or disk device.
Pull Request Details:
Type: Enhancement
Impact: Low
Reference to related issue (URL): closes OUTPUT_URL=file://... conflicts with OUTPUT=USB but ReaR does not error out appropriately #3098
How was this pull request tested?
rear mkrescue
withfails with
rear mkrescue
withfails with
If OUTPUT_URL uses the
file://
scheme, ReaR aborts with a weird error message "BUG: Filesystem where the booting related files are on ... could not be found" inoutput/USB/Linux-i386/850_make_USB_bootable.sh
.Check if OUTPUT_URL got actually mounted at the right place ($BUILD_DIR/outputfs) by
output/default/100_mount_output_path.sh
and abort earlier with a meaningful error message if not.