staging.inyokaproject.org

Dazu hätte ich zwei Fragen:

Wie und wann wird festgestellt, dass der Bootvorgang erfolgreich war???

Wie kann man einen erfolglosen Bootvorgang simulieren???

Denn im Prinzip ist das ja jetzt schon eingebaut - nur es fehlen mir die Testparameter, es zu überprüfen.

Ich habe mit grub-set-default unter Grub-Legacy noch nicht gearbeitet oder experimentiert. Wenn ich es aber auf die schnelle richtig verstanden habe, dann könnte man das mit GRUB 2 doch auch durch laden einer anderen Konfigurations-Datei - was GRUB 2 ja erlaubt - und der fallback-Variable nachbilden, oder?

Ist jetzt erst mal nur ein Gedankensprung.

Gruß, Martin

Ja - war auch mein Ansatz, hab' ich dann aber verworfen. Nur wann kann man von einem erfolgreichen Bootvorgang ausgehen. Also müsste die Lösung zum Zurückstellen in der Aktivierung von rc.local liegen. Und hier einfach dann ein grubenv-back zurückkopieren. Also einmal nach erfolgreichen Bootvorhgang von der grubenv diese als Backup-Kopie anlegen.

Dazu muss man natürlich eigene Scripte erstellen und diese richtig einorden. Als Beispiel mal (meine jetzige Versuchs-Anornung):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

#!/bin/sh -e

cat << EOF
menuentry "KUbuntu 10.04 Lucid Lynx (KDE-Test)" {
        recordfail
	set quiet=1
	set saved_entry="Ubuntu 10.04 Lucid Lynx (GDM-Test)"
	save_env saved_entry
	insmod ext2
	set root=(hd0,6)
	search --no-floppy --fs-uuid --set 843c4345-0c0a-4df6-8abe-8114b06393b2
	linux /vmlinuz root=UUID=843c4345-0c0a-4df6-8abe-8114b06393b2 ro splash
	initrd /initrd.img
}
EOF

Die Zeilen 7 + 8 ersetzen den normalen Eintrag savedefault. Damit startet dann beim nächsten Bootvorgang die GDM-Variante. Und in der /etc/rc.local vom GDM-System habe ich zur Zeit vor dem exit

mount /dev/sda3;
cp -a /mnt/boot/grub/grubenv-back /mnt/boot/grub/grubenv;
umount /dev/sda3;

eingefügt. So klappt das - nur ist das der richtige Zeitpunkt???

Wie und wann wird festgestellt, dass der Bootvorgang erfolgreich war???

Das geht nur indirekt. Erstmal muss der Kernel gefunden werden, sodass Grub selber keinen Fehler feststellt. Danach muss der Bootvorgang bis zum Systemstart sauber durchlaufen, damit dann die rc.local mit grub-set-default den gewünschten Normalzustand einstellt. Wenn der gestartete Kernel selber rebootet oder die Resettaste gedrückt wurde, weiss Grub natürlich nicht das ein Fehler passiert ist. Desshalb wird ja auch vor dem Bootvorgang eingestellt, was gebootet werden soll wenn etwas schiefgeht.

Man geht also grundsätzlich erstmal davon aus, dass etwas schiefgeht und korrigiert das erst wenn es doch gutgegangen ist.

Wie kann man einen erfolglosen Bootvorgang simulieren???

• Resett

• falscher Kernel, grub-set-default in rc.local "vergessen" ...

Wenn ich es aber auf die schnelle richtig verstanden habe, dann könnte man das mit GRUB 2 doch auch durch laden einer anderen Konfigurations-Datei

Eigentlich muss man nur wissen, wo Grub2 den "saved" Kernel aus dem Menüeintrag speichert. Zusätzlich muss Grub2 in der Lage sein, in dieser Datei einen anderen als den gerade gestarteten einzutragen, als den der im Fehlerfall gestartet werden soll.

Ich glaube ich suche am WE nochmal nach einer freien Partition auf meinem Testrechner.

Eigentlich muss man nur wissen, wo Grub2 den "saved" Kernel aus dem Menüeintrag speichert.

Siehe oben - in der /boot/grub/grubenv, dort wo der Grub installiert ist.

Zusätzlich muss Grub2 in der Lage sein, in dieser Datei einen anderen als den gerade gestarteten einzutragen, als den der im Fehlerfall gestartet werden soll.

