DietPi on BananaPi M5 bootdelay when headless

General Discussion
1

At the moment I still have have a tiny server with a bunch of containers running on a Nanopi Neo 3.
It’s performance is still OK, but adding more containers could run into performance or memory restrictions.
I also had a Banana Pi M5 laying around, but had no actual need for it until now. I had bought it becuase it seemed attractive:

  • 16Gb EMMC
  • 4GB Memory
  • a bit more powerfull than the NPN3
    So today I created a Dietpi version for this board.
    Of course I ran into problems like “invalid certificates” “expired certificates” etc but could solve that using de sub-shell during the conversion by:
  • adjusting the system time to the proper one with: dpkg-reconfigure tzdata
  • adjust the sources.list files to a working mirror (this happend a few times along the way, also during the 1st real DietPi boot update run)
    The most time consuming was when the script timed out with the messag: A dependency job for serial-getty@ttyS0.service failed
    During the hardware conversion 8 tty’s were found(?) to be converted? But in the end I disabled/masked all of them manually modifying each sytemctrl start getty@ttySx command to disable and resume. But every tty took its time to time-out.
    Anyway, in the end it I succeeded to have I regular Dietpi verion running on the Bananapi M5.

Still one thing bothers me: I use it headless, but I have not found a way to disable de display drivers yet.
When I will use it as a server I do ot intend to reboot it often, but rebooting the system takes more then a few minutes because the boot sequense tries to initialise but cannot gpu and or other drivers. How do I know?
On the debug console the following meson-drm messages appeared:

[    1.623367] meson-drm ff900000.vpu: DSI transceiver device is disabled
[    5.511965] panfrost ffe40000.gpu: error -ENODEV: _opp_set_regulators: no regulator (mali) found
[   15.838354] meson-drm ff900000.vpu: [drm] *ERROR* flip_done timed out
[   15.838373] meson-drm ff900000.vpu: [drm] *ERROR* [CRTC:43:meson_crtc] commit wait timed out
[   26.078362] meson-drm ff900000.vpu: [drm] *ERROR* flip_done timed out
[   26.078378] meson-drm ff900000.vpu: [drm] *ERROR* [CONNECTOR:33:Composite-1] commit wait timed out
[   36.318362] meson-drm ff900000.vpu: [drm] *ERROR* flip_done timed out
[   36.318380] meson-drm ff900000.vpu: [drm] *ERROR* [PLANE:37:meson_primary_plane] commit wait timed out
[   46.558360] meson-drm ff900000.vpu: [drm] *ERROR* flip_done timed out
[   46.558377] meson-drm ff900000.vpu: [drm] *ERROR* [CRTC:43:meson_crtc] commit wait timed out
[   56.798337] meson-drm ff900000.vpu: [drm] *ERROR* flip_done timed out
[   56.798347] meson-drm ff900000.vpu: [drm] *ERROR* [CONNECTOR:33:Composite-1] commit wait timed out
[   67.038370] meson-drm ff900000.vpu: [drm] *ERROR* flip_done timed out
[   67.038389] meson-drm ff900000.vpu: [drm] *ERROR* [PLANE:37:meson_primary_plane] commit wait timed out
[   77.278344] meson-drm ff900000.vpu: [drm] *ERROR* flip_done timed out
[   77.278361] meson-drm ff900000.vpu: [drm] *ERROR* [CRTC:43:meson_crtc] commit wait timed out
[   87.518335] meson-drm ff900000.vpu: [drm] *ERROR* flip_done timed out
[   87.518344] meson-drm ff900000.vpu: [drm] *ERROR* [CONNECTOR:33:Composite-1] commit wait timed out
[   97.758350] meson-drm ff900000.vpu: [drm] *ERROR* flip_done timed out
[   97.758369] meson-drm ff900000.vpu: [drm] *ERROR* [PLANE:37:meson_primary_plane] commit wait timed out

After a lot of those messages and may minutes later I finally can log into the system using ssh.
From there on the system seems to run OK.

My question: how can I disable the graphical items so there is no unneeded delay during (re)boot?
In the Dietpi-config I can only change the display settings, but not disable it completely.
I have seen some remarkts about headless here: AUTO_SETUP_HEADLESS disabling GPU - #4 by RyoShinzo
But that seems to be to old and I cannot locate the items referenced there.
I have searched in the various config and/or ini files but some I don’t even have or in the ones I do have I see no reference that seems related to enable/disable the graphical hardware or display.

