[OPGELOST] Karmic: onder welk pakket valt rc.local (voor Launchpad-foutmelding)?

[Pjotr]

Ik wil een foutmelding gaan doen op Launchpad, voor het feit dat een bepaald commando niet meer werkt in /etc/rc.local in Karmic. Namelijk hdparm op 254 zetten. Maar ik weet niet, onder welk pakket dat valt. Wie weet het?

Overigens: de hdparm op 254 zetten werkt nog steeds prima, wanneer je dat handmatig doet. Het ligt dus niet aan hdparm: op de een of andere manier "pakt" rc.local dit commando niet goed op, bij het opstarten van 9.10. Onder 9.04 ging het altijd vlekkeloos.

[Johan van Dijk]

Was dat niet een workaraound om te voorkomen dat je harde schijf steeds in een soort slaapstand gezet wordt?
Is dat nog steeds nodig in Karmic? Ik dacht dat het allang opgelost was 

Wat werkt er niet aan het commando? Krijg je een foutmelding?
Wat is het exacte commando dat je in rc.local gezet hebt?

[Johan van Dijk]

Oh, en in Jaunty zit rc.local in het "initscripts"-pakket.
Op packages.ubuntu.com is wel te vinden of dat in Karmic nog steeds zo is.

[Pjotr]

Was dat niet een workaraound om te voorkomen dat je harde schijf steeds in een soort slaapstand gezet wordt?
Is dat nog steeds nodig in Karmic? Ik dacht dat het allang opgelost was  

Wat werkt er niet aan het commando? Krijg je een foutmelding?
Wat is het exacte commando dat je in rc.local gezet hebt?

Niet opgelost, nee.... Het gaat hierom:
http://sites.google.com/site/computertip/fouten
(punt 10)

initscripts: dank, ik zal even nakijken of ik het daarbij kan melden.  

--toevoeging--
Ik heb het gemeld bij module-init-tools.
https://bugs.launchpad.net/ubuntu/+source/module-init-tools/+bug/459455

[Johan van Dijk]

Vreemd verhaal eigenlijk.
Volgens de bug (deze?) zou het probleem opgelost moeten zijn.

Dit zou dat moeten onderschrijven:

Code: [Selecteer]

johan@desktop:~$ cat /etc/acpi/ac.d/90-hdparm.sh
#! /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
(er zijn nog meer scripts in de /etc/acpi/ map die hetzelfde doen, bij verschillende omstandigheden)

Als het goed is, dan is het dus niet nodig om zelf hdparm uit te voeren, ook niet via rc.local

[DarkEra]

Sinds Ubuntu 9.04 en zelfs de puntuitgave van Ubuntu 8.04.3 LTS zou dit probleem opgelost moeten zijn.
Is het ook namelijk want ik heb er sinds deze versies en zelfs in 9.10 totaal geen last meer van van die parkeerklik-slijtage.

[Pjotr]

Vreemd verhaal eigenlijk.
Volgens de bug (deze?) zou het probleem opgelost moeten zijn.

Dit zou dat moeten onderschrijven:

Code: [Selecteer]

johan@desktop:~$ cat /etc/acpi/ac.d/90-hdparm.sh
#! /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
(er zijn nog meer scripts in de /etc/acpi/ map die hetzelfde doen, bij verschillende omstandigheden)

Als het goed is, dan is het dus niet nodig om zelf hdparm uit te voeren, ook niet via rc.local

Het hangt er natuurlijk vanaf, hoe de firmware van de harde schijf reageert op stand 128. Blijkbaar is de firmware bij mijn netboekje veel te agressief ingesteld door de fabriek.

Enfin, misschien kan ik de gewenste hdparm 254 ook instellen via dat script in hdparm.sh... Ik ga het eens proberen.

Blijft natuurlijk wel vreemd, dat rc.local niks doet. Misschien wordt hdparm.sh daarna uitgevoerd bij het opstarten?

[Pjotr]

Net gemerkt: /etc/acpi/ac.d/90-hdparm.sh bestaat niet in Karmic.

Hmmm... hoe regelen ze het dan in Karmic?

[Drummies]

@Pjotr kom je hier verder mee!!
Power Management Infrastructure
https://wiki.ubuntu.com/PowerManagement

