Posts by milhouse

  • Image from the compilation of LibreELEC cannot be installed on Intel NUC5i5RYH

    gprintemps how sure are you that the NUC is rebooting, and it's not actually Kodi crashing and restarting? These are two VERY different failures.

    Assuming this is in fact Kodi crashing, then boot the NUC using your USB stick, enter the "live" mode of the installer, allow LibreELEC to start and complete the startup wizard making sure you enable ssh. Connect to the system with ssh (username: root, password: libreelec), mount your internal system disk (usually /dev/sda1, and what would normally be /flash), edit syslinux.cfg (most probably the version in EFI/BOOT) and add "ssh" to the end of the kernel command line (the line that begins "APPEND"). Save the file, then shutdown, remove the USB and boot the system normally.

    Connect to the "rebooting" system with ssh (username: root, password: libreelec) then run the following commands:

    Code
    paste $(ls -1art /storage/.kodi/temp/kodi_crashlog* | tail -1)
journalctl -a | pastebinit

    and paste the two links.

  • [SOLVED] -Update to 8.1.0 on Generic Failed - "XZ-compressed data is corrupt - system halted​"

    The 8.1.0 installer booted without a problem from a cheap old USB memory stick. At the moment, other than corruption/hardware failure, I'm not sure what else to suggest. Maybe run memtest86+ to test your RAM?

    Edit: Just to add I used the "LibreELEC USB-SD Creator" (Windows, 64-bit) application to create USB memory stick. Don't write the 8.1.0 img.gz file directly to the USB memory stick (as that won't result in a bootable memory stick) - it needs to be uncompressed to .img, and then the .img written to the memory stick (the "USB-SD Creator" application handles all of this automatically). You probably know all of this already as you have a working 8.0.2 system but just in case... we've all done it. :)

  • [SOLVED] -Update to 8.1.0 on Generic Failed - "XZ-compressed data is corrupt - system halted​"

    Quote from ceekdp

    When the installer starts from USB where does it try to extract the kernel to? USB or internal hard drive?

    Neither, the compressed kernel is booting in RAM (read from the USB). You should be able to boot the USB without a hard drive being attached.

    Quote from ceekdp

    Have you upgraded any part of your Revo? Are you still using the original HDD? Could this be a hardware issue with the HDD?

    No upgrades, it's still got a 250GB HDD. Haven't made any changes to it in the 7 or 8 years I've had it.

    Quote from ceekdp

    I had a look at the bios and I couldn't see anything that looks out of the ordinary. Would you have any suggestions?

    Thanks again for looking into this for me. It is much appreciated.

    Kind Regards,

    ceekdp

    I'd need to look at my BIOS, but if 8.0.2 installs normally then in theory 8.1.0 should too. Can you try a different USB memory stick, it's _very_ unusual for the USB to not boot - either the KERNEL file is corrupt or the USB memory stick is corrupt.

    When you are upgrading, you are dropping the new tar file into the Update Samba share and rebooting? You're not extracting the contents of the tar manually (which you no longer need to do).

    I'll also write the 8.1.0 img to a USB and try booting the installer in my Revo3700.

  • 8.1.0 Beta - SystemD unmounts fail due to -c parameter not existing

    Can you post your nfs service:

    Code
    cat /storage/.config/system.d/storage-test.mount | pastebinit



    I've tested an NFS mount based on the default nfs.mount.sample (pastebin) but can't see a problem:

    I've tested this with 8.0.2, 8.1.0 and also LE9.

    Looking at the systemd source code there's no evidence it adds the "-c" argument when unmounting:
    systemd/mount.c at v232 · systemd/systemd · GitHub

  • [SOLVED] -Update to 8.1.0 on Generic Failed - "XZ-compressed data is corrupt - system halted​"

    I've installed 8.0.2 on my Revo3700 and upgraded to 8.1.0 without any problem (using both img.gz and .tar for the upgrade).

    I also regularly deploy my test builds (.tar) to my Revo 3700, again without any issue.

    Have you installed 8.0.2 to the internal hard disk of the Revo 3700? It all sounds like you're somehow booting from the wrong media, possibly a BIOS issue?

  • v8.0.0: Device crashes when entering suspended mode (nVidia driver issue)

    Quote from djhifi

    Is this solved?

    It would require someone testing with affected hardware and the latest 384.59 driver (which you can find in these LE9/Kodi 18 test builds) to know for sure.

    There is one mention of a suspend bug fix in 384.59 but it only applies to SLI so is unlikely to be responsible for the issues reported in this thread, but you never know what else might have been fixed...

    384.59 will be in the next LibreELEC 8 official release (once Kodi 17.4 is released).

  • rtl8812au wifi dongle on RPi 3

    giannia many thanks. Unfortunately there's been another report of an RTL8821 user losing support (this time in the Kodi RPi test thread) so given I've only got a fairly small sample of test users (about 250) it's probably not a good sign for the overall LibreELEC user base. Given that, I'm going to revert back to the v5.1.5 driver with broken AC from the paspro repository as of tonight. I guess it's better to have something that kind-of/mostly works for everyone rather than have something that works well for only a subset of existing users.

    If anything significant changes in future then I'll revisit this, but for now I think I'm done...

  • rtl8812au wifi dongle on RPi 3

    Quote from zaphod24

    I have this device

    {USB_DEVICE(0x7392, 0xA812), .driver_info = RTL8821}, /* Edimax - EW-7811UTC */

    which apparently uses the 8821 and not 8812 driver. Excited that AC might finally work for others, but for now I guess I'm capped at 5.1.5. Is there any hope in getting the 8821 device(s) working with 5.2.9?

    It's possible, but not looking terribly likely at the moment. The new rtl8812au driver doesn't include the HAL support for 8821AU/8814AU, and that's the only drawback to this driver.

    So at the moment a switch away from the old 5.1.5 driver would mean your hardware is no longer supported, but rtl8812au users would have working AC (based on feedback so far).

    I don't know if it will be possible to continue using the older 5.1.5 driver for non-rtl8812au users - we may need to investigate that - or else we stick with the older and somewhat broken driver as that "works" for everyone. Ideally the HAL support for the other chipsets would be merged into this newer driver, giving the same support as before, but it appears that chipset support is becoming a little fragmented with the more recent drivers provided by Realtek.

  • rtl8812au wifi dongle on RPi 3

    Hi rtl8812au users.

    There's a new rtl8812au driver in a recent LE9/Kodi18a1 test build, based on the work done by gordboy.

    The download details and initial feedback (working/stable AC connection) are here, and it would be really great to have more testing and feedback in order for us to make a more informed decision about switching to this new driver.

    Unfortunately this new driver does not support rtl8821au and some other chipsets that the older driver may have supported, so there could be some fallout but hopefully not too much.

    I'll start including this new v5.2.9 driver in future nightly LE9/Kodi 18 builds from tomorrow, Tuesday (#0718).

  • Libreelec 8.2: Errors compile project Generic (Nvidia driver)

    Quote from Ed68

    Hi, This is not cosmetics, after running libreelec reports that there is no X-Window. Computer ION 3 --> old nvidia driver.

    Satisfy the design? From you, I do not require anything simply to report an error. I can not do it.

    Ed68.

    It is cosmetics - you see these nvidia warnings now since scripts/image: print depmod errors by kszaq · Pull Request #1371 · LibreELEC/LibreELEC.tv · GitHub, and we also know why you see them and it has nothing to do with your system not working (you'll see these warnings on a system that does work perfectly). We may try to fix these warnings in future but as they're cosmetic and not important it's not high on the priority list.

    Post the Xorg.0.log and dmesg from your system that doesn't work.