#2278 PR `merged`: Feature rawdisk and opalpba improvements¶

Labels: enhancement, bug, fixed / solved / done

OliverO2 opened issue at 2019-11-17 19:29:¶

Pull Request Details:¶

Type: Bug Fix + Enhancement
Impact: Normal
Supersedes PR: #2277
Resolves issue (URL): #2275
How was this pull request tested? Creating and booting PBAs on Ubuntu 18.04.3 LTS.
Brief description of the changes in this pull request:
1. RAWDISK: include additional Grub modules from /boot/grub (and /boot/grub2) which had formerly been missing
2. OPALPBA: improve Plymouth boot animation on Ubuntu, provide integration capabilities for other distros
3. RAWDISK: add support for distros which use 'grub2' naming (fix #2275)

OliverO2 commented at 2019-11-17 19:33:¶

@franciscohosting Here is the promised patch. I'd be happy if you could test this on CentOS 7 and report your experiences here.

OliverO2 commented at 2019-11-17 21:56:¶

@jsmeix

https://github.com/rear/rear/pull/2277#issuecomment-554368834

So I look forward to your improvements regarding secure boot.
Hopefully we could use same code for same functionality in ReaR.

I am a bit afraid that you might be disappointed: The code I have just committed does not change the secure boot functionality at all in RAWDISK output but is a leftover from trying to make Grub 2 (UEFI) play nicely with a graphical boot animation afterwards, which I wanted for the TCG Opal 2 PBA (disk unlocking system). I had used syslinux before as it boots faster, but on a system configured for secure boot Grub 2 is a must.

I tried hard to get all that boot-time video support, mode switching and whatever as close to the original system as possible. As Grub 2 is scarcely documented there was much guesswork involved. I had two machines to test on with different graphics hardware (bare metal required) and both behaved differently. One insisted on booting into a black screen. There was an invisible password prompt waiting until Return was pressed once. Only then the display appeared.

After all it turned out that an incomplete Grub 2 configuration was not that much the culprit: It was a missing shared library: Plymouth could not dynamically load /usr/lib/x86_64-linux-gnu/plymouth/script.so as this referenced /lib/x86_64-linux-gnu/libply-splash-graphics.so.4 which was missing on the PBA system. The first library was included as part of a directory via COPY_AS_IS, but that did not automatically pull in libraries referenced by it. build/GNU/Linux/100_copy_as_is.sh handles executable dependencies but overlooks those of *.so files. Once I got that right, Grub 2 booted nicely into a graphical screen.

With respect to the remaining UEFI code in ReaR, it seems that there is some confusion about which code is responsible for which part. An example:
https://github.com/rear/rear/blob/2f66b904fdc1f69d31f1c9fa64e13a0964c21a38/usr/share/rear/finalize/Linux-i386/660_install_grub2.sh#L46

However, efibootmgr is not a boot loader, so it cannot replace Grub 2. It is just a tool to change UEFI variables which are stored in non-volatile memory on your motherboard. For example, efibootmgr can select the boot disk devices and the order of boot device preference. So instead of selecting boot devices in the BIOS setup you could use efibootmgr to the same effect.

If I understand ReaR code correctly (and I have only had a glimpse), 660_install_grub2.sh is only used to install a legacy (BIOS) bootloader. That's why it contains

is_true $USING_UEFI_BOOTLOADER && return

Installing an UEFI bootloader seems to be done in output/ISO/Linux-i386/820_create_iso_image.sh and usr/share/rear/finalize/SUSE_LINUX/i386/675_install_shim.sh by mechanisms I don't know about. shim-install seems SUSE-specific, it actually does install Grub 2 and may be worth a look as it is all-bash: https://build.opensuse.org/package/view_file/devel:openSUSE:Factory/shim/shim-install?expand=1

On shim: Linux distributions use shimx64.efi as their first stage boot loader, which is signed by Microsoft and thus works with secure boot at factory defaults. (Shim is used, as for legal reasons Grub cannot be signed directly.)

If you'd like more details, see Take Control of Your PC with UEFI Secure Boot | Linux Journal.

Hope this helps...

jsmeix commented at 2019-11-18 09:58:¶

@rear/contributors
I would appreciate a second review from another ReaR maintainer
to be more on the safe side against possible regressions.

jsmeix commented at 2019-11-18 10:10:¶

@OliverO2
thank you for your explanation in your
https://github.com/rear/rear/pull/2278#issuecomment-554791749

Yes, it helps because you also think that the current way
how ReaR re-installs UEFI booting during "rear recover"
at least looks a bit fishy and needs a closer look and
may perhaps need some cleanup and enhancement.

But for now how ReaR re-installs UEFI booting
seems to "work sufficiently in most cases" and
I think @gozora explained why in his
https://github.com/rear/rear/issues/2275#issuecomment-554028783

So no need to rush - better carefully and step by step,
cf. RFC 1925 items (2) and (2a)
https://tools.ietf.org/html/rfc1925

jsmeix commented at 2019-11-18 14:47:¶

Via
https://github.com/rear/rear/commit/28ba2bb8367a7750ef940c07f19e7f537bbf6213
I added a more explanatory comment in default.conf how COPY_AS_IS
versus LIBS, PROGS, and REQUIRED_PROGS are meant to be used.

jsmeix commented at 2019-11-22 13:17:¶

I would like to wait until next monday
for a second review from another ReaR maintainer.

When there is no objection I would merge it next monday afternoon.

jsmeix commented at 2019-11-26 07:59:¶

@OliverO2
thank you for your continuous fixes and improvements for ReaR.
In particular I appreciate it that you cuntinuously maintain
those features that you had initially contributed to ReaR
i.e. you care about "your code".

[Export of Github issue for rear/rear.]

#2278 PR merged: Feature rawdisk and opalpba improvements¶