KernelUpdate ändert die falsche menu.lst

framp · 20 Okt. 2010

Moin,

bei mir läuft ein LinuxServer im local LAN. Gestern habe mal wieder einen Update gefahren. Danach kam mein System nicht mehr hoch. Der Grund war schnell zu lokalisieren: Der Update beinhaltete einen KernelUpdate und dabei wurde die menu.lst updated, so dass sie die neue KernelVersion anzieht. Leider wird dabei nicht die menu.lst updated, die beim booten angezogen wird. Nachdem ich das System mit einer RescueCD gebootet hatte konnte ich das schnell fixen - einfach die RICHTIGE - menu.lst updated.

Weiss jemand was ich machen muss damit zuküftig ein KernelUpdate auf dem Server keine manuelle Intervention meinerseits erfordert?

gropiuskalle · 20 Okt. 2010

Scheint irgendwie konkret mit dem aktuellen Kernel-update zu tun zu haben - dieses Phänomen habe ich in den letzten Tagen z.B. ein paar mal bei forums.opensuse.org lesen können. Bei mir (oS 11.2) hat es aber hingehauen.

lOtz1009 · 21 Okt. 2010

Wieviele menu.lst gibt es bei dir?

admine · 21 Okt. 2010

Ist die menu.lst eine, aus einer anderen Distrie oder openSUSE-Version?

Evt. hilft es dir in der menu.lst die Links nach "vmlinuz" und "initrd" anzugeben.
Schau mal in /boot ... die gibt es nämlich noch und wurden früher immer im Bootloader verwendet.

Geht natürlich nur, wenn du /boot nicht für mehrere Distris zur Verfügung stellst.

framp · 21 Okt. 2010

Code:

idefix:/ # find . -name menu.lst -exec ls -la '{}' \;
-rw------- 1 root root 1230 Oct 16 19:39 ./linux2/boot/grub/menu.lst
-rw------- 1 root root 1237 Oct 16 18:05 ./boot/grub/menu.lst
-rw------- 1 root root 1547 Sep 13  2009 ./linux10.3/boot/grub/menu.lst

Da sieht man, dass ./boot/grub/menu.lst zuerst - nämlich beim KernelUpdate geändert wurde. Doch leider wird beim Booten die ./linux2/boot/grub/menu.lst angezogen. Man sieht deutlich, dass sie erst später von mir geändert wurde.
Ich habe bei mir immer 2 Partitionen -eine aktuelle - und eine BackupPartition mit einem älteren Stand (Genau den habe ich benutzt um die richtige menu.lst zu ändern ;-) )

Das /linux10.3 ist eine uralte Partition und wird irgendwann mal entsorgt.

Code:

idefix:/ # mount
/dev/sdd2 on / type ext3 (rw,acl,user_xattr)
...
/dev/sdd1 on /linux2 type ext3 (rw,acl,user_xattr)
/dev/sdb3 on /disks/vol1 type ext3 (rw,acl,user_xattr)
/dev/sdb2 on /linux10.3 type ext3 (rw,acl,user_xattr)
/dev/sdd5 on /disks/vol3 type ext3 (rw,acl,user_xattr)
/dev/md1 on /disks/raid1 type ext3 (rw,acl,user_xattr)
/dev/loop0 on /export/SuSE11.2 type iso9660 (rw)
/dev/loop1 on /export/SuSE11.3 type iso9660 (rw)

Code:

idefix:/ # fdisk -l

Disk /dev/sdb: 400.1 GB, 400088457216 bytes
...
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1         262     2104483+  82  Linux swap / Solaris
/dev/sdb2             263        2873    20972857+  83  Linux
/dev/sdb3            2874       48641   367631460   83  Linux

Disk /dev/sdd: 250.1 GB, 250059350016 bytes
...
   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1        1306    10490413+  83  Linux
/dev/sdd2            1307        2612    10490445   83  Linux
/dev/sdd3            2613        2744     1060290   83  Linux
/dev/sdd4            2745       30401   222154852+   5  Extended
/dev/sdd5            2745       30401   222154821   83  Linux

