Closed almirus closed 3 years ago
Hi folks, I've been speaking with Joulinar on the DietPi forum regarding a Radxa Zero issue running the prep script - I'm not sure if it's the same issue as is being discussed here, but the forum post is at https://dietpi.com/phpbb/viewtopic.php?p=38942 and I'm happy to run/test any betas to make sure it works fine. --Dhry
So your issue is that PREP freezes when purging dbus
? almirus didn't face that, AFAIK, but one issue was breaking network due to NetworkManager (a known issue when NetMan manages the network when running the script) uninstall, which is a later step, and then due to overwritten WiFi firmware.
Hanging tasks could be related to the above mentioned entropy issue, so please try to install those two packages first:
apt update
apt install rng-tools5 haveged
And it would be interesting to know whether it has a hardware random generator at all:
journalctl -u rngd
After installing rng-tools5 and havegd:
root@zero:/home/rock# journalctl -u rngd -- Logs begin at Sun 2021-10-10 08:07:01 UTC, end at Fri 2021-10-22 15:52:03 UTC. -- Oct 22 15:52:01 zero systemd[1]: Started Start entropy gathering daemon (rngd).
Then I installed the dev branch of the script, selected the dev branch of DietPi, chose Generic Device, chose to retain wifi functionality and began the install. Once again it froze up after the uninstall of dbus. See screenshots. showing the KiTTY window with package deletions, and the Radxa screen. The detection of the mouse continues every 60 seconds, but no additional activity after that. The start image I'm using is https://github.com/radxa/radxa-zero-images-released/releases/download/radxa-zero-v20211010/zero_debian_buster_xfce4_arm64_20211010_0810-mbr.img.gz
Dhry
I generated an image now: https://dietpi.com/downloads/images/DietPi_RadxaZero-ARMv8-Bullseye.7z Please see whether this works, especially whether it boots without the long delay until "random: crng init done". I skipped all firmware packages now, which are not present on Radxa's image either and it is unlikely that someone plugs a USB Ethernet or WiFi adapter on first boot, I guess.
If this generally works, I'm open to add general support for this SBC. Currently it shows "Generic Device" but we can add a regular hardware ID for it and also migrate the systems on next DietPi update to use the specific Radxa Zero hardware ID. It is still a bit a beta image, there is no bootloader package, the kernel is from the Radxa testing repository, the manually placed WiFi firmware files which are not attached to any package and conflict with Debian firmware packages etc, but we can keep an eye on this and migrate/update those packages on future DietPi updates as well, when they appear in the stable Radxa repo.
@MichaIng
[ 4.716960] hid-generic 0003:046D:C542.0003: input,hidraw2: USB HID v1.11 Mouse [Logitech Wireless Receiver] ...typing random keys [ 33.766010] VCC_5V: disabling ...typing random keys [ 208.550016] random: crng init done
stuck here, same as my early image https://github.com/MichaIng/DietPi/issues/4831#issuecomment-942571528
at the same time there is no image on the HDMI port
I don't know how to do the UART thing. I see nothing via HDMI so can't proceed further.
@dhry you need this cp2102 and connect with https://wiki.radxa.com/Zero/hardware/gpio 6,8,10 PIN
after restart, same ..... [ 6.440808] usb 1-1.3.2: USB disconnect, device number 6 [ 33.766046] VCC_5V: disabling [ 207.526052] random: crng init done
@dhry you need this cp2102 and connect with https://wiki.radxa.com/Zero/hardware/gpio 6,8,10 PIN
I don't have any of that, so I'll have to stand by until the HDMI is working and I can see what's happening via my monitor.
stuck here, same as my early image
Hmm quite confusing since bootloader, kernel, device tree and firmware are all untouched. The only thing that is automatically rebuilt is the initramfs. Since I don't see any systemd call in our outputs, entropy daemons have not yet a chance to fix it, so it seems to be something with the initial entropy seed. Not 100% sure but I guess this can be affected by the initramfs as well, depending on which modules are loaded.
I will extract the initrd.img-
file from the original Radxa image and upload it. You can easily replace it on your images as the boot partition is FAT and can hence be accessed from Windows and macOS hosts easily. Actually the initramfs-tools
should add a large amount of modules by default, and I cannot imaging that Radxa added additional ones only for the single initramfs build without changing the config file to have this done as well for all future builds, but we should rule it out. Probably it is also a change in the newer initramfs-tools
on Bullseye which cause the issue.
I think I found it: There is a custom script invoked on initramfs build which calculates its size and adjusts /boot/uEnv.txt
accordingly which is loaded then by the bootloader. I never saw something like this and I guess without applying this size explicitly (in boot.cmd
/boot.scr
) it would work as well, but when applying a wrong (too small) size, then it will most likely fail. And since this script uses bc
(command line calculator), which is not by default installed on DietPi, it fails.
As a quick test for you both: Could you download the uEnv.txt
and initrd.img-
from https://dietpi.com/downloads/ and replace the ones in the boot partition of your Radxa Zero image?
I also updated the image (linked above) with those two files, so that initramfs size and actual image match. If this indeed solves the issue, I'll make this persistent by installing bc
into the image for future initramfs updates. You should do the same if and once booted:
apt install bc
@MichaIng success!
` ───────────────────────────────────────────────────── DietPi v7.7.3 : 18:51 - Sun 10/24/21 ─────────────────────────────────────────────────────
LAN IP : 192.168.1.77 (wlan0) curl: (28) Resolving timed out after 3000 milliseconds ─────────────────────────────────────────────────────
DietPi Team : MichaIng (lead), Daniel Knight (founder), Joulinar (support) Image by : DietPi Core Team (pre-image: Radxa) Web : https://dietpi.com | https://twitter.com/DietPi_ Patreon Legends : Camry2731 Contribute : https://dietpi.com/contribute.html DietPi Hosting : Powered by https://myvirtualserver.com
dietpi-launcher : All the DietPi programs in one place dietpi-config : Feature rich configuration tool for your device dietpi-software : Select optimised software for installation htop : Resource monitor cpu : Shows CPU information and stats ` 💃💃💃
Nice, thanks for testing, glad that we finally found it. I full add bc
to the image then and verify that uEnv.txt
has a proper initramfs size entry after it has been built.
Just to assure again that the hardware random generator works:
systemctl status rngd
ls -l /dev/hwrng
after set chromium autostart
[ 86.515549] meson_clk_pll_set_rate: pll did not lock, trying to restore old rate 3600000000 [ 86.521892] Unable to handle kernel paging request at virtual address 00000000000f4138 [ 86.523405] paging request at virtual address 7fff000011aaea60 [ 86.526266] Mem abort info: [ 86.532004] Mem abort info: [ 86.534728] ESR = 0x96000004 [ 86.537488] ESR = 0x96000004 [ 86.540511] EC = 0x25: DABT (current EL), IL = 32 bits [ 86.543529] EC = 0x25: DABT (current EL), IL = 32 bits [ 86.548815] SET = 0, FnV = 0 [ 86.554076] SET = 0, FnV = 0 [ 86.557070] EA = 0, S1PTW = 0 [ 86.560088] EA = 0, S1PTW = 0 [ 86.563194] Data abort info: [ 86.566299] Data abort info: [ 86.569142] ISV = 0, ISS = 0x00000004 [ 86.571989] ISV = 0, ISS = 0x00000004 [ 86.575795] CM = 0, WnR = 0 [ 86.579589] CM = 0, WnR = 0 [ 86.582513] user pgtable: 4k pages, 48-bit VAs, pgdp=000000000130c000 [ 86.585445] [7fff000011aaea60] address between user and kernel address ranges [ 86.586665] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 86.586667] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 86.586668] Mem abort info: [ 86.586670] ESR = 0x96000004 [ 86.586671] Mem abort info: [ 86.586673] EC = 0x25: DABT (current EL), IL = 32 bits [ 86.586675] ESR = 0x96000004 [ 86.586676] SET = 0, FnV = 0 [ 86.586678] EC = 0x25: DABT (current EL), IL = 32 bits [ 86.586679] EA = 0, S1PTW = 0 [ 86.586680] SET = 0, FnV = 0 [ 86.586681] Data abort info: [ 86.586683] EA = 0, S1PTW = 0 [ 86.586684] ISV = 0, ISS = 0x00000004 [ 86.586685] Data abort info: [ 86.586686] CM = 0, WnR = 0 [ 86.586688] ISV = 0, ISS = 0x00000004 [ 86.586690] user pgtable: 4k pages, 48-bit VAs, pgdp=000000000428b000 [ 86.586691] CM = 0, WnR = 0 [ 86.586692] [0000000000000000] pgd=0000000000000000 [ 86.586694] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000001883000 [ 86.586697] , p4d=0000000000000000 [ 86.586698] [0000000000000000] pgd=0000000000000000 [ 86.586699] [ 86.586700] , p4d=0000000000000000 [ 86.586705] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 86.586709] Modules linked in: nls_iso8859_1 snd_soc_hdmi_codec dw_hdmi_i2s_audio snd_usb_audio brcmfmac snd_usbmidi_lib snd_hwdep brcmutil snd_rawmidi joydev uvcvideo snd_seq_device cfg80211 rfkill videobuf2_vmalloc panfrost gpu_sched meson_vdec(C) v4l2_mem2mem meson_saradc snd_soc_meson_axg_tdmout snd_soc_meson_g12a_tohdmitx videobuf2_dma_contig snd_soc_meson_axg_sound_card videobuf2_memops snd_soc_meson_axg_tdm_interface snd_soc_meson_codec_glue videobuf2_v4l2 snd_soc_meson_card_utils snd_soc_meson_axg_frddr reset_meson_audio_arb snd_soc_meson_axg_tdm_formatter videobuf2_common snd_soc_meson_axg_fifo snd_soc_core meson_dw_hdmi videodev meson_drm ac97_bus dw_hdmi snd_pcm_dmaengine mc snd_pcm drm_kms_helper snd_timer meson_canvas cec meson_rng snd display_connector soundcore drm drm_panel_orientation_quirks ip_tables x_tables autofs4 axg_audio sclk_div clk_phase rtc_meson_vrtc [ 86.586833] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G C 5.10.69-2-amlogic-g981b0a3cef #g981b0a3cef [ 86.586836] Hardware name: Radxa Zero (DT) [ 86.586841] pstate: 20000085 (nzCv daIf -PAN -UAO -TCO BTYPE=--) [ 86.586859] pc : ktime_get+0x40/0xa0 [ 86.586863] lr : ktime_get+0x48/0xa0 [ 86.586865] sp : ffff800011903e40 [ 86.586866] x29: ffff800011903e40 x28: ffff00003fd65238 [ 86.586871] x27: ffff00003fd65278 x26: ffff00003fd652b8 [ 86.586875] x25: ffff00003fd6518c x24: 7fffffffffffffff [ 86.586879] x23: 0000000000000003 x22: 0000001428cf0404 [ 86.586883] x21: 0000000000000000 x20: 0000000000000000 [ 86.586888] x19: ffff80001188da80 x18: 0000000000000000 [ 86.586892] x17: 0000000000000000 x16: 0000000000000000 [ 86.586896] x15: 000000000000013f x14: 0000000000000029 [ 86.586900] x13: ffff8000116a7000 x12: 00000000000000a3 [ 86.586904] x11: 0000000000000004 x10: 0000000000000000 [ 86.586908] x9 : ffff00003fd69700 x8 : 0000001428cefe00 [ 86.586912] x7 : 7fffffffffffffff x6 : 00000000834aab1b [ 86.586916] x5 : 00ffffffffffffff x4 : 00394602317f1404 [ 86.586920] x3 : 0000000000000018 x2 : 0000000000009ed8 [ 86.586924] x1 : 0000000029aaaaab x0 : 0000000000000000 [ 86.586930] Call trace: [ 86.586934] ktime_get+0x40/0xa0 [ 86.586941] clockevents_program_event+0x74/0x12c [ 86.586946] tick_program_event+0x58/0xa4 [ 86.586950] hrtimer_interrupt+0x138/0x2c0 [ 86.586958] arch_timer_handler_phys+0x38/0x50 [ 86.586967] handle_percpu_devid_irq+0x84/0x150 [ 86.586970] __handle_domain_irq+0x7c/0xe0 [ 86.586978] gic_handle_irq+0x50/0xd0 [ 86.586983] el1_irq+0xcc/0x180 [ 86.586990] arch_cpu_idle+0x18/0x30 [ 86.586997] default_idle_call+0x24/0x6c [ 86.587002] do_idle+0x22c/0x29c [ 86.587005] cpu_startup_entry+0x24/0x70 [ 86.587012] secondary_start_kernel+0x144/0x180 [ 86.587021] Code: 37000314 d50339bf f9400660 f9401a75 (f9400001) [ 86.587034] ---[ end trace 7a47dc28674422c3 ]--- [ 86.587039] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 86.587043] SMP: stopping secondary CPUs [ 86.591866] [00000000000f4138] pgd=0000000000000000 [ 86.911632] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 86.912994] , p4d=0000000000000000 [ 86.916386] Mem abort info: [ 86.919894] [ 86.923967] ESR = 0x96000004 [ 87.011917] EC = 0x25: DABT (current EL), IL = 32 bits [ 87.015525] SET = 0, FnV = 0 [ 87.019132] EA = 0, S1PTW = 0 [ 87.022738] Data abort info: [ 87.026152] ISV = 0, ISS = 0x00000004 [ 87.029587] CM = 0, WnR = 0 [ 87.033018] user pgtable: 4k pages, 48-bit VAs, pgdp=000000000428b000 [ 87.037302] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
@MichaIng
root@DietPi:~# systemctl status rngd ● rngd.service - Start entropy gathering daemon (rngd) Loaded: loaded (/lib/systemd/system/rngd.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2021-10-24 18:55:08 BST; 4min 29s ago Docs: man:rngd(8) Main PID: 1549 (rngd) Tasks: 1 (limit: 849) Memory: 208.0K CPU: 5ms CGroup: /system.slice/rngd.service └─1549 /usr/sbin/rngd -f Oct 24 18:55:08 DietPi systemd[1]: Started Start entropy gathering daemon (rngd).
root@DietPi:~# ls -l /dev/hwrng crw------- 1 root root 10, 183 Oct 24 18:52 /dev/hwrng
after set chromium autostart
Does the X server itself cause this kernel error? E.g. when you run startx
(and have a desktop installed), or if you have no desktop installed, testing with xterm
as simply X application:
apt install xterm
xinit xterm
@MichaIng but does chromium require a desktop? I try turned on kioskmode
No it does not, it only requires an X server, hence the alternative X application when no desktop is installed 😉.
reboot command doesn't work - stuck here
[ OK ] Removed slice system-modprobe.slice. [ OK ] Stopped target Graphical Interface. [ OK ] Stopped target Multi-User System. [ OK ] Stopped target Login Prompts. [ OK ] Stopped target Sound Card. [ OK ] Stopped tar Stopping Serial Getty on ttyAML0... Stopping Load/Save Random Seed... Stopping vmtouch... [ OK ] Stopped vmtouch. [ OK ] Stopped Start entropy gathering daemon (rngd). [ OK ] Stopped Getty on tty1. [ OK ] Stopped Serial Getty on ttyAML0. [ OK ] Stopped Regular background program processing daemon. [ OK ] Stopped LSB: Lightweight SSH server. [ OK ] Stopped Load/Save Random Seed. [ OK ] Removed slice system-getty.slice. [ OK ] Removed slice system-serial\x2dgetty.slice. Stopping Permit User Sessions... [ OK ] Stopped Permit User Sessions. [ OK ] Stopped target Network. [ OK ] Stopped target Remote File Systems. Stopping ifup for wlan0... Stopping Raise network interfaces... [ OK ] Stopped Raise network interfaces. [ OK ] Finished DietPi-Kill_SSH on shutdown. [ OK ] Stopped ifup for wlan0. [ OK ] Stopped target Network (Pre). [ OK ] Stopped DietPi-PreBoot. Stopping DietPi-RAMlog... [ OK ] Stopped DietPi-RAMlog. [ OK ] Stopped target Basic System. [ OK ] Stopped target Paths. [ OK ] Stopped target Slices. [ OK ] Stopped target Sockets. [ OK ] Stopped target System Initialization. [ OK ] Stopped target Local Encrypted Volumes. [ OK ] Stopped Dispatch Password …ts to Console Directory Watch. [ OK ] Stopped Forward Password R…uests to Wall Directory Watch. Stopping Restore / save the current clock... [ OK ] Stopped Apply Kernel Variables. [ OK ] Stopped Load Kernel Modules. Stopping Update UTMP about System Boot/Shutdown... [ OK ] Stopped Restore / save the current clock. [ OK ] Stopped Update UTMP about System Boot/Shutdown. [ OK ] Stopped Create Volatile Files and Directories. [ OK ] Stopped target Local File Systems. Unmounting /boot... Unmounting /tmp... Stopping Flush Journal to Persistent Storage... [ OK ] Unmounted /boot. [ 1216.301332] systemd-journald[1451]: Received client request to relinquish /var/log/journal/5cbf4952f53c4cd3b8b6d847229d8f11 access. [ OK ] Unmounted /tmp. [ OK ] Stopped Flush Journal to Persistent Storage. Unmounting /var/log... [ OK ] Stopped File System Check on /dev/disk/by-uuid/DFA8-81C0. [ OK ] Removed slice system-systemd\x2dfsck.slice. [ OK ] Unmounted /var/log. [ OK ] Stopped target Local File Systems (Pre). [ OK ] Stopped target Swap. Deactivating swap /var/swap... [ OK ] Stopped Create Static Device Nodes in /dev. [ OK ] Stopped Create System Users. [ OK ] Deactivated swap /var/swap. [ OK ] Reached target Unmount All Filesystems. [ OK ] Stopped Remount Root and Kernel File Systems. [ OK ] Reached target Shutdown. [ OK ] Reached target Final Step. [ OK ] Finished Reboot. [ OK ] Reached target Reboot. [ 1216.795224] systemd-shutdown[1]: Syncing filesystems and block devices. [ 1216.830094] systemd-shutdown[1]: Sending SIGTERM to remaining processes... [ 1216.851382] systemd-journald[1451]: Received SIGTERM from PID 1 (systemd-shutdow). [ 1216.879681] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 1216.907895] systemd-shutdown[1]: Unmounting file systems. [ 1216.909683] [7198]: Remounting '/' read-only in with options '(null)'. [ 1217.038103] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 1217.065939] systemd-shutdown[1]: All filesystems unmounted. [ 1217.066280] systemd-shutdown[1]: Deactivating swaps. [ 1217.071044] systemd-shutdown[1]: All swaps deactivated. [ 1217.076063] systemd-shutdown[1]: Detaching loop devices. [ 1217.087203] systemd-shutdown[1]: All loop devices detached. [ 1217.087314] systemd-shutdown[1]: Stopping MD devices. [ 1217.092443] systemd-shutdown[1]: All MD devices stopped. [ 1217.097484] systemd-shutdown[1]: Detaching DM devices. [ 1217.102926] systemd-shutdown[1]: All DM devices detached. [ 1217.107983] systemd-shutdown[1]: All filesystems, swaps, loop devices, MD devices and DM devices detached. [ 1217.133301] systemd-shutdown[1]: Syncing filesystems and block devices. [ 1217.134851] systemd-shutdown[1]: Rebooting. [ 1217.138530] kvm: exiting hardware virtualization
[ 1217.138530] kvm: exiting hardware virtualization
Do you have a virtualizer/virtual machine running on this machine?
/var/log/journal/5cbf4952f53c4cd3b8b6d847229d8f11
Did you manually create this directory to make system logs boot persistent? In this case you should disable DietPi-RAMlog to not break journald on early boot and shutdown.
Do you have a virtualizer/virtual machine running on this machine?
no it is clean setup - activated only kioskmode
on screen i see green screen :( instead of chromium
@MichaIng third restart and success, but resolution is wrong and I can't change it for generic device
┌──────────────────────────────┤ DietPi-Config ├───────────────────────────────┐ │ │ │ This option is not available for Generic Device (aarch64) │ │ │ ││ │ │ └──────────────────────────────────────────────────────────────────────────────┘
You can set Chromium resolution in dietpi.txt
. Another thing I wanted to change in general is simply not forcing a resolution for Chromium kiosk mode: In /var/lib/dietpi/dietpi-software/installed/chromium-autostart.sh
and remove --window-size=$RES_X,$RES_Y
from it. It should then simply keep the console resolution which should default to the native screen resolution.
small thing: i get periodically this warning
[ 921.824332] meson_clk_pll_set_rate: pll did not lock, trying to restore old rate 3600000000
Did you manually create this directory to make system logs boot persistent?
file is empty
Yes, the pure existence of the /var/log/journal
directory makes systemd-journald
logs there instead of to /run/log/journal
, and this may cause the reboot issues, at least it doesn't make any sense when /var/log
is a tmpfs so that logs are lost on reboot anyway.
┌─────────────────────────────┤ DietPi-Benchmark ├─────────────────────────────┐ │ │ │ Benchmarks completed: │ │ - CPU Performance : Duration = 11.04 seconds (lower is faster) │ │ - CPU Temp : Idle = 42'c | Full load = 49'c │ │ - RootFS : Write = 9 MiB/s | Read = 22 MiB/s │ │ - RAM : Write = 479 MiB/s | Read = 830 MiB/s │ │ │ │ Compare these results online with other users, using the link below: │ │ - https://dietpi.com/survey#benchmark │ │ │ ││ │ │ └──────────────────────────────────────────────────────────────────────────────┘
after setup wifi dietpi.txt contains
##### Network Options ##### # Enable Ethernet or WiFi adapter: 1=enable | 0=disable # - If both Ethernet and WiFi are enabled, WiFi will take priority and Ethernet will be disabled. # - If using WiFi, please edit dietpi-wifi.txt to pre-enter credentials. AUTO_SETUP_NET_ETHERNET_ENABLED=1 AUTO_SETUP_NET_WIFI_ENABLED=0
is it correct?
Those are only relevant for the very first boot (like all AUTO_SETUP_*
settings), to have WiFi automatically enabled for first run setup.
@MichaIng
ssh terminal (interaction) and mouse movements (chromium) freeze for about 5 sec at this moment I see a warning then repeats UART LOG:
[ 7101.379762] meson_clk_pll_set_rate: pll did not lock, trying to restore old rate 3600000000 [ 7119.947739] meson_clk_pll_set_rate: pll did not lock, trying to restore old rate 5592000000 [ 7131.901523] meson_clk_pll_set_rate: pll did not lock, trying to restore old rate 6000000000 [ 7243.718180] panfrost ffe40000.gpu: gpu sched timeout, js=1, config=0x7301, status=0x0, head=0x3131000, tail=0x3131000, sched_job=00000000de90a91b [ 7251.166297] meson_clk_pll_set_rate: pll did not lock, trying to restore old rate 3600000000
The same works fine on the Radxa Buster image?
like no
It seems to have issues adjusting the clock rate, but not sure whether this is about GPU (panfrost
module is the GPU driver module) or about CPU (meson) or both (e.g. both tied to each other). When this is not an issue on the Radxa image, it is probably that DietPi by default uses the schedutil
CPU governor and this ARM doesn't like it for some reason. So you could try to switch to ondemand
or conservative
or so via dietpi-config
> "Performance Options".
thanks! it looks like 'ondemand' fix that 😎
Nice. So seems like too quick CPU frequency changes are an issue with the current kernel. Actually schedutil
is meant to be the successor for both, ondemand
and conservative
, being more efficient with less overhead, so a Linux 5.10 and modern ARM should be able handle it. We hence should report this to Radxa.
Confirming, it works now! Used the updated image and it boots to the dietpi setup.
Only problem is that still, every 60 seconds, there's some background process that detects my mouse and writes the detection to the screen. Doesn't matter if it's a shell prompt or a dietpi "gui", it will still overwrite the screen text. Keeps happening even after config is completed and a reboot is done. Note that this is only on the master tty for the Zero, you don't see this in the SSH window at all.
I haven't done much else but wanted to let you know that we're definitely in business. Well done!
Also:
root@DietPi:~# systemctl status rngd
● rngd.service - Start entropy gathering daemon (rngd)
Loaded: loaded (/lib/systemd/system/rngd.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2021-10-25 00:21:06 BST; 9min ago
Docs: man:rngd(8)
Main PID: 1545 (rngd)
Tasks: 1 (limit: 849)
Memory: 204.0K
CPU: 4ms
CGroup: /system.slice/rngd.service
└─1545 /usr/sbin/rngd -f
Oct 25 00:21:06 DietPi systemd[1]: Started Start entropy gathering daemon (rngd).
root@DietPi:~# ls -l /dev/hwrng
crw------- 1 root root 10, 183 Oct 25 00:21 /dev/hwrng
The verbose console kernel log can be solved by changing the verbosity
setting in /boot/uEnv.txt
, e.g. to the default verbosity=4
. 7
is the highest level, 1
would only print emergency logs, 4
includes all types of error logs (emergency, alerts, critical errors and regular errors). dmesg
of course prints still all log levels, this only affects what is printed to the configured console(s), by default tty1 and ttyAML0 (the serial console).
EDIT: This can be done also for the current boot session: dmesg -n 4
That the driver creates kernel logs regularly at all may be related to some USB power management, not sure. Probably as well something to report to Radxa for investigation.
Don't forget to apt install bc
to keep boot working even when the initramfs is updated (which happens on quite some APT package triggers).
Done (verbosity) and done (bc). Confirming, no more USB detection messages.
Couple of quirks: 1) Weirdly, sudo shutdown -r now and sudo reboot don't reboot the Zero. They both just shut it down completely. Have to power cycle to bring it up again. Not sure why. 2) The other night I installed the Zero CoreELEC/Kodi image. Worked great. And it booted up really quick - many of these SBCs have some little graphic image that appears instantly on bootup, like "HARDKERNEL" for example. The Radxa throws up this green Radxa symbol on booting the CoreElec image, within a second or two. But DietPi doesn't. It takes something like 10-15 seconds before the first log items start appearing on the main tty screen, and no logo. Not sure what this initial delay is due to.
Edit: Even if modifying an option which makes DietPi request to reboot the device to apply settings, that reboot also doesn't work properly. Not sure what's up with triggering software reboots but they don't appear to work. 🤔
- Weirdly, sudo shutdown -r now and sudo reboot don't reboot the Zero
same https://github.com/MichaIng/DietPi/issues/4831#issuecomment-950370729
2. Not sure what this initial delay is due to
the delay is due to network checking
the delay is due to network checking
The network check (and time sync) is now done in background, so that shouldn't delay boot anymore. Service starts wait until all network interfaces have been configured, so e.g. DHCP leasing needs to finish.
Does reboot work on the Radxa image? And can you share the system logs from serial console when rebooting, so see where it hangs now and in which order systemd units are stopped? Above it looks like the /var/log
unmount with journald logging there is the issue, so after either removing /var/log/journal
(I still wonder how it landed there, as it's not part of the image) or disabling DietPi-RAMlog this part should be solved. But there are other reasons why this may not work, e.g. I know from some Armbian images as well that failing reboot is a known issue, kernel related. In this case the Radxa image should fail to reboot the same way.
(I still wonder how it landed there, as it's not part of the image)
I created it. I thought you asked here https://github.com/MichaIng/DietPi/issues/4831#issuecomment-950371871 😊
Does reboot work on the Radxa image
is there a new image?
I asked whether it has been created manually, not that it should be done, as it doesn't make sense in combination with DietPi-RAMlog and may cause (minor) issues, e.g. a hanging on reboot 😉.
I mean whether it works with the official Radxa Debian Buster image: https://github.com/radxa/radxa-zero-images-released/releases
If you have two SD cards for swapping, as flashing back and forth may not be feasible 😉. But before we report and issues to Radxa, we should assure that it is really a kernel/dtb/firmware/board issue and not related to something we broke our end (like the removed bc
required for the custom initramfs script).
@MichaIng got it now, I will be able to check it in 4 hours
Btw I updated our image to contain bc
, have ondemand
CPU governor enabled by default and console log verbosity set to 4
. Also Radxa is so kind to send me a Zero, so we can do own testing and polishing the image, config and software options for it.
PR up for initial support: #4900 I'll add this to the image as well, replacing only the hardware ID and detection script files (leaving everything else at DietPi v7.7).
@MichaIng
Does reboot work on the Radxa image?
no. used Linux zero 5.10.69-2-amlogic-g981b0a3cef #g981b0a3cef SMP PREEMPT Sun Oct 10 15:41:00 CST 2021 aarch64 (zero_debian_buster_xfce4_arm64_20211010_0810-mbr.img) same symptoms
[ OK ] Reached target Reboot. [ 328.270194] printk: systemd-shutdow: 29 output lines suppressed due to ratelimiting [ 328.324903] systemd-shutdown[1]: Syncing filesystems and block devices. [ 328.766060] systemd-shutdown[1]: Sending SIGTERM to remaining processes... [ 328.774732] systemd-journald[1446]: Received SIGTERM from PID 1 (systemd-shutdow). [ 329.006977] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 329.015955] systemd-shutdown[1]: Unmounting file systems. [ 329.018451] [2855]: Remounting '/' read-only in with options '(null)'. [ 329.070427] EXT4-fs (mmcblk1p2): re-mounted. Opts: (null) [ 329.087600] systemd-shutdown[1]: All filesystems unmounted. [ 329.087729] systemd-shutdown[1]: Deactivating swaps. [ 329.092698] systemd-shutdown[1]: All swaps deactivated. [ 329.097712] systemd-shutdown[1]: Detaching loop devices. [ 329.105451] systemd-shutdown[1]: All loop devices detached. [ 329.108507] systemd-shutdown[1]: Detaching DM devices. [ 329.129267] kvm: exiting hardware virtualization
dmesg for zero_debian_buster_xfce4_arm64_20211010_0810-mbr.img
[ 6.327456] systemd-journald[1447]: Received request to flush runtime journal from PID 1 [ 6.343165] systemd-journald[1447]: File /var/log/journal/7851a9aa1b9f499bbc87d84d73acdaf5/system.journal corrupted or uncleanly shut down, renaming and replacing.