[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    Re: [OE-core] [PATCH] Revert "kernel: Fix symlinks"
From:       Otavio Salvador <otavio.salvador () ossystems ! com ! br>
Date:       2017-08-31 20:31:21
Message-ID: CAP9ODKrDFdUrFfx0cuV=_t9WG4x9_F0_-iZyjJMc-8K88TBhmA () mail ! gmail ! com
[Download RAW message or body]

Hello guys,

On Wed, Aug 30, 2017 at 6:16 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Tue, Aug 22, 2017 at 12:40 PM, David Vincent <freesilicon@gmail.com> wrote:
>> On vendredi 18 août 2017 14:44:30 CEST Otavio Salvador wrote:
>>> On Wed, Aug 16, 2017 at 3:15 PM, Otavio Salvador
>>>
>>> <otavio@ossystems.com.br> wrote:
>>> > This reverts commit c7bc46b9bc29dd0953ab8d63b50fa105bb66892e.
>>> >
>>> > The commit has broken the alternatives concept as it is managed by
>>> > links controlled by the alternatives system. That said the failing
>>> > case identified (which some bootloaders fail to load the file) seems
>>> > to be due a misuse of the alternative system.
>>> >
>>> > Cc: Christopher Larson <chris_larson@mentor.com>
>>> > Cc: Ross Burton <ross.burton@intel.com>
>>> > Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
>>>
>>> I ended forgetting to add the commit author on Cc. Adding now :-)
>>
>> This issue has been discussed here : http://lists.openembedded.org/pipermail/
>> openembedded-core/2017-April/135923.html
>>
>> Reverting this patch to solve the alternative problem cannot be a definitive
>> solution as it breaks boot on some boards. IMHO, I'd rather break the
>> alternative system than boot (full disclosure : I use opkg's update-
>> alternatives).
>>
>> As already said, absolute paths cannot be used in bootloaders since it may
>> point to an invalid location (rootfs may not be mounted). I do not have
>> another solution with plain 'ls', but I think we should find a way to better
>> handle all cases than going back and forth on this patch.
>>
>> FYI, this is my use case : I have a bootloader which resides in EEPROM, but
>> needs to boot kernels that can be upgraded. Therefore, I rely on a fixed path
>> to the last kernel / devicetree on a specific partition outside rootfs.
>
> I understand the problem you are fixing but the solution in use is wrong.
>
> We should stop using the update-alternatives for the kernel and device
> tree files and instead just use plain symbolic links. Abusing of
> update-alternatives is just wrong.
>
> In fact, the update-alternatives for this specific use case is broken
> as the database is elsewhere and so the link cannot be managed
> properly.

I am struggling on how to properly fix this problem ...

 - update-alternatives: due the use of a central database and the full
path links, some bootloaders are broken

 - using plain symbolic links is problematic especially when we remove
a kernel package. What should we do?

The plain symbolic link seems to be the best option but it does not
allow that multiple kernel versions are going to be installed in
parallel.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[prev in list] [next in list] [prev in thread] [next in thread]