the boot process with udev >= 060 stop at checkfs stage because they can't find any /dev/md* devices and the root fs is on /dev/md/3, udev-059 works just fine. If I enter the root password and type "ls /dev" I can't find any /dev/md* devices. After a "udevstart" all appears in /dev. The raid* are compiled in the kernel and the arrays are autodetected during the boot process (kernel 2.6.11-gentoo-r11) in all cases. Reproducible: Always Steps to Reproduce: 1. emerge -u udev 2. reboot Actual Results: can't find device /dev/md/3 Expected Results: boot :) my emerge --info : Portage 2.0.51.22-r1 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r0, 2.6.11-gentoo-r11 x86_64) ================================================================= System uname: 2.6.11-gentoo-r11 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.13 ccache version 2.4 [enabled] dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r8, 2.16.90.0.3, 2.16.91.0.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=k8 -mtune=k8 -momit-leaf-frame-pointer -ftracer -ggdb -pipe -mmmx -msse -msse2 -m3dnow -feliminate-dwarf2-dups " CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -march=k8 -mtune=k8 -momit-leaf-frame-pointer -ftracer -ggdb -pipe -mmmx -msse -msse2 -m3dnow -feliminate-dwarf2-dups " DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks nostrip sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://mirror.switch.ch/mirror/gentoo/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo" LC_ALL="fr_FR.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.fr.gentoo.org/gentoo-portage" USE="X X509 Xaw3d a52 aac acl acpi acpi4linux adns alsa amd64 apache2 artworkextra audiofile avi bash-completion berkdb bitmap-fonts bluetooth bmp bonobo bzip2 c++ cairo caps cddb cdr chroot crypt cups curl dbm dbus dga dmx dts dv dvd eds encode esd evo exif expat ext-png ext-zlib fam fbcon ffmpeg foomaticdb fortran ftp gcc-libffi gcj gd gd-external gdbm gif gimp gimpprint gkrellm glade gnome gnutls gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile hal howl ieee1394 imagemagick imap imlib imlib2 innodb ipv6 jabber java javamail jce jikes jpeg junit lame latex lcms ldap libwww lm_sensors logrotate lzo lzw lzw-tiff mad mime mng motif mozilla mp3 mpeg mpeg4 mysql ncurses nfs nls nptl objc ogg oggvorbis opengl oss pam pcre pda pdflib perl php png posix postgres ppds python quicktime readline real scanner sdl silc slang spell ssl svg sysfs syslog tcltk tcpd tetex tga theora threads tidy tiff tiff-lzw truetype truetype-fonts type1-fonts unicode usb userlocales vorbis xine xinerama xinetd xml xml2 xosd xpm xrandr xv xvid xvmc yahoo yv12 zeroconf zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LDFLAGS, LINGUAS
sounds like a timing issue
Maybe related to bug #98193 ? I've tested udev 060, 062 and 063, all have this issue :( I stick on 059 for the moment.
I have the same problem (Epia Mainboard) and it *IS* definitely a timing problem. I guess udev just doesn't have enough time to create the md entries right after raid-start.sh assembled the arrays and before checkfs tries to use them. Adding the command 'sleep 5' just at the beginning of the start() function in /etc/init.d/checkfs solved the issue for now (If you think a patchfile would be appropriate, post me an email), but that's quick and dirty.
This isn't a udev issue, nothing udev can do about this...
So, I'm sorry but udev-068 have the same issue ... what can I do to test if it's udev or baselayout for exemple ???
