#2588 Issue closed: Replace possibly misleading "USB device" wording by generic "USB or disk device"

Labels: enhancement, cleanup, fixed / solved / done, minor bug

jsmeix opened issue at 2021-03-24 07:46:

The OUTPUT=USB method originated from using a USB stick
but actually it implements using any disk device
(also an additional built-in disk like nowadays a SSD).

In particular things like

# rear format /dev/sda
USB device /dev/sda is not formatted with ext2/3/4 or btrfs filesystem
Type exactly 'Yes' to format /dev/sda with ext3 filesystem
...

where /dev/sda is not a USB disk but the system disk are plain wrong
when ReaR shows it as if /dev/sda was a USB device, cf.
https://github.com/rear/rear/issues/2587#issuecomment-805199097

So I would like to replace wording like "USB device" or "USB disk" or similar
by generic wording.

jsmeix commented at 2021-03-24 07:46:

@rear/contributors
do you agree that I replace wording like "USB device" or "USB disk" or similar
by generic wording?

gdha commented at 2021-03-24 08:48:

@jsmeix I agree with you to make the wording more generic.

pcahyna commented at 2021-03-24 09:40:

I like it, especially because I am currently working on OUTPUT=USB support on S/390, where the disks certainly are not USB :-)

jsmeix commented at 2021-03-24 09:52:

@pcahyna
I had already so much "fun" with the various special ways of the USB method
that my wishful thinking is to implement a new separated clean and simple DISK method
which behaves fully compatible (as far as possible) with other methods in ReaR
cf. USB_SUFFIX in default.conf (see the GitHub issues therein).

So if the USB method leads to too many special case difficulties on IBM Z / s390
and you wish to "implement things right from scratch" I would help you as good as I can
(obviously we at SUSE also would like to have proper IBM Z / s390 support in ReaR).

Currently OUTPUT=RAWDISK and OUTPUT=USB compete somewhat in ReaR.
As far as I noticed OUTPUT=RAWDISK works better to boot on UEFI
while OUTPUT=USB supports to include the backup in the medium.
So adding one more competitor OUTPUT=DISK could be just wrong.
Perhaps improving OUTPUT=RAWDISK is better?

pcahyna commented at 2021-03-24 10:08:

@pcahyna
I had already so much "fun" with the various special ways of the USB method
that my wishful thinking is to implement a new separated clean and simple DISK method
which behaves fully compatible (as far as possible) with other methods in ReaR
cf. USB_SUFFIX in default.conf (see the GitHub issues therein).

So if the USB method leads to too many special case difficulties on IBM Z / s390
and you wish to "implement things right from scratch" I would help you as good as I can
(obviously we at SUSE also would like to have proper IBM Z / s390 support in ReaR).

So far it has seemed to me that extending USB support to S/390 will not be too difficult, but perhaps I have been optimistic only because I have not investigated deep enough. (I admit I was not aware of USB_SUFFIX, but this special handling does not seem to have any direct impact on architecture-dependent boot support. Do you know any other quirks to be aware of?)

Currently OUTPUT=RAWDISK and OUTPUT=USB compete somewhat in ReaR.
As far as I noticed OUTPUT=RAWDISK works better to boot on UEFI
while OUTPUT=USB supports to include the backup in the medium.
So adding one more competitor OUTPUT=DISK could be just wrong.
Perhaps improving OUTPUT=RAWDISK is better?

I like the ability of including the backup in the medium. OUTPUT=RAWDISK is attractive because it creates an image similar to an ISO image, but precisely for that reason I am afraid it will not support other desirable features of OUTPUT=USB, like multiple backups.

jsmeix commented at 2021-03-24 10:43:

@pcahyna
USB_SUFFIX belongs only to the backup so it has no impact on architecture-dependent boot support.
Currently - off the top of my head - I don't remember other quirks to be aware of
but various USB special stuff had hit me too often so I fear other things are
lurking around - I will tell you when something re-appears in my mind - shudder ;-)

Regarding including the backup in the medium:

We support to include the backup in the ISO via BACKUP_URL=iso:///backup
which is yet another area of special quirks, see ISO_MAX_SIZE
and ISO_FILE_SIZE_LIMIT.

Because OUTPUT=RAWDISK uses the entire disk device to be overwritten
(not only a partition) it is not possible to have multiple backups on the disk
that is used for OUTPUT=RAWDISK.

jsmeix commented at 2021-03-24 10:52:

For another USB special stuff see
usr/share/rear/prep/USB/Linux-ppc64/350_safeguard_error_out.sh
https://github.com/rear/rear/issues/2348

For BACKUP_URL=iso:///... special stuff see
https://github.com/rear/rear/issues/1613
and follow the links to the other issues therein

pcahyna commented at 2021-03-24 11:01:

For another USB special stuff see
usr/share/rear/prep/USB/Linux-ppc64/350_safeguard_error_out.sh
#2348

Thanks for the reply, I have hit that, for now rm -f /usr/share/rear/prep/USB/Linux-s390/350_safeguard_error_out.sh solves it :-) (I will update that file eventually when everything else is working.)

Because OUTPUT=RAWDISK uses the entire disk device to be overwritten
(not only a partition) it is not possible to have multiple backups on the disk
that is used for OUTPUT=RAWDISK.

Yes. That's why I don't think any extended form of OUTPUT=RAWDISK will be a sufficient 100% replacement for OUTPUT=USB.

pcahyna commented at 2021-03-24 11:05:

Because OUTPUT=RAWDISK uses the entire disk device to be overwritten
(not only a partition) it is not possible to have multiple backups on the disk
that is used for OUTPUT=RAWDISK.

Yes. That's why I don't think any extended form of OUTPUT=RAWDISK will be a sufficient 100% replacement for OUTPUT=USB.

That said (thinking aloud), why couldn't OUTPUT=RAWDISK create only a partition image instead of the entire disk image? And another partition could be used to store the actual backups.

jsmeix commented at 2021-03-24 11:11:

I was also wondering if using only a partition instead of the whole disk is possible
but I am not at all a sufficient booting expert to understand the details behind
whether or not that is actually possible with a
"make an image and then 'dd' that onto a disk"
method.

In contrast with OUTPUT=USB ReaR uses only partitions
(one can leave free space after the ReaR data partition for other partitions)
and ReaR installs the bootloader "as usual" on the (USB) disk.

jsmeix commented at 2021-03-24 13:29:

With https://github.com/rear/rear/pull/2589 merged
the initially described issue here is fixed so I close it.

@pcahyna
nevertheless feel free to add further comments here.


[Export of Github issue for rear/rear.]