Quiet-Mode bei Pioneer BluRay-Laufwerk abschalten

Veröffentlicht am

Ich habe ein BluRay-Laufwerk von Pioneer, Modell BDR-209M. Beim Rippen von Audio-CDs, DVDs usw. ist das leider übelst langsam und meilenweit von den Angaben im Datenblatt entfernt.

Schuld daran ist der standardmäßig aktivierte “Quiet Mode”: Das Laufwerk geht davon aus, dass man Audio-CDs anhört und Filme ansieht und reduziert dann, um weniger Radau zu veranstalten, die Drehzahl. Im Internet wird das gelegentlich boshaft als “Rip Lock” bezeichnet.

Bei Festplatten gibt es das Automatic Acoustic Management (AAM), das das Kopfklackern auf Kosten der Geschwindigkeit reduziert. AAM kann man mit eject -x 0 /dev/sr0 oder hdparm -M 0 /dev/sr0 abschalten. Bei dem Pioneer-Laufwerk funktioniert das aber nicht.

Nächster Versuch: Für Windows gibt es von Pioneer ein Drive Utility, mit dem man u.a. den Quiet Mode dauerhaft abschalten kann. Der Installer funktioniert nicht unter Wine, ist aber zum Glück nur eine selbstentpackende ZIP-Datei. Nach dem Entpacken mit unzip erhält man, versteckt in einem Unter-Unter-Unterverzeichnis, die Datei “PioneerBDDriveUtility_BDR-211.exe”, die einwandfrei unter Wine funktioniert.

Kurze Zeit später fand ich heraus, dass es auch ohne Wine und ohne das Pioneer-Drive-Utility geht: Das Linux-Programm cdvdcontrol (bei Debian im Paket qpxtool) kann den “Quiet Mode” bei Pioneer-Laufwerken ebenfalls abschalten:

cdvdcontrol -d /dev/sr0 --pio-limit off --pio-quiet perf

 

Was cdvdcontrol nicht kann sind Firmware-Updates, da muss man doch mit Wine ran:

Das Firmware-Update von Pioneer runterladen, den Installer mit unzip entpacken, und dann auf der Kommandozeile als root(!) mit Wine die entpackte Datei Updater.exe starten.

Multiseat mit Debian

Veröffentlicht am

PCs sind seit geraumer Zeit so schnell, dass sie sich die meiste Zeit mit Nichtstun beschäftigen können. Es ist daher naheliegend, einen einzigen Computer für mehrere Benutzer an mehreren Arbeitsplätzen zu verwenden. So spart man außerdem Geld, Zeit, Platz und Nerven.

Was braucht’s?

Der PC braucht pro Arbeitsplatz eine eigene Grafikkarte, und natürlich jeweils Monitor, Tastatur und Maus. Ich gehe unten mal von zwei Arbeitsplätzen aus. Im Rechner stecken also zwei Grafikkarten, und es sind zwei Tastaturen und zwei Mäuse angesteckt.

Wie funktioniert’s?

Jede Grafikkarte wird fest einem Arbeitsplatz (“seat”) zugeordnet, genauso die Tastaturen und Mäuse. Die Soundkarte wird gemeinsam genutzt: Die Benutzer können sich so gegenseitig die Lautstärke verstellen, was je nach Charakter Vor- und Nachteil sein kann. USB-Geräte werden ebenfalls gemeinsam verwendet: USB-Sticks können von allen benutzt werden. Ebenso DVD-Brenner, Drucker usw.

Soundkarte gemeinsam nutzen

Normalerweise startet systemd für jeden Benutzer, der sich am Rechner anmeldet, eine eigene Pulseaudio-Instanz. Da nur eine Soundkarte im Rechner steckt kann das mit mehreren Nutzern nicht funktionieren.

Lösung: Nur eine einzige, systemweite Pulseaudio-Instanz verwenden.

  1. Das Starten der User-Instanzen abschalten:
    systemctl --global --now mask pulseaudio.service
    systemctl --global --now mask pulseaudio.socket
  2. Einen neuen systemd-Service für Pulseaudio erstellen. Dazu folgende Datei “/etc/systemd/system/pulseaudio.service” anlegen:
    Description=PulseAudio Sound System
    After=dbus.service
    [Service]
    Type=notify
    ExecStart=/usr/bin/pulseaudio --system --daemonize=no --realtime --disallow-module-loading=0 --disallow-exit --log-target=journal
    Restart=always[Install]
    WantedBy=multi-user.target
    WantedBy=sound.target
  3. Den neuen Pulseaudio-Service aktivieren: systemctl daemon-reload; systemctl --now enable pulseaudio.service
  4. Damit die Benutzern den neuen systemweiten Pulseaudio-Service nutzen dürfen müssen sie Mitglied in der Gruppe pulse-access sein. Hinzufügen eines einzelnen Benutzers  geht so: adduser <username> pulse-access

Grafikkarte, Tastatur und Maus den Arbeitsplätzen zuordnen

Ein normales Linux-System kennt bereits das Konzept mehrerer Arbeitsplätze pro Rechner – standardmäßig werden nur alle Geräte dem “seat0” zugewiesen: Stecken zwei Mäuse am Rechner, steuern beide den gleichen Mauszeiger.

# loginctl list-seats

SEAT 
seat0

Die dem seat0 zugeteilten Geräte – aktuell sind das alle – kann man mit loginctl seat-status seat0 anzeigen lassen:

seat0
         Devices:
                  ├─/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
                  │ input:input6 "Power Button"
                  ├─/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input5
                  │ input:input5 "Power Button"
[...]
                  ├─/sys/devices/pci0000:00/0000:00:03.1/0000:08:00.0/drm/card0
                  │ [MASTER] drm:card0
                  │ ├─/sys/devices/pci0000:00/0000:00:03.1/0000:08:00.0/drm/card0/card0-DP-1
                  │ │ [MASTER] drm:card0-DP-1
                  │ ├─/sys/devices/pci0000:00/0000:00:03.1/0000:08:00.0/drm/card0/card0-DVI-D-1
                  │ │ [MASTER] drm:card0-DVI-D-1
                  │ └─/sys/devices/pci0000:00/0000:00:03.1/0000:08:00.0/drm/card0/card0-HDMI-A-1
                  │   [MASTER] drm:card0-HDMI-A-1
                  ├─/sys/devices/pci0000:00/0000:00:03.1/0000:08:00.0/drm/renderD128
                  │ drm:renderD128
                  ├─/sys/devices/pci0000:00/0000:00:03.1/0000:08:00.0/graphics/fb0
                  │ [MASTER] graphics:fb0 "amdgpudrmfb"
                  ├─/sys/devices/pci0000:00/0000:00:03.1/0000:08:00.1/sound/card0
[...]
                  ├─/sys/devices/pci0000:00/0000:00:03.2/0000:09:00.0/drm/card1
                  │ [MASTER] drm:card1
                  │ ├─/sys/devices/pci0000:00/0000:00:03.2/0000:09:00.0/drm/card1/card1-DP-2
                  │ │ [MASTER] drm:card1-DP-2
                  │ ├─/sys/devices/pci0000:00/0000:00:03.2/0000:09:00.0/drm/card1/card1-DP-3
                  │ │ [MASTER] drm:card1-DP-3
                  │ ├─/sys/devices/pci0000:00/0000:00:03.2/0000:09:00.0/drm/card1/card1-DVI-D-2
                  │ │ [MASTER] drm:card1-DVI-D-2
                  │ ├─/sys/devices/pci0000:00/0000:00:03.2/0000:09:00.0/drm/card1/card1-HDMI-A-2
                  │ │ [MASTER] drm:card1-HDMI-A-2
                  │ └─/sys/devices/pci0000:00/0000:00:03.2/0000:09:00.0/drm/card1/card1-HDMI-A-3
                  │   [MASTER] drm:card1-HDMI-A-3
                  ├─/sys/devices/pci0000:00/0000:00:03.2/0000:09:00.0/drm/renderD129
                  │ drm:renderD129
                  ├─/sys/devices/pci0000:00/0000:00:03.2/0000:09:00.0/graphics/fb1
                  │ [MASTER] graphics:fb1 "amdgpudrmfb"
[...]
                  ├─/sys/devices/pci0000:00/0000:00:07.1/0000:0a:00.3/usb5
                  │ usb:usb5
                  │ └─/sys/devices/pci0000:00/0000:00:07.1/0000:0a:00.3/usb5/5-2
                  │   usb:5-2
                  │   ├─/sys/devices/pci0000:00/0000:00:07.1/0000:0a:00.3/usb5/5-2/5-2.1/5-2.1:1.0/0003:0557:2213.0002/input/input1
                  │   │ input:input1 "ATEN Advance Tech Inc. KVM V1.2.116"
                  │   └─/sys/devices/pci0000:00/0000:00:07.1/0000:0a:00.3/usb5/5-2/5-2.1/5-2.1:1.1/0003:0557:2213.0004/input/input3
                  │     input:input3 "ATEN Advance Tech Inc. KVM V1.2.116"
                  └─/sys/devices/pci0000:00/0000:00:07.1/0000:0a:00.3/usb6
                    usb:usb6
[...]

Man muss also nur die Geräte, die dem zweiten Arbeitsplatz gehören sollen, einem anderen Seat, z.B. “seat-anna”, zuteilen. Das sollte eine Grafikkarte (endet mit …/drm/cardN) sein:

loginctl attach seat-anna /sys/devices/pci0000:00/0000:00:03.1/0000:08:00.0/drm/card0

Und Annas Tastatur und Maus:

loginctl attach seat-anna /sys/devices/pci0000:00/0000:00:07.1/0000:0a:00.3/usb5/5-2/5-2.1/5-2.1:1.0/0003:0557:2213.0002/input/input1
loginctl attach seat-anna /sys/devices/pci0000:00/0000:00:07.1/0000:0a:00.3/usb5/5-2/5-2.1/5-2.1:1.1/0003:0557:2213.0004/input/input3

Wenn man will kann man auch ganze USB-Hubs einem Benutzer zuteilen. Alles, was daran angeschlossen wird, gehört dann ausschließlich diesem Benutzer. Da Annas Eingabegeräte beide an “usb5” hängen würde statt der obigen zwei Befehle auch das hier funktionieren:

loginctl attach seat-anna /sys/devices/pci0000:00/0000:00:07.1/0000:0a:00.3/usb5

loginctl baut udev-Regeln und speichert diese unter “/etc/udev/rules.d/77-seat-<device>.rules”. Der Name des Seats wird als Tag zu den Geräten hinzugefügt. Mit loginctl flush-devices kann man sämtliche Zuordnungen wieder aufheben.

Xorg-Minimalkonfiguration

Eigentlich könnte man hier jetzt schon fertig sein: Die Geräte sind zugeordnet, Sound gibt’s auch, was will man mehr? Nur: Bei mir hat es so noch nicht funktioniert. Ganz gleich ob ich sddm, lightdm oder xdm als Display Manager verwendet hab und mit welchen Optionen ich dort Xorg starten lies: Entweder waren Geräte waren falsch zugeordnet, sämtliche Bildschirme blieb schwarz oder der Anmeldedialog wurde nur auf einem Bildschirm angezeigt. Letztendlich musste ich für jeden Arbeitsplatz eine eigene kleine Konfigurationsdatei anlegen, in der ich jeder Xorg-Instanz nochmal die richtige Grafikkarte  anhand der PCI-ID und den Seatnamen mitgeteilt habe.

Hier, für seat-anna, /etc/X11/xorg_seat-anna.conf:

Section "ServerLayout"
    Identifier  "seat-anna"
    Screen    0 "Screen1"             0 0
EndSection
Section "ServerFlags"
    Option      "AutoAddGPU"          "off"
    Option      "AllowMouseOpenFail"  "true"
EndSection
Section "Device"
    Identifier  "Videocard1"
    BusID       "PCI:08:00:0"
    Option      "ProbeAllGpus"        "false"
EndSection
Section "Screen"
    Identifier  "Screen1"
    Device      "Videocard1"
EndSection

Und für seat0 die Datei /etc/X11/xorg_seat0.conf – die Unterschiede zwischen den beiden Dateien sind rot markiert:

Section "ServerLayout"
    Identifier  "seat0"
    Screen    0 "Screen1"             0 0
EndSection
Section "ServerFlags"
    Option      "AutoAddGPU"          "off"
    Option      "AllowMouseOpenFail"  "true"
EndSection
Section "Device"
    Identifier  "Videocard1"
    BusID       "PCI:09:00:0"
    Option      "ProbeAllGpus"        "false"
EndSection
Section "Screen"
    Identifier  "Screen1"
    Device      "Videocard1"
EndSection

Die BusID kann man z.B. aus der loginctl-Ausgabe rauslesen:

loginctl seat-status seat-anna

         Devices:
                  ├─/sys/devices/pci0000:00/0000:00:03.1/0000:08:00.0/drm/card0
                  │ [MASTER] drm:card0
                  │ ├─/sys/devices/pci0000:00/0000:00:03.1/0000:08:00.0/drm/card0/card0-DP-1
                  │ │ [MASTER] drm:card0-DP-1
[...]

Die PCI-ID ist das, was direkt vor “drm” steht, hier also “0000:08:00.0”. Xorg erwartet das in einer etwas anderen Schreibweise: “0000” durch “PCI” ersetzen, den Punkt durch einen Doppelpunkt – so wird aus “0000:08:00.0” ein “PCI:08:00:0”

Die beiden Xorg-Konfigurationsdateien müssen jetzt noch in den Display Manager eingetragen werden: Der Display Manager zeigt den grafischen Anmeldedialog an, und das soll natürlich auf beiden Bildschirmen passieren, mit korrekt zugeordneter Maus und Tastatur.

Nach einigem Ausprobieren hat sich lightdm als der am besten geeignete Display Manager herausgestellt. Mit sddm dagegen ging es gar nicht.

Bei lightdm muss lediglich für die einzelnen Seats ein Xorg-Startbefehl am Ende der /etc/lightdm/lightdm.conf eingetragen werden:

[Seat:seat0]
xserver-command=/usr/lib/xorg/Xorg :0 -isolateDevice PCI:9:0:0 -config xorg_seat0.conf -sharevts -keeptty
[Seat:seat-anna]
xserver-command=/usr/lib/xorg/Xorg :1 -isolateDevice PCI:8:0:0 -config xorg_seat-anna.conf -sharevts -keeptty

Damit ist das Gröbste erledigt, das Anmelden sollte jetzt an beiden Arbeitsplätzen gelingen.

Feinschliff

Damit angestöpselte USB-Geräte von allen Arbeitsplätzen aus verwendet werden können (sofern der angemeldete Benutzer Mitglied der Gruppe “plugdev” ist) folgende Datei anlegen:

/etc/polkit-1/localauthority/50-local.d/20-org.freedesktop.udisks2.pkla

[Storage Permissions]
Identity=unix-group:plugdev
Action=org.freedesktop.udisks2.*;org.blueman.*;org.freedesktop.pulseaudio;org.gtk.vfs.file-operations
ResultAny=yes
ResultInactive=yes
ResultActive=yes

Damit von allen Arbeitsplätzen aus der Rechner heruntergefahren werden kann (sofern der angemeldete Benutzer Mitglied der Gruppe “powerdev” ist):

/etc/polkit-1/localauthority/50-local.d/10-org.freedesktop.upower.pkla

[Suspend/hibernate permissions]
Identity=unix-group:powerdev
Action=org.freedesktop.upower.*
ResultAny=yes
ResultInactive=yes
ResultActive=yes

Das war’s.

CF-Karten als IDE- und SCSI-Festplattenersatz

Veröffentlicht am

IDE, SCSI – ja, es geht offensichtlich um alte Computer. Solche mit kleinen, langsamen und altersschwachen Festplatten.

Eine Festplatte kann ziemlich einfach durch eine CF-Karte ersetzt werden. CF-Karten punkten mit kurzen Zugriffszeiten, Datenraten von um die 40 MByte/s, und mit einem USB-Kartenleser kann bequem und schnell eine Backup-Image erstellt/zurückgespielt werden.

CF-IDE-Adapter

Im Gegensatz zu gängigen SSDs sind CF-Karten sind IDE-kompatibel. Um eine CF-Karte an einen IDE-Controller anzuschließen braucht man nur einen billigen Adapter, der die Pins vom IDE-Kabel an die CF-Karte weiterleitet. Der Stromanschluss auf dem Adapter dient nur zur Stromversorgung der CF-Karte. Am praktischsten sind Slotblech-Adapter, weil man zum Wechseln der CF-Karte den Rechner nur ausschalten, aber nicht aufschrauben muss.

IDE und seine Tücken

Der IDE-Standard wurde im Laufe der Zeit immer wieder überarbeitet, hauptsächlich um mit der schnell wachsenden Kapazität der Festplatten und mitzuhalten, mehr Geräte zu unterstützen und höhere Übertragungsraten zu erreichen.

Größenbeschränkungen

Es gilt daher: Je älter der Computer, desto kleiner ist die maximal nutzbare Festplattengröße.

Die “magischen” Grenzen (528 MByte, 2.1 GByte, 8 GByte usw. ) sind samt Ursache hier beschrieben: https://www.tldp.org/HOWTO/Large-Disk-HOWTO-4.html

Wenn man unbedingt will kann man die Grenzen überwinden: Wird die Festplatte/CF-Karte zumindest erkannt, aber nur mit zu kleiner Kapazität, hilft oft eine Drive-Overlay-Software wie Ontrack Disk Manager oder EZ-Drive von Micro House/Western Digital.

Das XTIDE Universal BIOS dagegen ersetzt gleich die sämtliche Festplattenroutinen im Original-BIOS und funktioniert sehr zuverlässig, muss jedoch in ein ROM gebrannt werden, das dann z.B. im Netzwerkkarten-Boot-ROM-Sockel den Weg in den Rechner findet.

Removable oder fixed?

Je neuer der Computer, desto eher muss man darauf achten, dass sich die CF-Karte als “fixed Disk” meldet. Dummerweise melden sich die meisten als “removable”. Da hilft nur das Datenblatt vom Hersteller. Hier das Datenblatt für die “Industrial”-CF220-Karten-Reihe von Transcend: https://cdn.transcend-info.com/products/images/modelpic/701/No3147_20150916_Datasheet_CF220I%20v1.2.pdf

Die Karten melden sich als “fixed Disk” (“True IDE Mode: Fixed Disk (Default)”).

Im Internet werden gelegentlich Tools genannt, mit denen man CF-Karten von “removable” auf “fixed” umstellen könnte. Mir ist das mit keiner einzigen CF-Karte gelungen.

Zylinder, Sektoren und Köpfe

Die “C.H.S.-Table” auf Seite 2 des Datenblatts braucht man, um bei Computern, die noch keine IDE-Autodetection können (z.B. 386er), im BIOS die richtige Anzahl von Köpfen, Sektoren und Zylindern eintragen zu können. Stehen die Werte nicht im Datenblatt, dann kann man die CF-Karte einfach in einen USB-Kartenleser stecken und sich unter Linux mit fdisk -c=dos -u=cylinders -l /dev/sdX anzeigen lassen.

Ich hatte mal den Fall, dass eine CF-Karte nach der Verwendung in einem Rechner mit LBA-Adressierung nicht mehr von einem Rechner mit CHS-Adressierung erkannt wurde.

“Reparieren” konnte ich diese Karte dadurch, indem ich sie wieder in den Rechner mit LBA-Adressierung einsteckte, in dessen BIOS die Adressierung von “AUTO/LBA” auf “Normal” stellte und dann die CF-Karte neu partitionierte.

Wenn man die richtigen CHS-Werte kennt geht es aber auch einfacher: fdisk -c=dos -u=cylinders /dev/sdX Dann x, mit c Zylinder ändern, mit h die Heads und mit s die Sektoren/Track. Beenden und Speichern mit r, w, q

