Login prompt on HDMI (tty1) no longer visible after upgrading from customized Torizon OS 7.4.0 to customized Torizon OS 7.5.0 (and later)

Technical Support
, ,
1

Setup:

  • Apalis iMX8QM 4GB IT
  • Ixora Carrier Board v1.3A
  • HDMI screen connected
  • Torizon OS 7.4.0+build.28 (for Apalis iMX8) customized with Torizon Core Builder as per below.

and

  • Apalis iMX8QM 4GB IT
  • Ixora Carrier Board v1.3A
  • HDMI screen connected
  • Torizon OS 7.5.0+build.30 (for Apalis iMX8) customized with Torizon Core Builder as per below.

Torizon Core Builder customization

  • Version Torizon Core Builder image: torizon/torizoncore-builder:3.15.0

  • Using torizoncore-builder build

  • Customization section in tcbuild.yaml:

    customization:
    kernel:
    arguments:
    - console=tty1
    - console=ttyLP1,115200
    - fbcon=map:0
    - vt.global_cursor_default=1

Issue:

In the original setup (using Torizon OS 7.4.0 as base) I get a login prompt on the HDMI screen from the getty@tty1 service as wanted.

In the new setup (using Torizon OS 7.5.0 as base) I do not get a login prompt on the HDMI screen anymore. Also on later quarterly releases (7.6.1 and 7.7.0) I observe this behavior.

From my perspective, this appears to be some regression between 7.4.0 and 7.5.0.

I observed on 7.5.0 on start the getty@tty1 service is running, but not displaying on the HDMI. And that (manually) starting/stopping getty@tty0 restarts getty@tty1 as well and afterwards provides a login prompt (tty1) as HDMI. However I would prefer not to use this as a workaround.

torizon@apalis-imx8-08734975:~$ sudo systemctl stop getty@tty0
torizon@apalis-imx8-08734975:~$ journalctl | grep getty
Aug 11 10:20:46 apalis-imx8-08734975 systemd[1]: Created slice Slice /system/getty.
Aug 11 10:20:46 apalis-imx8-08734975 systemd[1]: Created slice Slice /system/serial-getty.
Aug 11 10:22:49 apalis-imx8-08734975 sudo[1121]:  torizon : TTY=ttyLP1 ; PWD=/var/rootdirs/home/torizon ; USER=root ; COMMAND=/usr/bin/systemctl start getty@tty0
Aug 11 10:22:54 apalis-imx8-08734975 systemd[1]: getty@tty1.service: Deactivated successfully.
Aug 11 10:22:55 apalis-imx8-08734975 systemd[1]: getty@tty1.service: Scheduled restart job, restart counter is at 1.
Aug 11 10:23:00 apalis-imx8-08734975 systemd[1]: getty@tty0.service: Deactivated successfully.
Aug 11 10:23:00 apalis-imx8-08734975 systemd[1]: getty@tty0.service: Scheduled restart job, restart counter is at 1.
Aug 11 10:23:03 apalis-imx8-08734975 sudo[1133]:  torizon : TTY=ttyLP1 ; PWD=/var/rootdirs/home/torizon ; USER=root ; COMMAND=/usr/bin/systemctl stop getty@tty0
Aug 11 10:23:03 apalis-imx8-08734975 systemd[1]: getty@tty0.service: Deactivated successfully.
Aug 11 10:23:03 apalis-imx8-08734975 systemd[1]: getty@tty1.service: Deactivated successfully.
Aug 11 10:23:03 apalis-imx8-08734975 systemd[1]: getty@tty1.service: Scheduled restart job, restart counter is at 2.

Questions:

  • What has been changed between 7.4.0 and 7.5.0 (and later) that cause this change in behavior?
  • How can I get the login prompt on the HDMI screen working again in 7.5.0 (and later) without workaround?

Note: My objective is to upgrade to the latest quarterly release, and (if possible) stay up-to-date.

Please let me know further if logs are needed to investigate/pinpoint the issue.

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

Based on your detailed description, this appears to be a regression in how the console and framebuffer are initialized between Torizon OS 7.4.0 and 7.5.0 for the Apalis iMX8QM.

