mdev seems to create the cciss devices with a slightly horrific naming convention similar to /dev/cciss!c0d0p2, as opposed to the more normal /dev/cciss/c0d0p2. This is quite obnoxious, as the rest of the system uses the more normal format :-) --S
This looks to be a bug in busybox/mdev, since there's no rule for udev munging the name, and mdev is *supposed* to use all of the standard kernel names.
Can you test to see if this is still an issue in genkernel-3.4.10? We upgraded busybox from 1.3.1 to 1.7.4.
i ran into this problem on a server with kernel 2.6.12-xen and initramfs build with genkernel 3.4.9 after adding doscsi to grub.conf it works maybe this info helps one.....
I can't imagine how adding 'doscsi' would affect this problem. However, doscsi is now the default with 3.4.10.
For me, this problem still exists, althoug I tried using 'doscsi'. I've tested using the following components: gentoo-sources-2.6.27-r7 genkernel-3.4.10-r2 busybox-1.11.1 busybox-1.13.1 I can't boot the server in this state, as the root block device can't be found. It seems someone was discussing this on the BB mailinglist too, but I didn't find out how to deal with this in the genkernel context: http://lists.busybox.net/pipermail/busybox/2008-July/032476.html Anyone has an idea how to apply this workaround?
Is there a possibility for anyone to confirm if this bug still exists? It is old, and busybox has been updated, and the handling of /dev has changed since it was filed.
last time i've updated my kernel it was still needed. cannot re-check atm because this is a production box. here is some system info: menu.lst title Gentoo Xen root (hd0,0) kernel (hd0,0)/boot/xen.gz cpuidle=0 cpufreq=none dom0_mem=4096M module (hd0,0)/boot/vmlinuz.xen crypt_root=/dev/cciss!c0d0p2 real_root=/dev/system/dom0_root dolvm max_loop=256 module (hd0,0)/boot/initramfs.xen virtualix-hbslx ~ # uname -a Linux virtualix-hbslx 2.6.34-xen-r4 #11 SMP Wed Apr 13 10:23:31 CEST 2011 x86_64 Intel(R) Xeon(R) CPU E5640 @ 2.67GHz GenuineIntel GNU/Linux virtualix-hbslx ~ # epm -q genkernel genkernel-3.4.10.907 virtualix-hbslx ~ # grep -i busybox /etc/genkernel.conf # Include (or suppresses the inclusion of) busybox in the initrd or initramfs. # If included, busybox is rebuilt if the cached copy is out of date. # BUSYBOX="yes" BUSYBOX_VER="1.7.4" BUSYBOX_SRCTAR="${DISTDIR}/busybox-${BUSYBOX_VER}.tar.bz2" BUSYBOX_DIR="busybox-${BUSYBOX_VER}" BUSYBOX_BINCACHE="%%CACHE%%/busybox-${BUSYBOX_VER}-%%ARCH%%.tar.bz2" virtualix-hbslx ~ # epm -q busybox busybox-1.17.4
(In reply to comment #7) > virtualix-hbslx ~ # epm -q genkernel > genkernel-3.4.10.907 > That version of genkernel has not yet got the /dev-handling love that may be required, and I am afraid I might not be able to get my hands on the hardware required. And as this is a production system we are talking about I am unsure if I want to advice you to try upgrading, unless you have to reboot the system for another reason. I that case if you have five minutes to try with a ramdisk generated by 3.4.15 (may contain other problems due to lack of testing, and changes in the mdadm handling, /dev handling, upgraded busybox and other stuff), and tell us the results. There should not be any damaging changes, just "will boot/will not boot".
(In reply to comment #8) > (In reply to comment #7) > > virtualix-hbslx ~ # epm -q genkernel > > genkernel-3.4.10.907 > > > > That version of genkernel has not yet got the /dev-handling love that may be > required, and I am afraid I might not be able to get my hands on the hardware > required. > > And as this is a production system we are talking about I am unsure if I want > to advice you to try upgrading, unless you have to reboot the system for > another reason. I that case if you have five minutes to try with a ramdisk > generated by 3.4.15 (may contain other problems due to lack of testing, and > changes in the mdadm handling, /dev handling, upgraded busybox and other > stuff), and tell us the results. There should not be any damaging changes, just > "will boot/will not boot". hi, today the system was rebooted for some maintenance and i've updated genkernel to 3.4.15. but still the same issue. initramfs complains about missing /dev/cciss/c0d0p2. after changing back to /dev/cciss!c0d0p2 the system boots without problems. lvm, luks everything ok. some info about current versions: virtualix-hbslx ~ # epm -q genkernel genkernel-3.4.15 virtualix-hbslx ~ # grep -i busybox /etc/genkernel.conf # Include (or suppresses the inclusion of) busybox in the initrd or initramfs. # If included, busybox is rebuilt if the cached copy is out of date. # BUSYBOX="yes" BUSYBOX_VER="1.18.1" BUSYBOX_SRCTAR="${DISTDIR}/busybox-${BUSYBOX_VER}.tar.bz2" BUSYBOX_DIR="busybox-${BUSYBOX_VER}" BUSYBOX_BINCACHE="%%CACHE%%/busybox-${BUSYBOX_VER}-%%ARCH%%.tar.bz2" # BUSYBOX_APPLETS="[ ash sh mount uname echo cut cat" if i can help with testing let me know. but there may be some delay in testing new stuff because of production status of this box. regards heiko
- The trailing digit may make busybox think that it's dealing with a partition, not a block device, see <http://git.busybox.net/busybox/tree/e2fsprogs/old_e2fsprogs/blkid/devname.c#n299> - You could try configuring genkernel's busybox so that CONFIG_BLKID_DEBUG is enabled. I expect that to enable the debugging output seen in the code above. - devname.c seems to ends up in busybox's tools blkid, findfs and mount: # fgrep -R devname.o . -h [..] lib-$(CONFIG_BLKID) += get_devname.o lib-$(CONFIG_FINDFS) += get_devname.o lib-$(CONFIG_FEATURE_MOUNT_LABEL) += get_devname.o - You could try using genkernel option --disklabel which will pull the real blkid code into the initramfs and prefer that over busybox's blkid. Maybe we're lucky and that one works better. - For testing you could also try adding an explicit rule to /etc/mdev.conf in the initramfs and see it hits, e.g. "/dev/cciss/(.+) 0:0 660 =ABC%1" should rename your device to /dev/ABCc0d0p2 if I read [1] correctly. Pick whatever you like :-) [1] http://git.busybox.net/busybox/tree/docs/mdev.txt
hi, just want to say that i was forced to switch to hpsa driver on my server after kernel update (2.6.38-xen-r1). newer cciss drivers do not support my controller anymore as upstream decided to split controller support. maybe i have another box with older kernel to test. but this is not for sure and i dont know when i can check this, sorry. regards heiko
Okay, thanks for the update. For anyone jumping onto this bug in the future: please see comment #10 on how to make progress with this.
I am closing this bug as obsolete since we moved to UDEV which should take care of this. Please re-open/file a new bug if you are still experiencing the issue.
