Schlagwort-Archive: Archlinux

BitBastelei #76 (Part 2/2) Installation von Arch Linux

Die grundlegenden Schritte lassen sich auf https://wiki.archlinux.org/index.php/Beginners’_Guide/Installation finden.

Die Hintergründe warum ich installiere und was meine Ziele sind finden sich in Part 1.

Inhalt
======
00:13 Download
01:05 USB-Stick zur Installation vorbereiten
02:49 Dateiintegrität per md5sum prüfen
03:30 Boot von USB-Stick
05:20 Wenns nicht bootet: acpi=off
07:00 Internetzugang konfigurieren
08:37 Tastatur auf Deutsch umschalten
08:47 Partitionieren der Festplatte
12:21 Formatieren der Partitionen (1 swap/ext2)
13:14 Verschlüsseln einer Partition mit cryptsetup
16:28 Formatieren der Partitionen (2 btrfs)
17:30 Mounten der Partitionen
18:44 Mirrorliste
19:49 Installation des Grundsystems
21:18 Erstellen einer fstab
21:47 Wechsel ins neue System
22:07 Konfiguration: locale-gen, Sprache, Keymap, Zeitzone, Hostname
24:40 initrd für Verschlüsselung anpassen
26:04 Bootloader installieren & konfigurieren
28:20 Passwort setzen
28:44 Erster Start ins neue System
29:50 Netzwerk & Installation von SSH
30:29 Dienste per Systemd
31:18 Desktop Environments: KDE/GNOME/XFCE/LXDE
33:15 Softwareinstallation: Gruppen, Provider, Optionale Abhängigkeiten, Suche
36:06 AUR: Übersicht
37:37 AUR: Installation per Hand
40:45 AUR: Installation per yaourt
43:38 fstab: Kompression für btrfs
45:16 Anlegen eines Users
45:34 Installation eines Grafikservers
46:10 Start des LXDM
46:37 Netzwerkkonfiguration per NetworkManager
47:25 Deutsche Tastatur in der grafischen Oberfläche
47:53 Anpassen des Panels: Akkumonitor
48:20 Fazit

Ergänzungen:
============
02:19 – Korrektur: bs=4M – dd if=archlinux….iso of=/dev/sdx bs=4M
07:53 – Wenn bereits beim Booten ein Netzwerkkabel eingesteckt ist bezieht der Rechner bereits eine IP, dieser Schritt kann dann entfallen
08:29 – https://wiki.archlinux.org/index.php/Beginners’_Guide/Installation#Wireless
10:03 – https://wiki.archlinux.org/index.php/Beginners’_Guide/Installation#Using_cgdisk_to_create_GPT_partitions
11:40 – SWAP = Auslagerungsspeicher, Erweiterung des RAMs auf der Festplatte. Hiermit kann das System selten genutzte Daten des Arbeitsspeichers auf die Festplatte verschieben und so den schnelleren RAM zur Verfügung halten.
20:26 – https://wiki.archlinux.org/index.php/Grub#UEFI_systems_2
42:53 – …und ein RM, welches jedoch auch OK aussieht…
46:49 – Wenn man immer Netzwerk möchte sollte man den Dienst automatisch starten: “systemctl enable NetworkManager”

Hinweise:
=========
Nicht vergessen: Es gibt keine 100%ige Sicherheit. Da die Bootdateien hier zum Beispiel nicht verschlüsselt sind könnte ein Angreifer an dieser Stelle ansetzen und den Kernel infizieren. Erschweren kann man dieses vorgehen z.B. durch ein Bootloader-Passwort, einen modifizierten Bootloader für verschlüsselte Partitionen oder durch dsa Auslagern der Boot-Dateien auf einen USB-Stick. Auch kann man z.T. mit Kältespray und entsprechender Hardware das RAM auslesen und so den Verschlüsselungskey zusammensetzen. Ebenfalls bringt die Verschlüsselung nichts, wenn eine Applikationslücke genutzt wird.

Symantec Backup Exec (RALUS) auf Arch Linux

