djurny

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,

Hi, Are you sure that this is not something related to your Wireguard configuration? Groetjes,

Hi, I still have this issue occur occasionally and was not successful in finding & building the v1.11 version of the r8152 kernel module. The symptoms included: lan0 (the USB attached NIC) sometimes disappeared. Entire broadcast domain stopped responding: helios64 reported: rk_gmac-dwmac fe300000.ethernet eth0: Reset adapter. orangepi zero reported: dwmac-sun8i 1c30000.ethernet eth0: Reset adapter. nanopi R2S sometimes reported messages about TX buffer/queue overflow (cannot locate this message anymore unfortunately). The NIC activity LED on one of the nanopi R2S boxen was showing a high amounts of traffic. The broadcast domain started working again, after I disconnected lan0 NIC of the nanopi R2S from local network. These symptoms reminded me of some incident we encountered during my daytime profession; an unresponsive broadcast domain, while all hardware was still OK. Turned out that one device on that network borked out and started flooding the broadcast domain with PAUSE frames, which are broadcast by the first switch it encounters. This will in turn cause all other devices to stop transmitting data as well, leading to the entire broadcast domain to come to a halt. Knowing this, I tried to disable the PAUSE options from the USB NIC on buster, but this seemed not possible: root@nanopi0:~# ethtool -A lan0 autoneg off rx off tx off Cannot get device pause settings: Operation not supported I tried to upgrade to bullseye, and lo and behold, the PAUSE option could be (partially) disabled on the USB NIC (lan0): root@nanopi1:~# ethtool -a lan0 Pause parameters for lan0: Autonegotiate: on RX: off TX: off RX negotiated: off TX negotiated: off Currently running bullseye and will keep monitoring. Hopefully either the upgrade to bullseye (or the disabling of PAUSE frames) will prevent this issue from popping up every now and then. (It had a habit of popping up, when I was away from home, making it impossible to connect to my home network from outside anymore.) Perhaps this might also help someone here? Groetjes,