sda und sdc sind in einem RAID Verbund und habe ich deshalb in der Ausgabe gelöscht.

Die Frage ist also - warum beim KernelUpdate die nicht aktuelle menu.lst geändert wurde .

josef-wien · 21 Okt. 2010

Als Menüdatei (in GRUB-Diktion config_file) wird standardmäßig /boot/grub/menu.lst verwendet. Es ist aber möglich, bei der Installation von GRUB eine andere Datei festzulegen. Die zu verwendende Menüdatei wird in der Datei /boot/grub/stage2 gespeichert.

framp schrieb:
Die Frage ist also - warum beim KernelUpdate die nicht aktuelle menu.lst geändert wurde .

Nachdem ich bei Deiner mount-Ausgabe keine eigene Boot-Partition sehe, muß /boot ein ganz normales Verzeichnis auf sdd2 sein. Dort befinden sich also auch Kernel (vmlinuz) und initrd. Und dort gibt es ein Verzeichnis /boot/grub, das die GRUB-Dateien enthält.

Bei Deiner Konstellation weiß ich nicht, wo sich jetzt die beim Systemstart verwendeten Dateien befinden. Wenn sie sich auf sdd1 befinden, dann weiß das laufende System nichts davon, und dann wird sich ein Kernel-Update nicht auf sdd1, sondern auf sdd2 niederschlagen. Wenn sie sich auf sdd2 befinden, dann wird sich ein Kernel-Update ebenfalls auf sdd2 niederschlagen, und warum soll die im rpm-Paket enthaltene Routine auf die Idee kommen, daß Du nicht die standardmäßige menu.lst verwendest?

Sehe ich da etwas falsch?

Anonymous · 22 Okt. 2010

Zeig mal die /etc/grub.conf . Die wird, wie ich aus meinen Yastlogs sehe, von Suse immer ausgelesen (dann wahrscheinlich auch ausgewertet) bevor nach einem Kernelupdate die menu.lst geändert wird.

robi

framp · 22 Okt. 2010

Code:

idefix:/ # cat /etc/grub.conf
setup --stage2=/boot/grub/stage2 --force-lba (hd0,0) (hd0,0)
quit
idefix:/ #

Anonymous · 22 Okt. 2010

Wie es scheint, ist der Bootloader der bei dir startet nicht der der zum System gehört.

Dein System ist der Meinung seinen Bootloader auf hd0,0 zu haben. Entweder auf dieser Platte ist im MBR ein weiterer Grub aktiv, oder es haben sich bei dir durch Plattenein- oder -Umbauten die BIOS Reihenfolge geändert oder du hast mal per Hand in der device.map was geändert. Oder du hast von einem deiner anderen Systeme irgendwann mal beabsichtigt oder auch nicht, den Bootloader deines Systems überschrieben. Das ganze wird wohl nicht aufgefallen sein, weil zufälligerweise die Kernelversion in dem anderem Linux zufällig die selbe war. Also nehme ich mal an dein aktueller Grub gehört zum Backupsystem.

Bei mehr als einem Linux auf dem Rechner empfehle ich immer, entweder nur eines der Systeme hat überhaupt grub und die Konfigurationsdateien dazu und startet von dort aus die anderen Systeme, (dann ist aber auf den anderen Systemen die Grubpakete auch gar nicht installiert), oder jedes System hat seinen eigenen Grub mit seinen privaten Konfiguratiosdateien für sich ganz alleine und es wird nur vom BIOS her festgelegt, welches Linux jetzt gerade hochfahren soll.

Schau mal hier vorbei. Von den beiden Befehlketten die Erste, sollten jeden grub bootloader, ob aktiv oder nicht in deinem System finden.

robi

framp · 22 Okt. 2010

robi schrieb:
Entweder auf dieser Platte ist im MBR ein weiterer Grub aktiv, oder es haben sich bei dir durch Plattenein- oder -Umbauten die BIOS Reihenfolge geändert oder du hast mal per Hand in der device.map was geändert.

