I encountered this with gparted; I haven't tried it with parted ATM due to time constraints but I assume it's likewise affected. I noticed that I was getting errors from gparted and the utilities that it invokes (in my terminal window), such as: e2fsck: No such file or directory while trying to open /dev/hda18 (or resize2fs or dumpe2fs, and for several other partitions on hda). I could try the same commands on my own at a shell and it would work fine. I started using strace to see what was going on. I'm using udev with traditional device naming. When gparted makes a change to my partition table (DOS disklabel), it takes udev several seconds to respond. On my most recent test run, there was a gap of 6.19 seconds between when /dev/hda18 was unlinked and when it was mknod/chmod'd back into existence. gparted calls sleep(1) after changing the partition table. Obviously in this case that's no longer sufficient. My $0.02 USD, if you care: My first reaction is that there's no reason for udev to be taking so long. Now, maybe it's perfectly reasonable for it to take that long, if only I could understand what needs to happen--and it's not like most people repartition their hard drives daily, so subsecond completion times aren't critical as far as the end user is concerned. In that case, it seems like there needs to be some sort of mechanism to tell other userspace processes that udev has finished shuffling things around. It doesn't look to me like setting an arbitrary number of seconds to sleep is going to cut it any longer.
Why don't you attach the strace? Also, post the udev version you are using and emerge --info output.
Also, what kernel version are you seeing this on?
kernel version 2.6.12-gentoo-r6 udev version 058 Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r0, 2.6.12-gentoo-r6 i686) ================================================================= System uname: 2.6.12-gentoo-r6 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.6.13 ccache version 2.3 [disabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-pipe -O2 -march=athlon-xp -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-pipe -O2 -march=athlon-xp -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirrors.acm.cs.rpi.edu/gentoo http://distro.ibiblio.org/pub/Linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowex X aac acl acpi alsa apm avi berkdb bitmap-fonts bonobo bzlib cdr crypt cscope cups curl eds emboss esd fam flac foomaticdb fortran gb gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml guile imlib ipv6 jack java jpeg libg++ libwww mad maildir matrox mbox memlimit mikmod mmx mmx2 mng mozilla mp3 mpeg ncurses nls ofx ogg oggvorbis opengl oss pam pcntl pdflib perl pic png posix ppds prelude python quicktime readline sdl speex spell sse ssl svg tcpd tetex theora tiff truetype truetype-fonts type1-fonts unicode usb videos vorbis wmf xine xml xml2 xmms xv xvid zlib video_cards_matrox userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY
Created attachment 65928 [details] strace log of udevd
Poked at this some more. There are several subprocesses, one per relevant hda* it seems, that are polling for the existence of /sys/devices/pci0000:00/0000:00:11.1/ide0/0.0/detach_state, which never exists AFAICT. Each goes for something like 6 seconds then gives up, and apparently proceeds without problem.
Yes, please upgrade your version of udev. This should be fixed there.
To which version? 058 is the latest stable for x86.
Latest unstable would be great, 067
Looks like it's working now. It might be a good idea to add a dependency that gparted needs udev >= 067. Also, I guess you can count this as a WorksForMe(TM) report in support of marking 067 stable on x86 :).
