dec

I'm just trying a basic operation with stock Tinker_Board-Debian-Buster-v3.0.11-20211026 image, but I immediately run in to this issue... I just want to list out what the existing NAT table is... iptables -t nat -L -n -v But I get this error... iptables v1.8.2 (nf_tables): CHAIN_ADD failed (No such file or directory): chain PREROUTING Been searching through all of the alternative / iptables-legacy / iptables-nft stuff, but not quite getting there. Any idea?

Did anyone ever figure this out? I'm just trying a basic operation with stock Tinker_Board-Debian-Buster-v3.0.11-20211026 image, but I immediately run in to this issue... I just want to list out what the existing NAT table is... iptables -t nat -L -n -v But I get this error... iptables v1.8.2 (nf_tables): CHAIN_ADD failed (No such file or directory): chain PREROUTING Any idea?

Update, I believe I found the issue… Somehow something caused the RTC chip to hang / freeze time. I disabled the overlay, and performed i2cdump to watch RTC registers…They weren’t changing! So pulled power, pulled the battery, and put it back in…Now time increments…hwclock is able to read the value now since it sees a changing value.

I have an RTC chip (uses ds1307 overlay) attached to standard Tinkerboard S that works just fine. It sits on the i2c-1 bus, and gets mapped to rtc1. I am able to communicate with it using hwclock -f /dev/rtc1 -r and it reports the time. This is good. However, I take that board and put it on a Tinkerboard S R2.0 running the Debian 3.0.11 image, with "ds1307-overlay" enabled. For some reason it gets mapped to rtc0. I am NOT able to communicate with it using hwclock -f /dev/rtc0 -r. The interesting thing is when I look at /var/log/syslog, I can see where it finds the ds1307, maps it to rtc0, and then declares that it is setting the system time to the proper time value (that it could have only gotten if it was able to read the time from the RTC). Why is this happening when hwclock -f /dev/rtc0 -r doesn't work. I can't set the clock either with a hwclock -f /dev/rtc0 -w command. Performing a udevadm info -a -p /sys/class/rtc/rtc0 shows a valid time in the output text, but if I execute the command again, the time does not change. It's like communication with the RTC worked initially, but then something changed during boot that prevents communication further.

Ok update... Was able to get sshd to start at boot after learning about sshd.socket. systemctl disable sshd.socket Now sshd will start

Any luck finding the Kernel sources? I found these, but not sure if this is really correct... https://github.com/TinkerBoard/debian_kernel/releases/tag/tinker_board-debian-3.0.11 https://github.com/TinkerBoard/debian_u-boot/releases/tag/tinker_board-debian-3.0.11

We are beginning to work with the new TinkerBoard S R2.0 using the Tinker_Board-Debian-Buster-v3.0.11-20211026 image. The only thing I did from the stock image was boot up and log in to WiFi. All good there. Now I’m just trying to configure system to run sshd at boot. I have it enabled. Systemd reports that it is enabled. I can start it manually when logged in. But it will not start at boot. There are no log entries. I turned on verbose logging in the sshd_config. Port is configured. The system also seems to report running out of inotify watch descriptors often. It will also report Failed to add /run/system/ask-password Initially the runlevel never made it past multiuser target. It was hanging in hostapd for some reason. (Hostapd seems to be having lots of failure entries in syslog, etc…) Also systemd time service (I forget the exact name at this time) was hanging. Disabling these two services using system disable allowed the runlevel to progress and achieve multiuser. But still no sshd. Also noticing rc-local.service and rockchip.service show failure using systemctl list-dependencies Of course systemctl status sshd shows dead. Any thoughts? I tried this on two boards, same results.