Posts by chewitt

Error code 110 is "ETIMEDOUT" i.e. connection timed out. I'm not sure knowing that helps though.

131 Linux Error Codes for C Programming Language using errno

Kodi doesn't build binary add-ons; that's left to distro maintainers to build/package them as needed for their users; so LE builds them and makes them available from our add-on repo.

The SD card will be /dev/mmcblk0 so as long as that /dev/device exists you can test writing with "dd if=/dev/random /dev/mmcblk0 bs=1m" and the OS will write random data to the entire card. It will take quite a while (larger card size = longer time) but if there are problems with the card (or reader hardware) it'll throw errors and hang/halt/barf on the task. To state the obvious; this will trash whatever data is currently on the card

AirPlay etc. require the router to replicate broadcast traffic that advertises the service on both wired and wireless segments. Some routers do that, and others don't. If the RPi cannot see the WiFi SSID; common reasons would be the SSID being hidden (ConnMan cannot see something that is not being broadcast) or the wireless regdomain might need configuring to align the radio properties.

It's a while since I shipped my Slice to another LE dev, but CM3 was a nice bump over CM1.

"computers"

In the absence of debug logs I'd make an educated guess that the keys that underpin the S in SFTP changed on the Synology side and while FileZilla is configured or defaults to ignoring that Kodi will probably flag the mismatch and fail. I'd have thought that kind of thing would be relatively obvious from logs though (although I never used SFTP for anything). See if clearing /storage/.ssh/known_hosts (or the old entries for the IP/FQNDs of the Synology target) makes a difference?

Quote from Zobi

So... I'll try this N100 fanless adventure, for 235 euros... It's more than 150 euros on RPi 5, but not so much (especially if it lasts 8 years also)... And the N100 is more future proof...

Estimated shipping in December 2023 as long as they accumulate enough backers. Dates on Indiegogo are often a little optimistic so good luck with the purchase

If it was already installed (and thus appended to $PATH at boot) the removal didn't alter $PATH in your current session and hence it should have been disoverable after reinstalling. If you uninstall > reboot > install .. it won't work again until another reboot or logout/login.

btw, this is the add-on icon.png that I created for a previous Argon addon attempt, based on the normal LE house-style/template.

Normally the "Disable SSH Password" option is used after configuring certificate authentication instead. So turn off the disable to allow SSH passwords again. If necessary (re)set the current password: there is deliberately no need to know the current one, it's just overwritten.

You need to reboot or logout/login after installing the binary add-ons else they aren't in the $PATH and can't be found.

I was wondering if the box was finding an older /storage partition from the older install, but blkid shows none of the partitions that exist on eMMC have partition GUIDs or names that would match so that's a dead end. And I meant "ssh" before, so that's not an issue.

You did mention running a custom OS and not the stock one, but I don't really see how that could impact on Linux since the box is still booting (vendor u-boot) and hooking it to boot LE from SD card. Both stock and current OS are likely to use the same u-boot code.

There's a pattern where services are waiting for things on the SD card second partition (/storage) to become available which results in some messages in the journal log, and the overall speed of boot looks a little slow to me. However I'm used to looking at logs from devices that boot from faster eMMC so that's just perception, and my boot logs also show similar messages: and ultimately /storage does mount and things do continue. I can't explain why the sshd.conf file hasn't been created automatically, but perhaps related to the second-boot failure to mount the storage partition. However boot scripts should still detect its absence on third boot and create that conf; it's not a one-time/first-boot only thing.

In short, I'm a little stumped

Have a look in config.txt (at the bottom) on the SD card. You probably configured an overlay which disables WiFi in device-tree.

Quote from LybsterKodi

EXT4 is often recommended here but what I don't know is how resilient is it. Will LE/KODI/EXT4 handle a power outage or is a repair going to be needed or what?

EXT4 is pretty robust but when it comes to power outages and the "what will I lose?" question, the reality is a dice roll with too many variables for anyone sensible to profer a guaranteed answer. The real question is "how much loss will you tolerate?" and then you spend appropriately so risk matches risk-appetite. As an example: I've invested thousands of man-hours ripping and recording a large private CD and Vinyl collection into FLAC format a few years ago and have zero plans to ever repeat the hurculean task. So I've spent on a local NAS with multi-disk redundancy and this is background sync'd over the internet to a second NAS parked with a relative with a fast internet connection. So I have both local and off-site redundancy on a multi-terrabyte media hoard. The proverb is "There are two types of IT user: those who take their backups seriously, and those who didn't lose all their data yet"

RPi4 cannot be switched on through a remote unless you add an IR/Power HAT. In this arrangement the HAT board is externally powered so the (always on) IR sensor can toggle 5V power to the board through the GPIO pins not the normal USB-C connector.

Feb 16 18:11:01 LibreELEC kernel: meson-vrtc c81000a8.rtc: registered as rtc1
Oct 25 09:21:39 LibreELEC kernel: rtc-hym8563 0-0051: registered as rtc0
Oct 25 09:21:39 LibreELEC kernel: rtc-hym8563 0-0051: setting system clock to 2023-10-25T09:21:39 UTC (1698225699)

^ the RTC chip seems to be doing its thing. Initial kernel time is taken from the glibc release date which is in the past but normally within six months-ish as LE uses a recent-ish release. The RTC chip is probed and then updates time, and then NTP (connman) is correcting time based on latest internet polled time:

Oct 25 09:21:48 LibreELEC connmand[891]: ntp: adjust (jump): +2.225134 sec
Oct 25 09:21:51 LibreELEC systemd[1]: Finished wait-time-sync.service.
Oct 25 09:21:51 LibreELEC systemd[1]: Reached target time-sync.target.

then a minute later crond shows this:

Oct 25 09:22:40 LibreELEC crond[489]: time disparity of 360911 minutes detected

^ I was thinking this is the RTC corrected jump between Feb 16 and Oct 25, but Google says that's 251 days and 360911 minutes is 240 days, so that doesn't line up correctly.

Oct 25 09:22:28 LibreELEC systemd[1]: sshd.service was skipped because no trigger condition checks were met.

^ this is also odd. The trigger conditions are either "sshd" in kernel command line (from boot params in uEnv.ini or extlinux.conf) or the file /storage/.cache/services/sshd.conf existing and that should be created on first boot.

If you do "touch /storage/.cache/services/sshd.conf && systemctl restart sshd" does the daemon start?

Can you also run "blkid | paste" and share the URL or output?

Also for kicks, please use https://chewitt.libreelec.tv/testing/LibreE…80.0-box.img.gz to boot in case some random bug has been fixed since the last LE11 release. This is an LE12 nightly from my own branch.