ESP flagging, name partitions in 300_format_usb_disk.sh

[ProBackup-nl]

(1) Change EFI partition from primary to ESP,
(2) name partitions,
(3) Set boot_flag to "esp" for EFI systemd-boot
(4) Make log message more explicit

[gdha]

@ProBackup-nl Need to verify this before I can approve it

[ProBackup-nl]

I find it quite handy when parted /dev/sdb print also prints a name describing the purpose of the partition, like:

Number  Start   End     Size    File system  Name      Flags
 1      4194kB  214MB   210MB   fat16        EFIBOOT   boot, esp
 2      214MB   15.6GB  15.4GB  ext4         REARDATA

[jsmeix]

Regarding "modern" flags like 'esp' or 'legacy_boot':

Older 'parted' on older Linux distributions do not support them, cf.
#1308 (comment)

The current code errors out when parted fails to set a flag.
I don't know how the various parted versions behave when
they should set a flag that is not supported.
I guess parted returns then a non-zero exit code so that
"rear format" errors out.

Accordingly I think there could be code that retries
those parted calls with a traditional flag as fallback
something (untested proposal) like

 if ! parted -s $RAW_USB_DEVICE set 1 $boot_flag on >&2 ; then
    # try a traditional flag as fallback
    if ! parted -s $RAW_USB_DEVICE set 1 boot on >&2 ; then
        Error "Could not make first partition bootable on '$RAW_USB_DEVICE'"
    fi
fi

[jsmeix]

I guess it is currently not sufficiently
fail-safe when an older parted is used
that does not support those settings.

[gdha]

Older versions require a primary partition; I'm afraid ESP is a rather new addition.

[ProBackup-nl]

@gdha ESP is in parted since release 3.2 (2014-07-28).

[gdha]

@ProBackup-nl this directory /boot/EFI/systemd/ is not a standard yet (this path for most common Linux versions)

[gdha]

@ProBackup-nl RHEL 6.3 still has parted 2.1, and lots of RHEL 7.2 still have version 3.1. I don't mind to have it on-board, but then at least it may not break parted < version 3.2.
Will you re-work the pull request, or would like to drop it?

[ProBackup-nl]

@gdha Please drop this request. After I have seen how easily new non-optional dependencies (like bc) are introduced in this project, I have lost my appetite.

[schlomo]

@ProBackup-nl I am sorry for your frustration. I think that this topic is something that should be part of a future ReaR major release that does away with all the pre-systemd compatibility requirements.

[ProBackup-nl]

@schlomo I think that it is not wise to introduce a new (hard/non-optional) dependency for a calculation problem that exists in one old version of a distribution.
In my opinion the code should check whether a (calculation) issue exists, and only in that case the code should require (bc) dependency to handle the exception (incorrect large integer calculations by bash).

[schlomo]

@ProBackup-nl good point and I agree. I actually take it to support my thesis that we should cut our obligations to the past and start working on a new ReaR version that is geared towards recent systems (recent probably being somewhat relative). I have a strong feeling that this will simplify a lot of things within ReaR.

[ProBackup-nl]

@schlomo By the way, I am not frustrated, more disappointed. Please do post me a note as soon as the bc dependency is optional. I can even see a need to support relatively older systems.

[schlomo]

I'll try to remember. BTW, I recently read the Archlinux FAQ and liked this part:

Several distributions, such as Debian, have different versions of shared libraries packaged as different packages: libfoo1, libfoo2, libfoo3 and so on. In this way it is possible to have applications compiled against different versions of libfoo installed on the same system.

In case of a distribution like Arch, only the latest stable versions of packages are officially supported. By dropping support for outdated software, package maintainers are able to spend more time ensuring that the newest versions work as expected. As soon as a new version of a shared library becomes available from upstream, it is added to the repositories and affected packages are rebuilt to use the new version.

It kind of makes me wish we could split ReaR into two parts: One that supports only recent distros and another one for the old stuff. I know that many if not most of our users rely on ReaR supporting their old stuff, this is just me as a developer speaking.

[ProBackup-nl]

@schlomo The newest versions of packages is one of the main reasons to use Arch Linux in the first place. Once too many I stumbled upon ancient packages in the major distributions, where I needed a newer version to get things done. And there wasn't a quick solution to install that newer package version.