19.08.2017, 22:32 UTC+2

Sie sind nicht angemeldet.

  • Anmelden
  • Registrieren

1

29.07.2017, 14:57

Anmerkungen zu Festplatteninstallation auf USB-Stick

Im Rahmen meiner Spielchen mit KNOPPIX versuchte ich auch eine Festplatteninstallation, wozu ich allerdings keine eingebaute Festplatte, sondern einen USB-Stick verwendete. Mich interessierte vor allem, was eine HD-Installation überhaupt macht. Einen konkreten Anwendungsfall für eine HD-Installation habe ich nicht, denke auch nicht, dass ich KNOPPIX dafür wählen würde. Warum ein System auf einen USB-Stick, darüber kann man sicher generell unterschiedlicher Ansicht sein. Früher nutzte ich das noch häufiger, inzwischen eher nur noch KNOPPIX als Live-Version mit Overlay-Partition.

KNOPPIX HD-Installation formatierte den Stick und legte eine kleine SWAP-Partition an und den Rest als ReiserFS. Das folgt den Designvorstellungen von Herrn Knopper und ich sehe keinen praktischen Sinn in diesem doch veralteten und exotischen Dateisystem. Auch ein SWAP auf einem langsamen USB-Gerät würde ich nicht wollen. Die Grundeinstellungen sind fest in einem Script verankert, KNOPPIX lässt einem hier zunächst keine Wahl.
Die Installation des Systems ist mehr oder weniger eine Kopie des vollständig gemounteten Systems. Es werden bei meinem KNOPPIX 771 drei Teile in einem UnionFS eingebunden: KNOPPIX, KNOPPIX1 und KNOPPIX_DATA, die Overlay Partition. Eine komplette Kopie des Dateibaumes bedeutet also dementsprechend, dass mein installiertes System später so funktioniert und alle Änderungen enthält, wie ich sie gerade eben auf dem Live-System benutzt habe.
Am Ende der Installation kommt eine Abfrage, ob nun Grub installiert werden soll und zwar in den MBR der ersten Platte. Das verneinte ich natürlich, mein USB-Stick war die zweite Platte im System. Damit ist solch ein Stick nicht bootfähig und braucht manuelle Korrektur.
Ich nutzte die Information aus dem Ubuntu-Wiki
https://wiki.ubuntuusers.de/GRUB/
https://wiki.ubuntuusers.de/menu.lst/
https://wiki.ubuntuusers.de/UUID/
https://wiki.ubuntuusers.de/GRUB/GRUB-Shell/
um manuell den GRUB auf dem Stick passend zu bearbeiten. Bei mir ist es so, dass ich den Stick mit Hilfe des Bootmenüs (edit: meines PCs) starte. Er ist dann in meinem PC das erste erkannte Gerät. Entsprechend bearbeitete ich die Einträge der menu.lst, die von KNOPPIX bereits vorbelegt waren. Außerdem hatte ich zusätzliche Einträge von grub-update generieren lassen, die aber allesamt nicht booten wollten. Der KNOPPIX-Eintrag zeigt nur auf einen 32 Bit-Kernel. Ich fügte weitere Eintzräge hinzu, um auch den vorhandenen 64Bit-Kernel starten zu können. Außerdem versuchte ich eine Zuordnung über die UUID des Dateisystems, aber das gelang mir nicht. Kein einziger getesteter Eintrag wollte Booten.
KNOPPIX setzt etliche Kernel-Optionen, von denen einige notwendig und andere verzichtbar sind. Ich habe nicht alles ausgetestet und es fehlt mir das Grundlagenwissen hierzu. Der vorbelegte Eintrag von Knoppix funktioniert so, wie er kommt.
Nach einem grub-install (in der Tat nahm ich diese Prozedur zahlreiche Male vor, um immer andere Kombinationen zu testen), wurde mein neuer Stick vorbereitet. Die /etc/fstab musste noch angepasst werden.
Danach bootete Knoppix wie erwartet und gewünscht und auch mit allen meinen letzten Änderungen (ich nutze zB Openbox als WM in LXDE).
Im folgenden nun die Vorgehensweise, wie sie für mich richtig war. Gebootet war mein Knoppix-Live, die ich also auf den Stick kopiert hatte. Der Stick war eingelegt und auf /sdb2 gemountet (sdb1 war die SWAP):