edit /etc/apm/event.d   /etc/acpi/start.d (als ik deze map open zie ik trouwens alleen maar bestand 60-asus-wireless-led.sh)

/lib/udev/hdparm  misschien moet je het daarin zoeken??

[Johan van Dijk]

Pjotr, zou je sudo hdparm -I uit kunnen voeren:
* Direct na het opstarten met de netstroom aangesloten
* Als je de adapter eruit haalt
* Als je de adapter weer aansluit
* (evt.) na het wakker worden uit de slaapstand.
De APM-waarden zijn dan natuurlijk waar het om gaat: die zouden moeten veranderen tussen 254 en 128.

Verder denk ik dat de bug die je geplaatst hebt voor een verkeerd pakket is. Ik zou eerder denken aan acpi-support of pm-utils. Of desnoods hdparm zelf, als het helemaal niet duidelijk is
Het uitvoeren van een hdparm-commando via rc.local is namelijk alleen een workaround, als het al werkt.
Maak je gebruik van de slaapstand dan wordt dat commando niet opnieuw uitgevoerd bijvoorbeeld, terwijl dat wel nodig is.

[Pjotr]

@Drummies: je aanwijzingen leken veelbelovend, maar het lijkt helaas geen oplossing te bieden.

@Johan: strikt genomen is het geen fout van hdparm, en ook niet van het energiebeheer. Voor verreweg de meeste laptop-hardeschijven is de standaardaanpak van Ubuntu immers de juiste. Het eigenlijke probleem is rotte firmware van de harde schijf zelf (veel te agressief met parkeren bij hdparm-stand 128), en dat is niet oplosbaar. Ja, een andere schijf erin douwen.  

Ik heb dus een stoplap nodig. Waar het mij om gaat, is dat ik een manier zoek om de stoplap voor de firmware, een handmatige hdparm-wijziging, te automatiseren.  Die automatisering zou moeten lukken met rc.local, zoals dat prima ging in 9.04.... Maar rc.local slaagt daar in Karmic ineens niet in. Vandaar de foutmelding op Launchpad voor module-init-tools, want rc.local lijkt te vallen onder dat pakket.

rc.local is de "moeder aller stoplappen", alleen hier laat hij (zij?) ineens verstek gaan.

[Johan van Dijk]

Pjotr, volgens mij is /etc/hdparm.conf bedoeld om dit soort aanpassingen te maken.
Mogelijk werkt dat ook als je de slaapstand gebruikt.
Het lijkt mij een betere oplossing dan rc.local.

Code: [Selecteer]

/dev/hda {
apm = 254
}Zoiets dus.

[Pjotr]

Pjotr, volgens mij is /etc/hdparm.conf bedoeld om dit soort aanpassingen te maken.
Mogelijk werkt dat ook als je de slaapstand gebruikt.
Het lijkt mij een betere oplossing dan rc.local.

Code: [Selecteer]

/dev/hda {
apm = 254
}Zoiets dus.

Bedankt, Johan! Dat ga ik eens proberen. Eerst met hdparm op 200.....

[Pjotr]

Helaas, geen effect.... Noch op stand 200, noch op 254.

[Johan van Dijk]

Jammer.
Ik kan het hier verder ook niet uittesten aangezien mijn schijven die apm-functie niet schijnen te ondersteunen.
Het zijn wel "groene" schijven die uit zichzelf al langzamer draaien en automatisch in slaap vallen als er geen activiteit is.
De SMART-waarden zien er allemaal wel perfect uit, dus ik hoef er verder ook niks aan te doen gelukkig

[Pjotr]

Oplossing gevonden! Je hebt me namelijk wel degelijk in de goede richting laten zoeken!  

De oplossing is, om aan het einde van hdparm.conf de volgende tekst toe te voegen:
command_line {
                     hdparm -B 254 /dev/sda
}


De truuk zit 'm in sda i.p.v. hda. Op hda reageert hij niet....

Bedankt voor de duw in de goede richting.  

P.S.: Mogelijk zou jouw oplossing ook werken met sda i.p.v. hda, maar dat heb ik niet meer geprobeerd.

[Johan van Dijk]

Ook weer opgelost 
Mooi dat het werkt!