Okay, since changing to 2005.0 gentoo now uses udev as default... This brought a lot of hazle to me. Don't know if anyone was thinking about kernel Raids without fd partitions and auto raid detection in the kernel. But I was running in trouble with this. Let my clarify: During devfsd times Primary Master was HDA, Primary Slave was HDB, Secondary Master was HDC and Secondary Slave was HDD. This ditdn't change even if discs were added or removed. It didn't matter how many controllers you have. The only thing you needet to know was in which order the controller are initiated. Than you knew every ports hdX link. But nowtimes (udev times) things have changed. The first disk discovered is HDA the second HDB and so on... So what happens When I add a disc between Primary Master and Secondary Master? Alls devicese after the Primary Master will be remapped after a reboot which requires changes in fstab AND in the RAIDTAB. So my raid was interrupted. Same with usb-masstorage-devices. It depends on the initiation of the usb-bus where your device will be mapped. So this will happen every time someone adds an additional disc except it is the last disc on the last initiated controller. Thats really, really nasty and generates a lot of trouble Devlabel would fix this problem in a smart way. This is why I think "Greg Kroah-Hartman" should at least consider including the patches announced in BUG #72137 into his hotplug build. Or maybe the devlabl prog with patches should be includet into portage as fast as possible regards blubbi Reproducible: Always Steps to Reproduce: 1.Add a disc on Primary Master and Secondary Master 2.configure your fstab to mount these two drives somewhere 3.Shutdown System 4.Add a disc to Primary Slave 5.Power up system 6.Take a closer look what disc has been mountet... and you'll notice that the newly added disc is mountet where the Secondary Master shuld be mounted. Actual Results: Lots of hazle with usb devices, adding/removing discs from a system Expected Results: The device links should not be changed and should behave like in devfs or better patch the hotplug scripts to work with devlabel like stated in bug #72137 Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r5 i686) ================================================================= System uname: 2.6.11-gentoo-r5 i686 AMD Athlon(TM) XP 1700+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Mar 30 2005, 04:33:07 )] distcc 2.16 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-mcpu=athlon-xp -O3 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/ config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=athlon-xp -O3 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distcc distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ ftp://ftp. easynet.nl/mirror/gentoo/ http://distfiles.gentoo.org http://www.ibiblio.org/ pub/Linux/distributions/gentoo" LANG="de_DE.utf8" LC_ALL="de_DE.utf8" MAKEOPTS="-j6" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 aalib acl apache2 apm arts avi bash-completion berkdb bitmap-fonts crypt cups curl emboss encode foomaticdb fortran gdbm gif gpm imlib ipv6 jpeg libg++ libwww lufsusermount mad mikmod motif mp3 mpeg mysqlncurses nls nptl oav oggvorbis oss pam perl png python quicktime readline samba sdl slang spell sse ssl svga tcpd tiff truetype truetype-fonts type1-fonts unicode usb vhosts winbind xml xml2 xmms xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS
sys-fs/mdadm requires no /etc/raidtab, basically it requires no configuration file at all for most purposes... Otherwise, you must set partition type to fd with both mdadm and raidtools for autodetection to work, why don
sys-fs/mdadm requires no /etc/raidtab, basically it requires no configuration file at all for most purposes... Otherwise, you must set partition type to fd with both mdadm and raidtools for autodetection to work, why don´t you do this? See http://www.tldp.org/HOWTO/Software-RAID-HOWTO-7.html#ss7.2
I did! here's my raidtab and so I created the raid. But still autodetection does not work. But that problem does not change the stupid devicenaming from udev. I am now hunting down my bug in creating the RAID. # /filing (RAID 1) smaller disk is disk 0 raiddev /dev/md0 raid-level 1 nr-raid-disks 2 chunk-size 32 persistent-superblock 1 device /dev/sdd1 raid-disk 0 device /dev/sdc1 raid-disk 1
The raid problem is found: Kernel cannot detect anything because the hipoint module hpt374 is loadet as module... So there's no sens with autodetection and this is why I ran into this. So one more reason for devlabl regards Bjoern
If you need to boot from RAID-1 then don
If you need to boot from RAID-1 then don´t compile the IDE controller driver as a module. No devlabels would solve this, I can´t see your point. How would devlabel fix a problem with kernel missing an IDE driver when it needs it and not seeing those disks at all? If you don´t boot from RAID then I don´t understand your problem. Autodetect works once the module is loaded.
I am not booting from the raid! And I don't want to build an initrd for the driver (the driver is not included in the kernel it's an external driver from highpoint) I created my arry according to the tlp howto... autodetection will not work. But that is not the primary problem why I issued this bug. Every fstab entry will be messed up when I boot with a attqached USB drive or add an extra hard disc to the controller. And there is no way to write rules for identical drives except the partition UUID which immho is not supported by hotplug or sysfs or udev by default. regards blubbi PS.: forgett the raid problem it might be stupid idea to mention it here.. but as you see, you can run in trouble when autodetection woun't work.
Well, if you have problems after adding another drive, then I would suggest that you should use /dev/ide/hostX/busX/targetX/lunX/partX or /dev/scsi/hostX/busX/targetX/lunX/partX instead of /dev/hdaX or /dev/sdaX in /etc/fstab and /etc/raidtab.
devlabel isn't needed, you can always write a custom udev rule to always keep your disks in the same place. I'm closing this bug because of this. And, you can always use devfs if you really like it...
