This looks like a recursive issue and a file is locked, me thinks.
==========================The following is brought to you by LINK to Ubuntu
==========================
acpi-support (0.109-0hardy2) hardy-proposed; urgency=low [ Jakob Unterwurzacher ] * Defensive quoting in 90-hdparm.sh, so that the script doesn't throw a syntax error when the battery state is undetermined. [ Steve Langasek ] * lib/power-funcs: refactor getState() to return 'AC' by default, since this is implicitly the case if we don't have a battery. LP: #59695. -- Thu, 15 Jan 2009 13:06:55 +0000==========================
The following is brought to you by "apt-get" update
==========================
Preparing to replace acpi-support 0.109-0hardy1 (using .../acpi-support_0.109-0hardy2_amd64.deb) * Disabling power management... [ OK ] Unpacking replacement acpi-support Setting up acpi-support (0.109-0hardy2) Installing new version of config file /etc/acpi/resume.d/90-hdparm.sh ... Installing new version of config file /etc/acpi/start.d/90-hdparm.sh ... Installing new version of config file /etc/acpi/ac.d/90-hdparm.sh ... Installing new version of config file /etc/acpi/battery.d/90-hdparm.sh ... * Checking battery state... /dev/sdc: setting Advanced Power Management level to 0xfe (254)==========================
The following is brought to you by "pstree -aclpu"
==========================
| |-kdesu,11825 -u root -c /usr/bin/adept_updater\040 | | `-adept_updater,11830,root | | `-dpkg,11936 --status-fd 61 --configure acpi-support | | `-acpi-support.po,11937 /var/lib/dpkg/info/acpi-support.postinst configure 0.109-0hardy1 | | `-invoke-rc.d,12099 /usr/sbin/invoke-rc.d acpi-support start | | `-acpi-support,12115 /etc/init.d/acpi-support start | | `-hdparm,12150 -i /dev/sde
I would blame quantum entanglement for this problem, but it seems that it may be intellectual entanglement and my mind is operating faster than my ability to understand.
| |-konsole,12176 | | `-bash,12177 | | `-hdparm,12270,root -i /dev/sde
This is the file as it exists.
#! /bin/sh # # This script adjusts hard drive APM settings using hdparm. The hardware # defaults (usually hdparm -B 128) cause excessive head load/unload cycles # on many modern hard drives. We therefore set hdparm -B 254 while on AC # power. On battery we set hdparm -B 128, because the head parking is # very useful for shock protection. # . /usr/share/acpi-support/power-funcs DO_HDPARM=y if [ -e /usr/sbin/laptop_mode ] ; then LMT_CONTROL_HD_POWERMGMT=$(. /etc/laptop-mode/laptop-mode.conf && echo "$CONTROL_HD_POWERMGMT") if [ "$LMT_CONTROL_HD_POWERMGMT" != 0 ] \ && [ -e /var/run/laptop-mode-tools/enabled ] then # Laptop mode controls hdparm -B settings, we don't. DO_HDPARM=n fi fi if [ "$DO_HDPARM" = y ] ; then # Get the power state into STATE getState; for dev in /dev/sd? /dev/hd? ; do if [ -b $dev ] ; then # Check for APM support; discard errors since not all drives # support HDIO_GET_IDENTITY (-i). if hdparm -i $dev 2> /dev/null | grep -q 'AdvancedPM=yes' ; then if [ "$STATE" = "BATTERY" ] ; then hdparm -B 128 $dev else hdparm -B 254 $dev fi fi fi done fi "/etc/acpi/battery.d/90-hdparm.sh" [readonly] 41L, 1157C
I am not exactly sure where the problem arises, however this is the change and as such, I am not liking things that stop the ability to get to console as it requires I fiddle from another partition and that is icky. Below is the defensive quoting.
if [ "$DO_HDPARM" = y ] ; then if [ $DO_HDPARM = y ] ; then
On top of that there is some weirdness going on with Firefox and it isn't minor. It appears to be a security hole and I don't even want to mess with that until I have resolved this. It results from a game that people play with image files and others may not be aware of it yet. I was trying to get a good example of it to test with. It is possible to make images un-copyable or worse , however the bandwidth is severely affected. I am really getting tired of the internet copyright wars and I may just go text mode and use a tunnel if it gets too bad.
I am reasonably sure there is some odd recursion going on and it is a matter of analytical skills is why I do it. It verifies that my CPU is running fine if I solve and understand problems. :)
1 comments:
I finally gave up and just killed the process as I think it went into an accidental deadly embrace. It works fine and it is just an issue for me as I was using "proposed" updates. I had fun digging in /sys and /proc a little bit.
Post a Comment