#3194 Issue open: PBA environment is stuck in Linux kernel log messages

Labels: support / question, special hardware or VM

edmcman opened issue at 2024-04-04 19:44:

  • ReaR version ("/usr/sbin/rear -V"):

git eadcc683 (March 4th)

  • If your ReaR version is not the current version, explain why you can't upgrade:

I'm getting an error on rear mkopalpba with the latest version. I'll file an issue for that shortly.

  • OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.3 LTS
Release:    22.04
Codename:   jammy
  • ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
OUTPUT=RAWDISK
OUTPUT_URL="file:///var/lib/rear/output"
SECURE_BOOT_BOOTLOADER="/boot/efi/EFI/ubuntu/shimx64.efi"
  • Hardware vendor/product (PC or PowerNV BareMetal or ARM) or VM (KVM guest or PowerVM LPAR):

PC System 76

  • System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):

x86

  • Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):

Open Firmware

Unsure about bootloader, whatever PBA is using

  • Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):

local NVMe

  • Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,LABEL,SIZE,MOUNTPOINT"):
/dev/nvme1n1       /dev/nvme1n1                  nvme   disk                         1.9T 
`-/dev/nvme1n1p1   /dev/nvme1n1p1 /dev/nvme1n1   nvme   part  vfat        OPAL PBA    99M 
/dev/nvme0n1       /dev/nvme0n1                  nvme   disk                       465.8G 
|-/dev/nvme0n1p1   /dev/nvme0n1p1 /dev/nvme0n1   nvme   part  vfat        EFI        512M /boot/efi
|-/dev/nvme0n1p2   /dev/nvme0n1p2 /dev/nvme0n1   nvme   part  ext4                   1.7G /boot
`-/dev/nvme0n1p3   /dev/nvme0n1p3 /dev/nvme0n1   nvme   part  crypto_LUKS          463.6G 
  `-/dev/mapper/nvme0n1p3_crypt
                   /dev/dm-0      /dev/nvme0n1p3        crypt LVM2_member          463.6G 
    |-/dev/mapper/vgubuntu-root
    |              /dev/dm-1      /dev/dm-0             lvm   ext4                 461.7G /
    `-/dev/mapper/vgubuntu-swap_1
                   /dev/dm-2      /dev/dm-0             lvm   swap                   1.9G [SWAP]
  • Description of the issue (ideally so that others can reproduce it):

When I produce and install the PBA, it gets stuck while displaying some Linux kernel status messages.

image

  • Workaround, if any:

  • Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):

jsmeix commented at 2024-04-05 14:33:

@edmcman
I am not a "rear mkopalpba" user.
I don't have a TCG Opal 2-compliant self-encrypting disk.
So I cannot reproduce anything with such hardware.

From what your kernel messages show, inparticular

... firmware load for ... failed ...
... no suitable firmware found!

my blind guess is that the PBA image which is made
by "rear mkopalpba" does not contain the firmware
which the kernel (usualy via some udev mechanism)
tries to upload into the 'iwlwifi' hardware.

In particular network hardware (and certain GPUs)
is known to need firmware uploaded into it to make it work.
So without such firmware the 'iwlwifi' hardware
won't work which means networking won't work
when this is the only networking hardware.
What is unexpected in this case is that it seems
the startup of the whole kernel is stuck when it fails
to upload firmware into the 'iwlwifi' hardware
regardless that I would assume a system should work
even without networking hardware.

I don't know it is possible to inspect what there is
inside the PBA image?

On my openSUSE Leap 15.5 workstation
I have lots of /lib/firmware/iwlwifi-* files.

Do you have /lib/firmware/ files in your PBA image?

Perhaps "rear -D mkopalpba" tells something about
whether or not firmware is included in the PBA image?

jsmeix commented at 2024-04-05 14:39:

I found the following documentation in
usr/share/rear/conf/default.conf

