Posts by milhouse

  • Can't browse SMB shares on Krypton version

    Quote from tiho

    I just made new install latest Libre elec on Pi3+ , no SAMBA , I'm with Win 7 , tried to find some tutorial - no any success . Any help ?

    We don't even know what the problem is - are you having a problem accessing your Windows share from LibreELEC, or are you having a problem accessing the LibreELEC shares from Windows?

    Assuming the former, have you read the blog which explains you must now enable authentication when accessing the Windows share (create a username/password in Windows, add this user to your Windows share, use this username/password when accessing the Windows share from LibreELEC).

  • Accessing network problems, again- (Kind-of)SOLVED!

    Quote from Billzilla

    I tried on the W7 pc, I turned on sharing needing a password (Change Advanced Sharing Settings) but it never asks for a password in any menu I can find.

    Windows allows you to set the password of a user when you create the new Windows user - that's where you set the password, in the Windows "User Accounts" Control Panel. If you haven't created a user *with a password* then you won't be able to authenticate using SMB when connecting to a Windows share as Microsoft recently made authentication mandatory. Once you've created the Windows user with a password, add this user to your Windows share with the relevant Windows file permissions.

    When you access the share from LibreELEC (with default settings) you should then use the new Windows username/password for authentication.

    Also, you have posted the contents of your passwords.xml where you appear to be using a username/password of kodi:kodi (all lowercase), but then in one of your Windows screenshots you've added a user called Kodi (uppercase K), and in yet another screenshot you're using a user called libreelec. This conflicting information doesn't make solving this issue any easier, but points more strongly towards an incorrect configuration.

    If you've tried accessing the Windows 10 share from Windows 7 and you are not being prompted for a username/password in Windows 7, then you have not configured the Windows 10 share correctly.

    If Windows 7 can't access the share then then chances are something is hosed on your Windows 10 PC, perhaps you've twiddled one too many random knobs.

  • [SOLVED] LibreElect won't "auto" boot

    durnehviir so there's no confusion, are you having a problem booting the USB flash drive (the "installer"), or are you having problems booting from your internal hard drive after the "installer" has installed LibreELEC to the hard drive? If the latter can you tell me which of these two files you have on the HDD: /flash/extlinux.conf or /flash/syslinux.cfg.

    Also, can you paste the output from the following command when you boot LE from your HDD:

    Code
    ls -la /sys/firmware/efi

  • Just one syslinux.cfg to edit for BIOS/UEFI

    Quote from sky42

    I see a potetial problem or two.

    A old installation is updated with a image with PR 2698. After that the user does getedid which changes syslinux.cfg, but it is a UEFI system with a existing /flash/EFI/BOOT/syslinux.cfg and getedid only changes /flash/syslinux.cfg. So the UEFI system will still use the /flash/EFI/BOOT/syslinux.cfg which is not changed.

    getedid will continue to update /flash/EFI/BOOT/syslinux.cfg if it exists AND the user has booted using UEFI. If the file doesn't exist (never installed, or deleted by the user) or the system is not booting with UEFI, then getedid will update /flash/syslinux.cfg.

    Quote from sky42

    Move the /flash/EFI/BOOT/syslinux.cfg to /flash/EFI/BOOT/syslinux.cfg.off will solve that. Deleting it may destroy work in syslinux.cfg what somebody did on his box.

    Cleaning up an existing installation is likely to be a case of damned if you do, damned if you don't.

    Moving /flash/EFI/BOOT/syslinux.cfg to /flash/syslinux.cfg is all fine, so long as the user doesn't mind having their non-UEFI config overwritten (which may contain custom changes).

    And if we were to delete /flash/EFI/BOOT/syslinux.cfg then again we're potentially losing custom changes that may not be in /flash/syslinux.cfg.

    Currently (in PR2698) we do neither, *except* when the user is booting in "run" mode when we know the file we're deleting is always an exact copy of /flash/syslinux.cfg, so no custom changes will be lost.

    After PR2698, clean installations will not have /flash/EFI/BOOT/syslinux.cfg, but users with upgraded installations can choose to move or delete the file if they wish (and they should, to avoid future confusion).

    Going forward I imagine any documentation will refer only to /flash/syslinux.cfg as referencing two files is confusing, and we'll just have to deal somehow with legacy installations (ie. "Delete /flash/EFI/BOOT/syslinux.cfg - you don't need it").

  • 2 init boot hooks and kernel argument to configure SYSTEM_TORAM_LIMIT (patch included)

    For building LibreELEC with encryption support we'll need to discuss that in a separate PR, which hopefully you'll be able to push yourself in due course. It's not likely to be a trivial change, so it will need careful thought/consideration - it's a niche feature, so we need to weigh that up.

    I'm happy to leave the post-flash and mount-storage hooks in my current PR, as they could in theory have a general applicability and be useful even without encryption, unless anyone posts an objection on the PR.

    To include encryption in the kernel we'd need to see what impact it has (kernel size, performance overhead) but that can all be discussed in a PR, so that would be the next step.

  • 2 init boot hooks and kernel argument to configure SYSTEM_TORAM_LIMIT (patch included)

    I just re-read your reply and see that mounting an encrypted /storage partition is also your goal.

    I've pushed an extra commit to the PR so that init will now call your script if it exists rather than mount /storage - it would be up to your script to mount /storage as $disk. Obviously the script must now be in /flash, and I've named it mount-storage.sh. I'm not sure where your crypto binaries are stored but presumably they will be accessible before /storage is mounted.

    If we ever wanted to support full disk encryption natively then I'm sure there would be a cleaner solution than this but I'm not really familiar with disk encryption or what packages are available, and also suspect this would be a pretty niche feature. :)

    So hopefully with the PR, you can now:

    1) capture your password/passphrase using /flash/post-flash.sh

    2) mount an encrypted /storage partition with /flash/mount-storage.sh

    3) automount encrypted external drives after replacing [email protected] with something suitable

  • Update with <new le>.img.gz failes when BOOT_IMAGE=/kern-82

    I've tested the change and it now works when upgrading a custom kernel filename from img (tested x86_64 and RPi2).

    However this change will only be included in LE9.0 and you'll need to upgrade once from tar file to get onto a version which includes the fix, and then subsequent updates from img should work. Until all your kernels include the fix you should continue upgrading from tar files.

    While testing an RPi2 installation with a custom kernel filename I discovered an issue with RPi installations so I've added an additional commit for that.

    Thanks for bringing this issue to our attention.

  • 2 init boot hooks and kernel argument to configure SYSTEM_TORAM_LIMIT (patch included)

    Oh OK, so this isn't about mounting an encyrpted /storage partition - instead you're mounting encrypted disks (ie. media drives) but need to capture the encryption password/passphrase during the boot sequence.

    Rather than mount disks in autostart.sh, you could replace the [email protected] with your own systemd mount service so that it mounts your encrypted disks as they are connected/reconnected. You could then also access your encrypted drives as automatically shared Samba shares.

  • 2 init boot hooks and kernel argument to configure SYSTEM_TORAM_LIMIT (patch included)

    Quote from sky42

    I was just excided that i finally did take the time to share my work in the forum and i like giving it back. And sometimes a nice sideeffect is that i have something less to maintain.

    Yep, everybody wins! :)

    Once you get the hang of it, submitting Pull Requests to github.com is actually easier than the forum, and is likely to catch the attention of a developer much sooner too.

  • 2 init boot hooks and kernel argument to configure SYSTEM_TORAM_LIMIT (patch included)

    I've got some initial commits here: Comparing LibreELEC:master...milhousevh:le90_init_sky42_patches · LibreELEC/LibreELEC.tv · GitHub

    Can you review the changes and post back in this thread. I know there are three threads discussing different suggestions which are all bundled up in the one branch but keeping the discussion on topic in each of the threads might make things easier.

    I've taken the liberty of modifying your patch slightly:

    1) use "ramlimit=####" instead of SYSTEM_TORAM_LIMIT=####

    2) fold the post-* functions into mount_flash() and mount_storage(), eliminating the extra build steps

    3) use "/storage/.config/post-storage.sh" instead of "/storage/.config/post-update.sh"

    I'm still a little unclear on what you are using the "hooks" for so I've added them as a commit that can be easily dropped if necessary.