Dann ist meine Lösung, das Script oben genau, was Du suchst. Zwar ersetzt nicht Grub dieses, aber die Sequenz aus der rc.local oder einer anderen Datei, die man ja entsprechend im runlevel (rc2.d) setzen kann. Oder von Hand, wenn man im letzten Notsystem angekommen ist und die Basis repariert hat.

gruß syscon-hh

Jetzt habe ich das Script verstanden, und jetzt weiss ich auch, womit ich die Suchmaschine füttern muss. Mein Wissensstand ist jetzt folgender:

• save_env ersetzt savedefault

• set saved_entry="" ersetzt default

aber das wichtigste

• grub-editenv ersetzt grub-set-default

gefunden hier und an anderen Stellen, wo es eigentlich um eine kaputte grubenv geht (ubuntuuser müssen noch sudo einfügen).

cd /boot/grub
rm grubenv
grub-editenv grubenv create
grub-editenv grubenv set default=0

Damit ist die Richtung meiner Experimente schonmal vorgegeben. Es wird eben nichts einfacher.

Dakuan schrieb:

aber das wichtigste

• grub-editenv ersetzt grub-set-default

gefunden hier und an anderen Stellen, wo es eigentlich um eine kaputte grubenv geht (ubuntuuser müssen noch sudo einfügen).

cd /boot/grub
rm grubenv
grub-editenv grubenv create
grub-editenv grubenv set default=0

Danke, für die Info! Hab' ich gleich mal in die Linksammlung mit aufgenommen - also meine persönliche meine ich.

Gruß, Martin

Gerade ausprobiert - aus der rc.local heraus reicht:

grub-editenv  /boot/grub/grubenv  set default=0

oder anstelle 0 ein Text eingefasst in " ". Ggf. ist noch das Einbinden der Partition mit der Grub-Installation erforderlich (dabei Pfad entsprechend anpassen). Löschen (rm) und Erzeugen (create) als Zwischenschritt scheint nicht notwendig.

Danke für den Tipp - man lernt eben nicht aus. Newubunti wo soll denn das eingefügt werden, halt ich für relevant.

gruß syscon-hh

syscon-hh schrieb:

Newubunti wo soll denn das eingefügt werden, halt ich für relevant.

Also spontan würde ich sagen, dass man dazu wohl am besten einen eigenen Abschnitt innerhalb des Konfigurationsartikels anlegt, oder?

Wo sollte es sonst hin? rc.local ist noch ein wenig dünn dafür... hmm... also ich denke ein eigener Abschnitt innerhalb vom Konfig-Artikel "Automatischen Fallback einrichten" oder so ähnlich.

Oder habe ich Dich falsch verstanden?

Gruß, Martin

Ihr seid jetzt schneller als ich testen kann (hab ja noch nicht mal einen Rechner zum testen ausgesucht).

Also erstmal steht in dem Artikel

Die Datei grubenv darf nicht manuell verändert werden!!

da wäre vielleicht ein Hinweis auf grub-editenv angebracht.

Löschen (rm) und Erzeugen (create) als Zwischenschritt scheint nicht notwendig.

Bei den ersten relevanten Treffern von Google ging es, wie ich bereits andeutete, um eine fehlerhafte Datei. Für den von mir angedachten Fall ist sicherlich nur eine Aktualisierung notwendig.

Für den Wiki Artikel reicht wohl erstmal der Hinweis auf das Programm grub-editenv ausreichend, soweit es denn (hoffentlich) eine man page gibt.

Wenn es soweit ist, werde ich auf jeden Fall etwas darüber schreiben, auch wenn es nur für mich ist. Für das Wiki wird es aber wohl nicht geeignet sein, da ich das eher als Erfahrungsbericht in einem sehr speziellen konkreten Beispiel machen möchte, was somit nicht allgemeingültig sein kann.

Bei mir geht es weniger um das automatische ausprobieren aller möglichen bootbaren Systeme (fallback) sondern mehr darum, gezielt das Servissystem zu booten, um dann ein Backup oder Reparaturarbeiten durchführen zu können. Für so ein System sind noch weitere Punkte von Bedeutung, die wenig mit Grub zu tun haben. So sollte z.B. der SSH Server auf den Service/Notfallsystem denselben Schlüssel verwenden, wie das Haupsystem. Möglicherweise benötigt man auch noch einen minimalen Webserver, um Anwender darauf aufmerksam zu machen, das der eigentliche HTTP Server nicht da ist, u.s.w.

