Warning: file_put_contents(): Only 0 of 10 bytes written, possibly out of free disk space in /var/web/h/heller.christian/htdocs/www.plomlompom.de/PlomWiki/plomwiki.php on line 287
ArchLinuxEeePC
PlomWiki: Zur Start-Seite Suche Letzte Änderungen (Feed) Letzte Kommentare (Feed)
Impressum Datenschutz-Erklärung

ArchLinuxEeePC

Ansicht Bearbeiten Anzeige-Titel setzen Versions-Geschichte Seiten-Passwort setzen AutoLink-Anzeige ein-/ausschalten

Notizen zu meinem Versuch, Arch Linux auf meinem Asus Eee PC 1015P zu installieren.

Via USB-Stick booten

Ich brannte mit ...

$ dd if=archlinux-2010.05-core-x86_64.iso of=/dev/sdb 

... das Installations-Image auf meinen USB-Stick. Beachte: das x86_64-iso, der Intel-Atom-CPU-N450-Prozessor des 1015P soll nämlich 64-bittig sein.

Um das BIOS zum USB-Booten zu bringen, muss unter "Boot" -> "Boot Settings" -> "Hard Disk Drives" ein erkanntes USB-Device (das gar keine Hard Disk sein, nur als solche dem BIOS erscheinen muss) als "1st Drive" markiert werden; dann klappt's auch, ebendieses als "1st Boot Device" unter "Boot" -> "Boot Settings" -> "Boot Device Priority" einzustellen.

Diverse Hinweise, man müsse unter "Boot" den "Boot Booster" disablen, damit das Booten via USB klappt, erübrigen sich so, denn auf meinem USB-Stick findet das BIOS gar keine Boot-Booster-Cache-Partition. Beachte, möglicherweise verwirrend: Die Boot-Booster (und auch die Express-Gate)-Enable/Disable-Funktion erscheint/verschwindet nicht unmittelbar nach Umstellen der "Hard Disk Drives"-Reihenfolge, sondern erst beim nächsten Reboot; offenbar schaut sich das BIOS vor Anzeige des "BIOS Setup Utility" um, ob es entsprechende Partitionen auf der voreingestellten ersten Festplatte findet.

Ärger mit der voreingestellten EFI-Partition

Ich folgte gemütlich den einfachen Anweisungen unter https://wiki.archlinux.org/index.php/Beginners'_Guide -- bis zum Partitionieren. Da wählte ich die Von-Hand-Variante und bekam als Belohnung folgende Fehlermeldung:

FATAL ERROR: Bad primary partition 3: Partition ends in the final partial cylinder 
                           Press any key to exit cfdisk 

Ein kurzer Blick mit fdisk in die Partitionstabelle offenbarte folgenden merkwürdigen ("Windows 7 Starter" war vorinstalliert) Auslieferungszustand (von Hand abgetippt, vielleicht nicht ganz korrekt):

[root@archiso ~]# fdisk /dev/sda 
 
[...] 
 
Command (m for help): p 
 
Disk /dev/sda: 160.0 GB, 160041885696 bytes 
255 heads, 63 sectors/track, 19457 cylinders 
Units = cylinders of 16065 * 512 = 8225280 bytes 
Sector size (logical/physical): 512 bytes / 512 bytes 
I/O size (minimum/optimal): 512 bytes / 512 bytes 
Disk identifier: 0x0dafeed1 
 
   Device Boot      Start         End      Blocks   Id  System 
/dev/sda1   *           1       10444    83887104    7  HPFS/NTFS 
/dev/sda2           10444       12402    15728640   1b  Hidden W95 FAT32 
/dev/sda3           12402       19455    56652800    7  HPFS/NTFS 
/dev/sda4           19455       19458       21336   ef  EFI (FAT-12/16/32) 

Das, was hier unter sda4 firmiert, mit seinem spezifischen Partitionstyp und seiner spezifischen ID, wird im Netz gern als Cache für des EeePC's "Boot Booster" gezählt. Und tatsächlich, nachdem ich sie mit fdisk löschte (was auch cfdisk wieder arbeitswillig machte), wollte das BIOS keinen Einstellpunkt zu "Boot Booster" (und auch keinen "Express Gate") mehr anzeigen, selbst wenn ich bei einem vorhergehenden Boot des EeePC's Festplatte als erste Festplatte zurückeingestellt hatte. Eine Partition besagten Typs ließ sich mit fdisk auch wieder neu anlegen, was das BIOS auch wieder "Boot Booster" und "Express Gate" hervorholen ließ; fdisk schlug allerdings eine neue, geringere Größe als mögliches Maximum vor, die in folgender Zeile resultierte:

/dev/sda4           19455       19457       18784+  ef  EFI (FAT-12/16/32) 

Hiermit kam cfdisk nun sogar klar. Sollte der 1015P ab Werk mit einer unnötig kaputten Partitionstabelle ausgeliefert werden?

Partitionieren, dateisystemen

Hab dann mal getestet, ob "Boot Booster" beim vorinstallierten Windows messbare Geschwindigkeitserhöhung bringe; mir ist nichts Substanzielles aufgefallen. Also weg mit dieser Partition wie mit allen anderen: Ich werde meinen 1015P ganz Linux weihen! Mein Partitionsschema, im Groben: 2 Gigabyte Swap-Partition (der alten Regel folgend, doppelt soviel Swap wie RAM), dann eine 20-Gigabyte-Partition ext4 / (root) für mein ArchLinux, dann lass ich 20 Gigabyte frei für das nächste Linux was ich installieren will (ich hab sooo viel Platz auf der Platte, ich brauch da kein schlechtes Gewissen zu haben), bleiben noch 120 Gigabyte für was so an Daten anfallen mag, ext4 /data.

Paketauswahl

In der Paketauswahl der erste Härtetest für die Ansprüche von ArchLinux. Das soll ja angeblich einen recht schlanken Systemaufbau ermöglichen, unter Vermeidigung aller Software-Blähungen. Aber wie klein kann ich mir meine Start-Paketauswahl zusammenklicken, ohne dass die Installation scheitert, bzw. so, dass ich ein Boot-fähiges System habe, von dem aus ich weitere Pakete installieren kann?

Per Default schlägt ArchLinux ein "minimales" "Base"-System vor, das bei genauerem Hinschauen aus rund sechzig vorausgewählten Paketen besteht. Deren Installation zieht über Paket-Abhängigkeiten noch rund zwanzig weitere Pakete nach. Das Ergebnis frisst dann schon einen halben Gigabyte Festplattenplatz. Geht's wirklich nicht kleiner? Ein rasches Überfliegen der Paketnamen legt nahe, dass nicht jede Installation alle davon als absolutes Start-Minimum benötigen wird ("cryptsetup"? "pcmciautils"?). Also rumprobieren, was sich alles abwählen lässt!

Beim So-wenige-Pakete-wie-möglich-Installieren fällt zuallererst auf, dass die nachfolgende Installation in jedem Fall doch ziemlich viele Abhängigkeiten mit reinholt. Die Minimal-Auswahl für Bootfähigkeit sind die drei Pakete "grub" (damit es einen Bootloader hat), "kernel26" (in irgendwas muss der Bootloader ja reinbooten) und "initscripts" (an irgendwas muss der Kernel ja übergeben), zuzüglich deren (an dieser Stelle nicht manipulierbare) Abhängigkeiten ziehe ich mir aber schon über vierzig Pakete und mehrere hundert Megabyte rein. So ganz überzeugt mich das Minimalismus-Versprechen von ArchLinux an dieser Stelle noch nicht.

Für die Fähigkeit, nach dem Booten weitere Pakete nachzuinstallieren, muss ich immerhin zusätzlich nur noch "pacman" und "dhcpcd" anwählen (beides zieht natürlich auch wieder weitere Abhängigkeiten mit rein).

Konfiguration, Installation

Beim nachfolgenden texteditorischen Gang durch die Konfigurationsdateien denke ich mir noch einen netteren Hostnamen in /etc/rc.conf aus (in /etc/hosts wird der interessanterweise automatisch ergänzt) und kommentiere die deutsche UTF8-Locale aus. (Und natürlich setze ich ein Root-Passwort.) Dann Installation Bootloader und alles ist fertig. Reboot! System läuft, jetzt kann ich mit "pacman -S [Paketname]" weitere Pakete reinholen.

Im neuen System: erste Schritte mit Pacman, Nutzer-Einrichtung

ArchLinux bootet und ich stehe schließlich als root in der Shell. Internet-Kabel steckt drinne, sodass ich gleich mal Pacman ausprobieren kann.

[root@plom-eee ~]# pacman-db-upgrade && pacman -Syy 

"pacman-db-upgrade" ist erforderlich, weil es wohl inzwischen eine neue Pacman-Version gibt; "pacman -Syy" meckerte, ich solle erstmal ersteres ausführen, bevor sich damit das restliche System auf den neuesten Stand bringen ließ. Weiter:

Um etwas arbeitsfähiger zu werden, installiere ich mir erstmal "less" und "nano":

# pacman -S less && pacman -S nano 

Damit kann ich dann die nächsten im "Beginner's Guide" empfohlenen Schritte ausführen: das Optimieren der Pacman-Mirrorliste:

# pacman -Syyu curl # Wird offenbar für das rankmirrors-Skript benötigt. 
# cd /etc/pacman.d 
# cp mirrorlist mirrorlist.backup 
# nano mirrorlist.backup 

Wie befohlen, de-kommentiere ich in mirrorlist.backup diverse Mirrors in meiner geografischen Nähe -- d.h. alle deutschen Mirrors. Danach de-installiere ich noch das nicht mehr benötigte "curl" mitsamt seiner reingeholten Abhängigkeiten.

# rankmirrors -n 6 mirrorlist.backup > mirrorlist 
# pacman -Syy 
# pacman -Rs curl 

Jetzt sollte Pacman so gut angebunden sein wie möglich. Ich teste es gleich mal aus, indem ich weiteres Nützliches installiere:

# pacman -S man-db # Das erlaubt den Umgang mit bereits installierten man-pages. 
# pacman -S man-pages # Das installiert weitere, Linux-spezifische man-pages. 
# mandb # Updated den man-Index? 

So, und jetzt noch rasch Nutzer-Einrichtung:

# useradd -m plomlompom 
# passwd plomlompom      # ein Passwort für den plomlompom ... 
# passwd                 # ... und eins für Papa Root 

Wifi, unverschlüsselt

Was traditionell bei Linux ein bisschen kompliziert geraten kann: Die WLAN-Konfiguration. Erstmal rausbekommen, welche Karte man hat und wie der Kernel mit der kann und ob es extra Treiber braucht usw. usf. https://wiki.archlinux.org/index.php/Wifi hilft hier weiter.

Glücklicherweise ist mein Treiber schon im ArchLinux-StartKernel als Modul enthalten: rt2860sta. Unglücklicherweise beißt es sich mit einigen anderen Modulen, falls diese beim Booten automatisch geladen werden -- siehe https://wiki.archlinux.org/index.php/Wifi#rt2860_and_rt2870. Dort wird mir der (erfolgreiche Tipp) gegeben, das automatische Laden folgender Module in der /etc/rc.conf zu untersagen: "rt2800pci rt61pci rt2x00pci rt2800usb rt2800lib rt2x00usb rt2x00lib".

Treiber-seitig müsste jetzt alles klappen. Als Nächstes brauche ich die Software zum Spielen mit dem Wireless-Interface:

# pacman -S wireless_tools 
# pacman -S iputils        # fürs "ping" zum Testen! 

