This is kind of an offshoot of https://bugzilla.redhat.com/show_bug.cgi?id=1593028 . One thing I figured out while investigating that bug is that the Fedora aarch64 kernel builds have this in their kernel config: CONFIG_CMDLINE="console=ttyAMA0" that's not done for any other arch (not even armv7hl) - only aarch64. It basically 'bakes' console=ttyAMA0 into the cmdline on any boot of a Fedora aarch64 kernel. You can specify *additional* consoles, but you can never *not* have a console on ttyAMA0. This has various consequences. Not least, it means that if an aarch64 system actually has both a 'real' display and a serial console on ttyAMA0 - e.g. a typical aarch64 VM - you will not get plymouth displayed on its physical display unless you manually add 'console=tty0' to its boot parameters, due to details of how plymouth works. plymouth will only show up on the serial console. pbrobinson and pwhalen seem to be of the opinion that this was basically an ugly hack from the early early days and it should probably go away now, so I'm filing this bug to make sure this isn't forgotten. I also happened to notice a small inconsistency between the other arches here. Other arm arch configs (armv7hl, armv7hl-debug, armv7hl-lpae, armv7hl-lpae-debug) have CONFIG_CMDLINE="" , but all the other arches do not mention it at all (not even an 'is not set' line). I'm not sure if this is significant, just thought I'd mention it.
I'm looking at this.
I've pushed this, it'll be in the rc2 build, I've not tested as much as I'd have liked due to dealing with other issues so we'll see how we get on with this.
WHAT COULD POSSIBLY GO WRONG
So looks fine via serial console on: * mustang * Pine64 * Dragonboard 410c Boot tested on Raspberry Pi 3B+ but not tested serial console but it's not ttyAMA0 anyway. Config looks fine: $ grep CONFIG_CMDLINE /boot/config-4.18.0-0.rc2.git1.1.fc29.aarch64 # CONFIG_CMDLINE_PARTITION is not set CONFIG_CMDLINE="" # CONFIG_CMDLINE_FORCE is not set So I think this should be all good, kernel should be in tomorrow's compose
thanks, now I guess I get to take all those workarounds I wrote into openqa tests back out again :)
So, it seems that that actually does not do the trick. See https://bugzilla.redhat.com/show_bug.cgi?id=1661288 , which goes a long way around the houses, but eventually works out that, right after I took the workaround out of the openQA tests (the 'workaround' is to pass 'console=tty0' on the cmdline), this broke again - aarch64 tests stopped seeing boot messages. Somehow I forgot about this whole thing, though, and wasted a bunch of time trying to figure out why. For now I'm going to put the workaround back in the openQA tests.
Is the qemu based vm on which openQA is running perhaps using devicetree rather then UEFI ? In devicetree it is possible the indicate the prefered/defailt console= value by setting stdout-path in the chosen node in devicetree: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/chosen.txt Doing a "grep -R stdout-path arch/arm64/boot/dts" in the kernel tree shows that most dts files define stdout-path and point this to the serial0 or serial1 alias.
No, it's UEFI.
(In reply to Adam Williamson from comment #8) > No, it's UEFI. Well could still be something similar, ACPI tables can embed devicetree-data and on aarch64 this is sometimes being used AFAIK.