Quellcode

1
2
3
4
5
6
7
root@Microknoppix:/home/knoppix# mount -o bind /dev /media/sdb2/dev
root@Microknoppix:/home/knoppix# mount -o bind /sys /media/sdb2/sys
root@Microknoppix:/home/knoppix# mount -t proc /proc /media/sdb2/proc
root@Microknoppix:/home/knoppix# chroot /media/sdb2 /bin/bash
root@Microknoppix:/# ls
bin   dev  home   	KNOPPIX  lib64   media  opt   root 	run   sys   	tmp  var
boot  etc  iamchroot  lib  	libx32  mnt	proc  rules.d  sbin  tftpboot  usr
Auf dem Stick hatte ich im Wurzelverzeichnis zuvor die Datei "iamchroot" angelegt, um als einfacher Anzeiger für einen erfolgreichen chroot zu dienen.
Mit fdisk -l prüfte ich nochmals die Geräte und blkid zeigte die UUID meiner gewünschten Partition.
Mit dieser Information bearbeitete ich nun die menu-lst:

Quellcode

1
root@Microknoppix:/# nano /boot/grub/menu.lst
und die zeige ich nun mal:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
default 0
timeout 2
color cyan/yellow red/light-green

# key definitions for a keyboard layout better suited to german keyboards
# this cannot be complete, but does not need to be
# to unset just type "setkey" (without parameters) on the GRUB command line
setkey y z
setkey z y
setkey Y Z
setkey Z Y
setkey equal parenright
setkey parenright parenleft
setkey parenleft asterisk
setkey doublequote at
setkey plus bracketright
setkey minus slash
setkey slash ampersand
setkey ampersand caret
setkey underscore question
setkey question underscore
setkey semicolon less
setkey less backslash
setkey colon greater
setkey greater bar
setkey asterisk braceright


title KNOPPIX
root (hd0,1)
kernel /boot/vmlinuz root=/dev/sda2 rootwait lang=de apm=power-off nomce libata.force=noncq tz=localtime loglevel=1 lang=de apm=power-off initrd=minirt.gz nomce libata.force=noncq hpsa.hpsa_allow_any=1 loglevel=1 no3d rw
Man sieht, dass die Kernel-Optionen bei diesem Default-Eintrag von Knoppix teilweise doppelt eingetragen sind und es wird auf die, in der HD-Installation nicht mehr vorhandene initrd=minirt.gz verwiesen. Diesen Eintrag und die doppelten Optionen konnte ich entfernen und damit noch immer ein System erfolgreich booten. Entfernte ich zu viele Optionen, dann hing der Boot und brachte eine Panic.
Ich konnte aber auch zusätzliche Zeilen einfügen, wie etwa

Quellcode

1
2
3
title KNOPPIX64
root (hd0,1)
kernel /boot/vmlinuz-4.7.9-64 root=/dev/sda2 rootwait lang=de apm=power-off nomce libata.force=noncq tz=localtime loglevel=1 lang=de apm=power-off initrd=minirt.gz nomce libata.force=noncq hpsa.hpsa_allow_any=1 loglevel=1 no3d rw
und damit den erwähnten 64Bit-Kernel booten.
Einträge der folgenden Art versagten bisher immer, wobei ich die Syntax gelegentlich änderte und unterschiedliche Optionen probiert hatte. Es gab dabei keine Fehlermeldung, der Bootvorgang hing einfach nur und lief nicht weiter.

Quellcode

