« Posts tagged Linux

Neuer Dockstar Kernel für Debian (2.6.32.56)

Mal wieder mein aktualisierter Dockstar Standardkernel 2.6.32.56 mit der Konfiguration und dem Patch von Jeff.

Kurze Installationsanleitung:
1.) Headers und Kernel installieren:

sudo dpkg -i linux-headers-2.6.32.56-dockstar-eigenbau_1.0_armel.deb linux-image-2.6.32.56-dockstar-eigenbau_1.0_armel.deb

2.) Initiale Ramdisk und Kernelimage für Uboot erzeugen:

sudo /usr/bin/mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-2.6.32-56 -d /boot/vmlinuz-2.6.32.56-dockstar-eigenbau /boot/uImage
sudo /usr/bin/mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs -d /boot/initrd.img-2.6.32.56-dockstar-eigenbau /boot/uInitrd

3.) Neustart

4.) Kernelmodule neu einlesen:

sudo depmod -a

5.) Neustart

6.) (Optional) Alten Kernel deinstallieren

sudo apt-get purge linux-image-2.6.32.55-dockstar-eigenbau linux-headers-2.6.32.55-dockstar-eigenbau
sudo rm -r /lib/modules/2.6.32.55-dockstar-eigenbau/

MD5:
ecff5a6ed707742e1cacf4380a0ff671 config-2.6.32.56-dockstar-eigenbau
ca13626f7d91cd57c8ba2d598360a3b2 linux-headers-2.6.32.56-dockstar-eigenbau_1.0_armel.deb
d423493001bb54995e2a64af1ad39e33 linux-image-2.6.32.56-dockstar-eigenbau_1.0_armel.deb

Hoffe dass der Kernel irgendwem nützt, ich nutze meine Eigenbaukernel seit Monaten ohne Probleme. Falls eure Dockstar brennt, kaputt geht, in die Luft fliegt oder sonstiges, übernehme ich keine Verantwortung dafür.

Alles weiteren Infos im alten Post zu Kernel 2.6.32.50.

Danke an Jeff für seine Konfig und seine fantastische Arbeit mit der Dockstar. Besucht sein Forum, es ist die beste Anlaufstelle für Dockstarnutzer.

Kurze Info: In ca. einem Monat läuft übrigens der Support für die 2.6.32er Reihe aus, ich denke ich werde dann zur 3.0 Reihe wechseln, die dann wohl die neue Longterm Support Reihe werden soll…

Update: Es gibt bereits einen neueren longterm Kernel! Den neusten longterm Dockstar Kernel findet ihr immer hier. Die alten Links habe ich entfernt.

Neuer Dockstar Kernel für Debian (2.6.32.55)

Mal wieder mein aktualisierter Dockstar Standardkernel 2.6.32.55 mit der Konfiguration und dem Patch von Jeff.

Kurze Installationsanleitung:
1.) Headers und Kernel installieren:

sudo dpkg -i linux-headers-2.6.32.55-dockstar-eigenbau_1.0_armel.deb linux-image-2.6.32.55-dockstar-eigenbau_1.0_armel.deb

2.) Initiale Ramdisk und Kernelimage für Uboot erzeugen:

sudo /usr/bin/mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-2.6.32-55 -d /boot/vmlinuz-2.6.32.55-dockstar-eigenbau /boot/uImage
sudo /usr/bin/mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs -d /boot/initrd.img-2.6.32.55-dockstar-eigenbau /boot/uInitrd

3.) Neustart

4.) Kernelmodule neu einlesen:

sudo depmod -a

5.) Neustart

6.) (Optional) Alten Kernel deinstallieren

sudo apt-get purge linux-image-2.6.32.54-dockstar-eigenbau linux-headers-2.6.32.54-dockstar-eigenbau
sudo rm -r /lib/modules/2.6.32.54-dockstar-eigenbau/

MD5:
3ffddc6f63008d7d1814844733ef5f88 config-2.6.32.55-dockstar-eigenbau
3fed202d560035aaee648ef2e0ae9187 linux-headers-2.6.32.55-dockstar-eigenbau_1.0_armel.deb
65eca9b52298f365107a0ee61a7d6246 linux-image-2.6.32.55-dockstar-eigenbau_1.0_armel.deb

Hoffe dass der Kernel irgendwem nützt, ich nutze meine Eigenbaukernel seit Monaten ohne Probleme. Falls eure Dockstar brennt, kaputt geht, in die Luft fliegt oder sonstiges, übernehme ich keine Verantwortung dafür.

Alles weiteren Infos im alten Post zu Kernel 2.6.32.50.

Danke an Jeff für seine Konfig und seine fantastische Arbeit mit der Dockstar. Besucht sein Forum, es ist die beste Anlaufstelle für Dockstarnutzer.

Kurze Info: In ca. einem Monat läuft übrigens der Support für die 2.6.32er Reihe aus, ich denke ich werde dann zur 3.0 Reihe wechseln, die dann wohl die neue Longterm Support Reihe werden soll…

Update: Es gibt bereits einen neueren longterm Kernel! Den neusten longterm Dockstar Kernel findet ihr immer hier. Die alten Links habe ich entfernt.

USB Wakeup bei Kernel 3.2 aktivieren

Seit dem Update auf Kernel 3.2.1 muss ich, damit der USB Wakeup funktioniert, zusätzlich noch Wakeup am USB Root HUB, an dem meine Fernbedienung hängt, freischalten. Weiß auch nicht warum es diese Änderung gab, und ob es explizit am Kernel liegt, vermute dies aber mal, weil es seitdem nicht mehr geht.

Insgesamt muss ich also um meine X10 Fernbedienung für einen USB Wakeup zu nutzen folgendes machen:

status=`cat /proc/acpi/wakeup | grep "USB0" | awk {'print $3}'`
if [ "$status" = "disabled" -o "$status" = "*disabled" ]; then
   echo "USB0" > /proc/acpi/wakeup
fi
echo enabled > /sys/bus/usb/devices/2-1/power/wakeup
echo enabled > /sys/bus/usb/devices/usb2/power/wakeup

Dachte ich schreib das mal, hab auch eine Weile gesucht bis ich das herausgefunden hab. Wenn ihr diese Optionen beim suspend automatisch setzt (oder manuell von Hand), solltet ihr euren PC aus dem Standby/Suspend mit der Power oder Mutetaste auf eurer X10 wecken können. Mal sehen was beim nächsten Update an Änderungen kommen…

Neuer Dockstar Kernel für Debian (2.6.32.54)

Mal wieder mein aktualisierter Dockstar Standardkernel 2.6.32.54 mit der Konfiguration und dem Patch von Jeff.

Kurze Installationsanleitung:
1.) Headers und Kernel installieren:

sudo dpkg -i linux-headers-2.6.32.54-dockstar-eigenbau_1.0_armel.deb linux-image-2.6.32.54-dockstar-eigenbau_1.0_armel.deb

2.) Initiale Ramdisk und Kernelimage für Uboot erzeugen:

sudo /usr/bin/mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-2.6.32-54 -d /boot/vmlinuz-2.6.32.54-dockstar-eigenbau /boot/uImage
sudo /usr/bin/mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs -d /boot/initrd.img-2.6.32.54-dockstar-eigenbau /boot/uInitrd

3.) Neustart
4.) Kernelmodule neu einlesen:

sudo depmod -a

5.) Neustart
6.) (Optional) Alten Kernel deinstallieren (sudo apt-get purge linux-image…)

Jetzt übrigens ohne Warnungen beim Installieren … :D

MD5:

d4c9173391f58d50dac750d79d010740  config-2.6.32.54-dockstar-eigenbau
6c4e9a51da895162ca870927f83250ed  linux-headers-2.6.32.54-dockstar-eigenbau_1.0_armel.deb
fe4c52300e4746ac642bfeffc9094b72  linux-image-2.6.32.54-dockstar-eigenbau_1.0_armel.deb

Hoffe dass der Kernel irgendwem nützt, ich nutze meine Eigenbaukernel seit Monaten ohne Probleme. Falls eure Dockstar brennt, kaputt geht, in die Luft fliegt oder sonstiges, übernehme ich keine Verantwortung dafür.

Alles weiteren Infos im alten Post zu Kernel 2.6.32.50.

Danke an Jeff für seine Konfig und seine fantastische Arbeit mit der Dockstar. Besucht sein Forum, es ist die beste Anlaufstelle für Dockstarnutzer.

Kurze Info: In ca. einem Monat läuft übrigens der Support für die 2.6.32er Reihe aus, ich denke ich werde dann zur 3.0 Reihe wechseln, die dann wohl die neue Longterm Support Reihe werden soll…