Any help appreciated
By the way, I used a minimal Armbian image to boot from and then ran the dietpi-conversion script

2

Best to use following commands to check boot sequence and time needed per step

systemd-analyze blame
systemd-analyze critical-chain
3

From the first command it looks like the interface and journalling mechanism is the problem, but that is different with the 2nd command.

I am quite sure that the systemd-analyze critical-chain shows the real situation. At least it lines up with what I see on the debug terminal. The grafical unit(s)/drivers timeout after a few tries. Only then the remaining kernel initialization continues.
When I can skip all graphical stuff that would be OK. Preferably just adding some lines in dietpi.txt or if needed in armbianEnv.txt
The boot.cmd refers to armbianEnv.txt. ( shouldn’t that become dietpi.txt after the conversion?)
In the boot.cmd I read the line:
setenv display_autodetect “true”
In the armbianEnv.txt file ( or the dietpi.txt) I see nothing related to this setenv option.
Maybe it’s just another setenv command that is needed, but I could not find any information about the various options availabe.

root@DietPi:~# systemd-analyze blame
1min 33.196s ifupdown-pre.service
     30.935s systemd-journal-flush.service
     10.330s ifup@eth0.service
       925ms dev-mmcblk0p1.device
       908ms systemd-random-seed.service
       416ms systemd-udev-trigger.service
       340ms keyboard-setup.service
       277ms networking.service
       266ms dpkg-db-backup.service
       212ms dietpi-preboot.service
       212ms systemd-journald.service
       160ms systemd-udevd.service
       153ms systemd-timesyncd.service
       120ms dietpi-ramlog.service
       118ms dev-hugepages.mount
       116ms dev-mqueue.mount
       115ms sys-kernel-debug.mount
       112ms fake-hwclock.service
       109ms modprobe@efi_pstore.service
       108ms systemd-modules-load.service
       106ms systemd-remount-fs.service
       106ms modprobe@dm_mod.service
       106ms modprobe@loop.service
       105ms modprobe@fuse.service
       105ms kmod-static-nodes.service
       103ms modprobe@configfs.service
        93ms systemd-sysusers.service
        82ms systemd-sysctl.service
        64ms tmp.mount
        59ms systemd-tmpfiles-setup.service
        55ms console-setup.service
        49ms systemd-tmpfiles-setup-dev.service
        48ms var-log.mount
        33ms systemd-update-utmp.service
        33ms systemd-user-sessions.service
        30ms systemd-update-utmp-runlevel.service
        20ms sys-fs-fuse-connections.mount
        16ms sys-kernel-config.mount

root@DietPi:~# systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

graphical.target @1min 45.657s
└─multi-user.target @1min 45.655s
  └─getty.target @1min 45.653s
    └─serial-getty@ttyAML0.service @1min 45.651s
      └─systemd-user-sessions.service @1min 45.565s +33ms
        └─network.target @1min 45.514s
          └─ifup@eth0.service @1min 35.180s +10.330s
            └─network-pre.target @1min 35.153s
              └─dietpi-preboot.service @1min 34.936s +212ms
                └─dietpi-ramlog.service @1min 34.784s +120ms
                  └─basic.target @1min 34.735s
                    └─sysinit.target @1min 34.721s
                      └─systemd-update-utmp.service @1min 34.576s +33ms
                        └─systemd-tmpfiles-setup.service @1min 34.472s +59ms
                          └─systemd-journal-flush.service @2.071s +30.935s
                            └─var-log.mount @1.971s +48ms
                              └─local-fs-pre.target @1.171s
                                └─systemd-tmpfiles-setup-dev.service @1.120s +49ms
                                  └─systemd-sysusers.service @1.000s +93ms
                                    └─systemd-remount-fs.service @871ms +106ms
                                      └─systemd-journald.socket @761ms
                                        └─-.mount @706ms
                                          └─-.slice @706ms
4

between these 2 services you are loosing a lot of time

and something doesn’t seems to fit on the network side.

I doubt your challange has anything todo with a grafical unit(s)/drivers timeout

Can you reboot your system and share a full system log journalctl. Pls attach as txt file as it will be quite long log.

5

After some analyzing a decided to go back to the original armbian version I had used.:
Armbian_25.5.1_Bananapim5_bookworm_current_6.12.28_minimal.img.xz
Booting this image already had the huge boot delay and similar meson vpu messages in its log files.
So I decided to use an older armbian release:
Armbian_24.11.1_Bananapim5_bookworm_current_6.6.61_minimal.img.xz
This version did not have the (re)boot-delays.
I will use that image to create a Dietpi version.
I am not sure, did not verify, but I think both versions used the same DTB’s, so the (re)boot delay was introduced in the newer armbian version. Hopefully the update/conversion will be succesfull and does not introduce the (re)boot-delay again. I’ll let you know if I succeeded.

6

Unfortunately it was as I expected: the update introduced the (re)boot -delays.
Attached the output of journalctl aftere the conversion:
Armbian_24.11.1_Bananapim5_bookworm_current_6.6.61_minimal.img.xz
to dietpi.

bpim5_journalctl4.log (74,6 KB)
I also include the same log, but then from the bare arbian661 image:
armbian661_journalctl1.log (251,1 KB)

What I see is different entries related to grapic drivers or hardware with errors or timeouts.
If needed I have also the complete terminal log from the conversion armbian661—>dietpi.

During the conversion I encountered less problems then with the previous conversion. I expect this was caused due to time setting differences. This time I had to manually set the time accurately on the armbian system using the “date” command. Other ways using armbian-config or dpkg tzdata did not work.

One strange thing remained: when setting hardware ( tty0..7) they all failed, I manually modified all failing “systemctl start serial-getty@ttyS0..7” to: systemctl disable serial-getty@ttyS0..7

Only the terminal: /dev/ttyAML0 could be enabled.

Knowing all this I think the problem I encounterd is actually an Armbian problem and not to blame to Dietpi.

The only weird thing is the failing hardware setting for the 8 tty’s. I do not see a source for so many tty’s. Maybe it is somehow related to the (re)boot-delay problem, but for now I assume it is not, because the AML0 tty seems to function ok.

With the previous conversion I also changed the console=both line in armbianEnv.txt to console=serial, so that only the serial console was passed to the kernel to use but that made no difference for the (re)boot-delay.

7

Latest findings:
it is the display stuff!
When I connect a display to the HDMI interface them boot delay is not there.
see attached log:
bpim5_journalctl5.log (50,2 KB)
So my main question remains: how do I disable or skip the display?

Maybe buying a hdmi dummy plug at alixpress is the easyiest solution. But not the best…
I think that would be really ridiculous when that is the only option. I assume that I am not the only one using a SBC headless even when it is equipped with display hardware.

8

If the problems persist with a normal Armbian image, it might be best to install the original Armbian image and report the boot behavior in the Armbian forum. Maybe they have an idea.

Small tip: if you create a report in the Armbian forum, I would avoid any reference to DietPi. Some people in the Armbian forum are not so friendly to DietPi users.

9

After finding out that the latest Armbian introduced this problem I searched the Armbian forum and found:
Long Boot Delay on Banana Pi M5 in Headless Mode - Banana Pi M5 - Armbian Community Forums
Unfortunately no signs of a sulution yet. And another user came up with the same workaround I thought up : dummy hdmi plug…
Problem solved, sort of…

1 Like
10

Just to cross-reference stuff:

I have the same issue for a couple of months and started this post in the Armbian forum: Slow boot without monitor plugged in after v25.2 update - Beginners - Armbian Community Forums

At some point I managed to find a kernel mailing list post blaming some drm implementation, see Making sure you're not a bot!

Unfortunately, there seems to be no movement at all in this matter.

11

Hi Holgi,
thanks for mentioning your thread. I had seen it myself and also concluded: solving the issue will probably never happen. So I too settled with the dummy hdmi plug as a workaround.
Now I only hope new kernels will not introduce other errors that mess up my bananapi M5 server.

12

I tried another option:

I created a minimal debian image, booted it and logged in using ssh: ( headless…)
The minimal debian version was this one:
https://dl.sd-card-images.johang.se/debians/2025-06-02/debian-bookworm-arm64-xoa4co.bin.gz

First I had the problem that an image flashed to a proper SD card ( Sandisk Ultra) didn’t boot. During reading the kernel the Bananapi failed to recognise the SDcard… I tried a lesser quality SDcard. It booted without problems…

Then after logging into the system:
apt update threw some errors:
E: Release file for http://security.debian.org/debian-security/dists/bookworm-security/InRelease is not valid yet (invalid for another 9d 19h 4min 31s). Updates for this repository will not be applied.
E: Release file for http://deb.debian.org/debian/dists/bookworm-updates/InRelease is not valid yet (invalid for another 9d 21h 3min 22s). Updates for this re

This error originates from an improper system time.

I tried to set it with: dpkg-reconfigure tzdata, but still ended up with a wrong date and some hours off.
Manually adjusting the time with something like: date -s “8 JUN 2025 17:14:00” worked.
( I don’t know how accurate this must be, but I had a time sincked clock on my desk. It appeared to be good enough)
curl was not installed on the minimal Debian image so:
apt install curl
( suggested dependencies include certificates also)
I forgot to install systemd-sysv, but that was already installed…
Then I ran the dietpi_install script:
bash -c “$(curl -sSfL ‘https://raw.githubusercontent.com/MichaIng/DietPi/master/.build/images/dietpi-installer’)”
This run without problems until the script started to change the network config. It got stuck and I could not communicate via ssh anymore.
I connected a screen and keyboard to the system and I could login again. ( So a headless install of Dietpi is not possible…)
I got the screen with the part that lost the connection to the outside world ( somewhere around line 1870 in the install-script) I tried to enable the eth0 interface from a sub-shell but that did not work. So I rebooted the system from within the sub-shell. The system came up with the message that the 1rst dietpi run had failed to complete.
I then entered the network part and enabled the ethernet interface and additionally disabled ipv6.
Then the script could reach the outside world again, continued a bit, but timed-out over the ntp server.
I reconfigured the ntp server to one more nearby and then the script continued and I could finish the dietpi_install.

All well now?
Not quite.

The working Dietpi image flashed to a Sandisk SD card didn’t boot either. I assume that the u-boot used for this image lacks the proper settings. I did not have this problem with the Armbian images before. Maybe I should use the Armbian u-boot instaed of this generic u-boot.

Another problem is that this system enabled all getty@ttySx services for ttyS0..6 but not the ttyAML0
Is that a problem? Not in normal use, but the gettyS0 fails after a while and then you cannot login into the debug console.

As long as the system is running OK that’s no problem, but you know how it goes. Sooner or later you need to login, but that’s not working anymore…

The kernel version is now: 6.1.0-37-arm64, so without the (re)boot delay due to improper graphic configuration of the kernel.
When this kernel will be updated sometime, what will happen? New and already known bugs?

Anyway. It looks promising, but there are still some things to be ironed out I guess.

Maybe someone has a suggestion how to:

  • disable the getty@ttyS0..6
  • enable the getty@ttyAML0.
  • use another u-boot e.g. the Armbian one so the board will not be picky about the SD card used.
    In the end I wan’t to use the EMMC memory, but I need an easy fallback option.

To be continued?

13

Knowing a few things now I did the following to create a headless dietpi version booting from and with rootfs on EMMC
1- Flash this Armbian image, Armbian_25.5.1_Bananapim5_bookworm_current_6.12.28_minimal.img.gz, on a regular(!) microSD card.
The Armbian version is not critical I think. But I do not know why a regular or slow MicroSD card is needed. When a good quality MicroSD cards is used reading the sd card fails when the linux kernel is loaded.
2- login to armbian, do some minimal setup, new pw /usr etc.
3- transfer the system to EMMC with: armbian-install, choose 2: boot from emmc/system emmc
this transfer takes a while…
4- remove MicroSD card and boot Armbian from EMMC
5- set proper time/date manually with: date -s “27 JUN 2025 16:20:00”
I don’t know how accurate this should be, but with a clock on your workstation it should be quite accurate.
6- start the dietpi conversion: bash -c “$(curl -sSfL ‘https://raw.githubusercontent.com/MichaIng/DietPi/master/.build/images/dietpi-installer’)”
7- select generic device when asked
8- the conversion script ran OK until it tried to set the getty@tty services
a pop-up screen appears when trying to set the getty@tty services for every tty[0..7]
then select: “change command” modify to: disable serial-getty@ttyS[1..7]
I did this manually for every single tty, every timeout takes a minute or more I guess…
After disabling ttyS7 the AML0 tty service is enabled without problems, that’s the proper tty for this board.
9- wait for the script to end the conversion process and reboot.
Mind that the ip address may change when Dietpi boots…
10- With the 1st Dietpi boot I encountered an NTP server timeout.
a popup with: config menu appeared and I configured a more local timeserver from the list.
11- the normal dietpi 1st boot continued etc.
Additional: I have a dummy HDMI plug connected on the HDMI interface so there is no bootdelay when the board is (re)booted.
Of cource when you don’t want the headless version you can connect a screen. keyboard etc.
I do not know how well this board will behave with future updates, but because I only use generic functionality, native Dietpi packages such as docker/portainer, I do not expect problems.