Neuer Kernel (2.6.18 / 2.6.19) - Probleme

[gucky]

Hi!

Eigentlich eine einfache Aufgabe - einen kleinen Server für zu Hause aufsetzen. Kein Problem - AMD Prozessor, NForce4 Mainboard, 1*IDE für das System, 2*SATA für dei Daten. Damit begann die Odyssee - der Rechner ist nie länger als zwei Tage durchgelaufen (egal ob Debian pur, Knoppix oder Ubuntu).

Nun mit dem neuesten Ubuntu und dem 2.6.17-10-server Kernel und der Option "noapic" scheint mein Rechner endlich stabil zu laufen.

Ein 80GB rsync Job gestern hat aber dann eine SATA Platte zum stehen gebracht. 100% busy aber sie hat nichts mehr gemacht.

Nov  4 20:14:05 xx kernel: [43113787.420000] ata1: command 0x35 timeout, stat 0xd0 host_stat 0x21
Nov  4 20:14:05 xx kernel: [43113787.420000] ata1: translated ATA stat/err 0xd0/00 to SCSI SK/ASC/ASCQ 0xb/47/00
Nov  4 20:14:05 xx kernel: [43113787.420000] ata1: status=0xd0 { Busy }
Nov  4 20:14:05 xx kernel: [43113787.420000] sd 0:0:0:0: SCSI error: return code = 0x8000002
Nov  4 20:14:05 xx kernel: [43113787.420000] sda: Current: sense key: Aborted Command
Nov  4 20:14:05 xx kernel: [43113787.420000]     Additional sense: Scsi parity error
Nov  4 20:14:35 xx kernel: [43113817.420000] ata1: command 0x35 timeout, stat 0xd0 host_stat 0x21
Nov  4 20:14:35 xx kernel: [43113817.420000] ata1: status=0x50 { DriveReady SeekComplete }
Nov  4 20:14:35 xx kernel: [43113817.420000] sda: Current: sense key: No Sense
Nov  4 20:14:35 xx kernel: [43113817.420000]     Additional sense: No additional sense information

Eine kleine Recherche im Internet hat ergeben, dass das an ATA Treibern liegen soll und ein neuer 2.6.18-mm oder 2.6.19 Kernel abhilfe bringen soll.

Nun, das versuche ich nun. 2.6.18.2 sowie 2.6.19-rc4 hab ich mir von www.kernel.org geholt und compiliert.

Leider klappt der Boot aber doch nicht. Er meint er könne die Datei /lib/modules/2.6.19-rc4/modules.dep nicht finden. (Obwohl die dort ganz sicher liegt )

Bin ich zu innovativ, was die Filesysteme angeht?

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/mapper/Ubuntu-root /               ext3    defaults,errors=remount-ro 0       1
# /dev/hda5 -- converted during upgrade to edgy
UUID=0ff8543e-694c-425d-ab4d-f15146f70840 /boot ext3 defaults 0 2
/dev/mapper/Ubuntu-home /home           xfs     defaults        0       2
/dev/mapper/Ubuntu-opt /opt            xfs     defaults        0       2
/dev/mapper/Ubuntu-tmp /tmp            xfs     defaults        0       2
/dev/mapper/Ubuntu-usr /usr            xfs     defaults        0       2
/dev/mapper/Ubuntu-var /var            xfs     defaults        0       2
/dev/mapper/Ubuntu-varwww /var/www        xfs     defaults        0       2
/dev/mapper/Ubuntu-swap_1 none            swap    sw              0       0
/dev/hdc        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/mapper/VGsda-sda1 /sda1            xfs     defaults        0       3
/dev/mapper/VGsdb-sdb1 /sdb1            xfs     defaults        0       3

Beim Boot passiert dann folgendes: (Screenshot)

Tja, was mag sein?

Vielen Dank!

 

[b3ll3roph0n]

AW: Neuer Kernel (2.6.18 / 2.6.19) - Probleme

Wie hast du den Kernel gebaut?
Module für LVM (dm-mod) in der Config aktiviert? - Als Modul oder fest in den Kernel integriert.
Neue initrd erstellt?

Btw:
Ziemlich wilde Partitionierung!
(Sieht nach einchfach aus dem WIKI abgeschrieben aus)
Ich empfehle nicht unbedingt die root-Partition in ein LVM zu legen (hat imho keinerlei Vorteile).
Zumindest swap gehört definitiv nicht in ein LVM.
Bei einer normalen Swap-Partition liegen alle Daten nahe nebeneinander auf der Festplatte. Bei einer LVM-Swap-Partition kann es sein, dass die Daten über unterschiedliche Bereiche der Festplatte verteilt sind, was den Zugriff verlangsamt.
Außerdem werden sowohl root als auch swap sehr früh im Bootprozess aktiviert, so dass die Notwendigen Module mit der initrd geladen werden müssen.

 

[gucky]

AW: Neuer Kernel (2.6.18 / 2.6.19) - Probleme

Wie hast du den Kernel gebaut?
Module für LVM (dm-mod) in der Config aktiviert? - Als Modul oder fest in den Kernel integriert.
Neue initrd erstellt?

Das mit dem Module muss ich nochmal prüfen. Die initrd hab ich erstellt. Muss ich beim Aufruf von mkinitrd vielleicht noch was bzgl. LVM oder XFS mit übergeben?

Btw:
Ziemlich wilde Partitionierung!
(Sieht nach einchfach aus dem WIKI abgeschrieben aus)

Jo, in Teilen. Muss deswegen aber doch nicht schlecht sein..? So unsinnig finde ich sie auch nicht.

Ich empfehle nicht unbedingt die root-Partition in ein LVM zu legen (hat imho keinerlei Vorteile).
Zumindest swap gehört definitiv nicht in ein LVM.
Bei einer normalen Swap-Partition liegen alle Daten nahe nebeneinander auf der Festplatte. Bei einer LVM-Swap-Partition kann es sein, dass die Daten über unterschiedliche Bereiche der Festplatte verteilt sind, was den Zugriff verlangsamt.

Naja, wenn ich den Swap erweiteren müsste, dann würde ich entweder eine zusätzliche Swap Partition einhängen - oder eben die Swap Partition erweitern. Sollte beides (so die Disk per LVM nicht total fragmentiert ist) auf das selbe herauskommen. (Swap über zwei Bereiche der Platte verteilt.) Ist in meinem Fall aber nicht so relevant, da der Swap jetzt eh schon eher überdimensioniert ist.

Außerdem werden sowohl root als auch swap sehr früh im Bootprozess aktiviert, so dass die Notwendigen Module mit der initrd geladen werden müssen.

Jo, das mag jetzt vielleicht tatsächlich das Problem sein.
Aber das wird sich ja hoffentlich lösen lassen.

Bzw. es lässt sich natürlich lösen - mein Standard Ubuntu Kernel bootet ja mit den selben Partitionen auch. Ich hab das nur leider mit meinen selbst gebastelten Kerneln noch nicht richtig nachbilden können.

Dennoch Danke,
Gucky.

 

[b3ll3roph0n]

AW: Neuer Kernel (2.6.18 / 2.6.19) - Probleme

Das mit dem Module muss ich nochmal prüfen. Die initrd hab ich erstellt. Muss ich beim Aufruf von mkinitrd vielleicht noch was bzgl. LVM oder XFS mit übergeben?

Äh, ja.
Du musst die Module xfs und dm-mod aus der initrd starten.
=> /etc/mkinitramfs/modules

Jo, in Teilen. Muss deswegen aber doch nicht schlecht sein..? So unsinnig finde ich sie auch nicht.

Hast du Daten in deinem /opt-Verzeichniss?
Da Ubuntu ein Debian-Derivat ist, wird dieses Verzeichnis (im Gegensatzt zu SuSE oder Arch) nicht verwendet.
xfs für /tmp ? - Überflüssig. ext2 tut es auch. Ist schneller und /tmp braucht kein Journaling.
Gleiches gilt für /boot. Das Journal belegt da außerdem zu viel Platz.

Naja, wenn ich den Swap erweiteren müsste, dann würde ich entweder eine zusätzliche Swap Partition einhängen - oder eben die Swap Partition erweitern. Sollte beides (so die Disk per LVM nicht total fragmentiert ist) auf das selbe herauskommen. (Swap über zwei Bereiche der Platte verteilt.) Ist in meinem Fall aber nicht so relevant, da der Swap jetzt eh schon eher überdimensioniert ist.

Bei einer LVM-Swap-Partition kann es sein, dass die Daten über unterschiedliche Bereiche der Festplatte verteilt sind, was den Zugriff verlangsamt.