Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [DE] Grub2 Fortsetzung  (Read 3476 times)

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
[DE] Grub2 Fortsetzung
« on: 2010/10/26, 15:52:18 »
Dann wollen wir doch mal so freundlichen Wünschen entsprechen. Wie auch von von ralul schon dankenswerter Weise geschrieben, deaktivieren des 30_os_prober entsorgt schon vielen Schrott. Das von ralul gebrachte Beispiel kann praktisch so als Anleitung übernommen werden, so soll das mal aussehen, wenn Grub2 fertig ist. Die Anzeichen in den Quellen mehren sich, dass es da voran geht. Bis dahin ist halt Handarbeit angesagt.

Bis dahin bringt der Einsatz der 30_os_prober ungefähr (momentan -7) folgende Ergebnisse:
Code: [Select]

### BEGIN /etc/grub.d/30_os-prober ###
Found Debian GNU/Linux (squeeze/sid) on /dev/mapper/vg0-web_root

#01. Alf - das ist eigentlich eine virtuelle Maschine, aber richtig erkannt
#          Kann man nur nichts im Bootmenü mit anfangen
#          * die uuid ist an dieser Stelle erstaunlicher Weise richtig (vg0-web_root)
menuentry "Debian GNU/Linux (squeeze/sid) (on /dev/mapper/vg0-web_root)" {
insmod raid
insmod mdraid
insmod lvm
insmod part_msdos
insmod ext2
set root='(vg0-web_root)'
search --no-floppy --fs-uuid --set 343932b6-d8dd-4a74-8489-ee6c012a12bb
linux /boot/vmlinuz-2.6.32-5-amd64 root=/dev/dm-4
initrd /boot/initrd.img-2.6.32-5-amd64
}

#02. Alf - Das ist ein typisches Beispiel für Schwachsinn aus 30_os_prober:
#          * richtig erkannt wird, dass das Teil auf vg1-root_neu liegt
#          * unschön ist die Verwendung einer uuid, die richtig ist (md0)
#          * fatal ist die Verwendung root=/dev/md1 statt /dev/mapper/vg1-root_neu
#          * Dass der Xen-Kernel auch noch dazugemischt wird, ok, er ist halt da  
Found Debian GNU/Linux (squeeze/sid) on /dev/mapper/vg1-root_neu
menuentry "Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 (on /dev/mapper/vg1-root_neu)" {
insmod raid
insmod mdraid
insmod part_msdos
insmod part_msdos
insmod ext2
set root='(md0)'
search --no-floppy --fs-uuid --set c387b4e4-9a88-40c6-9d69-10bf607b8828
linux /vmlinuz-2.6.32-5-xen-amd64 root=/dev/md1 ro nolapic_timer lapic nolapic_timer
initrd /initrd.img-2.6.32-5-xen-amd64
}

#03. Alf - Selbes Spiel, anderer Kernel
menuentry "Debian GNU/Linux, with Linux 2.6.32-5-amd64 (on /dev/mapper/vg1-root_neu)" {
insmod raid
insmod mdraid
insmod part_msdos
insmod part_msdos
insmod ext2
set root='(md0)'
search --no-floppy --fs-uuid --set c387b4e4-9a88-40c6-9d69-10bf607b8828
linux /vmlinuz-2.6.32-5-amd64 root=/dev/md1 ro nolapic_timer lapic nolapic_timer
initrd /initrd.img-2.6.32-5-amd64
}

#04. Alf - Auch hier wieder sichtbar - Kernel passt zur virtuellen Maschine
#          Leider am Thema vorbei, denn diese Maschine will ich nun wirklich
#          nicht starten.
Found Debian GNU/Linux (squeeze/sid) on /dev/mapper/vg1-web_root_neu
menuentry "Debian GNU/Linux (squeeze/sid) (on /dev/mapper/vg1-web_root_neu)" {
insmod raid
insmod mdraid
insmod lvm
insmod part_msdos
insmod ext2
set root='(vg1-web_root_neu)'
search --no-floppy --fs-uuid --set b1a15ad7-035a-4622-8b2a-fb0981515aa1
linux /boot/vmlinuz-2.6.32-5-amd64 root=/dev/dm-0
initrd /boot/initrd.img-2.6.32-5-amd64
}
### END /etc/grub.d/30_os-prober ###

