6

I have two computers, both running Debian Bookworm and upgraded to the same degree with the latest software installed. Both machines are configured to boot to text terminals, which they need to do before starting X.

The problem is that one computer boots to /dev/tty0 instead of /dev/tty1 which means that the xinit command that works on Computer 2 doesn't work on Computer 1.

Computer 1's kernel boots to /dev/tty0 with these permissions:

crw------- 1 ben  tty 4, 0 May 23 16:46 /dev/tty0
crw--w---- 1 root tty 4, 1 May 23 16:46 /dev/tty1
crw------- 1 ben  tty 4, 2 May 23 16:13 /dev/tty2

Computer 2's kernel boots to /dev/tty1 with these permissions:

crw--w---- 1 root tty 4, 0 May 23 05:55 /dev/tty0
crw--w---- 1 ben  tty 4, 1 May 23 16:29 /dev/tty1
crw------- 1 ben  tty 4, 2 May 23 16:13 /dev/tty2

The command to start X that works on Computer 2 but not on Computer 1 is:

xinit /home/ben/.xinitrc -- /usr/bin/X :0 vt1

User ben has no permission on Computer 1 to access tty1, so X fails with a no permission message.

To start X on Computer 1, user ben needs to change the xinit command to use vt2, and navigate to tty2 to run it.

The mystifying aspect for me is that /dev/tty1 is not available on Computer 1.

Computer 1 shows the terminals as:

Ctrl+alt+F1 gets /dev/tty0

Ctrl+alt+F2 gets /dev/tty2

Ctrl+alt+F3 gets /dev/tty3

whereas on Computer 2 shows the terminals as:

Ctrl+alt+F1 gets /dev/tty0

Ctrl+alt+F2 gets /dev/tty1

Ctrl+alt+F3 gets /dev/tty2

In an attempt to boot to /dev/tty1 on Computer 1, I added the kernel option of console=/dev/tty1. The machine froze with a blank screen and the flashing cursor at the top left. It needed a rescue-disk to rewrite the grub.cfg file and erase the option to be able to boot properly.

Systemd shows the same active and running output for [email protected] on both machines.

My query is: how to configure the machine so that /dev/tty1 appears on Computer 1, and thus have Computer 1 boot to dev/tty1 instead of to /dev/tty0?

I ask here having failed to find an answer elsewhere.

Edits: Thanks to all the respondents!

cat /proc/fb outputs the same on both machines: 0 nouveaudrmfb.

I guess I could script a change to ownership of tty0 and tty1 on boot but it feels like a workaround. No other machines here would need this.

Improve this question
4
  • On Computer 1, set the owner of /dev/tty1 to ben, and the owner of /dev/tty0 to root.
    – Cheetaiean
    May 23 at 16:59
  • I guess the graphics hardware is different. What is the output of cat /proc/fb?
    – Hauke Laging
    May 23 at 17:38
  • Just to satisfy my curiosity: why are you using the archaic xinit directly, and not startx? The latter would probably allow you to simplify the X startup command line, see man startx for details.
    – telcoM
    May 24 at 7:55
  • Yes telcoM, it is archaic and it's the result of historical use over many years here on a number of machines that all have had the same configs for a long time on debian testing so they've never been refreshed with a new installation and the configs simply persisted. I take your point about startx.
    – currawong
    May 25 at 0:37

1 Answer 1

Reset to default
5

The device node /dev/tty0 acts like a hard link to "whatever is the currently selected virtual console", although it is actually implemented within the virtual console driver code.

As a console= boot option value, /dev/tty0 means "I want to use the usual KVM physical console (with its entire set of virtual consoles) as a system console". Like you discovered, a boot option console=/dev/tty1 is not valid (on x86 hardware at least):

Normally root will own any logged-out tty devices, and a logged-in user will have ownership of their tty device assigned to them by the login process. A logout should return the tty device to the ownership of root. But if user ben has managed to get the ownership of /dev/tty0, that could mean they might be able to use it (e.g. by logging in over a SSH connection) to inject stuff into the session of whoever is logged in locally on any actual virtual console (/dev/tty[1..N]).

The ownership of /dev/tty0 should never change away from root ownership.

Can you see processes running on tty0, with fuser /dev/tty0 run as root? There should not be any normally.

Is there a [email protected] defined? If it is, that could be causing the problems: /dev/tty0 should never be used for regular logins.

Improve this answer
1
  • 1
    fuser /dev/tty0 output 763, and cat /proc/763/cmdline is bash. fuser /dev/tty1 showed no output. getty@tty0 is "loaded and active" on Computer 1, but not on computer 2. It's clear now that /dev/tty0 was defined, and enabled by systemctl. I have disabled it and now the expected behaviour of booting to /dev/tty1 has reappeared. Thank you!
    – currawong
    May 23 at 22:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .