[OE-core] [PATCH] Revert "kernel: Fix symlinks"

[Andrea Adami]

On Fri, Apr 21, 2017 at 2:48 PM, Andreas Oberritter <obi at opendreambox.org>
wrote:
> On Fri, 21 Apr 2017 14:37:36 +0200
> David Vincent <freesilicon at gmail.com> wrote:
>
>> On 2017-04-21 13:30 GMT+02:00 Andreas Oberritter <obi at opendreambox.org>:
>> > On Fri, 21 Apr 2017 13:02:51 +0200
>> > Andrea Adami <andrea.adami at gmail.com> wrote:
>> >
>> >> On Fri, Apr 21, 2017 at 12:39 PM, Andreas Oberritter
>> >> <obi at opendreambox.org> wrote:
>> >> > This reverts commit c7bc46b9bc29dd0953ab8d63b50fa105bb66892e.
>> >> >
>> >> > It broke dpkg's update-alternatives, which requires absolute paths.
>> >>
>> >> This is really uncommon.
>> >
>> > Actually it's not. Try it on any Debian or Ubuntu system.
>> >
>> >> I had already expressed my negative opinion about absolute paths for
kernel [1].
>> >> Personally, I had to patch the bootloader (kexecboot).
>>
>> Same here, that's why I submitted it in the first place. Didn't
>> thought that would break dpkg...
>>
>> >>
>> >> So please try some workaround instead of changing it back.
>> >
>> > Well, there's no workaround. Other than opkg's update-alternatives,
dpkg's maintains
>> > an alternatives database in /etc/alternatives, so the symlink is going
to point to
>> > an absolute path outside of /boot anyway.
>>
>> The problem is that, for bootloaders, it is not always possible to
>> mount the rootfs. So, it must only rely on information in the boot
>> partition that can be mounted anywhere.
>
> I understand the problem the patch tried to address.
>
> Those bootloaders don't find the kernel by chance. The name of the image
> is usually set in the environment. You can update the environment in
postinst-
> scripts or just change the name of the kernel image to match the
bootloader's
> expectations, just to name some alternatives.
>
>> >
>> > To fix your problem, kernel.bbclass should be changed to not use
update-alternatives
>> > at all. But it's definitely wrong to break the original u-a by using
invalid command-
>> > line arguments.
>> >
>>
>> And reverting this patch breaks boot for those who rely on a relative
>> symlink ; that is also wrong.
>
> Yes. However, I'd argue that a regression is worse than a problem that
> persisted for years.

We lived for years with the relative symlink.

Then  78ee4d8  broke the bootloaders in 2014
Finally it was reverted end 2016 and now it is under review again...ouch

What broke what?

My point is, while I had the sources and could modify and reflash the
bootloader, the same is not valid for many people.

Anyway, I have found out that there was a workaround to allow boot from NFS:

+ROOTFS_POSTPROCESS_COMMAND += "make_zimage_symlink_relative;"

Cheers
Andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170422/09f7fb7d/attachment-0002.html>