Posts by chewitt

We have no idea (or our guess is as bad as your guess). There are multiple manufacturers of these generic boxes and some of them will save a few cents and put the cheaper S905W chip inside and there's no way to distinguish them without opening the case and looking at what's printed on the chip. S905W can do up to 4K30. S905X can do 4K60.

The "network error" bug is present since OE 3.2 ish but requires someone with python skills to debug it (so not me) and I've given up trying to entice someone on staff to look into it (90% sure it's an untrapped error message from dbus). It's not relevant. Also (for the record) changing the timezone in Kodi has zero impact on kernel wireless regulatory domain configuration - two completely unrelated things. What is relevant, is setting the correct regulatory domain. Which I already explained how to do.

echo "options cfg80211 ieee80211_regdom=DE" > /storage/.config/modprobe.d/cfg80211.conf

^ run that over SSH and change "DE" to the ISO country code for wherever you are and missing WiFI channels will normally appear.

You might get more success with GRUB as the bootloader instead of syslinux. ISTR those things have quirky boot.

LE includes the openvpn binary, but built for client use so missing capabilities needed to run as a server. Use a docker container.

Before you do anything with LE update the NUC firmware (which requires Intel's Windows-only updater).

If you force it to use /dev/sda1 and /dev/sda2 everything depends on device probe order (whichever gets probed first gets sda, next device gets sdb) and might change. If you want consistent behaviour use UUDI or LABEL instead.

[   28.101402] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.clm_blob failed with error -2
[   28.101410] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available

^ this stuff is harmless (most chipsets don't have clm_blob files) and can be ignored.

Not supported and no plans to support. Most of these STB boxes run Linux but with locked boot processes and code that prevent other Linux OS being installed.

I forget which add-on, but usb_modeswitch is included in one of our tools add-on packages

SSH into the box and run "dmesg | paste" and share the URL

I think the issue is local to your hardware. A bug is not impossible, but it's improbable. We've hardly touched the installer code in 2-years (and not recently) and that means ~50k+ successful 'Generic' installs over time. If there was a big problem we'd have a horde of pitchfork waving villagers putting the forums under siege.

Sorry I wouldn't know .. I haven't run 3.14 kernel images for some time now.

If you do this (which is not recommended) please make sure you disable password authentication and use ssh key auth.

If not .. you'll be able to find yourself in Shodan within 24 hours.

The LE settings add-on is always visible under "Add-ons > Program Add-ons" from the Home Menu in any skin. The shortcut icon in the Kodi settings menu is only visible in Estuary and Confluence (and maybe Aeon).

Some wireless devices mount as a read-only CDROM (so Windows drivers can be installed) and they need to be modeswitched or the "CD" needs to be ejected before the actual NIC shows up. See what happens in dmesg if you "eject /dev/sr0" from the command line. If that works (and the NIC appears) it's an easy task to write a udev rule that does this automagically when the USB ID is seen. Some/most of devices that do this also have a Windows utility app that allows the initial CDROM mode to be permanently disabled.

It's one of those lurking corner cases that needs someone to rework scripts. It will be needed once more hardware moves to mainline kernels because the situation with broadcom firmware in mainline is both better (lots of unnecessarily complicated hciattach stuff has been eliminated by serdev) and worse (the kernel is still in the early stages of supporting hardware with the new regime). As a broad rule there is reasonable coverage of chips and firmware but zero coverage of nvram configs, so having the ability to experiment with those from userspace will be rather useful.

LE contains routines to fsck the boot partition if errors are found but I'm not sure those also include the /storage partition. NB: The solution to repeated power-off disk corruption issues is either a) stop pulling the power before you shutdown, or b) get a UPS to work around whatever terrible power situation you have going on. It's better to prevent the problem than wrongly assume the problem is always fixable - at some point you'll trash an important disk sector and lose the data. It's one of those "when, not if" scenarios.