Ich habe die beiden Platten sda und sdc für das RAID später eingebaut (320er von Samsung). Scheint wohl damit zu tun zu haben.

Code:

idefix:~ # for i in $(awk '/[0-9]/ {print $4}' /proc/partitions);do file -s /dev/$i; done | grep -i grub | cut -d":" -f1
/dev/sdd
/dev/sdd1
idefix:~ # # oder wenn dieser Befehl nichts findet dann mal so versuchen
idefix:~ # for i in $(awk '/[0-9]/ {print $4}' /proc/partitions);do file -s /dev/$i; done | grep -i "x86 boot sector" | cut -d":" -f1
/dev/sda
/dev/sdb
/dev/sdc
/dev/sdd
/dev/sdd1
/dev/sdd4

Diese 2 Zeilen sind gut :thumbs:

Code:

idefix:~ # cat /boot/grub/device.map
(fd0)   /dev/fd0
(hd3)   /dev/disk/by-id/ata-WDC_WD2500JB-00GVC0_WD-WCAL76129579
(hd2)   /dev/disk/by-id/ata-SAMSUNG_HD320LD_S0K1J1GL502984
(hd1)   /dev/disk/by-id/ata-SAMSUNG_HD400LD_S0AXJ1CPA25939
(hd0)   /dev/disk/by-id/ata-SAMSUNG_HD320LD_S0K1J1LLB06398

Wie man sieht ist auf sdd1 (dem BackupLinux) der Bootloader - aber auf dem aktiven Linux auf sdd2 nicht. Das erklärt warum das passiert ist. Wie kann ich das am besten wieder glattziehen?

Anonymous · 22 Okt. 2010

du hast auf sdd zwei Bootloader, der erste im MBR ist der der arbeiten kann, der zweite würde erst funktionieren wenn der MBR entfernt würde.

Was du oben aus der grub.conf herausgeholt hast, passt nicht zu deinem System, damit greift grub während des Bootes auf die menü.lst des Backupsystems, zu

Code:

setup --stage2=/boot/grub/stage2 --force-lba (hd0) (hd0,1)
quit

währe richtiger

Code:

grub --batch < /etc/grub.conf

würde dann den Bootloader für dein System in den MBR schreiben und Yast und Suse würde das demnächst auch richtig verstehen. Wenn du nicht sicher bist, mach das besser über Yast, das überprüft das alles nochmal.

ganz kurze Einführung gibts auch hier.
robi

josef-wien · 22 Okt. 2010

framp schrieb:
Ich habe die beiden Platten sda und sdc für das RAID später eingebaut (320er von Samsung).

framp schrieb:
(hd2) /dev/disk/by-id/ata-SAMSUNG_HD320LD_S0K1J1GL502984
(hd0) /dev/disk/by-id/ata-SAMSUNG_HD320LD_S0K1J1LLB06398

Von Namen her müssen das die beiden RAID-Platten sein, somit kann "... (hd0) (hd0,1)" in der neuen grub.conf nicht stimmen. Welche von

framp schrieb:
(hd3) /dev/disk/by-id/ata-WDC_WD2500JB-00GVC0_WD-WCAL76129579
(hd1) /dev/disk/by-id/ata-SAMSUNG_HD400LD_S0AXJ1CPA25939

ist sdd? Und welche von den 4 Platten ist Deine Boot-Platte? Falls Du Dir die beiden Fragen als root vom System beantworten lassen willst:

Code:

hwinfo --disk | egrep "Device Files:|BIOS id:"

framp · 24 Okt. 2010

robi schrieb:
...Was du oben aus der grub.conf herausgeholt hast, passt nicht zu deinem System, damit greift grub während des Bootes auf die menü.lst des Backupsystems, zu

Code:

setup --stage2=/boot/grub/stage2 --force-lba (hd0) (hd0,1) quit

Das würde schon mal das Problem erklären. Nur verstehe ich nicht wie Du darauf kommst, dass hd0 das BackupSystem ist.

