On Fri, 21 Apr 2017 14:37:36 +0200 David Vincent <freesili...@gmail.com> wrote:
> On 2017-04-21 13:30 GMT+02:00 Andreas Oberritter <o...@opendreambox.org>: > > On Fri, 21 Apr 2017 13:02:51 +0200 > > Andrea Adami <andrea.ad...@gmail.com> wrote: > > > >> On Fri, Apr 21, 2017 at 12:39 PM, Andreas Oberritter > >> <o...@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. Regards, Andreas -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
