Posts by chewitt

    ^ minor changes to log uptime and background commands else they block boot. I do have a large media library so scrolling around will consume some RAM with caching and kids do play old SNES games somtimes (although they've been sent to grandparents for the next two weeks). The rest of our family usage is rather ordinary: watching media from a NAS in the LAN and streams from a remote Tvheadend instance.

    Code
    RPi5:~ # uptime
     17:00:37 up 12 days, 20:36,  load average: 2.62, 2.65, 2.67
    RPi5:~ # free -m
                   total        used        free      shared  buff/cache   available
    Mem:            8052        2177        4711         201        1461        5875
    Swap:              0           0           0

    This is LE13 (master) not LE12 but it's the same Kodi version in the image (not Piers, yet). Remind me in another couple of days and let's see if memory has substantially increased.

    I've some some Google searching on the error messages but didn't find anything conclusive. The card is using the unmtaintained Broadcom "wl" driver and there's been a few issues reported recently that just seem to point to kernel drift as a cause. In short, the kernel keeps moving forwards and this (not in-kernel) vendor driver has been in a static state for some years (at least a decade, maybe longer) and the phrase "if you're not moving forwards, you're going backwards" applies. Eventually the kernel has moved forward far enough that random stuff just starts breaking, and that seems to be the pain zone where we are now. The main option for LE will be to drop "wl" and swap to the in-kernel "b43" driver, but that's not brilliant (not really maintained since forever too) and lacks 5GHz support which will break some people's setups. It's probably the lesser of evils though.

    If you can swap the card for something else, it might time to investigate doing so. Most of the devices I've seen this cards in use some kind of PCIe card or mini-PCIe daughter-card so they can be pulled and inexpensively replaced with something better.

    Boot Debian or Ubuntu in Live mode. Erase the drive and:

    - Create a GPT partition 512MB in size with a VFAT or EXT4 filesystem labelled BOOT and enable it for boot

    - Create a GPT partition with EXT4 filesystem that fills 100% remaining space

    - Install Grub (not syslinux) to the internal drive and create a boot entry (crib the APPEND content from the LE installer usb).

    - Copy KERNEL and SYSTEM to the BOOT partition

    Shutdown Debian and see if it boots?

    Our forum is regularly targetted for product placement posts and although they are caught by moderation (and thus you don't see them) it's a chore and staff would rather help with an issue than deal with user-generated makework. The reason we exorcise those kind of posts is .. the more you allow, the more you're targetted. Kodi has a much larger moderation team and it's up to them to set their own rules, and CE can similarly do whatever it likes; but they don't support x86_64 hardware so not much point.

    You're welcome to post a simple link to the Radxa product page. I've already edited the original post to leave only the link to the CNX review, which being a formal product review, has a ton of info. Reposting the entire review or the entire product page; not welcome.

    My guess would be that those aren't actually "override", but they are always "fallback", and DHCP happens no matter what. That would totally explain what is happening at least.

    That would make sense to me, and does indeed explain the current behaviour.

    i'd prefer some script to issue that ntpd command

    The problem with that is you cannot disable ConnMan NTP checking so regardless of what date/time you set via a boot script (or cron task) there will be times when ConnMan runs an NTP check against the router and reverts the device to router time, until the next scheduled script NTP check that will correct it again.

    The better solution is to use a router that keeps time. The best solution is to author code that modifies ConnMan to optionally ignore NTP responses from routers (there are overrides for some other things, but not NTP). You can always submit the problem to the ConnMan mailing list and hope someone helps with that, but "You can have it fast or cheap, pick one" applies and $free requires someone on the list to feel kind or inspired enough to code something. Usually $free has a long waiting period.