Ich schalte mein Heim-WLAN erstmal auf "unencrypted", fangen wir mal mit dem Einfachsten an. Mit ...

# modprobe rt2860sta 
# ifconfig wlan0 up 
# iwlist wlan0 scan 

... aktiviere ich das Wireless-Interface und scanne nach den umgebenden Netzwerken, worunter ich mein Heim-WLAN mit dem Namen "kadatheron" entdecke. Eigentlich müsste ich jetzt nur noch Folgendes machen:

# iwconfig wlan0 essid "kadatheron" 
# dhcpcd 

Aus irgendeinem Grund führt der erste Schritt aber nicht zum gewünschten Ergebnis, das Interface an mein "kadatheron" zu binden; es bleibt ungebunden. Nach ein bisschen Rumprobiere habe ich Folgendes herausgefunden:

Mein Interface startet (vor jedem Verbindungsversuch!) mit dem "Mode:Auto" und einer "Link Quality=10/100" (aus der Anzeige nach "iconfig wlan0"). Eigentlich brauche ich "Mode:Managed", aber kein "iwconfig wlan0 mode Managed" schaltet das Auto aus; vielleicht kann man sich ja auf "Auto" verlassen, von selbst auf "Managed" zu schalten, aber ein positives Ergebnis bringt es bei mir an dieser Stelle nicht. Was interessanterweise stattdessen funktioniert: "iwconfig wlan0 mode Ad-hoc". Dann klickt das Interface auf "Mode:Ad-hoc" und manchmal auch schon (entweder jetzt oder gleich nach dem nächsten Schritt) auf eine "Link Quality=70/100". Mache ich danach ein "iwconfig wlan0 mode Managed", springt das Interface auf "Auto" zurück, aber mit erhöhter "Link Quality". Jetzt klappt auch die Bindung mit "iwconfig wlan0 essid ..." Meine (aufgrund ihrer Unverstandenheit nicht ganz zufriedenstellende) Lösung für unverschlüsselte Netzwerke sieht also so aus:

# iwconfig wlan0 mode Ad-hoc 
# iwconfig wlan0 mode Managed 
# iwconfig wlan0 essid "kadatheron" 
# dhcpcd 

Vielleicht irgendein Bug in Karte / Treiber?

Wifi, verschlüsselt

Das Ganze jetzt auch noch mit Verschlüsselung zum Laufen zu bringen, müsste doch ein zusätzlicher, noch komplizierterer Krampf sein, oder? Nicht ganz. Zwar funktioniert das hierfür brauchbare Programm ...

# pacman -S wpa_supplicant 

... auf den ersten Blick etwas umständlich, insoweit man für jedes neue Netzwerk erstmal mittels eines weiteren Programms "wpa_passphrase" etwas in eine Konfigurations-Datei "/etc/wpa_supplicant.conf" schreiben muss, die dann von einem trotzdem mittels barocker Parameter zu startenden "wpa_supplicant" ausgelesen wird. Auf den zweiten Blick lässt sich der Vorgang aber auf wenige Schritte großer Automatisierbarkeit reduzieren:

# wpa_passphrase "kadatheron" [Passwort] > /etc/wpa_supplicant.conf 
# wpa_supplicant -B -Dwext -i wlan0 -c /etc/wpa_supplicant.conf 

Als Bonus ersetzt wpa_supplicant auch noch die ganzen obigen iwconfig-Schritte, einschließlich der Verwirrung um den Mode. Der ganze Vorgang des Einloggens schrumpft also auf:

# modprobe rt2860sta 
# ifconfig wlan0 up 
# wpa_passphrase [Netzwerkname] [Passwort] > /etc/wpa_supplicant.conf 
# wpa_supplicant -B -Dwext -i wlan0 -c /etc/wpa_supplicant.conf 
# dhcpcd wlan0 

Wobei die dritte Zeile ausgelassen werden kann, falls der richtige Eintrag von zuvor bereits in /etc/wpa_supplicant.conf eingetragen steht.

Zugriff auf USB-Sticks

Zwei Kernel-Module müssen geladen werden, damit ich einen USB-Stick unter /dev/sdb finde:

# modprobe usb_storage 
# modprobe ehci_hcd 

X und TouchPad

Drei Pakete muss ich installieren, damit X läuft:

# pacman -S xorg-server xorg-xinit xf86-video-intel 

So kann ich nun mit "xinit" prinzipiell in X rein. So richtig Sinn macht das aber nur, wenn man xinit ein Programm übergibt, das es in X anzeigen kann, sonst schaut es sich kurz ergebnislos nach einer Aufgabe um und fährt den X-Server dann wieder runter. Also geben wir ihm mal was zum Spielen:

# pacman -S xterm 

Ein bloßes "xinit" sollte jetzt reichen, um ins xterm zu gelangen, denn xinit startet per default in xterm. Ein Problem gibt es aber noch: Sollten die entsprechenden Kernel-Treiber nicht geladen sein, weiß X nichts von Nutzer-Eingabe-Möglichkeiten, weder für die Maus noch für Tasten-Befehle. So gäbe es dann auch keine Möglichkeit, das xterm zu beenden oder sich sonstwie aus X durch ambitionierte Tasten-Kombinationen in einen anderen Terminal zu retten. Sicherheitshalber lade ich also folgende Kernel-Module:

# modprobe evdev && modprobe psmouse 

Auf ersteres scheint sich X allgemein für Nutzer-Eingaben zu verlassen, Zweiteres macht aus unerfindlichen Gründen das TouchPad ansprechbar. Dann läuft alles prima:

$ xinit 

xterm kann ich jetzt strenggenommen auch wieder deinstallieren:

# pacman -Rs xterm 

Für eine etwas komfortablere TouchPad-Steuerung bietet sich übrigens die Installation des X-Moduls "xfree86-input-synaptics" an:

# pacman -S xfree86-input-synaptics 

Das legt eine Datei /etc/X11/xorg.conf.d/10-synaptics.conf an, in der sich das TouchPad konfigurieren lässt. Ich kommentiere vor allem die drei voreingestellten Tap-Buttons aus:

Section "InputClass" 
        Identifier "touchpad catchall" 
        Driver "synaptics" 
        MatchIsTouchpad "on" 
        MatchDevicePath "/dev/input/events*" 
        # Option "TapButton1" "1" 
        # Option "TapButton1" "2" 
        # Option "TapButton1" "3" 
EndSection 

Denn ich bin alles Andere als ein Freund hyperaktiver TouchPads, und so interpretiert er ein Rumhüpfen meines Fingers auf dem Pad selbst (statt ein Klicken auf den darunterliegenden Tasten) nicht bereits als Tasten-Klick.

Sound

ALSA läuft qua Kernel und muss nur noch per alsamixer aufgedreht werden.

# pacman -S alsa-utils 
# alsamixer 

Testen mit:

# speaker-test -c 2 

Damit es auch für normale User klappt, müssen die in die Audio-Gruppe:

# gpasswd -a plomlompom audio 

Obacht! Erst nach einem Neustart klappt es bei mir, dass sich das Privileg wirkungsvoll auf den Normal-User überträgt.

Browser, Flash

# pacman -S chromium 

Mit dem Chromium lässt es sich gut browsen. Damit auch Flash funktioniert, muss ich erstmal in der /etc/pacman.conf/ das hier auskommentieren:

[multilib] 
Include = /etc/pacman.d/mirrorlist 

Dann kann ich:

# pacman -S flashplugin 

Kommentare

Keine Kommentare zu dieser Seite.

Schreibe deinen eigenen Kommentar

Kommentar-Schreiben derzeit nicht möglich: Kein Captcha gesetzt.

PlomWiki-Engine lizensiert unter der AGPLv3. Quellcode verfügbar auf GitHub.