# The following variable, if non-empty, overrides FIRMWARE_FILES for the PBA system.
OPAL_PBA_FIRMWARE_FILES=()
...
# The by default empty FIRMWARE_FILES array means that
# usually all files in the /lib*/firmware/ directories
# get included in the rescue/recovery system but on certain
# architectures like ppc64 or ppc64le the default could be different
# cf. the conf/Linux-ppc64.conf and conf/Linux-ppc64le.conf scripts:
FIRMWARE_FILES=()

so by default you should get all files
in the /lib*/firmware/ directories included in the PBA image
(as far as I understand what is told in default.conf)

jsmeix commented at 2024-04-05 14:50:

The only ReaR script that deals with OPAL_PBA_FIRMWARE_FILES is
usr/share/rear/prep/OPALPBA/Linux-i386/001_configure_workflow.sh
which does what default.conf tells about OPAL_PBA_FIRMWARE_FILES
so by default only FIRMWARE_FILES matters.

The only ReaR script that deals with FIRMWARE_FILES is
usr/share/rear/build/GNU/Linux/420_copy_firmware_files.sh
which should also be run for "rear mkopalpba" according to

# usr/sbin/rear -s mkopalpba | grep firmware
Source build/GNU/Linux/420_copy_firmware_files.sh

So I would suggest to run "rear -D mkopalpba"
and check the ReaR log file what happens after

+ source ...usr/share/rear/build/GNU/Linux/420_copy_firmware_files.sh

and - if possible - also check what firmware files
got actually included in the PBA image.

jsmeix commented at 2024-04-05 15:01:

Hmm...
perhaps the 'iwlwifi' firmware issue is not the reason
why the startup of the whole kernel is stuck because
before that there are kernel messages that look like
problems with the 'nvme' disk and such issues may let
the startup of the whole kernel stuck
and
before the 'nvme' messages there is another firmware issue
regarding 'regulatory.db' but that is also WIFI related
so probably not severe enough to let the kernel stuck?

edmcman commented at 2024-04-05 15:07:

perhaps the 'iwlwifi' firmware issue is not the reason
why the startup of the whole kernel is stuck because
before that there are kernel messages that look like
problems with the 'nvme' disk and such issues may let
the startup of the whole kernel stuck

I think this is just a warning. This message is present during normal Linux boots as well.

edmcman commented at 2024-04-05 15:09:

I will take a look at the firmware. I initially ignored that because I didn't think that missing firmware should cause the machine not to boot.

jsmeix commented at 2024-04-05 15:16:

Another blind guess:

Does the image with the kernel messages in your initial posting
show where the kernel is stuck?
Are there no further kernel (error or panic) messages?
I.e. all of a sudden there are no further kernel messages?

In this case the kernel may just proceed rather well
but you only don't get further messages on your console.

See the various 'CONSOLE' variables descriptions
in usr/share/rear/conf/default.conf for

OPAL_PBA_USE_SERIAL_CONSOLE
USE_SERIAL_CONSOLE
SERIAL_CONSOLE_DEVICES
SERIAL_CONSOLE_DEVICES_KERNEL
SERIAL_CONSOLE_DEVICE_SYSLINUX
SERIAL_CONSOLE_DEVICE_GRUB

what you may have to manually specify to ensure that
all kernel messages appear on your system console.

edmcman commented at 2024-04-05 15:27:

There are very few files in the PBA image itself. In the initrd.cgz image inside of the PBA, there are more, but I don't see any firmware files. I will continue to investigate why that happens. I do not have any firmware-related configuration options, so I would expect that the default would be to include all the firmware, even in the PBA image. I believe that the rescue image includes the firmware, but I will double check that.

Nothing appears on the screen beyond what is in the photo I posted. I waited for a while (about an hour) and there are no other messages.

I will investigate the console configs. Thanks for the idea.

jsmeix commented at 2024-04-05 15:35:

Normally (i.e. for "rear mkrescue") the initrd contains
all the ReaR recovery system files.
What is booted when one boots for example from an ISO image
that was made by "rear mkrescue" is the kernel of the
original system where "rear mkrescue" was run
(I mean the original system's kernel is copied to be
used as kernel for what is booted e.g. from an ISO image)
plus ReaR's special initrd that contains all the files
of the ReaR recovery system (which runs in a ramdisk).

