Created attachment 700035 [details] Shell script to work around this bug Unlike on other distributions with binary kernel packages that update the kernel automatically, running `emerge -uDNU @world` doesn't automatically trigger genkernel when a new kernel sources package is installed. I added a shell script as a temporary workaround, but adding post-installation triggers to all sys-kernel/<X>-sources packages to automatically set the new kernel sources and run genkernel post-merge would be a better move going forward. The attached shell script, for the record, also runs dracut as a callback instead of applying the 'all' option to genkernel because unlike genkernel's built-in initramfs generator, dracut supports Plymouth. Adding a configuration option to genkernel.conf to automatically run such a callback by default would also be a good idea, but that's something for another bug report entirely.
Created attachment 700044 [details] Shell script to work around this bug Updating the script to make the intention even clearer re: what I eventually want Portage to do by default whenever new kernel sources are installed.
Created attachment 700047 [details] Systemd service to delete old kernels on boot One of the downsides to automatic kernel updates is that it clutters /boot with a lot of old kernels; this solves that problem.
I leave this for bug wranglers to figure out what to do with this bug but just a few comments: Your proposed solution/idea will fit your specific use case but doesn't fit a general use case. For example, not everyone wants to upgrade immediately, not everyone wants to cleanup previous kernel immediately. Also, why are you using genkernel *and* dracut? For your use case you better try something like sys-kernel/gentoo-kernel which should do already what you proposed.
(In reply to Thomas Deutschmann from comment #3) > Also, why are you using genkernel *and* dracut? Because genkernel builds kernel images and dracut doesn't while dracut supports Plymouth and genkernel doesn't.
I doubt this is something we would actually want to implement in pkg_postinst. I am assigning this to the kernel team since they maintain the kernel source packages and this request specifically says "after kernel sources upgrade". Also copying dist-kernel since this overlaps with their work.
(In reply to Kenneth G. Strawn from comment #4) > Because genkernel builds kernel images This is what sys-kernel/gentoo-kernel is about.
(In reply to Thomas Deutschmann from comment #6) > (In reply to Kenneth G. Strawn from comment #4) > > Because genkernel builds kernel images > > This is what sys-kernel/gentoo-kernel is about. It's an older version than that produced by compiling from git-sources. Running dracut as a callback to genkernel and using "kernel" instead of "all" (i.e. tell genkernel to build the kernel but NOT the initrd) allows both newer kernels AND Plymouth support.
You have a specific request which you have to address on your own. I see nothing Gentoo can do for you. Well, actually we have solved your problem already: Like said, gentoo-kernel package is doing what you want. If you want to use different sources, either try to use user patch feature to patch sources the way you want it or get familiar with kernel-build eclass to write an own ebuild for your custom sources. And you could even write an ebuild utilizing genkernel and dracut.
Created attachment 700899 [details] My kernel configuration Another potential problem with sys-kernel/gentoo-kernel: if it's the same kernel as what's on the LiveCD, that means it's configured to support a *much* smaller range of hardware and features than mine.
(In reply to Thomas Deutschmann from comment #8) > > And you could even write an ebuild utilizing genkernel and dracut. I've already written a Catalyst .spec file doing just that which is attached to bug 784218. The use of dracut however is something another dev brought up which is completely beside the point of this bug ― the point of this bug is to patch the sources ebuilds so that they automatically build the kernel on kernel upgrade in other areas. Since that would interfere with my use-case, however, marking this invalid because it could break a lot of things including Catalyst.
(In reply to Kenneth G. Strawn from comment #9) > Another potential problem with sys-kernel/gentoo-kernel: if it's the same > kernel as what's on the LiveCD, that means it's configured to support a > *much* smaller range of hardware and features than mine. It's not. It's based mostly on the configs Fedora is using, and I haven't had any reports of hardware support missing in it.
Keep in mind that you can pass your custom kernel.config to any ebuild using kernel-build eclass via savedconfig feature (see USE=savedconfig).
Created attachment 700905 [details] Ebuild that gives users this option Reopening now that I found a solution
(In reply to Michał Górny from comment #11) > (In reply to Kenneth G. Strawn from comment #9) > > Another potential problem with sys-kernel/gentoo-kernel: if it's the same > > kernel as what's on the LiveCD, that means it's configured to support a > > *much* smaller range of hardware and features than mine. > > It's not. It's based mostly on the configs Fedora is using, and I haven't > had any reports of hardware support missing in it. Good to know. My config is based on Arch's which also supports a lot more hardware than the Gentoo live media default ― *and* also supports /proc/config.gz on top of that.
(In reply to Kenneth G. Strawn from comment #13) > Created attachment 700905 [details] > Ebuild that gives users this option > > Reopening now that I found a solution Please read genkernel man page. --kernel-config can read from /proc/config.gz already out-of-the-box. Your proposed solution has also disadvantages regarding current Gentoo solutions: For example, user will be unable to make kernel.config changes because you are always reading from current running kernel. Anyway, last comment before I will leave this bug: You want to read about https://wiki.gentoo.org/wiki/Handbook:X86/Portage/Advanced#Hooking_in_the_emerge_process
(In reply to Thomas Deutschmann from comment #15) > Your proposed solution has also > disadvantages regarding current Gentoo solutions: For example, user will be > unable to make kernel.config changes because you are always reading from > current running kernel. That's exactly why I created a new ebuild instead of patching an already-existing one. If merged into the tree correctly, users would be able to choose between auto-git-sources which automatically builds using src_postinst and plain git-sources which doesn't. Going to attach a tree patch that makes this ebuild its own separate package to make this choice clear
Created attachment 700929 [details] Add separate sys-kernel/auto-git-sources package Fixing some ebuild issues, including pulling in Arch's default kernel configuration when auto-building for the first time instead of using the already-running kernel's configuration.
The current ebuild draft violates Gentoo's package standards (QA). Personally I believe this is a specific solution for a specific problem and doesn't belong into Gentoo repository. But maybe you will find a developer who will proxy you... Kernel project is not interested in your proposed solution, sorry. Kernel project out.
I wonder if a 9999 version of sys-kernel/gentoo-kernel would be possible. That would definitely solve this problem.
gentoo-kernel is maintained by the dist-kernel team, we are not interested in the 9999 version. I am sorry.
