Posts by chewitt

    Code
    #################################################################
    # Installing syslinux to /tmp/installer/part1
    #################################################################
    
    /dev/nvme0n1p1: unsupported sectors size

    (as before) the installer fails to install syslinux to the NVME drive and no bootloader = no boot.

    If you have a standard non-fancy drive around you can see if that works (to isolate the issue to NVME vs SATA) but it's likely due to some oddity with NVME drive firmware. I'm unsure what the solution/workaround is with syslinux so install grub to the (otherwise fine) nvme drive instead of syslinux and see what happens.

    Google reports there are 387,000 results for "install grub bootloader" so plenty of things to read.

    The add-on base version is bumped occasionally during development; meaning over time there are multiple versions of the add-on repo and a specific LE nightly will pull add-ons only from it's hard-coded version-matched repo. We aim to keep current and one-previous nightly repo version around (although only the current one will receive updates) and we delete older repos to save disk space over time which means old nightlies will often have no add-ons available. It's not clear from your explanation whether this is an LE11 or LE12 nightly, but I'd guess LE12 and that's likely the problem. Unless you want to build your own add-ons, the sole solution is to update to a current release (with current repo).

    NB: while it will boot, Zero 2W is no longer supported due to being 512MB RAM size. I'm also not aware of any issues with Samsung SD cards over 32GB, and anything with major boot impact like that would normally be a high priority firmware or kernel issue for the Pi developers to resolve.

    Create an Ubuntu Live USB and see if that boots. If it does, grub works (where syslinux does not) and you can do a manual LE install to the NVME drive using grub as the bootloader. Create a GPT partition scheme on the drive with two partitions: BOOT (512MB/VFAT) and STORAGE (100% remaining space/EXT4) and setup the grub boot entry using the data in syslinux.cfg as a general guide for boot params.

    Capturing and setting persistent EDID data will prevent LE from seeing disconnect/connect events on the HDMI connection. This might help the AVR not loose sync, or it might not (my gut feel is it won't).

    There's nothing to prevent you from using one HDMI port for video and one for audio. Just configure it.

    I'd guess the SD card is a newer/faster one and doesn't get reset properly after the initial boot and thus can't be read-from. If you find an old/slow SD card without fancy fast modes it will probably work. Using the USB adaptor sidesteps such issues.

    NB: AMLGX is not perfect. If you want to nit-pick on what works/doesn't, you can save fingers from typing forum reports about this/that test file because a) I know there are bugs, b) I know nobody is working to fix them. I'd like to see improvements of course, but until there are some, the reports aren't interesting. Best results come with using the mode whitelist and adjust-refresh. Using "sync playback to display" will probably cause more issues that it might solve. If it works for you, that's nice. If it doesn't, /shrug

    If you want to run things like teleconferencing apps on-screen side-by-side with Kodi you need a desktop or app environment where such apps exist, e.g. Ubuntu/Fedora or (don't laugh) Android or Windows. LE is not what you're looking for; unless it's being run in a virtual environment (with GPU mapped to the VM) to handle media-client activities under one of the dedicated NAS distros that allow such things.

    Please provide a full debug log.

    How to post a log (wiki)

    1. Enable debugging in Settings>System Settings>Logging
    2. Restart Kodi
    3. Replicate the problem
    4. Generate a log URL (do not post/upload logs to the forum)

    use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link

    There is nothing to stop someone changing how the OS is packaged to add more users and run apps/services under different creds, but the OS was originally and intentionally designed to keep things super-simple and running under a single user is part of that. The UX design goal is to achieve 99% of tasks in the GUI and thus negate any need to go near the console (which is default disabled) and the fact the entire core of the OS is read-only largely prevents users from causing problems with errant commands. Users can rm -rf their Kodi config but in most cases a simple reboot will regenerate anything essential so the main risk is losing personal media; and users accessing their own media under their own share don't need sudo for that task anyway.

    From a security perspective running everything is root is bad (no disputing that) but I've spent the last decade in/around DFIR work for my day-job and I have observed real attackers and red-team staff compromising LE devices and while I have seen devices being accessed (via known passwords) the attacker has ultimately lost interest in the device because either our distro packaging defeats scripts and other attack tooling and/or because attacker Linux knowledge/assumptions are based on the RHEL/Ubuntu derived world and/or because they couldn't ascertain what the device was for and were cautious as a result. Attackers were never able to compromise devices with basic controls deployed; i.e. SSH/SMB disabled and the firewall enabled. I'd also argue that if you are a genuine target of interest to a real actor, the "runs everything as root" LE box in your home network is the least of your worries.

    There are known issues with some of the RK devices and resolutions at the moment (there are some threads in the RK section of the forum). I'm not actively following but I believe they are being looked into.