I assume that with "rear mkopalpba" it is basically the same
i.e. that the initrd in the PBA image ontains all the files
of the system that is booted when one boot from a PBA image.

jsmeix commented at 2024-04-05 15:40:

Regarding no further messages on the console see
https://github.com/rear/rear/issues/2843
in particular see
https://github.com/rear/rear/issues/2843#issuecomment-1196588256
what usually helps when you do not have a serial console.

edmcman commented at 2024-04-05 17:08:

I can confirm that the mkrescue's initrd contains /lib/firmware, but mkopalpba's initrd does not.

edmcman commented at 2024-04-05 17:16:

From rear -D mkopalpba log file:

+ source /usr/share/rear/build/GNU/Linux/420_copy_firmware_files.sh
++ is_false no
++ case "$1" in
++ return 0
++ LogPrint 'Omit copying files in /lib*/firmware/ (FIRMWARE_FILES='\''no'\'')'
2024-04-05 13:14:48.813546125 Omit copying files in /lib*/firmware/ (FIRMWARE_FILES='no')
++ return
+ source_return_code=0
+ test 0 -eq 0
+ cd /home/ed
+ test 1
+ Debug 'Leaving debugscript mode (back to previous bash flags and options settings).'
2024-04-05 13:14:48.815543501 Leaving debugscript mode (back to previous bash flags and options settings).

edmcman commented at 2024-04-05 17:22:

It seems that the PBA intentionally does not include firmware by default to conform to the small 100 MiB size requirement: https://github.com/rear/rear/blob/master/usr/share/rear/prep/OPALPBA/Linux-i386/001_configure_workflow.sh#L16

edmcman commented at 2024-04-05 18:36:

Here's what I put in /etc/rear/local.conf:

OUTPUT=RAWDISK
OUTPUT_URL="file:///var/lib/rear/output"
SECURE_BOOT_BOOTLOADER="/boot/efi/EFI/ubuntu/shimx64.efi"
OPAL_PBA_FIRMWARE_FILES+=( '*/iwlwifi-so-a0-gf-a0-83.ucode*' )
USE_SERIAL_CONSOLE='no'

Here is what I get:
image

On a normal boot, here are the iwlwifi messages:

ed@banana:~$ sudo dmesg | fgrep iwlwifi
[   12.822755] iwlwifi 0000:00:14.3: Detected crf-id 0x400410, cnv-id 0x80401 wfpm id 0x80000020
[   12.822780] iwlwifi 0000:00:14.3: PCI dev 7a70/0094, rev=0x430, rfid=0x2010d000
[   12.825493] iwlwifi 0000:00:14.3: api flags index 2 larger than supported by driver
[   12.825508] iwlwifi 0000:00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.41
[   12.826166] iwlwifi 0000:00:14.3: loaded firmware version 83.e8f84e98.0 so-a0-gf-a0-83.ucode op_mode iwlmvm
[   12.963263] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6E AX211 160MHz, REV=0x430
[   12.971359] iwlwifi 0000:00:14.3: WRT: Invalid buffer destination
[   13.146853] iwlwifi 0000:00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x20
[   13.146862] iwlwifi 0000:00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
[   13.146870] iwlwifi 0000:00:14.3: WFPM_AUTH_KEY_0: 0x90
[   13.146879] iwlwifi 0000:00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x0
[   13.147210] iwlwifi 0000:00:14.3: loaded PNVM version e28bb9d7
[   13.147279] iwlwifi 0000:00:14.3: RFIm is deactivated, reason = 5
[   13.163651] iwlwifi 0000:00:14.3: Detected RF GF, rfid=0x2010d000
[   13.232694] iwlwifi 0000:00:14.3: base HW address: ac:19:8e:9d:c8:1c
[   13.279489] iwlwifi 0000:00:14.3 wlp0s20f3: renamed from wlan0
[   14.405180] iwlwifi 0000:00:14.3: WRT: Invalid buffer destination
[   14.564884] iwlwifi 0000:00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x20
[   14.564914] iwlwifi 0000:00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
[   14.564922] iwlwifi 0000:00:14.3: WFPM_AUTH_KEY_0: 0x90
[   14.564930] iwlwifi 0000:00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x0
[   14.566155] iwlwifi 0000:00:14.3: RFIm is deactivated, reason = 5
[   14.656388] iwlwifi 0000:00:14.3: Registered PHC clock: iwlwifi-PTP, with index: 0

