Summary: | emerging hdparm doesnt update /etc/conf.d/hdparm | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Peter Humphrey <peter> |
Component: | Current packages | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | x00000000 |
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Peter Humphrey
2006-08-04 05:36:17 UTC
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. |