Bei echten Festplatten sind die “Heads” übrigens die Anzahl der verwendeten Platter-Seiten (Platter sind die Scheiben in einer Festplatte, auf die die Daten gespeichert werden).  “Cylinders” ist die Anzahl der ringförmigen Spuren auf einer Platterseite, von denen jede nochmals in “Sektors” aufgeteilt wird.

SCSI-zu-IDE-zu-CF

Mit einem IDE-zu-SCSI-Konverter (auch als SCSI-Bridge bezeichnet) können IDE-Geräte an einem SCSI-Controller betrieben werden – und das IDE-Gerät kann dabei auch ein CF-IDE-Adapter sein.

SCSI-Bridges kosten um die 100€ und sind somit ziemlich teuer. Ich habe einige von Acard, die funktionieren problemlos.

Abraten möchte ich von den Konvertern, die Yamaha in den 2000ern benutzte um aus IDE-CD-Brennern SCSI-CD-Brenner zu machen (Modellbezeichnung: Yamaha V769970): Sie funktionieren nicht mit allen CF-Karten, unterstützt nur asynchronen Datentransfer und kommen damit höchstens auf 5 MByte/s.

Wenn eine SCSI-Bridge verwendet wird ist es egal ob sich die CF-Karte als “removable” oder “fixed” meldet: Sämtliche CF-Karten, auch egal welcher Größe, werden als korrekt als normale SCSI-Festplatte erkannt. Nur manche SCSI-Controller aus der Computersteinzeit haben Schwierigkeiten mit Kapazitäten größer 1 oder 2 GByte.

 

Fazit

Top! Allein schon das einfache Wechseln und Sichern/Wiederherstellen der CF-Karten ist Gold wert. Die im Vergleich zu Festplatten höhere Geschwindigkeit spielt beim Einsatz in alten Computern keine große Rolle, die sind so oder so langsam.

Um die oben beschriebenen BIOS-bedingten Größenbeschränkungen zu umgehen verwende ich meist einen SCSI-Controller, an den ich per IDE-zu-SCSI-Konverter ein CF-Kartenadapter-Slotblech angeschlossen habe. Man mag es kaum glauben, aber das funktioniert absolut stabil und problemlos.

Seltener benutze ich das XTIDE Universal BIOS. Es funktioniert auch problemlos und stabil, nur ist SCSI halt immer besser als IDE :)

Synology HyperBackup mit rsync

Veröffentlicht am

RAID ist kein Ersatz für ein Backup, darum sind NAS-Geräte von Synology sinnvollerweise ab Werk mit einem Backup-Program ausgestattet.

Dieses Backup-Programm trägt den wenig bescheidenen Namen “HyperBackup“. Bei manchen DMS-Versionen ist es vorinstalliert, bei anderen muss es offenbar als “App” nachinstalliert werden.

HyperBackup kann die Daten vom NAS zeitgesteuert irgendwo hin kopieren. Wie es sich gehört werden dabei nur die Änderungen zum letzten Backup übertragen. Außerdem kann man nicht nur die letzte sondern auch alle vorherigen Dateiversion wiederherstellen. Als Backup-Medium werden allerlei kommerzielle Dienste von Amazon über Google zu Microsoft angeboten. Wer keine Lust hat seine Daten auf fremde Server zu schieben kann einen USB-Stick (wenig praktikabel) oder einen rsync-Server verwenden.

Die Doku von Synology ist zu rsync etwas dürftig, ein bisschen rumprobieren verrät dann, dass HyperBackup ganz normal rsync über ssh zum Zielsystem tunnelt (à la rsync -e ssh <quelle> <ziel>).

Auf dem Zielsystem muss kein rsync-Dämon laufen. Die rsync-Ports können geschlossen bleiben, nur der ssh-port (22, tcp+udp) muss geöffnet sein.

HyperBackup verwendet keine Verzeichnisangabe für das Ziel, sondern den Namen eines sog. Backup-Moduls. Backup-Module werden auf dem Zielsystem unter /etc/rsyncd.conf eingetragen:

charset: utf-8
[backup-von-synology]
   path = /data/hyperbackup-backup
   comment = Backup von Synology NAS
   use chroot = true
   uid = root
   gid = root
   read only = false

Hier wird ein rsync-Backup-Modul namens “backup-von-synology” erstellt, bei dessen Verwendung ins Verzeichnis “/data/hyperbackup-backup” gesichert wird.

Nur noch schnell auf dem Zielsystem einen Benutzer anlegen und ihm Schreibrecht auf den Backup-Pfad geben, fertig.

 

Sollte das Zielsystem ein Netgear ReadyNAS sein, kann man sich die Konfiguration einfach in dessen Weboberfläche zusammenklicken:

  1. Neuen User anlegen und SSH-Shell-Zugriff erlauben
  2. Share anlegen (Name des Shares = rsync-Modulname)
  3. Dem neuen User Schreibrechte auf den neuen Share geben
  4. Den Share außerdem für Rsync  (lesen+schreiben, keine Benutzerrestriktionen) freigeben

Auf Snapshots kann verzichtet werden, die macht HyperBackup selbst.

 

Einstellungen in HyperBackup:

Servertyp: rsync-kompatibler-server

Servername oder IP-Adresse: <Servername>

Übertragungsverschlüsselung: Ein

Port: 22

Benutzername: <benutzernameAufZielsystem>

Passwort: <passwortDesBenutzers>

Backupmodul: backup-von-synology

Verzeichnis: Synology-Backup (wird dann unterhalb des Backup-Modul-Verzeichnisses automatisch angelegt, kann auch leer gelassen werden)

 

Debian Linux auf IBM RS/6000 44P-170

Veröffentlicht am

Die IBM 44P-170 ist eine Low-End-Unix-Workstation aus den 2000ern, die vor allem für CAD eingesetzt wurde. Damaliger Listenpreis: stolze 30.000 USD.

Hardware

Der Prozessor, ein IBM POWER3-II, ist auf einer Steckkarte untergebracht, die sich beim Transport gerne lockert. Der Rechner bleibt dann beim Hochfahren (was gut und gerne bis zum Erscheinen des OpenFirmware-Bildschirms 5 Minuten dauert) mit “E0…” im 7-Segment-Display stehen.

In Linux 3.17 wurde die Unterstützung für diesen Prozessortyp entfernt – nachdem sie schon einige Versionen davor nicht mehr funktioniert hat.

Den Rechner gab es mit verschiedenen Grafikkarten: GXT3000P, GXT4000P, GXT4500P, GXT6000P und GXT6500P. Linux-Kernel vor Linux 3.8 unterstützen davon nur GXT4500P und die GXT6000P. In Linux 3.9 kam Unterstützung für GXT4000P und GXT6500P dazu, der Patch funktioniert jedoch auch mit älteren Kernel-Versionen. 3D-Beschleunigung darf man nicht erwarten, es wird nur der Framebuffer-Modus unterstützt.

Sowohl unter AIX als auch unter Linux startet der Rechner mit diesen Grafikkarten mit einer Auflösung von 1280×1024@60Hz.

IBM hatte außerdem einige umgelabelte Grafikkarten von anderen Herstellern im Angebot, die von AIX und Linux unterstützt werden: GXT2000P (3D Labs Permedia 2), GXT110P (S3 Trio64V+), GXT120P (Matrox Millenium I), GXT130P (Matrox Millenium II) und GXT135P (Matrox G450).

Debian-Installation

Die Linux-Installation mit einer nicht unterstützten Grafikkarte ist möglich, nur etwas umständlicher: Man kann sich mit einen zweiten Rechner über die serielle Schnittstelle mit der 44P-170 verbinden. Ich habe das nicht ausprobiert, sondern mir für etwa 15€ eine GXT135P besorgt.

Sobald man weiß, welches CD-Image bootet und ob die aktuelle Grafikkarte von jeweiligen Kernel unterstützt wird, ist die Debian-Installation einfach:

Von Debian 6 zu 7 zu 8 zu 9

Die letzte funktionsfähige Debian-CD ist das Netinst-Image von Debian 6: https://cdimage.debian.org/mirror/cdimage/archive/6.0.10/powerpc/iso-cd/debian-6.0.10-powerpc-netinst.iso

Runterladen, auf CD brennen, booten.

Beim Bootprompt “install64” wählen.  Während der unspektakulär verlaufenden Installation als Spiegelserver “archive.debian.org” eintragen und als Bootloader “yaboot” auswählen. Debian 6 installiert Kernel 2.6.32.

Danach auf Debian 7 upgraden: Dazu in /etc/apt/sources.list die Quellen von “squeeze” durch die von “wheezy” ersetzen, apt-get update && apt-get dist-upgrade. Debian 7 installiert Kernel 3.2.

Weiter zu Debian 8 – der letzte Debian-Version offizieller PowerPC64-Unterstützung: In /etc/apt/sources.list die Quellen von “wheezy” durch die von “jessie” ersetzen, apt-get update && apt-get dist-upgrade. Debian 8 installiert Kernel 3.9. Achtung: Dieser Kernel hängt beim Booten mit SCSI-Resets und ist damit unbrauchbar. Am Besten gleich wieder deinstallieren! Der alte Kernel 3.2 von Debian 7 funktioniert jedoch auch unter Debian 8.

Trotz Einstellung des offiziellen Debian-PowerPC64-Zweiges gibt es noch neue Debian-Pakete in Debian 9 (“stretch”), nur nicht mehr in “stable”, sondern nur noch in “unstable”.

Eigener Kernel

Da meine Workstation ursprünglich mit einer GXT4000P kam, habe ich mir selbst einen Kernel kompiliert aus den Quellen des Kernel 3.2 von Debian 7, ergänzt um den GXT4000P/6500P-Support-Patch. Hier das Kernel-Paket: linux-image-3.2.78_1.0.geierb~ppc64gxt_powerpc.deb

Yaboot

Beim Booten sucht die OpenFirmware auf der Festplatte nach einer PReP-Bootpartition (die wird bei der Debian-Installation automatisch angelegt) und startet, was auch immer da drin liegt.

Yaboot legt dort ein anhand von /etc/yaboot.conf konfiguriertes Binary ab, das ein simples Menü anzeigt, Kernel und Ramdisk aus /boot lädt und startet.

Die Datei /etc/yaboot.conf erinnert ein wenig an die GRUB-Konfigurationsdatei und ist größtenteils selbsterklärend. Man kann Kernelparameter eintragen, Kernelimage und initrd, usw.

Wenn /etc/yaboot.conf geändert wurde , muss ein neues Binary in die PReP-Bootpartition geschrieben werden. Dazu einfach den Befehl ybin -v ausführen.

Um den Kernel laden zu können muss yaboot das Dateisystem verstehen, auf dem /boot liegt. Man hat die Wahl zwischen ext2, ext3 und ext4.

Was nicht geht

Sound. Sound geht nicht. Auf dem Mainboard ist ein Crystal CS4236B-Soundchip verbaut, der per ISA-Bridge angebunden ist. Der PowerPC64-Kernel unterstützt leider kein ISA – auch nicht, wenn man die Unterstützung per Patch reinzwingt und die richtigen Modul-Parameter für den Soundchip kennt (port=0x534, cport=0x538, irq=5, mpu_port=0x330, mpu_irq=9, fm_port=0x388, dma1=1, dma2=3). Ich habe es nicht geschafft, den Rechner mit einem 32-Bit-Kernel zu starten. Der könnte mit ISA umgehen.

Als Abhilfe bietet sich eine PCI-Soundkarte mit Crystal CS4281-Chip an. IBM verkaufte diese für die Intellistation-Workstations als “IBM 8244 AudioPCI”. Die funktioniert sowohl unter AIX als auch Linux.

Fazit

Wenn man weiß wie es geht ist es einfach, der Weg dahin jedoch ziemlich steinig. Steinig im Sinne von zeitaufwändig: Die lange Boot-Dauer macht das Ausprobieren ziemlich nervig.