Created attachment 656510 [details] output from "emerge --info" I recently compiled a new kernel (5.4.60-gentoo-x86_64) and used "genkernel" to create an initramfs file. That combination would not boot correctly: I ended up with kernel panic, cannot locate root file system. I regenerated the initramfs file using dracut, and now my system boots fine. So I believe that genkernel (which I just updated yesterday) isn't working correctly. There's a discussion about this in the Gentoo forum: https://forums.gentoo.org/viewtopic-t-1118000.html. I'm sorry I can't be more specific. I can reproduce the boot error (I kept the old, faulty initramfs file). Let me know if there's something more you need. Thanks!
Like posted in the forum's thread it looks like you are not actually booting genkernel's initramfs -- the error msg is coming from kernel and did not confirm seeing any genkernel-related output.
You guys must think I'm stupid, or something. I'm 69 years old, and 45 years ago I was doing sysgens on an IBM S/360 Model 30. 256 K of main memory, and an 8k supervisor program. Two partitions: BG and F1. I've patched Autocoder programs (even though the 1401 / 1410 was before my time -- some old Autocoder programs were being run under emulation in some shops until 1990 or so), and over a period of 25 years I pumped out a couple of million lines of assembly language code. I still remember how: STM 14,12,12(13) (which means the same thing as "PUSH" in Intel assembler for the x86, more or less). I've used PDZAP (an IBM utility program that allowed direct hexadecimal modification of modules in the system load library) to fix errors made by IBM's ANSI Cobol compiler (i.e., I have fixed faulty machine language code generated by a buggy compiler, by hand). I may not be up to speed on Rust and C++ and PERL and all that stuff, but I debugged an awful lot of core dumps when I was working on the big iron. And I know a bug when I see one. Just to prove my point, I ran "emerge =sys-kernel/genkernel-4.0.10" followed by "genkernel --install initramfs". Then I booted into the 5.4.60 kernel successfully. So here's the situation. -- If I use an initramfs file created by genkernel-4.0.10, the system boots up OK. -- If I use an initramfs file created by dracut-049-r3, the system boots up OK. -- If I use an initramfs file created by genkernel-4.1.0-r2 the system dies with a kernel panic: cannot mount root device. Everything else remained the same. Same bootloader. Same kernel. Same grub.cfg file. Same BIOS. The only thing that changed was the initramfs file. The INESCAPABLE conclusion is that the initramfs file generated by genkernel-4.1.0-r2 is faulty. In other words, there is a bug in genkernel-4.1.0-r2. Or at least, there is a bug in the version of genkernel-4.1.0.tar.xz that I downloaded from a Gentoo mirror at ~6:30 pm CDT yesterday, August 23. YMMV. Frankly, I don't really care if y'all want to fix it, or not. That's up to you. I have done my part by reporting the error. See ya.
I am sorry if you got that impression. Fact is, *if* root detection within genkernel's initramfs is failing, you will get a different error message. The error message you are quoting is coming from kernel. Therefore I asked you if you see a message like > Genkernel 4.1.0 (<your build date>), Linux 5.4.60-gentoo-x86_64 early at startup which you didn't confirm yet. If even this message is missing it will indicate that genkernel's initramfs isn't used.
Created attachment 656616 [details] Terminal output. Gzip has CRC integrity check. XZ file doesn't have anything. The old genkernel (4.0.10) provided a crc value. The new genkernel (4.1.0-r2) has "check=none".
I'm not sure how I can view the ring buffer after the kernel dies. "dmesg" won't work, because /bin abd /sbin are inaccessible. Can I use some sort of grub shell command at that point? See the new attachment. I believe the kernel refuses to load an archive that has no integrity check information. Genkernel 4.0.10 used gzip compression, where CRC32 is provided by default. Genkernel 4.1.0-r2 is using xz compression, and apparently says "xz --check=none", because there isn't any integrity info in that initraamfs file. Look at man xz to see what I'm talking about. I found a reference to this problem at a web site. https://www.linuxquestions.org/questions/slackware-installation-40/booting-with-xz-compressed-initrd-4175599273/ I think you can resolve my bug report with this information. If you need me to recreate the kernel panic and try to read the ring buffer somehow, please help me understand how to do that. Thanks!
OK, I did get a couple of archives mixed up the other day. But I'm still right about one thing. Genkernel 4.1.0-r2 is applying xz data compression incorrectly. It needs to use "xz --check=crc32" or "xz --check=crc64" when compressing the cpio archive. I'll dig into the script sometime, and try to create a diff for you.
(In reply to David Bryant from comment #6) > OK, I did get a couple of archives mixed up the other day. Thank you for clarafication. > But I'm still right about one thing. Genkernel 4.1.0-r2 is applying xz > data compression incorrectly. It needs to use "xz --check=crc32" or > "xz --check=crc64" when compressing the cpio archive. I'll dig into the > script sometime, and try to create a diff for you. Sure? From https://github.com/torvalds/linux/blob/v5.8/Documentation/xz.txt#L56-L64 > Notes on compression options > ============================ > > Since the XZ Embedded supports only streams with no integrity check or > CRC32, make sure that you don't use some other integrity check type > when encoding files that are supposed to be decoded by the kernel. With > liblzma, you need to use either LZMA_CHECK_NONE or LZMA_CHECK_CRC32 > when encoding. With the xz command line tool, use --check=none or > --check=crc32. We are using > xz -e --check=none -z -f -9 (see https://gitweb.gentoo.org/proj/genkernel.git/tree/defaults/compression_methods.sh?h=v4.1.0#n34) which hasn't changed for years, compare for example with https://gitweb.gentoo.org/proj/genkernel.git/tree/gen_initramfs.sh?h=v3.4.52#n967
