#1292 PR `closed`: ESP flagging, name partitions in 300_format_usb_disk.sh¶

Labels: enhancement, won't fix / can't fix / obsolete

ProBackup-nl opened issue at 2017-04-13 19:12:¶

(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

ProBackup-nl commented at 2017-04-14 22:37:¶

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 commented at 2017-04-19 12:29:¶

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

Older 'parted' on older Linux distributions do not support them, cf.
https://github.com/rear/rear/pull/1308#issuecomment-295246028

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

ProBackup-nl commented at 2017-05-11 07:28:¶

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

gdha commented at 2017-05-20 15:24:¶

@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 commented at 2017-06-13 13:06:¶

@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 commented at 2017-06-13 13:11:¶

@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 commented at 2017-06-14 15:03:¶

@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 commented at 2017-06-14 15:14:¶

@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 commented at 2017-06-15 08:13:¶

@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 commented at 2017-06-15 08:32:¶

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 commented at 2017-06-15 09:09:¶

@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.

[Export of Github issue for rear/rear.]

#1292 PR closed: ESP flagging, name partitions in 300_format_usb_disk.sh¶