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
Best to use following commands to check boot sequence and time needed per step
systemd-analyze blame
systemd-analyze critical-chain
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
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.
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.
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.
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.
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.
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