So the [ 12.825493] iwlwifi 0000:00:14.3: api flags index 2 larger than supported by driver message is "normal".

I'll try to add /lib/firmware/regulatory.db* to the firmware files, but I don't really think that the wifi is the problem.

@jsmeix Setting USE_SERIAL_CONSOLE='no' should have provided more console output, right?

jsmeix commented at 2024-04-09 07:43:

Regarding
"PBA ... small 100 MiB size requirement":

To me a 100 MiB size maximum for a bootable image
looks rather arbitrary and needlessly small
with nowadays disk and memory sizes.

By googling for "PBA image size limit" I found
https://github.com/Drive-Trust-Alliance/sedutil/issues/293
that tells
(I copy whole text parts to have them here saved):

Technically on Opal TCG 2.0 compliant drives,
the PBA image can use the entire "Shadow MBR"
dedicated space which must be 128MB.

In reality it's not a question of how big
the PBA image can be but how big it should be.
It should be (for most folks) a minimum size
that boots the system enough to authenticate
a credential set and unlock the drive,
then causes a reboot into the "real" MBR space
(or EFI space for newer drives).

WinMagic (which has a commercial product
"SecureDoc" that can manage TCG drives)
has a pretty good explanation of it here:
https://www.winmagic.com/blog/how-seds-really-work/

Therein the link with link text

https://www.winmagic.com/blog/how-seds-really-work/

has a wrong URL behind the link text
so one must copy&paste the link text
and then one gets (excerpts):

Seagate DriveTrust and TCG Opal SEDs
have an MBR (Master Boot Record) Shadow.
...
The "host" computer (i.e. the laptop) doesn't get
direct access to physical storage media ...
the drive presents a virtual view of the storage.
In the virtual view the storage space is presented
in logical blocks of 512 bytes to the host.
Each logical block gets a number assigned to it,
a Logical Block address (LBA).
The LBA starts at zero and goes up to a really big number
depending on the size of the drive.
The highest one is called Max LBA.

When the drive ships from the factory it is already
encrypting everything written to it.
If you buy a laptop from an OEM  (Lenovo, HP, etc)
with say Windows 7 pre-loaded on it the entire drive
is encrypted, even Windows.
This encryption is completely transparent to the OS
and at this point provides no protection of the data
because there is no authentication required to boot.

When our SecureDoc software executes in Windows
it first checks if the drive is a SED.
If it isn't then we encrypt the drive using software
but if it is a SED we use TCG commands to create the
MBR shadow and write our pre-boot authentication (PBA)
software to it.
The MBR shadow is a 128 MB area that is totally "off the map".
If the OS or a virus were to read each LBA on the drive
from LBA 0 to MAX LBA it would still not to be able
to see it or modify it.

Once MBR shadow is written by SecureDoc the drive is
configured to "lock" in the powered off state.
When the laptop is next turned on it doesn't see
the normal virtual space.
Rather it sees the MBR shadow in the 1st 128 MB
of the LBA's and above 128 MB to MAX LBA
it sees only 512 byte blocks of zeros.
That is, the MBR shadow is mapped into the first 128 MB
of virtual LBA space instead of the normal Windows MBR.

The host boots into the SecureDoc PBA code in the MBR shadow
instead of Windows, authenticates the user (e.g. they type in
a password), and then unlocks the drive.
At this point SecureDoc maps the MBR shadow
out of the LBA virtual space
and the normal Windows MBR and the rest of the
original drive is mapped in.
The host is rebooted this time into Windows and
it boots up as it did before the machine was
protected with MBR shadow.

