When udev and hotplug are started at boot I get the message "cdrom: open failed" twice. (I have two CD-drives). Seemingly it does not affect the working with both drives so I do not understand what those messages want to tell me. But "failed" does not sound normal to me ... Reproducible: Always Steps to Reproduce: 1. Boot Gentoo 2. 3. Actual Results: Getting the messages Expected Results: Should not get the messages ... # emerge info Portage 2.0.51-r2 (default-x86-1.4, gcc-3.4.2, glibc-2.3.4.20041006-r0, 2.6.8-ck8 i686) ================================================================= System uname: 2.6.8-ck8 i686 AMD Duron(tm) Gentoo Base System version 1.6.3 distcc 2.18 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux-headers-2.4.19,sys-kernel/linux-headers-2.4.22 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=i686 -O3 -pipe -mmmx -msse -m3dnow -mfpmath=sse -ftracer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /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="-march=i686 -O3 -pipe -mmmx -msse -m3dnow -mfpmath=sse -ftracer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs candy ccache distlocks sandbox" GENTOO_MIRRORS="ftp://mirror.switch.ch/mirror/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowex X aalib acl acpi acpi4linux alsa apache2 apm avi berkdb bitmap-fonts blender-game bonobo bootsplash bzlib cdparanoia cdr clanVoice crypt cups dba dedicated dga divx4linux doc dvd encode escreen f77 fbcon foomaticdb freetype gd gdbm gif gnome gpm gtk gtk2 imagemagick imlib java jpeg libg++ libwww mad mailwrapper mbox mikmod mmx mmx2 motif mpeg mysql ncurses net nls oggvorbis opengl oss pam pdflib perl png python quicktime radeon readline rtc ruby samba sdl session shared silverxp slang sockets spell spl sse ssl stencil-buffer svga tcltk tcpd tetex tokenizer truetype usb videos wxwindows x86 xchattext xfs xml xml2 xmms xpm xprint xsl xv zlib"
try 1.11.4 and if that fails to work, give us some more information 'at boot' is *awfully* vague what's messages do you see before and after it ?
I quote "When udev and hotplug are started at boot", but I knew that this is also a bit vague, sorry. I will post the exact messages before and after those messages after the next reboot. I will also upgrade to 1.11.4 before ...
I forgot to add that this is (almost?) kernel-independent since it occured with ck-sources-2.6.8.1-r8 and -2.6.9-r1 . With 2.6.8.1-r8 I certainly didn't have those messages before, so I think the kernel as a reason can be excluded ...
Messages occur between "Populating /dev with device nodes" and "Using /sbin/hotplug for udev management" This is still with 1.11.3. I am going to test it with 1.11.4 now.
Same with 1.11.4
what baselayout did you have before this error started showing up ? where you using udev then too ? what version of udev are you running now ? the only thing that happens between the two messages you posted is that the device tarball is unpacked into /dev and /sbin/udevstart is run ... if you set RC_DEVICE_TARBALL=no in /etc/conf.d/rc, does the error still happen ?
Before I was using baselayout-1.10.4 I used and I am using udev, currently version 042 I remember there was a udev upgrade also in the last days from 040 to 042. Maybe I will downgrade udev and test it then, too. I am going to test the thing with the device tarball later this day since I have to go to school now ;)
Maybe I have another clue: I just had a cd in one of the drives and I got only one message. I guess, that something is trying to open the cdrom drives and if no cd is in them it fails?
OK, I did some tests: - Downgraded to udev-040: Did not fix it. - Downgraded to baselayout-1.10.4: Fixed it !! So I tried after re-upgrading to baselayout-1.11.4 what you told me: I set RC_DEVICE_TARBALL to no. That didn't fix it either. But I have another clue: I had a cd in /dev/hdc and as I said already above I then get only one "cdrom: open failed" when booting at the described point. Now I had removed the cd and when I shut down the system I got the following message after * Shutting down Locigal Volume Manager : "/dev/hdc: open failed: No medium found" So I guess something is looking for inserted media at boot and seems to insist on the media still being inserted at shutdown ... Maybe that helps ...
hmm, that's interesting :) what if you try `chmod a-x /sbin/lvm` and then reboot ? i'm assuming that (1) you have lvm installed and (2) you dont actually use lvm ...
Yes, you're right in (1), I have LVM installed, but unfortunately wrong in (2), I do use LVM. I have put two harddisks on an extra controller (hde, hdg) together to one device.
hmm, how do you use lvm ? do you use it for like /usr or something critical ? if not, could you try editing /sbin/rc and removing the call to lvm in populate_udev() ?
I have to apologize myself because this is a wrong alert: You were right: it had to do something with LVM: I had the standard /etc/lvm/lvm.conf and changing the line filter = [ "a/.*/" ] into filter = [ "a|/dev/hde|", "a|/dev/hdg|", "r|.*|" ] resolves this issue for me. So sry again for this wrong alert ...
Sry for me being OT, but: Am I generally allowed to close bugs, for example marking this as RESOLVED INVALID? Or is this preferentially done by Gentoo Developers?
you're the reporter of the bug so technically you can do whatever you like :) glad things are sorted out
