djurny

Hi there, Seems like the kernel is waiting for the wrong filesystem to become available. If blkid shows you PTUUID="8cdc55ae-c576-6f4c-a793-0397a48dccf0 and not any UUID=... associated with a filesystem on that partition, that means that either you do not have a [root] filesystem on that partition or that your root filesystem is on another partition of your SDcard. A PTUUID is the UUID for the partition itself, not for a filesystem. i.e. An empty partition still has a PTUUID. Most (if not all) filesystems have a UUID. Using a UUID makes it easier to have the kernel identify where a/the root filesystem is located. as it is not guaranteed how the storage devices are discovered at boot time. A UUID is linked to the filesystem and not to the device where it is stored on. If you are convinced that you have a root filesystem on a certain partition of your SDcard, you can always use rootdev=/dev/mmcblk1p1 (or wherever your root filesystem lives) in your /boot/armbianEnv.txt to instruct the kernel to expect a root filesystem there. ...but that partition does need to actually have a root filesystem, unless you end up in the same situation you are describing. Can you share the output of sudo parted /dev/mmcblk1 u s pr and sudo blkid -g followed by sudo blkid /dev/mmcblk* ? Groetjes,

Hi @Vodalex, You do not have to upgrade to the newest kernel in order to use the U-Boot SPL. If you want to test out the changes in the load addresses, you can also add the following lines to your armbianEnv.txt: ramdisk_addr_r=3000000 script_addr_r=4000000 pxefile_addr_r=4100000 The changes i made to the load addresses in the Kobol U-Boot can also be done by issuing setenv commands on the U-Boot commandline, but you would need a serial connection to the U-Boot console for that to work. The armbianEnv.txt is loaded as an external U-Boot environment file, meaning that adding the lines as above should also work. This way you can keep your current U-Boot with all the changes it has underwent upto today. The U-Boot i built is based on the Kobol one, which is from some years back already. If you want to use the U-Boot SPL i built, then yes, you should put the SDcard into a Linux PC or other SBC of choice. Find out which device it is and write out the image file starting from the second sector. The two syncs you can omit and replace with the following dd invocation: sudo dd if=u-boot-spl.kwb of=/dev/sdX bs=512 seek=1 conv=fsync The conv=fsync will ensure that data+metadata will be physically written to disk before dd exits. Groetjes,

Hi @Ed van den Enden, Checked a bit more on the internets and found that you have added the device overlay to your BanananaPi in the same manner as you have done on your RaspberryPi: dtoverlay=i2c-rtc,ds1307 On armbian you add overlays using: # armbian provided overlays overlays=usbhost2 usbhost3 i2c0 uart1 pps-gpio # user provided overlays user_overlays=rtc0-i2c-ds3231-rtc1-soc Also confirmed that boot.cmd indeed only expects to see user_overlays in the armbianEnv.txt and does not check for dtoverlay. You can check in /boot/dtb/overlay/ which armbian provided overlays are there, but for the i2c RTC you would need to add a user defined overlay. Safest bet would be to use the armbian-add-overlay tool that will compile (and check) then add the overlay to your armbianEnv.txt using the keywords that will make sure the overlay is used during boot. As mentioned before as well, you would need to have the device tree files handy for armbian-add-overlay to process them. These are .dts files and are human readable. The topic mentioned in the reply earlier has the two .dts device tree overlays that should also work for your case. Groetjes,

Hi @Ed van den Enden, After checking your provided information: [ 1.019881] sun6i-rtc 1f00000.rtc: registered as rtc0 [ 1.019937] sun6i-rtc 1f00000.rtc: setting system clock to 2025-04-22T10:04:37 UTC (1745316277) This actually shows the SoC provided RTC, not the i2c one. I cannot see any other RTC being picked up by the kernel, so it seems something is not working well with the overlay. See below what you should expect to see: Apr 24 22:12:12 blippi kernel: [ 3.271653] sun6i-rtc 1f00000.rtc: registered as rtc1 Apr 24 22:12:12 blippi kernel: [ 3.277001] sun6i-rtc 1f00000.rtc: RTC enabled Apr 24 22:12:12 blippi kernel: [ 5.455786] rtc-ds3232 0-0068: registered as rtc0 Apr 24 22:12:12 blippi kernel: [ 5.462541] rtc-ds3232 0-0068: setting system clock to 2025-04-25T05:12:02 UTC (1745557922) The messages mentioning sun6i-rtc are from the SoC, the ones mentioning rtc-ds3232 are from the i2c attached ds3231 (supported by the ds3232 module by the rtc0-i2c0-ds3231.dts overlay mentioned in the post at the bottom of this reply). Can you list the contents of /boot/overlay* and /boot/overlay-user ? And also, can you share the contents of the dt overlay "i2c-rtc,ds1307" ? (Not sure if that is supposed to be seperated by whitespace or a comma.) (Also not sure if 'dtoverlay=' is the correct keyword here, please check https://docs.armbian.com/User-Guide_Armbian_overlays/#armbianenvtxt-entries-reference to make sure you added the overlay correctly.) While you are at it, any possibility to get the U-Boot output? That will show if the overlay can be found or not. Groetjes, PS Check the topic below for how the same RTC can be made working on an OrangePi 0, which uses the same SoC as the BananaPi M2 0. There are two dt overlay files mentioned there that should add the i2c RTC (and name it rtc0) and one that will 'rename' the SoC RTC to rtc1.

Hi @Ed van den Enden, the blob shown was a device tree overlay. The device tree is the non-PCI variant of PCI config spaces. It specifies which hardware is located where and on what bus and so on. There are default device tree overlays for adding an 'external' RTC to the board, the one I shared is based on this, but just to make sure the 'external' will be 'found' first (and therefore updated by kernel). Edit: to be clear - if you choose to use a device tree overlay where the RTC is listed as the first RTC in your system, you do not need to use the script. If you do not use the device tree overlay to put your external RTC first in line, you can try if the script suits your needs. The scrip attached, you can just put on your system, somewhere in /usr/local/sbin/ would be my advice. To make it work, you have to trigger it during boot and on interval basis. I think I have it triggered from /etc/rc.local (not the best spot, but it works). Set proper ownership (root as owner and anyone in the adm group can execute): sudo chown root:adm /usr/local/sbin/rtc-sync sudo chmod 0750 /usr/local/sbin/rtc-sync Add to /etc/rc.local: /usr/local/sbin/rtc-sync -A start (Create and) Add to /etc/cron.d/rtc-sync: */22 * * * * root /usr/local/sbin/rtc-sync -A update The cron job will start rtc-sync 'update' every 22 minutes, which checks if the wallclock is synchronized by ntp. If so, if will update the 'freerunning' clocks with the wallclock. 'freerunning' means "not updated by ntpd" in this case. For all this to work, you do need to install and configure ntp. The ntp daemon will update the wallclock and the kernel will set the first RTC it sees (/dev/rtc0) with the adjusted wallclock it keeps. The kernel will not update any other RTC than the first one -> this is where the rtc-sync script will help. This update will happen every 11 minutes and is hardcoded in the kernel somewhere. (See https://unix.stackexchange.com/questions/285129/switch-off-11-minute-kernel-mode for some more info.) Hope this all helps, Groetjes, PS I forgot why I added the link to the topic about the NTP server with external GPS receiver... I guess I sometimes get a little bit distra

Hi @Ed van den Enden, I think your BananaPi runs an Allwinner SoC, which is similar to the OrangePi zero. Can you list the RTCs on your board? ls /dev/rtc* On my OrangePi's here, the H2+ SoC also has an RTC that is wildly unprecise, but it's still used as /dev/rtc0 and therefore used by the kernel to synchronize to when the kernel boots. I do not know much about your SBC, but perhaps sharing my config for the OrangePi zero helps you as well: I have two RTCs, one from the H2+ SoC and one connected via i2c: djurny@sinaspi:~$ ls /dev/rtc* /dev/rtc /dev/rtc0 /dev/rtc1 As the SoC RTC will be seen first by the kernel, i had to update the DTB to make it appear later than the i2c one: The dtb is specifically for the OrangePi zero (1), so most likely not suitable for your SBC. But the idea might help you to fixup your dtb. For my NanoPi neo3 i was not able to apply a dtb fix and had to make some oddball script (attached). It would check for any RTC that is currently being synced by NTP and if i cannot find one (during boot and before NTP can sync) it will copy the date/time from the first "external" RTC it can find. If it finds NTP is sync'ed, it will write the wallclock to the external "freerunning" RTCs to make sure the "external" RTC will have a reasonably accurate time when the system power cycles/reboots. Let me know if this works for you. About the dtb fixups, i cannot really remember unfortunately, but some other posts on here helped a lot. You can try here for more hints and things you can try: Hope some of this might help your case, Groetjes, rtc-sync

Hi there, Some other solution that I have not been able to make "permanent" yet. Thanks @FredK@Josua-SR and @Igor for allowing me to have some fun building U-Boot once more (have not built a U-Boot since i think 2006!), it for sure did bring back some good memories 🙂 Unfortunately the built U-Boot (with SDHCI_SDMA disabled) did not solve my issue. Then i decided to revert back to the previous release (*-6.6.87-current-mvebu => *-6.6.43-current-mvebu) by moving the symlinks in /boot around, which at least allowed the kernel and some userspace to boot. But due to lacking kernel modules (the 6.6.43 were removed during upgrade to 6.6.87) the box itself did not really work. After some inspection, based on the remarks from @Josua-SR about memory corruption, i decided to check if this might not be just a simple overlapping issue with the images, e.g. kernel image partially occupying where the initrd is loaded. Kernel image Size Size (hex) vmlinuz-6.6.43-current-mvebu 7170736 0x6d6ab0 vmlinuz-6.6.87-current-mvebu 8858728 0x872c68 Loading of files is done as follows: fdt (dtb) 0x2040000 (0x840000 max size) ramdisk (uInit) 0x2880000 kernel (vmlinuz) 0x2080000 (0x7fffff max size) You can already spot that the kernel image will not fit into the area that U-Boot has designated for it: 0x872c68 > 0x7fffff. whereas the 6.6.43 kernel should fit fine: 0x6d6ab0 < 0x7fffff. Some testing showed that when setting ramdisk_addr_r to a higher value - which should fit the bigger kernel image - things started to boot again: => setenv ramdisk_addr_r 2980000 => boot switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2996 bytes read in 210 ms (13.7 KiB/s) ## Executing script at 03000000 Boot script loaded from mmc 176 bytes read in 201 ms (0 Bytes/s) 28834 bytes read in 424 ms (66.4 KiB/s) 11504908 bytes read in 2562 ms (4.3 MiB/s) 8858728 bytes read in 2218 ms (3.8 MiB/s) ## Loading init Ramdisk from Legacy Image at 02980000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 11504844 Bytes = 11 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 02040000 Booting using the fdt blob at 0x2040000 Loading Ramdisk to 0f507000, end 0ffffccc ... OK reserving fdt memory region: addr=2040000 size=6d000 Loading Device Tree to 0f497000, end 0f506fff ... OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0 Next is to try and figure out how I could change ramdisk_addr_r (the initial spot where U-Boot wants to load the ramdisk into), as I prefer not to have to type this at the U-Boot prompt every single time i reboot the box. Hope this helps someone out there with similar issue. Update: I built a U-Boot from the Kobol repo (https://wiki.kobol.io/helios4/uboot/#u-boot-2018) with the SDHCI_SDMA option disabled, and different memory load addresses for the ramdisk, script and efi stuff, see attached. Note i had some issues with the scripts/dtb, some yylloc variable had to be defined as external due to some linker error. in "scripts/dtc/dtc-lexer.lex.c" i had to change line 618 to: extern YYLTYPE yylloc; To update the memory load addresses, in "include/configs/helios4.h": #define KERNEL_ADDR_R __stringify(0x2080000) #define FDT_ADDR_R __stringify(0x2040000) #define RAMDISK_ADDR_R __stringify(0x3000000) #define SCRIPT_ADDR_R __stringify(0x4000000) #define PXEFILE_ADDR_R __stringify(0x4100000) Essentially moved RAMDISK_ADDR_R from 0x0288'0000 to 0x0300'0000 to allow for larger kernel image and moved SCRIPT_ADDR_R (a.o.) to make room for the ramdisk image, from 0x0300'0000 to 0x0400'0000. Then to write the U-Boot single page loader image out to the SDcard: sudo dd if=u-boot-spl.kwb of=/dev/mmcblk0 seek=1 bs=512 Groetjes, PS Warranty until the door for the attached U-Boot.... u-boot-spl.kwb

Hi there, Seems that you are trying to download an incorrect image for HASS: 2024-05-14 11:38:38.835 ERROR (MainThread) [supervisor.docker.interface] Can't install ghcr.io/home-assistant/odroid-n2-homeassistant:2024.5.3: 404 Client Error for http+docker://localhost/v1.45/images/ghcr.io/home-assistant/odroid-n2-homeassistant:2024.5.3/json: Not Found ("No such image: ghcr.io/home-assistant/odroid-n2-homeassistant:2024.5.3") 2024-05-14 11:38:38.837 WARNING (MainThread) [supervisor.homeassistant.core] Error on Home Assistant installation. Retrying in 30sec Looks like the HASS supervised installation is trying to install a docker image for an Odroid N2 instead of the Libre Renegade? According to Odroid, the N2 is based on an Amlogic SoC and not on a Rockchip SoC (like the Libre Renegade). Apart from that, it appears it cannot locate the docker image either. Perhaps contact the HASS community? You can also try to install Armbian on your SBC and use the regular Docker image for HASS. Hope that helps, Groetjes,

Hi there, Can you share your serial console logging? Groetjes,

Hi Nathan, This is something that indeed is done by mdadm configuration. You need to check /etc/cron.d/mdadm: # # cron.d/mdadm -- schedules periodic redundancy checks of MD devices # # Copyright © martin f. krafft <madduck@madduck.net> # distributed under the terms of the Artistic Licence 2.0 # # By default, run at 00:57 on every Sunday, but do nothing unless the day of # the month is less than or equal to 7. Thus, only run on the first Sunday of # each month. crontab(5) sucks, unfortunately, in this regard; therefore this # hack (see #380425). 57 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi You can either disable this cronjob by commenting out the actual cron entry, or by moving the file 'mdadm' out of the '/etc/cron.d' folder. Easiest would be to write a script that will iterare all mdadm devices, start the redundancy check, wait for the check to complete. then move to the next mdadm device. Something like: #!/bin/bash case "$( /usr/bin/id -u )" in '0') ;; *) echo "Please run as root user." exit 1 ;; esac for MD in /dev/md[0-9]* do SYNC_ACTION="/sys/block/${MD:?}/md/sync_action" ( echo 'check' > "${SYNC_ACTION:?}" ) || exit 1 while true do case "$( /usr/bin/cat "${SYNC_ACTION:?}" )" in '') exit ;; 'idle') break ;; esac sleep 10 done done # EOF Note that that code snippet was not tested, but should give you direction to your solution. Hope that helps, Groetjes,