1
2
3
title KNOPPIX64UUID
root (hd0,1)
kernel /boot/vmlinuz-4.7.9-64 root='UUID=d55555d9-4575-4d77-81cf-ea4751298590' rootwait lang=de apm=power-off nomce libata.force=noncq tz=localtime loglevel=1 lang=de apm=power-off initrd=minirt.gz nomce libata.force=noncq hpsa.hpsa_allow_any=1 loglevel=1 no3d rw
Ich sehe nicht, was ich falsch gemacht habe. Laut Dokumentation sollte so ein Booten des richtigen Dateisystems möglich sein. ich habe aber auch keinen Update des in KNOPPIX mitgelieferten GRUB probiert und einfach das benutzt, was vorhanden war.
Zu guter Letzt muss GRUB neu installiert und die chroot verlassen werden:

Quellcode

1
2
3
4
5
6
7
8
9
10
11
root@Microknoppix:/# grub-install /dev/sdb
Searching for GRUB installation directory ... found: /boot/grub
Installation finished. No error reported.
This is the contents of the device map /boot/grub/device.map.
Check if this is correct or not. If any of the lines is incorrect,
fix it and re-run the script `grub-install'.

(hd0)	/dev/sda
(hd1)	/dev/sdb

root@Microknoppix:/# exit
Dabei möchte ich nochmal darauf hinweisen, dass nun mein Stick das zweite Gerät ist, KNOPPIX live vom ersten Gerät gebootet wurde. Später will ich den installierten Stick booten, wobei der Live-Stick nicht mehr vorhanden ist und auch sonst keine Festplatte oder ein anderer Datenträger die Reihenfolge zerstören könnte. Deshalb muss ich Grub nun zwar ins Gerät zwei (hd1 /dev/sdb) installieren, die Konfiguration wird aber so gesetzt, dass es später als Gerät 1 erkannt und behandelt wird. UUID wären hier natürlich grundsätzlich wünschenswert.

Bemerkenswert ist vielleicht noch der Umstand, dass die fstab automatisch falsch ausgefüllt war. Trotzdem wurde der Stick richtig gebootet und die SWAP auf dem Stick nicht eingebunden. Stattdessen bildet ein /dev/zram0 oder so ähnlich den SWAP. Dies ist ein Gerät im Speicher. Besonders in der 32Bit-Version, wo eh nicht der komplette verfügbare Speicher benutzt werden kann, ist das eine ziemlich lästige Sache, vom Prinzip her. In der Praxis ist dieser SWAP dynamisch und bei kurzen Einsatzzeiten wird er nicht wirklich jemals belegt werden. Nach Korrektur der fstab wird die vorhandene SWAP auf dem Stick eingebunden und zusätzlich genutzt. Ich habe mich nicht bemüht, ihn ausschließlich zu nutzen.

Das System lief von diesem Stick (ein USB3.1 Gerät) wesentlich langsamer, als das Live-System (auf einem USB2.0 Gerät). Bei dieser Art von USB-Stick hatte ich zuvor schon den Verdacht, dass sie mit installierten Systemen extrem langsam laufen und zwar unabhängig von Dateisystem und mount-Optionen. Die Geschwindigkeit war in der Tat so lahm, dass ich die Lust am Spielen schnell verlor. Alleine das Einloggen als Superuser, also die Reaktion auf den einfachen Befehl su, die dauerte mitunter bis zu einer Minute. Weil es nur ein Experiment war, tolerierte ich das, führte aber nicht alle Tests und Untersuchungen durch, die ich gerne machen wollte.

Derzeit will ich noch die Umstellung auf ein ext-Dateisystem (vermutlich ext2fs) probieren und dann werde ich das wohl beenden und den Stick wieder für andere Aufgaben benutzen.

2

30.07.2017, 11:09

Umstellung auf ext2 funktioniert

Also, mit meinem langsamen Stick hat es etwas länger gedauert und meine Spielerei beinhaltet auch einen kompletten Fehlversuch, doch soeben bootet das installierte System vom USB-Stick mit einem ext2 Dateisystem.
Zunächst zu dem Fehlversuch: ext4. Ich hatte erst ext4 gewählt, weil es moderner ist und sicher die erste Wahl für eine wirkliche Festplatteninstallation wäre. Das gelingt nicht mit dem ausgelieferten Knoppix.
Um das Dateisystem zu ändern, habe ich die ReiserFS formatierte Partition mit Knoppix in einem GNU/Linux (Ubuntu) eingebunden und alle Daten dorthin in einen Ordner gesichert (rsync). Anschließend den Stick ausgehängt und mittels gpart die Partition bearbeitet, sprich, neu formatiert. Dann die neu formatierte Partition wieder eingebunden und alle Daten zurück gespielt.
Bei diesem Vorgehen wird so der Grub Bootloader nicht verändert. Ich probierte es trotzdem und erlebte (eigentlich wie erwartet), dass der Stick so nicht starten konnte.
Also wollte ich den Grub neu installieren und ging dabei wie zuvor beschrieben vor und chrootete in das System auf dem Stick. Erstaunt nahm ich zur Kenntnis, dass ich Grub nicht neu installieren konnte. Es gab Fehlermeldungen.
Ein Blick auf die vorhandenen Loader zeigte mir dann:

Quellcode

1
2
3
4
5
6
7
8
9
pit@senyo ~:- > ls /media/da1s2/boot/grub | grep stage
e2fs_stage1_5
fat_stage1_5
jfs_stage1_5
minix_stage1_5
reiserfs_stage1_5
stage1
stage2
xfs_stage1_5
es gibt da also nicht nur keinen ntfs_stage1_5 (wie ich zuvor wegen eines anderen Beitrags schon nachgesehen hatte), sondern auch für ext nur den einen Eintrag für ein ext2fs.
Wenn ich versuchte mittels apt-get --reinstall grub neu zu installieren, erhielt ich entweder die Meldung, dass kein Grub gefunden werden konnte, oder, dass mein installierter Grub schon aktuell sei (ich erhielt beide Antworten abwechselnd bei unterschiedlichen Versuchen). Das kommt mir sehr merkwürdig vor. Ich habe aber auch nicht die Nerven, deshalb weiter nach zu forschen. Ich wollte ja sehen, ob es auch ohne ReiserFS geht und mir persönlich ist sogar ext2fs sympathischer, weil es auch in meinem Betriebssystem unterstützt wird (ext4 nur Lesend).
Ich bin sicher (was auch sonst), dass viele GNU/Linux Systeme in ext4 formatierten Dateisystemen liegen und von Grub gebootet werden. Ich kann mir nicht vorstellen, dass nur Grub2 ext4 kann, kenne mich damit aber auch nicht aus. Für eine Installation auf einem USB-Stick würde man ext4 ohnehin etwas zurecht tunen, wenn man das Konzept überhaupt ernsthaft umsetzen möchte. Es spricht aus meinen Augen nichts für ein solches Vorhaben.
Für mich ist es wichtig, weil ich in einem anderen Beitrag nass-forsch behauptete, Knoppix könne selbstverständlich auch auf anderen Dateisystemen laufen, als auf ReiserFS. Ich würde es auch nicht auf ReiserFS haben wollen, Knoppix hat aber eine starke Vorliebe dafür. Ich halte es nach wie vor für möglich, ein installiertes System auch auf ext4 um zurüsten (oder ein anderes modernes Dateisystem, das von Linux beherrscht wird), aber mit den ausgelieferten Mitteln, den Bordwerkzeugen von Knoppix direkt nach der Installation, da gibt es damit Probleme.
Ext2fs indessen gelingt problemlos, wie mein weiterer Test dann zeigte.
Also nochmal Partition um-formatiert, Daten zurück, chroot, Grub installiert und dann davon gebootet und es läuft.

Linux HardwareLinux Computer & PCs | Linux Notebooks & Laptops | Geek Shirts | Geek und Nerd Shirt Shop