Update: Es gibt bereits einen neueren longterm Kernel! Den neusten longterm Dockstar Kernel findet ihr immer hier. Die alten Links habe ich entfernt.

Neuer Dockstar Kernel für Debian (2.6.32.53)

Mal wieder mein aktualisierter Dockstar Standardkernel 2.6.32.53 mit der Konfiguration und dem Patch von Jeff.

Kurze Installationsanleitung:
1.) Headers und Kernel installieren:

sudo dpkg -i linux-headers-2.6.32.53-dockstar-eigenbau_1.0_armel.deb linux-image-2.6.32.53-dockstar-eigenbau_1.0_armel.deb

3.) Initiale Ramdisk und Kernelimage für Uboot erzeugen:

sudo /usr/bin/mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-2.6.32-53 -d /boot/vmlinuz-2.6.32.53-dockstar-eigenbau /boot/uImage
sudo /usr/bin/mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs -d /boot/initrd.img-2.6.32.53-dockstar-eigenbau /boot/uInitrd

4.) Neustart
5.) Kernelmodule neu einlesen:

sudo depmod -a

7.) Neustart
8.) (Optional) Alten Kernel deinstallieren (sudo apt-get purge linux-image…)

Beim Installieren der Header kommt eine Warnung, dass man zu erst die Header installieren soll … einfach ignorieren. Keine Ahnung warum das so ist, es ist jedenfalls kein Fehler.

MD5:

cae07fb120dfe447b1907bf6219a8c91  config-2.6.32.53-dockstar-eigenbau
ea8bf7f4ca3f32f0f062ad8e01812464  linux-headers-2.6.32.53-dockstar-eigenbau_1.0_armel.deb
09fa854e741c398c726b6a48ef2c11be  linux-image-2.6.32.53-dockstar-eigenbau_1.0_armel.deb

Hoffe dass der Kernel irgendwem nützt, ich nutze meine Eigenbaukernel seit Monaten ohne Probleme. Falls eure Dockstar brennt, kaputt geht, in die Luft fliegt oder sonstiges, übernehme ich keine Verantwortung dafür.

Alles weiteren Infos im alten Post zu Kernel 2.6.32.50.

Danke an Jeff für seine Konfig und seine fantastische Arbeit mit der Dockstar. Besucht sein Forum, es ist die beste Anlaufstelle für Dockstarnutzer.

Update: Es gibt bereits einen neueren longterm Kernel! Den neusten longterm Dockstar Kernel findet ihr immer hier. Die alten Links habe ich entfernt.

Neuer Dockstar Kernel für Debian (2.6.32.52)

Das geht ja echt ratzfatz … hier wieder mein aktualisierter Dockstar Standardkernel 2.6.32.52 mit der Konfiguration und dem Patch von Jeff.

Kurze Installationsanleitung:
1.) Headers und Kernel installieren:

sudo dpkg -i linux-headers-2.6.32.52-dockstar-eigenbau_1.0_armel.deb linux-image-2.6.32.52-dockstar-eigenbau_1.0_armel.deb

3.) Initiale Ramdisk und Kernelimage für Uboot erzeugen:

sudo /usr/bin/mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-2.6.32-52 -d /boot/vmlinuz-2.6.32.52-dockstar-eigenbau /boot/uImage
sudo /usr/bin/mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs -d /boot/initrd.img-2.6.32.52-dockstar-eigenbau /boot/uInitrd

4.) Neustart
5.) Kernelmodule neu einlesen:

sudo depmod -a

7.) Neustart
8.) (Optional) Alten Kernel deinstallieren (sudo apt-get purge linux-image…)

Beim Installieren der Header kommt eine Warnung, dass man zu erst die Header installieren soll … einfach ignorieren. Keine Ahnung warum das so ist, es ist jedenfalls kein Fehler.

MD5:

1dc91f2989bbc4836b5bec6e9ea514b0  config-2.6.32.52-dockstar-eigenbau
e515e10896a5e6cf2f3fb5200e403bd5  linux-headers-2.6.32.52-dockstar-eigenbau_1.0_armel.deb
664a9d6b2e793d878d2072b674440723  linux-image-2.6.32.52-dockstar-eigenbau_1.0_armel.deb

