In 2.6.25* (-rc3 presently), the sysfs nodes have changed somewhat. Due to how mdev works, this means is miscreates device nodes as character devices instead of block devices. Meaning mounting doesn't work ("block device required"), and LVM ignores the devices. Reviewing the busybox-1.1.3+gentoo, the problem with mdev appears to be the use of strncmp on the sysfs path. path = /sys/%s type = strncmp(path+5, "block/", 6) ? S_IFCHR : S_IFBLK; This expects the /sys/block/FOO to be a directory. However, in 2.6.25, /dev/block/FOO is a symlink to another location. Here's an example: root@grubbs-int:~ # ls -la /sys/block/ total 0 drwxr-xr-x 2 root root 0 2008-03-01 16:06 . drwxr-xr-x 11 root root 0 2008-03-01 15:59 .. lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-0 -> ../devices/virtual/block/dm-0 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-1 -> ../devices/virtual/block/dm-1 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-10 -> ../devices/virtual/block/dm-10 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-11 -> ../devices/virtual/block/dm-11 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-12 -> ../devices/virtual/block/dm-12 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-13 -> ../devices/virtual/block/dm-13 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-14 -> ../devices/virtual/block/dm-14 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-15 -> ../devices/virtual/block/dm-15 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-16 -> ../devices/virtual/block/dm-16 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-17 -> ../devices/virtual/block/dm-17 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-18 -> ../devices/virtual/block/dm-18 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-19 -> ../devices/virtual/block/dm-19 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-2 -> ../devices/virtual/block/dm-2 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-20 -> ../devices/virtual/block/dm-20 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-21 -> ../devices/virtual/block/dm-21 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-22 -> ../devices/virtual/block/dm-22 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-23 -> ../devices/virtual/block/dm-23 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-24 -> ../devices/virtual/block/dm-24 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-25 -> ../devices/virtual/block/dm-25 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-26 -> ../devices/virtual/block/dm-26 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-3 -> ../devices/virtual/block/dm-3 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-4 -> ../devices/virtual/block/dm-4 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-5 -> ../devices/virtual/block/dm-5 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-6 -> ../devices/virtual/block/dm-6 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-7 -> ../devices/virtual/block/dm-7 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-8 -> ../devices/virtual/block/dm-8 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 dm-9 -> ../devices/virtual/block/dm-9 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 md2 -> ../devices/virtual/block/md2 lrwxrwxrwx 1 root root 0 2008-03-01 16:06 sda -> ../devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5:1.0/host0/target0:0:0/0:0:0:0/block/sda lrwxrwxrwx 1 root root 0 2008-03-01 16:06 sdb -> ../devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5:1.0/host0/target0:0:0/0:0:0:1/block/sdb lrwxrwxrwx 1 root root 0 2008-03-01 16:06 sdc -> ../devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5:1.0/host0/target0:0:0/0:0:0:2/block/sdc lrwxrwxrwx 1 root root 0 2008-03-01 16:06 sdd -> ../devices/pci0000:00/0000:00:1d.7/usb2/2-5/2-5:1.0/host0/target0:0:0/0:0:0:3/block/sdd lrwxrwxrwx 1 root root 0 2008-03-01 16:06 sde -> ../devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host2/target2:0:0/2:0:0:0/block/sde lrwxrwxrwx 1 root root 0 2008-03-01 16:06 sdf -> ../devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host2/target2:1:0/2:1:0:0/block/sdf lrwxrwxrwx 1 root root 0 2008-03-01 16:06 sdg -> ../devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host2/target2:2:0/2:2:0:0/block/sdg lrwxrwxrwx 1 root root 0 2008-03-01 16:06 sdh -> ../devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host2/target2:3:0/2:3:0:0/block/sdh lrwxrwxrwx 1 root root 0 2008-03-01 16:06 sdi -> ../devices/pci0000:00/0000:00:1c.2/0000:03:00.0/host2/target2:4:0/2:4:0:0/block/sdi lrwxrwxrwx 1 root root 0 2008-03-01 16:06 sdj -> ../devices/pci0000:00/0000:00:1e.0/0000:06:01.0/host11/target11:0:0/11:0:0:0/block/sdj lrwxrwxrwx 1 root root 0 2008-03-01 16:06 sr0 -> ../devices/pci0000:00/0000:00:1f.2/host4/target4:0:0/4:0:0:0/block/sr0 sdj is my boot media (3ware). I think if we convert the strncmp of "block/" to a plain strcmp, it should work, without any false positives.
Ok, the trivial change of strncmp -> strcmp doesn't help it. I'm trying a few other bits, incl moving the entire busybox forward to 1.9.0, or back-porting the 1.9.0 mdev.
Created attachment 145057 [details, diff] busybox-1.1.3+gentoo-mdev-1.9.0.patch This patch is the clones the code used to set the devnode type from 1.9.0 to the 1.1.3 branch. It relies on the fact that the char devnodes 'dev' under /sys/class. This is NOT foolproof, as ttyXX and a lot of other devices are under the /sys/device hierarchy instead of /sys/class or /sys/block. It does work, but I don't trust it.
Created attachment 145058 [details, diff] busybox-1.1.3+gentoo-mdev-block.patch Here's another patch that I came up with, it uses the detection of the string "block/" using strstr(path,"block/"). The trailing slash is important because there are some items in sysfs that have block as part of the name. This seems to work better than the check from 1.9.0 for now, and while it's not fool-proof, I'd call it good enough to use.
Is this bug still valid with the new busybox in genkernel?
this bug can go away with the new busybox (which is where I borrowed the code for the first patch on here anyway). Just if we have crazy devices in the initramfs in the future, remember the second patch maybe.
I guess this is INVALID now, since the busybox with the problem is no longer used :P
Actually, this was FIXED...
We'll RESOLVED-FIXED it once 3.4.10 final is out.
I've tried both busybox 1.10.1-r2 (which includes current patches from upstream) and my own vanilla busybox 1.10.1 with all upstream patches applied directly from http://busybox.net/downloads/fixes-1.10.1/ The kernel I'm testing against is vanilla-sources-2.6.25.2 (with the deprecated sysfs structures switched off). I'm using a static build of busybox in an initrd script with mdev being used with kernel hotplug (and also being used manually with mdev -s). It seems that mdev is still populating /dev with character devices regardless of what type of device it should actually be. Can anyone please confirm if busybox-1.10.1-r2 actually fixes this mdev bug (from experience/testing)? Or is it just me that is still having problems? Thanks
Created attachment 153091 [details, diff] Proposed patch using strstr function to check for block devices Also suggested upstream via the mailing list (see http://busybox.net/lists/busybox/2008-May/031408.html)
i have reportet this bug alredy: https://bugs.gentoo.org/show_bug.cgi?id=220993
1.10.1-r3 still has the same issue...
But fixed in 1.10.3 (vanilla), see bug #226101.
So this is *not* fixed using genkernel 3.4.9 or 3.4.10-r1 (without modifying the busybox version used) correct?
Friendly reminder: we'll probably push for 2.6.25 stable in the next week or so, so it would be great to see this fixed
If this is going to get fixed soon, someone will need to provide a patch against mdev in busybox-1.7.4, since that's what we're currently using in genkernel-3.4.10. We just went through an upgrade of busybox from 1.1.3 to 1.7.4, and I'm not doing that again any time soon.
(In reply to comment #10) > Created an attachment (id=153091) [edit] > Proposed patch using strstr function to check for block devices Will this patch work properly with mdev from 1.7.4 as well?
This appears to have finally been fixed upstream in revision 22814. See: http://busybox.net/cgi-bin/viewcvs.cgi/trunk/busybox/util-linux/mdev.c?rev=22814&r1=22813&r2=22814&diff_format=h I haven't tried this upstream version yet. However it essentially the same as the patch I posted here a few months ago, with a change to the if/else branch to allow better CPU branch prediction (I think). The patch I submitted here for revision 21977 will not work with 1.7.4 because the block/char determination at that time was: /* Determine device name, type, major and minor */ device_name = bb_basename(path); type = path[5]=='c' ? S_IFCHR : S_IFBLK; (see http://busybox.net/cgi-bin/viewcvs.cgi/branches/busybox_1_7_stable/util-linux/mdev.c?rev=19676&view=markup ) It should however be fairly easy to backport revision 22814 to use strstr to determine the value of 'type', rather than the old school method of checking the 5th character in the device path name.
This one looks oh-so-fun... We probably want to try to get this done for 3.4.11's release. Could any of you help us with the 1.7.4 patches? If not, it'll likely take much longer to get done, since the genkernel team has very limited manpower and developer time.
Was there a change in newer kernels that fixed this? I've built a CD based of 2.6.26 and 2.6.27 without problems.
I'm going to call this one fixed, because I haven't seen this one myself with the newer busybox and 2.6.2[67] kernels.
Due to the date of the last comment on this bug I assume that feature to be included in 3.4.10.907 or an earlier release of genkernel. Therefore, I remove this bug from tracker bug #245389 "Features for inclusion by 3.4.11".
