Posts by DavidGA

    I think "ignore SB_RDONLY when mounting nfs" is the problem:

    See this discussion:

    Making sure you're not a bot!

    Relevant parts:

    Quote

    When mounting the second NFS, the shared superblock is marked as ro,
    causing the previous NFS mount to become read-only.

    To resolve both issues, the ro flag is no longer applied to the superblock
    during remount. Instead, the ro flag on the mount is used to control
    whether the mount point is read-only.

    I don't know exactly how this applies to the problem here, but it sure smells the same. In my case, both the boot and disk mounts are subdirectories of the same NFS share.


    I can confirm that if you make boot= and disk= completely separate NFS mountpoints, the problem goes away.

    If this can't be easily fixed, it should at least be documented.

    I checked out that thread, and tried adding vers=3 params, but that made no difference. (The mounts were vers=3 already, so I didn't expect it to.)

    My NFS server doesn't support v4, if that's the issue, I can't test it. I hope that the problem is not "only NFSv4 is supported now" because lots of servers don't support v4. The "manage-gids" thing seems to be a red herring since that isn't enabled on my server.

    Bisecting this is a lot of work but I'll get back to you if I find the time.

    When booting LibreELEC 12.0.2 on a Pi using NFS netboot, the /storage mount is mounted "ro", which breaks everything.

    I added "textmode" to cmdline.txt and then did mount -o remount,rw /storage, which worked fine, which seems to rule out a server issue.

    My cmdline.txt looks like this:
    boot=NFS=<NFS server IP>:/path/to/boot disk=NFS=<NFS server IP>:/path/to/disk ssh ip=dhcp quiet console=ttyAMA10,115200 console=tty0

    This works in 12.0.1, but is broken in:
    12.0.2
    12.0-nightly-20250404-5c24d2b
    13.0-nightly-20250410-fe6b62d

    Tested with both the Pi 4 and Pi 5 version, same results.

    I want to add my voice to how important fixing this limitation is. Right now, on a Pi 4, depending on whether DRM PRIME is enabled or not, you can choose to be able to play interlaced video (which includes most live TV), or 4K video (which cannot be decoded in software on a Pi 4 in real time).

    This is a huge regression from LibreELEC 9, which can do either without having to change a system setting in-between.

    Thanks, but that really just explains how the whitelist works, which I already understand. This is obviously a bug, in that it's not detecting all the available modes offered by the receiver/TV, I just don't know if the bug is in Kodi or the specific libreelec implementation of it.

    I'm running LibreElec 9.2.6 on a Pi 4, and some resolutions are missing from the whitelist. In particular, although there is a 3840x2160p at 25Hz, there are no other resolutions available at 25Hz - it's not listed for 1080p or 720p. This makes watching PAL material a pain.

    Additionally, 480p resolutions are listed, but there are no 576p resolutions.

    These resolutions are listed as supported at Video options in config.txt - Raspberry Pi Documentation so they should be possible.

    I tried forcing hdmi_group=1 in config.txt but it didn't make any difference.

    Is this a known issue? If not I can make a log file.