RPi4 icon indicating copy to clipboard operation
RPi4 copied to clipboard

Debian installer uses serial console by default

Open pbatard opened this issue 5 years ago • 10 comments

It looks like, currently, the console from an uninitialized firmware is neither completely serial nor graphical, as, if you try to install Debian 11, and if you don't go to the console settings, it will default to using serial console instead of graphical.

Most likely, other distros' installers also default to using serial.

This is of course very problematic for users as, if they don't explicitly go to the setup/console preference selection, they are only going to be met with a black screen.

It would appear that the console settings we apply when we detect that no console has been set (which result in boot message ConsolePrefDxeEntryPoint: no console preference found, defaulting to graphical) and the ones we apply when graphical has been explicitly do not result in the same outcome...

pbatard avatar Jun 08 '20 16:06 pbatard

Further investigation shows that, until you explicitly go into the menu to set the variable, the OnReadyToBoot() event from ConsolePrefDxe.c never happens, even as the gBS->CreateEventEx call reports success...

And it's not a matter of the OnReadyToBoot() being called and bailing out early. OnReadyToBoot() is just never called, even as its associated event was successfully queued up.

pbatard avatar Jun 13 '20 22:06 pbatard

The best explanation I have for this behaviour is that, until we save the variables, we default to booting PlatformRecovery, and therefore the EFI_EVENT_GROUP_READY_TO_BOOT event group is not being processed as, per specs, this is tied to Boot Manager being invoked:

EFI_EVENT_GROUP_READY_TO_BOOT This event group is notified by the system when the Boot Manager is about to load and execute a boot option.

For reference this is the debug output from a firmware where the variables have not been saved:

[Bds]=============Begin Load Options Dumping ...=============
  Driver Options:
  SysPrep Options:
  Boot Options:
    Boot0000: UiApp              0x0109
    Boot0001: UEFI Shell                 0x0000
  PlatformRecovery Options:
    PlatformRecovery0000: Default PlatformRecovery               0x0001
[Bds]=============End Load Options Dumping=============
[Bds]BdsWait ...Zzzzzzzzzzzz...
[Bds]BdsWait(5)..Zzzz...
.[Bds]BdsWait(4)..Zzzz...
.[Bds]BdsWait(3)..Zzzz...
.[Bds]BdsWait(2)..Zzzz...
.[Bds]BdsWait(1)..Zzzz...
..[Bds]Exit the waiting!
Process PlatformRecovery0000 (Default PlatformRecovery) ...

And the same output after they have:

[Bds]=============Begin Load Options Dumping ...=============
  Driver Options:
  SysPrep Options:
  Boot Options:
    Boot0000: UiApp              0x0109
    Boot0001: UEFI Shell                 0x0000
    Boot0002: SD/MMC on Arasan SDHCI             0x0001
    Boot0003: UEFI SanDisk USB Extreme Pro 00000000000000000000                  0x0001
    Boot0004: UEFI PXEv4 (MAC:DCA6320C92F5)              0x0001
    Boot0005: UEFI PXEv6 (MAC:DCA6320C92F5)              0x0001
    Boot0006: UEFI HTTPv4 (MAC:DCA6320C92F5)             0x0001
    Boot0007: UEFI HTTPv6 (MAC:DCA6320C92F5)             0x0001
  PlatformRecovery Options:
    PlatformRecovery0000: Default PlatformRecovery               0x0001
[Bds]=============End Load Options Dumping=============
[Bds]BdsWait ...Zzzzzzzzzzzz...
[Bds]BdsWait(5)..Zzzz...
.[Bds]BdsWait(4)..Zzzz...
.[Bds]BdsWait(3)..Zzzz...
.[Bds]BdsWait(2)..Zzzz...
.[Bds]BdsWait(1)..Zzzz...
..[Bds]Exit the waiting!
[Bds]Stop Hotkey Service!
[Bds]UnregisterKeyNotify: 000B/0000 Success
[Bds]UnregisterKeyNotify: 0017/0000 Success
[Bds]UnregisterKeyNotify: 0000/000D Success
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>> OnReadyToBoot: OnReadyToBoot <<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

pbatard avatar Jun 15 '20 12:06 pbatard

EDK2 patch proposal in https://edk2.groups.io/g/devel/message/61327 + https://edk2.groups.io/g/devel/message/61328.

pbatard avatar Jun 16 '20 09:06 pbatard

Seems like an EDK2 bug : https://edk2.groups.io/g/devel/message/61433

samerhaj avatar Jun 19 '20 01:06 samerhaj

discussion in BZ issue https://bugzilla.tianocore.org/show_bug.cgi?id=2831

samerhaj avatar Aug 26 '20 15:08 samerhaj

FYI. I tried yesterday Debian installer for bullseye alpha3, https://cdimage.debian.org/cdimage/bullseye_di_alpha3/arm64/iso-dvd/debian-bullseye-DI-alpha3-arm64-DVD-1.iso specifically, with RPi4 UEFI 1.22 on RPi 4 8GB, and the installation was by default graphical (I mean "not over serial"). I didn't even need to adjust kernel parameters or anything, it was this way by default.

baryluk avatar Feb 05 '21 01:02 baryluk

Debian 11 was released recently, and the installer started correctly for me using using firmware 1.29 on an 8GB Pi. Didn't default to serial.

Wyzard256 avatar Aug 26 '21 05:08 Wyzard256

Didn't default to serial.

That's because we are applying this extra patch to our builds.

Without it, the console will default to serial. We also explicitly state so in the README:

This firmware was built from the official EDK2 repository, with the following extra patch applied: 0001-MdeModulePkg-UefiBootManagerLib-Signal-ReadyToBoot-o.patch, so that the Graphical console is set as default.

pbatard avatar Aug 26 '21 06:08 pbatard

UEFI Forum has just approved an ECR to UEFI spec to require signaling ReadyToBoot on platform recovery path: https://bugzilla.tianocore.org/show_bug.cgi?id=3336

Based on that ECR, this extra patch is proper and matches the spec language. There is no reason to keep holding it out of tree, it should get submitted to the mailing list (referencing the approved spec ECR) to get merged upstream.

samerhaj avatar Aug 26 '21 14:08 samerhaj

This should be ready to close right? allow for another point release?

paulwratt avatar Feb 17 '22 14:02 paulwratt