Accordingly it seems the PBA image size limit
is the size of the MBR shadow and that seems to be
a hardware limit of the Self Encrypting Drive.
Because the text above tells
"we use TCG commands to create the MBR shadow"
so it could be possible to use TCG commands
to create a MBR shadow of arbitrary size?
But the MBR shadow could be different hardware storage
than the normal disk storage (totally "off the map")
so the size of the MBR shadow storage cannot be changed.

At least the usual SED factory default seems to be
that the MBR shadow size is "128 MB".
I assume "128 MB" is actually 128 MiB.

128 MB = 128 * 1000 * 1000 Bytes = 128000000 Bytes

128 MiB = 128 * 1024 * 1024 Bytes = 134217728 Bytes

128 MB is less than 6 MiB but more than 6 MB smaller
than 128 MiB so at least 120 MiB should be possible
for a PBA image.

20 MiB more could make a noticeable difference
when a PBA image size is near the size limit.

jsmeix commented at 2024-04-09 07:47:

By the way:
Regarding Self Encrypting Drives in general I found
https://www.ibm.com/docs/en/psfa/7.2.1?topic=administration-about-self-encrypting-drives
that reads (excerpt):

Self-encrypting drives (SEDs) encrypt data as it is written
to the disk. Each disk has a disk encryption key (DEK)
that is set at the factory and stored on the disk.

So the whole security of a SED depends on
how secure that key is "stored on the disk".

jsmeix commented at 2024-04-09 08:31:

@edmcman
yes, USE_SERIAL_CONSOLE='no' should have provided
more console output
BUT
what actually matters is what 'console' kernel
command line options are set when booting the kernel.

Normally (i.e. when booting the ReaR recovery system)
there is a ReaR recovery system bootloader screen
where you can see and if needed modify the
kernel command line options.
For example on a BIOS system
when booting a ReaR recovery system ISO image
with SYSLINUX/ISOLINUX as bootloader one can get
the ReaR recovery system kernel command line arguments
by selecting in the ReaR recovery system boot menue
the topmost enty of the form "Recover HOSTNAME" and then
pressing the [Tab] key which shows the kernel command line.

I don't know if something like that is also available
when booting ReaR's PBA image.

edmcman commented at 2024-04-10 13:10:

I can't seem to access any type of menu, but I was able to extract the grub configuration file from the PBA image:

insmod all_video
set timeout=0
set default=0
menuentry "TCG Opal pre-boot authentication" {
    linux /vmlinuz-6.5.0-26-generic  selinux=0 quiet splash systemd.volatile=yes systemd.unit=sysinit-opalpba.target  vt.handoff=7 libata.allow_tpm=1
    initrd /initrd.cgz
}

I'll try to remove quiet splash and see if that helps...

sei-eschwartz commented at 2024-04-10 13:43:

I was able to modify the grub config and set the timeout to 10, which let me change the kernel arguments to whatever I wanted. I tried a few things. First, I disabled iwlwifi. This removed the iwlwifi warnings, but the boot did not seem to progress any further. Second, I added the ignore_loglevel argument which causes more kernel logging:

image

My suspicion, which could be wrong, is that the kernel is "booted" in some sense, but we're either stuck in systemd, or maybe plymouth isn't working as expected.

I just saw that passing debug can make systemd log some more, so I'll try that. And maybe rd.plymouth=0 plymouth.enable=0.

sei-eschwartz commented at 2024-04-10 14:06:

Good news! If I pass nomodeset, then I am prompted for the opal password, and then the machine reboots. I don't currently have an OS installed on the Opal drive, so I got an error about there not being an OS installed, but that seems expected :-)

So now we know that the problem has something to do with modesetting. I wonder if it is missing firmware for the i915 driver?

jsmeix commented at 2024-04-10 14:47:

Perhaps 'nomodeset' should be set by default
because according to what I understand how things work in
https://github.com/rear/rear/issues/3194#issuecomment-2044355011
the only purpose of booting what there is in the MBR shadow
is to unlock the drive and for that task the simple
kernel framebuffer driver with traditional VGA resolution
should be sufficient.

Perhaps simple traditional VGA output to unlock the drive
(I assume what you get on the screen in this case
is only traditional text console output)
could be even an advantage compared to having that
e.g. in Full HD resolution only in the upper left quarter
of a 4K display (tiny text which is really hard to read).

edmcman commented at 2024-04-10 14:48:

I found a bunch of PBA related settings in
Ubuntu.conf and tried them:
local.conf.txt

This still got stuck, which suggests the problem is perhaps the i915 firmware. It's pretty big, though, so not sure if including it all will work:

ed@banana:~/rear$ du -ch /lib/firmware/i915/
27M /lib/firmware/i915/
27M total

jsmeix commented at 2024-04-10 14:52:

I would try to avoid special GPU stuff if possible.
When things look OK on the screen with 'nomodeset'
for the only purpose to unlock the drive
then I think 'nomodeset' is the simplest and
most straightforward way (i.e. KISS principle).

edmcman commented at 2024-04-10 14:54:

Yes, I think if there is any general take away from my problems, it is that nomodeset should probably be the default.

One of the developers the OPAL functionality clearly was using Plymouth for a fancier way of doing things: https://github.com/rear/rear/blob/master/usr/share/rear/conf/Ubuntu.conf
https://github.com/rear/rear/blob/b838a352136811900511a209d06c809ce552e636/usr/share/rear/skel/default/etc/scripts/unlock-opal-disks

But I think most people would be happy with a working text prompt!

edmcman commented at 2024-04-10 15:00:

Success! With the i915 firmware, I get the GUI prompt, which is pretty slick I have to admit:

image

But IMHO:

  1. nomodeset should be the default option
  2. There should be an optional way to disable this, and perhaps a section added to https://github.com/rear/rear/blob/master/doc/user-guide/13-tcg-opal-support.adoc to discuss how to enable the GUI.

jsmeix commented at 2024-04-10 15:01:

FYI:
For the bootloader setup of the ReaR recovery system
we set vga=normal

usr/share/rear/conf/templates/RESULT_usage_RAMDISK.txt
           --command-line='root=/dev/ram0 vga=normal'

usr/share/rear/lib/bootloader-functions.sh
    echo "append initrd=$REAR_INITRD_FILENAME root=/dev/ram0 vga=normal rw $KERNEL_CMDLINE"
    echo "append initrd=$REAR_INITRD_FILENAME root=/dev/ram0 vga=normal rw $KERNEL_CMDLINE auto_recover $ISO_RECOVER_MODE"
    echo "    append initrd=$PXE_INITRD root=/dev/ram0 vga=normal rw $KERNEL_CMDLINE $PXE_RECOVER_MODE"
        echo "    append initrd=$PXE_HTTP_DOWNLOAD_URL/$PXE_INITRD root=/dev/ram0 vga=normal rw $KERNEL_CMDLINE $PXE_RECOVER_MODE"
    echo "linux (tftp)/$PXE_KERNEL root=/dev/ram0 vga=normal rw $KERNEL_CMDLINE $PXE_RECOVER_MODE"

usr/share/rear/output/USB/Linux-i386/300_create_extlinux.sh
    append initrd=/$USB_PREFIX/$REAR_INITRD_FILENAME root=/dev/ram0 vga=normal rw $KERNEL_CMDLINE
    append initrd=/$USB_PREFIX/$REAR_INITRD_FILENAME root=/dev/ram0 vga=normal rw $KERNEL_CMDLINE auto_recover

usr/share/rear/output/default/940_grub2_rescue.sh
        echo "          linux $grub_boot_dir/$boot_kernel_name root=/dev/ram0 vga=normal rw $KERNEL_CMDLINE"

usr/share/rear/output/PXE/default/810_create_pxelinux_cfg.sh
    append initrd=$OUTPUT_PREFIX_PXE/$PXE_INITRD root=/dev/ram0 vga=normal rw $KERNEL_CMDLINE $PXE_RECOVER_MODE

edmcman commented at 2024-04-10 15:06:

That's interesting. Those parameters do not make it into the PBA image.

jsmeix commented at 2024-04-10 15:10:

I am not a SED user but from what I see at
https://github.com/rear/rear/issues/3194#issuecomment-2047794207
I even think the "system76 ... Ubuntu" GUI prompt
is misleading because (as far as I understand what goes on)
what you run there is not your actual "system76 ... Ubuntu"
but ReaR's Pre-Boot Authorization (PBA) system from the MBR shadow
which was made by ReaR from parts of your "system76 ... Ubuntu"
but that PBA system is not your actual "system76 ... Ubuntu"
so it should not show up as if it was your "system76 ... Ubuntu".

At least when I look at the screenshot in
https://github.com/rear/rear/issues/3194#issuecomment-2047794207
I would never ever think this is a ReaR PBA system
so it would be at least misleading to others
who fail to imagine what actaully goes on there.

edmcman commented at 2024-04-10 15:17:

Yes, that is from the PBA image. System 76 is the PC manufacturer and their logo shows in other Plymouth prompts as well.

FWIW, as a sed user, I don't really care too much about the Ubuntu logo appearing there. Perhaps it would be more appropriate to have a ReaR logo, but I think anyone using a ReaR OPAL PBA probably knows what is going on. A very simple mitigation could be to include ReaR in the text prompt, e.g., "ReaR PBA: Enter password to unlock TCG OPAL disks". 🤷

jsmeix commented at 2024-04-10 15:17:

I think 'vga=normal' alone cannot work
when the GPU is used but without firmware
because the GPU without firmware cannot show
any screen output (also none in 'vga=normal' mode).

So I think 'nomodeset' is crucial when a GPU is used
that needs firmware (which many nowadays GPUs need)
to get screen output in simple console text mode
when one does not want to bother with firmware stuff
under the rather low size limits of the MBR shadow.

jsmeix commented at 2024-04-10 15:20:

@edmcman
could you please also post a screenshot how it looks
with 'nomodeset' in simple console text mode i.e. for
https://github.com/rear/rear/issues/3194#issuecomment-2047646496
so I could get a better understanding how that things look
"in real world out there".

edmcman commented at 2024-04-10 15:44:

So I just added nomodeset but left the i915 firmware and plymouth specific config settings, and the GUI still appeared. So apparently KMS isn't needed for the GUI.

Still working on getting the CLI interface for you.

edmcman commented at 2024-04-10 15:50:

image

jsmeix commented at 2024-04-11 07:55:

This looks rather terse.

Perhaps the password_prompt text in
usr/share/rear/skel/default/etc/scripts/unlock-opal-disks
could be a bit more descriptive to make it more clear
what it is about (but must still fit on a 80 columns
traditional console) like

Enter password to unlock TCG Opal 2 disks

or less tecnically accurate

Enter password to unlock self-encrypting disks

or both

Enter password to unlock TCG Opal 2 self-encrypting disks

where the latter results on the screen
via the ask_for_password() function

Enter password to unlock TCG Opal 2 self-encrypting disks:

with a trailing blank which is 59 characters long.

Or in simpler wording - for the user it does not matter
how ('self' or via another method) it is encrypted
(this is a technical implementation detail)
what matters is that there are encrypted disks
which need to be unlocked:

Enter password to unlock TCG Opal 2 encrypted disks:

It matters for the user that the disks are TCG Opal 2 compliant
(i.e. the SEDs are encrypted in a TCG Opal 2 compliant way)
because other kind of SEDs are not supported according to
https://github.com/rear/rear/blob/master/doc/user-guide/13-tcg-opal-support.adoc

edmcman commented at 2024-04-11 12:54:

I think the consumer of the message can be divided in two cases: (1) the person who configured the drives and PBA, (2) someone else.

