Schlagwort-Archiv: Ubuntu

Ubuntu 14.04.4 auf Medion Akoya E6240T

Bei der Installation von Ubuntu 14.04.4 auf ein ALDI Notebook (Medion Akoya E6240T) sind mir ein paar Dinge aufgefallen.

Touchscreen

Das Notebook besitzt einen Touchscreen und ist damit mit den Fingern wie ein Tablet bedienbar. Überraschenderweise funktionierte das sofort ohne weitere Konfiguration.

UEFI

Vor der Ubuntu-Installation lief (besser:kroch) das Gerät mit Windows 10. Im BIOS musste als Boot Manager wieder UEFI anstelle von Windows Boot Manager eingestellt werden, damit ein Boot von DVD funktionierte. Die automatische Partitionierung ha dann eine UEFI Partition angeboten und eingerichtet- also alles recht problemlos.

WLAN

Das WLAN ist zickig und verlor zunächst schnell wieder die Verbindung. Abhilfe schafft eine entsprechende Modulkonfiguration. Anzulegen ist die Datei /etc/modprobe.d/rtl8723be.conf mit folgende Inhalt:

options rtl8723be fwlps=N ips=N

Damit läuft das WLAN mit ordentlicher Geschwindigkeit und ohne Abbrüche.

Touchpad

DAs Touchpad funktionierte zunächst überhaupt nicht. Abhilfe schafft eine Ergänzung in /etc/defaults/grub:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i8042.reset=1 i8042.nomux=1 i8042.noloop=1"

wobei die Optionen quiet und splash schon vorhanden waren. Damit geht auch das Touchpad.

Sondertasten

Leider funktionieren bisher nur die Tasten (Fn-Taste) für die Helligkeitssteuerung. Alle anderen funktionieren nicht oder nicht korrekt; die Lautstärkeregelung blockiert die GNOME Flasback- und Unity Sitzung durch eine dauerhaft angezeigte Lautstärkenanzeige.

Ubuntu 9.04 und TrekStor Vibez MP3 Player

Mein TrekStor Vibez MP3-Player wurde unter früheren Linux-Distributionen immer als USB Massenspeicher erkannt. Daten liessen sich ohne Probleme wie bei einem USB Stick kopieren. Unter Ubuntu 9.04 wird das Gerät als Vibez MP3 Player erkannt, es lassen sich aber keine Daten kopieren. Die Ursachen dieses Fehlers und seine Behebung sind folgendermassen zu beschreiben:

Der Fehler

Für die Erkennung von USB Geräten und die Einbindung in das System ist u.a. HAL (hardware abstraction layer) zuständig. Bei Anschluss eines USB Geräts scannt HAL dieses und entscheidet über die Einbindungsart. Für den TrekStor Vibez ist in /var/log/messages zu sehen:


[1] usb 2-1.2: new high speed USB device using ehci_hcd and address 7
[2] usb 2-1.2: configuration #1 chosen from 1 choice
[3] scsi12 : SCSI emulation for USB Mass Storage devices
[4] gvfsd-gphoto2[22362]: segfault at c ip b7d629e0 sp bfbf4c24 error 4 in libpthread-2.9.so[b7d5b000+15000]

In Zeile 1 wird das Gerät erkannt, in Zeile 4 wird das für dieses Gerät zuständige GVFS Modul gestartet. GVFS ist die GNOME Implementierung eines virtuellen Dateisystems auf Benutzerebene. Es abstrahiert reale Dateisysteme und bietet eine einheitliche Schnittstelle für Anwenderprogramme, z.B. für Nautilus. Das Problem hier ist nur: Das gvfsd-gphoto2 Modul stürzt nach dem Laden mit einem Segmentation Fault ab ! Dies ist ein bekannter Bug (ua. https://bugs.launchpad.net/ubuntu/+bug/345916).

Die Lösung

In diesem Artikel fand sich ein Lösungsansatz:

  1. Aus einem Terminal heraus als Systemverwalter nach /usr/share/hal/fdi/preprobe/10osvendor/ wechseln
  2. Eine Sicherheitskopie der Datei 20-libgphoto2.fdi machen
  3. Die Originaldatei in einen Editor laden und nach „TrekStor“ suchen
  4. Der Eintrag findet sich in einem Konfigurationsblock, der mit

    <match key="usb.vendor_id" int="1647">

    beginnt.
  5. Dieser Block (11 Zeilen) wird gelöscht. Dadurch wird die Zuordnung des Moduls gvfsd-gphoto2 entfernt.

Wenn man danach das Gerät wieder anschliesst, wird es korrekt als Massenspeicher erkannt. Das zeigt sich auch im Protokoll:


usb 2-1.2: new high speed USB device using ehci_hcd and address 10
usb 2-1.2: configuration #1 chosen from 1 choice
scsi15 : SCSI emulation for USB Mass Storage devices
usb 2-1.2: reset high speed USB device using ehci_hcd and address 10
scsi 15:0:0:0: Direct-Access TrekStor vibez 2 PQ: 0 ANSI: 4
sd 15:0:0:0: [sdg] 23429729 512-byte hardware sectors: (11.9 GB/11.1 GiB)
sd 15:0:0:0: [sdg] Write Protect is off
sd 15:0:0:0: [sdg] 23429729 512-byte hardware sectors: (11.9 GB/11.1 GiB)
sd 15:0:0:0: [sdg] Write Protect is off
sd 15:0:0:0: [sdg] Attached SCSI removable disk
sd 15:0:0:0: Attached scsi generic sg8 type 0

Mit dieser Änderung lassen sich wieder Dateien kopieren. Zuständig ist jetzt das usb-storage Modul, das den USB Massenspeicher als SCSI Gerät einbindet.

Tipps zur Ubuntu 9.05 Installation

Nach dem Wechsel auf Ubuntu 9.04 „Jaunty Jackalope“ als Desktop-Betriebssystem sind für einen Fedora Core- Umsteiger einige Dinge anders als gewohnt. Hier ein paar Praxis-Tipps:

Problem:

Ein am Parallelport angeschlossener Drucker funktioniert nicht

Lösung:

Wahrscheinlich sind nicht alle erforderlichen Module für die parallele Schnittstelle nicht vollständig geladen. Nach der Installation sind zwei Module aktiv (Ausgabe von lsmod):

lp 17156 0
parport 42220 3 ppdev,lp

Es fehlt das PC-spezifische Parport-Modul; das lässt sich auch aus dem Systemlog (/var/log/messages) nachvollziehen:

lp: driver loaded but no devices found

Das Nachladen des Moduls behebt das Problem:

sudo modprobe parport_pc

Im Systemlog wird gemeldet:

parport0: PC-style at 0x278 (0x678), irq 5, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA]

Damit das Modul beim Boot automatisch geladen wird, ist ein Eintrag in /etc/modules erforderlich; einfach den Modulnamen in einer einzelnen Zeile eintragen.

Problem:

Beim Aktivieren des Netzwerks soll ein bestimmtes Kommando ausgeführt bzw. ein Daemon gestartet werden

Lösung:

Wenn die Netzinterfaces über das GUI-Tool „Netzverbindungen“ konfiguriert wurde, ist der beste Weg, in /etc/network/ip-up.d das passende Startscript zu hinterlegen. Die dort vorhandenen Scripts können als Muster dienen.

Problem:


Die Installation soll auf einem System mit einem On-Board RAID Controller erfolgen. Der Ubuntu-Installer sieht aber die einzelnen Platten und ignoriert anscheinend die RAID Einstellungen.

Lösung:

Die auf Mainboards im Consumer-Bereich verbauten Chips/Chipsätze bieten oft kein wirkliches Hardware-RAID. Vielmehr stellen sie Multikanal-Diskcontroller mit einer besonderen BIOS Unterstützung zur Konfiguration dar. Die Realisierung der RAID Level muss mehr oder weniger umfangreich der jeweilige Treiber (und damit die Host-CPU) zum Chip/Chipsatz übernehmen. Vielfach spricht man hier von einem „Fake RAID“.

Der auf meinem ASUS Board verbaute Intel ICH8R Chipsatz stellt ein derartiges RAID bereit. Ubuntu 9.04 erkennt bei der regulären Installation nur normale SATA Kanäle. Um dennoch eine erfolgreiche Installation unter Nutzung der RAID Funktionen hinzubekommen, muss anders vorgegangen werden:

  1. Zunächst wird das Installationsmedium als LiveCD gebootet
  2. Dann wird das Modul „dmraid“ zur Unterstützung installiert
  3. Nach einer normalen Installation ohneGrub-Einrichtung wird Grub manuell aus einem chroot-Environment installiert und das „dmraid“ Modul in die Init-RAM-Disk übernommen

Das ist das Prinzip des Vorgehens, die Details stehen im

Ubuntu Fake RAID Howto

Zu beachten ist hierbei (Abschnitt zu Ubuntu 9.04):

  • Schritt 9, Absatz l, Satz ii ist nur nötig, wenn bereits ein anderes Betriebssystem auf den Platten liegt. Auf einer frischen Neuinstallation wird das find Kommando keinen Bootloader finden.
  • Schritt 9, Absatz n ist ebenfalls obsolet, wenn kein weiteres System vorhanden ist.

Das Vorgehen ist im übrigen hervorragend beschrieben und zeigt sehr beeindruckend, welche Vorteile die Installation von einem vollständigen Live System bietet.

Problem:


Beim Booten sollen CIFS (Windows) Shares gemoutet werden, die beim Herunterfahren auch wieder unmountet werden sollen.

Lösung:

Zunächst muss das Paket smbfs installiert sein. Dann reicht für das automatische Mounten ist ein Eintrag in /etc/fstab:


//server/share /meinmountpoint smbfs credentials=/etc/geheim,auto,port=139,ip=1.2.3.4 0 0

Hierbei ist zu beachten:

  1. /etc/geheim ist eine Datei mit dem Benutzernamen und dem Passwort des Windows-Logins, über das der Share gemountet werden soll. Das steht in zwei Zeilen:

    username=windowuser
    password=seinpassword

  2. port=139 erzwingt die Benutzung des klassischen SMB Ports für die Freigabe. smbfs benutzt in der aktuellen Version erst Port 445/tcp und erst bei Misserfolg den Port 139/tcp. Wenn aber der Windows-Server nur 139/tcp kennt, entsteht dadurch eine überflüssige Verzögerung.

Eigentlich würde das auch für das Unmounten reichen, aber hier wird es schwierig:
Weil beim Shutdown erst das Netzwerk gestoppt wird und dann alle Mounts entfernt werden, hängt der Shutdown. Abhilfe schafft ein Verlinken des Scripts /etc/init.d/umountnfs.sh in die passenden SysV Initverzeichnisse:

ln -s /etc/init.d/umountnfs.sh /etc/rc0.d/K17umountnfs
ln -s /etc/init.d/umountnfs.sh /etc/rc6.d/K17umountnfs

 

Dieses Script übernimmt das Abhängen nicht nur von NFS-, sondern auch von allen anderen Netzuwerkmounts.