------- Comment From <email address hidden> 2020-07-20 12:57 EDT-------
(In reply to comment #19)
> On Fri, 26 Jun 2020 at 15:01, bugproxy <email address hidden> wrote:
> >
> > (In reply to comment #17)
> > > Eoan and later d-i, new installer, curtin do not install
> > > /etc/kernel-img.conf.
> > > Upgraded systems keep having it (ie. installed with bionic or xenial, and
> > > upgraded).
> > >
> > > Can you please let me know if _removing_ /etc/kernel-img.conf breaks $ sudo
> > > make install, and if adding /etc/kernel-img.conf back fixes $ sudo make
> > > install?
> > >
> > > Cause the expectation is that `/etc/kernel-img.conf` should not be there,
> > > yet everything should still work correctly.
> > >
> > > I think somewhere something is reading "link_in_boot=yes" and was not
> > > updated with the new implicit default to always assume that on recent ubuntu.
> >
> > For me the installkernel script (including in the current case "sudo
> > make install" from a mainline Linux tree) doesn't update the
> > /boot/initrd.img symlink.
> >
> > Interestingly a package upgrade for linux-generic does overwrite this
> > symlink.
>
> .deb package uses very different maintainer scripts / codepath, and is
> not the same operation as "sudo make install".
>
> I personally always build my kernels as debs, and install debs, rather
> than doing "sudo make install". But I am a distribution developer, and
> I care for .debs to work right. Kernel developers, I guess, are
> inverse, and care for "upstream" $ sudo make install to work.
>
> >
> > Not with the /etc/kernel-img.conf[0] and not without it either.
> > As before the /boot/vmlinuz link is always updated.
> >
>
> That is slightly concerning, as to how $ sudo make install, ever
> worked before..... Or what has changed since.
>
> Normally, $ sudo make install, should lookup if /sbin/installkernel is
> available, and call that to "do what it has to do, on a given
> distribution", and that script is shipped by the debianutils package
> which is required and must be installed always. And it hasn't been
> touched in ages.
>
> I wonder which arguments are passed to /sbin/installkernel by $ sudo
> make install. And whether the 4th argument is passed, and if it is
> empty, /, or /boot. It should be either empty, or /boot.
>
> --
> Regards,
>
> Dimitri.
So when I built on a beefy development server I usually copy a tar of the modules + bzImage + System.map and e.g.:
that works well on RHEL, Fedora, SUSE and I'm pretty sure it worked on Ubuntu only a week prior to me opening this Bugzilla. I also looked in the history
and didn't find anything so yeah I'm pretty confused how that
used to work on Ubuntu but I've even bisected like that (on Ubuntu) so have used that approach dozens of times.
Of course for us working with multiple distros there's a lot of value in
this working the same on all of them and I think that's the main point
of the installkernel script.
------- Comment From <email address hidden> 2020-07-20 12:57 EDT------- img.conf. img.conf breaks $ sudo img.conf back fixes $ sudo make img.conf` should not be there, img.conf[ 0] and not without it either.
(In reply to comment #19)
> On Fri, 26 Jun 2020 at 15:01, bugproxy <email address hidden> wrote:
> >
> > (In reply to comment #17)
> > > Eoan and later d-i, new installer, curtin do not install
> > > /etc/kernel-
> > > Upgraded systems keep having it (ie. installed with bionic or xenial, and
> > > upgraded).
> > >
> > > Can you please let me know if _removing_ /etc/kernel-
> > > make install, and if adding /etc/kernel-
> > > install?
> > >
> > > Cause the expectation is that `/etc/kernel-
> > > yet everything should still work correctly.
> > >
> > > I think somewhere something is reading "link_in_boot=yes" and was not
> > > updated with the new implicit default to always assume that on recent ubuntu.
> >
> > For me the installkernel script (including in the current case "sudo
> > make install" from a mainline Linux tree) doesn't update the
> > /boot/initrd.img symlink.
> >
> > Interestingly a package upgrade for linux-generic does overwrite this
> > symlink.
>
> .deb package uses very different maintainer scripts / codepath, and is
> not the same operation as "sudo make install".
>
> I personally always build my kernels as debs, and install debs, rather
> than doing "sudo make install". But I am a distribution developer, and
> I care for .debs to work right. Kernel developers, I guess, are
> inverse, and care for "upstream" $ sudo make install to work.
>
> >
> > Not with the /etc/kernel-
> > As before the /boot/vmlinuz link is always updated.
> >
>
> That is slightly concerning, as to how $ sudo make install, ever
> worked before..... Or what has changed since.
>
> Normally, $ sudo make install, should lookup if /sbin/installkernel is
> available, and call that to "do what it has to do, on a given
> distribution", and that script is shipped by the debianutils package
> which is required and must be installed always. And it hasn't been
> touched in ages.
>
> I wonder which arguments are passed to /sbin/installkernel by $ sudo
> make install. And whether the 4th argument is passed, and if it is
> empty, /, or /boot. It should be either empty, or /boot.
>
> --
> Regards,
>
> Dimitri.
So when I built on a beefy development server I usually copy a tar of the modules + bzImage + System.map and e.g.:
# sudo tar -xavf 5.8.0-rc6- 06703-g93c67d79 4cfc.tar -C /usr/ 06703-g93c67d79 4cfc bzImage System.map /boot
# sudo installkernel 5.8.0-rc6-
that works well on RHEL, Fedora, SUSE and I'm pretty sure it worked on Ubuntu only a week prior to me opening this Bugzilla. I also looked in the history
and didn't find anything so yeah I'm pretty confused how that
used to work on Ubuntu but I've even bisected like that (on Ubuntu) so have used that approach dozens of times.
Of course for us working with multiple distros there's a lot of value in
this working the same on all of them and I think that's the main point
of the installkernel script.