djurny
Members-
Posts
67 -
Joined
-
Last visited
Profile Information
-
Gender
Male
-
Location
Taiwan
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
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,
-
Disable/spread regular HDD integrity checks
djurny replied to Nathan Driver's topic in Marvell mvebu
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, 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,
-
Hi Nick, That's interesting. After some trial and error on my box, I also could not get it to work on kernel version 5.9.13 (21.02.0-trunk.16). What happens if you put the "activity" in the trigger file? If I do that on my box, it does seem to light up almost in the same cadence as the activity LED on the ethernet connector. echo 'activity' | sudo tee '/sys/class/leds/helios64:blue:net/trigger' Note that this is not 'activity' of the network, but activity in the form of CPU activity. Not exactly what you are looking for, but this does seem to generate at least some action on the LED. Groetjes,
-
Hi @NickS, Sorry, I wanted to ask what the LED behavior is after that command. Groetjes,
-
Hi @NickS, Can you try to do the following: echo 'netdev' | sudo tee '/sys/class/leds/helios64:blue:net/trigger' ...and show the result? Groetjes,
-
Hi, Are you talking about the LAN activity LED at the front of the box (as the top picture)? Or the LED at the rear of the box - as part of the ethernet port (bottom picture)? Groetjes,
-
Hi @IgorS, After following the how to's on this forum and the internets, would like to share some other things I did to make it work even better on my OrangePi Zero. Connect DS3231 to TWI0 (PA11+PA12 and +5V/GND of course). Add i2c0 overlay to /boot/armbianEnv.txt (or use armbian-config to enable the i2c0 overlay). [...] overlays=usbhost2 usbhost3 uart1 pps-gpio i2c0 [...] Add custom overlay to add DS3231 RTC (using DS3232 module instead of DS1307). Save as rtc0-i2c0-ds3231.dts. Add the custom DT overlay: sudo armbian-add-overlay rtc0-i2c0-ds3231.dts Add custom overlay to rename H2+ SoC RTC to rtc1. Save as rtc1-soc.dts. Add the custom DT overlay: sudo armbian-add-overlay rtc1-soc.dts Disable fake-hwclock service: sudo systemctl stop fake-hwclock.service # stop sudo systemctl disable fake-hwclock.service # disable sudo systemctl mask fake-hwclock.service # really disable Reboot and verify that you now have 2x RTC on your OrangePi Zero: root@sinaspi:~# ls -l /dev/rtc* lrwxrwxrwx 1 root root 4 Aug 5 22:57 /dev/rtc -> rtc0 crw------- 1 root root 253, 0 Aug 5 22:57 /dev/rtc0 crw------- 1 root root 253, 1 Aug 5 22:57 /dev/rtc1 As mentioned in another post, on the H2+ the SoC supplied RTC is indeed running fast, confirm this as follows: for RTC in /dev/rtc[0-9] do hwclock --rtc="${RTC:?}" --adjust hwclock --rtc="${RTC:?}" --systohc done sleep $(( 5 * 60 )) for RTC in /dev/rtc[0-9] do echo "${RTC:-N/A}:" hwclock --rtc="${RTC:?}" --get date --rfc-3339=ns done On my OrangePi Zero the SoC RTC is dashing ahead: /dev/rtc0: 2021-08-08 09:17:52.760046+08:00 2021-08-08 09:17:52.526062078+08:00 /dev/rtc1: 2021-08-08 11:59:11.150733+08:00 2021-08-08 09:17:54.392611945+08:00 (rtc0 = DS3231 and rtc1 = SoC RTC.) On the same OrangePi Zero, there is also a GPS receiver connected that has PPS output. Used @Elektrický's how to, to set up GPS and ntpsec. After successfully following the how to, ntp will synchronize and adjust system clock to high(er) accuracy. Once system clock is synchronized, the kernel will also update the RTC (/dev/rtc0) every 11 minutes, giving you a system as follows: root@sinaspi:~# timedatectl Local time: Sun 2021-08-08 09:24:01 CST Universal time: Sun 2021-08-08 01:24:01 UTC RTC time: Sun 2021-08-08 01:24:02 Time zone: Asia/Taipei (CST, +0800) System clock synchronized: yes NTP service: inactive RTC in local TZ: no root@sinaspi:~# ntpq -p remote refid st t when poll reach delay offset jitter ======================================================================================================= 0.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0019 1.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0019 2.debian.pool.ntp.org .POOL. 16 p - 256 0 0.0000 0.0000 0.0019 3.debian.pool.ntp.org .POOL. 16 p - 64 0 0.0000 0.0000 0.0019 oPPS(0) .PPS. 0 l 56 64 377 0.0000 -0.0072 0.0035 xSHM(0) .GPS. 0 l 21 64 377 0.0000 -15.3659 1.7862 +SHM(2) .PPS. 0 l 18 64 377 0.0000 -0.0163 0.0094 +europa.ellipse.net 209.180.247.49 2 u 40 64 377 167.9069 -0.9358 0.1437 +ntp1.time.nl .MRS. 1 u 43 64 377 210.9643 1.7869 0.1945 +promethee.boudot.one 94.198.159.10 2 u 21 64 377 220.2528 2.3322 0.0931 root@sinaspi:~# As the DS3231 is now set as rtc0, the udev rules in /lib/udev/rules.d/85-hwclock.rules will make sure to read the DS3231 clock time after a reboot, making sure your system clock has a nice starting offset after being powered off for a while. Hope this helps anyone out there, Groetjes,
-
Hi, I found myself in a similar situation, (on OrangePi Zero, but method described here should also apply here) where my I2C based DS3231 was detected last (rtc1) and the SoC's RTC detected first (rtc0). Looks like all kernel and userspace processes & tools use first detected RTC only (11 minute sync), timedatectl, ntp[sec]d. Tried some udev rules to rename the devices based on their DEVPATH, but this did not work. I also did not want to start renaming device nodes or do some symbolic link cooking to get it to work. What did work (for my OrangePi Zero): Add an overlay where the SoC's RTC is aliased to rtc1 and the I2C based one is aliased as rtc0: /dts-v1/; /plugin/; / { compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,sun8i-h3", "allwinner,sun50i-a64", "allwinner,sun50i-h5"; /* * Aliases can be used to set the external RTC as rtc0 * Needs supplying the correct path to the I2C controller RTC is connected to, * this example is for I2C0 on H2+ (TWI0 on PA11 + PA12) * NOTE: setting time at boot by the kernel * may not work in some cases if the external RTC module is loaded too late */ fragment@0 { target-path = "/aliases"; __overlay__ { rtc0 = "/soc/i2c@1c2ac00/ds3231@68"; }; }; fragment@1 { target = <&i2c0>; __overlay__ { #address-cells = <1>; #size-cells = <0>; ds3231@68 { compatible = "dallas,ds3232"; reg = <0x68>; status = "okay"; }; }; }; fragment@2 { target-path = "/aliases"; __overlay__ { rtc1 = "/soc/rtc@1f00000"; }; }; fragment@3 { target = <&rtc>; __overlay__ { rtc@1f00000 { status = "disabled"; }; }; }; }; The SoC's RTC location should be matched to your SoC in fragments 2 and 3 (or remove fragmet 3 altogether). Also, the 'compatible' line should be modified to match your SoC's/board's DT as well. The overlay is based on the one available here. Modified the ds1307 to ds3232 after reading this post. Added the fragments 2 and 3 to alias the SoC's RTC to rtc1, the 'disable' part is not working. Hope this helps for you as well: Groetjes,
-
Hi, I have a similar possible identical issue. One of my NanoPi R2S systems is running as my VPN gateway (for both data and Pihole DNS). On several occasions my Pihole get shut (pun intended) -- DNS stops working due to my VPN gateway being unreachable on it's LAN side. On the serial console there are no warnings, errors or messages of any kind, bar armbianmonitor. 02:09:48: 408MHz 0.04 1% 0% 0% 0% 0% 0% 50.8°C 0/5 02:09:53: 600MHz 0.04 2% 1% 0% 0% 0% 0% 51.2°C 0/5 02:09:58: 1200MHz 0.27 6% 4% 0% 1% 0% 0% 53.3°C 0/5 02:10:03: 408MHz 0.25 3% 1% 1% 0% 0% 0% 50.8°C 0/5 02:10:08: 408MHz 0.31 1% 0% 0% 0% 0% 0% 51.7°C 0/5 02:10:14: 408MHz 0.41 1% 1% 0% 0% 0% 0% 50.8°C 0/5 02:10:19: 408MHz 0.38 1% 0% 0% 0% 0% 0% 51.7°C 0/5 02:10:24: 408MHz 0.43 1% 1% 0% 0% 0% 0% 50.4°C 0/5 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 02:10:29: 1200MHz 0.55 5% 4% 0% 0% 0% 0% 52.1°C 0/5 02:10:34: 600MHz 0.67 1% 1% 0% 0% 0% 0% 50.8°C 0/5 02:10:39: 408MHz 0.78 1% 1% 0% 0% 0% 0% 51.2°C 0/5 02:10:45: 408MHz 0.87 2% 1% 0% 0% 0% 0% 50.4°C 0/5 02:10:50: 600MHz 0.96 1% 1% 0% 0% 0% 0% 50.8°C 0/5 02:10:55: 408MHz 1.05 1% 1% 0% 0% 0% 0% 52.5°C 0/5 The interesting thing is that the load number seems to increase at some point: where it was average around well below 0.8 before, it started to creep up to around 7.00. 07:23:16: 408MHz 7.05 1% 1% 0% 0% 0% 0% 51.2°C 0/5 07:23:21: 1200MHz 7.05 1% 1% 0% 0% 0% 0% 52.5°C 0/5 07:23:26: 1200MHz 7.04 2% 2% 0% 0% 0% 0% 54.6°C 0/5 After attempting to log in on the serial console, there was nothing in 'top' indicating any processes were hogging up the cores causing high load numbers at all: (Note that I did have to "terminate all tasks" using <BRK>+e to be able to login on the serial console, so the 'top' results might be useless here.) Currently I have added the udev rule to the system to disable TX and RX offloading, as well as to disable the link power management for the RTL8153 device. SUBSYSTEM!="net", GOTO="__rtl815x_end" ACTION!="add", GOTO="__rtl815x_end" ENV{ID_VENDOR_ID}!="0bda", GOTO="__rtl815x_end" ENV{ID_MODEL_ID}!="8153", GOTO="__rtl815x_end" LABEL="__rtl815x_disable_lpm" RUN+="/bin/sh -c 'echo %E{ID_VENDOR_ID}:%E{ID_MODEL_ID}:k > /sys/module/usbcore/parameters/quirks'" LABEL="__rtl815x_disable_offloading" RUN+="/usr/sbin/ethtool -K $name rx off tx off" LABEL="__rtl815x_end" (Bit modified to also apply to any other RTL8153 device, to use the assigned name instead of hardcoded 'lan0'.) Spoilers below on 'blocked task state' show some links to the r8152 module and RTL8153 device. Backtrace of all active CPUs below. As I did spot several references to either suspend states of the RTL8153 (rtl8152_get_link_ksettings, rtl8152_suspend, __pm_runtime_resume), it might be more related to the link power management issue referenced in this thread. In the meantime, as this 'hangup' occurs only perhaps once every 1-2 weeks, I will monitor the system to see if it will happen still after the LPM and RX/TX offloading tweaks. If anyone is interested in some more backtrace content, I can provide. Groetjes,
-
Hi @tparys, LUKS2 on-disk format is not supported/understood by cryptsetup 1.x, it requires cryptsetup 2.0 or higher. At that time, I do recall I had to build it (cryptsetup 2.x) from source on my Helios4 and Helios64 boxes which were at 4.4.x back then. As mentioned, my memory is failing here as I cannot recollect or find any logs on the actual errors I encountered, but the errors thrown at me by LUKS(1) were putting me on all my wrong feet at that time. Anyhow, I thought it is worth to check out to see if this might help out - or not of course. Groetjes,
-
Hi @a5s397, I also had some issues with my LUKS encrypted partitions after a kernel upgrade before, but I have a hard time remembering what actually happened and how I managed to get it working again. Perhaps I'm stating the obvious, but are you sure you have a LUKS or LUKS2 type setup on your drive? As for me, I had to recompile LUKS2 in the past to get it to work for sure. Cannot really recall about the ... stopping here, just read your console.txt and you indeed have a LUKS2 format. Can you paste the output of cryptsetup --version and a syslog or dmesg output just before, during and after your first initial attempt to luksOpen your device on the working and non-working setups? Groetjes,
-
Hi, You can try the following to get an idea of which process is modifying the file: sudo apt-get install auditd sudo auditctl -w /boot/armbianEnv.txt -p wa sudo tail -F /var/log/audit/audit.log The output should show actions performed on the file and (IIRC) the process ID performing those actions, perhaps that might help? e.g.: type=CWD msg=audit(1624526184.097:207): cwd="/home/djurny" type=PATH msg=audit(1624526184.097:207): item=0 name="/boot/" inode=7601 dev=b3:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(1624526184.097:207): item=1 name="/boot/armbianEnv.txt" inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=CREATE cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.097:207): proctitle=xx type=SYSCALL msg=audit(1624526184.109:208): arch=40000028 syscall=94 per=800000 success=yes exit=0 a0=3 a1=81a4 a2=c80eeb00 a3=81a4 items=1 ppid=9641 pid=9642 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=2 comm="vi" exe="/usr/bin/vim.basic" subj==unconfined key=(null) type=PATH msg=audit(1624526184.109:208): item=0 name=(null) inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.109:208): proctitle=xx type=SYSCALL msg=audit(1624526184.109:209): arch=40000028 syscall=226 per=800000 success=yes exit=0 a0=1787820 a1=b6e3e1a0 a2=1907fc0 a3=1c items=1 ppid=9641 pid=9642 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts5 ses=2 comm="vi" exe="/usr/bin/vim.basic" subj==unconfined key=(null) type=CWD msg=audit(1624526184.109:209): cwd="/home/djurny" type=PATH msg=audit(1624526184.109:209): item=0 name="/boot/armbianEnv.txt" inode=43198 dev=b3:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=PROCTITLE msg=audit(1624526184.109:209): proctitle=xx Source: Find which process is modifying a file [duplicate] It honestly sounds a bit more like a filesystem that has lost track or a inode mixup somewhere? As someone mentioned, perhaps something else is writing to this file, thinking it is something else? Perhaps try to locate a symbolic (or hard)link to armbanEnv.txt: ## find any symbolic links to armbianEnv.txt sudo find / -xdev -type l -ls | egrep -i -- armbianEnv.txt ## find hardlinks to armbianEnv.txt - need to be on the same filesystem! sudo find / -xdev -samefile /boot/armbianEnv.txt Groetjes,
- 20 replies
-
4
-
- PINE A64
- ESPRESSObin
-
(and 1 more)
Tagged with: