Upgrade Problem von 2.6.5 nach 2.6.7
Upgrade Problem von 2.6.5 nach 2.6.7
Hi all,
ich hab da ein unschönes Problem. Ich wollte meine Kiste von linux 2.6.5 auf 2.6.7 upgraden. Leider klappt das nicht in beiden Fällen benutze ich die Standard-Pakete von debian sid.
Alter Kernel: kernel-image-2.6.5-1-i386
Neuer Kernel: kernel-image-2.6.7-1-i386
Also alles sehr konservativ. Im Prinzip müsste auch die i686 Varainte laufen.
Das Problem ist, dass init das Console-Device nicht findet.
Nun zum Setup:
1. Ich benutze Grub als Bootloader, weil lilo immer Zicken macht, da die IDE Drives zur Bootzeit nicht vorhanden sind, wohl aber wenn Linux beootet wurde. Außerdem hat Grub noch einige andere angenehme Features, die ich nicht missen möchte.
2. Die /boot/grub/menu.lst sieht so aus:
timeout=20
default=0
title 2.6.5
kernel /boot/vmlinuz-2.6.5-1-386
initrd /boot/initrd.img-2.6.5-1-386
title 2.6.7
kernel /boot/vmlinuz-2.6.7-1-386
initrd /boot/initrd.img-2.6.7-1-386
Alles sehr rudimentär aber mit dem 2.6.5 funktionierts.
3. Wenn Grub den Kernel lädt, wird auch korrekt das richtige initrd.img geladen zumindest zeigt er das so an.
4. Nun zu der Ausgabe des Kernels während des Hochfahrens.
4.1 Ausgabe des 2.6.5 Kernels
[...]
sym0: using LOAD/STORE-based firmware.
sym0: SCAN AT BOOT disabled for targets 1 2 3 4 5 6.
sym0: SCAN FOR LUNS disabled for targets 0 1 2 3 4 5 6.
sym0: SCSI BUS has been reset.
scsi0 : sym-2.1.18i
Using anticipatory io scheduler
Vendor: IBM Model: DORS-32160 Rev: WA0A
Type: Direct-Access ANSI SCSI revision: 02
sym0:0:0: tagged command queuing enabled, command queue depth 16.
sym0:0: FAST-10 SCSI 5.0 MB/s ST (200.0 ns, offset 15)
SCSI device sda: 4226725 512-byte hdwr sectors (2164 MB)
SCSI device sda: drive cache: write back
/dev/scsi/host0/bus0/target0/lun0: p1 p2 p3
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Adding 249832k swap on /dev/sda1. Priority:-1 extents:1
EXT3 FS on sda2, internal journal
4.2 Und nun die Ausgabe von 2.6.7
sym0: using LOAD/STORE-based firmware.
sym0: SCAN AT BOOT disabled for targets 1 2 3 4 5 6.
sym0: SCAN FOR LUNS disabled for targets 0 1 2 3 4 5 6.
sym0: SCSI BUS has been reset.
scsi0 : sym-2.1.18j
Using anticipatory io scheduler
Vendor: IBM Model: DORS-32160 Rev: WA0A
Type: Direct-Access ANSI SCSI revision: 02
sym0:0:0: tagged command queuing enabled, command queue depth 16.
scsi(0:0:0:0): Beginning Domain Validation
sym0:0: FAST-10 SCSI 5.0 MB/s ST (200.0 ns, offset 15)
scsi(0:0:0:0): Domain Validation skipping write tests
scsi(0:0:0:0): Ending Domain Validation
SCSI device sda: 4226725 512-byte hdwr sectors (2164 MB)
SCSI device sda: drive cache: write back
/dev/scsi/host0/bus0/target0/lun0: p1 p2 p3
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
pivot_root: No such file or directory
/sbin/init: 424: Cannot open dev/console: No such file
Kernel panic: Attempted to kill init!
Die Unterschiede sind minimal ab im Deatil sind das:
1. Es gab wohl ein Treiber Upgrade von sym-2.1.18i nach sym-2.1.18j
2. Eine Domain Validation kam hinzu was immer das sein mag
scsi(0:0:0:0): Beginning Domain Validation
scsi(0:0:0:0): Domain Validation skipping write tests
scsi(0:0:0:0): Ending Domain Validation
3. Die Zeilen:
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
erscheinen zwei mal.
4. Er sucht aber findet nicht pivot_root. Wobei dieses Programm unter /sbin/pivot_root zu finden ist.
5. Er kann das console-Device nicht finden.
Was nun das Problem ist kann ich leider nicht sagen. Habe aber einige Vermutungen:
a) Es liegt ein Fehler an initrd.img-2.6.7-1-i386 vor
b) Der neue SCSI-Treiber funktioniert nicht so wie er soll. Eventuell muss was ausgeschaltet oder eingeschaltet werden. Nur weiß ich nicht was.
Für alle möglichen Vorschläge dankber
Reiner
ich hab da ein unschönes Problem. Ich wollte meine Kiste von linux 2.6.5 auf 2.6.7 upgraden. Leider klappt das nicht in beiden Fällen benutze ich die Standard-Pakete von debian sid.
Alter Kernel: kernel-image-2.6.5-1-i386
Neuer Kernel: kernel-image-2.6.7-1-i386
Also alles sehr konservativ. Im Prinzip müsste auch die i686 Varainte laufen.
Das Problem ist, dass init das Console-Device nicht findet.
Nun zum Setup:
1. Ich benutze Grub als Bootloader, weil lilo immer Zicken macht, da die IDE Drives zur Bootzeit nicht vorhanden sind, wohl aber wenn Linux beootet wurde. Außerdem hat Grub noch einige andere angenehme Features, die ich nicht missen möchte.
2. Die /boot/grub/menu.lst sieht so aus:
timeout=20
default=0
title 2.6.5
kernel /boot/vmlinuz-2.6.5-1-386
initrd /boot/initrd.img-2.6.5-1-386
title 2.6.7
kernel /boot/vmlinuz-2.6.7-1-386
initrd /boot/initrd.img-2.6.7-1-386
Alles sehr rudimentär aber mit dem 2.6.5 funktionierts.
3. Wenn Grub den Kernel lädt, wird auch korrekt das richtige initrd.img geladen zumindest zeigt er das so an.
4. Nun zu der Ausgabe des Kernels während des Hochfahrens.
4.1 Ausgabe des 2.6.5 Kernels
[...]
sym0: using LOAD/STORE-based firmware.
sym0: SCAN AT BOOT disabled for targets 1 2 3 4 5 6.
sym0: SCAN FOR LUNS disabled for targets 0 1 2 3 4 5 6.
sym0: SCSI BUS has been reset.
scsi0 : sym-2.1.18i
Using anticipatory io scheduler
Vendor: IBM Model: DORS-32160 Rev: WA0A
Type: Direct-Access ANSI SCSI revision: 02
sym0:0:0: tagged command queuing enabled, command queue depth 16.
sym0:0: FAST-10 SCSI 5.0 MB/s ST (200.0 ns, offset 15)
SCSI device sda: 4226725 512-byte hdwr sectors (2164 MB)
SCSI device sda: drive cache: write back
/dev/scsi/host0/bus0/target0/lun0: p1 p2 p3
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Adding 249832k swap on /dev/sda1. Priority:-1 extents:1
EXT3 FS on sda2, internal journal
4.2 Und nun die Ausgabe von 2.6.7
sym0: using LOAD/STORE-based firmware.
sym0: SCAN AT BOOT disabled for targets 1 2 3 4 5 6.
sym0: SCAN FOR LUNS disabled for targets 0 1 2 3 4 5 6.
sym0: SCSI BUS has been reset.
scsi0 : sym-2.1.18j
Using anticipatory io scheduler
Vendor: IBM Model: DORS-32160 Rev: WA0A
Type: Direct-Access ANSI SCSI revision: 02
sym0:0:0: tagged command queuing enabled, command queue depth 16.
scsi(0:0:0:0): Beginning Domain Validation
sym0:0: FAST-10 SCSI 5.0 MB/s ST (200.0 ns, offset 15)
scsi(0:0:0:0): Domain Validation skipping write tests
scsi(0:0:0:0): Ending Domain Validation
SCSI device sda: 4226725 512-byte hdwr sectors (2164 MB)
SCSI device sda: drive cache: write back
/dev/scsi/host0/bus0/target0/lun0: p1 p2 p3
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
pivot_root: No such file or directory
/sbin/init: 424: Cannot open dev/console: No such file
Kernel panic: Attempted to kill init!
Die Unterschiede sind minimal ab im Deatil sind das:
1. Es gab wohl ein Treiber Upgrade von sym-2.1.18i nach sym-2.1.18j
2. Eine Domain Validation kam hinzu was immer das sein mag
scsi(0:0:0:0): Beginning Domain Validation
scsi(0:0:0:0): Domain Validation skipping write tests
scsi(0:0:0:0): Ending Domain Validation
3. Die Zeilen:
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
erscheinen zwei mal.
4. Er sucht aber findet nicht pivot_root. Wobei dieses Programm unter /sbin/pivot_root zu finden ist.
5. Er kann das console-Device nicht finden.
Was nun das Problem ist kann ich leider nicht sagen. Habe aber einige Vermutungen:
a) Es liegt ein Fehler an initrd.img-2.6.7-1-i386 vor
b) Der neue SCSI-Treiber funktioniert nicht so wie er soll. Eventuell muss was ausgeschaltet oder eingeschaltet werden. Nur weiß ich nicht was.
Für alle möglichen Vorschläge dankber
Reiner
Also /dev/console gibt es. Hab auch nochmal nachgesehen aber wenn ich unter 2.6.5 bootet ist es da. Wundert auch nicht sonderlich, da es ja mit 2.6.5 prima klappt.
Ich denke eher, dass was mit dem initrd.img nicht in Ordnung ist. Weil er das pivot_root nicht findet. Welches dazu benutzt wird von initrd.img als Root-Verzeichnis auf das der Festplatte gewechselt wird. Komisch ist auch, dass er zwei mal "EXT3-fs: mountet filesystem ..." sagt. Wo er unter 2.6.5 dies nur einmal tut.
Ich were mal versuchen das initrd.img zu mounten und es mit dem anderen zu vergleichen.
Ich denke eher, dass was mit dem initrd.img nicht in Ordnung ist. Weil er das pivot_root nicht findet. Welches dazu benutzt wird von initrd.img als Root-Verzeichnis auf das der Festplatte gewechselt wird. Komisch ist auch, dass er zwei mal "EXT3-fs: mountet filesystem ..." sagt. Wo er unter 2.6.5 dies nur einmal tut.
Ich were mal versuchen das initrd.img zu mounten und es mit dem anderen zu vergleichen.
Hallo!
Mir ist heute etwas ganz ähnliches passiert.
Bei mir bootet der 2.6.7-1-386. Allerdings der 2.6.7-1-k7 und auch ein selbstgebackener laufen nicht.
Habe es dann mal mit nem 2.6.6er probiert. Gleiches Ergebnis, ungefähr. Der originale bootet, der neugebastelte wieder nicht.
Leider habe ich keine bootmeldungen da liegen
*total ahnungslos sei*
Mir ist heute etwas ganz ähnliches passiert.
Bei mir bootet der 2.6.7-1-386. Allerdings der 2.6.7-1-k7 und auch ein selbstgebackener laufen nicht.
Habe es dann mal mit nem 2.6.6er probiert. Gleiches Ergebnis, ungefähr. Der originale bootet, der neugebastelte wieder nicht.
Leider habe ich keine bootmeldungen da liegen
*total ahnungslos sei*
vielleicht lsg/workarround
Hi!
Nochmal ich.
Habe mir jetzt einmal den 2.6.8.1-k7 gezogen. Der ging *g*
Also wenn es nicht unbedingt der 2.6.7er sein muss (auch wenn der 2.6.8.1 wohl nicht so dolle ist, würde es so gehen *g*)
Aber eine Lösung bis auf die, dass die obrigen Module irgndwie nicht sind habe ich nicht gefunden.
Weiß jemand eine möglichkeit, wie man Kernelmodule direkt einer Kerneloption zuordnen kann?
Da fällt mir noch was ein: Also ich mir mal mit einem
make oldconfig
+ ändern des CPU-Typs von dem 386er eine Config erstellt habe, hat er bei mir auch nicht gebootet. keine Änderung des Bootverhaltens zum "originalen" K7er
Nochmal ich.
Habe mir jetzt einmal den 2.6.8.1-k7 gezogen. Der ging *g*
Also wenn es nicht unbedingt der 2.6.7er sein muss (auch wenn der 2.6.8.1 wohl nicht so dolle ist, würde es so gehen *g*)
Aber eine Lösung bis auf die, dass die obrigen Module irgndwie nicht sind habe ich nicht gefunden.
Weiß jemand eine möglichkeit, wie man Kernelmodule direkt einer Kerneloption zuordnen kann?
Da fällt mir noch was ein: Also ich mir mal mit einem
make oldconfig
+ ändern des CPU-Typs von dem 386er eine Config erstellt habe, hat er bei mir auch nicht gebootet. keine Änderung des Bootverhaltens zum "originalen" K7er
-
- Beiträge: 17
- Registriert: 07.10.2004 09:25:31
-
- Beiträge: 17
- Registriert: 07.10.2004 09:25:31