## legende
#  /dev/md0: UUID="c387b4e4-9a88-40c6-9d69-10bf607b8828" TYPE="ext2"
#  /dev/mapper/vg0-web_root: LABEL="web_root" UUID="343932b6-d8dd-4a74-8489-ee6c012a12bb" TYPE="ext4"
#  /dev/mapper/vg1-web_root_neu: LABEL="web_root_neu" UUID="b1a15ad7-035a-4622-8b2a-fb0981515aa1" TYPE="ext4"
 



Im Endeffekt ist alles, was 30_os_prober geliefert hat, für die Tonne, denn da wird kein funktionierendes System draus.
Niedlich sind auch noch die Doppeleintragungen für insmod part_msdos. Bei den virtuellen Maschinen fehlen die, da wird einfach der Eintrag aus der jeweiligen grub.cfg genommen und entsprechend modifiziert.

Code: [Select]

### BEGIN /etc/grub.d/10_linux ###
Found linux image: /boot/vmlinuz-2.6.32-5-xen-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-xen-amd64
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64' --class debian --class gnu-linux --class gnu --class os {
insmod raid
insmod mdraid
insmod part_msdos
insmod part_msdos
insmod ext2
set root='(md0)'
search --no-floppy --fs-uuid --set c387b4e4-9a88-40c6-9d69-10bf607b8828
echo 'Loading Linux 2.6.32-5-xen-amd64 ...'
linux /vmlinuz-2.6.32-5-xen-amd64 root=/dev/md1 ro lapic nolapic_timer
echo 'Loading initial ramdisk ...'
initrd /initrd.img-2.6.32-5-xen-amd64
}
Found linux image: /boot/vmlinuz-2.6.32-5-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-amd64
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-amd64' --class debian --class gnu-linux --class gnu --class os {
insmod raid
insmod mdraid
insmod part_msdos
insmod part_msdos
insmod ext2
set root='(md0)'
search --no-floppy --fs-uuid --set c387b4e4-9a88-40c6-9d69-10bf607b8828
echo 'Loading Linux 2.6.32-5-amd64 ...'
linux /vmlinuz-2.6.32-5-amd64 root=/dev/md1 ro lapic nolapic_timer
echo 'Loading initial ramdisk ...'
initrd /initrd.img-2.6.32-5-amd64
}
### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###
Found linux image: /boot/vmlinuz-2.6.32-5-xen-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-xen-amd64
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-xen-amd64 and XEN 4.0-amd64' --class debian --class gnu-linux --class gnu --class os --class xen {
insmod raid
insmod mdraid
insmod part_msdos
insmod part_msdos
insmod ext2
set root='(md0)'
search --no-floppy --fs-uuid --set c387b4e4-9a88-40c6-9d69-10bf607b8828
echo 'Loading Linux 2.6.32-5-xen-amd64 ...'
multiboot /xen-4.0-amd64.gz placeholder  
module /vmlinuz-2.6.32-5-xen-amd64 placeholder root=/dev/md1 ro lapic nolapic_timer
echo 'Loading initial ramdisk ...'
module /initrd.img-2.6.32-5-xen-amd64
}
### END /etc/grub.d/20_linux_xen ###


Die 10_ ist fehlerfrei bis auf das doppelte Modul part_msdos. Hurra, die Wahrscheinlichkeit ist groß, dass das System nach dem Update noch startet. Die 20_linux_xen funktioniert so auch, ist aber von Schönheit weit entfernt. Was allerdings fehlt, ist in der Xen-Erkennung die richtige Zusammenstellung auf den Dom0-Kernel im LVM. Bereinigt man diese "Kleinigkeiten" und schiebt das in die 40_custom oder in eine Kopie 09_xxx, hat man ein funktionierendes System und kann ganz entspannt der Entwicklung in den Scripten folgen.

Als Anfänger möchte ich aber mit solchem Mist eigentlich nichts zu tun haben, da bin ich einfach mal überfordert. Das Argument mit dem Verzicht auf die separate Bootpartition zieht auch nicht, da ohne separate Boot-Partition LVM und Verschlüsselung nicht wirklich möglich sind. Irgendwie sträuben sich dann bei mir die Nackenhaare, solche Sachen müssen in der Entwicklung gesehen und dediziert mit Workaround an die breite Masse gegeben werden. Ich bleibe bei meiner Meinung: Grub2 ist toll, die Scripte für die Erstellung der Konfiguration sind in diesem Zustand für den Anus.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline ralul

  • User
  • Posts: 1.814