Zum thema gehört dann aber wieder, ob sich Grub2 auch über die /dev/ttyS0 ansprechen läßt, das wäre dann bei mir Plab-B. Plan-C wäre dann von irgendwoher eine Tastatur und einen Bildschirm anzuschließen ☹

Dakuan schrieb:

Ihr seid jetzt schneller als ich testen kann (hab ja noch nicht mal einen Rechner zum testen ausgesucht).

Da mach Dir mal keine sorgen. Ich habe im Moment weder ein Test-System noch die Zeit um Änderungen an irgend einem der GRUB-Artikel vorzunehmen - was natürlich nicht andere davon abhalten soll dies zu tun, falls gewollt.

Im Moment sieht es so aus - als könnte sich bei mir Ende Februar Anfang März ein Zeitfenster ergeben, um dann Änderungen in Angriff zu nehmen. Das wäre auch insofern gut, als dass sich dann bei GRUB2 bezüglich Lucid nicht mehr all zu viel ändert.

Gruß, Martin

Ja - man grub-editenv ist vorhanden. Sowie für weitere Befehle (Umfang kann mit ls /usr/bin | grep grub- ermittelt werden).

Ich habe mal den Artikel GRUB 2/Konfiguration aufgeteilt, um die Trennung vom Original nach einer Installation und nachträglicher Veränderungen in den Griff zu bekommen (siehe Baustelle/GRUB 2/Konfiguration).

Andererseits erhoffe ich durch die Ausgliederung der Beschreibungen zu den eigenen Skripten diesen Aspekt zu bündeln und damit auch die Lesbarkeit bzw. Anwendbarkeit zu verbessern.

gruß syscon-hh

Hallo syscon-hh,

wäre es nicht sinnvoller, dass was jetzt unter eigene Skripte steht innerhalb von GRUB 2 Konfiguration zu belassen und stattdessen die Standard-Skripte in einen eigenen Artikel auszulagern?

Argumente:

• Die Grub-Standardskripte zu erklären, geht doch ziemlich schnell in die Breite, was doch "GRUB 2 Konfiguration" dann eben auch schnell ausufern lassen würde.

• Wenn ich mich nicht so gut auskenne, dann würde ich von "GRUB 2 Konfiguration" erwarten, dass mir dort erklärt wird, wie man eigene Menü-Einträge konfiguriert. Denn der Hauptgrund für das Suchen nach "Konfigurationsmöglichkeiten" dürfte wohl der sein, dass GRUB 2 ein System nicht oder nicht so wie erwartet, in das Boot-Menü einbindet.

• Das Arbeiten an den Standard-Skripten würde ich als schon eher fortgeschritten bezeichnen, im Zweifel zerschießt man sich damit zumindest mal die Grund-Boot-Fähigkeit.

Oder spricht etwas anderes gegen diese Art der Aufteilung, was ich jetzt nicht sehe?

Gruß, Martin

Sehe ich im Moment anders - bin aber aufgeschlossen - dazu meine Argumentation:

Das WIKI Konfiguration beschreibt erst einmal den Zustand, den man mit den Standard-Komponenten erreicht / erreichen kann. Also was passiert, wenn ich in der /etc/default/grub nach einer Installation etwas einstelle bzw. verändere. Und so ist/war dieses WIKI ja mal angelegt worden - erst die Konfigurations-Datei grub und dann die vorhanden, mitgelieferten Skripte.

Hier bei der Konfiguration kann/muss man ggf. noch ausdrücklicher drauf hinweisen, das ausschließlich die Datei ../grub angefasst werden darf. Da liegen doch die Probleme.

Wer sich zutraut, weitergehende Veränderungen anzugehen, da gehe ich mal davon aus, dass man weiß, was man tut und sich erst einmal am Standard orientiert (erfahrungsgemäß leider nicht, weil doch nicht richtig gelesen wird).

Nur als Hinweis - rund ist das Ganze noch nicht, ist mir bewusst, da muss man noch dran arbeiten, ist sozusagen der erste Entwurf.

By the way - ist das Skript 10_hurd eigentlich noch relevant?? Das taucht(e) bei mir nie auf!!