Analysis of Your Configuration

Your kernel arguments configuration looks correct for enabling console output on tty1 (HDMI):

customization:
  kernel:
    arguments:
      - console=tty1
      - console=ttyLP1,115200
      - fbcon=map:0
      - vt.global_cursor_default=1

The fact that stopping getty@tty0 triggers getty@tty1 to restart and then display correctly suggests a timing or initialization order issue with the framebuffer console between versions.

Potential Solutions

1. Adjust Kernel Argument Order

Try reordering your console arguments to prioritize tty1:

customization:
  kernel:
    arguments:
      - console=ttyLP1,115200
      - console=tty1
      - fbcon=map:0
      - vt.global_cursor_default=1

The last console= argument typically becomes the primary console, which might help with the initialization sequence.

2. Force Framebuffer Console Initialization

You could try adding explicit framebuffer console parameters:

customization:
  kernel:
    arguments:
      - console=tty1
      - console=ttyLP1,115200
      - fbcon=map:0
      - fbcon=font:VGA8x16
      - vt.global_cursor_default=1

3. Investigate System Logs

To better understand what changed, please collect and compare:

  • dmesg | grep -i "console\|tty\|fb" on both 7.4.0 and 7.5.0
  • systemctl status getty@tty1 immediately after boot on 7.5.0
  • Check if there are differences in device tree or display initialization timing

4. Check Release Notes

I recommend reviewing the release notes between 7.4.0 and 7.5.0 for any changes related to console initialization, framebuffer handling, or systemd service ordering that might explain this behavior.

Unfortunately, the available documentation doesn’t contain specific information about this regression or changes to console initialization between these versions. I suggest:

  1. Testing the kernel argument adjustments above
  2. Collecting the diagnostic logs mentioned
  3. Reporting this issue to Toradex support with your findings, as this appears to be a genuine regression that may require investigation at the distribution level

You may find relevant discussions on the Toradex Community by searching for “getty tty1 7.5.0” or similar terms.

Best regards,
Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Both the suggested solutions (switching order of console arguments, and adding the fbcon=font:VGA8x16 argument) did not resolve the issue.

For further inspection I have collected the proposed logs (including switching the order of the console arguments). From my understanding, no differences theres.

7.4.0

torizon@apalis-imx8-08734975:~$ dmesg | grep -i "console\|tty\|fb"
[    0.000000] OF: reserved mem: 0x00000000c0000000..0x00000000fbffffff (983040 KiB) map reusable linux,cma
[    0.000000] Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/3e4f244de16b51393a7b12e8780244dd314bae833d3f70bdc7060bc8f0579155/0 console=ttyLP1,115200 console=tty1 fbcon=map:0 vt.global_cursor_default=1
[    0.000889] Console: colour dummy device 80x25
[    0.000900] printk: console [tty1] enabled
[    0.863502] 5a060000.serial: ttyLP0 at MMIO 0x5a060010 (irq = 61, base_baud = 5000000) is a FSL_LPUART
[    0.864537] 5a070000.serial: ttyLP1 at MMIO 0x5a070010 (irq = 62, base_baud = 5000000) is a FSL_LPUART
[    0.864667] printk: console [ttyLP1] enabled
[    0.865860] 5a080000.serial: ttyLP2 at MMIO 0x5a080010 (irq = 63, base_baud = 5000000) is a FSL_LPUART
[    0.866882] 5a090000.serial: ttyLP3 at MMIO 0x5a090010 (irq = 64, base_baud = 5000000) is a FSL_LPUART
[    4.328610] systemd[1]: Created slice Slice /system/getty.
[    4.332475] systemd[1]: Created slice Slice /system/serial-getty.
[    4.443917] systemd[1]: Starting Virtual Console Setup...
[    7.027886] ahci-imx 5f020000.sata: flags: 64bit ncq sntf pm clo only pmp fbs pio slum part ccc sadm sds apst
[    7.028791] Console: switching to colour frame buffer device 240x67
[    7.028822] imx-drm display-subsystem: [drm] fb0: imx-drmdrmfb frame buffer device
[   18.864579] usb 4-1: SerialNumber: 010176d5a572d8dc0253b0afb98bfb9d50400cfa5679d5a9e69d8e5f8d04d29e4b7b00000000000000000000858b9ba0ff9e7500915581076d302386