Hoffe dass der Kernel irgendwem nützt, ich nutze meine Eigenbaukernel seit Monaten ohne Probleme. Falls eure Dockstar brennt, kaputt geht, in die Luft fliegt oder sonstiges, übernehme ich keine Verantwortung dafür.

Alles weiteren Infos im alten Post zu Kernel 2.6.32.50.

Danke an Jeff für seine Konfig und seine fantastische Arbeit mit der Dockstar. Besucht sein Forum, es ist die beste Anlaufstelle für Dockstarnutzer.

Update: Es gibt bereits einen neueren longterm Kernel! Den neusten longterm Dockstar Kernel findet ihr immer hier. Die alten Links habe ich entfernt.

Neuer Dockstar Kernel für Debian (2.6.32.51)

Hier mal wieder mein aktualisierter Dockstar Standardkernel 2.6.32.51 mit der Konfiguration und dem Patch von Jeff.

Kurze Installationsanleitung:
1.) Headers und Kernel installieren:

sudo dpkg -i linux-headers-2.6.32.51-dockstar-eigenbau_1.0_armel.deb linux-image-2.6.32.51-dockstar-eigenbau_1.0_armel.deb

3.) Initiale Ramdisk und Kernelimage für Uboot erzeugen:

sudo /usr/bin/mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-2.6.32-51 -d /boot/vmlinuz-2.6.32.51-dockstar-eigenbau /boot/uImage
sudo /usr/bin/mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs -d /boot/initrd.img-2.6.32.51-dockstar-eigenbau /boot/uInitrd

4.) Neustart
5.) Kernelmodule neu einlesen:

sudo depmod -a

7.) Neustart
8.) (Optional) Alten Kernel deinstallieren (sudo apt-get purge linux-image…)

Beim Installieren der Header kommt eine Warnung, dass man zu erst die Header installieren soll … einfach ignorieren. Keine Ahnung warum das so ist, es ist jedenfalls kein Fehler.

Hoffe dass der Kernel irgendwem nützt, ich nutze meine Eigenbaukernel seit Monaten ohne Probleme. Falls eure Dockstar brennt, kaputt geht, in die Luft fliegt oder sonstiges, übernehme ich keine Verantwortung dafür.

Alles weiteren Infos im alten Post zu Kernel 2.6.32.50.

Danke an Jeff für seine Konfig und seine fantastische Arbeit mit der Dockstar. Besucht sein Forum, es ist die beste Anlaufstelle für Dockstarnutzer.

Update: Es gibt bereits einen neueren longterm Kernel! Den neusten longterm Dockstar Kernel findet ihr immer hier. Die alten Links habe ich entfernt.

Neuer Dockstar Kernel für Debian (2.6.32.50)

Ich dachte ich stelle euch heute mal meinen gestern gebauten Dockstar Kernel zur Verfügung, da man doch kaum “gescheite” Kernel findet im Netz oder wenn man einen findet, fehlern die Headers dazu.

Da ich bis vor einigen Monaten den Kernel von Jeff genutzt habe, habe ich für meine eigenen Kernel einfach die Konfig von ihm übernommen. Ebenfalls bin ich auf dem -noch gepflegten- 2.6.32er Zweig geblieben, welcher für die Dockstar absolut ausreichend ist. Da ich die Header mitliefere, kann man eigene Treiber recht einfach nachbauen, falls sie fehlen.

Es ist einfach ein aktualisierter 2.6.32 Standardkernel, mit dem Dockstar Patch von Jeff (für die LED) gepatcht und mit der Konfig von Jeff kompiliert. Wenn ihr also noch den Kernel von Jeff nutzt, könnt ihr gefahrlos “upgraden”.

Kurze Installationsanleitung:
1.) Headers installieren:

sudo dpkg -i linux-headers-2.6.32.50-dockstar-eigenbau_1.0_armel.deb

2.) Kernel installieren:

sudo dpkg -i linux-image-2.6.32.50-dockstar-eigenbau_1.0_armel.deb

3.) Initiale Ramdisk und Kernelimage für Uboot erzeugen:

sudo /usr/bin/mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-2.6.32-50 -d /boot/vmlinuz-2.6.32.50-dockstar-eigenbau /boot/uImage
sudo /usr/bin/mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs -d /boot/initrd.img-2.6.32.50-dockstar-eigenbau /boot/uInitrd

4.) Neustart
5.) Kernelmodule neu einlesen:

sudo depmod -a

