Archiv für die 'Linux' Kategorie

Notebook fährt beim Drücken des Ausschaltknopfes sofort herunter

4. Januar 2014 von edgar

Auch dies ist ein Problem, das bisher nur bei meinem Notebook „Lenovo ThinkPad Edge E330“ unter Ubuntu (mit KDE) auftrat. Vermutlich ist es aber kein Hardware-spezifisches Problem. Eigentlich habe ich mein Notebook im Betriebssystem so einestellt, dass es in den Standby-Zustand (Suspend-to-RAM) wechselt, wenn man den Ausschaltknopf drückt. Der Standby funktioniert problemlos beim Zuklappen des Bildschirms, nicht jedoch beim Betätigen des Ausschaltknopfes. Dann fährt das Notebook sofort und ohne Nachfrage herunter. Das ist ziemlich ärgerlich, weil alle Programme direkt geschlossen werden.

So wie es aussieht, lässt sich das Problem zur Datei /etc/acpi/powerbtn.sh zurückverfolgen. Denn ganz am Ende wird ein sofortiges Herunterfahren inittiert, wenn alles andere nicht geklappt hat:

[...]
# If all else failed, just initiate a plain shutdown.
/sbin/shutdown -h now "Power button pressed"

Nun ist es aber so, dass der Computer eigentlich schon korrekt in den Standby-Zustand versetzt wird, lediglich wird dies in powerbtn.sh nicht erkannt und deshalb am Ende der shutdown eingeleitet. Ein etwas unschöner, aber wirksamer Workaround ist das einfache auskommentieren dieser letzten Zeile:

[...]
# If all else failed, just initiate a plain shutdown.
# /sbin/shutdown -h now "Power button pressed"

Schon funktioniert alles wie gewünscht.

Helligkeitssteuerung bei Lenovo ThinkPad Edge E330 funktioniert unter Ubuntu nicht korrekt

4. Januar 2014 von edgar

Ein sehr seltsames Problem tritt bei meinem Notebook „Lenovo ThinkPad Edge E330“ unter Ubuntu (bisher sowohl 13.04 als auch 13.10) auf: Die Helligkeitsstufen scheinen nicht korrekt angeordnet zu sein. Das heißt, wenn man den Bildschirm nach und nach dunkler einstellt, wird er irgendwann wieder heller. Anders ausgedrückt: Die drei niedrigsten Stufe sind heller als die viertniedrigste.

Woran das Problem liegt, kann ich nicht genau sagen, aber Abhilfe schafft eine Option für GRUB2.

In der Datei /etc/default/grub muss man der option GRUB_CMDLINE_LINUX_DEFAULT den wert acpi_backlight=vendor hinzufügen.

Das ganze sieht dann z.B. so aus:
(alt) GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
(neu) GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=vendor"

Nach einem sudo update-grub und einem anschließenden Neustart sollte die Helligkeitssteuerung ganz normal funktionieren.

Update für Ubuntu 15.04
Mit dem Erscheinen von Ubuntu 15.04 funktionierte die Helligkeitsregelung auch so nicht. Abhilfe schaffte das Erstellen der Datei /usr/share/X11/xorg.conf.d/20-intel.conf mit dem Inhalt

Section "Device"
Identifier "card0"
Driver "intel"
Option "Backlight" "intel_backlight"
BusID "PCI:0:2:0"
EndSection

zusätzlich zu oben genannter Änderung für Grub.

Apache-Pakete kollidieren mit sich selbst bei der Installation von PHP

9. Oktober 2012 von edgar

Eigentlich ist es ganz interessant, dass die aktuellen Anleitungen für die Installation eines LAMP-Systems unter (k)ubuntu nicht zu funktionieren scheinen. Sobald Apache läuft, ist es egal ob ich libapache2-mod-php5 oder direkt php5 installieren möchte: es geht nicht. Wegen einer ungelösten Abhängigkeit versucht aptitude, einen Großteil des Basissystems zu deinstallieren.