torizon@apalis-imx8-08734975:~$ systemctl status getty@tty1
* getty@tty1.service - Getty on tty1
     Loaded: loaded (/usr/lib/systemd/system/getty@.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-08-11 11:20:26 UTC; 1min 12s ago
       Docs: man:agetty(8)
             man:systemd-getty-generator(8)
             https://0pointer.de/blog/projects/serial-console.html
   Main PID: 1054 (agetty)
      Tasks: 1 (limit: 3279)
     Memory: 304.0K (peak: 1.7M)
        CPU: 55ms
     CGroup: /system.slice/system-getty.slice/getty@tty1.service
             `-1054 /sbin/agetty -o "-p -- \\u" --noclear - linux

Aug 11 11:20:26 apalis-imx8-08734975 systemd[1]: Started Getty on tty1.

7.5.0

torizon@apalis-imx8-08734975:~$ dmesg | grep -i "console\|tty\|fb"
[    0.000000] OF: reserved mem: 0x00000000c0000000..0x00000000fbffffff (983040 KiB) map reusable linux,cma
[    0.000000] Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/355a9292db51ac073efe0f4bd0d04594b90533e9a5a643f6338ca91f7086d93a/0 console=ttyLP1,115200 console=tty1 fbcon=map:0 vt.global_cursor_default=1
[    0.000899] Console: colour dummy device 80x25
[    0.000910] printk: console [tty1] enabled
[    0.872213] 5a060000.serial: ttyLP0 at MMIO 0x5a060010 (irq = 61, base_baud = 5000000) is a FSL_LPUART
[    0.873255] 5a070000.serial: ttyLP1 at MMIO 0x5a070010 (irq = 62, base_baud = 5000000) is a FSL_LPUART
[    0.873380] printk: console [ttyLP1] enabled
[    0.874573] 5a080000.serial: ttyLP2 at MMIO 0x5a080010 (irq = 63, base_baud = 5000000) is a FSL_LPUART
[    0.875592] 5a090000.serial: ttyLP3 at MMIO 0x5a090010 (irq = 64, base_baud = 5000000) is a FSL_LPUART
[    4.340303] systemd[1]: Created slice Slice /system/getty.
[    4.344156] systemd[1]: Created slice Slice /system/serial-getty.
[    4.464937] systemd[1]: Starting Virtual Console Setup...
[    6.894022] Console: switching to colour frame buffer device 240x67
[    6.894105] imx-drm display-subsystem: [drm] fb0: imx-drmdrmfb frame buffer device
[    7.241920] ahci-imx 5f020000.sata: flags: 64bit ncq sntf pm clo only pmp fbs pio slum part ccc sadm sds apst
[   19.435646] usb 4-1: SerialNumber: 010176d5a572d8dc0253b0afb98bfb9d50400cfa5679d5a9e69d8e5f8d04d29e4b7b00000000000000000000858b9ba0ff9e7500915581076d302386

torizon@apalis-imx8-08734975:~$ systemctl status getty@tty1
* getty@tty1.service - Getty on tty1
     Loaded: loaded (/usr/lib/systemd/system/getty@.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-08-11 11:09:30 UTC; 2min 10s ago
       Docs: man:agetty(8)
             man:systemd-getty-generator(8)
             https://0pointer.de/blog/projects/serial-console.html
   Main PID: 1091 (agetty)
      Tasks: 1 (limit: 3279)
     Memory: 188.0K (peak: 792.0K)
        CPU: 16ms
     CGroup: /system.slice/system-getty.slice/getty@tty1.service
             `-1091 /sbin/agetty -o "-p -- \\u" --noclear - linux

Aug 11 11:09:30 apalis-imx8-08734975 systemd[1]: Started Getty on tty1.

No clear clue on the cause of the issue yet in my opinion. Further support is appreciated.

4

Thank you for providing those detailed logs. You’re right that the dmesg output appears nearly identical between 7.4.0 and 7.5.0, which makes this issue more puzzling. Both show the console initialization happening correctly at the kernel level.

Further Investigation Steps

Since the kernel-level initialization appears identical, the issue likely lies in the userspace initialization timing or systemd service ordering. Let me suggest some additional diagnostic steps:

1. Check Plymouth Status and Timing

Plymouth (the boot splash screen) can interfere with getty initialization. Check if there are differences in Plymouth behavior:

systemctl status plymouth-quit-wait.service
systemctl status plymouth-quit.service
journalctl -u plymouth-quit-wait.service
journalctl -u plymouth-quit.service

On Torizon OS, Plymouth services can affect when the framebuffer console becomes available to getty(1).

2. Examine Complete Boot Journal

Capture the full systemd initialization sequence to identify timing differences:

journalctl -b | grep -E "getty@tty1|fb0|Console|plymouth"

Compare this output between 7.4.0 and 7.5.0 to spot any ordering changes.

3. Check VT Allocation

Verify which virtual terminal is actually active:

fgconsole
cat /sys/class/tty/tty0/active

4. Inspect getty Service Dependencies

Check if there are dependency differences:

systemctl show getty@tty1.service | grep -E "After|Before|Requires|Wants"

5. Test Direct Console Activation

Try forcing the console switch after boot:

chvt 1

If this makes the login prompt appear, it confirms the issue is related to VT activation rather than framebuffer initialization.

Potential Workaround

While not ideal, you could create a systemd service that explicitly switches to tty1 after the framebuffer is ready. However, I understand you prefer to avoid workarounds.

Recommendation

Given that:

  • The kernel arguments are identical and correct
  • The framebuffer initialization completes successfully in both versions
  • The getty service starts correctly in both versions
  • Yet the display output differs

This strongly suggests a regression in systemd service ordering or Plymouth integration between Torizon OS 7.4.0 and 7.5.0.

I recommend reporting this to Toradex support with:

  1. Your detailed setup information (already well documented)
  2. The comparison logs you’ve collected
  3. The additional diagnostic information from the steps above

This appears to be a distribution-level issue that requires investigation by the Toradex team, as it’s not something that can be resolved through standard configuration changes.

You may also find relevant discussions on the Toradex Community by searching for “tty1 7.5.0 regression” or similar terms.

Best regards,
Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

5

Greetings @mtimmer,

I was able to reproduce your issue here exactly as you’ve described it. I did my tests on the latest 7.7.0 release so it still seems to be the case today.

I think I’ve partially solved the problem. I restarted getty@tty0 as you described to get the virtual console on HDMI to work. That’s when I noticed next to the login prompt on the HDMI console it’s tty0 not tty1. While the serial console is still tty1. This is why restarting getty@tty0 “fixes” the HDMI console since that’s the tty it happens to be using. I assume this is the case for you as well where the HDMI console is using tty0. If you could confirm that would be helpful.

However, I still don’t know what caused the virtual console on HDMI to be on tty0 instead of tty1 now. Our Linux Reference Image that Torizon OS is based on top of, still has the HDMI console on tty1. I’ll probably need to report this internally for further analysis to see if we can identify the change that caused this. Then we need to decide what to do after that.

For now, what I found works is to do sudo systemctl enable getty@tty0. This will enable it by default, you should be able to capture the change with TorizonCore Builder via the isolate command. That way you have a customized image that has this enabled by default.

I’ll try to inform you if we have any updates. Thank you for bringing this to our attention.

Best Regards,
Jeremias

6

Hello @jeremias.tx

Thank you for picking this up.

I think I’ve partially solved the problem. I restarted getty@tty0 as you described to get the virtual console on HDMI to work. That’s when I noticed next to the login prompt on the HDMI console it’s tty0 not tty1. While the serial console is still tty1. This is why restarting getty@tty0 “fixes” the HDMI console since that’s the tty it happens to be using. I assume this is the case for you as well where the HDMI console is using tty0. If you could confirm that would be helpful.

On 7.5.0, after (re)starting getty@tty0, I also observed tty0 on the HDMI console like you describe. But then, after about 5-10 seconds it switches to tty1 at the HDMI. So now tty1 is actually visible.

Looking in the logs shows that (re)starting getty@tty0 also forces getty@tty1 to be restarted, and as it seems somehow causes it to be displayed on the HDMI this time.

As workaround, I am ok with starting getty@tty0 and isolating the change.
Though I am absolutely interested in updates on this topic.

Kind regards,
Marco

7

But then, after about 5-10 seconds it switches to tty1 at the HDMI. So now tty1 is actually visible.

Interesting, I double-checked my setup and this doesn’t happen to me on 7.7.0. On HDMI I still see tty0 after several minutes of letting the system run idle. Are you doing anything on the HDMI console? Or do you just let it run idle and it “switches” on it’s own.

Looking in the logs shows that (re)starting getty@tty0 also forces getty@tty1 to be restarted, and as it seems somehow causes it to be displayed on the HDMI this time.

I noticed this too, but in theory then you could just restart only getty@tty1. But, only restarting this without restarting getty@tty0 doesn’t seem to actually do anything for the HDMI console.

As workaround, I am ok with starting getty@tty0 and isolating the change.
Though I am absolutely interested in updates on this topic.

We’ll try to let you know if we happen to find any updates regarding this.

Best Regards,
Jeremias

9

I also observe on 7.7.0 that first tty0 gets displayed on the HDMI, and then after ~5 seconds tty1.
My steps:

  • Reboot
  • Make SSH connection
  • Via SSH connection, start tty0

Looking at the logs, I see that this causes tty1 to be stopped/restarted.

torizon@apalis-imx8-15630234:~$ sudo systemctl start getty@tty0
Password:
torizon@apalis-imx8-15630234:~$ journalctl | tail -n 15
Aug 18 12:19:27 apalis-imx8-15630234 kernel: audit: type=1327 audit(1787055567.220:59): proctitle=737368643A20746F72697A6F6E205B707269765D
Aug 18 12:19:27 apalis-imx8-15630234 audit: BPF prog-id=18 op=UNLOAD
Aug 18 12:19:27 apalis-imx8-15630234 audit: BPF prog-id=17 op=UNLOAD
Aug 18 12:19:27 apalis-imx8-15630234 audit: BPF prog-id=16 op=UNLOAD
Aug 18 12:19:27 apalis-imx8-15630234 kernel: audit: type=1334 audit(1787055567.660:60): prog-id=18 op=UNLOAD
Aug 18 12:19:27 apalis-imx8-15630234 kernel: audit: type=1334 audit(1787055567.660:61): prog-id=17 op=UNLOAD
Aug 18 12:19:27 apalis-imx8-15630234 kernel: audit: type=1334 audit(1787055567.660:62): prog-id=16 op=UNLOAD
Aug 18 12:19:41 apalis-imx8-15630234 sudo[1101]:  torizon : TTY=pts/0 ; PWD=/var/rootdirs/home/torizon ; USER=root ; COMMAND=/usr/bin/systemctl start getty@tty0
Aug 18 12:19:41 apalis-imx8-15630234 systemd[1]: Started Getty on tty0.
Aug 18 12:19:46 apalis-imx8-15630234 systemd[1]: getty@tty1.service: Deactivated successfully.
Aug 18 12:19:46 apalis-imx8-15630234 systemd[1]: getty@tty1.service: Scheduled restart job, restart counter is at 1.
Aug 18 12:19:46 apalis-imx8-15630234 systemd[1]: Started Getty on tty1.
Aug 18 12:19:51 apalis-imx8-15630234 systemd[1]: getty@tty0.service: Deactivated successfully.
Aug 18 12:19:51 apalis-imx8-15630234 systemd[1]: getty@tty0.service: Scheduled restart job, restart counter is at 1.
Aug 18 12:19:51 apalis-imx8-15630234 systemd[1]: Started Getty on tty0.
10

I also observe on 7.7.0 that first tty0 gets displayed on the HDMI, and then after ~5 seconds tty1.

Huh strange, I don’t see this on my end. For me on HDMI it stays at tty0 the whole time. I wonder what causes this behavior on your setup.

Well in any case I’ve reported this behavior change of the tty to our team. They will investigate this when they are able to.

Best Regards,
Jeremias