Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 690028 - sys-kernel/genkernel-4.0.0_beta4 freezes due to elog message
Summary: sys-kernel/genkernel-4.0.0_beta4 freezes due to elog message
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Genkernel Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-07-16 22:14 UTC by Mike Auty (RETIRED)
Modified: 2019-07-17 01:02 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Auty (RETIRED) gentoo-dev 2019-07-16 22:14:58 UTC
First off, glad to see some progress on genkernel, it hasn't seen much love in a long time!  5:)

Just wanted to point out that one of the last elog statements uses backticks, meaning that:

elog "Please remove `emerge @module-rebuild` from genkernel config"

actually runs emerge @module-rebuild, and makes it look like the entire process has hung.
Comment 1 Thomas Deutschmann (RETIRED) gentoo-dev 2019-07-16 22:30:14 UTC
Uhm, interesting... I think this is a bug within portage. Anyway, I'll replace backticks, thank you for the report. I am looking forward for some genkernel-4 feedback once you are able to merge.. :-)
Comment 2 Larry the Git Cow gentoo-dev 2019-07-16 22:30:52 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=71a2982a32c7fa4e27f3c22b04ec9ae7de50bdcf

commit 71a2982a32c7fa4e27f3c22b04ec9ae7de50bdcf
Author:     Thomas Deutschmann <whissi@gentoo.org>
AuthorDate: 2019-07-16 22:30:26 +0000
Commit:     Thomas Deutschmann <whissi@gentoo.org>
CommitDate: 2019-07-16 22:30:44 +0000

    sys-kernel/genkernel: remove backticks from elog
    
    Closes: https://bugs.gentoo.org/690028
    Package-Manager: Portage-2.3.68, Repoman-2.3.16
    Signed-off-by: Thomas Deutschmann <whissi@gentoo.org>

 sys-kernel/genkernel/genkernel-4.0.0_beta4.ebuild | 2 +-
 sys-kernel/genkernel/genkernel-9999.ebuild        | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
Comment 3 Thomas Deutschmann (RETIRED) gentoo-dev 2019-07-16 22:36:14 UTC
PS: Of course not a portage bug. Just my fault. Sorry and again, thank you for the report. :)
Comment 4 Mike Auty (RETIRED) gentoo-dev 2019-07-16 22:41:45 UTC
It installed fine with a Ctrl+C, and I've already tested and it booted fine too!  5:)  Thanks for the speedy patch regardless!

The only other feedback I've got is that the initramfs was 6Mb larger than my previous ones and I realized that's because the intel microcode is now getting rolled in to each initramfs.  I previously had a /boot/intel-uc.img which got added as an additional initrd line, which allowed the early loading, and meant that when the intel-microcode package got updated, it automatically updated on next boot too (without my having to rerun genkernel).  Also, since I'm somewhat oldschool, I still have /boot on a separate 200Mb partition, so the extra 6Mb every kernel is going to chew through that much quicker.  I might have a hack at allowing the microcode to be loaded as a second initrd line at some point, it seemed like quite a tidy way of keeping the space usage down and keeping the microcode up-to-date.  5:)

Ah, something I do have is a patch to add systemd-boot support to the gen_bootloader code.  I can file that as a separate bug if bugs.g.o is the right place for it?  I didn't know if genkernel had a different home now?
Comment 5 Thomas Deutschmann (RETIRED) gentoo-dev 2019-07-16 22:56:07 UTC
(In reply to Mike Auty from comment #4)
> The only other feedback I've got is that the initramfs was 6Mb larger than
> my previous ones and I realized that's because the intel microcode is now
> getting rolled in to each initramfs.  I previously had a /boot/intel-uc.img
> which got added as an additional initrd line, which allowed the early
> loading, and meant that when the intel-microcode package got updated, it
> automatically updated on next boot too (without my having to rerun
> genkernel).

You can still do that and genkernel should be recommending that, see the code in https://gitweb.gentoo.org/proj/genkernel.git/tree/gen_initramfs.sh?h=v4.0.0_beta4#n1732:

The problem is that we don't have anything in repository which will provide the same like /boot/intel-uc.img for AMD. Therefore, for backward compatibility, adding MCU to initramfs is the default. But when you tell genkernel you are only interested in MCU for Intel processors, you will see a hint to disable --microcode-initramfs and use the /boot/intel-uc.img method instead.


> Ah, something I do have is a patch to add systemd-boot support to the
> gen_bootloader code.  I can file that as a separate bug if bugs.g.o is the
> right place for it?  I didn't know if genkernel had a different home now?

I remember you from https://github.com/robbat2/genkernel/pull/23 -- still on my list.
Comment 6 Thomas Deutschmann (RETIRED) gentoo-dev 2019-07-16 23:01:10 UTC
PS: And sys-firmware/intel-microcode[hostonly] will only install MCUs for your processor which will save you some bytes as well.
Comment 7 Mike Auty (RETIRED) gentoo-dev 2019-07-17 01:02:30 UTC
Ah, that USE="hostonly" trick is perfect, thanks!  5:)

Sorry about the pull request, I guess it fell off the bottom of my list.  I'll revisit it and make the suggested changes.

Apparently, I already discovered the joy of in-kernel microcode[1] on my laptop!  5:P  No wonder my systemd entries didn't have an additional initrd line!  So no more intel-uc.img needed anyway...  5;)

[1] https://wiki.gentoo.org/wiki/Intel_microcode#New_method_without_initram-fs.2Fdisk