• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

opensuse 11.3 menu.lst plötzlich ohne Einträge

Hab für einen Freund eine Neuinstallation gemacht, dabei eine Partition formatiert (war OSS 11.1 drauf) und 11.3 hinein installiert, alle anderen Partitionen gelassen. (Kleine Unschärfe: Hab nicht mehr in Erinnerung, ob die BOOT-Partition schon von der letzten Installation übrig war, oder erst jetzt eingerichtet wurde - wegen EXT4 Systempartition/Grub.) Es ist das einzige OS und lief einwandfrei. Seit ein paar Tagen geht jetzt das Booten nicht mehr. Stattdessen landet er im GRUB Dialog. Das Problem selbst konnte ich rasch in Ordnung bringen. Ursache war, dass die menu.lst nur noch den Kommentar-Header hatte, aber keine Menüeinträge mehr. Hab eine Kopie eingespielt.

Nun überlege ich, wie das passieren konnte.

Offensichtlich wurde nicht eine "andere" menu.lst gesucht, aber die Menüeinträge in der Erwarteten gelöscht. Also gehe ich nicht von verschiedenen Grubs aus. Meine, dass ich damals und jetzt in den MBR installiert habe (kann ich das im Nachhinein noch rausfinden?)

Hat jemand eine Idee dazu?

Da ich die Ursache nicht verstehe, weiß ich auch nicht, ob es vielleicht wieder passiert.

[UPD] mbr info ergänzt
 
gorgonz schrieb:
Ursache war, dass die menu.lst nur noch den Kommentar-Header hatte, aber keine Menüeinträge mehr.
Von einer Fehlfunktion mit derartigen Auswirkungen habe ich noch nichts gehört, ob sich da die Ursache nicht zwischen Rückenlehne des Sessels und Tastatur befindet?

gorgonz schrieb:
kann ich das im Nachhinein noch rausfinden?
Verwende robi's 1. Befehl aus http://www.linux-club.de/viewtopic.php?f=4&t=104557&p=642645&#p642645. Du kannst auch mit
Code:
dd if=/dev/sda bs=512 count=1 | hexdump -C | egrep -i "error|grub"
den MBR untersuchen, wenn die Ausgabe "error" enthält, hast Du einen generischen MBR, wenn sie "GRUB" enthält, steckt GRUB drinnen.
 
Hab inzwischen gelesen, dass auch andere von dem Problem betroffen sindkann aber noch nicht alles nachvollziehen. Den Test hab ich gemacht. Es kommt die error Variante, also ist es ein generischer MBR. Kann schon sein, dass von der früheren 11.1 Installation noch mal ein Grub übrig ist. Mir ist noch nicht klar, ob der generische MBR automatisch Vorrang hat, schließlich ist nur eine Platte drin. Wie wird das Bit zur Primärpartition festgelegt bzw. wo kann ich sehen, welches es geworden ist? Das BIOS liefert ja nur die Plattenreihenfolge.
 
Wenn das BIOS den PC von einer Festplatte starten soll, wird der Boot-Code in deren MBR ausgeführt. Durch einen generischen MBR wird die erste aktive Partition gesucht und der in deren Boot-Sektor enthaltene Boot-Code ausgeführt. Welche Partition aktiv ist, kannst Du mit Programmen wie fdisk, cfdisk, sfdisk oder parted feststellen (und auch ändern). Zur Anzeige wird hier im Forum meistens
Code:
fdisk -l
verwendet.

Die Standard-Vorgehensweise von openSUSE ist ein generischer MBR und Installation von GRUB in der Systempartition bzw. in der erweiterten Partition, wenn die Systempartition eine logische Partition ist.
 
Inzwischen gab es wieder ein kernel update auf v.6.34.7-0.5 und das problem ist wieder aufgetaucht. habe den rechner jetzt da und kann alles nachsehen.

  • MBR hat wohl generischen BootManager (->enthält string ERROR)
  • extended partition sda2 hat den GRUB (-> enthält string GRUB) und fdisk -l kennzeichnet diese mit "*", ist also die aktivierte
  • /boot/grub/menu.lst enthält vernünftige einträge
  • hab auch /etc/grub.conf nachgesehen, passt das? /dev/sda6 ist die System-Partition -> siehe unten
  • Für die Datei gilt: /boot/vmlinuz -> vmlinuz-2.6.34.7-0.5-desktop und die gibt es auch

Ah, jetzt hab ich was gefunden, der Link initrd stimmt nicht
Code:
ls -al
initrd -> initrd-2.6.34.7-0.5-desktop@

Der "@" soll wohl sagen, dass der link nicht geht, oder? Würde stimmen, denn es gibt nur "initrd-2.6.34.7-0.4-desktop"
könnte ich den link neu einrichten und auf *0.4 zeigen lassen? Irgendwie glaub ich, das hängt mit dem ext4 zusammen.

[UPDATE]
Hab händisch einen Menüeintrag erstellt, der nicht die Links initrd/vmlinuz hat, sondern die direkten Targets des Vorgänger-Kernels. Damit konnte ich wieder booten. Hab jetzt das Updaten auf den aktuellen Kernel nochmal gemacht und prompt wieder das alte Fehlerbild, dass in der menu.lst die Einträge fehlen. Allerdings ist diesmal die aktuelle initrd Datei vorhanden. Nach manuellem Einsetzen der Menüpunkte kann ich jetzt auch den neuen Kernel *0.5 booten. Aber es bedeutet, dass das Problem immer noch vorhanden ist <seufz> Weiss jemand Rat?[/UPDATE]


Code:
grub.conf:
setup --stage2=/boot/grub/stage2 --force-lba (hd0,1) (hd0,5)

