noble server and xfce fail to start up properly on RPi5

[Janos Szigetvari]

Hello!

 

I have an RPi5 8GB board that I bought off of AliExpress, along with a Waveshare PoE M.2 HAT+ ( https://www.waveshare.com/poe-m.2-hat-plus-b.htm )

Initially I tried to use the Noble XFCE image, by following the recommended installation procedure via rpi-imager via a USB drive, hoping to install the system to a Toshiba (Kioxia) NVMe drive.

The RPI5 was connected to a CrowView Note.

 

What I saw was that the firmware loaded up the necessary files from the USB drive (then later the micro-SD card), and the initramfs loaded up too, then systemd started up, and probably when the screen usually goes blank for a short time (probably switching to KMS), here, the signal completely drops, and apparently nothing happens.

(The messages scroll too fast, and then disappear, and I can't make out anything from the screen content.)

I tried looking on the network to see whether the RPi5 comes up at all, but no.

Since then, I tried to eliminate elements from my setup to see whether that makes any difference:

• I removed the Waveshare HAT
• Swtiched to using a micro-SD card instead of the USB thumb drive
• Tried to boot it without the CrowView Note
• Tried using the Noble Server image to eliminate any possible problems with the graphical UI 

but none of these helped.

I now have the bare RPi5 with an active heatsink, and it's still not booting properly.

What should I try? Should I try to get serial console working so that I at least see the boot messages?

Is there an activity LED on the RPI5 where I could at least configure a heartbeat so that I could check whether the OS is alive at all?

 

Since the OS can't be installed, I can't really submit much diagnostic information.

[Janos Szigetvari]

All the while the Raspberry PI OS (version September 2025) has booted out of the box on the board itself.

I will check it with with the HAT added too.

[Janos Szigetvari]

I can report back that the above mentioned HAT works well well with the Kioxia SSD I have.

So this problem very likely has something to do with armbian, and is not hardware related.

[Janos Szigetvari]

The Trixie-based XFCE image seems to work fine too, so only the Noble-based images seem to be broken.

[Janos Szigetvari]

Any comments on this would be welcome.

[laibsch]

Providing logs with 

armbianmonitor -u

 helps with troubleshooting and significantly raises chances that issue gets addressed.

[Janos Szigetvari]

@laibsch Thanks for the suggestion, but I wasn't able to actually get a login prompt, or start up a shell as a result of this problem. (No UI or virtual console was visible or accessible.)

[laibsch]

Then it is time to follow http://debug.armbian.de

[Janos Szigetvari]

@laibsch Hmmm, the current latest image seems to work OK.
On the other hand, I tried to get the serial console working, but I did not manage to do so.

I used an FTDI-based cable ( https://ftdichip.com/wp-content/uploads/2020/07/DS_TTL-232R_RPi.pdf ) with the recommended connection diagram, but nothing ever showed up on minicom's output. (It always showed it as Offline, and not even a single byte came through)
I tried 9600 and 115200 baud for minicom, and also set `dtoverlay=uart0` in config.txt at some point. But neither helped in any way.

[c0rnelius]

The /boot/firmware/cmdline.txt requires: console=serial0,115200 

The /boot/firmware/config.txt requires: enable_uart=1

 

That's it.

 

[Janos Szigetvari]

@c0rnelius Thanks for stepping in to help.

I've added enable_uart=1 to config.txt

In cmdline.txt, I currently have:

console=serial0,115200 console=tty1 ...

Do the two settings work in tandem, or do they override each other?

[Janos Szigetvari]

Okay, I tested, but it works kind of weird: they work in tandem, but the boot messages were only output to the video console, not on the serial one.
Once after the initial automatic login, the output started to go to both consoles, but the initial and systemd boot messages were only output to the video console, which would have made sharing the details of the initial problem difficult.

[Janos Szigetvari]

Furthermore, I found the following:

• I used the noble xfce image from 2025-08-08
• The serial console (login console, not boot console!) worked initially
• After the install, I did an apt-upgrade, and also used raspi-config to enable the serial console
• After that, the systemd console service seems to have moved from ttyAMA0 to ttyAMA10, and I am gettin no output in minicom

So I have mixed feelings.

[c0rnelius]

 

5 hours ago, Janos Szigetvari said:

made sharing the details of the initial problem difficult.

 

 Give serial priority

console=tty1 console=serial0,115200

 

[c0rnelius]

21 minutes ago, Janos Szigetvari said:

ttyAMA0 to ttyAMA10,

 

Without it being enabled in the config.txt file `ttyAMA0` isn't visible under /dev, last I checked.

 

pibox: ~  $ cat /boot/firmware/config.txt | grep "enable_uart*"
enable_uart=1
pibox: ~  $ ls /dev/ttyAMA*
/dev/ttyAMA0  /dev/ttyAMA10

 

I wouldn't use `raspi-config` on an img that isn't RASPIOS. I feel that is bound to produce failure. 

 

[Janos Szigetvari]

49 minutes ago, c0rnelius said:

I wouldn't use `raspi-config` on an img that isn't RASPIOS. I feel that is bound to produce failure. 

 

Yes, I kind of reached the same conclusion, unfortunately. BTW, does it have any mode, where it would do a dry run, and tell you what it would modify?

 

As for ttyAMA0, I don't seem to have it, even though have the UART enabled in config.txt:

 

The priority increase seems to work, in the sense that serial now likely has the upper hand, but the system is not booting, so something is likely not working.
I will try reverting the console priority.

[c0rnelius]

I installed a fresh Trixie img to SD, made the adjustments I suggested, booted, upgraded and rebooted.

 

root@rpi5b:~# ls /dev/ttyAMA*
/dev/ttyAMA0  /dev/ttyAMA10

 

Still there.

 

[Janos Szigetvari]

I am using the Noble image.

I have added the following entries to config.txt:

usb_max_current_enable=1
enable_uart=1
dtoverlay=uart0
dtparam=pciex1
dtparam=pciex1_gen=3
max_current_enable=1
dtoverlay=disable-wifi
dtoverlay=disable-bt 

 

I now have both ttyAMA* devices.
As the next step, I tried to remove the ttyAMA10 getty and add a ttyAMA0 one:

systemctl disable serial-getty@ttyAMA10
systemctl enable --now serial-getty@ttyAMA0

 

But it doesn't seem to work. I'm still not seeing any activity in minicom. (It worked right after installation, and I haven't touched the wiring since.)

Edited yesterday at 02:46 PM by Janos Szigetvari

[c0rnelius]

Same deal using Noble; https://paste.armbian.com/orexafoxen.less

 

[Janos Szigetvari]

Well, that's strange, and thus I am a bit confused.

I retried a few times: flashed Armbian_25.8.1_Rpi4b_noble_current_6.12.41_xfce_desktop.img.xz onto a micro-SD card in a UGREEN SD-card reader. I tried both rpi-imager and plain old dd.

I am using a WCH340-based USB-serial adapter (came from the Pine64 webshop) wired up apparently correctly (see the attached photo).

(I believe that my initial problem may have been caused by the rpi-imager custiomization settings, that I thought were supported with the Armbian image too.) Since then I stopped using those customization settings.

The system now boots OK, the GUI comes up, but I'm still not seeing anything in the minicom screen.
My config.txt settings are still:

usb_max_current_enable=1
enable_uart=1
dtoverlay=uart0
dtparam=pciex1
dtparam=pciex1_gen=3
max_current_enable=1
dtoverlay=disable-wifi
dtoverlay=disable-bt 

 

I now have both ttyAMA0 and ttyAMA10 devices:

root@rpi5b:~# ls -l /dev/ttyAMA*
crw-rw---- 1 root dialout 204, 64 nov    7 12:16 /dev/ttyAMA0
crw--w---- 1 root tty     204, 74 nov    7 12:57 /dev/ttyAMA10
root@rpi5b:~# systemctl status serial-getty@ttyAMA10.service 
● serial-getty@ttyAMA10.service - Serial Getty on ttyAMA10
     Loaded: loaded (/usr/lib/systemd/system/serial-getty@.service; enabled-runtime; preset: enabled)
    Drop-In: /usr/lib/systemd/system/serial-getty@.service.d
             └─10-term.conf
     Active: active (running) since Fri 2025-11-07 12:57:12 CET; 1h 49min ago
       Docs: man:agetty(8)
             man:systemd-getty-generator(8)
             https://0pointer.de/blog/projects/serial-console.html
   Main PID: 2714 (agetty)
      Tasks: 1 (limit: 9411)
     Memory: 200.0K (peak: 1.7M)
        CPU: 12ms
     CGroup: /system.slice/system-serial\x2dgetty.slice/serial-getty@ttyAMA10.service
             └─2714 /sbin/agetty -o "-p -- \\u" --keep-baud 115200,57600,38400,9600 - linux

nov 07 12:57:12 rpi5b systemd[1]: serial-getty@ttyAMA10.service: Scheduled restart job, restart counter is at 1.
nov 07 12:57:12 rpi5b systemd[1]: Started serial-getty@ttyAMA10.service - Serial Getty on ttyAMA10.
root@rpi5b:/usr/lib/systemd/system# systemctl enable --now serial-getty@ttyAMA0
Created symlink /etc/systemd/system/getty.target.wants/serial-getty@ttyAMA0.service → /usr/lib/systemd/system/serial-getty@.service.
root@rpi5b:/usr/lib/systemd/system# systemctl restart serial-getty@ttyAMA0
root@rpi5b:/usr/lib/systemd/system# fuser -c /dev/ttyAMA0 
/dev/ttyAMA0:           42rc  3040m  4999
root@rpi5b:/usr/lib/systemd/system# ps auxfw | fgrep 4999
root        5013  0.0  0.0   9040  2108 pts/4    S+   14:50   0:00                  \_ grep -F --color=auto 4999
root        4999  0.0  0.0   8192  1956 ttyAMA0  Ss+  14:49   0:00 /sbin/agetty -o -p -- \u --keep-baud 115200,57600,38400,9600 - linux
root@rpi5b:/usr/lib/systemd/system# systemctl restart serial-getty@ttyAMA10
root@rpi5b:/usr/lib/systemd/system#

 

And in the end, nothing seems to be happening when I start the new getty on AMA0 or restart the old one on AMA10.
I am puzzled.

[c0rnelius]

Does it work when you remove that HAT?

[Janos Szigetvari]

@c0rnelius I will try that too, along with some other ideas that I came across. I won't have time to work on this during the weekend, but I will get back to you early next week.

Appreciate your patience!

[c0rnelius]

1 hour ago, Janos Szigetvari said:

I will try that too, along with some other ideas that I came across. I won't have time to work on this during the weekend, but I will get back to you early next week.

 

Ok.

 

Also I think these are wrong for the PI5:

dtoverlay=disable-wifi

dtoverlay=disable-bt

 

I believe it's:

dtoverlay=disable-wifi-pi5
dtoverlay=disable-bt-pi5

 

My notes on this:

# Pi3 / ZERO2W

dtoverlay=pi3-disable-wifi
dtoverlay=pi3-disable-bt

 

# PI5

dtoverlay=disable-wifi-pi5
dtoverlay=disable-bt-pi5

 

# Everything else

dtoverlay=disable-wifi
dtoverlay=disable-bt

 

Back in the day, I read somewhere that Bluetooth can inhibit serial from functioning correctly on the Pi's. I've never seen it happen, but maybe using the wrong overlay is hindering it in some way? Worth looking into.