Bug#952452: initramfs-tools: prefers serial console over framebuffer console

[Alper Nebi Yasak]

Package: initramfs-tools
Version: 0.136
Severity: minor

Dear kernel team,

I'm using Debian on an arm64 chromebook, and not setting "console=tty1" 
in the kernel command line results in a number of weird behaviours 
related to the initramfs.


During an ordinary boot, plymouth doesn't show the futureprototype boot 
splash. Instead, it shows the init log; but pressing ESC does switch to 
plymouth (but with what I'm assuming is the text theme instead).


If I use "break" (even "break=init") in the kernel command line, I don't 
see an initramfs shell prompt and the keyboard does nothing. If plymouth 
is installed, I see the "Spawning shell within the initramfs" message 
but rest is the same (plymouth quits in it's panic hook).


When I'm trying to boot from an encrypted root (different installation), 
I don't see the "Please unlock disk" cryptsetup prompt and can't type a 
passphrase; unless plymouth is installed.


I'm able to boot the encrypted system as a QEMU virtual machine and I 
get similar behaviour there, no messages or prompts are printed to the 
graphical console and instead all go to the serial console. However 
having plymouth doesn't make the cryptsetup prompt ask in the graphical 
console in the virtual machine.


All these are fixed by simply adding "console=tty1" to the command line, 
is that something a user is supposed to do manually (e.g. GRUB configs)? 
Should the initramfs (or maybe the kernel itself) be detecting when 
graphics are working and automatically switch outputs/prompts to that? I 
want to work on this, what would be the best way to proceed?



-- Might be relevant:
-- /proc/consoles:
ttyS2-W- (EC p a)4:66
tty0 -WU (E  p  )4:7

-- Some dmesg lines that might be useful:
[0.00] Booting Linux on physical CPU 0x00 [0x410fd034]
[0.00] Linux version 5.4.0-4-arm64 (...)
[0.00] Machine model: Google Kevin
[0.001029] Console: colour dummy device 80x25
[0.001038] printk: console [tty0] enabled
[0.044788] Serial: AMBA PL011 UART driver
[1.853700] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[1.855861] ff1a.serial: ttyS2 at MMIO 0xff1a (irq = 39, 
base_baud = 150) is a 16550A

[1.856046] printk: console [ttyS2] enabled
[1.857318] Serial: AMBA driver
[1.857898] msm_serial: driver initialized
[2.103745] ttyS2 - failed to request DMA
[2.159994] Run /init as init process
[2.785121] rockchip-drm display-subsystem: bound ff8f.vop (ops 
rockchip_drm_fini [rockchipdrm])
[2.787381] rockchip-drm display-subsystem: bound ff90.vop (ops 
rockchip_drm_fini [rockchipdrm])
[2.794270] rockchip-drm display-subsystem: bound ff97.edp (ops 
rockchip_drm_fini [rockchipdrm])
[2.794439] rockchip-drm display-subsystem: bound fec0.dp (ops 
rockchip_drm_fini [rockchipdrm])

[2.794446] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.794449] [drm] No driver support for vblank timestamp query.
[2.824898] cdn-dp fec0.dp: [drm:cdn_dp_pd_event_work 
[rockchipdrm]] Not connected. Disabling cdn

[3.076232] Console: switching to colour frame buffer device 300x100
[3.132091] rockchip-drm display-subsystem: fb0: rockchipdrmfb frame 
buffer device
[3.144856] [drm] Initialized rockchip 1.0.0 20140818 for 
display-subsystem on minor 0

[4.972935] systemd[1]: systemd 244.3-1 running in system mode. (...)


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 12M Jan 19 11:20 /boot/initrd.img-5.4.0-2-arm64
-rw-r--r-- 1 root root 16M Feb  8 12:52 /boot/initrd.img-5.4.0-3-arm64
-rw-r--r-- 1 root root 16M Feb 19 14:25 /boot/initrd.img-5.4.0-4-arm64
-- /proc/cmdline
cros_secure kern_guid=7849fbba-1fb3-4f0b-9989-952567ef5a3c 
root=PARTUUID=3518689e-a82c-4448-9ec2-c79b13f88d8e rootwait quiet splash


-- resume
RESUME=UUID=490bfb86-ee41-4944-8bcf-4f4b2211026d
-- /proc/filesystems
ext3
ext2
ext4
fuseblk

-- lsmod
Module  Size  Used by
vhost_net  32768  0
vhost  49152  1 vhost_net
tap32768  1 vhost_net
uhid   24576  1
algif_hash 20480  1
algif_skcipher 16384  1
af_alg 28672  6 algif_hash,algif_skcipher
rfcomm 81920  16
fuse  139264  5
xt_CHECKSUM16384  1
xt_MASQUERADE  20480  3
xt_conntrack   16384  1
ipt_REJECT 16384  2
nf_reject_ipv4 16384  1 ipt_REJECT
xt_tcpudp  20480  6
nft_compat 20480  13
nft_counter16384  30
nft_chain_nat  16384  8
nf_nat 45056  2 nft_chain_nat,xt_MASQUERADE
nf_conntrack  159744  3 xt_conntrack,nf_nat,xt_MASQUERADE
nf_defrag_ipv6 24576  1 nf_conntrack
nf_defrag_ipv4 16384  1 nf_conntrack
libcrc32c  16384  2 nf_conntrack,nf_nat
nf_tables 151552  102 nft_compat

Bug#952452: initramfs-tools: prefers serial console over framebuffer console

[Alper Nebi Yasak]

On 24/02/2020 19:50, Alper Nebi Yasak wrote:

I'm using Debian on an arm64 chromebook, and not setting "console=tty1"
in the kernel command line results in a number of weird behaviours
related to the initramfs.


Turns out my device-tree has (for debugging purposes?):

chosen {
stdout-path = "serial2:115200n8";
};

Removing that makes everything work on the screen again, but that's a 
worse way to solve it compared to adding a kernel cmdline arg.


QEMU on aarch64 does a similar thing according to [0]:

$ sudo dmesg | grep -i console
[0.00] ACPI: SPCR: console: pl011,mmio,0x900,9600
...

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1661288#c35

Those seem to be the root cause.

Bug#952452: initramfs-tools: prefers serial console over framebuffer console

[Alper Nebi Yasak]

On 27/02/2020 02:10, Ben Hutchings wrote:

A device that is intended to be used with keyboard and video display
should not have this in the device tree for production units.  If we
ship the device tree then we can correct that.  If not, then the boot
loader should be configured to override it, and the installer could do
that by default.


I'm using rk3399-gru-kevin.dtb from the Debian package. The stdout-path 
property comes from arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi in the 
kernel tree. Setting a serial console this way seems to be ordinary, a 
lot of other devices have it too.


For the bootloader (part of the firmware), I don't know if there is a 
way to make it change that property in the device-tree file. Meanwhile 
I've added "console=tty0" to the default cmdline my bootloader-handler 
project uses, so everything should be fine for now.



I don't think it makes sense for initramfs-tools to do this, as the
wrong default console will still affect other software.


I intended to say that maybe initramfs-tools should correct the default 
console to the virtual console not just for itself but for the entire 
userspace. (I don't even know if that's possible.)

Bug#952452: initramfs-tools: prefers serial console over framebuffer console

[Ben Hutchings]

On Fri, 2020-02-28 at 17:59 +0300, Alper Nebi Yasak wrote:
> On 27/02/2020 02:10, Ben Hutchings wrote:
> > A device that is intended to be used with keyboard and video display
> > should not have this in the device tree for production units.  If we
> > ship the device tree then we can correct that.  If not, then the boot
> > loader should be configured to override it, and the installer could do
> > that by default.
> 
> I'm using rk3399-gru-kevin.dtb from the Debian package. The stdout-path 
> property comes from arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi in the 
> kernel tree. Setting a serial console this way seems to be ordinary, a 
> lot of other devices have it too.

I think most devices for which the kernel provides the device tree are
development boards, so a serial console is a fairly sensible default
for them.  It sounds like this should be changed for the "kevin" board.

> For the bootloader (part of the firmware), I don't know if there is a 
> way to make it change that property in the device-tree file.

Yes, it is normal for the boot loader to modify the device tree after
loading it.  For example, to set the kernel command line or memory
size.

> Meanwhile 
> I've added "console=tty0" to the default cmdline my bootloader-handler 
> project uses, so everything should be fine for now.
> 
> > I don't think it makes sense for initramfs-tools to do this, as the
> > wrong default console will still affect other software.
> 
> I intended to say that maybe initramfs-tools should correct the default 
> console to the virtual console not just for itself but for the entire 
> userspace. (I don't even know if that's possible.)

Right, but I don't think it is possible.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.




signature.asc
Description: This is a digitally signed message part