Grub2 Fortsetzung
« Reply #1 on: 2010/10/26, 16:36:40 »
Immer wieder springt mir LVM bei Grub2 Bugreports in die Augen. Ich kann dazu aber nichts sagen, weil mich LVM nicht interessiert (LVM ist nur ein den dynamischen Disks bei Microsoft vergleichbarer Hack in meinen Augen).

Zweimal insmod part_msdos könnte auch ein Hack sein für spät reagierende Biose ?

Meine Frage im anderen Thread war, bezüglich separater /boot Partition:
Wo wird der Symlink (vmlinuz) dann hingelegt bei einer Kernel Installation, in die /boot Partition oder auch in die /-root Partition ?
experiencing siduction runs better than my gentoo makes me know I know nothing

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
Grub2 Fortsetzung
« Reply #2 on: 2010/10/26, 18:14:54 »
Doofe Frage: Welcher Symlink? Der wird doch meines Wissens nur benutzt/gesetzt, wenn man seine Kernel unversioniert als Metapackage installiert, oder? Ich habe hier keine Symlinks.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen

Offline agaida

  • User
  • Posts: 1.760
    • http://g-com.eu
Re: Grub2 Fortsetzung
« Reply #3 on: 2010/10/27, 11:06:43 »
Quote from: "ralul"
Immer wieder springt mir LVM bei Grub2 Bugreports in die Augen.

LVM2 und Grub2 ist eigentlich eine feine Sache. LVM2 ist eigentlich unverzichtbar, wenn man mehr als Standard mit einem Rechner anstellen möchte. Wenn man sich einmal mit der Philosophie dahinter beschäftigt hat, wird man es lieben lernen. Eine Abstraktionsebene mehr im Bereich Blockdevices macht die ganze Sache natürlich nicht unbedingt einfacher zu verstehen und eventuell auch anfälliger für Bedienfehler. Nachdem ich mir in  meinen Anfängerzeiten mit LVM mal fürchterlich ins Knie geschossen habe, habe ich mich noch mal dem Thema gewidmet - Fazit: Ich weiss gar nicht, wie ich vorher glücklich leben konnte.

Nachdem Du schon einen um die Auswirkungen von Scripting bereinigten Abschnitt Grub.cfg eingestellt hast, stell Dir bitte vor, was passiert, wenn Du direkt nach LVM bootest und bestimmte Module nicht geladen werden oder der falsche Kernel angezogen wird etc. pp.

Die LVM-Problematik kann ich voll und ganz nachvollziehen, nach der Repartitionierung meines Raid1/LVM Systems verweigerten meine XEN-Maschinen allesamt den Dienst. Der erhofft einfache Umstieg von einem System mit der Architektur md0 - /boot, md1 - swap, md2 - /, md3 - lvm2 zu
md0 -/boot, md1 - swap, md2 -lvm mit / auf vg0-root war es dann auch nicht. Auch hier versagte eine Automatik gleich mehrfach. Diesmal war es die Integration der benötigten Module in die initrd.

Jetzt stellen wir uns mal vor, was bei einem Update passiert, an dessen Ende ein update-initramfs und update-grub auf der Liste steht. Frohsinn ist angesagt. So was ist zwar relativ einfach aus der Welt zu schaffen, wenn man es schon mal gemacht hat, aber ganz ehrlich - wer hat das schon, dazu noch aus der kalten, parat. Diese Meldungen liest man dann oft, auch gerne noch mit Verschlüsselung aufgepeppt, in allen Foren. Da wird dann Hilfe von aussen oftmals auch grenzwertig.

Dieses relativ einfach aus der Welt schaffen hat dann bei mir am heutigen Tag 3 Stunden gedauert - ich dachte eigentlich, ich würde im Thema stehen, es hat aber trotzdem gedauert, dieses doch recht komplexe Thema zu sortieren. Die alte Regel von Murphy: "Komplexe Systeme erzeugen komplexe Fehler!" gilt weiterhin, also macht eine Steigerung der Komplexität eines Systems die Fehlersuche und -beseitigung nicht einfacher. Die Vermeidung von Fehlern bei der Programmierung auch nicht.
There's this special biologist word we use for "stable". It's "dead". ~ Jack Cohen