when booting a kernel built with genkernel 3.4.0-r1 and it needs to access dmraid devices i have the following: >> Activating mdev... >> Activating Device-Mapper raid(s)... >> Determining root device... >> The root block device is unspecified or not detected Please specify a device to boot, or "shell" for a shell... boot() :: no chances to make it work through the shell. the same kernel (2.6.16-gentoo-r13) built with genkernel 3.3.11d works fine. maybe something is messed up in mdev (genkernel 3.3.11d uses udev instead of mdev)?
What command line options do you have when booting your kernel? Also, what options did you pass to genkernel when you compiled your kernel?
grub.conf: title=Gentoo Linux 2.6.16-gentoo-r13 kernel (hd0,2)/boot/kernel-genkernel-x86-2.6.16-gentoo-r13 root=/dev/ram0 real_root=/dev/mapper/isw_bhahgcdbb_RAID_Volume14 init=/linuxrc udev dodmraid vga=791 initrd (hd0,2)/boot/initramfs-genkernel-x86-2.6.16-gentoo-r13 and the kernel / initrd were built with: genkernel --menuconfig --dmraid all i am supposing that the problem may be in busybox-1.1.3, because in genkernel 3.3.11d busybox is busybox-1.00-rt-mdstart.plasmaroo.tar.bz2 + busybox-1.00-headers_fix.patch while in genkernel 3.4.0 is busybox-1.1.3+gentoo.tar.bz2 and (very fast) looking at the code i've seen mdev is only mentioned in the newer, while busybox-1.00 still uses plain udev. later i am going fetch busybox-1.2.0 to the genkernel pkg/ directory, editing /etc/genkernel.conf and trying to build the same kernel/initrd...
tried with busybox-1.2.1, same problems. downgraded to genkernel 3.3.11d and masked >= 3.4.0 as other users reported in forums, going into the ash shell and doing a ls /dev it points out that i don't have a /dev/mapper, but instead a /dev/device-mapper, so if it looks for real_root=/dev/mapper/isw_bhahgcdbb_RAID_Volume14 it will not find it
same problem here with a nvidia-soft-raid i had only a /dev/device-mapper in the ash shell solution: masked genkernel-3.4* and used 3.3.11d please add a warning to genkernel-3.4*, that the system can probably not to be start, if you use dmraid with it - otherway downgrade to genkernel-3.3.11d tanks
*** Bug 144487 has been marked as a duplicate of this bug. ***
I've got this one too -- I'm assuming its an mdev issue also -- /dev/mapper and subsidiaries are not created. Shouldn't this be enough to keep 3.4.* in ~arch?
No. ~arch isn't for bugs, it's for ebuild testing... Besides, this, we asked *repeatedly* for release testers, and nobody came across this problem. The solution is to patch genkernel, release 3.4.1, then get 3.4.1 stable. Moving a package back to ~arch should really *never* be done. For everyone that had a failure, if you move to /dev/device-mapper/* does it work? We won't be downgrading genkernel, and we plan on using mdev from now on, so this needs to be "resolved" either through documentation, or big fat warnings telling people that they need to change their bootloader configurations. However, before we do that, I want to ensure that /dev/device-mapper stuff is created properly. The /dev/mapper stuff was all an artifact of udev and was only added by the custom udev rules. In other words, it isn't the standard kernel device node, and shouldn't be used for anything critical, anyway.
All the LVM2 guides I saw, all mention /dev/mapper. I don't even have a /dev/device-mapper directory (after normal bootup). How is it obtained ?
(In reply to comment #7) > For everyone that had a failure, if you move to /dev/device-mapper/* does it > work? i've tried that, but still it's not able to find the root old grub.conf: title=Gentoo Linux 2.6.17-gentoo-r4 kernel (hd0,2)/boot/kernel-genkernel-x86-2.6.17-gentoo-r4 root=/dev/ram0 real_root=/dev/mapper/isw_bhahgcdbb_RAID_Volume14 init=/linuxrc udev dodmraid vga=791 initrd (hd0,2)/boot/initramfs-genkernel-x86-2.6.17-gentoo-r4 new grub.conf: title=Gentoo Linux 2.6.17-gentoo-r4 (test) kernel (hd0,2)/boot/kernel-test-x86-2.6.17-gentoo-r4 root=/dev/ram0 real_root=/dev/device-mapper/isw_bhahgcdbb_RAID_Volume14 init=/linuxrc udev dodmraid vga=791 initrd (hd0,2)/boot/initramfs-test-x86-2.6.17-gentoo-r4 still no idea... maybe removing the "udev" command line option could bring to something? i'm gonna try
I have the same problem with LVM2.
> Besides, this, we asked *repeatedly* for release testers, and nobody came > across this problem. Well, whoever made the switch to mdev didn't test it thoroughly enough. That's not the users fail. > The solution is to patch genkernel, release 3.4.1, then > get 3.4.1 stable. Moving a package back to ~arch should really *never* be > done. Agreed > For everyone that had a failure, if you move to /dev/device-mapper/* does it > work? Well, not for me. /dev/device-mapper is not even a directory on my system; it's a character-device. > We won't be downgrading genkernel, and we plan on using mdev from now on, so > this needs to be "resolved" either through documentation, or big fat warnings > telling people that they need to change their bootloader configurations. Well, if you really want to go through with such a switch, then as long as (a) it doesn't work and (b) there's still references to udev in genkernel, then this is a bug which needs to be resolved (without ""). BTW: What is the reason for dumping udev anyway? > However, before we do that, I want to ensure that /dev/device-mapper stuff is > created properly. The /dev/mapper stuff was all an artifact of udev and was > only added by the custom udev rules. In other words, it isn't the standard > kernel device node, and shouldn't be used for anything critical, anyway. /dev/mapper is there (if I remember correctly) to make sure that device-nodes are more or less consistent between versions. Claiming the something shouldn't be used just because it's a part of udev is an invalid IMHO. If that was the case, then mdev should be dumped too and we should all return to the good old mknod-days.
(In reply to comment #11) > Claiming the something shouldn't be used just because it's a part of udev is an > invalid IMHO. If that was the case, then mdev should be dumped too and we > should all return to the good old mknod-days. This should have been: Claiming that something shouldn't be used just because it's a part of udev is not valid IMHO. If that was the case, then mdev should be dropped too and we should all return to the good old mknod-days.
tried without the "udev" commandline option, no luck. as Martin said, /dev/device-mapper isn't a directory. so i've issued a dmraid -ay to see if it was able to find my array, but none was detected. then a dmraid -V told me this: dmraid version: 1.0.0.rc10 (2006.xx.xx) shared dmraid library version: 1.0.0.rc10 (2006.xx.xx) device-mapper version: unknown so there is something wrong loading device-mapper?
(In reply to comment #11) > > Besides, this, we asked *repeatedly* for release testers, and nobody came > > across this problem. > > Well, whoever made the switch to mdev didn't test it thoroughly enough. That's > not the users fail. It is impossible to test for things we don't have the hardware to test. This is exactly why we had it in testing for 2 months, plus had over 50 "Release Testers" and not a single person found this bug. I'm sorry, but bashing on the hard work of others that volunteer their time for free is simply shitty. > Well, not for me. /dev/device-mapper is not even a directory on my system; OK. This wasn't apparent from any of the earlier posts. That helps. > BTW: What is the reason for dumping udev anyway? It was broken on nearly every architecture with regards to genkernel, causes us countless bugs every release, and is overly complex and large for our needs.
(In reply to comment #13) > tried without the "udev" commandline option, no luck. > > as Martin said, /dev/device-mapper isn't a directory. > so i've issued a dmraid -ay to see if it was able to find my array, but none > was detected. > then a dmraid -V told me this: > dmraid version: 1.0.0.rc10 (2006.xx.xx) shared > dmraid library version: 1.0.0.rc10 (2006.xx.xx) > device-mapper version: unknown > > so there is something wrong loading device-mapper? That appers to be the case. Was device-mapper built, and do you have the modules? Did the module names change recently? Can you attach your .config to this bug, please?
(In reply to comment #14) > (In reply to comment #11) > > > Besides, this, we asked *repeatedly* for release testers, and nobody came > > > across this problem. > > > > Well, whoever made the switch to mdev didn't test it thoroughly enough. That's > > not the users fail. > > It is impossible to test for things we don't have the hardware to test. This > is exactly why we had it in testing for 2 months, plus had over 50 "Release > Testers" and not a single person found this bug. > > I'm sorry, but bashing on the hard work of others that volunteer their time for > free is simply shitty. I'm sorry if it appears like I'm "bashing" anyone. It was not really my intension. It was simply a response to the claim that it was the users own fault for not testing it thoroughly during the unstable fase. Anyway, this is hardly the place for a heated argument about blame, so I will stop here. Let's just solve this bug. > > BTW: What is the reason for dumping udev anyway? > > It was broken on nearly every architecture with regards to genkernel, causes us > countless bugs every release, and is overly complex and large for our needs. Do you have any documentation for mdev? I tried to find some on bosybox's homepage, but without any luck.
Created attachment 94997 [details] kernel's .config file
(In reply to comment #15) > That appers to be the case. Was device-mapper built, and do you have the > modules? Did the module names change recently? Can you attach your .config to > this bug, please? > i think device-mapper was not built, since i'm not able to find the dmsetup binary when dropping into the ash shell on startup... but i don't have any device-mapper related error in the output of genkernel where should i look for the modules? and, last, there was an update to device-mapper some weeks ago, but it didn't bring any problem to the system
I also have this Problem with LVM2, but I'm writing to offer an excuse. I had this problem since gentoo-sources-2.6.17-r4 now (had genkernel and gentoo-sources in testing), so I could have reported it long ago, but I thought "surely I misconfigured my kernel, I'll wait till I have my new monitor, before I try resolving the bug" (I only accessed my system via xdmcp, only seldom via connecting a monitor, so I was too lazy to bug my roommate for his monitor to do deeper testing). I'm sorry, that I didn't tell you earlier. I know, that this doesn't fix the problem, but I think it is appropriate anyway, because I profit very much from your work, and since I missed contributing via a bug report, offering an excuse is the least I can do. And besides that: Thank you very much for your work!
(In reply to comment #18) > i think device-mapper was not built, since i'm not able to find the dmsetup > binary when dropping into the ash shell on startup... but i don't have any > device-mapper related error in the output of genkernel livecd / # ls -la /lib/modules/2.6.17-gentoo-r7/kernel/drivers/md/dm-mod.ko -rw-r--r-- 1 root root 61413 Aug 29 01:54 /lib/modules/2.6.17-gentoo-r7/kernel/drivers/md/dm-mod.ko At least the driver was built. Now, if dmsetup was not built, then genkernel would have died during release building thanks to lines 713 and 714 of gen_compile.sh, so it isn't that. > and, last, there was an update to device-mapper some weeks ago, but it didn't > bring any problem to the system Well, genkernel is a self-contained system and does not use the ebuilds for device-mapper. You could try updating your genkernel.conf to use a newer device-mapper tarball and see if that resolves the issue. >
I managed to solve the problem by updating genkernel.conf. Here's what i changed (didn't remember to copy the old version somewhere before changing, so can't give a diff): ----------------------------- MODULE_INIT_TOOLS_VER="3.2.2-r1" MODUTILS_VER="2.4.27-r1" DIETLIBC_VER="0.30-r1" UDEV_VER="099" DEVICE_MAPPER_VER="1.02.09" LVM2_VER="2.02.09" ----------------------------- Maybe genkernel could do these updates itself, since I'm sure many users aren't aware of the necessity of these updates. Maybe the ebuilds could update genkernel, so when I install a new udev, it gets added to genkernel.conf automatically.
(In reply to comment #21) Tryed it with the versions I had of the listed utils, didn't work for me :-(
Created attachment 96961 [details, diff] initrd.scripts.diff OK. Can one of you apply this patch to /usr/share/genkernel/generic/initrd.scripts, build a new initrd, and see if the system boots. This needs to apply to genkernel 3.4.0-r1, not 3.3.11d...
(In reply to comment #23) > Created an attachment (id=96961) [edit] > initrd.scripts.diff > > OK. Can one of you apply this patch to > /usr/share/genkernel/generic/initrd.scripts, build a new initrd, and see if the > system boots. > > This needs to apply to genkernel 3.4.0-r1, not 3.3.11d... > this WORKS on my system. re-emerged genkernel-3.4.0-r1, deleted all the stuff in /usr/share/genkernel/pkg/x86/ so everything get recompiled, applied the patch. it is all ok, no partitions lost and no need to change anything around. thanks a lot for your great job Chris :)
This patch has been added to CVS. Hopefully, it'll solve the problem for everyone and will be in the next genkernel release.
Fixed in 3.4.1, thanks!
