Veröffentlicht am

Ubuntu Kernel 2.6.17-11 crasht NdisWrapper

Nach dem Update auf Kernel 2.6.17-11 verweigerte mein über NdisWrapper eingebundener D-Link DWL-G122 Revision C1 den Dienst. Ein Blick in /var/log/messages offenbarte auch schnell den Grund dafür:

Feb 26 21:34:46 linbook loadndisdriver: loadndisdriver: main(546): version 1.9 doesn't match driver version 1.8

Beheben ließ sich das Problem durch vollständiges deinstallieren des NdisWrappers und anschließende Neuinstallation:

sudo make uninstall
make distclean
make
sudo make install

Der Windowstreiber musste dann ebenfalls über sudo ndiswrapper -i /Dr71WU.inf eingebunden werden. Seitdem läuft wieder alles reibungslos. 🙂

Ob andere Distributionen von dem Problemchen ebenfalls betroffen sind, vermag ich nicht zu sagen.

Wenn doch sich bloß mehr Hersteller von WLAN-Chipsätzen an der Entwicklung entsprechender Kernelmodulen beteiligten oder wenigstens die Spezifikationen ihrer Hardware offenlegen würden, wäre das Leben so viel einfacher.

Doch ich möchte mich nicht beschweren: Unter unixartigen Betriebssystemen vermochte ich bislang jeden WLAN-Adapter zu installieren – auch wenn es schon mal umständlich gewesen sein mag.
Vor der Windows XP Installation auf dem Notebook meiner Schwester jedoch musste ich kürzlich kapitulieren: Der alte Adpater Marke Noname unterstützte leider nur WEP, so dass ein Wechsel der Hardware nötig war. Die alten Treiber ließen sich jedoch offenbar nicht vollständig entfernen, so dass der neue WLAN-Adapter (ebenfalls ein ein DWL-G122) nicht korrekt arbeitete. Die Verbindung zum AP wird sporadisch getrennt, die Bandbreite bricht ein und gelegentlich setzt es sogar einen Bluescreen. Das Problem konnte bis heute nicht gelöst werden und wird wohl in einer Neuinstallation des Betriebsystems münden. Möglicherweise gelingt es mir sogar meine Schwester für Ubuntu zu begeistern…. Also wenn jemand gute Argumente für Linux hat, die auch bei weniger geekigen Menschen ziehen: Immer her damit!

Veröffentlicht am

Ubuntu Edgy auf Dell Dimension 5150

Als ich versuchte Ubuntu Edgy auf meinem Dell Dimension 5150 zu installieren, brach der Installer schon beim Starten mit der Meldung Starting System log daemon: syslogd, klogd. ab. Zwar konnte das Problem durch den Bootparameter debian-installer/probe/usb=false behoben werden, doch sollte derartiges gar nicht nötig sein. An den USB-Bus angeschlossen sind ein Logitech Keyboard, eine alte Microsoft Maus sowie ein Lide30-Scanner von Canon. Bei der Installation von Dapper Drake auf gleicher Hardware gab es noch keine Probleme. Ich bin gespannt, wie sich Feisty Fawn schlagen wird. Selbst wenn Geräte am USB-Bus kaputt sind, sollte das System dadurch nicht einfrieren.

Veröffentlicht am

Wozu /media?

Gemäß den Empfehlungen des FHS sollte /media zum Einbinden von Wechseldatenträgern wie CD-ROMs, DVDs, USB-Sticks und ähnlichen in unixartigen Betriebssystemen genutzt werden. Warum nicht /mnt als „Mount point for a temporarily mounted filesystem“ ebenfalls für Wechseldatenträger genutzt werden sollte, die als solche ebenfalls nur temporär eingebunden werden, erschließt sich mir nicht ganz. Spätestens bei USB-Festplatten verliert die Unterscheidung zwischen /mnt /media meines Erachtens an Eindeutigkeit.

Veröffentlicht am

Meine Top 10 Unixshell-Kommandos

IBM hat unter Productivity tips einen interessanten Artikel veröffentlicht, der einige Tipps enthält, wie mensch seine Produktivität auf der Kommandozeile optimieren kann.
Als sehr aufschlussreich empfinde ich die vorgestellte Möglichkeit durch Kombination bekannter UNIX-Tools eine Statistik der am häufigsten in der Shell aufgerufenen Kommandos zu erstellen.

$ history|tail -1000|awk '{print $2}'|awk 'BEGIN {FS="|"} {print $1}'|sort|uniq -c|sort -r

Auf dem MacBook:

92 cd
89 ls
44 vim
34 gcc
30 awk
31 make
17 sudo
13 wget
13 java
10 echo
9 top

