<div dir="ltr"><br><br>On Fri, Apr 21, 2017 at 2:48 PM, Andreas Oberritter &lt;<a href="mailto:obi@opendreambox.org">obi@opendreambox.org</a>&gt; wrote:<br>&gt; On Fri, 21 Apr 2017 14:37:36 +0200<br>&gt; David Vincent &lt;<a href="mailto:freesilicon@gmail.com">freesilicon@gmail.com</a>&gt; wrote:<br>&gt;<br>&gt;&gt; On 2017-04-21 13:30 GMT+02:00 Andreas Oberritter &lt;<a href="mailto:obi@opendreambox.org">obi@opendreambox.org</a>&gt;:<br>&gt;&gt; &gt; On Fri, 21 Apr 2017 13:02:51 +0200<br>&gt;&gt; &gt; Andrea Adami &lt;<a href="mailto:andrea.adami@gmail.com">andrea.adami@gmail.com</a>&gt; wrote:<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;&gt; On Fri, Apr 21, 2017 at 12:39 PM, Andreas Oberritter<br>&gt;&gt; &gt;&gt; &lt;<a href="mailto:obi@opendreambox.org">obi@opendreambox.org</a>&gt; wrote:<br>&gt;&gt; &gt;&gt; &gt; This reverts commit c7bc46b9bc29dd0953ab8d63b50fa105bb66892e.<br>&gt;&gt; &gt;&gt; &gt;<br>&gt;&gt; &gt;&gt; &gt; It broke dpkg&#39;s update-alternatives, which requires absolute paths.<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; This is really uncommon.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; Actually it&#39;s not. Try it on any Debian or Ubuntu system.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt;&gt; I had already expressed my negative opinion about absolute paths for kernel [1].<br>&gt;&gt; &gt;&gt; Personally, I had to patch the bootloader (kexecboot).<br>&gt;&gt;<br>&gt;&gt; Same here, that&#39;s why I submitted it in the first place. Didn&#39;t<br>&gt;&gt; thought that would break dpkg...<br>&gt;&gt;<br>&gt;&gt; &gt;&gt;<br>&gt;&gt; &gt;&gt; So please try some workaround instead of changing it back.<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; Well, there&#39;s no workaround. Other than opkg&#39;s update-alternatives, dpkg&#39;s maintains<br>&gt;&gt; &gt; an alternatives database in /etc/alternatives, so the symlink is going to point to<br>&gt;&gt; &gt; an absolute path outside of /boot anyway.<br>&gt;&gt;<br>&gt;&gt; The problem is that, for bootloaders, it is not always possible to<br>&gt;&gt; mount the rootfs. So, it must only rely on information in the boot<br>&gt;&gt; partition that can be mounted anywhere.<br>&gt;<br>&gt; I understand the problem the patch tried to address.<br>&gt;<br>&gt; Those bootloaders don&#39;t find the kernel by chance. The name of the image<br>&gt; is usually set in the environment. You can update the environment in postinst-<br>&gt; scripts or just change the name of the kernel image to match the bootloader&#39;s<br>&gt; expectations, just to name some alternatives.<br>&gt;<br>&gt;&gt; &gt;<br>&gt;&gt; &gt; To fix your problem, kernel.bbclass should be changed to not use update-alternatives<br>&gt;&gt; &gt; at all. But it&#39;s definitely wrong to break the original u-a by using invalid command-<br>&gt;&gt; &gt; line arguments.<br>&gt;&gt; &gt;<br>&gt;&gt;<br>&gt;&gt; And reverting this patch breaks boot for those who rely on a relative<br>&gt;&gt; symlink ; that is also wrong.<br>&gt;<br>&gt; Yes. However, I&#39;d argue that a regression is worse than a problem that<br>&gt; persisted for years.<br><br>We lived for years with the relative symlink.<br><br>Then  78ee4d8  broke the bootloaders in 2014<br>Finally it was reverted end 2016 and now it is under review again...ouch<br><br>What broke what?<br><br>My point is, while I had the sources and could modify and reflash the bootloader, the same is not valid for many people.<br><br>Anyway, I have found out that there was a workaround to allow boot from NFS:<br><br>+ROOTFS_POSTPROCESS_COMMAND += &quot;make_zimage_symlink_relative;&quot;<br><br>Cheers<br>Andrea<br><br></div>