Ich spiel auf meinem uralten Laptop (einem Asus L8400K – und damit einem P3 mit 850 Mhz und rund 256MB RAM) gerade ein wenig herum und habe hierbei festgestellt, dass sich auch Lubuntu anhübschen lässt.
Die Webseite von lubuntu hat einen Screencast online, den man für die ersten Schritte ganz gut auswerten kann.
Ralf hatte sich schon vor einiger Zeit ein hübsches Notebook von Acer gekauft – mit den üblichen Windowsbeigaben: Vista und XP Pro.
Ich hab gerade ein Ubuntu Lucid 10.04 installiert und musste feststellen, dass das CD/DVD Laufwerk nicht funktioniert. Es liegt an der BIOS Version 1.02. Nach einem Update auf die BIOS Version 1.24 funktioniert das Laufwerk reibungslos, WLan tat schon vorher und auch sonst konnte ich auf die Schnelle keine Zicken mehr feststellen.
Von der MS-Zwangssteuer einmal abgesehen scheint es sich hier um ein auch unter Linux gut laufendes Gerät zu handeln.
Hier zu Dokumentationszwecken für Interessierte die Ausgabe von
sudo lsusb -vv
und die Ausgabe von
sudo lspci -vv
Das sollte für eine Orientierung reichen.
Jaunty macht mich fast kirre: Während Hardy meine DV Camera ohne Probleme erkennt und ich mit Kino dann arbeiten kann, geschieht auf dem Laptop unter Jaunty … nichts, außer Fehlermeldungen, dass /dev/raw1394 entweder nicht vorhanden oder nicht mit den nötigen Rechten ausgestattet sei. Jetzt hab ich eine ganze Reihe von Tipps ergooglet und in der hier angegebenen Reihe dann auch umgesetzt. Ob auch einzelne davon ausreichend sind, möge jeder selbst herausfinden, denn welcher in Kombination mit welchem davon dann am Ende für meinen Laptop den Ausschlag gab, weiß ich auch nicht. Wer sich der Reihe nach durchtastet – immer wieder neu booten, sonst reicht es einmal am Ende.
Es funktionieren bei mir nun die folgenden Einstellungen und Anpassungen für die Arbeit mit Firewire Kameras und Kino unter Ubuntu Jaunty:
1. Anpassen von /etc/modules:
sudo vi /etc/modules
Hier müssen die folgenden Zeilen enthalten sein:
raw1394
dv1394
video1394
2. Anpassen der udev rules:
sudo vi /lib/udev/rules.d/50-udev-default.rules
Hier im Abschnitt zu firewire die folgenden Zeilen einfügen (sofern diese noch nicht vorhanden sind):
# Firewire
KERNEL==“dv1394[0-9]*“, NAME=“dv1394/%n“, GROUP=“video“
KERNEL==“video1394[0-9]*“, NAME=“video1394/%n“, GROUP=“video“
KERNEL==“raw1394″, GROUP=“disk“
Das Device raw1394 hab ich also der Gruppe disk zugeordnet und nicht, wie viele Tipps im Netz meinen, der Gruppe video. Eine neue Zeile beginnt übrigens immer mit KERNEL (egal wie das nun im Browser aussehen mag).
3. Anpassen der bootmisc.sh
sudo vi /etc/init.d/bootmisc.sh
Hier am Ende (nach dem \:) die folgenden Zeilen einfügen:
# Begin Edit
mknod /dev/raw1394 c 171 0
chown root:video /dev/raw1394
chmod 666 /dev/raw1394
#End Edit: exit 0
Wie gesagt – alles nur geklaut und der Reihe nach dann zusammen gestückelt, sehr Ergebnisorientiert aber am Ende wirksam. Dass es sicherlich (bei systematischer Herangehensweise) intelligentere Eingriffe ins System gibt (bei den Tipps oben ist offensichtlich, dass die jeweiligen Gruppenzuordnungen nicht zueinander passen) ist mir auch klar. War mir heute egal. Ich will schneiden und nicht im System fummeln.
Meine Quellen:
http://www.kdenlive.org/forum/toubleshooting-firewire-capture-ubuntu-jaunty-904-how
http://ubuntuforums.org/showthread.php?t=2792
https://help.ubuntu.com/community/Firewire
Die hier wiedergegebene Anleitung funktionierte auf Dell Latitude D830 und Dell Vostro 1510.
Mein Laptop unter Intrepid verschluckte sich am acroread Update aus dem Medibuntu Repo mit folgender Fehlermeldung:
Vorkonfiguration der Pakete …
(Lese Datenbank … 204761 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereiten zum Ersetzen von acroread 8.1.3-0medibuntu0.8.10.2 (durch …/acroread_9.1.0-7intrepid1_i386.deb) …
Entpacke Ersatz für acroread …
dpkg: Fehler beim Bearbeiten von /var/cache/apt/archives/acroread_9.1.0-7intrepid1_i386.deb (–unpack):
Versuche, »/usr/share/man/man1/acroread.1.gz« zu überschreiben, welches auch in Paket acroread-debian-files ist
Verarbeite Trigger für man-db …
Fehler traten auf beim Bearbeiten von:
/var/cache/apt/archives/acroread_9.1.0-7intrepid1_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Ein simples
sudo apt-get purge acroread
mit anschließendem
sudo apt-get install acroread
bügelte den Fehler wieder aus und installierte brav die neueste Version. Einige Pakete werden nun nicht mehr benötigt und diese entfernt ein
sudo apt-get autoremove
aus dem System.
Unter OpenSuSE 11.1 und auch unter Intrepid war es nur möglich auf dem Server-share Dateien und Verzeichnisse zu schreiben, zu lesen und zu löschen. An den Inhalt von Dateien durfte ich nicht ran. Speicherversuche quittierte gedit z.B. mit der Meldung
Unerwarteter Fehler not a directory
Dieses Problem hatten auch andere. Leider hab ich das erst gemerkt, als die SuSE vom Vostro schon wieder verschwunden und ein Intrepid installiert war. Dabei ist die SuSE garnicht die Schuldige – die Ursache für Probleme beim Verändern von Dateiinhalten auf Server-shares scheint eher an CIFS selbst zu liegen.
Bei mir (Debian Etch Server mit unixextensions = yes) hat es ausgereicht in der fstab auf den Intrepid Clients
//10.32.1.1/verwalter /home/dirk/Serververz cifs
rw,user,nounix,auto,uid=dirk,gid=dirk,credentials=/home/dirk/.credentials/server.cred,iocharset=utf8 0 0
zu schreiben.
Vom Intrepid Client aus gesehen erhalten die Dateien nun
-rwxrwSrwx 1 dirk dirk 307 2009-01-20 10:04 test.txt
Die gleiche Datei vom Hardy Client aus gesehen:
-rw-r–r– 1 dirk dirk 389 2009-01-20 10:05 test.txt
Auf dem Server sieht es aber richtig so aus:
-rw-r–r– 1 verwalter teachers 389 2009-01-20 10:05 test.txt
Die Übersetzung klappt also. Änderungen an der smb.conf waren nicht nötig.
Nebenwirkungen habe ich noch nicht getestet – aber jetzt kann ich wenigstens wieder von allen Clients aus den Inhalt von Dateien verändern.
Ob das nun alles auch mit rsync noch hinhaut werde ich sehen: Bisher rsyncte ich vor einem Dienstgang meine Verzeichnisse des Servers mit denen des Clients und wenn ich zurückkam ging es in die andere Richtung. Im dümmsten Fall tut rsync garnix mehr – im anderen dümmsten Fall schiebt rsync alles rüber und nicht nur die Veränderungen.
Andreas hat mich (mehr oder weniger) dazu überredet mal auch die neue OpenSuSE auszuprobieren und da ich gerade eben einen Dienstlaptop erhalten habe tat ich das auch gleich.
Die Installation auf dem Dell Vostro 1510 lief ohne Probleme durch, die zuerst falsch erkannte Bildschirmauflösung konnte über YaST angepasst werden und auch die Installation des nvidia Treibers klappte auf Anhieb.
Nur die WLan Karte wurde nicht erkannt bzw. es wurde kein Treiber eingebunden – ein Problem, das unter Ubuntu 8.10 wohl nicht auftritt, wie ein erster Test mit der LiveCD zeigte.
lspci
findet aber die richtigen Angaben für die Karte und für eine Suche im Netz nach Hilfe:
Network controller: Broadcom Corporation BCM4312 802.11b/g (rev 01)
Auf den Seiten von Broadcom gibt es für das Ding einen Treiber: http://www.broadcom.com/support/802.11/linux_sta.php
Der Rest ergibt sich aus diesem Blogbeitrag (vielen Dank) und der Beschreibung in den Treiberdateien selbst:
tar xfz hybrid-portsrc-x86-32_5_10_27_12.tar.gz
su –
zypper ref ; zypper in kernel-source linux-kernel-headers
make -C /lib/modules/(uname -r)/build M=`pwd` clean
make -C /lib/modules/(uname -r)/build M=`pwd`
mkdir /lib/modules/$(uname -r)/extra
cp wl.ko /lib/modules/$(uname -r)/extra
depmod -a
modprobe -v ieee80211_crypt_tkip wl
Jetzt noch neu booten – und schon begrüßt einen das Leuchtdiödchen für WLan und auch der gnome Netzwerkmanager findet Kontakt.
Ob das auch mit verschlüsselten WLan APs läuft – keine Ahnung. Das konnte ich noch nicht testen. Was auf jeden Fall auf mich zukommt ist, dass ich nach den sicherlich unter SuSE ebenfalls üblichen monatlichen Kernelupdates wieder neu kompilieren muss.
Nach der Installation von VMWare Workstation auf meinem Laptop unter Intrepid Ibex wollten die VMs nicht erkennen, welches Tastaturlayout ich eingestellt habe. Alle Versuche, dies über die xorg.conf oder über Gnome in [System] [Einstellungen] [Tastatur] zu richten, schlugen fehl. Nach einiger Zeit kam ich darauf, dass ich auf dem Laptop die [Fn] Taste gedrückt halten muss und die „Nummerntastatur“ verwenden muss, um den Cursor zu steuern. Zeichen wie € und @ konnte ich aber jedesmal von Neuem suchen, weil ich mir einfach nicht merken konnte, wo nun welches Zeichen liegt.
Am Anfang brachte auch Google nicht viel – ich verwendete immer die falschen Suchbegriffe. Erst eine Suche in den Foren von ubuntuusers.de brachte nun den gewünschten Hack zum Vorschein. VMware hat so seine Probleme bei der Interpretation von Tasten. Allerdings lässt sich dies auf sehr einfache Weise richten (wenn man Glück hat). Dieser Blogeintrag war für mich die Lösung, die ich hier mal auf Deutsch übersetzt ablege.
Offensichtlich handelt es sich um ein Problem mit dem evdev input driver. Dank des Posts von „doranikov“, ist aber die Lösung einfach: Teile VMWare mit, was Deine Tastatur wirklich tut! Lege hierzu die Datei ~/.vmware/config an:
xkeymap.keycode.108 = 0x138 # Alt_R
xkeymap.keycode.106 = 0x135 # KP_Divide
xkeymap.keycode.104 = 0x11c # KP_Enter
xkeymap.keycode.111 = 0x148 # Up
xkeymap.keycode.116 = 0x150 # Down
xkeymap.keycode.113 = 0x14b # Left
xkeymap.keycode.114 = 0x14d # Right
xkeymap.keycode.105 = 0x11d # Control_R
xkeymap.keycode.118 = 0x152 # Insert
xkeymap.keycode.119 = 0x153 # Delete
xkeymap.keycode.110 = 0x147 # Home
xkeymap.keycode.115 = 0x14f # End
xkeymap.keycode.112 = 0x149 # Prior
xkeymap.keycode.117 = 0x151 # Next
xkeymap.keycode.78 = 0x46 # Scroll_Lock
xkeymap.keycode.127 = 0x100 # Pause
xkeymap.keycode.133 = 0x15b # Meta_L
xkeymap.keycode.134 = 0x15c # Meta_R
xkeymap.keycode.135 = 0x15d # Menudone!
Die Datei ~/.vmware/config existierte bei mir noch nicht – was aber nichts weiter ausmacht: Einfach neu anlegen.
Sollte dies nicht den erwünschten Erfolg bringen, dann führt der oben schon verlinkte Artikel weiter aus, dass mit Hilfe von xev die Keycodes gefunden werden können:
Um die für Deine Tastatur passenden keycodes in Erfahrung zu bringen, startest Du xev in einem Terminal. Setze Deinen Cursor in das xev Fenster und drücke dann eine Taste auf Deiner Tastatur (im folgenden Fall die rechte STRG Taste).
Im Terminal sind nun Ausgaben wie die Folgende zu sehen:
KeyPress event, serial 33, synthetic NO, window 0x3200001, root 0x1cb, subw 0x0, time 749698, (167,181), root:(1793,706), state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 33, synthetic NO, window 0x3200001, root 0x1cb, subw 0x0, time 749810, (167,181), root:(1793,706), state 0x14, keycode 105 (keysym 0xffe4, Control_R), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False
Entscheidend sind die Werte nach keycode – im Schnipsel oben fett. Für die Taste [Strg] -Rechts ist das in diesem Fall 105. Verändere nun in der ~/.vmware/config den xkeymap.keycode. auf 105:
xkeymap.keycode.105 = 0x11d # Control_R0x11d ist der scan code.
… und es tut tatsächlich, auch wenn es im dümmsten Fall eine ganze Weile dauert, die Anpassungen vorzunehmen.
… ich konnte die Finger einfach nicht davon lassen und habe mir heute den Release Candidate des neuen Ubuntus auf meinen Dell D830 geschoben. Bisher bin ich eher positiv angetan: Zum ersten Mal funktionieren bei mir mit dem 177er Treiber von NVIDIA die Desktopeffekte „out of the box“ und auch die gesamte Hardware scheint rund zu laufen (Firewire hab ich bisher noch nicht getestet, aber bisher – also unter Gutsy und Hardy – traten da keine Probleme auf). Sogar das Birnchen für WLan tut.
Meine These, dass Hardware und vor allem Laptops erst ein Jahr „abhängen“ müssen, bis Linux läuft, halte ich damit für vorläufig bestätigt. Jetzt mach ich mich an’s Testen und füll mal launchpad mit den gefundenen Fehlern.
Die Auflösung meines Dell D830 mit 1280×800 Punkten nervt gelegentlich bei der Arbeit am Arbeitsplatz zu Hause. Also habe ich einen externen Monitor angeschlossen und Hardy über [System] [Einstellungen] [Bildschirmauflösung] versucht mitzuteilen, mit welcher Auflösung die beiden zu betreiben sind.
[Clone Screens] lief gleich von Anfang an ohne Probleme. Auch das Vornehmen von beliebigen anderen Einstellungen klappt – leider aber nur im Fenster für die Einstellungen selbst, übernommen hat Hardy diese nicht. In einer Art endloser Schleife musste ich das Häkchen bei [Clone Screens] immer wieder entfernen.
Erst als ich dann doch von Hand in die xorg.conf den folgenden Eintrag setzte, funktionierte das Entfernen des Clone Modus und die Einstellungen wurden von Hardy geschluckt:
Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
Device "Configured Video Device"
SubSection "Display"
Virtual 2700 1050
EndSubSection
Defaultdepth 24
EndSection
Das 2700 entspricht der x Achse beider Monitor zusammengerechnet, das 1050 der y Achse des größeren der beiden. Dies hat die Nebenwirkung, dass auch auf dem Laptopbildschirm nun 1050 statt 800 Pixel vorhanden sind – aber damit kann ich leben, weil ich in dem geschilderten Fall eh nur auf dem CRT arbeite. Warum Hardy derartige Einstellungen nicht alleine richtig setzen kann … aber ich warte ja eh auf Intrepid.
Bei xkcd zum Thema BSD gefunden – passt aber hier gerade auch auf meine Erfahrungen mit Hardy:
