qemu: no ha-cli in headless mode

[532910]

Describe the issue you are experiencing

I run HAOS from haos_ova-11.5.qcow2
On ttyS0 it starts it prints kernel log and starts agetty.
On tty1 it prints boot log and starts ha-cli.

1. I'd like to run ha-cli on ttyS0 or even on both: ttyS0 and tty1
2. agetty login has no reason on ttyS0

What operating system image do you use?

generic-x86-64 (Generic UEFI capable x86-64 systems)

What version of Home Assistant Operating System is installed?

11.5

Did you upgrade the Operating System.

Yes

Steps to reproduce the issue

...

Anything in the Supervisor logs that might be useful for us?

no

Anything in the Host logs that might be useful for us?

no

System information

System Information

version	core-2024.2.2
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.12.1
os_name	Linux
os_version	6.1.74-haos
arch	x86_64
timezone	Etc/UTC
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
GitHub API Calls Remaining	5000
Installed Version	1.34.0
Stage	running
Available Repositories	1468
Downloaded Repositories	11
HACS Data	ok

Home Assistant Cloud

logged_in	false
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 11.5
update_channel	stable
supervisor_version	supervisor-2024.01.1
agent_version	1.6.0
docker_version	24.0.7
disk_total	30.8 GB
disk_used	8.9 GB
healthy	true
supported	true
board	ova
supervisor_api	ok
version_api	ok
installed_addons	Piper (1.4.0), Whisper (1.0.2), openWakeWord (1.8.2), ESPHome (2023.12.9), Terminal & SSH (9.9.0), Matter Server (5.1.2)

Dashboards

dashboards	5
resources	6
views	11
mode	storage

Recorder

oldest_recorder_run	February 9, 2024 at 12:31
current_recorder_run	February 20, 2024 at 06:26
estimated_db_size	214.18 MiB
database_engine	sqlite
database_version	3.44.2

Additional information

No response

[sairon]

Currently getty is started on serial (ttyS0) via the standard systemd flow, while tty1 (graphical console) is handled by a special service ha-cli@.service with the default instance set to tty1. I don't think it's possible to set multiple default instances, moreover other platforms are implemented different, so it may not be applicable universally. May I ask what is the use case? Even on the serial console without ha-cli as the default shell, you can simply use ha commands.

[532910]

OK, if is't impossible to set multiple default instances the single one will be enough.

1. getty on ttyS0 is completely useless: it's impossible to login there
2. ha-cli@.service on graphical console is completely useless: what is the reason to run qemu with videocard, while serial console is enough

instead of two completely useless things I'd like to have only one, but useful: ha-cli@.service on ttyS0. No ha-cli on tty0, no getty on ttyS0, only one ha-cli on ttyS0

[532910]

May I ask what is the use case to run ha-cli on graphical console?

[agners]

While I agree, it is a waste of resources to emulate a graphics card/frame buffer, believe it or not, most people actually use the graphical console on virtual machines 🙈 I also think that nowadays the resources used by a graphical console are negligible by the grand scheme of things. And there are still OSes which only have graphical consoles, so I guess it just has become the standard 🤷‍♂️

That said, the question here is weather to start the HA CLI shell by default on the serial console as well. I'll create a main response to address that.

[github-actions[bot]]

There hasn't been any activity on this issue recently. To keep our backlog manageable we have to clean old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant OS version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[532910]

stale is not a reason to close issues

[agners]

Technically, this is not an issue, but a feature request/discussion. So I've converted the issue to a GitHub discussion.

[agners]

There are actually three ways to access the HAOS shell:

1. Graphical consoles (tty0/tty1...)
2. Serial console (on OVA, Yellow via USB-C)
3. SSH on port 22222 via public key authentication

Now, only graphical console on tty0 actually starts the HA CLI shell. All other cases just the bare (Busybox ash) shell.

That said, on all consoles the HA CLI is available via the ha command. So you can still access HA commands.

Also note that the SSH/Web Terminal add-on doesn't give shell access to the OS directly, but a shell in a container. You do have access to the ha command in that shell though.

There are a few minor downsides to starting the HA CLI directly:

1. Additional resource use: Each HA CLI is a go process running using a couple of megabytes of RAM
2. People get confused: Technically they don't need to type ha <subcommand> but <subcommand> directly. Since most folks use the console from SSH/Web Terminal add-on, they are used to type the ha. We do strip it away automatically, so this is not a big issue. But to me this seems a bit a inconsistency how folks use the shells available on HA.
3. VS Code Remote Development doesn't work (Remote SSH or Dev Container, or even both, not sure)
4. Some automation frameworks don't work well in such environments (namely my attempts with Labgrid didn't work well with HA CLI). It is really neat to do automated testing with OVA images using the serial console, as no additional setup is required to gain OS level shell access.

Now there is one major upside when starting the HA CLI directly: The HA banner is printed, with that users sees the IP addresses etc. without typing a command.

Now this last argument here is the big differentiator, and the main reason things are the way they are right now: Being able to see the IP address without having to enter a command is especially helpful for devices which have only a screen attached (e.g. on a Raspberry Pi, where you might just opt to remove the keyboard normally). For the serial console this isn't really an argument, as typically you have input and output available when accessing a serial console.

I'd like to run ha-cli on ttyS0 or even on both: ttyS0 and tty1

You still can: Just use the commands with ha prefix or hassos-cli. Given this, and the reasons outlined above, I'd prefer to keep things as they are. Unless I miss something, and you have another reason you'd prefer to get the ha-cli by default?

[agners]

Thinking about this a bit more, maybe more consistency here would be nice: How about always show the banner, but not drop into a CLI anywhere? 🤔

While at it, we should also allow root passwords and not auto-login.

[532910]

This issues was mainly about qemu: I don't want to have video enabled on haos guest, but I want to have full log and cli. And right now serial in qemu only shows grub, kernel messages and useless haos login.