Symantec hat für ihr Produkt “Backup Exec” auch einen Agenten im Angebot, welcher die Sicherung von Linux- und Unix-Systemen ermöglichen soll. Dieser so genannte “Remote Agent for Linux and Unix Servers” aka RALUS hat leider eine sehr eingeschränkte Kompatibilitätsliste. Zwar gibt es im Netz einige Anleitungen für Debian, für Arch wurde ich aber nicht fündig. Nach ein paar Versuchen war mir die Herkunft der Paketbeschreibung eines Repos für CENTOS auch klar:

It is a crappy tool and you should seriously consider not using it.

Nicht nur, dass die Installationsdaten lediglich versteckt als deb und rpm vorliegen: Teile der Config werden über ein Wirrwarr an Perl-Scripten generiert und bei der Nutzung mit Kerneln >=3 muss man am Kernel oder im Binärcode herumpatchen. Great!

Nungut, inzwischen läuft der Daemon, ein passender PKGBUILD für die mir vorliegende Version (14.0.1798-0, 64 Bit) ist auf Github zu finden. Mit drin ist der Binärpatch für Kompatibilität mit Kernel 3.x sowie etwas Rechtefoo. Da das Ganze mehr eine Vorlage als funktionsfähiges PKGBUILD darstellt wandert’s erst mal nicht ins AUR.

ext4 vs. BTRFS – mal wieder

OK, ok, zugegeben, das Thema gibt’s zu Hauf im Netz, aber ich vertraue lieber eigenen Zahlen: Was ist schneller: ext4 oder btrfs? Hintergrund ist ein Backupzwischensystem, welches große Datenmengen schnell verarbeiten muss. Die Kompression von BTRFS wäre angesichts der Kosteneinsparung durch weniger Plattenverbrauch ein schöner Bonus, aber darf nicht auf Kosten der Geschwindigkeit gehen.

Das System ist ein “Low-End” Dualcore (Intel(R) Pentium(R) CPU G645 @ 2.90GHz) mit 16GB RAM und 4 Hitachi Deskstar 5K3000 á 2TB. Die Platten mit 5300rpm sehen zwar auf den ersten Blick etwas schwachbrüstig aus, da die Daten aber vermutlich sehr groß und entsprechend hoffentlich am Stück geschrieben werden sollte die geringe Drehzahl hoffentlich nicht wirklich ins Gewicht fallen. Das Mainboard (ASRock H77 Pro4/MVP) verfügt über zwei SATA-Controller – der Intel® H77 steuert neben 4 SATA2-Ports zusätzlich 2 Ports mit SATA3 bei, ein ASMedia ASM1061 stellt 2 zusächliche SATA3-Ports bereit. Die Platten wurden über die SATA3-Ports an beide Controller verteilt.

Die Tests liefen auf einem Arch Linux x86_64-System mit Kernel 3.11.2, als RAID kam das im Kernel enthaltene md-Framework zum Einsatz, auf die bei BTRFS integrierte RAID-Funktion verzichte ich, da ich separate Schichten für besser wartbar halte.

Erst einmal die rohen Werte der Platte: Diese lieferten im Test jeweils etwa 140MB/s sequential Read.

Erster Versuch: 1GB sequential Write, die Platten werden dabei erst mal als RAID5 genutzt, in der Hoffnung, dass die Geschwindigkeit noch ausreichend ist. Das Ergebnis ist etwas ernüchternd:

1GB Sequencial File Write
RAID5, EXT4 99MB/s
RAID5, BTRFS 134MB/s
RAID5, BTRFS (LZO) 144MB/s

BTRFS liegt zwar klar vor ext4 und auch die Kompression bringt auf Grund der gut komprimierbaren Quelle einen Geschwindigkeitsschub, insgesamt liegt die Leistung aber unter meinen Anforderungen – 144MB/s könnte die 2GBit/s Uplink grade so bewältigen, aber eigentlich hätte ich schon gerne noch etwas Reserve… Die Antwort dürfte klar sein: Da die Daten hier nur zwischengelagert werden bin ich auf das RAID5 nicht angewiesen, also RAID0 ftw – der erste Blick aufs rohe Device ist vielversprechend: 490MB/s sind ein guter Start – und was machen die Dateisysteme daraus?

RAID0, EXT4 349MB/s
RAID5, BTRFS 376MB/s
RAID5, BTRFS (LZO) 382MB/s

Viel ändert sich nicht – BTRFS mit Kompression erreicht gegenüber ext4 knapp 10% höhere Schreibraten. Die 380MB/s dürften erst bei etwa 4GBit/s uplink an ihre Grenzen stoßen – bis die fällig sind dürfte eher der Plattenplatz ausgehen. Sieger gefunden würde ich sagen: BTRFS schlägt ext4 sowohl bei Geschwindigkeit als auch beim Funktionsumfang – ob es auch die Stabilität der ext-Systeme nacheifern kann wird die Zeit zeigen.

Arch Linux: Mehrere X-Server, Systemd und VT-Switch

Die Migration auf Systemd hat noch immer ihre Nebenwirkungen auf meinem System: Ich verwende hauptsächlich ein Multimonitor-Setup auf meinem Rechner. Leider unterstützen nicht alle Anwendungen ein solches Konstrukt fehlerfrei, daher nutze ich von Zeit zu Zeit einen zweiten XOrg mit nur einem Monitor um die Software zu betreiben. Um diesen zu starten nutzte ich bisher den Befehl startx -- :1 -layout LayoutSingle. Über das übliche VT-Switch konnte ich ggf. zwischen den Serven wechseln, die Multimonitor-Lösung befand sich auf vt7 (Ctrl-Alt-F7) und der zweite Server mit nur einem Monitor auf vt8 (Ctrl-Alt-F8).

Nach der Migration auf Systemd war damit Schluss: Zwar startete der zweite X-Server normal und ich konnte ihn benutzen, habe ich ihn aber einmal auf eine andere Konsole verlassen gab es keine Möglichkeit mehr auf den Bildschirm zurück zu kommen. Zum Glück ist die Lösung recht einfach und offensichtlich (wenn man sie erst mal gefunden hat) – der Befehl zum Starten heißt nun startx -- :1 -layout LayoutSingle vt8

et-sdl-sound: Segfault – Patch

Der ET-spielenden Linux-Bevölkerung ist “et-sdl-sound” sicher ein Begriff: Dieser “Hack” erlaubt es über LD_PRELOAD das Spiel vom bisherigen “Open Sound System” (OSS) loszulösen und per SDL auch z.B. mit ALSA oder Pulse zu betreiben und somit die Sondausgabe auf aktuellen Distributionen zu ermöglichen. Leider haben die letzten Updates meines Arch Linux Systems gleich mehrere Fehler ausgelöst: Im ersten Schritt änderte sich (durch die /usr/bin-Migration?) die CRC der ET-Binary. Da über diese Prüfsumme der Hack das Spiel erkennt war keine Tonausgabe mehr möglich. Ein weiteres Problem stellt inzwischen wohl die Nutzung von stdout dar – warum auch immer, bei jeder Ausgabe verabschiedet sich das Spiel per Segfault.

Für beide Probleme habe ich nun eine aktualisierte Version in meinem Github-Repo – die CRC der Arch-Linux Version wurde ergänzt, der Code grob für neuere Compiler umgestellt und die Info-Ausgaben in die Datei /tmp/et-sdl-sound.log umgeleitet.

Updates für php-dio und fusecompress-1 @ AUR

Soderle, kleinen Frühjahrsputz für mein Archlinux veranstaltet: php-dio ist jetzt auf Version 0.0.7 – eigentlich unnötig, da offenbar nur Änderungen für Windows drin sind, aber hey, die Optik spielt ja auch eine Rolle. Zudem habe ich mich mal erbarmt und die C-Variante von Fusecompress auf die aktuelle Version gehoben bzw. einige Compile-Patches eingearbeitet – mal schauen, sollte die letzte Version endlich die FUSE-Abstürze auf meinem PC beheben adoptiere ich es eventuell dauerhaft, aber erst mal wird jetzt die neue Version mit meinem /home auf Herz und Nieren getestet…

Back to the Roots: Gnome 2 – Fork “MATE” auf Archlinux

Ja, Gnome3 ist toll – wenn man auf grafischen Schnickschnack steht. Zugegeben, auf Netbook und co nutze ich Gnome3 gerne, aber auf meinem PC zählen die Grafikeffekte nicht – im Gegenteil: Sie stören beim Arbeiten. Fehlende Panels, mangelnde Leistung und Probleme mit mehreren Monitoren haben mich seit dem Update nach über 10 Gnome-Jahren dazu gezwungen auf Fluxbox zu wechseln. Das läuft zwar schnell, aber die schonen Panels fehlen mir noch immer – doch jetzt naht Rettung! Mit dem Projekt “MATE” gibt es einen Gnome2-Fork, welcher einen Großteil der Funktionen der guten, alten 2er-Version auch auf aktuellen Systemen herstellen kann. Für Archlinux gibt es entsprechende AUR-Pakete, für Faule auch ein eigenes Repository. Fühlt man sich gleich wieder daheim…

Gentoo-Look & Feel für die Archlinux-Bash

Auch wenn Gentoo eigentlich mein Haputsystem ist: Auf Netbooks o.Ä. macht das ganze recht wenig Spaß, daher bin ich vor einiger Zeit über Archlinux gestolpert. Auch, wenn die Stabilität und Flexibilität nicht immer an meine Gentoo-Erfahrungen heran kommen, so kann man sich dank sehr großem Binärrepository und den einfach zu erstellenden PKGBUILDS (ähnlich ebuilds) schnell helfen.

Eins, was mir jedoch gewaltig auf den Keks ging war die Bash-Konfiguration: Viele der “Komfortfunktionen” wie Farbschemata, Historysuche o.Ä. sind unter Archlinux nicht vorhanden oder haben andere Tastenkombinationen – Abhilfe kann wie folgt erfolgen:

Als erstes muss die .bashrc dran glauben – hier sind die meisten Einstellungen drin. Am einfachsten geht das über das Paket aur/gentoo-bashrc, welches unter /usr/share/gentoo-bashrc/bashrc eine Kopie der Gentoo-Konfiguration anlegt. Nach Prüfung kann man diese Datei als persönliche Einstellungsdatei unter /home//.bashrc bzw. /root/.bashrc einspielen. Wichtig: Nicht die Systemweite Datei überschreiben – einerseits würde dies einige Archlinux-spezifische Einstellungen überschreiben und andererseits würde der Updater die Datei nicht mit z.B. neuen Bashcompletion-Einstellungen aktualisieren können.

Was fehlt ist der von mir häufig genutzte Schnellzugriff auf die Bash-History. Damit meine ich, dass wenn ich z.B. “ls” Tippe mit dem Tasten PgUp und PgDown durch die letzten Befehle, welche mit ls beginnen scrollen kann. Dies läuft über die Datei /etc/inputrc – diese habe ich vollständig durch das Gentoo-Pendant ersetzt:

Arch Linux Bug: “cron for user root job sys-hourly”-Mails

Durch einen Fehler in pacman kommt es seit einigen Wochen zu einem Fehler während der Arch Linux Systemupdates. Unter anderem wird ein Script zum synchronisieren der Systemuhr aus den stündlichen Cronjobs entfernt – dummerweise ist dann das Verzeichnis /etc/cron.hourly leer und Pacman hat die Angewohnheit leere Verzeichnisse zu löschen. Entsprechend kann Cron das Verzeichnis nicht mehr finden und quittiert das ganze stündlich mit einer Email “cron for user root job sys-hourly”.

Als Workarround reicht ein simples “mkdir /etc/cron.hourly” als root – die Rechte sollten mit root:root OK sein.

Auf in dunkle Zeiten – Softwaregesteuerte Helligkeitskontrolle unter X11

Mein Netbook ist ansich ja ein praktisches Teil: Klein und leicht genug um neben dem Fernsehen ein bisschen rumtippen zu können – leider gibt es einen großen Nachteil, der anscheinend inzwischen bei vielen Geräten modern ist: Selbst auf der niedrigsten Helligkeitsstufe lässt sich mit dem Display das halbe Zimmer beleuchten – an gemütliches Fernsehn ist angesichts dieses Scheinwerfers vor der Nase nicht zu denken. Inzwischen habe ich einen kleinen Workarround gefunden: Mit der Software “xbrightness” lässt sich die Helligkeit unter X11 auf Softwareebene verringern. Eine solche Softwarelösung führt zwar zu einem gewissen Kontrastverlust, für Web & Code ists jedoch noch erträglich.
Für Archlinux ist das Paket jetzt in AUR.