# Neuer Kernel (2.6.18 / 2.6.19) - Probleme

**URL:** <https://discourse.suseforum.de/t/neuer-kernel-2-6-18-2-6-19-probleme/1512>\
**Category:** Ubuntu / Kubuntu (Archiv - read only)\
**Tags:** kubuntu-installation\
**Created:** [5. November 2006 um 15:24 UTC](https://discourse.suseforum.de/t/neuer-kernel-2-6-18-2-6-19-probleme/1512 "2006-11-05T15:24:32Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![gucky](https://discourse.suseforum.de/letter_avatar_proxy/v4/letter/g/d07c76/32.png) [@gucky](https://discourse.suseforum.de/u/gucky)\
**Post date:** [5. November 2006 um 15:24 UTC](https://discourse.suseforum.de/t/neuer-kernel-2-6-18-2-6-19-probleme/1512/1 "2006-11-05T15:24:32Z")

</div>

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.

```auto
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](http://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?

```auto
# /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)  
[http://www.soffie.de/ubunto-panic.gif](http://www.soffie.de/ubunto-panic.gif)

Tja, was mag sein?

Vielen Dank!

---

<div class="post-metadata">

**Author:** ![b3ll3roph0n](https://discourse.suseforum.de/letter_avatar_proxy/v4/letter/b/b9e5f3/32.png) [@b3ll3roph0n](https://discourse.suseforum.de/u/b3ll3roph0n)\
**Post date:** [6. November 2006 um 05:23 UTC](https://discourse.suseforum.de/t/neuer-kernel-2-6-18-2-6-19-probleme/1512/2 "2006-11-06T05:23:05Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![gucky](https://discourse.suseforum.de/letter_avatar_proxy/v4/letter/g/d07c76/32.png) [@gucky](https://discourse.suseforum.de/u/gucky)\
**Post date:** [6. November 2006 um 14:40 UTC](https://discourse.suseforum.de/t/neuer-kernel-2-6-18-2-6-19-probleme/1512/3 "2006-11-06T14:40:35Z")

</div>

AW: Neuer Kernel (2.6.18 / 2.6.19) - Probleme

> [@b3ll3roph0n](#):
>
> 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?

> [@b3ll3roph0n](#):
>
> 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.

> [@b3ll3roph0n](#):
>
> 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.

> [@b3ll3roph0n](#):
>
> 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.

---

<div class="post-metadata">

**Author:** ![b3ll3roph0n](https://discourse.suseforum.de/letter_avatar_proxy/v4/letter/b/b9e5f3/32.png) [@b3ll3roph0n](https://discourse.suseforum.de/u/b3ll3roph0n)\
**Post date:** [6. November 2006 um 15:24 UTC](https://discourse.suseforum.de/t/neuer-kernel-2-6-18-2-6-19-probleme/1512/4 "2006-11-06T15:24:31Z")

</div>

AW: Neuer Kernel (2.6.18 / 2.6.19) - Probleme

> [@gucky](#):
>
> 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

> [@gucky](#):
>
> 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.

> [@gucky](#):
>
> 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.

> [@b3ll3roph0n](#):
>
> Bei einer LVM-Swap-Partition kann es sein, dass die Daten über unterschiedliche Bereiche der Festplatte verteilt sind, was den Zugriff verlangsamt.