On Fri, Apr 21, 2017 at 2:48 PM, Andreas Oberritter <o...@opendreambox.org> wrote: > 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.
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
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
