Kategorie-Archiv: Linux

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.

VMWare ESXi 5.x Kommandozeile

Manchmal steht zur Konfiguration eines VMWare ESXi Servers nur ein Shellzugang zur Verfügung. Durch die CLI Kommandos lassen sich dann aber doch einige administrative Aufgaben erledigen. In diesem Beitrag sammele ich die Kommandos, die ich in derartigen Situationen selbst verwendet habe. Die Liste ist also nicht vollständig und unter pragmatischen Aspekten zusammengestellt.

vim-cmd vmsvc/getallvms alle konfigurierten VMs anzeigen, erste Spalte ist vmid = interne nummer der VM
esxcli vm process list alle laufenden VMs anzeigen
vim-cmd vmsvc/power.on vmid starte VM mit angegebener vmid
vim-cmd vmsvc/power.getstate vmid Status VM mit vmid
esxcli system shutdown Host herunterfahren
reboot Host neu starten

Atari ST und Linux mit Nullmodem verbinden

Zum Datenaustausch zwischen Linux und einem Atari ST bietet sich in Ermangelung von verfügbaren Netzwerkkarten für den Atari eine Verbindung per Nullmodemkabel an. Folgende Schritte sind n&oouml;tig:

  1. Die serielle Schnittstelle des Atari (25-polig, Male) mit der seriellen Schnittstelle des PC (meist 9-polig, Male) mit Nullmodemkabel verbinden.
  2. Auf der Linux-Seite (hier: CentOS 5.4) einen getty-Prozess starten. Hierzu am Ende der Datei /etc/inittab ergänzen (root-Rechte erforderlich):

    ag:2345:respawn:/sbin/agetty -h ttyS0 19200 vt52
     

    und mittels Befehl init q den Initprozess um Neueinlesen und Starten des getty-Prozesses bitten (mit ps -ax kontrollieren).

  3. Das Programm Teddy Term von http://www.chebucto.ns.ca/software/atariST/comm/tterm214.zip herunterladen und per Diskette auf den Atari übertragen, entpacken und starten.
  4. Mit der linken Maustaste öffnet sich ein Menü, dort kann unter Modem Configuration die Bitrate auf 19200 Bits/s eingestellt werden.
  5. Nach Drücken der Eingabetaste sollte sich der Login-Prompt des Linuxrechners zeigen.
  6. Auf der Linuxseite muss das Paket lrzsz (ist Bestandteil der meisten Distributionen) installiert sein. Dann kann mit sz dateiname nach der Anmeldung am PC über Teddy Term ein ZModem-Upload vom PC auf den Atari angestossen werden. Das Terminalprogramm erkennt die Übertragung selbstständig und speichert die Datei ab.

 

Zwar sind die Übertragungsgeschwindigkeiten nicht berauschend, dafür ist man nicht mehr auf funktionierende 2DD Disketten angewiesen.

Linux Server durch USV automatisch herunterfahren

Unter Linux steht mit den Network UPS Tools ein leistungsfähiges Werkzeug für die Nutzung von unterbrechungsfreien Stromversorgungen (USV) und die Reaktion auf Signale von diesen bereit. So kann ein Server automatisch heruntergefahren werden, wenn der USV der Strom ausgeht.

Hierzu braucht es aber ein wenig Vorbereitung:

  1. In der Datei /etc/upsmon.conf ein Script definieren, das ausgeführt wird, wenn ein Shutdown-Signal kommt:

    SHUTDOWNCMD "/usr/local/sbin/ups_shutdowncmd.sh"

  2. Darin die erforderlichen Kommandos für den Shutdown hinterlegen. In meinem Falle bedeutet dies, erst alle Mounts meines NAS zu entmounten, dann das NAS herunterzufahren und schliesslich den Server selbst zu stoppen:

    sudo /etc/init.d/netfs stop
    /opt/local/sbin/buffalo_shutdown.sh &
    /bin/sleep 5s
    sudo /sbin/shutdown -h now

    sudo ist erforderlich, weil das Script nicht mit Root-Rechten, sondern mit der UserID von upsmon ausgeführt wird; dies ist bei CentOS 5.3 der User nut

  3. In /etc/sudoers sind folgende Ergänzungen nötig:

    Defaults:nut !requiretty
    nut ALL=(root) NOPASSWD: /sbin/shutdown
    nut ALL=(root) NOPASSWD: /etc/init.d/netfs

    Die „Defaults“ Zeile er möglicht dem User nut auch, Kommandos ohne ein laufendes Terminal abzusetzen. Ohne diese Zeile wären die Kommandos zwar interaktiv von einer Shell, aber nicht aus dem Script möglich. Die beiden anderen Zeilen geben die Kommandos ohne vorherige Passworteingabe frei.

Atari ST oder Amiga Disketten unter Linux lesen

Die nachfolgenden Hinweise beziehen sich immer auf 3 1/4 Zoll Disketten mit 720 kBytes, Double Sided, Double Density (DS/DD)

Allgemeines zu DD Disketten

Zum Thema DD Disketten sind einige Punkte wichtig:

  1. Disketten mit „Double Density“ (DD) sind mit Eisenoxid beschichtet und besitzen eine Koerzitivfeldstärke von ca. 300 Oersted (Oe), „High Density“ Disketten verwenden Kobalt dotiertes Eisenoxid mit einer Koerzitiv-Feldstärke von ca. 600 Oe. Dementsprechend schreiben HD-Laufwerke mit doppelter Feldstärke schmalere Spuren als DD Laufwerke. DD Laufwerke können diese Magnetisierung nicht vollständig löschen. Versucht man also, eine bereits formattierte HD Diskette auf einem DD Laufwerk erneut zu formattieren, erhält man entweder sofort Fehler oder das Beschreiben der Diskette funktioniert nicht. Dies gilt für DD Laufwerke bei Atari, AMIGA und auch für die Laufwerke in Knubbel-Macs.
  2. Nur echte DD Disketten lassen sich auf einem Atari oder AMIGA mit DD Laufwerk formattieren. Daher sollte man seinen Bestand an echten 2DD Disketten gut behüten !
  3. Die Lochung links oben in einer 2DD Disk signalisiert normalerweise einem PC Disklaufwerk die Grösse. Ein Überkleben dieses Lochs spiegelt dem Laufwerk eine 720 KByte Disk vor, sie lässt sich dann nur auf 720 kByte formattieren. Aber: Die Spurbreite und Magnetisierung ist nach wie vor die eines HD Laufwerks und nicht die eines DD Laufwerks. Diese oft zitierte „Fake-DS“ Methode funktioniert also oft nicht. Es kann helfen, die Diskette mehrfach auf einem DD Laufwerk zu formattieren. Wird sie dann aber vom HD Laufwerk des PC beschrieben (zwecks Datenaustausch), klappt dies meist nur einmal.

Das Schreiben der Disketten auf dem PC kann so klappen:

  • Auf dem PC läuft Linux Ubuntu 9.04, die MTools sind installiert und das Floppy Device (/dev/fd0) ist für den Benutzer les- und schreibbar
  • In /etc/mtools global den Formatcheck für Disketten abschalten:

    MTOOLS_SKIP_CHECK=1

  • Das passende Format der Floppy in einer Shell vorgeben:

    setfdprm /dev/fd0 "720/720"

Atari ST

Das Datenaustausch mit einem Atari Mega ST2 mit einem Linux Ubuntu-PC klappt folgendermassen:

  • Diskette auf dem Atari formatieren (Double Sided)
  • Unter Linux sollte sich mit mdir a: der Inhalt einer Original-Atari Diskette anzeigen lassen.
  • Atari TOS verwendet das gleiche Format (FAT) wie MSDOS, schreibt aber eine andere Kennung in den Bootsektor. Daher muss bei den MTools die Prüfung dieser Kennung unterdrückt werden.
  • Nach meinen Beobachtungen treten nach einigen Kopiervorgängen mit mcopy unter Linux wieder Fehlermeldungen auf den Disketten auf. Dann muss die Disk neu auf dem Atari formatiert werden (Löschen/Schnellformatieren genügt), anschliessend funktioniert sie wieder einige Zeit.

Amiga

Im Prinzip gilt das oben gesagte, allerdings ist zu beachten (alles für A1200 mit Workbench 3.1):

  • Die normal formatierten Amiga Disketten haben (Double Sided, Single Density) aufgrund der anderen Laufwerksfabrikate eine Kapazität von 880 kByte und sind damit nicht kompatibel zu den PC-Diskettenlaufwerken.
  • PC-kompatibel sind nur Disketten, die als MSDOS Disketten formatiert werden. Hierzu muss aus Comodities/CrossDOS das Icon PC0 (internes Laufwerk) in das Verzeichnis DEVS/DOSDrivers des Systemvolumes gezogen werden. Anschliessend ist ein Neustart fällig!
  • Jetzt lassen sich MSDOS 720 KByte Disketten als MSDOS (FAT) Disks formattieren und auch auf dem PC unter Linux lesen (setfdprm wie oben!)

Netatalk auf CentOS 5.3 installieren

Netatalk implementiert Appletalk und AppleShare IP auf UNIX-Systemen und ist auch auf der Linux-Distribution CentOS 5.3 (basiert auf Red Hat Enterprise Linux Quellcode) lauffähig. Dadurch tritt ein Linuxrechner als Server in einem Apple-Netzwerk auf- sozusagen ein SAMBA für klassische Apple-Netze. Allerdings muss die Software aus dem Quellcode neu kompiliert und ein anderer als der standardmässig installierte Kernel verwendet werden. Hier kommt eine Schritt-für-Schritt Anleitung.

Kernel-Update

Der normalerweise mit CentOS installierte Kernel verfügt nicht über das erforderliche atalk Kernelmodul. Dieses stellt das eigentliche Appletalk-Protokoll bereit. Ein Weg wäre, einen passenden Kernel aus den Quellen neu zu kompilieren. Dies ist aber aufwändig und fehleranfällig hinsichtlich der richtigen Konfiguration. Einfacher ist es, den Kernel aus dem CentOS Plus Repository zu installieren.

  1. Das CentOS Plus Repository nur für Kernel-Pakete eingefügen:
    • Hinzufügen an das Ende von /etc/yum.repos.d/CentOS-Base.repo:

      #additional packages that extend functionality of existing packages
      [centosplus]
      name=CentOS-$releasever - Plus
      mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus
      gpgcheck=1
      enabled=1
      gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-centos5
      includepkgs=kernel*
    • In der Sektion [base] hinzufügen:

      exclude=kernel kernel-devel kernel-PAE-*
    • In der Sektion [update] hinzufügen:

      exclude=kernel kernel-devel kernel-PAE-*
  2. Testen, ob das Hinzufügen auch geklappt hat:yum list updatesAusgabe ist dann:

    ...
    * centosplus: centos.intergenia.de
    ...
    centosplus | 1.9 kB
    ...
    Excluding Packages from CentOS-5 - Base
    Finished
    Excluding Packages from CentOS-5 - Updates
    Finished
    Reducing CentOS-5 - Plus to included packages only
    Finished
    ...
  3. Wurde das Repository korrekt eingebaut, startet ein yum update kernel* das Update. Hierbei wird der neue Kernel zusätzlich zum alten in die Grub-Konfiguration übernommen; geht etwas schief, kann immer noch der alte Kern gebootet werden.
  4. Nach einem Reboot steht das Appletalk-Protokoll bereit, ein modprobe appletalk als root sollte das Protokoll laden (lsmod zeigt die geladenen Module).

Netatalk-Installation

  1. Netatalk nutzt die Berkeley-DB und benätigt das Development-Paket. Vor der eigentlichen Installation muss diese also ergänzt werden:

    yum install db4-devel
  2. Die Quellen liegen auf Sourceforge und lassen sich z.B. mit WGET herunterladen:

    cd /tmp
    wget http://downloads.sourceforge.net/project/netatalk/netatalk/2.0.5/netatalk-2.0.5.tar.gz?use_mirror=kent
  3. Kompilieren und Installieren geht nach dem üblichen Muster:

    cd /usr/src
    tar -xvzf /tmp/netatalk-2.0.5.tar.gz
    cd netatalk*
    ./configure --enable-redhat --with-mutex="x86/gcc-assembly"
    make | tee /tmp/netatalk_make.log
    make install | tee /tmp/netatalk_make_install.log

    Dies sollte ohne Fehlermeldungen durchlaufen, dies kann man in den durch tee erzeugten Logdateien später nachlesen.

  4. Die Installation kopiert die Dateien nach /usr/local und die Konfigurationsdateien nach /usr/local/etc/netatalk, dort genügt anfangs eine minimale Konfiguration:afpd.conf:

    - -transall -uamlist uams_guest.so,uams_clrtxt.so,uams_dhx.so

    AppleVolumes.default:

    # die Tilde gibt die Home-Verzeichnisse der User frei !
    ~
    /var/share "Austausch"

    atalkd.conf:

    eth0 -phase 2 -net 0-65534 -addr 65280.59

  5. Nun lohnt sich der Start von Netatalk:

    /etc/init.d/atalk start

    Starting AppleTalk services:
    Starting atalkd: [ OK ]
    Registering myserver:Workstation: [ OK ]
    Registering myserver:netatalk: [ OK ]
    Starting cnid_metad: [ OK ]
    Starting afpd: [ OK ]

    Der Start der einzelnen Prozesse dauert ein wenig, also Geduld !

GnuPG und nicht eigensignierte Keys

Bei dem Versuch, manche Public Keys aus ASCII Dateien zu importieren, beschwert sich GnuPG direkt oder ein verwendetes Frontend (unter Windows z.B. WinPT aus der GPG4Win Suite) über eine fehlende Eigensignatur des Keys und verweigert den Import. In der Keyfile wird „0“ für die Anzahl der öffentlichen Schlüssel angezeigt.

Die Eigensignatur bezieht sich auf die Benutzer-ID innerhalb des Public Keys; genaues ist in der
Selfsign FAQ (deutsch) nachzulesen.

Um dennoch derartige Public Keys importieren zu können, hilft ein Eintrag in der GnuPG Konfigurationsdatei. Diese ist mit WinPT aus der Schlüsselverwaltung unter „Bearbeiten, Einstellungen, GnuPG-Optionen“ zu erreichen. Am Ende der Datei wird hinzugefügt:


allow-non-selfsigned-uid

Der Import funktioniert dann; allerdings sollten nur diejenigen Keys importiert werden, über deren Urheber wirklich Klarheit besteht.

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.

Linuxinstallation auf andere Maschinen übertragen

Ich stehe oft vor der Aufgabe, bestehende Linux-Installationen mit installierten Anwendungen auf andere Maschinen (Zielsystem) zu kopieren, die bestehende Maschine (Quellsystem) also sozusagen zu klonieren. Unter Linux ist das mit Bordmitteln und den jeweiligen Installationsmedien nicht schwierig.

Die nachfolgenden Pfade beziehen sich auf Red Hat / CentOS / Fedora, bei anderen Distributionen können Änderungen nötig sein

  1. Auf dem Quellsystem mittels tar ein Vollbackup erzeugen. Ich erzeuge immer eine Backup-Datei pro Verzeichnis in der Wurzel (also /). Hierbei dürfen die Verzeichnisse /proc, /sys, /boot und /mnt nicht gesichert werden, auf /tmp verzichte ich auch meistens. Am besten geht das so:tar -cvzpSlf archiv.tgz /verzeichnis

    Die so erzeugten Dateien brenne ich auf CDROM oder schiebe sie auf ein System im Netz, z.B. per FTP.
    Beachten sollte man aber:

    • Alle Anwendungen bzw. Daemons sollten beendet sein (stop über die Init-Scripts)
    • Es sollten keine Benutzer auf dem Quellsystem arbeiten.
  2. Das Zielsystem erhält mittels der Installationsmedien ersteinmal eine Minimalinstallation. Dabei verzichte ich i.d.R. auch auf eine grafische Oberfläche; meist klone ich so Applikationsserver ohne direkte Benutzer-Logins auf dem System. Die Partitionierung kann aber vom Quellsystem abweichen, auch andere Hardware-Ausstattung ist meist kein Problem.
  3. Unter /root lege ich ein Verzeichnis „orig“ an, dort hinein kopiere ich die Dateien:
    • /etc/fstab
    • /etc/mtab
    • /etc/modprobe.conf oder modules.conf
    • /etc/modprobe.d (mit cp-a)
    • /boot (als tar-Archiv)
  4. Dann entpacke ich nacheinander die Archive aus dem Backup des Quellsystems
  5. Anschliessend kopiere ich aus /ect gesicherten Dateien zurück.
  6. Hat man versehentlich doch /boot kopiert, muss man jetzt die oben erstellte Sicherung wieder entpacken
  7. Jetzt ist ein Neustart fällig, der eigentlich klappen sollte.
    Oft beschwert sich die Hardware-Erkennung (Red Hat kudzu) über veränderte Hardware, die Meldungen muss man eben abarbeiten. Sofern beim Backup des Quellsystems nicht alle Anwendungen gestoppt waren, können ebenfalls Fehlermeldungen auftreten. Bei 2.Reboot sollten diese aber nicht mehr erscheinen.

Wichtig ist: Diese Methode funktioniert nur, wenn man für die Minimalinstallation die gleiche Distribution und die gleiche Version benutzt, wie sie das Zielsystem besitzt.

Probleme kann es geben, wenn auch dem Quellsystem durch Anwendungsinstallationen Binaries oder Bibliotheken durch andere Versionen überschrieben wurden, die auf dem Zielsystem aufgrund anderer Hardware nicht „passen“. Meist klappt das Vorgehen aber ohne Probleme.

Auf diese Weise können auch Installationen in eine virtuelle Maschine umziehen.