edgar@discovery: ~ $
sudo aptitude install php5
Die folgenden NEUEN Pakete werden zusätzlich installiert:
apache2-mpm-prefork{ab} libapache2-mod-php5{a} php5 php5-cli{a}
php5-common{a}
0 Pakete aktualisiert, 5 zusätzlich installiert, 0 werden entfernt und 0 nicht aktualisiert.
6.619 kB an Archiven müssen heruntergeladen werden. Nach dem Entpacken werden 17,9 MB zusätzlich belegt sein.
Die folgenden Pakete haben verletzte Abhängigkeiten:
apache2-mpm-worker : Kollidiert mit: apache2-mpm , welches ein virtuelles Paket ist.
apache2-mpm-prefork : Kollidiert mit: apache2-mpm , welches ein virtuelles Paket ist.
offen: 110; geschlossen: 1076; zurückgestellt: 39; Konflikte: 70 Internal error: the solver Install(fontconfig-config:amd64 2.8.0-3ubuntu9
{fontconfig-config:amd64 2.8.0-3ubuntu9}>) of a supposedly unresolved dependency is already installed in step 1421
offen: 195; geschlossen: 2062; zurückgestellt: 113; Konflikte: 280
Die folgenden Aktionen werden diese Abhängigkeiten auflösen:
[... 234 Pakete, welche entfernt werden sollen ...]

Das Problem liegt auf der Hand: Ein virtuelles Paket, welches von der alleinigen Installation von Apache herrührt, kollidiert mit einem der Apache-Pakete, die für PHP benötigt werden.

Wie löst man dieses Problem?

Bei mir hat die Installatio geklappt, als ich libapache2-mod-php5 bzw. php5 installiert habe, ohne vorher eine Grundinstallation von Apache durchzuführen. Apache wird bei der Installation von PHP mitinstalliert, man muss sich also gar nicht darum kümmern.

Also einfach das Paket apache2 mit aptitude remove apache2 wieder deinstallieren und gleich php5 mit aptitude install php5 installieren und schon sollte es gehen.

Schlussbemerkung: Mit der graphischen Paketverwaltung hat die Installation problemlos geklappt.

Wine startet nicht unter Ubuntu 11.10 (64 bit)

13. Februar 2012 von edgar

Schon länger hatte ich dieses Problem, aber erst heute Zeit, mich damit zu beschäftigen: Wine (was man z.B. für Teamviewer braucht) ließ sich nicht starten. Dabei habe ich es auf meinem relativ neu installierten ubuntu 11.10 (oneiric) schon neu installiert, entfernt, wieder installiert und so weiter. Allerdings ließ es sich trotzdem nicht starten.

Im Terminal ausgeführt zeigte sich folgendes:

/usr/bin/wine: Datei oder Verzeichnis nicht gefunden

Die Datei ist aber definitiv da. Ein bisschen Recherche später habe ich das Problem gefunden: Eine Bibliothek ist schadhaft. Bei mir reichte es, sie durch den Befehl

sudo aptitude reinstall libc6-i386

einfach neu zu installieren.

Schwarze Dreiecke in KDE

13. Juli 2011 von edgar

Nach der Installation von Ubuntu 11.04 (Narry Narwhal) hatten viele Programme (OpenOffice bzw. LibreOffice, Firefox, Thunderbird, …) ein hässliches schwarzes Dreieck an der rechten unteren Fensterecke. Das musste unbedingt weg, schließlich kann man sein hübsches KDE nicht so verhunzt lassen. Nach einigen Nachforschungen fand ich heraus, dass es sich dabei um den „Griff“ für die Größenänderung handelt, den es bei gtk-Programmen unter KDE verhaut.

Weg bekommt man die schwarzen Ecken, indem man den gtk-Style ein bisschen anpasst. Das geht für den einzelnen Benutzer in der Datei .gtkrc-2.0-kde4 oder systemweit in der Datei /usr/share/themes/oxygen-gtk/gtk-2.0/gtkrc. Nach dem Öffnen mit dem Lieblingseditor fügt man ganz am Ende folgenden Abschnitt ein:


style "default-style"
{
GtkWindow::resize-grip-height = 0
GtkWindow::resize-grip-width = 0
}
class "GtkWidget" style "default-style"

Dadurch werden die „Grips“ auf null gesetzt, wodurch die schwarzen Ecken verschwinden.

Datei oder Verzeichnis nicht gefunden

13. Juni 2011 von edgar

Nun, manchmal hat es den Anschein, als möchte das Betriebssystem den Benutzer gezielt ärgern. So auch bei diesem Problem:

edgar@discovery: ~/[...]/bin $ ./java
bash: ./java: Datei oder Verzeichnis nicht gefunden

Das Betriebssystem will mir also mitteilen, dass die Datei nicht existiert. Allerdings ist sie vorhanden und die Rechte stimmen auch, wie ls -la offenbart:

edgar@discovery: ~/[...]/bin $ ls -la
[...]
-rwxr-xr-x 1 edgar edgar 47308 2011-02-19 15:54 java
[...]

Nun gut, aber was soll das ganze?

Leider ist die Meldung „Datei oder Verzeichnis nicht gefunden“ — zumindest in meinem Fall — völlig falsch. Es fehlt eine Bibliothek, weil hier ein 32-Bit-Programm auf einem 64-Bit-System ausgeführt werden soll. Allerdings erzählt einem das keiner. Eine Installation des Paketes ia32-libs hat bei mir das Problem behoben.

Notebook wacht bei Akkubetrieb nicht aus dem Standby-Modus (Suspend) auf

17. Januar 2011 von edgar

Heute habe ich ein sehr seltsames Problem bei meinem Notebook behoben: Im Akkubetrieb erwachte es nicht aus dem Standby-Modus, und zwar weder aus S3 (Suspend to Disk, STD) noch aus S4 (Suspend to RAM, STR). Naja, eigentlich wachte das Notebook schon auf, ist aber jedesmal kurz danach eingefroren (freeze). Im Netzbetrieb zeigten sich jedoch keinerlei Probleme.

Der Vollständigkeit halber: Bei dem Notebook handelt es sich um ein Belinea o.book 1304 mit einer Realtek R8187SE WLAN-Karte, welche das Problem verursachte.

Nachdem pm_trace nichts brauchbares lieferte, sah ich mir die Logdateien erneut an. In /var/log/syslog fand ich einen Hinweis auf den Netzwerk-Manager:


Jan 17 20:22:53 discovery NetworkManager[961]: wake requested (sleeping: yes enabled: yes)
Jan 17 20:22:53 discovery NetworkManager[961]: waking up and re-enabling...
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): now managed
Jan 17 20:22:53 discovery kernel: [26104.861236] r8169 0000:02:00.0: eth0: link down
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): device state change: 1 -> 2 (reason 2)
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): bringing up device.
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): preparing device.
Jan 17 20:22:53 discovery NetworkManager[961]: (eth0): deactivating device (reason: 2).
Jan 17 20:22:53 discovery NetworkManager[961]: Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 17 20:22:53 discovery NetworkManager[961]: Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Jan 17 20:22:53 discovery NetworkManager[961]: (wlan0): now managed
Jan 17 20:22:53 discovery NetworkManager[961]: (wlan0): device state change: 1 -> 2 (reason 2)
Jan 17 20:22:53 discovery NetworkManager[961]: (wlan0): bringing up device.
Jan 17 20:22:53 discovery kernel: [26104.861678] ADDRCONF(NETDEV_UP): eth0: link is not ready
Jan 17 20:22:53 discovery kernel: [26104.862500] r8180: Bringing up iface
Jan 17 20:22:53 discovery kernel: [26104.881316] Skipping EDID probe due to cached edid
Jan 17 20:22:54 discovery kernel: [26105.062340] r8180: Card successfully reset
Jan 17 20:22:54 discovery kernel: [26105.811381] r8180: WIRELESS_MODE_G
Jan 17 20:22:54 discovery kernel: [26105.811383]
Jan 17 20:22:54 discovery NetworkManager[961]: (wlan0): preparing device.
Jan 17 20:22:54 discovery NetworkManager[961]: (wlan0): deactivating device (reason: 2).
Jan 17 20:22:54 discovery kernel: [26105.828079] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jan 17 20:22:54 discovery NetworkManager[961]: (wlan0): supplicant interface state: starting -> ready
Jan 17 20:22:54 discovery NetworkManager[961]: (wlan0): device state change: 2 -> 3 (reason 42)

Dies war der letzte Eintrag vor dem Einfrieren (und damit vor dem Reboot).

Testweise habe ich den Netzwerk-Manager vor dem Energiesparmodus über /etc/init.d/network-manager stop angehalten und siehe da: Der Computer erwachte aus dem Standby. Nach dem Starten des Netzwerk-Manager fror er prompt wieder ein.

Die üblichen Verdächtigen bei Fehler dieser Art sind fehlerhafte Treiber. Deshalb habe ich das Kernelmodul meiner WLAN-Karte (r8187se) entsprechend einer Anleitung von Ubuntuusers in die Datei /etc/pm/config.d/unload_module folgendermaßen eingefügt:

SUSPEND_MODULES="$SUSPEND_MODULES r8187se"

Nachdem diese Datei mit sudo chmod +x /etc/pm/config.d/unload_module ausführbar gemacht wurde, funktioniert der Standbymodus wie gewohnt auch bei meinem Notebook.

Natürlich können auch andere Treiber ein Problem dieser Art hervorrufen. Ein Mögliches Vorgehen ist, sich mit sudo lsmod alle Kernelmodule anzeigen zu lassen und diese durch Eintragen in unload_module der Reihe nach darauf hin zu testen, ob sie das Problem verursachen.

Absturz von OpenOffice beim Dateiauswahldialog

19. Dezember 2010 von edgar

Dieser Fehler trat bei mir immer mal wieder auf, und zwar völlig unregelmäßig. Die meiste Zeit ging alles ganz normal, aber an manchen Tagen tauchte folgendes Problem auf:

OpenOffice stürzt einfach ab, sobald der Dateiauswahldialog geöffnet wird (also beim Öffnen, Speichern unter, PDF-Export). Das Problem lässt sich problemlos reproduzieren. Nach einem Neustart des Computers ist es (manchmal) weg. Allerdings ist dieses Problem insgesamt sehr nervig, weil man nicht mehr vernünftig arbeiten kann.

Wenn ich OpenOffice in der Kommandozeile starte, dann erhalte ich folgende Fehlerausgabe:

QInotifyFileSystemWatcherEngine::addPaths: inotify_add_watch failed: No such file or directory
QFileSystemWatcher: failed to add paths: /home/edgar/.config/ibus/bus
Bus::open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext: no connection to ibus-daemon
X-Error: BadAtom (invalid Atom parameter)
Major opcode: 17 (X_GetAtomName)
Resource ID: 0x13121313
Serial No: 15681 (15681)
These errors are reported asynchronously,
set environment variable SAL_SYNCHRONIZE to 1 to help debugging

Weder der Hinweis zu iBus noch SAL_SYNCHRONIZE brachten mich bei diesem Fehler weiter. Falls jemand einen Grund oder eine Lösung findet, bitte hier posten.

Ich habe lediglich ein Workaround gefunden: Wenn der Fehler auftritt kann man bei „Extras“ > „Optionen“ unter „OpenOffice.org“ > „Allgemein“ > „Öffnen/Speichern Dialoge“ das Häkchen vor „OpenOffice.org-Dialoge verwenden“ setzen.

luksOpen tut nichts bei (falsch) zusammengebautem RAID

6. Dezember 2010 von edgar

Hier kommt mal wieder ein sehr nerviges Problem. Mein Szenario ist folgendes:

Man hat ein RAID 1 (Festplattenspiegelung), darin liegt eine mit LUKS verschlüsselte Partition. Dabei ist mindestens eine der RAID-Partitionen die einzige Partition der Festplatte. Nachdem man zunächst das RAID von Hand angelegt und dann alles getestet hat, trägt man die Daten für das RAID (welche man über mdadm --detail --scan bekommt) in die Datei /etc/mdadm/mdadm.conf ein. Nach dem nächsten Reboot läuft auch alles (scheinbar) ganz normal. Allerdings passiert nichts, wenn man mit

sudo cryptsetup luksOpen /dev/md0 [label]

sein verschlüsseltest Laufwerk aktivieren möchte. Es kommt nicht einmal eine Meldung. Hier hilft der Parameter -v:

edgar@atlantis: ~ $ sudo cryptsetup -v luksOpen /dev/md0 backup
Command failed with code 22: /dev/md0 is not a LUKS device.

Natürlich ist hier weder das Cryptolaufwerk noch LUKS kaputt, sondern das RAID. Vermutlich würde auch alles andere (z.B. mount) einen Fehler melden. Was genau kaputt ist liefert ein Blick in /proc/mdstat:

cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb1[0] sdc[1]
488351744 blocks [2/2] [UU]
unused devices: none

Seht ihr den Unterschied? Ein Eintrag lautet „sdb1“, der andere nur „sdc“. mdadm hat aus versehen die gesamte Festplatte (/dev/sdc) als RAID-Device interpretiert und nicht die Partition (/dev/sdc1). Das ist sehr ärgerlich und lässt sich laut ubuntuusers dadurch vermeiden, dass man die Partition mindestens 128 KB kleiner macht als die Plattengröße.

Sicherer ist aber eine Definition in der /etc/mdadm/mdadm.conf. Der vordefinierte Eintrag „DEVICE partitions“ allein hilft allerdings nicht. Man sollte die Partitionen entweder komplett für jedes RAID in der Form „DEVICE /dev/[partition1] /dev/[partition2]“ angeben, oder aber einen Wildcard-Eintrag der Form „DEVICE /dev/hd*[0-9] /dev/sd*[0-9]“ benutzen.

Achtung: Bei einem RAID sollte man immer zuerst prüfen, ob es korrekt zusammengebaut ist! Sobald man irgendwelche Tools wie z.B. fsck auf ein falsch gebautes RAID loslässt, gehen die Daten mit hoher Wahrscheinlichkeit verloren!

rdiff-backup bei vorhandenen Daten initialisieren

30. November 2010 von edgar

Angenommen man möchte von einer anderen Backup-Variante (z.B. rsnapshot, rsync, unison, cp, … ) auf rdiff-backup umsteigen. Dann hat man zumeist ein Datenverzeichnis, in dem eine Kopie der Originaldaten liegt. Jetzt wäre es schön, wenn man dieses „reine“ Datenverzeichnis mit rdiff-backup in ein rdiff-backup-Ziel umwandeln könnte, ohne alle Dateien neu übertragen zu müssen*. Leider beschwert sich rdiff-backup aber, wenn man das vorhat:

Fatal Error: Destination directory
/mnt/backup/home
exists, but does not look like a rdiff-backup directory. Running
rdiff-backup like this could mess up what is currently in it. If you
want to update or overwrite it, run rdiff-backup with the --force
option.

Laut den alten Listenarchiven kann man die Option –force hier problemlos benutzen, um ein Verzeichnis mit rdiff-backup zu initialisieren. Die Daten werden dabei nicht komplett neu übertragen, sondern nur die Änderungen. Allerdings wird das Backup trotzdem recht lange dauern, weil rdiff-backup zuerst seine Datenbank erstellt und die Metadaten aller Dateien auslesen bzw. anlegen muss.

*: Ein ähnliches Szenario wäre es, wenn man das Backup über das Internet machen möchte. Dabei will man vermutlich zuerst den Datenbestand auf einer externen Festplatte übertragen (Initialbackup), damit man nicht alles über das Internet verschicken muss.



css.php