When I start my HA VM with:
virsh start haos --console
I see the expected UEFI (debug) text and then some GRUB try A B ( a menu of 4), then it picks the default and the VM boots up fine to a working state, but the serial console is showing nothing anymore.
On my x86_64 system, I see the expected kernel/dmesg and finally the login prompt where I can simply login as root. That is very handy as serial console is much more convenient (linux copy/paste text doesn’t wotk in the graphical console. I am very used to this as well on physical Arm boards like RPi and NanoPi with a USB2serial cable connection.
on x86_64: cat cmdline.txt
console=ttyS0 console=tty1
on aarch64: cat cmdline.txt
console=tty1 console=ttyS0
swapping doesn’t help as I expected, so seems like kernel config or the rootfs somewhere a config file that is changed too much compared to vanilla Debian12. On RPiOS there were similar issues, they made it ‘nice’ so less kernel (debug) messages on the console, but it hides fatal kernel states (of USB3). So I changed it.
Not sure, but after things have booted and running fine, when you are in your console shell, type tty. which should tell you the ttyXXXX your running in. Does it match any of the consoles in cmdline.txt?
I am sorry, I already deleted the HA OS based installation for aarch64 and installed HA Supervised on an existing Debian12 aarch64 VM where serial console simply works.
I still have the x64_86 HA OS running, so to compare, if I select serial console there:
haos login: root
Last login: Thu Apr 4 16:06:00 UTC 2024 on ttyS0
Last login: Sat Apr 6 04:37:07 on ttyS0
Welcome to Home Assistant OS.
Use ha to access the Home Assistant CLI.
tty
/dev/ttyS0
Which is expected. In the graphical console the ‘ha’ program is active, it is the main shell I think, haven’t done anything with it so far, also don’t know how to exit.
I hope this topic rings a bell for someone who did the kernel config, on ARM serial console works out-of-the-box for years already for the default (debian) linux kernel config. The problem might be that a RPi kernel (needed for Yello I think) is taken as base and RPi traditionally has had non-mainline kernel patches because the Broadcom STB chips have multiple UARTs and depending on whether Bluetooth is used or not, names/usage is swapped. They use ‘serial0’, but it might be mapped to the wrong HW block. I had many troubles with it on Pi0 I remember. The newer and more capable Pi SoCs have many UARTs, but because of that older ‘serial0’ there is more trouble than benefits. My way of working is disable BT in HW via config.txt so the (main) linux kernel has/sees a more clean HW, same as a VM environment is presenting. On the Pi5, there is yet another port with a special connector, that also requires extra thinking how and what to map on pins etc.
On vanilla Debian (not the RPi patched RPiOS) you get ttyS0, and it simply works. I have multiple brands SBC’s, several different SoC’s, /dev/ttyS0 is the one to use in scripts etc when you want primary console.