3.2.0-4-486: Cannot read the Linux header

[Stimpelton]

Hallo zusammen,

ich habe mal wieder ein Problem - entweder mag Debian mich nicht oder ich stelle mich sehr blöd an.

Ich habe hier auf einer kleinen Kiste einen Debian Wheezy laufen, der stupide einmal am Tag per FTP ein Backup diverser anderer Kisten zieht. Vor ein paar Tagen habe ich gemerkt, dass der Rechner eingefroren ist und habe ihn entsprechend "hard reset" (Stecker raus), da das System komplett eingefroren war. Als HDD ist eine Compact Flash Karte verbaut, die ist auch laut kurzem Check fehlerfrei.

Wenn ich nun den Rechner anschalte, meldet sich GRUB mit folgenden Fehlermeldungen zu Wort:

Code: Alles auswählen

Linux 3.2.0-4-486 wird geladen ?
error: cannot read the Linux header.
Initiale Ramdisk wird geladen ?
error: you need to load the kernel first.

Ich habe in GRUB auch keine Auswahl anderer Kernels, lediglich failsafe ist noch dabei, bringt aber das selbe Resultat.

Also Knoppix-CD rein und schauen, ob eventuell die entsprechenden Dateien in /boot fehlen. Die sind aber vorhanden, und ich glaube (!) die md5 Werte müssten so auch stimmen. Wobei ich mir aber nicht ultimativ sicher bin, wo ich die am besten checke. Knoppix kennt debsums nicht, ich habe also einfach mal nach den Werten gegoogled (*räusper* professionell jaja *hust* ).


Inhalt der /boot/grub/grub.cfg
http://pastebin.com/wknwdm1j

md5sum
http://pastebin.com/LLeasUyN

ls -la von "/boot"
http://pastebin.com/GZznj9az


Ich bin jetzt etwas aufgeschmissen. Warum scheitert das Laden des Kernels denn immer?
Habt ihr da einen Ansatz? Ich bin auch irgendwie etwas unfähig mit Knoppix / einer Live-Umgebung einen neuen Kernel zu installieren, gebe ich offen zu...

Danke schon mal!

LG
Max

[Stimpelton]

Hat keiner eine Idee?

Für mich wäre ein erster Ansatzpunkt, wenn mir jemand sagen könnte ob der Fehler trotz (scheinbar?) richtigem MD5 Wert an den Kernel-Dateien liegen könnte - und wie ich eben jenen Kernel ersetzen kann ohne laufendes System (praktisch nur mit Knoppix vom USB Stick).

LG
Max

[rendegast]

/var/lib/dpkg/info/linux-image-..........-........md5sums

zBsp

Code: Alles auswählen

cd /mountpunkt
md5sums -c var/lib/dpkg/info/*.md5sums
resp.
md5sums -c var/lib/dpkg/info/*.md5sums          | egrep -v ": OK$"

(Beachte 'var/...' und nicht '/var/....')

ein Backup diverser anderer Kisten zieht.
....
Als HDD ist eine Compact Flash Karte verbaut, die ist auch laut kurzem Check fehlerfrei.

Nicht noch eine andere Platte als Speicher für die Backups?
Sodaß ein Wechsel der Platten stattgefunden hat?

Test in der grub-Shell, 'c' (TAB als Completion), in etwa

Code: Alles auswählen

grub> ls ( <TAB>
....
grub> ls (hd0 <TAB>
....
grub> ls (hd0,jenachdem)/ <TAB>
......
grub> ls (hd0,jenachdem)/boot

[Stimpelton]

Hey rendegast!

Danke für deine Antwort
Es ist nur die erwähnte HDD verbaut. Sozusagen eine SSD für arme Auch wenn es nicht klug ist, wie sich gerade beweist, wird alles auf dieser HDD gespeichert. Es handelt sich praktisch nur um ein "Backups der Backups", von daher empfand ich bei der Installation, dass dieses Setup ausreicht. (Beweist sich jetzt als böser Fehler.)

Die md5sums sind soweit alle "OK", bei zwei Dateien meckert er, die scheinen mir aber irrelevant:

Code: Alles auswählen

usr/share/vim/vim73/doc/help.txt: FEHLSCHLAG
usr/share/vim/vim73/doc/tags: FEHLSCHLAG
md5sum: WARNUNG: 2 berechnete Prüfsummen passten NICHT

Die Grub-Commandline kann auf die Dateien scheinbar zugreifen:

Code: Alles auswählen

grub> ls 
(hd0) (hd0,msdos1)

grub> ls (hd0,msdos1)/boot
System.map-3.2.0-4-486 config-3.2.0-4-486 grub/ vmlinuz-3.2.0-4-486 initrd.img-3.2.0-4-486

Ein entsprechendes

Code: Alles auswählen

linux vmlinuz<TAB>

führt nur wieder zur Fehlermeldung aus dem ersten Post / Thread-Titel.

Denke ich richtig, wenn ich sage: Es muss an GRUB liegen, weil die Dateien scheinbar okay sind und an sich scheinbar auch lesbar (sonst würde er ja keine md5 Hashes erstellen).

Habe mit Knoppix auch grub-install getriggert. Grub verweigert aber den Install weil die Inodes der Platte 256 statt 128 sind und scheinbar der grub-install immer noch Probleme mit inodes größer als 128 hat.

Liebe Grüße
Max

[rendegast]

ZBsp. grml hat auch lilo dabei,
es müßte eine einfache /etc/lilo.conf erstellt werden.

Noch

Code: Alles auswählen

mount --bind  /mountpunkt/boot /boot

Code: Alles auswählen

# If you want to prevent console users to boot with init=/bin/bash,
#  restrict usage of boot params by setting a passwd and using the option
#  restricted.
#compact       # faster, but won't work on all systems.
###message=/boot/message
menu-scheme=Wg:kw:Wg:Wg
read-only
prompt
timeout=20

#lba32
#   Was ist bei einer CF-Karte?

menu-title="-----CF-Karte-----"
# hier kommt der bootsektor hin:
boot=/dev/sda
# die disk mit /boot:
disk=/dev/sda
    bios=0x80
# die richtige map/start-Datei:
map=/boot/map.SDA
    
    vga = normal
#    vga = 0x0154   #normal    # force sane state
#    vga = 0x0121   #normal    # force sane state
#    append = "acpi=off"
#password=blafoo
#restricted
# End LILO global Section

default = 3.2.0-4-486

image = /boot/vmlinuz-3.2.0-4-486
  root = /dev/sda1
  label = 3.2.0-4-486
  initrd = /boot/initrd-3.2.0-4-486
#    append = "apm=on init 3"
#    append = "init 3"
#restricted
optional

(eventuell ist dieses label zu lang, dann kuerzen)




-----------------------------------------------------------
Aehhhh, anders:
obiges Mounten nach /boot bleibt,
aber dann eine Root-Mountzeile der (grml-)fstab hinzufügen

Code: Alles auswählen

echo "/dev/sda1  /  auto  defaults  0 1" >> /etc/fstab

liloconfig
#erstellt eine /etc/lilo.conf

# abschließend
lilo -v

Die erstellte lilo.conf noch auf das gemountete System kopieren.

[KBDCALLS]

ich denke mal der Kernel hat nen Hau weg. Hab das ganze mal in einer Virtualbox mit Wheezy und Kernel 3.9.0 nochvollzogen. haben den Kernel installiert und anschließend in ein anderes Verzeichnis verschoben. Gabs dann ein ähnliches Ergebnis. Am Ende kam dann folgende Ausgabe

Code: Alles auswählen

error: you need to load the kernel first.

Auch wenn du mit Sicherheit Grub 2 hast sollte sich die Fehlemeldungen ähneln die von Grub Legacy produziert werden. Ich würde erstmal versuchen den Installer im Rescue Modus zu starten. Und wenn das funktioniert den Kernel reinstallieren.

[Stimpelton]

Vielen herzlichen Dank für alle Antworten!

Die Idee mit dem Rescue-Install ist mir noch gar nicht gekommen Das werde ich direkt mal machen, im Normalfall installiert er ja die linux-header auch mit neu.

Wenn das nicht klappt geht's mit lilo weiter. Da schaue ich mir die Confi noch mal genauer an, scheint aber wirklich machbar zu sein - danke für die Beispiel-Confi!

Und wenn das nicht klappt, bleibt wohl nur neu aufsetzen. Dann aber mit einer anderen (älteren) Kernel-Version. Kann vielleicht auch daran liegen, dass der Rechner über etwas veraltete Hardware verfügt. Daher ja auch Debian als Distri des Vertrauens

LG
Max

[KBDCALLS]

Ich wurde aber doch mal schauen ob der Kernel nicht einen weg hat. Eventuel eine md5 oder sha Prüfsumme erstellen und das dann mit Kernel im deb vergleichen.

[Stimpelton]

Daran wird es gelegen haben, oder ein Mischmasch aus allem

Im rescue-Mode hat er sich geweigert, die Festplatte nach /target zu mounten (angeboten wurde sdb2, die Festplatte ist aber sda bzw. sda1 die Partition). Nach einem Unterbrechen des Installers und einem manuellen mounten nach /target wollte er nach wie vor GRUB nicht installieren ("Fehlercode 1").

Ich habe GRUB dann erstmal in Ruhe gelassen und durch den Installer den Kernel und die Standardpakete neu draufspielen lassen.

Daraufhin wollte GRUB nicht mehr arbeiten. Mit der Prompt vom GRUB konnte ich dann zwar den Kernel laden, aber dann hat er wegen dem initramfs rumgenölt - und dann hatte ich auch keinen Bock mehr.

Aktuell installiert Debian gerade Wheezy neu.

Die Frage bleibt: Warum hat der Installer im Rescue mir dauernd sdb mounten wollen, die gar nicht existiert?! Ist das ein Bug oder stimmt was mit dem Bios bei mir nicht? Der Installer partitioniert die Platte ganz brav und hat keinerlei Probleme...

LG
Max

[KBDCALLS]

Nö das dürfte kein Bug sein. Eine Möglickeit wäre das in dem Rechner mehrere Festplattenkontroler verbaut sind, und jenachdem welcher zuerst angesprochen wird, können schonmal die Laufwerksbezeichner wechseln. Aus sda wird sdb oder umgekehrt. Um dem aus dem Wege zu gehen benutz man nicht mehr die Bezeichner wie sda usw. sondern UUIDs . Ne andere Möglichkeit wären Labels . Und dem Linux ist es dann egal ob das Laufwerk dann als /dev/sda oder sonstwas angesprochen wird. Bei UUIDS ist Eindeutigkeit fast immer gegeben, bei Labels muß da schon mehr aufpassen Oder vergibt absichtlich identische Lables bei externen Laufwerken.

[Stimpelton]

Danke für die Info!

Kurze Zwischenmeldung nur noch mal:
Ich habe gestern einen Versuch gewagt und Debian noch mal geupdated per apt-get upgrade, und es war wieder genau das gleiche Problem. Ein neuer Kernel wurde installiert und Grub kann den Linux header nicht mehr lesen.
Irgendetwas stimmt da nicht, keine Ahnung woran es genau liegt (Hardware, OS, Kernel, ...), aber ich denke ich steige jetzt auf eine andere Distri um. Debian bleibt mir ja auf anderen Rechnern noch erhalten, aber aktuell ist mir das zu abenteuerlich.

LG
Max