usr/share/rear/prep/USB/Linux-i386/350_check_usb_disk.sh - if we pass…

[sidrew]

… in the actual raw block device, we fail to confirm it via udev since TEMP_USB_DEVICE never gets set via the first two conditions... so, let's check to see if we've set RAW_USB_DEVICE also.

Relax-and-Recover (ReaR) Pull Request Template

Please fill in the following items before submitting a new pull request:

Pull Request Details:

• Type: Bug Fix

• Impact: Normal

• Reference to related issue (URL): OUTPUT=USB neither works with BACKUP_URL=nfs://... nor with whole disk USB_DEVICE=/dev/sdc #2171

• How was this pull request tested? Tested in situ on affected server using real usb device.

• Brief description of the changes in this pull request:
  Allows us to assert the original raw block device inferred from udev info.

[jsmeix]

I didn't test it myself but the explanation in
#2171 (comment)
makes sense to me and in general code of the form

if variable is empty then assign variable

should be o.k.

[jsmeix]

@gdha
I assign it to you because that code part originates from you according to

git log -p --follow usr/share/rear/prep/USB/Linux-i386/350_check_usb_disk.sh

[jsmeix]

@sidrew
could you please add an explanatory comment to the code
so that it is easier for others to understand at any time later
how things work, cf. "Code should be easy to understand"
https://github.com/rear/rear/wiki/Coding-Style

[sidrew]

@sidrew
could you please add an explanatory comment to the code
so that it is easier for others to understand at any time later
how things work, cf. "Code should be easy to understand"
https://github.com/rear/rear/wiki/Coding-Style

Sure thing... what's the etiquette here for adding another change? Second pull request? Modify original pull request? My github-fu is lacking...

Oh, nevermind... duh. Looks like it pulled in my follow-up commit automagically. Neato.

[sidrew]

So, I think looking at this more, that passing in a raw block device, such as /dev/sdc isn't ever going to work, since the usb code path doesn't assert that any partition be created and used, such as /dev/sdc1 ... I was assuming that if you gave a raw block device, it would assume that. So, this change, as the tool is presently designed... is mostly pointless.

[jsmeix]

@sidrew
you must run once something like

rear -v format /dev/sdc

or e.g. with a format workflow specific option like

rear -v format -- --efi /dev/sdc

to prepare your USB device for use with ReaR.

Note the mandatory '--' before the format workflow specific
options ('-v' is the generic rear option).
Without that the format workflow specific options won't work
(for background information about that see the getopt documentation).
Valid format workflow options are: -e/--efi -f/--force -y/--yes
(for details inspect the code in usr/share/rear/lib/format-workflow.sh
and mainly in usr/share/rear/format/USB/default/300_format_usb_disk.sh).

"rear format" prepares a whole disk device like /dev/sdc
by creating partitions and creating filesystems on it, cf.
the various USB_DEVICE_* config variables in default.conf
and see "man rear" e.g. online at
https://github.com/rear/rear/blob/master/doc/rear.8.adoc
and the section "Configuring Relax-and-Recover for USB storage devices" in
https://github.com/rear/rear/blob/master/doc/user-guide/04-scenarios.adoc
and http://relax-and-recover.org/documentation/getting-started

[sidrew]

@sidrew
you must run once something like

rear -v format /dev/sdc

or e.g. with a format workflow specific option like

rear -v format -- --efi /dev/sdc

to prepare your USB device for use with ReaR.

Sure, that's not the issue. I had formatted the drive. The problem is that when the base block device is passed in via USB_DEVICE, e.g. /dev/sdr ... rear tries to use that to install the rescue image. It doesn't scan the device looking for any label... it doesn't assume /dev/sdr1 ...

This pull request was to address that if I passed the base block device, this helper script was unable to determine RAW_USB_DEVICE... since it's expecting to have a partition passed in USB_DEVICE. This patch addressed it being able to figure out RAW_USB_DEVICE... but, doesn't address the overall issue that really, the rest of the workflow needs to know about a partition in which to install rescue and backup data.