[workaround, not!! solved] Etch, Grub 0.97 und grub reboot savedefault-once (wegen NVRAM)

Negge · 18. April 2007

Hi

ich habe meinen sarge auf etch geupdatet, nun hab ich aber ein Problem.

Mein Bios braucht nen Reboot, damit er die Wakup-Zeiten im NVRAM auch nutzt. Bisher klappte das auch recht gut. Beim Rebooten hat er halt "savedafault-once 1) genutzt und dann bei grub nur "halt" ausgeführt. Beim nöchsten boot startete er dann wieder mit Eintrag "2" (mit grub 0.95 aus sarge).

Bei grub 0.97 funktionierte das aber nun so nicht mehr! Der startet immer Eintrag "2", egal ob ich beim runterfahren savedefault-once setze. Das Problem ist auch bei 0.97 schon bekannt, allerdings hab ich keine Lösung gefunden. Muss ich jetzt selektiv auf den sarge-grub "downgraden", oder wie macht ihr dass?.

HolgerR · 18. April 2007

Hi,

zunächst mal glaube ich ganz ehrlich, dass die meisten hier das ganze anders lösen ("poweroff-kernel oder in Runlevel 0 booten)

An das Grub 0.97 Problem kann ich mich ganz dunkel erinnern. Es gibt IMHO irgendwo einen Patch der "savedefault --once" fixen soll.

Alternativ:
Würde es nicht funkionieren, wenn du dem "halt" Eintrag in Grub mitgeben würdest, dass er deinen "normalen" Eintrag als default speichern soll?

In etwa so:

Eintrag 1
"halt"
savedefault 2

Eintrag 2
"normal"
savedefault 2

Gruß,
Holger

PS: Detaillierter hier

Negge · 18. April 2007

Danke, so gehts gut. (Und reproduziert das Verhalten von zuvor)

(Wilderigel hat das aber anscheinend am Wochenende auch schon ins Wiki gehackt, da hab ich ausnahmweise mal nicht geguckt. Naja, nun findet die Fourumssuche auch was )

Negge · 18. April 2007

Zu fürh gefreut. Geht doch nicht?!?

Grub-reboot 0 startet totzdem grub position 2 (obwohl default=saved gesetzt und der eigentlich saved=0 setzten sollte?!?

HolgerR · 18. April 2007

Ich vermute mal ein "grub-set-default 0" mit anschließendem Reboot funktioniert auch nicht?

Gruß,
Holger

wilderigel · 18. April 2007

Könnte hier ned klagen.
Ist ne Etch Installation ohne Altlasten.
Da tut grub-reboot.

Negge · 18. April 2007

Zitat

Original von HolgerR
Ich vermute mal ein "grub-set-default 0" mit anschließendem Reboot funktioniert auch nicht?

Scheinbar nicht. Zumindest hatte ich 5min später wieder zugriff. (also nach dem Reboot, der ein Halt sein sollte) Das Problem ist, das ich gerade von entfernt teste und eigentlich den VDR nur wieder schlafen legen will, geht aber nicht, komme immer wieder mit ssh an ihn ran.

Ich muss heute abend mal schauen wie sich das verhält, wenn ich wieder davor sitze...

Mistig...

wilderigel: Kannst du mal den Inhalt deiner /usr/sbin/grub-reboot posten?

wilderigel · 18. April 2007

Hab da nix geändert dran, also sollte sie original Debian grub Paket sein.

Negge · 18. April 2007

Zitat

Original von wilderigel
Hab da nix geändert dran, also sollte sie original Debian grub Paket sein.

Ich hab die Dateinen gerade verglichen. Ist bei mir auch exakt dieselbe grub-reboot?!?
(bei sarge und Grub 0.95 (sagt mein Backup) lag die Datei auch noch unter /sbin/grub-reboot).
Insofern hat er die Datei beim Dist-Upgrade auch sauber erneuert. AARGS

Was mir ansonsten noch einfallen würde wäre der kernel (obwohl der ja nicht viel mit grub zu tun haben sollte). Ich nutze 2.6.16-ct-1?

e9hack · 18. April 2007

Zitat

Original von Negge

Bei grub 0.97 funktionierte das aber nun so nicht mehr! Der startet immer Eintrag "2", egal ob ich beim runterfahren savedefault-once setze. Das Problem ist auch bei 0.97 schon bekannt, allerdings hab ich keine Lösung gefunden. Muss ich jetzt selektiv auf den sarge-grub "downgraden", oder wie macht ihr dass?.

Bei grub 0.97 läßt Du nur noch 'default 2' am Anfang von menu.lst drin. In das Shut-Down-Scrpt kommt dann 'grubonce 0' rein.

Das hat auch den Vorteil, das der PC nach unsauberem runterfahren (Reset, Netzstecker gezogen, ...) ohne Hilfe bootet. Grub weigert sich bei nicht sauberem File-System 'savedefault x' auszuführen. Das muß dann im Grub-editor beim booten gelöscht werden.

Gruß
e9hack

Negge · 18. April 2007

Zitat

Original von e9hack
Bei grub 0.97 läßt Du nur noch 'default 2' am Anfang von menu.lst drin. In das Shut-Down-Scrpt kommt dann 'grubonce 0' rein.

So war das bei mir im Prinzip früher bei 0.95 (und debian/sarge). Grub-reboot-2 hat da auch nur grub savedefault--once irgendwie aufgerufen...

Soweit ich gelesen hab muss man bei Grub0.97 aber immer "default saved", sonst führt der immer den Eintrag unter default (also die Zahl) aus und irgnoriert andere Einstellungen.

grubonce gibt es übrigend bei mir (normales debian/etch) nicht?!?

Zitat

Das hat auch den Vorteil, das der PC nach unsauberem runterfahren (Reset, Netzstecker gezogen, ...) ohne Hilfe bootet. Grub weigert sich bei nicht sauberem File-System 'savedefault x' auszuführen. Das muß dann im Grub-editor beim booten gelöscht werden.

Wie bekommt den Grub was von einem unsauberen start mit?!? Oder unsauberen Filesystem. Das save-default wird doch schon vorm laden den kernels gesetzt. Das verstehe ich jetzt nicht?!?

e9hack · 18. April 2007

Zitat

Original von Negge
Soweit ich gelesen hab muss man bei Grub0.97 aber immer "default saved", sonst führt der immer den Eintrag unter default (also die Zahl) aus und irgnoriert andere Einstellungen.

Das war bei mir nicht so. Jetzt benutze ich acpi. Gelegentlich verwende ich grubonce, z.B. wenn ich einen anderen Kernel booten will. Das funktioniert problemlos.

Zitat

grubonce gibt es übrigend bei mir (normales debian/etch) nicht?!?

Ich habe Suse 10.1. Da wars mit dabei. Ich weiß nicht von wem es wirklich ist. Normalerweise steht bei Suse und grub irgenwas mit drin. Bei dem Scrip jedoch nicht.

Zitat

Wie bekommt den Grub was von einem unsauberen start mit?!? Oder unsauberen Filesystem. Das save-default wird doch schon vorm laden den kernels gesetzt. Das verstehe ich jetzt nicht?!?

Grub schaut irgendwo im Header vom FS nach, ob es sauber unmountet wurde. Wenn nicht, wird save-default nicht ausgeführt. Grub weigert sich dann zu booten, solange der save-default Eintrag im ausgewählten Menu steht. Da mein VDR keine Tastatur hat, ist das keine gute Lösung. Wenn man zwischen grubonce und unmount einen Reset auslöst, hat man das Problem natürlich auch.

Gruß
e9hack

wolf_rambatz · 18. April 2007

Schön, dass dieses Problem auch hier jemand mitbekommt

Nachdem meine Recherchen bis jetzt nur ergeben hatten, dass auch viele andere Debian-Nutzer nach dem Umstieg auf Etch das gleiche Problem haben (ohne es gelöst zu haben), bin ich zu LILO zurückgekehrt.

Irgendwie hat sich der Mechanismus von grub geändert: grub verwendet jetzt eine Datei "default" in /boot/grub. In meinem Fall kann da aber stehen, was will (sowohl mit grub-set-default als auch manuell probiert); grub (re)bootet immer den Kernel, der in der Liste zuerst steht. Ich gebe aber zu, dass ich den Mechanismus nicht 100%ig verstanden habe.

So wie es im offiziellen Manual beschrieben wird, klappt es jedenfalls nicht. Bin gespannt, ob sich hier eine nachvollziehbare Lösung ergibt.

Gruß,

Wolf

TCr82 · 18. April 2007

Ich muss sagen.. bin froh das ich noch nicht meinen vdr upgedatet habe (läuft noch auf sarge)

Aber ich habe mal für euch geschaut, ob da schon jemand an dem Problem dran ist, und siehe da:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378243
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=254475
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412652

Gruß,
Thomas

Negge · 19. April 2007

Yup, die Links beschreiben genau das Problem.

Ich hatte das auch nochmal getest. Auch ein savedefault in der menu.lst (mit anschließendem manuellen Auswählen des EIntrags beim boot) hatte keine Auswirkung und wurde nicht gespeichert.
Mich beschleicht daher das gefühl, da hängt mit dem im mbr installierten grub zusammen, das da irgendwie nen Bug hat. Eine neue Grub-Version wird beim Update, soweit ich das gesehen hab, nicht neu im MBR installiert.

Ich habs allerdings nicht mehr weiter getestet, da ich mir den Bootbereich nicht zerschießen wollte (Risiko war mir zu hoch). Daher verwende ich einen (nicht idealen) workarround, und zwar grub-0.95 aus sarge (dank Pinning). Tut auch unter etch problemlos seinen Dienst und hat keine extra Abhängigkeiten.

Hier meine apt-preferences-Datei (hab die 0.95 gepinnt):

Code

Package: grub
Pin: version 0.95*
Pin-Priority: 1005


Package: grub-doc
Pin: version 0.95*
Pin-Priority: 1005


Package: grub-splashimages
Pin: release v=3.1*,o=Debian
Pin-Priority: 1005

Alles anzeigen

Saxman2k · 21. April 2007

Nach dem Update auf Etch hatte ich auch zuerst den 0.95er Grub belassen. Beim Lesen dieses Threads jedoch wollte ich es nochmal mit der offiziellen 0.97 probieren.

Den Fehler, den ich beim letzten mal gemacht habe ist ganz einfach folgender:

Wenn grub mit aptitude upgedatet wird, wird der MBR nicht neu geschrieben!

Also nach dem Update ein beherztes "grub-install /dev/hda" eingegeben.
Jetzt läuft es so, daß ich mit "grub-set-default" einen Eintrag auswählen kann. Dieser wird auch beim nächsten Booten genommen. Dann beim NVRam-Eintrag in der menu.lst noch ein "savedefault 0" (0 ist bei mir der normal zu bootende Kernel) reingesetzt und fertig.

Was jedoch nicht funktioniert ist "grub-reboot". Die /boot/grub/default wird zwar entsprechend geschrieben, nach dem Booten aber nicht mehr geändert. Das hat den Nachteil, daß immer der NVRAM-Eintrag gebootet wird. Vielleicht habe ich ja hier auch noch so einen blöden Denkfehler wie die erneute Installation drin. Mal sehen - erstmal läuft es zumindest jetzt.

TCr82 · 22. April 2007

so.. habe gestern mein system NEU installiert und stecke gerade am gleichen Problem fest...

Meine (auf die wichtigsten punkte gekürzte) menu.list schaut nun folgendermassen aus:

Code

default saved
timeout         1




title           Debian GNU/Linux, kernel 2.6.20.1
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.20.1 root=/dev/hda1 ro vga=791
savedefault


title           Debian GNU/Linux, kernel 2.6.20.1 (single-user mode)
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.20.1 root=/dev/hda1 ro single
savedefault


title           Debian GNU/Linux, kernel 2.6.18-4-686
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.18-4-686 root=/dev/hda1 ro vga=791
initrd          /boot/initrd.img-2.6.18-4-686
savedefault


title           Debian GNU/Linux, kernel 2.6.18-4-686 (single-user mode)
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.18-4-686 root=/dev/hda1 ro single
initrd          /boot/initrd.img-2.6.18-4-686
savedefault


### END DEBIAN AUTOMAGIC KERNELS LIST


title NVRAM-Timer
root (hd0,0)
savedefault 0
halt

Alles anzeigen

Mein System starte ich dann wie folgt neu

Code

grub-set-default $((`grep ^title /boot/grub/menu.lst | wc -l`-1)) && reboot

Dann wird fleissig neu gestartet und mein PowerOff ausgewählt. Das Problem ist nur, dass nach einem erneuten einschalten, das System wieder auf dem PowerOff eintrag steht und aus geht...

Hat noch wer ne Idee?

Gruß,
Thomas

TCr82 · 22. April 2007

hmm.. laut diesem Bug-Report ist das Problem gefixt... ist aber anscheined noch testing.

Siehe hier

Ich hole mir das Paket mal, um zu schauen, ob es damit geht... melde mich dann nochmal...

Gruß,
Thomas

EDIT: ok... ist wohl doch nicht so...

Code

vdr:~# apt-cache policy grub
grub:
  Installiert:0.97-27
  Mögliche Pakete:0.97-27
  Paketstecknadel: 0.97-27
  Versions-Tabelle:
 *** 0.97-27 900
        500 cdrom://[Debian GNU/Linux 4.0 r0 _Etch_ - Official i386 DVD Binary-1 20070407-11:40] etch/main Packages
        900 http://ftp.de.debian.org etch/main Packages
        800 http://ftp.de.debian.org lenny/main Packages
        700 http://ftp.de.debian.org sid/main Packages
        100 /var/lib/dpkg/status

Alles anzeigen

es wird zwar dort geschrieben, dass der Bug gefixt sein soll.. aber bei mir funzt es irgendwie trotzdem nicht (wie bei euch ja auch)...

Also doch noch etwas weiter probieren...

TCr82 · 23. April 2007

ok.. hab mich heute nochmal an das Problem gemacht und bin dabei über diesen Beitrag gestolpert:

NVRAM funktioniert, GRUB-Menü Eintrag wird aber nicht ausgewählt

Demnach habe ich meinen PowerOff Eintrag abgeändert (das cat /boot/gr...hat bei mir anscheinend geholfen, so unsinnig das auch scheint..)

Gruß,
Thomas

gandalf · 11. Mai 2007

Zitat
Originally posted by aLiEnTxC
so.. habe gestern mein system NEU installiert und stecke gerade am gleichen Problem fest...

Meine (auf die wichtigsten punkte gekürzte) menu.list schaut nun folgendermassen aus:
Code
default saved
timeout         1




title           Debian GNU/Linux, kernel 2.6.20.1
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.20.1 root=/dev/hda1 ro vga=791
savedefault


title           Debian GNU/Linux, kernel 2.6.20.1 (single-user mode)
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.20.1 root=/dev/hda1 ro single
savedefault


title           Debian GNU/Linux, kernel 2.6.18-4-686
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.18-4-686 root=/dev/hda1 ro vga=791
initrd          /boot/initrd.img-2.6.18-4-686
savedefault


title           Debian GNU/Linux, kernel 2.6.18-4-686 (single-user mode)
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.18-4-686 root=/dev/hda1 ro single
initrd          /boot/initrd.img-2.6.18-4-686
savedefault


### END DEBIAN AUTOMAGIC KERNELS LIST


title NVRAM-Timer
root (hd0,0)
savedefault 0
halt
Alles anzeigen
Mein System starte ich dann wie folgt neu
Code
grub-set-default $((`grep ^title /boot/grub/menu.lst | wc -l`-1)) && reboot
Dann wird fleissig neu gestartet und mein PowerOff ausgewählt. Das Problem ist nur, dass nach einem erneuten einschalten, das System wieder auf dem PowerOff eintrag steht und aus geht...

Hat noch wer ne Idee?

Gruß,
Thomas
Alles anzeigen

Hi Thomas,

Ich habe wie bei Saxman2k beschrieben grub neu installiert und seitdem funzt es auch mit einer menu.lst die in Essenz deiner entspricht. Wichtig ist, wie bei dir, der savedefault NUMvor dem halt

Bei mir funktioniert jetzt wieder der "normale" shutdown über nvram-wakeup und die dort verankerten Mechanismen.

[workaround, not!! solved] Etch, Grub 0.97 und grub reboot savedefault-once (wegen NVRAM)

Jetzt mitmachen!

Teilen