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

1st Official Post

    If the kernel name is not KERNEL the update process fails on Generic x86_64 version 8.2.5, when the update file is a .img.gz. With .tar files as update all is fine.

    The problem is in packages/sysutils/busybox/scripts/init. The update process says "kern-82 or SYSTEM is missing". For me it looks like the UPDATE_KERNEL variable is wrong and the patch init_patch.txt fixed it for me, but i dont know if there is any impact on other architectures than x86_64. I commented out 5 line, because i could not figure out what theyshould do and they change UPDATE_KERNEL and that seems to be the problem.

    kernel command line

    kodi7:~ # cat /proc/cmdline

    root=/dev/ram0 rdinit=/init usbcore.autosuspend=-1 ip=dhcp boot=/dev/sda1 SYSTEM_IMAGE=sys-82 disk=/dev/sda5 ssh quiet BOOT_IMAGE=/kern-82


    Hardware:

    Asrock B360m itx with 8GB, 300GB, i3-8100 und uefi only mode

    NUC D34010WYK with 8GB, 250GB

    • Official Post

    BOOT_IMAGE isn't to be used on non android bootloader platforms. Please remove that along with SYSTEM_IMAGE.

    That would be very sad to dont use it. It is very usefull to me for some years to boot more than 1 OpenELEC/LibreELEC version on one box (after enlaging /flash of course). For me there are at least 3 version on my box: the stable one, the nightly and since 8.2 a patched version with Xin1 playback, which is not very stable.

    The BOOT_IMAGE is set by syslinux because of a kernel line with /kern-82. I set the SYSTEM_IMAGE in the kernel command line.

    It is very practicle to have multiple LibreELEC versions on one box (each one with its own /storage) and to use the automatic update within. I do select them with the help of menu.c32 or vesamenu.c32 and some rewritten syslinux.cfg.

    I can rewrite my patch to only act on the Generic version (if i can find out in the init script which one is booting). Or should i make a feature request of it? If not i can live with only using .tar for updates.

    I think this is a valid issue, and a quirk of the img update mechanism, so I'll look into fixing this. Unfortunately as with anything that touches init even trivial changes usually require a disproportionate amount of testing so it's a good thing you can self-build. :)

    This commit should do the trick. I will try changing my community build and check. Tomorrow i am on vacation for 5 days and will have time to check it.

    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.