7.) Neustart
8.) (Optional) Alten Kernel deinstallieren (sudo apt-get purge linux-image…)

Beim Installieren der Header kommt eine Warnung, dass man zu erst die Header installieren soll … einfach ignorieren. Keine Ahnung warum das so ist, es ist jedenfalls kein Fehler.

Hoffe dass der Kernel irgendwem nützt, ich nutze meine Eigenbaukernel seit Monaten ohne Probleme. Falls eure Dockstar brennt, kaputt geht, in die Luft fliegt oder sonstiges, übernehme ich keine Verantwortung dafür.

Danke an Jeff für seine Konfig und seine fantastische Arbeit mit der Dockstar. Besucht sein Forum, es ist die beste Anlaufstelle für Dockstarnutzer.

Update: Es gibt bereits einen neueren longterm Kernel! Den neusten longterm Dockstar Kernel findet ihr immer hier. Die alten Links habe ich entfernt.

Verschlüsseltes Home Verzeichnis in Arch Linux mit eCryptFS [UPDATE]

Matrix eCryptFS

Ich arbeite schon länger daran, das ganze in Verbindung mit PAM-Mount hinzubekommen, allerdings scheint es, als ob
die Anleitung  im ArchWiki nicht mehr funktioniert bzw. essentielle Schritte fehlen. Ich habs wirklich Stunden versucht – ohne Erfolg.
Daraufhin fand ich aber einen wesentlich einfacheren Weg, das ganze hinzubekommen, den ich kurz erklären möchte.

Zu aller erst, zur Vorbereitung wäre es ratsam, folgende zwei Artikel zu lesen:

System Encryption with eCryptfs im Archwiki und eCryptfs and $HOME von anrxc (Thx man!)

Das klappt möglicherweise auch auf anderes Distributionen genauso, es ist immerhin exakt der Weg, den Ubuntu für eCryptFS nimmt ;)

Also, fangen wir an:

1.) Installiere keyutils, and ecryptfs-utils and pam_mount from AUR

yaourt -S keyutils ecryptfs-utils pam_mount

[Alle folgenden Schritte als root!]

2.) Erzeuge eine Gruppe namens ecryptfs

groupadd ecryptfs

3.) Füge den User, dessen $HOME verschlüsselt werden soll, der oben erstellten Gruppe hinzu

usermod -aG ecryptfs user

4.) Lade das eCryptFS Modul

modprobe ecryptfs

5.) Editiere /etc/pam.d/login, so dass es wie folgt aussieht:

#%PAM-1.0
auth            required        pam_securetty.so
auth            requisite       pam_nologin.so
auth            required        pam_unix.so nullok
auth            optional        pam_ecryptfs.so unwrap
auth            required        pam_tally.so onerr=succeed file=/var/log/faillog
# use this to lockout accounts for 10 minutes after 3 failed attempts
#auth           required        pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog
account         required        pam_access.so
account         required        pam_time.so
account         required        pam_unix.so
#password       required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
password        optional        pam_ecryptfs.so
#password       required        pam_unix.so md5 shadow use_authtok
session         required        pam_unix.so
session         optional        pam_ecryptfs.so unwrap
session         required        pam_env.so
session         required        pam_motd.so
session         required        pam_limits.so
session         optional        pam_mail.so dir=/var/spool/mail standard
session         optional        pam_lastlog.so

6.) Für Gnome < 3.2 (gdm < 3.2) Anschließend auch /etc/pam.d/gdm: (sofern du gdm benutzt .. ansonsten selber rausfinden ;) )

#%PAM-1.0
auth            requisite       pam_nologin.so
auth            required        pam_env.so
auth            required        pam_unix.so
auth            optional        pam_ecryptfs.so unwrap
auth            optional        pam_gnome_keyring.so
account         required        pam_unix.so
session         required        pam_limits.so
session         required        pam_unix.so
session         optional        pam_ecryptfs.so unwrap
session         optional        pam_gnome_keyring.so auto_start
password        required        pam_unix.so
password        optional        pam_ecryptfs.so

Für Gnome >= 3.2 (gdm >= 3.2) muss man stattdessen /etc/pam.d/gdm-password editieren:

#%PAM-1.0
auth            requisite       pam_nologin.so
auth            required        pam_env.so
auth            requisite       pam_unix.so nullok
auth		optional	pam_ecryptfs.so unwrap
auth            optional        pam_gnome_keyring.so
auth            sufficient      pam_succeed_if.so uid >= 1000 quiet
auth            required        pam_deny.so
account         required        pam_unix.so
password        required        pam_unix.so
password        optional        pam_ecryptfs.so
session         required        pam_loginuid.so
-session        optional        pam_systemd.so
session         optional        pam_keyinit.so force revoke
session         required        pam_limits.so
session         required        pam_unix.so
session         optional        pam_ecryptfs.so unwrap
session         optional        pam_gnome_keyring.so auto_start

7.) Führe folgenden Befehl aus: (Es kann lange dauern, da er das gesamte $HOME verschlüsselt. Folge den Bildschirmanweisungen!)

ecryptfs-migrate-home -u user

Beachte abschließend unbedingt die Bildschirmanweisungen und führe sie nach Schritt 8.) aus! (Lösche das unverschlüsselte Backup danach (/home/user.XXXXX) / Notier dir die Passphrase, welche von ecryptfs generiert wurde mit Hilfe von ecryptfs-unwrap-passphrase / …)

8.) Log dich ein, und prüfe ob alles in Ordnung war.

Diese Vorgehensweise ist recht einfach und führt schnell ans Ziel und wird genau so von Ubuntu (10.04/10.10) benutzt. Ausserdem hat es nun den Vorteil, dass man User mit verschlüsseltem $HOME und ohne verschlüsseltes $HOME haben kann und dass $HOME automatisch nach logout “geschlossen” wird, was anrxc’s Lösung nicht macht.

Man kann außerdem auch den Swap-Space mit einem eCryptFS Tool verschlüsseln, einfach mal ecryptfs-setup-swap probieren ;)

Ich hoffe das hilft jemand, ich hab das auch ins Archwiki eingestellt.

Weiterhin 1000 mal Danke an jomen für die Vorstellung dieser super Lösung im Arch-Forum!

Edit am 02.10.2011: Gnome 3.2/gdm 3.2 hat probleme mit der bisherigen Methode, das funktioniert irgendwie nicht.
Dank

Zotac 9300-ITX (ION) läuft nicht unter Ubuntu 11.04 und von HDMI Audio wollen wir gar nicht erst anfangen… [UPDATE 27.09.2011]

Hi,

überall im Netz findet man Berichte darüber, das die Zotac ION/9300 Board Probleme haben, unter Linux mit den neueren Nvidia Treibern zu funktionieren, das Nvidia Kernel Modul stürzt wie von mir bereits hier berichtet, ab.

Damals hab ich unter Mythbuntu 10.10 (Ubuntu mit MythTV und XFCE) das x-swat PPA angehabt um immer die neusten Nvidia Treiber zu haben, wegen Performance usw. Es gibt zwar auch den “freien” Treiber nouveau, aber damit gibts keine 3D-Beschleunigung geschweige denn von VDAPU (und deswegen haben wir ja IONs in unseren HTPCs ;) ). Ausserdem tut wohl HDMI Audio damit gar nicht.

Nun hab ich damals ja einen Bugreport geschrieben, das PPA entfernt, und hatte (nach etwas Gebastel) wieder 260.19.06 drauf und alles war gut. Nachdem 11.04 nun seit einiger Zeit raus ist, wagte ich auch das 11.04 Update, weil ich damals noch dachte das 270.x Problem entstand wegen Inkompatibilitäten zwischen dem XServer und dem Nvidia Treiber.

Nun hat sich Nvidia wohl nicht drum gekümmert und unter 11.04 existiert selbst mit den neusten 270.41.19 Treibern (und wohl auch mit den Beta 275.x Treibern) das Problem. Einzige Lösung: Nouveau oder nvidia-173. Ersteres ergibt: Keine 3D Beschleunigung, Kein VDAPU, Kein HDMI-Audio. Zweiteres ergibt:  Kein VDAPU, kein HDMI-Audio.  Ich hab unter 11.04 (obwohl hdmi-audio erkannt wird mit aplay -l) den HDMI Audioausgang nicht zum ertönen gebracht, obwohl ich alles versucht hab. (U.a. meine alte Anleitung hier).

