Red Hat 9 on Michael’s Domain

Ändern des Runlevels (inittab, telinit)

Sat, 26 May 2007 00:00:00 +0000

Normalerweise ändert man den Standard-Runlevel durch Bearbeiten der Datei /etc/inittab. Manchmal bootet man jedoch in Runlevel 3 (z. B. durch Auswahl des abgesicherten Modus im GRUB-Menü) und möchte dann zu Runlevel 5 wechseln. Dies erreichen Sie im laufenden Betrieb mit dem Befehl: telinit 5. Unter RedHat 9 ändern Sie einfach in der Datei /etc/inittab den Runlevel von 5 auf 3, und beim Booten steht Ihnen standardmäßig nur noch die Befehlszeile zur Verfügung. Keine grafische X11-Anmeldung usw. In neueren Ubuntu-Versionen funktioniert dies offenbar nicht mehr, obwohl „telinit + Zahl“ den Runlevel eigentlich noch ändern sollte; zumindest in „Precise Pangolin“ (12.04) scheinen die Befehle „telinit 2–5“ jedoch keine Wirkung zu zeigen. „telinit 1“ versucht, den Rechner herunterzufahren, doch bei meinem Test blieb der Vorgang auf halbem Weg hängen. Um etwas Ähnliches wie den Wechsel in Runlevel 3 zu erreichen, musst du die grafische Benutzeroberfläche beenden (d. h. den gdm- oder lightdm-Prozess beenden). Das Runlevel-Konzept scheint nicht mehr zu funktionieren.

Einbinden von Disk-Image-Dateien und verschlüsselten Dateisystemen/Partitionen

Sat, 26 May 2007 00:00:00 +0000

Um eine Festplatte (oder eine Partition) in eine Datei zu kopieren, verwenden Sie den folgenden Befehl: dd if=/dev/hda3 of=file.bin Dieser Befehl schreibt die gesamten Daten der Partition hda3 in die Datei file.bin.Um das in der Datei enthaltene Dateisystem einzuhängen, müssen Sie ein Loopback-Gerät erstellen: losetup /dev/loop0 file.bin Nun können Sie das Dateisystem wie gewohnt einhängen: mount -r -t filesystemtype /dev/loop0 /mnt/mountpoint Offenbar kann man die letzten beiden Befehle zu einem zusammenfassen:mount -t Dateisystemtyp -o loop ./file.bin /mnt/mountpointWenn Sie die Daten in einer Datei verschlüsseln möchten, die ein ganzes Dateisystem enthält, wird es etwas komplizierter:sudo mkdir /mnt/secure (Mountpunkt für das Dateisystem erstellen)dd if=/dev/zero of=Pfad/zur/Datei bs=1k count=409600 (eine leere Datei mit einer Größe von 400 MB erstellen) sudo /sbin/losetup -e xor /dev/loop0 Pfad/zur/Datei/sbin/mkfs -t ext2 /dev/loop0 409600 (das Gerät als ext2 formatieren)sudo mount -t ext2 /dev/loop0 /mnt/secure (die Gerätedatei einhängen)cd /mnt/securechown Benutzername . (Eigentümer des obersten Verzeichnisses des Dateisystems ändern)Wenn Sie das Dateisystem aushängen möchten:sudo umount /dev/loop0Wenn Sie das Dateisystem entfernen möchten, müssen Sie die Zuordnung zum Loop-Gerät 0 aufheben: /sbin/losetup -d /dev/loop0Aus irgendeinem Grund bietet RedHat 9 keine DES-Unterstützung, daher verwende ich vorläufig (bis ich den Kernel patche oder zu Suse Linux wechsle) die schnellere, aber wesentlich schwächere XOR-Verschlüsselung.SUSE 9 verfügt über eine integrierte starke Verschlüsselung und bietet bereits während der Installation die Möglichkeit, eine verschlüsselte Partition anzulegen. SUSE 9 fragt beim Booten nach der Passphrase, um das verschlüsselte Dateisystem einzuhängen. Der Bootvorgang wird angehalten und wartet zwei Minuten, bevor er fortgesetzt wird, wenn Sie das Passwort nicht eingeben. Um diese Zeit zu verkürzen, können Sie die Datei /etc/init.d/boot.crypto bearbeiten. Ändern Sie in der folgenden Zeile 120 beispielsweise in 10: ${TIMEOUT:=120}Falls Sie die Gelegenheit verpasst haben, die Passphrase während des Bootvorgangs einzugeben, können Sie die verschlüsselte Partition wie folgt einbinden:/sbin/losetup -e twofish /dev/loop0 /dev/hda7 mount /dev/loop0 /media/confÜbrigens: Die Informationen zu verschlüsselten Dateisystemen befinden sich in /etc/cryptotab.

rio500-0.7-1.i386.rpm läuft unter RedHat 9

Sat, 26 May 2007 00:00:00 +0000

Ich habe erneut versucht, rio500-0.8.1 zu kompilieren, jedoch ohne Erfolg. Die Kompilierung schlägt unter dem Kernel 2.4 fehl. Dies ist ein noch ungelöstes Problem, das auch in den Diskussionsforen erwähnt wird. Daher habe ich das Rio500-Paket rio500-0.7-1.i386.rpm installiert. Interessanterweise gelang es mir über die Befehlszeile, a) den internen Speicher zu formatieren: rio_format, b) einen Ordner anzulegen (was notwendig ist, bevor man einen Song hochladen kann): rio_add_folder, c) MP3s hochzuladen: rio_add_song. Das ist ein großer Vorteil gegenüber der miesen Windows-Rioport-Oberfläche. Als Nächstes werde ich versuchen, die Gnome-GUI zu installieren. Als ich mir die ersten Songs auf dem Rio500 anhörte, die ich unter Linux übertragen hatte, klangen sie sehr leise. Wenn ich das nächste Mal einige Songs kodiere, sollte ich die Lame-Option „–scale“ ausprobieren. Ich weiß jedoch nicht, welches Argument ich verwenden muss, um eine angemessene Verstärkung des Klangs zu erzielen.

Suse 9

Fri, 25 May 2007 00:00:00 +0000

Ich bin auf SUSE 9 umgestiegen. Aus den Ankündigungen von Red Hat kann ich nicht herauslesen, was sie eigentlich vorhaben. Deshalb sollte ich mich besser schon jetzt an eine Alternative gewöhnen. Außerdem bin ich von GNOME auf KDE umgestiegen, und zumindest unter SUSE 9 gefällt mir KDE besser als GNOME unter Red Hat 9.

Suse 9 zu Red Hat 9 hinzufügen (zwei verschiedene Distributionen auf demselben Computer)

Wed, 23 May 2007 00:00:00 +0000