idefix:~ # cat /boot/grub/device.map
(fd0) /dev/fd0
(hd3) /dev/disk/by-id/ata-WDC_WD2500JB-00GVC0_WD-WCAL76129579
(hd2) /dev/disk/by-id/ata-SAMSUNG_HD320LD_S0K1J1GL502984
(hd1) /dev/disk/by-id/ata-SAMSUNG_HD400LD_S0AXJ1CPA25939
(hd0) /dev/disk/by-id/ata-SAMSUNG_HD320LD_S0K1J1LLB06398[/cuote] zeigt doch, dass hd0 eine von den RAID Platten ist :???:

wäre richtiger

Code:

grub --batch < /etc/grub.conf

würde dann den Bootloader für dein System in den MBR schreiben und Yast und Suse würde das demnächst auch richtig verstehen. Wenn du nicht sicher bist, mach das besser über Yast, das überprüft das alles nochmal.

Zum Vergrößern anklicken....

Zum Vergrößern anklicken....

Hm ... sehr merkwürdig: Yast sage mir

Code:

/dev/disk/by-id/ata-SAMSUNG_HD320LD_S0K1J1LLB06398-part1

wäre meine Custom Boot Partition. Das würde wieder zu der Ausgabe von der obigen devices.map passen. Aber ich habe die menu.lst vom Backupsystem geändert - so dass das System wieder booten konnte. Jetzt interessiert mich, wie Du siehst, dass die menu.lst vom BackupSystem angezogen wird :???:

framp · 24 Okt. 2010

josef-wien schrieb:
Welche von

framp schrieb:

(hd3) /dev/disk/by-id/ata-WDC_WD2500JB-00GVC0_WD-WCAL76129579
(hd1) /dev/disk/by-id/ata-SAMSUNG_HD400LD_S0AXJ1CPA25939

Zum Vergrößern anklicken....

ist sdd?

Die WD250er Platte - also hd3

Code:
Und welche von den 4 Platten ist Deine Boot-Platte? Falls Du Dir die beiden Fragen als root vom System beantworten lassen willst:

Code:

hwinfo --disk | egrep "Device Files:|BIOS id:"

Code:

idefix:~ # hwinfo --disk | egrep "Device Files:|BIOS id:"
  Device Files: /dev/sda, /dev/block/8:0, /dev/disk/by-id/ata-SAMSUNG_HD320LD_S0K1J1LLB06398, /dev/disk/by-id/scsi-SATA_SAMSUNG_HD320LDS0K1J1LLB06398, /dev/disk/by-path/pci-0000:00:07.1-scsi-0:0:0:0
  Device Files: /dev/sdb, /dev/block/8:16, /dev/disk/by-id/ata-SAMSUNG_HD400LD_S0AXJ1CPA25939, /dev/disk/by-id/scsi-SATA_SAMSUNG_HD400LDS0AXJ1CPA25939, /dev/disk/by-path/pci-0000:00:07.1-scsi-0:0:1:0, /dev/disk/by-id/edd-int13_dev81
  BIOS id: 0x81
  Device Files: /dev/sdc, /dev/block/8:32, /dev/disk/by-id/ata-SAMSUNG_HD320LD_S0K1J1GL502984, /dev/disk/by-id/scsi-SATA_SAMSUNG_HD320LDS0K1J1GL502984, /dev/disk/by-path/pci-0000:00:07.1-scsi-1:0:0:0, /dev/disk/by-id/edd-int13_dev82
  BIOS id: 0x82
  Device Files: /dev/sdd, /dev/block/8:48, /dev/disk/by-id/ata-WDC_WD2500JB-00GVC0_WD-WCAL76129579, /dev/disk/by-id/scsi-SATA_WDC_WD2500JB-00_WD-WCAL76129579, /dev/disk/by-path/pci-0000:00:07.1-scsi-1:0:1:0, /dev/disk/by-id/edd-int13_dev80
  BIOS id: 0x80

josef-wien · 24 Okt. 2010

framp schrieb:
Device Files: /dev/sdd, ..., /dev/disk/by-id/ata-WDC_WD2500JB-00GVC0_WD-WCAL76129579, ...
BIOS id: 0x80

Das ist Deine Boot-Platte. Laut device.map ist das (hd3).

Beim Systemstart richtet sich GRUB ausschließlich nach der vom BIOS vorgegebenen Festplattenreihenfolge (etwas anderes steht zu diesem Zeitpunkt nicht zur Verfügung). Im laufenden System dient device.map als Übersetzungstabelle, wenn (direkt oder indirekt) GRUB-Befehle ausgeführt werden. YaST geht davon aus, daß jene Platte, die mit (hd0) eingetragen ist, die Boot-Platte sei.

Mit dem grub.conf-Inhalt

Code:

setup --stage2=/boot/grub/stage2 --force-lba (hd3) (hd3,1)
quit

installierst Du bei unveränderter device.map GRUB (dessen Dateien sich auf sdd2 befinden) in den MBR von sdd (und ersetzt den bisherigen MBR, der auf Grund der in diesem Thema geschilderten Begebenheiten auf sdd1 zeigen muß).

framp · 25 Okt. 2010

Vielen Dank für die Erläuterungen :thumbs:

Da habe ich wieder was über Platten, Grub und devices.map gelernt

framp · 25 Okt. 2010

Zu früh gefreut ....

nachdem ich

Code:

setup --stage2=/boot/grub/stage2 --force-lba (hd3) (hd3,1)
quit

in die /etc/grub.conf geschrieben habe und dann

Code:

grub --batch < /etc/grub.conf

ausgeführt habe kam beim Booten die Meldung, dass es kein hd3 gibt. Daraufhin habe ich im Grub Prompt den Eintrag manuell geändert und konnte booten. Dann habe ich fälschlicherweise in

Code:

setup --stage2=/boot/grub/stage2 --force-lba (hd1) (hd1,1)
quit

geändert und wieder mit

Code:

grub --batch < /etc/grub.conf

installiert ...

und nun habe ich den Effekt, dass das System in einer EndlosBootSchleife steckt :???:

Bios - boot - kurzer Grub Display
Bios - boot - kurzer Grub Display
Bios - boot - kurzer Grub Display
Bios - boot - kurzer Grub Display
...

Da kein CDROM Laufwerk an der Kiste ist muss ich das erst einbauen ... toBeContinued :zensur:

josef-wien · 25 Okt. 2010

framp schrieb:
kam beim Booten die Meldung, dass es kein hd3 gibt

Das ist jetzt ein Nebenschauplatz, aber ich sehe gerade, daß laut der gestrigen hwinfo-Ausgabe die Platte SAMSUNG_HD320LD_S0K1J1LLB06398 vom BIOS keine BIOS-ID erhält (es gibt nur 0x80, 0x81 und 0x82, was für GRUB üblicherweise mit hd0, hd1 und hd2 ausgedrückt wird), und das finde ich sehr seltsam von Deinem BIOS. Aber kehren wir zum Problem zurück. Möglicherweise stand hd3 schon immer in der menu.lst drinnen, bis jetzt ist die Datei ja nicht verwendet worden.

framp schrieb:
Daraufhin habe ich im Grub Prompt den Eintrag manuell geändert und konnte booten.

Welchen Eintrag hast Du auf welchen Wert geändert?

framp schrieb:
setup --stage2=/boot/grub/stage2 --force-lba (hd1) (hd1,1)
und nun habe ich den Effekt, dass das System in einer EndlosBootSchleife steckt

Diese Reaktion verstehe ich nicht. Damit hast Du in den MBR der Platte SAMSUNG_HD400LD_S0AXJ1CPA25939 GRUB installiert. Aber diese Platte ist nicht Deine Boot-Platte, also ist es völlig belanglos, was dort im MBR steht (wenn der GRUB-Befehl erfolgreich war, könntest Du diese Platte vorübergehend zur Boot-Platte machen). Hast Du noch irgendwelche Aktionen ausgeführt?

framp · 26 Okt. 2010

josef-wien schrieb:
framp schrieb:

Daraufhin habe ich im Grub Prompt den Eintrag manuell geändert und konnte booten.

Zum Vergrößern anklicken....

Welchen Eintrag hast Du auf welchen Wert geändert?

Im grub mit 'e' hd3 in hd0 geändert - und schon kam das OS wieder hoch.

josef-wien schrieb:
framp schrieb:

setup --stage2=/boot/grub/stage2 --force-lba (hd1) (hd1,1)
und nun habe ich den Effekt, dass das System in einer EndlosBootSchleife steckt

Zum Vergrößern anklicken....

Diese Reaktion verstehe ich nicht. Damit hast Du in den MBR der Platte SAMSUNG_HD400LD_S0AXJ1CPA25939 GRUB installiert. Aber diese Platte ist nicht Deine Boot-Platte, also ist es völlig belanglos, was dort im MBR steht (wenn der GRUB-Befehl erfolgreich war, könntest Du diese Platte vorübergehend zur Boot-Platte machen). Hast Du noch irgendwelche Aktionen ausgeführt?

Jupp, wie geschrieben, die /etc/grub.conf auf hd1 geändert und setup aufgerufen. Hätte hd0 sein müssen - ich weiss

ps:

Anyhow: Auch ohne Einbau eines CD ROMs kann ich jetzt wieder nach manueller config von grub ein Linux starten - ist ein 10.3 welches auf der sdb2 noch aus alten Zeiten rumsteht... Leider findet

Code:

find /boot/vmlinuz

in der grub commandline nur hd0,1 - also sdb2 - obwohl -wenn ich das 10.3 starte und die sdd2 Partition mounte, dort ein vmlinuz finde :???:

Was ich nun überhaupt nicht verstehe, warum das 10.3 auf (hd0,1) startet - obwohl auf hdd (hd1) ja grub installiert ist :???:

josef-wien · 26 Okt. 2010

framp schrieb:
Hätte hd0 sein müssen - ich weiss

Nein, Du hättest die menu.lst auf sdd2 ändern müssen, was im übrigen noch zu tun ist. GRUB hat ja bereits gepaßt.

framp schrieb:
Was ich nun überhaupt nicht verstehe, warum das 10.3 auf (hd0,1) startet - obwohl auf hdd (hd1) ja grub installiert ist

Was hast Du bei

framp schrieb:
manueller config von grub

gemacht? Versuche bitte in Zukunft nicht mehr, Tätigkeiten auszulassen oder nur vage zu umschreiben, sonst werden wir nur schwer auf einen grünen Zweig kommen. Wenn Du die Boot-Reihenfolge nicht geändert hast, mußt Du Deine normale Boot-Platte wieder mit einem korrekten GRUB versorgt haben.

framp schrieb:
Leider findet find /boot/vmlinuz in der grub commandline nur hd0,1 - also sdb2 - obwohl -wenn ich das 10.3 starte und die sdd2 Partition mounte, dort ein vmlinuz finde

Wenn Du den Befehl aus dem Boot-Menü heraus ausführst, muß mehr kommen. Im laufenden System findet der Befehl nur Dateien auf Platten, die in device.map (und bei 10.3 ist das eine andere als bei 11.2) eingetragen sind.

Ich würde in der vorkorksten Situation folgendes machen:
- Auf der Partition sdd2 (unter 10.3 kann die auch anders heißen) im Verzeichnis /boot eine neue Datei anlegen, die auf den anderen Partitionen nicht exisitert, ich nenne sie /boot/framp
- Neu starten
- Vom textbasierten Boot-Menü mit c die GRUB-Befehlszeile aufrufen
- find /boot/framp
- root (hdX,Y) ==> X,Y laut Ergebnis von find
- setup (hdX) ==> X laut Ergebnis von find (= MBR)

KernelUpdate ändert die falsche menu.lst

Moderator

Guru

Moderator

Ultimate Guru

Moderator

Ultimate Guru

Anonymous

Gast

Moderator

Anonymous

Gast

Moderator

Anonymous

Gast

Ultimate Guru

Moderator

Moderator

Ultimate Guru

Moderator

Moderator

Ultimate Guru

Moderator

Ultimate Guru