My startup log includes this fragment: -- * Running hdparm on /dev/hda ... [ ok ] * Running hdparm on /dev/hdc ... HDIO_GETGEO failed: Inappropriate ioctl for device [ ok ] -- My /etc/conf.d/hdparm: -- # /etc/conf.d/hdparm: config file for /etc/init.d/hdparm # You can either set hdparm arguments for each drive using hdX_args, # discX_args, cdromX_args and genericX_args, e.g. # # disc1_args="-d1" # cdrom0_args="-d1" # or, you can set hdparm options for ALL drives using all_args, e.g. # #all_args="-d1" hda_args="-a256A1c1d1m16u1" -- No mention of hdc in that file, so why is hdparm trying to set it? -- $ emerge --info Gentoo Base System version 1.6.15 Portage 2.1-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-gentoo-r4 i686) ================================================================= System uname: 2.6.17-gentoo-r4 i686 AMD Sempron(tm) Processor 2800+ app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 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-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=k8 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=k8 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk http://ftp.easynet.nl/mirror/gentoo http://trumpetti.atm.tut.fi/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 alsa apache2 apm arts avi bash-completion berkdb bitmap-fonts bzip2 cdr cli crypt cups dlloader dri dvd eds emboss encode esd foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 imlib ipv6 isdnlog ithreads javascript jpeg kde libg++ libwww logrotate mad mikmod motif mp3 mpeg ncurses nls nptl nptlonly ogg opengl oss pam pcre pdflib perl png ppds pppd python qt qt3 qt4 quicktime readline reflection session spell spl ssl symlink tcpd truetype truetype-fonts type1-fonts udev usb userlocales vorbis xml xmms xorg xv zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux userland_GNU" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS --
me thinks you have an older hdparm sync up, re-emerge hdparm, and see if the latest init.d works
Nope. I sync daily, and this is version 6.3 of hdparm. Only 6.6 is shown as newer, and that's masked by ~x86 keyword. So I set "sys-apps/hdparm ~x86" in package.keywords and updated to 6.6, but I get the same behaviour.
One point - during the emerge of 6.6 I noticed that a new /etc/conf.d/hdparm file had been installed, as I expected, but etc-update found no new files. I don't have any fancy CONFIG_PROTECT settings though. Something more subtle is going on, no? Such as having the wrong CPU type: -- $ cat proc.cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 44 model name : AMD Sempron(tm) Processor 2800+ stepping : 2 cpu MHz : 1600.011 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow up pni lahf_lm ts ttp tm stc bogomips : 3207.32 -- -- $ cat make.conf # These settings were set by the catalyst build script that automatically built this stage # Please consult /etc/make.conf.example for a more detailed example CFLAGS="-O2 -march=k8 -pipe" CHOST="i686-pc-linux-gnu" CXXFLAGS="${CFLAGS}" ftp_proxy="ftp://localhost:3128/" GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk http://ftp.easynet.nl/mirror/gentoo http://trumpetti.atm.tut.fi/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://ftp.uni-erlangen.de/pub/mirrors/gentoo http://distfiles.gentoo.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" http_proxy="http://localhost:3128/" MAKEOPTS="-j2" PORTAGE_NICENESS=3 PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="-X -doc -sdl bash-completion bzip2 cdr cups dvd ithreads javascript logrotate nls nptl nptlonly ppds symlink tcpd usb userlocales" -- Those look fine to me, but I could be wrong.
the problem is because your /etc/conf.d/hdparm is not being updated the error is showing up because `hdparm /dev/hdc` is being run (i guess your hdc is a cdrom device huh) if you add: pata_all_args="-d1" to your /etc/conf.d/hdparm, things should work just fine
Do other config protected files update normally with etc-update? I've just remerged hdparm-6.6 with portage-2.1-r1 and it handled the config file update normally for me.
Now you're confusing me. What is wrong with the /etc/conf.d/hdparm file I quoted? Etc-update works happily the rest of the time (at least it has so far - I've nothing to test it with at the moment), so what's wrong with updating hdparm? How can its content affect whether it's considered for etc-updating? Is it no longer true that either form is acceptable in /etc/conf.d/hdparm? Namely, what the comments say: either set each drive separately, or set them all at once. What was wrong with the original title of the bug?
the config file has changed format to work with the new init.d file ... you have the new init.d file with the old conf.d file so that is why you're seeing this error
*** Bug 144171 has been marked as a duplicate of this bug. ***
From bug 144171 (init script runs hdparm on all devices, even with unset/empty args): Problem is in do_hdparm() in /etc/init.d/hdparm: if [[ -n ${args:=${all_args} ${!extra_args}} ]] ; then is always true because of the space. Simplest fix is to replace it with if [[ " " != ${args:=${all_args} ${!extra_args}} ]] ; then (Note that empty args for hdparm mean -acdgkmnru, and that may produce errors.)
thanks, that part should be fixed in cvs now
I haven't tried it, but the new code: local my_all_args="${all_args} ${!extra_args}" if [[ -n ${args:=${my_all_args}} ]] ; then shouldn't change anything because ${my_all_args} still contains a space if neither ${all_args} nor ${!extra_args} is set and thus the condition is always true. If you don't like the simple hack with comparison to " " (yes, I consider it bad style too, and it will fail if someone happens to use " " to mean "empty args"), you need to use something like if [[ -n ${args:=${all_args}${all_args:+ }${!extra_args}} ]] ; then or be more verbose like if [[ -z ${args} ]] ; then if [[ -z ${all_args} && -z ${!extra_args} ]] ; then return fi args="${all_args} ${!extra_args}" fi You could also use |echo| to collapse white-space: if [[ -n ${args:=`echo -n ${all_args} ${!extra_args}`} ]] ; then but behavior of |echo| isn't well defined if arguments start with "-" and it doesn't support "--" to mark the end of options.
hrm, yeah, my change didnt fix anything should be fixed for real now though ;)
Closing this mystery bug then.