Red Hat 9 ist installiert und es liegt folgende Partitionierung vor: hdd1 /boot (ext3) 100 MB hdd2 /home (reiserfs) 7,8 GB hdd3 / (ext3) 7,8 GB hdd4 EXT hdd5 swap 1 GB hdd6 /mnt/documents (reiserfs) 12 GB hdd7 /mnt/music (reiserfs) 90 GBDie Aufgabe besteht darin, ein zweites Linux-Betriebssystem (Suse 9) auf dieser Festplatte zu installieren, ohne dabei Daten zu verlieren. Die Root-Partition dieses Systems soll 10 GB groß sein. Außerdem möchte ich alle von Benutzern erstellten Dateien auf einer Partition zusammenfassen (derzeit befinden sie sich auf drei verschiedenen Partitionen: hdd2, hdd6 und hdd7). Zunächst besorgte ich mir eine externe 200-MB-USB-2.0-/FireWire-Festplatte (Maxtor, unter /mnt/sdb1 eingebunden) und kopierte die Daten von hdd1, hdd2, hdd6 und hdd7 mit „cp -ax /home /mnt/sdb1“ usw. darauf. Anschließend startete ich den Rechner mit der Knoppix-3.3-CD neu und führte von einem Root-Terminal aus „partimage“ aus. Ich versuchte, das Image der Root-Partition direkt auf mein externes USB-Laufwerk zu speichern, jedoch ohne Erfolg: Jedes Mal blieb das Programm während des Vorgangs an einer Stelle hängen. Daraufhin speicherte ich das Image unter /mnt/music, was gelang. Ich habe das System unter Red Hat 9 neu gestartet und das Image manuell von /mnt/music auf das USB-Laufwerk (/mnt/sdb1) kopiert. Da ich dem Programm „partimage“ nicht traute, habe ich das Dateisystem zusätzlich manuell mit den folgenden Befehlen auf das USB-Laufwerk kopiert: mkdir /mnt/sdb1/redhat_root cd / find . -xdev -print | cpio -padm /mnt/sdb1/redhat_root Anscheinend werden dabei alle Daten einschließlich Sonderdateien, Einhängepunkte usw. kopiert, wobei alle Dateimetadaten erhalten bleiben. Danach habe ich das externe USB-Laufwerk (vorsichtshalber) abgezogen, in Knoppix neu gestartet und wollte QTParted ausprobieren. Damit sollte es möglich sein, die Größe von Partitionen anzupassen. Im Root-Terminal gab ich „qtparted“ ein. Allerdings konnte ich die Größe von nichts ändern (die Optionen waren ausgegraut). Ich konnte die Partitionen allerdings löschen und neu anlegen (was nicht viel half). Also entschied ich mich für einen kompletten Neuanfang, legte die Suse-9-CD in das Laufwerk ein und startete den Suse-9-Installer. Ich wählte die „Experten-Partitionierung“, löschte alle vorhandenen Partitionen und legte die folgenden Partitionen neu an. Ich habe darauf geachtet, für hdb3 genau die gleiche Anzahl an Blöcken (1019) zu verwenden wie zuvor für hdd3, da ich wusste, dass partimage Images nur auf Partitionen wiederherstellen kann, die genau dieselbe Größe haben oder größer sind: /dev/hdb1 1 8 64228+ 83 Linux (ext3) /boot/dev/hdb2 9 1314 10490445 83 Linux (reiserfs) //dev/hdb3 1315 2333 8185117+ 83 Linux (reiserfs) /redhat/dev/hdb4 2334 14945 101305890 f Win95 Ext'd (LBA)/dev/hdb5 2334 2464 1052226 82 Linux swap/dev/hdb6 2465 14945 100253601 83 Linux (reiserfs) /homeNachdem die Installation abgeschlossen war, startete ich den Rechner unter Knoppix neu und versuchte, die Red-Hat-Root-Partition auf hdb3 wiederherzustellen. Partimage meldete mir, dass die Partition kleiner als das Image sei, weshalb eine Wiederherstellung nicht möglich war. Also startete ich Suse 9 neu und kopierte das Red Hat 9-Root-System manuell zurück auf hdb3 (mit derselben Befehlsfolge, die ich verwendet hatte, um es manuell auf den USB-Stick zu kopieren). Anschließend passte ich die Datei /redhat/etc/fstab an die neue Partitionierung an und kopierte alle Dateien aus /boot (jedoch nicht die Unterverzeichnisse von /boot) auf die neue Boot-Partition (mit Ausnahme der Dateien, für die es bereits Entsprechungen in /boot gab). Anschließend habe ich die Datei /boot/grub/menu.lst geändert, indem ich eine Zeile für die Red-Hat-Installation hinzugefügt habe:title Red Hat 9 Linuxroot (hd1,0)kernel /vmlinuz-2.4.20-19.9 root=/dev/hdb3initrd /initrd-2.4.20-19.9.img Außerdem habe ich die beiden Benutzerordner im Verzeichnis /home angelegt (das früher der Einhängepunkt für die /home-Partition war). Dabei habe ich alle versteckten Dateien und Verzeichnisse (die mit einem . beginnen) in die Benutzerordner kopiert. Dann habe ich versucht, Red Hat 9 zu starten. Ohne Erfolg. Kernel-Panic. Kein init gefunden. Versuchen Sie, die Option init= an den Kernel zu übergeben. Tatsächlich ist die Dateisystemprüfung von hdb3 fehlgeschlagen (kein Superblock gefunden). Es gibt mehrere Fehlermeldungen, wobei die wichtigen zuerst und schnell erscheinen (und man sie nicht sieht), während die schlechten, irreführenden Fehlermeldungen erst später kommen. Etwa, dass man die Partition manuell reparieren sollte. Und dass „root“ schreibgeschützt eingehängt ist. Und dass man sie mit „mount -n -o remount,rw /“ in den Lese-Schreib-Modus versetzen kann. Und dass man nur mit Strg-D in diesem Zustand neu starten kann. Das werde ich natürlich tun. Es gibt jedoch keinen Hinweis darauf, welchen Befehl man verwenden soll. Mehrere Versuche, irgendetwas zu unternehmen, während hdb eingehängt war, schlugen fehl (wenn ReiserFS schreibgeschützt ist, kann es nicht repariert werden; wenn es schreib- und lesbar ist, kann es nicht überprüft werden). Also starte ich Knoppix neu und führe die Reparatur von dort aus durch: fsck (das reiserfsck ausführt) erledigt die Aufgabe nicht: Es prüft nur, führt aber keine Reparaturen durch. Ich habe herausgefunden, dass der Befehl reiserfsck –rebuild-sb /dev/hdb3 den Superblock repariert. Immer noch kein Erfolg, also führe ich den langsamen, vollständigen Neuaufbau des Dateisystems von Grund auf mit reiserfsck --rebuild-tree /dev/hdb3 durch. Es bootet immer noch nicht in RH9. Dann kommt mir der Gedanke: Der RH9-Kernel unterstützt ReiserFS möglicherweise nicht (oder das Modul ist nicht geladen). Oder (alternativ) funktioniert das Kopieren bestimmter Dateien von einer ext3-Partition auf eine ReiserFS-Partition möglicherweise einfach nicht. Also lösche ich (von Knoppix aus) die gesamte hdb3 und erstelle sie als ext3 neu. Ich kopiere alle Daten zurück (QTParted beschwert sich immer noch über eine zu geringe Größe). Und endlich funktioniert es. Ich erstelle zwei Verzeichnisse für die beiden Benutzer auf der /home-Partition und kopiere manuell die nicht versteckten Dateien der alten Benutzerordner dorthin. Die versteckten Dateien kopiere ich nicht. Es gibt viele davon, die Suse durcheinanderbringen und eine Anmeldung unmöglich machen würden (das hatte ich zuvor bereits ausprobiert). Ich melde mich als root bei Suse 9 an und erstelle die beiden Benutzer mit genau denselben Namen wie unter RH9. Es erscheint eine Warnung, dass das Verzeichnis bereits existiert und dass dessen gesamter Inhalt dem neuen Benutzer gehören wird. Das ist natürlich in Ordnung.