Re: Grub2-UID Fehler
Am Mittwoch, 15. Juni 2011 schrieb Martin Steigerwald:
> Am Mittwoch, 15. Juni 2011 schrieb Martin Steigerwald:
> > Am Mittwoch, 15. Juni 2011 schrieb Siegfrid Brandstätter:
> > > Hallo Debianer,
> >
> > Hallo Siegfried,
> >
> > > da ich feststellen mußte das in meiner grub.cfg mit welcher
> > > gebootet wird mehrere grobe Fehler sind, wollte ich diese
> > > ausbessern. Da dies ja nicht direkt geht wie früher "in den
> > > guten alten Zeiten", habe ich also zuvor die
> > > /etc/grub.d/40_custom editiert ohne die ersten Zeilen zu ändern
> > > oder zu löschen. Danach ein "chmod -x
> > > /etc/grub.d/30_os-prober" mit einem nachfolgendem "update-grub"
> >
> > Welche Fehler denn? Wenn es denn gebootet hat, war der Zustand
> > vorher offenbar besser als nach deinen Änderungen.
> >
> > Bei 40_custom sind die Zeilen am Anfang sehr wichtig:
> >
> > merkaba:/etc/grub.d> cat 40_custom
> > #!/bin/sh
> > exec tail -n +3 $0
> > # This file provides an easy way to add custom menu entries.
> > Simply type the
> > # menu entries you want to add after this comment. Be careful not
> > to change
> > # the 'exec tail' line above.
> >
> > Also das exec tail ist ziemlich wichtig. Denn es sorgt dafür, dass
> > alles was nach den drei Kommentarzeilen kommt, dann unverändert in
> > der grub.cfg landet. D.h. nach den Kommentaren ist nichts mehr mit
> > Shell-Programmieren, sondern nur die Konfigurationseinträge, wie
> > sie auch in der grub.cfg dann stehen.
>
> Anderersherum ists noch wichtiger:
>
> *ohne* exec tail interpretiert die Bash Deine
> GRUB-Konfigurationseinträge als wären sie ein Shell-Skript. Und das
> könnte mir die lustigen Fehlermeldungen von unten schon erklären.
>
> In /etc/grub.d sind *Shell-Skripte*. Der Trick mit exec-Tail sorgt
> dafür, dass der Rest dieses Skriptes direkt in die grub.cfg geht.
> Der exec-Befehl ersetzt den Prozess mit dem Skript durch den
> tail-Befehl, der auf das Skript ($0) losgeht.
>
> Ich hab da durchaus den Kopf geschüttelt, als ich das zum ersten Mal
> gesehen hab, aber so haben das die GRUB-Entwickler nunmal gelöst.
>
Da habe ich den Vorteil das ich das gar nicht verstehe was da passiert,
der Vorteil des Laien ;-)
> Eine andere Änderung, die ich nicht verstehe, ist, dass GRUB 2 nun
> eines von beiden Partitionen oder Festplatten ab eins zählt, das
> andere aber immer noch ab Null. GRUB 1 hat Beides ab null gezählt.
> Ich frage mich, wie jemand auf die irrsinnige Idee kommt, dann nur
> eines auf die Zählung ab eins umzustellen. Entweder dann wenigstens
> beides oder einfach so lassen.
>
Das kommt mir auch unlogisch vor.
> Bescheuert finde ich, auch den Standard-Boot-Eintrag per Nummer vom
> Anfang an zu definieren:
>
> set default="0"
>
> Denn die Stelle, an der ein Eintrag steht, ändert sich ja auch
> durchaus mal, wenn ich einen neuen Kernel installiere. Und dann
> bootet GRUB nicht mehr den Eintrag, der vorher ausgewählt war. Das
> hat LILO besser gemacht. Da war der Standard-Eintrag mit Label
> angegeben.
>
> Aber gut, anstatt den Kopf zu schütteln, wäre es wohl besser
> Fehlerberichte zu schreiben, bzw. was die Zählweise ab 1 angeht, mal
> herauszufinden, warum die GRUB-Entwickler das so gemacht haben.
> Irgendeinen Grund dafür wirds wohl schon geben. Wenn es aber um
> akademische Richtigkeit geht, dann... *grrr*
>
> Ja, also bin da durchaus bei dir, wenn du GRUB 2 als umständlich
> empfindest. Der ein oder andere ist da vielleicht auch auf Syslinux
> oder Ähnliches umgestiegen. Gegen GRUB 1 spricht, dass der zumindest
> von den GRUB-Entwicklern wohl kaum noch gewartet wird. Wenn er
> funktioniert, kanns einem aber egal sein, solange Debian-Pakete
> existieren.
Mich wundert nur das du von dem Fehler beim alten Grub, mit den
Partitionen zu vertauschen noch nicht gehört hattest. Aber dem neuen
möcht ich das nicht unterstellen das er das auch macht. Es dürfte eher
mir bei dem Chaos passiert sein das ich hatte als die Platte
vollgelaufen war.
--
Einen Schönen Gruß,
Sigi
Reply to: