Schlagwort-Archive: Archlinux

BitBastelei

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

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

(85 MB) 00:49:04

2013-12-29 11:00 🛈

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.

Software

Symantec Backup Exec (RALUS) auf Arch Linux

Schreibe einen Kommentar

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.

Software

ext4 vs. BTRFS – mal wieder

2 Kommentare

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.

Software

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

Schreibe einen Kommentar

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

Software

et-sdl-sound: Segfault – Patch

Schreibe einen Kommentar

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.

Software

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

Schreibe einen Kommentar

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…