Posts by procount

    OK, thanks. I'll sort it.
    You will still have to generate the sha checksum of your tar.gz files, but PINN will do the checking for you.

    I will provide guidance for you going forward.

    Apologies in advance if I take a while doing this - I'm juggling many plates!

    I have created a separate os_list for LibreElec, added the Pi5 version and updated the meta-data dates & versions.

    The meta files work, but I'm looking at some improvements.

    I note you have your own md5 checksums for kernel.mg and system. PINN can also use an sha512 checksum across the tar.gz files and partition_setup.sh file that you are not using at present. You could use them instead of, or in addition to, your own md5 checksum, or keep it as it is. Any thoughts?

    procount another question: do you support UUID=... instead of LABEL=... in partition setup now? Currently we still have label entries in partition.json but as LABELs can easily clash that's not ideal.

    By default PINN uses /dev/mmcblk0pX for SD card installations and PARTUUID on USB drives. These normally work well for most OSes.

    /dev/sdX can be forced for USB drives (e.g. for Android that doesn't use PARTUUID), or labels can be specified, but are not preferred as you have realised.

    If you don't need to use labels, I would suggest leaving it up to PINN to use PARTUUID or /dev/mmc as appropriate.

    I will look at your partition_setup.sh file for you, but its probably ok.


    procount

    is that the list that is pulled for the current images ? Wondering because there are only old releases listed.

    Yes, but the URLs point to your own release servers, so although the meta-data is out of date, it should still be installing your latest versions (I haven't checked!). This will be resolved when you have control over updating the os_list.json file yourselves.

    Hey guys,

    Thanks for the feedback & support!

    Let me review your metadata and update PINN to serve the latest LibreELEC versions. Then we can look at you managing your own os_list, so you can keep it updated and support multiple versions going forward.

    Thanks :)

    It was the last one I had before NOOBS was deprecated.
    If you have any later versions, I'd be happy to update them.

    Do you also keep old versions available, seeing as users have specifically requested 9.26 & 9.28?

    NOOBS does not perform upgrades. It's just a one time installer. It can install a newer version, but it would delete the old one first, along with any other OSes that were installed at the same time.

    Once LibreELEC is installed on the SD card, I guess it would be upgraded in the same way that it would be had it been copied as an image file. I'm not sure how the tar files or partition names would have any influence on that.

    For example, Raspbian would be upgraded with `sudo apt-get update; sudo apt-get upgrade`

    milhouse - We have investigated and conferred and agreed that you should ignore Mattrix's comments about the tarball parameter, in order to maintain compatibility with NOOBS.

    I've reviewed your Pull Request and it looks ok to me, as far as the partition name changes are concerned. The directory changes look ok as far as I can tell, but I guess you will test it further anyway. If you provide the URLs to the new tarballs I can perform a test by creating a dummy os_list.json file and test it installs ok under NOOBS and PINN before you ask the RPF to update their os_list_v3.json file.

    The System0, System1 issue is just NOOBS' way of making the partition name unique (which it must be) in case of a clash. I guess general users of LibreELEC would not normally see such partition names when using LibreELEC/Kodi, but anyone who can get to a shell can see them with lsblk, mount, fdisk etc. Maybe if you auto-mount additional partitions in Kodi you would see these partition names as the mount points? I don't know (sorry I'm not a big user of media centres).

    Well, even if the prefix clashed, NOOBS/PINN would still add an index to make them unique.

    Yes, it is possible to install both RPi1 and RPi2 versions on the same SD card (for reasons of e.g. creating an SD card for another RPi System), but it is not the default. The user has to add the `showall` option to the cmdline to enable this feature, otherwise it only shows OSes appropriate to the current RPi model it is running on.

    In PINN I'm adding an algorithm to reduce any overly long partition name to fit the file systems. You can see some examples in my initial NOOB issue post here ->LibreELEC labels · Issue #456 · raspberrypi/noobs · GitHub (and a link to a draft of the actual algorithm). Hopefully this contrived shortening will maintain the appropriate parts of the partition name to still be meaningful. I will probably push it as a PR to NOOBS, but it may not get implemented there as I indicated before.

    OK, so noobs/pinn will still work with System and Storage. It solves the immediate issue.

    I shall review your PR as is. Do you want me to just comment or approve? (Not done this process on Git before. Probably I don't have permissions to approve anyway!)

    Ahh, I missed that Lakka has this issue too! Maybe they could use LKSystem and LKStorage?

    There are 17 OSes listed in os_list_v3.json, none of which I have responsibility for. A lot do have just boot and root partition names. However, when you have installed several OSes alongside each other and their partition names are boot, root, boot0, root0, boot1, root1, boot2, root2 etc. it does become difficult to work out which is which!

    I have created noobs images of an additional 30 OSes (See pinn-os/os_all.json at master · procount/pinn-os · GitHub) that can be installed by PINN and mostly by NOOBs. In most cases I have chosen to add the OSname as a suffix to improve this situation, so I provide names like boot_void, root_void, boot_gen, root_gen etc. to easily distinguish them. (Although I too have some partition names that I need to adjust because they are too long as well)

    PINN can also install another 12 OSes from Matt Huisman's repository, which includes Rasplex that also uses System and Storage partition names.

    So if there are several OSes installed with "System" and "Storage" as their partition names, the second one will get renamed to System0 & Storage0, the third to System1 & Storage1 etc.

    So that's my rationale for adding a prefix, but you are free to choose as you wish.

    I will gladly review your PR, but let me know if you're going to stick with your naming or add a prefix, so that I only need to review it once. ;)

    Hi Milhouse, Thanks for getting back to me (and sorry for the late reply as I forgot to turn on email notifications for this forum :blush: )

    Yes, the tar files need to match the partition label names, as this is how NOOBS & PINN identify the tar file to be installed for each partition.

    "LEStorage" and "LESystem" would be fine.

    When performing a modification for NOOBS, please bear the following in mind:

    NOOBS can install LibreELEC from the internet, or from a local device (if the NOOBS distribution files have been previously downloaded).

    In the case of a local installation, it uses the default filename derived from the label specified in the "partitions.json" file.

    For an internet installation, it uses the tarball URL given in "http://downloads.raspberrypi.org/os_list_v3.json" which currently specifies the existing tarfile URLs such as: "http://releases.libreelec.tv/noobs/LibreELE…2_System.tar.xz" et al.

    So, if you change the partition names and associated tar file names, you need to notify the Raspberry Pi developers of this change so they can update their tarball references in os_list_v3.json file. Until this is done, you should keep both the old and new tarfiles in place, otherwise NOOBS users will not be able to download LibreELEC during this transition period. Once it is all in-sync again, the old tarfiles can be removed.


    As an aside, I have developed an algorithm for shortening partition names appropriately for their file system type in PINN to get around this issue, but it makes some assumptions and is unlikely to get into NOOBS for a while, if at all. But changing the partition names at the source will give a much more predictable outcome.

    Thanks.

    I'm the developer of PINN, a fork of NOOBS for the Raspberry Pi.

    I've noticed that the partition label names for LibreELEC in LibreELEC.tv/partitions.json at master · LibreELEC/LibreELEC.tv · GitHub are too long to be used as partition/volume labels. They currently have names like "LibreELEC_RPi2_System" and "LibreELEC_RPi2_Storage" derived from your distroname and project name.

    However, FAT partitions have a maximum label name of 11 characters, and 16 for ext partitions.

    NOOBS may also add a single digit to the label name to make it unique if necessary, further restricting the original name length to 10/15 characters.

    In addition, NOOBS will ignore any partition label >15 characters. This is what is happening in the case of LibreELEC and its partitions are not being labelled at all.

    This seems a bit of a bug in NOOBS, but the developers have indicated they are not planning any changes to NOOBS in the near future.

    So I suggest the partition labels used for LibreELEC are shortened to 10 characters so that their partitions are labelled correctly.

    I shall try to put a fix in PINN to workaround such issues, but even so it is not clear how to do this universally. For example, If the existing label names are truncated to 10 characters, both LibreELEC partitions will be given the same name before the single digit suffix is added to disambiguate them. Maybe LE2System and LE2Storage would be appropriate? But I'll leave it to you as it seems to revolve around some macro system. Whatever you choose, please ensure consistency with their associated tar files.

    In NOOBS, this is largely a cosmetic issue, but it makes identifying the partitions much easier if they have the correct names.

    In PINN it is blocking a new feature, so I will have to work around it somehow, but I'm sure it would be better if the partitions could be labelled consistently in the first place.

    Thanks.