Code:
fdisk -l
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1              63     4209029     2104483+  82  Linux swap / Solaris
/dev/sda2   *     4209030  1250258624   623024797+   f  W95 Ext'd (LBA)
/dev/sda5         4209093    46138679    20964793+   c  W95 FAT32 (LBA)
/dev/sda6        46138743   109049219    31455238+  83  Linux
/dev/sda7       109049283   528474239   209712478+  83  Linux
/dev/sda8       528474303  1250226494   360876096   83  Linux
Code:
menu.lst
# Modified by YaST2. Last modification on Thu Sep 16 23:05:57 CEST 2010
# THIS FILE WILL BE PARTIALLY OVERWRITTEN by perl-Bootloader
# Configure custom boot parameters for updated kernels in /etc/sysconfig/bootloader

default 0
timeout 8
##YaST - generic_mbr
gfxmenu (hd0,5)/boot/message
##YaST - activate

###Don't change this comment - YaST2 identifier: Original name: linux###
title openSUSE 11.3
    root (hd0,5)
    kernel /boot/vmlinuz root=/dev/disk/by-id/ata-WDC_WD6400AAKS-65A7B2_WD-WCASY5566815-part6    resume=/dev/disk/by-id/ata-WDC_WD6400AAKS-65A7B2_WD-WCASY5566815-part1 splash=silent quiet showopts vga=0x375
    initrd /boot/initrd

###Don't change this comment - YaST2 identifier: Original name: failsafe###
title Failsafe -- openSUSE 11.3
    root (hd0,5)
    kernel /boot/vmlinuz root=/dev/disk/by-id/ata-WDC_WD6400AAKS-65A7B2_WD-WCASY5566815-part6 showopts apm=off noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe vga=0x375
    initrd /boot/initrd
 
gorgonz schrieb:
Inzwischen gab es wieder ein kernel update auf v.6.34.7-0.5
vmlinuz-2.6.34.7-0.5-desktop und die gibt es auch
es gibt nur "initrd-2.6.34.7-0.4-desktop"
Wenn es keine Datei initrd-2.6.34.7-0.5-desktop gibt und die übrigen Dateien in /boot/ *-2.6.34.7-0.5-desktop heißen, dann wurde beim Kernel-Update keine initrd erstellt. Frage mich nicht, warum das hin und wieder passiert. Wenn Du Linux mit der initrd einer anderen Version startest, wird es in diesem Fall mit ein paar Fehlermeldungen wahrscheinlich funktionieren, ich empfehle aber, die initrd in einer chroot-Umgebung zu erstellen (es gibt einige Anleitungen von robi hier im Forum).

gorgonz schrieb:
hab auch /etc/grub.conf nachgesehen, passt das?
Diese Datei wird von der YaST-Bootloader-Konfiguration verwendet. Damit wird GRUB in den Bootsektor der Partition (hd0,1) installiert, die GRUB-Dateien befinden sich auf der Partition (hd0,5). Wenn (hd0) in der Datei /boot/grub/device.map auf die richtige Platte zeigt, paßt es.

Für die Zukunft wäre es überlegenswert, einen neuen Kernel vorerst zusätzlich zu installieren oder nach dem Kernel-Update und vor einem Neustart die initrd mit mkinitrd manuell zu erstellen. Außerdem solltest Du bei der YaST-Softwareverwaltung das Protokoll prüfen (/etc/sysconfig/yast2: PKGMGR_ACTION_AT_EXIT="summary").
 
Hi josef-wien, wir haben uns überholt, hatte gleichzeitig eine update info in meinen beitrag geschrieben. Hatte Glück, weil noch alle *0.4 Dateien da waren.

Diese Datei wird von der YaST-Bootloader-Konfiguration verwendet. Damit wird GRUB in den Bootsektor der Partition (hd0,1) installiert, die GRUB-Dateien befinden sich auf der Partition (hd0,5). Wenn (hd0) in der Datei /boot/grub/device.map auf die richtige Platte zeigt, paßt es.
Der grub sitzt auf der extended /dev/sda2, das sollte hd(0,1) entsprechen
/boot sitzt innerhalb root auf /dev/sda6, wäre dann konsequent hd(0,5), mit eigener boot-part. hatte ich mich getäuscht
hd0 muss richtig zeigen, da nur eine Platte und stimmt auch
--> das wars also nicht

Den Eintrag PKGMGR_ACTION_AT_EXIT habe ich von close auf summary geändert. Das könnte beim nächsten Mal eine wertvolle Änderung sein, danke für diesen Tipp! :)

Auf meinem eigenen Rechner passiert sowas nicht. Das muss doch einen Grund haben. Vielleicht doch, weil ich kein ext4 habe?

Code:
cat /etc/fstab
/dev/disk/by-id/ata-WDC_WD6400AAKS-65A7B2_WD-WCASY5566815-part1 swap                 swap       defaults              0 0
/dev/disk/by-id/ata-WDC_WD6400AAKS-65A7B2_WD-WCASY5566815-part6 /                    ext4       acl,user_xattr        1 1
/dev/disk/by-id/ata-WDC_WD6400AAKS-65A7B2_WD-WCASY5566815-part7 /home                ext3       defaults              1 2
/dev/disk/by-id/ata-WDC_WD6400AAKS-65A7B2_WD-WCASY5566815-part8 /usr                 ext3       acl,user_xattr        1 2
/dev/disk/by-id/ata-WDC_WD6400AAKS-65A7B2_WD-WCASY5566815-part5 /windows/C           vfat       users,gid=users,umask=0002,utf8=true 0 0

Code:
cat devicemap
(hd0)	/dev/disk/by-id/ata-WDC_WD6400AAKS-65A7B2_WD-WCASY5566815
 
Oben