The person who configured the drives really only needs the message to tell them when the PBA is ready for the password. They already know the drives are encrypted.

Other people probably need slightly more context. I think a slightly longer explanation would be more useful. Something like:

"This computer is configured to boot from an encrypted disk. Please enter the encryption password to unlock the disks:"

That is longer than 80 characters, but is that really a problem? We could put a line-break before the prompt sentence.

jsmeix commented at 2024-04-11 13:41:

Some general understanding questions:

I just don't understand
https://github.com/rear/rear/blob/master/doc/user-guide/13-tcg-opal-support.adoc
I confuses me what is where (USB stick vs. disk vs. SED).

I thought you get the prompt

Enter password to unlock disks:

only when booting the ReaR PBA system
(from the shadow MBR of a SED).

Now I am wondering what the purpose is
of that SED with the ReaR PBA system on it?

Will that SED become your normal operating system disk
or will that SED become your ReaR recovery medium that
you only use to recreate your operating system?

When that SED with the ReaR PBA system
becomes your normal operating system disk
it means (as far as I imagine things) that
when that SED is unlocked,
it will boot the normal operating system
and
when that SED is locked,
it will boot the ReaR PBA system.

So any user of the computer with that SED
may get the ReaR PBA system booted
(when that SED is locked).

If my above guess how all that belongs together is right,
I understand now why there was so much effort taken
to make booting the ReaR PBA system look nice
with splash screen and whatnot:
To make booting the computer with that SED
look mostly same as booting with a normal disk.

In this case 'nomodeset' text-only booting by default
would make booting from a TCG Opal 2-compliant SED
look rather different for normal users compared to
booting from a normal (unencrypted) disk.

Is my above guess how all that belongs together right
or do I misunderstand and confuse things?

edmcman commented at 2024-04-11 14:39:

Overall I think you have a good understanding of how things will work.

Will that SED become your normal operating system disk
or will that SED become your ReaR recovery medium that
you only use to recreate your operating system?

The former. It's kind of weird, but I came to the project for the PBA support only :-)

In this case 'nomodeset' text-only booting by default
would make booting from a TCG Opal 2-compliant SED
look rather different for normal users compared to
booting from a normal (unencrypted) disk.

I could be wrong, but I think that nomodeset was still able to use Plymouth for the nice GUI prompt and it didn't noticeably look different to me from Plymouth outside of PBA.

Also, one detail that you may not be thinking of is that after the PBA unlocks the disks, the computer actually reboots. So I don't think the PBA will ever be a completely seamless experience.

jsmeix commented at 2024-04-11 14:56:

@edmcman
yes - of course - 'nomodeset' does not mean text-only.
Thank you for correcting me - I got confused.

Cf.
https://askubuntu.com/questions/716957/what-do-the-nomodeset-quiet-and-splash-kernel-parameters-mean

The newest kernels have moved the video mode setting
into the kernel. So all the programming of the hardware
specific clock rates and registers on the video card
happen in the kernel rather than in the X driver when
the X server starts.. This makes it possible to have
high resolution nice looking splash (boot) screens
and flicker free transitions from boot splash
to login screen. Unfortunately, on some cards this
doesn't work properly and you end up with a black screen.
Adding the nomodeset parameter instructs the kernel
to not load video drivers and use BIOS modes instead
until X is loaded.

i.e. with 'nomodeset' one basically gets
a simple kernel video (framebuffer?) driver
with some traditional VGA resolution and likely
some lower frames per second rate (e.g. 60 Hz)
as I wrote above (where I was not yet confused)
https://github.com/rear/rear/issues/3194#issuecomment-2047760674
and that should be well sufficient for the only task
to enter the password to unlock the SED.

Also thank you that you explicitly described that
after the PBA unlocked the disks, the computer reboots.
I assumed that from what I had read but now I know it
actually behaves this way.

edmcman commented at 2024-04-11 15:36:

I was expecting nomodeset to disable the GUI as well. It was a pleasant surprise.

[Export of Github issue for rear/rear.]