Disk password prompt isn't shown in external monitor

Bug #2069039 reported by Sergio Costas
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
initramfs-tools (Ubuntu)
Won't Fix
Low
Unassigned

Bug Description

Up to Ubuntu 23.10, when my laptop (which has encrypted hard disk) booted, it asked for the deciphering password as usual, and, if an external monitor was connected, the prompt was shown in both the internal and the external screens. After updating to Ubuntu 24.04 this no longer is the case: the prompt is shown only in the internal screen, and the external one remains in powersave mode. After typing the password, the system begins to boot and, after some seconds (I presume that it's until the initramfs is pivoted), the external monitor wakes up and shows the remaining boot process.
---
ProblemType: Bug
ApportVersion: 2.28.1-0ubuntu3
Architecture: amd64
BootLog: Error: [Errno 13] Permiso denegado: '/var/log/boot.log'
CasperMD5CheckResult: pass
CurrentDesktop: GNOME
DefaultPlymouth: /usr/share/plymouth/themes/bgrt/bgrt.plymouth
DistroRelease: Ubuntu 24.04
InstallationDate: Installed on 2022-05-09 (764 days ago)
InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Release amd64 (20220419)
MachineType: SLIMBOOK PROX14-AMD
NonfreeKernelModules: zfs
Package: plymouth 24.004.60-1ubuntu7
PackageArchitecture: amd64
ProcCmdLine: BOOT_IMAGE=/vmlinuz-6.8.0-35-generic root=/dev/mapper/vgubuntu-root ro quiet splash acpi_backlight=video vt.handoff=7
ProcFB: 0 amdgpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-6.8.0-35-generic root=/dev/mapper/vgubuntu-root ro quiet splash acpi_backlight=video vt.handoff=7
ProcVersionSignature: Ubuntu 6.8.0-35.35-generic 6.8.4
Tags: noble wayland-session
TextPlymouth: /usr/share/plymouth/themes/ubuntu-text/ubuntu-text.plymouth
Uname: Linux 6.8.0-35-generic x86_64
UpgradeStatus: Upgraded to noble on 2024-05-08 (34 days ago)
UserGroups: adm cdrom dip docker kvm libvirt lpadmin lxd plugdev sambashare sudo swtpm vboxusers
_MarkForUpload: True
dmi.bios.date: 07/28/2022
dmi.bios.release: 5.16
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: N.1.07GRP05
dmi.board.asset.tag: Standard
dmi.board.name: PROX14-AMD
dmi.board.vendor: SLIMBOOK
dmi.board.version: Standard
dmi.chassis.asset.tag: Standard
dmi.chassis.type: 10
dmi.chassis.vendor: SLIMBOOK
dmi.chassis.version: Standard
dmi.ec.firmware.release: 1.9
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrN.1.07GRP05:bd07/28/2022:br5.16:efr1.9:svnSLIMBOOK:pnPROX14-AMD:pvrStandard:rvnSLIMBOOK:rnPROX14-AMD:rvrStandard:cvnSLIMBOOK:ct10:cvrStandard:sku0001:
dmi.product.family: RENOIR
dmi.product.name: PROX14-AMD
dmi.product.sku: 0001
dmi.product.version: Standard
dmi.sys.vendor: SLIMBOOK
modified.conffile..etc.default.apport:
 # set this to 0 to disable apport, or to 1 to enable it
 # you can temporarily override this with
 # sudo service apport start force_start=1
 enabled=0
mtime.conffile..etc.default.apport: 2023-03-17T11:34:48.669034

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in plymouth (Ubuntu):
status: New → Confirmed
Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : CurrentDmesg.txt

apport information

tags: added: apport-collected noble wayland-session
description: updated
Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : Dependencies.txt

apport information

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : EtcDefaultGrub.txt

apport information

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : Lspci.txt

apport information

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : Lspci-vt.txt

apport information

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : Lsusb.txt

apport information

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : Lsusb-t.txt

apport information

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : Lsusb-v.txt

apport information

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : ProcCpuinfo.txt

apport information

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : ProcCpuinfoMinimal.txt

apport information

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : ProcEnviron.txt

apport information

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : ProcInterrupts.txt

apport information

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : ProcModules.txt

apport information

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : UdevDb.txt

apport information

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote : acpidump.txt

apport information

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

I was told this is a know limitation of simpledrm, and the only remedy is to load the native driver first before FDE pwd prompt..

Revision history for this message
Daniel van Vugt (vanvugt) wrote (last edit ):

Timo is right I think. Secondary monitors will only wake up after:

1. The native kernel DRM graphics driver is loaded.
2. Plymouth detects the new driver and switches to it.

And the native kernel DRM graphics drivers seem to be loading slightly later now that we have kicked them out of the initrd. In fact I think there might be a hard limit where they can't even start loading until the root FS is decrypted.

We want to keep those drivers out of the initrd because they've become bloated, but also because they take so long (up to 10 seconds) to load that they're not helpful to Plymouth wanting to display boot graphics very early. So we rely on SimpleDRM for that instead, which apparently can only display on the original BIOS display??

You should be able to work around it by adding 'amdgpu' to '/etc/initramfs-tools/modules' and then run:

  sudo update-initramfs -k all -u

or get the system to automatically insert all the modules you're currently using by changing the MODULES line in '/etc/initramfs-tools/initramfs.conf' to MODULES=dep and again:

  sudo update-initramfs -k all -u

affects: plymouth (Ubuntu) → initramfs-tools (Ubuntu)
Revision history for this message
Daniel van Vugt (vanvugt) wrote (last edit ):

This is probably a "Won't Fix" but I'll give others time to chime in and correct me.

We might fix this by restoring the full graphics drivers in initrd for encrypted setups, but I'm not sure there will be sufficient demand on this bug to make that the default.

tags: added: simpledrm
Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

I can confirm that, in my case, adding "amdgpu" to the initramfs does the trick. So now here comes the idea... What if we dynamically add to the initramfs the graphics driver needed for the current system only if the hard disk is encrypted? This is: add a script that is run right before updating initramfs that checks if the disk encryption is enabled, in which case will check the initramfs.conf file and add the needed graphics driver, only for the current configuration?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Yes it's been done before. I think the Nvidia drivers still do it because they're designed for older kernel builds that don't have SimpleDRM included.

But "needed" is a strong word in this case. It's unusual that you wouldn't be able to see the primary boot display at boot time. So in that case I don't think we should be forcing everyone with disk encryption to have a bloated initrd again.

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

When I say "needed", I mean to add only the specific module for the current hardware. This is: in my system, only the amdgpu would be added, not the intel or the nVidia ones. Also, we can add more heuristics... or just make it manual, so if an user has this problem, we can tell they: "just run XXXX and the problem will be fixed".

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

I can try to do it, but of course only if you consider that it worth it.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

The scripts for automatically deciding what goes into the initrd can be found in /usr/share/initramfs-tools/hooks/ and initramfs-tools in general could certainly be made more user-friendly...

In the end the foundations/kernel teams will decide what goes in and what doesn't. I just have a preference that we don't reintroduce the full graphic driver stack into initrd automatically without good reason. I don't think there is a good reason unless the disk unlock prompt failed to appear on the boot display.

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

So, the big question now is... with which graphic chips the unlock prompt doesn't appear on an external boot display?

In my case, with AMD integrated graphics it doesn't appear, and I think that it's safe to presume that it will happen with any other AMD graphics chip, no matter if it is integrated or not.

~tjaalton What graphics chip do you have in your system?

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

The issue will occur with all GPU types. All DRM drivers that support multiple monitors.

But I'd argue it's not a problem at all. Not wanting to have the boot display in view when you power on the machine is so uncommon that I feel the medicine would be worse than the disease. Just apply the workaround (comment #18) if it bothers you.

tags: added: regression-release
Changed in initramfs-tools (Ubuntu):
importance: Undecided → Low
status: Confirmed → Won't Fix
Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

I have to disagree. I attach a picture of my workbench, where you can see that I have an external monitor as the main display, and the laptop is just behind because I don't use its screen. As you can see, I have to, literally, look over the monitor to be able to know when do I have to type the password and to know if I typed it right, because the external display won't turn on until after it has been typed. This kind of configuration is becoming more and more common thanks to USB-C: use the laptop in a "classic desktop mode" at home, just disabling the builtin screen, and keeping it only for the cases where the laptop is used outside home, so I'm sure that we will begin to receive more and more complains about this as more and more people migrate to 24.04.

Revision history for this message
Daniel van Vugt (vanvugt) wrote :

I feel that photo kind of proves my point about how uncommon the situation is. Not invalid, just uncommon.

I also wonder if you could trick the laptop into using the external monitor as primary? Maybe if you can configure the BIOS to turn the machine on in response to USB keyboard/mice while the laptop is fully closed. Then there would only be one screen during boot and in theory the bug would never occur.

Revision history for this message
Sergio Costas (rastersoft-gmail) wrote :

I probably can do, but as I said, I think that this configuration is more and more common thanks to USB-C (you can just connect one cable and have a desktop system). But, of course, without objective data about real usage, all we have are just opinions, so I agree in that it's better to close this and wait to see if more people reports this as a problem. In my case, it's fixed with that trick.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

my thinkpad has i915, and I never plug it to any external monitor, except for testing stuff like this :)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.