Siduction Forum
Siduction Forum => Upgrade Warnings => Topic started by: mrsarmitage on 2012/02/08, 12:12:52
-
ich habe auf meiner 64Bit-Installation nach dist-upgrade bei den letzten beiden Kerneln das Problem, dass diese nicht gebootet werden können. Fehlermeldung: "Cannot read the linux header, you need to load kernel first." Der Kernel 3.2-1.towo.3-siduction-amd64 bootet einwandfrei.
[System: Host: siductionbox1 Kernel: 3.2-1.towo.3-siduction-amd64 x86_64 (64 bit, gcc: 4.6.2)
Desktop KDE 4.7.2 (Qt 4.7.4) Distro: siduction 11.1 One Step Beyond - kde - (201112302141)
Machine: Mobo: Gigabyte model: GA-MA74GM-S2H version: x.x Bios: Award version: FC date: 08/13/2009
CPU: Dual core AMD Athlon 64 X2 5200+ (-MCP-) cache: 1024 KB flags: (lm nx sse sse2 sse3 svm) bmips: 7232.56
Clock Speeds: 1: 1800.00 MHz 2: 1800.00 MHz
Graphics: Card: nVidia G71 [GeForce 7300 GS] bus-ID: 01:00.0 X.Org: 1.11.3.901 driver: nvidia Resolution: 1280x1024@50.0hz
GLX Renderer: GeForce 7300 GS/PCI/SSE2 GLX Version: 2.1.2 NVIDIA 290.10 Direct Rendering: Yes
Network: Card: Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller
driver: r8169 ver: 2.3LK-NAPI port: de00 bus-ID: 02:00.0
IF: eth0 state: up speed: 1000 Mbps duplex: full mac: 00:24:1d:5b:e6:88
Drives: HDD Total Size: 160.0GB (-) 1: WDC_WD1600JS
Info: Processes: 147 Uptime: 2:44 Memory: 760.6/2007.6MB Runlevel: 5 Gcc sys: 4.6.2 Client: Shell inxi: 1.7.27 ]
Die Headers sind installiert.
grub.cfg
[/### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux, mit Linux 3.2-5.towo.1-siduction-amd64' --class debian --class gnu-linux --class gnu --class os {
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root ce761d93-98a3-4631-8da1-785838768920
echo 'Linux 3.2-5.towo.1-siduction-amd64 wird geladen …'
linux /boot/vmlinuz-3.2-5.towo.1-siduction-amd64 root=UUID=ce761d93-98a3-4631-8da1-785838768920 ro quiet
echo 'Initiale Ramdisk wird geladen …'
initrd /boot/initrd.img-3.2-5.towo.1-siduction-amd64
}
menuentry 'Debian GNU/Linux, mit Linux 3.2-2.towo.1-siduction-amd64' --class debian --class gnu-linux --class gnu --class os {
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root ce761d93-98a3-4631-8da1-785838768920
echo 'Linux 3.2-2.towo.1-siduction-amd64 wird geladen …'
linux /boot/vmlinuz-3.2-2.towo.1-siduction-amd64 root=UUID=ce761d93-98a3-4631-8da1-785838768920 ro quiet
echo 'Initiale Ramdisk wird geladen …'
initrd /boot/initrd.img-3.2-2.towo.1-siduction-amd64
}
menuentry 'Debian GNU/Linux, mit Linux 3.2-1.towo.3-siduction-amd64' --class debian --class gnu-linux --class gnu --class os {
insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root ce761d93-98a3-4631-8da1-785838768920
echo 'Linux 3.2-1.towo.3-siduction-amd64 wird geladen …'
linux /boot/vmlinuz-3.2-1.towo.3-siduction-amd64 root=UUID=ce761d93-98a3-4631-8da1-785838768920 ro quiet
echo 'Initiale Ramdisk wird geladen …'
initrd /boot/initrd.img-3.2-1.towo.3-siduction-amd64]
Für Hinweise wäre ich dankbar.
UB
-
ls -al /boot/
df -h
-
@mrsarmitage, du bist neu hier, deswegen sage ich dir:
Towo macht hier im Forum eine äußerst effektive Hilfe in der kürzest denkbaren Art. Seine zwei Zeilen oben sollen Dir bedeuten, dass du ihm den Output der beiden Befehle in der Konsole zeigen sollst, damit er dir helfen kann:
- Was liegt in /boot
- Wieviel Platz ist noch auf der Platte
Seine cryptischen Buchstabenfolgen stellen also in keiner Weise eine verschlüsselte Beleidigung dar.
-
ralul,
mrsarmitage ist schon seit sidux tagen selig mit an Bord :)
greetz
devil
-
@ralul ist schon klar, also hier der output von ls -al/boot/:
drwxr-xr-x 3 root root 4096 Feb 8 15:45 .
drwxr-xr-x 25 root root 4096 Feb 7 14:42 ..
-rw-r--r-- 1 root root 116943 Dez 23 22:11 config-3.1-6.towo.2-siduction-amd64
-rw-r--r-- 1 root root 116832 Jan 13 12:17 config-3.2-1.towo.3-siduction-amd64
-rw-r--r-- 1 root root 116832 Jan 26 08:51 config-3.2-2.towo.1-siduction-amd64
-rw-r--r-- 1 root root 116907 Feb 6 21:41 config-3.2-5.towo.1-siduction-amd64
drwxr-xr-x 3 root root 12288 Feb 8 15:43 grub
-rw-r--r-- 1 root root 11010215 Jan 18 11:01 initrd.img-3.1-6.towo.2-siduction-amd64
-rw-r--r-- 1 root root 11416588 Jan 19 15:27 initrd.img-3.2-1.towo.3-siduction-amd64
-rw-r--r-- 1 root root 11422144 Jan 27 13:42 initrd.img-3.2-2.towo.1-siduction-amd64
-rw-r--r-- 1 root root 11178577 Feb 8 15:45 initrd.img-3.2-5.towo.1-siduction-amd64
-rw-r--r-- 1 root root 361641 Feb 7 16:15 ipxe.lkrn
-rw-r--r-- 1 root root 176764 Nov 13 19:01 memtest86+.bin
-rw-r--r-- 1 root root 178944 Nov 13 19:01 memtest86+_multiboot.bin
-rw-r--r-- 1 root root 1892559 Dez 23 22:11 System.map-3.1-6.towo.2-siduction-amd64
-rw-r--r-- 1 root root 1902610 Jan 13 12:17 System.map-3.2-1.towo.3-siduction-amd64
-rw-r--r-- 1 root root 1903745 Jan 26 08:51 System.map-3.2-2.towo.1-siduction-amd64
-rw-r--r-- 1 root root 1909304 Feb 6 21:41 System.map-3.2-5.towo.1-siduction-amd64
-rw-r--r-- 1 root root 2659824 Dez 23 22:11 vmlinuz-3.1-6.towo.2-siduction-amd64
-rw-r--r-- 1 root root 2643152 Jan 13 12:17 vmlinuz-3.2-1.towo.3-siduction-amd64
-rw-r--r-- 1 root root 2644464 Jan 26 08:51 vmlinuz-3.2-2.towo.1-siduction-amd64
-rw-r--r-- 1 root root 2656368 Feb 6 21:41 vmlinuz-3.2-5.towo.1-siduction-amd64
und df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
rootfs 149G 24G 119G 17% /
udev 999M 0 999M 0% /dev
tmpfs 201M 436K 201M 1% /run
/dev/disk/by-uuid/ce761d93-98a3-4631-8da1-785838768920 149G 24G 119G 17% /
tmpfs 5,0M 0 5,0M 0% /run/lock
tmpfs 402M 56K 402M 1% /tmp
tmpfs 402M 132K 402M 1% /run/shm
//192.168.2.220/Public/Ulli 916G 552G 364G 61% /media/QNAP1
der letzte Eintrag hier ist ein per fstab eingebundenes NAS
UB
-
Welches Filesystem benutzt Du?
-
ext4
-
Bitte führe mal als root folgendes aus:
grub-fstest /dev/sda1 crc /boot/vmlinuz-3.2-5.towo.1-siduction-amd64
grub-fstest /dev/sda1 crc /boot/vmlinuz-3.2-1.towo.3-siduction-amd64
-
root@siductionbox1:/home/ubochum# grub-fstest /dev/sda1 crc /boot/vmlinuz-3.2-1.towo.3-siduction-amd64
ffffffff
root@siductionbox1:/home/ubochum# grub-fstest /dev/sda1 crc /boot/vmlinuz-3.2-5.towo.1-siduction-amd64
ffffffff
-
Du könntest mal ein apt-get --reinstall install grub-pc versuchen.
Allerdings ist Dein Problem ein Fehler, den es gar nicht geben dürfte.
-
@mrsarmitage: Vielleicht liegt es nicht an Grub+Kernel sondern an der Hardware.
Wie alt ist die Festplatte bzw. ist sie sehr viel benutzt (z.B. 3y@24h/365d oder eher 3y@4h/d)?
Vielleicht liefert die Installation von smartmontools (http://wiki.debianforum.de/Festplattendiagnostik-_und_%C3%9Cberwachung) und die Frage nach dem Zustand (http://de.wikipedia.org/wiki/Self-Monitoring,_Analysis_and_Reporting_Technology#Auswertung) eine Erklärung.
Du kannst nachsehen mit
smartctl -t short /dev/sda
und nach 2 Minuten die Meldungen abfragen
smartctl -l selftest /dev/sda
Nicht alle Meldungen, die man zunächst als Ausfallswarnung sieht, zeigen auch Festplattenversagen an. (Auch schwache SATA-Kabel sind eine Ursache für Meldungen. Nach einem Kabelaustausch ist manchmal alles wieder in Butter.)
-
Also die Re-Installation von grub-pc hat keine Änderung gebracht, der Test mit smartmontools ebenfalls keine Fehlermeldungen. Der neueste Kernel bootet ebenfalls nicht. Bleibt nur Neu-Installation?
UB
-
Schwer zu sagen. Da es das Problem eigentlich nicht gibt, weiss man leider nicht, wann es das Problem nicht mehr gibt.
Du kannst entweder weitere Kernel abwarten (wobei ich nicht wirklich glaube, dass es der Kernel selbst ist) oder wirklich neu installieren.
greetz
devil
-
@mrsarmitage, was soll eine neu Installation bringen, wenn der siduction Installer bei dir einen Bug zeigt, den wir noch nicht herausgefunden haben?
Mich interessiert mal rein spekulatious:
fdisk -lu
(meine Theorie: du hattest mal eine extra /boot Partition)
Ausserdem würde ich, wenn neu-Installation, eine neue parallel Installation machen mit debootstrap (geht auch schneller), um siduction-installer Probleme auszuschliessen und zu vergleichen ....
-
ralul,
wie kommst Du auf Installer?
greetz
devil
-
Wenn bei einer Neu Installation der erste Kernel weiter gut geht, aber folgende nicht, kann es doch sein, dass irgendwelche Spezial Optionen verwandt worden sind bei der Installation, die aber nicht vollständig in die HD-Grub-Oderwas-Installation übernommen worden sind. Das wäre dann ein siduction-installer-bug.
Wenn ... gibt noch tausend andere Möglichkeiten, also Ausschlussmethode:
Wenn eine debootstrap NeuInstallation geht, kann man ausschliessen
- Hardware-Fehler
- Hardware-Inkopatibilitäten von siduction mit seiner Hardware
-
Ich mach's mal im spekulativen Modus.
1. Ich habe keine nvidia-Treiber installiert - geht hier auch ohne.
Solltest Du diese oder andere "propri"-Treiber installiert haben, entferne die und versuch's dann neu.
(Bei mir wird immer wieder eine Firmware-Warnung angezeigt für meine Netzwerkkarte. Die ignoriere ich - es ging bisher bei allen Kerneln ohne extra Firmware oder "propri"-Treiber (vielen, vielen Dank towo).
2. Es sind mehrere Kernel installiert und die letzten wollen nicht booten.
Boote mit dem "neuesten" Kernel der geht, geh in den Terminal und entferne mit
kernel-remover
alle angebotenen Kernel die entfernt werden können (außer dem gerade gebooteten, der sollte auch nicht angezeigt werden als "zu entfernen" und dem neuesten).
Damit bleiben dann 2 Kernel übrig, vielleicht hilft aufräumen Grub auf die Sprünge (habe Zweifel, aber vielleicht geht's auch ohne Neu-Installation).
-
so danke für eure Hinweise und Anregungen, ich habe jetzt doch neu installiert und d-u gemacht mit neuem Kernel und dieser bootet auch. Mit aktiviertem kdenext Repo kam dann auch KDE 4.7.4.
UB