Auf dem Server:

80 ls
51 cd
47 sudo
41 apt-get
40 tail
23 exit
17 df
10 grep
10 rm
10 chmod
9 cat

Um eine repräsentativere Statistik zu erstellen, wäre es ratsam mit history -c sparsamer umzugehen. 😉

Veröffentlicht am

ext2 unter Windows

Linux ist oft die letzte Rettung, um Daten von einer zerstörten Windows Partition zu retten. Das Problem ist nur, wohin die Daten sichern? Die Schnittmenge der von Windows und Linux unterstützten Dateisysteme bildet FAT32. FAT32 hat viele Unzulänglichkeiten, von denen in Praxis am schwersten wiegt, dass Dateien nicht größer als 4 GB sein dürfen. Das Spiegeln einer Partition mit dd wird damit unmöglich, ohne das Dump in mehrere kleine Dateien zu splitten.
Der Schreibzugriff auf NTFS-Volumes ist unter Linux nur auf Umwegen über captive Userland“treiber“ zu empfehlen, wenngleich der im Linux-Kernel implementierte NTFS-Support seit Version 2.6.12 nicht mehr als experimentell eingestuft wird. Captive kann jedoch leider nicht immer genutzt werden, da dazu der original Treiber ntfs.sys von Microsoft vorliegen muss. Außerdem ist der Zugriff über captive auf NTFS-Volumes sehr langsam, da ein erheblicher Overhead durch die API-Emulation entsteht.

Einen Ausweg aus der Misere bietet explore2fs, ein Open Source Tool für Windows, das es ermöglich ext2 und ext3 Partitionen und Images zu öffnen. Der Lesezugriff funktioniert damit auf ext2 und ext3 formatierte Volumes sehr zuverlässig, so dass es kein Problem darstellt auch größere Datenmenge von einer NTFS-Partition unter Linux zu sichern, um sie später unter Windows mit Hilfe vom explore2fs wiederherzustellen.

Veröffentlicht am

ProFTPD – langsame Logins

Dauert das Anmelden auf einem mit ProFTPD betriebenen FTP-Server ungewöhnlich lange, ist die Ursache zumeist ein DNS Lookup des Clients.
Abhilfe schaffen die folgenden Optionen in der proftpd.conf:

UseReverseDNS off
IdentLookups off

Wird eine eingehende aktive oder ausgegehende passive Datenverbindung angestoßen, versucht der FTP-Server die IP-Adresse des Clients in einen Namen aufzulösen. Das braucht ein wenig Zeit; und sofern die Auflösung der IP nicht möglich ist, weil zum Beispiel der DNS durch eine Firewall blockiert wird, wartet ProFTD bis zum Timeout durch die libc.
Ähnlich verhält es sich mit den IdentLookups: Hier versucht der FTP-Server mittels Ident-Protokoll den Benutzernamen des Clients zu erfragen – wird das Protokoll vom Client nicht unterstützt oder die Abfrage durch einen Portfilter (aka Firewall) blockiert, muss ProFTPD auf ein Timeout warten.

Veröffentlicht am

Linux kann NTFS lesen – Windows XP nicht

Heute bat mich ein Bekannter um Hilfe, nachdem er seine Windows Systempartition unbrauchbar gemacht hatte. Das Unglück geschah beim Versuch mit Hilfe des Acronis Partition Expert die Clustergröße seiner Windows XP Systempartition zu verändern – natürlich ohne vorher ein Backup der Partition anzulegen. Nach scheinbar erfolgreichem Abschluss der Clustergrößenänderung fand der installierte Bootloader grub die Windowspartition nicht mehr. Der Versuch das Problem auf der Windows Rettungskonsole zu beheben scheiterten daran, dass die Systempartition von Windows lediglich als unpartitionierter Speicherplatz erkannt wurde. Auch eine mit BartPE erstellte LiveCD vermochte die Partition nicht zu erkennen. Allen Anschein nach hatte der Acronis Partition Expert die Partitionstabelle arg beschädigt.

Allerdings konnte die parallel installierte openSUSE 10.2 problemlos die Windows-Systempartition mounten und lesen. Dank dd war die vermeintlich zerstörte Partition schnell als Image auf eine externe Festplatte geschrieben. Der Rest wird einfach: Partition löschen, Windows neu installieren, mit einer beliebigen LiveCD starten, Image einbinden und sämtliche Dateien zurückspielen.

Was bleibt ist die Frage, warum Windows die Partition nicht lesen kann. Ist nun also der auf reserve engineering basierende NTFS Support von Linux tatsächlich stabiler oder zumindest fehlertoleranter als der von Microsoft selbst?