Unter 11.04 (Natty) schaffte ich es auch nicht, irgendwie den 260.19.06 zu installieren aus Maverick. Nichtmal selbst kompilieren hilft, da XServer mit dem Treiber inkompatibel ist, selbst mit -ignoreABI stürzt er ab. Ergo: Bei 10.10 bleiben oder sofern man (wie ich) schon auf 11.04 ist .. warten :(

Vllt. versuche ich das demnächst noch, dann hätte ich hoffentlich auch wieder HDMI Audio.

Es gibt auch diverse Bugreports dazu:

https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/748396

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/790822

http://www.warp1337.com/content/ubuntu-1104-natty-segmentation-fault-nvidia-geforce-9-series-kernel-failure-solved (für mich war das keine Lösung, half gar nicht. Ist aber auch ein anderer Bug, bei ihm stürzt das Kernel Modul nicht  komplett ab!)

https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/771594

https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/770559

http://www.nvnews.net/vbulletin/showthread.php?t=162538&highlight=9300

Ich hoffe Nvidia korrigiert das Problem demnächst mal. Unter Archlinux existiert es übrigens auch, scheint also kein Ubuntu spezifisches Problem zu sein…

P.S.: Ich hab sogar gehört, dass das Problem sogar in gleicher Form unter Windows existiert. WTF Nvidia?

Edit am 15.07.2011:
Man könnte ja meinen, dass es in der Zwischenzeit gefixt ist, dem ist nicht so.
Windows weiterhin ab > 260.99 BSODs, Linux weiterhin gleiches Problem mit 275.19 (heute am 15.7.11 erschienen) sowie 280.04 beta.
Immerhin haben wir es geschafft, dass Nvidia einen internen Bugreport dazu hat, allerdings konnten sie den Fehler bisher “nicht reproduzieren“. BUG ID ist 836658, Status kann via linux-bugs@nvidia.com erfragt werden.
Weiterhin haben wir einen Thread auf NVnews (Linux Bug Forum für Nvidia) und einen im offiziellen Nvidia Forum.
Weiterhin sollte jemand den Fehler an den Nvidia Windows Bugtracker posten, die Linux Bugreports wurden wohl gelöscht, mit dem Hinweis, dass Linux Bugreports ins NVNews Forum gehören. Falls es schon einen Windows Bugreport gibt, haben wir dann tatsächlich alle Möglichkeiten ausgeschöpft.

Ich hoffe dieser Bug wird endlich mal gefixt, ich bin echt nahe dran mein 9300-Mainboard zu verkaufen, weil es seit 2 Monaten nicht mehr richtig benutzt werden kann… Aber ehrlich gesagt, glaube ich nicht mehr daran :(

Edit am 28.07.2011:
Heute hab ich von einem Leser erfahren, dass es eine neuere Zotac Version namens “Zotac GF9300-K-E”  mit 3 Sata Ports gibt, welche das Problem nicht hat. Damit sind unsere Chancen wohl ziemlich gesunken, dass es einen Fix seitens Nvidia geben wird, hab ich zumindest das Gefühl.
Von Nvidia gibt es auch nichts neues, sie versuchen immer noch ein Board (zum Testen) zu erhalten.

Edit am 08.09.2011:
Lange ist es her seit dem letzten Update .. und es gibt wie immer nichts neues. Okay nicht ganz, Nvidia hat nun so ein Board aufgetrieben, aber offensichtlich ist es das falsche (oder zu neu und ohne Bug). Keine Ahnung wie es jetzt weiter geht, drüben im nvnews Thread hat ein User angeboten einen seinter 50 PCs an Nvidia zu schicken damit sie ein “Bug”-Mainboard erhalten. Langsam aber sicher bin ich echt genervt, ich mein ich bin froh dass sich überhaupt was tut und Nvidia sich darum kümmert, aber es tut sich halt nicht wirklich was. Noch sehe ich allerdings kaum Alternativen, aber langsam ist der Punkt erreicht, wo ich anfange mich danach umzusehen. Seit Anfang April geht das nun schon – und langsam glaube ich, dass wir da nie mehr eine Lösung sehen werden. :(

Edit am 12.09.2011: Es gibt tatsächlich positive Neuigkeiten; NVIDIA schaffte es den Bug in Windows und in Linux zu reproduzieren. Vllt. ist dieser Bug ja schon bald gefixt? (Quelle)

Edit am 27.09.2011: Gute Nachrichten! Nvidia hat endlich den Bug gefixt und das nächste Treiber Release wird wieder funktionieren (Ich denke das gilt auch für Windows!). Hooray! [Quelle]