Genkernel 3.4.0-r1 makes non-bootable initramfs. It stops trying to mount real root. Compare to older version of genkernel the new one tries to init "mdev" instead of "udev".
Could you please try to provide some more information? What kernel are you using? What genkernel options on the command line?
The files created by genkernel boot perfectly for me on the 300 or so kernels that I've built during the course of the 3.4.0_pre series, so I'm not sure where you're getting off that it doesn't work. I'd assume that this is either kernel or configuration specific.
As for it "stops trying to mount real root" what is the actual error message?
kernel is 2.6.17-gentoo-r4, processor amd64
kernel configuration is taken from /etc/kernels from older kernel
the same kernel compiled with genkernel 3.3 works.
It stops during startup:
>> Loading modules
:: Scanning for ehci-hcd........
>> Activating mdev
Then follows message from /init that mdev is not found. I dont remember the
message exactly, i should have to emerge genkernel and recompile kernel again.
The difference is here. Older genkernel does not activate mdev but udev.
Genkernel 3.4 then complains that it cannot find root filesystem /dev/hda3 and
needs entry other filesystem or start shell.
Genkernel 3.3 continues with:
>> Determining root device...
>> Mounting root...
>> Booting (initramfs)
Yeah, I'm not really concerned with genkernel 3.3, at all.
What if you use a different kernel configuration?
Like, say... the one I'm about to attach?
Created attachment 93300 [details]
2.6.17 kernel config for amd64
With your configuration and genkernel 3.4 is error still here:
>> Activating mdev
/init: 216: mdev: not found
>> Determining root device..
!! Block device /dev/hda3 is not a valid root device..
!! The root block device is unspecified or not detected.
Please specify a device to boot, or "shell" for a shell...
genkernel 3.3 works fine.
I have the same problem on x86 with genkernel 3.4.0-r1 and kernel 2.6.16-beyond4.1 (using lvm2 + reiser4 root).
Identical kernel boots fine with genkernel 3.3.11d.
In my opinion, such issues show that important packages such as genkernel 3.4 should stay (at least) ~x86 and ~amd64 for a bit longer...
It doesn't matter. Nobody ever tests the thing or gives feedback until it goes stable anyway.
As for your reiser4, genkernel is known to be somewhat busted building on a reiser4 filesystem (not for a reiser4 filesystem) and we have no real plans on trying to fix it until reiser4 is considered a supported filesystem.
What I am not understanding is how you are not getting mdev built. It builds for all 2.6 kernels by default. Exactly what options are you using with genkernel? And please don't tell me that 3.3 worked *again*. I really don't care as they're different code bases, so it's comparing apples to oranges. No offense. It just gets old. Especially since 3.3 had *way* more problems, udev being one of them, that affected *way* more people and blocked our ability to build the 2006.1 release. The package was in testing for over 2 months without a single complaint. I have successfully built over 300 kernels with it on several architectures. I honestly don't know what you guys could be doing, or have on your systems, that is affecting the mdev build, other than possibly a broken genkernel.conf file.
Broken /etc/genkernel.conf - solved, thanks for idea. I forgot to make etc-update. It would be nice to have version check in /etc/genkernel.conf, when the old configuration file can block system from booting.
Oops, my last response didn't get through.
Sorry, I wasn't aware that 3.4.0 got so much testing. My genkernel.conf is up to date, so I guess I have a different problem. IIRC I don't have the "mdev" error message, and when I enter the shell, I don't have a /dev/mapper directory. Should I file another bug ?
(In reply to comment #9)
> Oops, my last response didn't get through.
> Sorry, I wasn't aware that 3.4.0 got so much testing. My genkernel.conf is up
> to date, so I guess I have a different problem. IIRC I don't have the "mdev"
> error message, and when I enter the shell, I don't have a /dev/mapper
> directory. Should I file another bug ?
Yes please :)