New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PBA environment is stuck in Linux kernel log messages #3194
Comments
@edmcman From what your kernel messages show, inparticular
my blind guess is that the PBA image which is made In particular network hardware (and certain GPUs) I don't know it is possible to inspect what there is On my openSUSE Leap 15.5 workstation Do you have Perhaps "rear -D mkopalpba" tells something about |
I found the following documentation in
so by default you should get all files |
The only ReaR script that deals with OPAL_PBA_FIRMWARE_FILES is The only ReaR script that deals with FIRMWARE_FILES is
So I would suggest to run "rear -D mkopalpba"
and - if possible - also check what firmware files |
Hmm... |
I think this is just a warning. This message is present during normal Linux boots as well. |
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. |
Another blind guess: Does the image with the kernel messages in your initial posting In this case the kernel may just proceed rather well See the various 'CONSOLE' variables descriptions
what you may have to manually specify to ensure that |
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. |
Normally (i.e. for "rear mkrescue") the initrd contains I assume that with "rear mkopalpba" it is basically the same |
Regarding no further messages on the console see |
I can confirm that the mkrescue's initrd contains /lib/firmware, but mkopalpba's initrd does not. |
From
|
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 |
Here's what I put in /etc/rear/local.conf:
On a normal boot, here are the iwlwifi messages:
So the 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? |
Regarding To me a 100 MiB size maximum for a bootable image By googling for "PBA image size limit" I found
Therein the link with link text
has a wrong URL behind the link text
Accordingly it seems the PBA image size limit At least the usual SED factory default seems to be 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 20 MiB more could make a noticeable difference |
By the way:
So the whole security of a SED depends on |
@edmcman Normally (i.e. when booting the ReaR recovery system) I don't know if something like that is also available |
I can't seem to access any type of menu, but I was able to extract the grub configuration file from the PBA image:
I'll try to remove |
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 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 |
Good news! If I pass So now we know that the problem has something to do with modesetting. I wonder if it is missing firmware for the i915 driver? |
Perhaps 'nomodeset' should be set by default Perhaps simple traditional VGA output to unlock the drive |
I found a bunch of PBA related settings in 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:
|
I would try to avoid special GPU stuff if possible. |
Yes, I think if there is any general take away from my problems, it is that 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 But I think most people would be happy with a working text prompt! |
Success! With the i915 firmware, I get the GUI prompt, which is pretty slick I have to admit: But IMHO:
|
FYI:
|
That's interesting. Those parameters do not make it into the PBA image. |
I am not a SED user but from what I see at At least when I look at the screenshot in |
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". 🤷 |
I think 'vga=normal' alone cannot work So I think 'nomodeset' is crucial when a GPU is used |
@edmcman |
So I just added Still working on getting the CLI interface for you. |
This looks rather terse. Perhaps the
or less tecnically accurate
or both
where the latter results on the screen
with a trailing blank which is 59 characters long. Or in simpler wording - for the user it does not matter
It matters for the user that the disks are TCG Opal 2 compliant |
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. |
Some general understanding questions: I just don't understand I thought you get the prompt
only when booting the ReaR PBA system Now I am wondering what the purpose is Will that SED become your normal operating system disk When that SED with the ReaR PBA system So any user of the computer with that SED If my above guess how all that belongs together is right, In this case 'nomodeset' text-only booting by default Is my above guess how all that belongs together right |
Overall I think you have a good understanding of how things will work.
The former. It's kind of weird, but I came to the project for the PBA support only :-)
I could be wrong, but I think that 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. |
@edmcman Cf.
i.e. with 'nomodeset' one basically gets Also thank you that you explicitly described that |
I was expecting |
git eadcc68 (March 4th)
I'm getting an error on
rear mkopalpba
with the latest version. I'll file an issue for that shortly.PC System 76
x86
Open Firmware
Unsure about bootloader, whatever PBA is using
local NVMe
When I produce and install the PBA, it gets stuck while displaying some Linux kernel status messages.
Workaround, if any:
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
The text was updated successfully, but these errors were encountered: