Update problem

  • I'm guessing it's an older OE install that was cross-graded to LE at some point. OE used a 235MB boot partition and LE 7.x/8.x are around 230MB so fit within that partition size constraint. The LE 9.0 image has grown a little due to drivers and such and the 235MB boot partition is now too small to host the files so the upgrade aborts. To fix this you have two choices:


    a) Backup the LE 8.2.5 install and move the backup file off-box, then clean install LE 8.2.5 (which gives you a 512MB boot partition) and then restore the backup; then update to LE9.0. This is normally the fastest option as most LE installs only have 1-4GB of actual Kodi data on the /storage partition that needs to be backed-up and moved and the reinstall/restore process is quick.


    b) Boot an Ubuntu (or similar) LiveUSB and use gparted to shrink and then relocate the /storage partition to create space for the boot partition to be size expanded to 512MB or 1GB (whatever you fancy). This is normally the slower of the two options as you end up moving 31GB of data on disk.

  • How exactly do I move the backup file off-box? Secondly, how do I do a clean install without using the backup itself while the existing OS is already on there? I guess I'm asking, could you dumb it down a bit for me please.

  • When LE formats a storage device, the FAT partition is usually small, and the majority is taken by the Linux partition. Please check the size of the FAT partition. As user chewitt mentioned, you can use "GParted Live" a) to shrink the Linux partition and b) expand the FAT partition.


    Of course you can start from scratch, too. A fresh installation will take the right FAT partition size.

  • Format the whole disk. After that, you should have a single Windows-readable partition. Then run the LE installer. The LE installer will reformat the disk, and you will get the two mentioned partitions - now with the right size of the FAT partition.

  • How exactly do I move the backup file off-box? Secondly, how do I do a clean install without using the backup itself while the existing OS is already on there? I guess I'm asking, could you dumb it down a bit for me please.

    The backup file is in /storage/backup so use WinSCP to transfer over the network, or if a USB drive is locally connected (and mounted) you can copy the file using 'cp' from the SSH console or the Kodi FileManager in Kodi settings.


    Or if you don't care about any of the existing data. Create an install USB using the USB/SD Creator app and boot/install. The install process will nuke everything on whatever device you install to.

  • Just an FYI (I've got a lot of these lately), the 'in-app' updater (Main Menu -> LibreElec -> Updates) acts differently, than dropping the ".img" file in ".update" (and rebooting) when upgrading from 8.2.x to 9.0.x


    The 'in-app' updater does not appear to 'migrate' configuration settings, skin, and add-ons (as per my recent experiences updating all the units I've deployed), so I've avoided 'that' method, and have had 100% success (so far) with the 'full image file' method...


    EXCEPT !! 2 installed add-ons appear to have frequent issues with the upgrade (Confluence and Lame) which are 'auto-disabled' during the process, and have to be 're-enabled' and 'updated' manually, before they can be used again...

    Edited once, last by yubby ().

  • The only difference between updating from .tar file (in-app or external file) or using the .img.gz or .img (external file) is that we have to unzip and loop mount the .img file first. With the .tar file all we need to do is unpack it. There is no other difference, and Kodi handles migration of data not the LE (OS) update process. Add-ons are often a problem when updating to a new Kodi version, but that's nothing LE specific.

  • Yes, as long as the 2 'packages' contain the same contents, and are both installed during the 'reboot' process (where I get to watch the ASCII terminal text of it unpacking, check-summing, and installing), it 'should' behave in the same manner.

    BUT, it hasn't, which is the odd thing...

    Also, with the add-ons which get auto-disabled during the process, it may point to specific Kodi configurations, where the 'order' of the steps is blocking or being negated due to prerequisites of specific steps not being met (i.e. check for add-on updates, 'before' deciding whether the add-on is to be disabled). The 2 add-ons that I've experienced the issue with (Confluence and Lame) are in the official Kodi repository, which you'd think 'would' be auto-updated...

  • BUT, it hasn't, which is the odd thing...

    And what is the difference? In both cases /flash/KERNEL and /flash/SYSTEM files are updated.

    Better support for Amlogic devices: use CoreELEC

    Blu-ray Disc Java menus support - forum thread, Github

    my lamp addon (unofficial/community with limited support)
    my touchscreen support and instructions by Grruhn (now touchscreen addon exists in repository)

  • Yes, 'those 2' steps are performed, but as mentioned in my original utterance (above), the 'peripheral' items appeared (to me at least, but someone 'liked' my post, which may indicate that they have experienced the same issue) to have been 'skipped', such as migrating the current 'skin' and it's settings, and other configuration items...


    AH ! But now that I think about the issue realized (made apparent) during the '.img' file installation method, if the Confluence add-on is being 'auto-disabled', then the skin and it's "settings" would NOT be migrated (would they ?)....


    And the 'encoding' settings for RIPing CD's are lost, since there's no 'encoder' (LAME being auto-disabled)..


    SO, if there 'is' an issue with add-ons being auto-disabled (rather than being 'updated' from the Kodi repository), then 'that' may be the 'only' issue, which if resolved, would solve the issues that 'I' have encountered with the updates.... (results may vary)

  • Kodi v17 and v18 are different with different features. Settings that exist in both will "migrate" to the newer version. Settings that never existed before the new version will need to be set. This has been true of all Kodi releases since I've run in the last decade. In most cases add-ons should self-update on first run of the newer version, but there may be reasons why that didn't happen and resulted in things being disabled. The main reasons are that you have old versions of Kodi binary add-ons are installed that are no longer API compatible and nothing newer is available. If all the add-ons were disabled you had a corrupted add-on DB leading to migration failure. In this case the problem add-on DB is cleared and automatically regenerated, but all the add-ons are disabled to prevent issues.