#1736 Issue closed: rear format fails with formatted USB stick

Labels: enhancement, support / question

ritzmann opened issue at 2018-02-24 14:59:

  • rear version (/usr/sbin/rear -V): Relax-and-Recover 2.3 / 2017-12-20
  • OS version (cat /etc/rear/os.conf or lsb_release -a): Debian GNU/Linux 8.10 (jessie)
  • rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):
    OUTPUT=USB
    USB_DEVICE=/dev/disk/by-label/REAR-000
    USB_DEVICE_FILESYSTEM=ext4
    BACKUP=REQUESTRESTORE
    TIMESYNC=NTP
  • Are you using legacy BIOS or UEFI boot? BIOS
  • Brief description of the issue:
    With an already formatted USB stick, rear format /dev/sdl fails like this:

2018-02-24 16:46:30.106490992 ======================
2018-02-24 16:46:30.108520401 Running 'format' stage
2018-02-24 16:46:30.110376147 ======================
2018-02-24 16:46:30.124062858 Including format/USB/default/200_check_usb_layout.sh
2018-02-24 16:46:30.150109436 USB device /dev/sdl is not formatted with ext2/3/4 or btrfs filesystem
2018-02-24 16:46:30.155210978 UserInput: called in /usr/share/rear/format/USB/default/200_check_usb_layout.sh line 64
2018-02-24 16:46:30.163355586 UserInput: No choices specified
2018-02-24 16:46:30.167571286 Type exactly 'Yes' to format /dev/sdl with ext4 filesystem
2018-02-24 16:46:30.171449915 (default 'No' timeout 300 seconds)
2018-02-24 16:46:32.803458855 UserInput: 'read' got as user input 'Yes'
2018-02-24 16:46:32.819413495 Including format/USB/default/300_format_usb_disk.sh
2018-02-24 16:46:32.824138332 Repartitioning '/dev/sdl'
2018-02-24 16:46:32.828554706 Creating partition table of type 'msdos' on '/dev/sdl'
2018-02-24 16:46:33.063681623 Creating ReaR data partition up to 100% of '/dev/sdl'
2018-02-24 16:46:33.216028290 Setting 'boot' flag on /dev/sdl
2018-02-24 16:46:38.722554704 Creating ext4 filesystem with label 'REAR-000' on '/dev/sdl1'
mke2fs 1.42.12 (29-Aug-2014)
Found a dos partition table in /dev/sdl1
Proceed anyway? (y,n)
2018-02-24 16:46:39.523899752 ERROR: Failed to create ext4 filesystem on '/dev/sdl1'
==== Stack trace ====
Trace 0: /usr/sbin/rear:543 main
Trace 1: /usr/share/rear/lib/format-workflow.sh:92 WORKFLOW_format
Trace 2: /usr/share/rear/lib/framework-functions.sh:101 SourceStage
Trace 3: /usr/share/rear/lib/framework-functions.sh:49 Source
Trace 4: /usr/share/rear/format/USB/default/300_format_usb_disk.sh:110 source
Message: Failed to create ext4 filesystem on '/dev/sdl1'
== End stack trace ==
2018-02-24 16:46:39.536313469 Running exit tasks.
2018-02-24 16:46:39.540968817 Finished in 10 seconds
2018-02-24 16:46:39.543865348 Removing build area /tmp/rear.PzcEZNRW5Bveddm
2018-02-24 16:46:39.556436834 End of program reached

  • Work-around, if any:
    The only option I am aware of is to run mkfs.ext4 with flag -F.

gdha commented at 2018-03-02 12:22:

@ritzmann Strange - you are first having this issue (at least some-one who has reported it).
Ok - -F flag could be added from my point of view - @jsmeix any objections against it?

However, it struck my that you want to boot off from an USB disk, but skip any backup (BACKUP=REQUESTRESTORE) - are you just testing it perhaps?

ritzmann commented at 2018-03-02 12:54:

I actually want to (manually) restore a BackupPC backup.

My first choice was OUTPUT=ISO instead of USB and then write the ISO image to a USB stick when I actually need it. But I have so far not managed to create a bootable USB stick based on the ISO. I would have one or two more questions still, what would be the best channel to discuss them?

jsmeix commented at 2018-03-05 11:19:

The problem is to keep backward compatibility in the current code
in format/USB/default/300_format_usb_disk.sh

LogPrint "Creating $USB_DEVICE_FILESYSTEM filesystem with label '$USB_DEVICE_FILESYSTEM_LABEL' on '$rear_data_partition_device'"
if ! mkfs.$USB_DEVICE_FILESYSTEM -L "$USB_DEVICE_FILESYSTEM_LABEL" $USB_DEVICE_FILESYSTEM_PARAMS $rear_data_partition_device >&2 ; then
    Error "Failed to create $USB_DEVICE_FILESYSTEM filesystem on '$rear_data_partition_device'"
fi

because any options must work for all mkfs.$USB_DEVICE_FILESYSTEM commands
i.e. for all allowed values of USB_DEVICE_FILESYSTEM which are according to default.conf

# Only ext3 and ext4 are supported by the format workflow.
...
USB_DEVICE_FILESYSTEM=ext3

but in contrast the comments in the code also tell about ext2 and btrfs,
e.g. see format/USB/default/350_label_usb_disk.sh
and format/USB/default/200_check_usb_layout.sh

An additional -F option would only work for mkfs.ext2 mkfs.ext3
and mkfs.ext4 (according to the man pages down to SLES10)
but -F is not supported for mkfs.btrfs because there the force option is -f.

jsmeix commented at 2018-03-05 11:53:

@ritzmann
regarding separated issues like
"How to create a bootable USB stick with ReaR?"
you may create separated issues here.

I did that some time ago via "rear format" plus "rear mkrescue"
and for me on my laptop things "just worked" so that
if "rear format" plus "rear mkrescue" does not create a
bootable USB stick plus the ReaR recovery system on it
in your case it probably depends on your particular hardware
so that you would have to provide us information on what hardware
a USB stick made with "rear format" plus "rear mkrescue"
does not boot the ReaR recovery system.

Because ReaR is all plain bash scripts you can adapt them
as you need it, for example you can add the -F option to your
usr/share/rear/format/USB/default/300_format_usb_disk.sh
script to the mkfs.$USB_DEVICE_FILESYSTEM command like

LogPrint "Creating $USB_DEVICE_FILESYSTEM filesystem with label '$USB_DEVICE_FILESYSTEM_LABEL' on '$rear_data_partition_device'"
if ! mkfs.$USB_DEVICE_FILESYSTEM -F -L "$USB_DEVICE_FILESYSTEM_LABEL" $USB_DEVICE_FILESYSTEM_PARAMS $rear_data_partition_device >&2 ; then
    Error "Failed to create $USB_DEVICE_FILESYSTEM filesystem on '$rear_data_partition_device'"
fi

to make things work for your particular case (regardless whether or not
your particular way is also backward compatible in all other cases).

ritzmann commented at 2018-03-06 12:45:

OK. I was thinking that I could use USB_DEVICE_FILESYSTEM_PARAMS to pass "-F" to mkfs.ext4.

FWIW, I am not clear how I managed to evoke this issue. I tried to reproduce it multiple times without success.

jsmeix commented at 2018-03-06 13:08:

Now that you mention it I also think you could use
USB_DEVICE_FILESYSTEM_PARAMS to pass "-F" to mkfs.ext4

I promise next time I may even read our documentation in default.conf ;-)

gdha commented at 2018-04-11 06:24:

@ritzmann @jsmeix Is the issue resolved with this variable USB_DEVICE_FILESYSTEM_PARAMS from your side?

@ritzmann I noticed you use BackupPC software - why don't you try to integrate it with ReaR?

jsmeix commented at 2018-04-11 10:20:

@gdha
I think because "rear format" explicitly asks the user for confirmation
we should in ReaR use hardcoded enforced formatting calls
i.e. -F for mkfs.ext2/3/4 (and if needed -f for mkfs.btrfs).

ritzmann commented at 2018-04-12 20:46:

Is the issue resolved with this variable USB_DEVICE_FILESYSTEM_PARAMS from your side?

Yes.

I noticed you use BackupPC software - why don't you try to integrate it with ReaR?

I actually tried a "poor man's" integration by building a rescue image that would contain the required pieces of software to run BackupPC (Perl, rsync and sudo). I am backing up the backup server with ReaR, so it needs a few more pieces to run BackupPC than if it were just a client. I reached the limits of my skill set however when sudo and su, while running from the rescue image, complained about PAM not being present.

I figured that I would get faster results by backing up the relevant parts of the system with NETFS and then, after restoring the system, restore the rest of the files from the restored system with BackupPC. I hope that description wasn't too confusing. :-)

gdha commented at 2018-04-13 07:22:

@ritzmann Thank you for your input around BackupPC. I just wonder if you need sudo anyhow in the ReaR rescue image as you run directly as root? Or, do you run if with a different account?

jsmeix commented at 2018-04-13 09:44:

I think in general it is better to keep separated things separated.
In this case I mean to keep the recovery of the basic system
separated from the recovery of "higher level" parts of the system.

I think in general it is better to use ReaR only to recover the basic system
(with a relatively small backup that contains only the files of the basic system)
to get the basic system up and running as fast as possible,
and then in the recreated running basic system do the recovery of the various
"higher level" parts of the system in separated additional steps where that
additional separated steps could be even run in parallel (provided the various
"higher level" parts of the system are sufficiently independent of each other).

Regarding doing the recovery of the various "higher level" parts of the system
in separated additional steps that run in parallel cf.
https://github.com/rear/rear/blob/master/doc/user-guide/11-multiple-backups.adoc
which describes how to do that with ReaR but the idea behind also applies
when the recovery of the various "higher level" parts of the system is done
by various other tools as needed for each particular "higher level" part.

In general regarding huge "all-in-one" backups see also
https://github.com/rear/rear/issues/1006#issuecomment-248862040

ritzmann commented at 2018-04-13 11:28:

Thanks all for your valuable advise. Sounds like I am on the right path.

Just to answer @gdha's last question:
In general, BackupPC expects to run with a dedicated backup user. When rsyncing files it will switch to root on the backed up system. I guess it would be possible to run it all as root but that setup is a bit delicate.

jsmeix commented at 2018-07-20 06:18:

@gdha
see my question in
https://github.com/rear/rear/issues/1736#issuecomment-380402840

If you agree that we should in the rear format workflow
use hardcoded enforced formatting calls
I would implement it.

[Export of Github issue for rear/rear.]