On non-devfs systems, esp. on systems running >= udev-065 where devfs names are being removed in favor of LSB names, the script /etc/init.d/hdparm tries to open block devices as a prerequisite to running hdparm against the device. This attempt to open the device fails on removeable-media block devices unless the media is in the drive. Specifically: /etc/init.d/hdparm: ... else # non-devfs compatible system for device in /dev/hd? do # check that the block device really exists # by opening it for reading if [ -b $device ] && ( : <$device ) 2>/dev/null then eval args=\${`basename $device`_args} do_hdparm fi done fi } ---end--- The conditional: if [ -b $device ] && ( : <$device ) 2>/dev/null will fail on block devices such as cdroms unless there is media in the drive. There is no need to try and open the device on udev systems where devices are created at boot (as opposed to from a tarball), since the creation of the device node is only done as needed. The existence of the device node ought to be considered "enough" to warrant running hdparm against it. The above conditional should be replaced with: if [ -b $device ] to fix the problem. I will attach a patch to fix hdparm/files/hdparm-init-7 Phil Reproducible: Always Steps to Reproduce: 1.create /etc/conf.d/hdparm entries for removable block devices, e.g. to turn on DMA on a cdrom: hdc_args="-d1" 2.use >=udev-065 with no device tarballs 3. reboot and observe that hdparm will not run against hdc unless there's a cd in the drive Actual Results: hdparm ignores the hdc_args entry in /etc/conf.d/hdparm Expected Results: hdparm should run against the hdc device using the paramaters supplied in /etc/conf.d/hdparm Portage 2.0.51.22-r2 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.5-r1, 2.6.12-gentoo-r9 i686) ================================================================= System uname: 2.6.12-gentoo-r9 i686 Intel(R) Pentium(R) 4 CPU 2.40GHz Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.12 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="-march=pentium4 -O2 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp://gentoo.mirrors.pair.com http://gentoo.ccccom.com" LANG="en_US.utf8" LC_ALL="en_US.utf8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 X alsa avi cdr cups divx4linux dvd dvdr encode fbcon gif gpm gtk gtk2 jpeg mad mikmod mmx mpeg ncurses nls nptl oggvorbis opengl oss perl png python readline sdl slang spell sse ssl tcpd truetype unicode xml2 xprint xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS, LINGUAS
Created attachment 66444 [details] /usr/portage/sys-apps/hdparm/files/hdparm-init-7.diff Diff/patch to correct /usr/portage/sys-apps/hdparm/files/hdparm-init-7 in order to fix this bug.
Created attachment 66445 [details, diff] sys-apps/hdparm/files/hdparm-init-7.diff note: sys-apps/hdparm/files/hdparm-init-7 is copied to /etc/init.d/hdparm during emerge hdparm. my first diff was against the /etc/init.d/hdparm file, but to correct the problem in portage, the patch should be against sys-apps/hdparm/files/hdparm-init-7
forgot to mention hdparm is in my boot run-level.
*** This bug has been marked as a duplicate of 69284 ***
no. this is not a duplicate of that bug!
