Ich habs jetzt nochmal mit Debian 6 probiert:
- System über die graphische Installation von CD auf eine separate
Platte
- Installation in eine Partition in ein verschlüsseltes lvm-Volume
Das Löschen der 500 GB Platte hat sage uns schreibe 8 Stunden gedauert.
Merkwürdig war, daß man in der von grün nach rot wechselnde Zugriffs-LED
im Wechselrahmen nur ein winziges rotes Lichtchen im hellen grünen Licht
mehr erahnen, als sehen konnte. Was die Mühle da gemacht hat, bleibt
rätselhaft.
Als das OS dann endlich drauf war, wollte ich die ebenfalls
verschlüsselte lvm-Platte mit Ubuntu 10.04 mounten - Debian weigert sich
standhaft, die lvm-Partition als gültig anzuerkennen, während die
Boot-Partition der Platte zugreifbar ist.
Gegenprobe:
Ubuntu 10.04 gebootet und die Debian-Platte gemountet - geht ohne
Probleme.
Was soll das denn? Ist Debian auf die Canoniker sauer und erkennt deren
lvm-Platten nicht an?
Möglicherweise eine Frage der Versionen vom lvm. Debian hinkt gewöhnlich
etwas hinterher während Ubuntu vorneweg läuft.
Das Ubuntu 10.04 schon gute 2 Jahre alt. Debian 6 kam erst im Februar
2011 raus.
Uhu Uhuhu schrieb:
> Debian weigert sich
> standhaft, die lvm-Partition als gültig anzuerkennen
Wie äußert sich das?
Versuch' mal
An den lvm-Versionen sollte es eigentlich nicht liegen:
Ubuntu 10.04
LVM version: 2.02.54(1) (2009-10-26)
Library version: 1.02.39 (2009-10-26)
Driver version: 4.15.0
Debian 6.0.4
LVM version: 2.02.66(2) (2010-05-20)
Library version: 1.02.48 (2010-05-20)
Driver version: 4.15.0
Lukas K. schrieb:
> Wie äußert sich das?
Debian meint, das Ubuntu-Volume sei invalid
> # vgchange -a y
Ich möchte nicht das Ubuntu-Volume schlachten, bevor ich sicher bin, daß
ich es nicht mehr brauche.
Uhu Uhuhu schrieb:
> Debian meint, das Ubuntu-Volume sei invalid
Meint das ein Dateimanger?
Nautilus weigert sich bei mir seit jeher recht hartnäckig, LVMs ohne
nachhilfe zu mounten.
Was sagt ?
pvscan findet nur das Debian-Volume.
Ein Mount-Versuch fragt nach dem User-Paßwort, aber nicht nach der
lvm-Paßphrase - lvm scheint deas Volume also im ganz frühen Stadium
schon nicht zu erkennen, oder wird gar nicht erst gefragt und der
normale Linux-Mount muß natürlich fehlschlagen.
> Nautilus weigert sich bei mir seit jeher recht hartnäckig, LVMs ohne
> nachhilfe zu mounten.
Unter Ubuntu 10.04 mault er nach dem Anklicken ein bischen rum - no
mountable volume, oder sowas ähnliches -, aber hinterher zeigt er die
Patitionen im Volume links an und man kann rein.
Uhu Uhuhu schrieb:
> aber nicht nach der
> lvm-Paßphrase
Der LVM macht keine verschlüsselung.
Darum kümmert sich luks.
Versuche mal das Laufwerk 'zu Fuß' schritt für schritt zu mounten.
1 | # cryptsetup luksOpen <verschlüsselte Partition>
| 2 | # pvscan
| 3 | # vgscan
| 4 | # lvscan
| 5 | sollten nun das LVM finden
| 6 | #vgchange -a y
| 7 | nun kann man die verschlüsselten Paritionen aus /dev/mapper/* mit herkömmlichen Mitteln mounten
|
Wenn dir Debian zunehmend auf die Nerven fällt, guck' dir mal Arch an ;)
So, jetzt sind ein paar mehr Informationen rausgekleckert: 1 | root@lx6:/home/inet# cryptsetup luksOpen /dev/sdb5 lx5
| 2 | Geben Sie den Passsatz für /dev/sdb5 ein:
| 3 | root@lx6:/home/inet# pvscan
| 4 | Found duplicate PV Cr20MGKFAZd4JZrNCGxoUmOpqLo0h7zL: using /dev/dm-3 not /dev/dm-0
| 5 | PV /dev/dm-3 VG lx6 lvm2 [465,52 GiB / 0 free]
| 6 | Total: 1 [465,52 GiB] / in use: 1 [465,52 GiB] / in no VG: 0 [0 ]
| 7 | root@lx6:/home/inet# vgscan
| 8 | Reading all physical volumes. This may take a while...
| 9 | Found duplicate PV Cr20MGKFAZd4JZrNCGxoUmOpqLo0h7zL: using /dev/dm-3 not /dev/dm-0
| 10 | Found volume group "lx6" using metadata type lvm2
| 11 | root@lx6:/home/inet# lvscan
| 12 | Found duplicate PV Cr20MGKFAZd4JZrNCGxoUmOpqLo0h7zL: using /dev/dm-3 not /dev/dm-0
| 13 | ACTIVE '/dev/lx6/root' [457,96 GiB] inherit
| 14 | ACTIVE '/dev/lx6/swap_1' [7,56 GiB] inherit
|
Wie kommt es zu dem duplicate PV? Beide Platten haben dieselbe
Paßphrase - das dürfte doch eigentlich nicht der Grund sein, oder?
lx6 ist das Debian-Volume.
Uhu Uhuhu schrieb:
> Paßphrase - das dürfte doch eigentlich nicht der Grund sein, oder?
Nein, LVM vergibt UUIDs, anhand derer die PVs identifiziert werden.
Taucht das 'duplicate PV' auch bei noch gesperrtem Ubuntu-LVM auf?
Ist debian so nett und legt in /dev/mapper/* verständliche Symlinks auf
/dev/dm-* ab?
Lukas K. schrieb:
> Taucht das 'duplicate PV' auch bei noch gesperrtem Ubuntu-LVM auf?
Du meinst ein pvscan vor dem cryptsetup luksOpen /dev/sdb5 lx5?
Nein, das pvscan nimmt keine Notiz von der Ubuntu-Platte.
Uhu Uhuhu schrieb:
> Du meinst ein pvscan vor dem cryptsetup luksOpen /dev/sdb5 lx5?
Jap, dann wüssten wir, ob der duplicate PV-Fehler auch tatsächlich
Ubuntu-induziert ist. Meckert pvscan auf Ubuntu auch über doppelte PVs?
Meine persönliche Erfahrung in der Kooperation mit debian-Anwendern hat
gezeigt, dass unter Debian mitunter 'unerklärliche' Dinge geschehen, wie
sie mir unter Arch nie untergekommen sind. Irgendwie müssten sich die
totgepatchten uralt-Pakete ja auswirken ;) Meine bescheidene,
subjektiv-unbegründbare Meinung zu debian.
Nein, pvscan auf Ubuntu meckert nicht doppelte PVs,
Bevor ich die Debain-Platte (durch Klick auf das Physical Volume im
Nautilus) gemountet habe, sieht pvscan unter Ubuntu die D-Platte auch
nicht.
Nach dem Klick auf das PV kommt ein Fehler:
Unable to mount 500 GB LVM2 Physical Volume
Not a mountable file system
Anschließend erscheint die D-Partition im Nautilus und ich kann rein.
Debian hat seit eh und je gewisse Eigenheiten - da scheinen sie sich
auch über die Jahre treu geblieben zu sein, in denen ich ihnen untreu
war...
Ich seh mir mal das Arch an. Danke für die Hilfe.
Uhu Uhuhu schrieb:
> Ich seh mir mal das Arch an. Danke für die Hilfe.
Um die Vorfreude zu steigern: LVM ist bei dem Live-Installer von Arch
dabei ;)
Ich hab mir gerade den Wikipediaartikel darüber reingezogen - die
Konfiguration scheint völlig anders, als bei Debian/Ubuntu zu sein;
nicht schön, denn ich habe mir über die Jahre so einiges
zusammengebastelt, um das Ubuntu so hinzubiegen, wie es mir gefällt.
Das KISS-Prinzip hat natürlich was für sich, aber meine Lust, wieder be
Null anzufangen, ist ziemlich begrenzt.
Ich werde wohl doch bei Ubuntu bleiben und mir eine neue 12.04-Platte
zusammenstellen.
Uhu Uhuhu schrieb:
> Das KISS-Prinzip hat natürlich was für sich, aber meine Lust, wieder be
> Null anzufangen, ist ziemlich begrenzt.
Soo schlimm ist's nun wieder auch nicht - es ist ja immer noch Linux.
Die Distributionsspezifischen Eigenheiten von Arch beschränken sich
primär auf die /etc/rc.conf und pacman.
https://wiki.archlinux.de/title/Arch_vs._Distribution_X#Arch_vs_Debian
>Arch ist einfacher als Debian
Der Arch-Einstieg mag nicht unbedingt einfach und reibungslos sein, wenn
man den aber gemeistert hat wird man mit einem stabilen System belohnt,
welches nur sehr wenig Zuwendung benötigt. Rolling release wird man auch
nicht missen wollen: Die Frage, ob nach dem nächsten Distro-upgrade noch
alles Funktioniert stellt sich nicht.
Lukas K. schrieb:
> Um die Vorfreude zu steigern: LVM ist bei dem Live-Installer von Arch
> dabei ;)
Sieht mir nicht so aus. Von lvm finde ich da überhaupt nichts. (Es ist
das 2011.08.19-ISO-Image)
>Von lvm finde ich da überhaupt nichts.
Nanun? Der ganze lvm-krams (pv*/vg*/lv*) ist doch vorhanden. cryptsetup
auch. Klar, LVMs anlegen etc. kann der Arch installer nicht. Das ist dem
Anwender selbst überlassen. (Gibt Anleitungen und ist kein Hexenwerk)
Ok, ich habs im Wiki gefunden. Allerdings drehe ich mich seit 3 Stunden
im Kreis, weil ich mit der Beschreibung einfach keine verschlüsselte
Platte hinbekomme.
Was ich gemacht habe:
1. Versuch
- Platte manuell partitioniert (200 MB boot, linux-lvm auf dem Rest)
- Restliche Partitionen mit ..create angelegt
So weit hat das prima funktioniert. Dann fand ich einen Hinweis, daß das
auch von /arch/setup unterstützt wird. Dachte mir, das sei vielleicht
einfacher...
2. Versuch
/arch/setup gestartet
- Platte neu partitioniert mit einer 200 MB Boot-Partition (ext2)
mit einer Linux-LVM-Partition auf dem Rest
Der Versuch, mit Manually configure weiter zu machen zeigt mir nur die
Boot-Partition an und eine IDE-Platte an, die ich aber unberührt lassen
will, während ich von der lvm-Partition nichts sehe.
Wenn ich dann DONE auswähle mault er, daß keine Root vorhanden ist -
woher auch.
Ich habe das Spielchen 4, oder 5 mal durchexerziert - immer mit dem
gleichen Mißerfolg.
Die Hinweise im "Official Installation Guide" zu dem Thema
Verschlüsselung sind aber auch sowas von dürftig und mißverständlich...
Noch so ein kleiner Gag am Rande: die Zuteilung der /dev-Files für die
beiden Platten (eine IDE und eine sata) scheint zufällig zu sein - da
muß man verteufelt aufpassen, daß man sich nicht noch was platt macht.
Uhu Uhuhu schrieb:
> Noch so ein kleiner Gag am Rande: die Zuteilung der /dev-Files für die
> beiden Platten (eine IDE und eine sata) scheint zufällig zu sein
Na und? Nicht umsonst legt udev seit geraumer Zeit in
/dev/disk/by-{label,uuid} eindeutige Verknüpfungen an. Mount versteht
auch Angaben nach UUID= und LABEL= Wird leider nur selten gescheit
kommuniziert (wo denn auch) Das /dev/sd*-Rätselraten ist obsolet.
Uhu Uhuhu schrieb:
> während ich von der lvm-Partition nichts sehe.
Wie gesagt, der arch-installer(/arch/setup) kann keine LVMs anlegen. Das
musst du selbst (auf einer anderen Shell) machen. Ich bin damals
erfolgreich nach http://www.pindarsign.de/webblog/?p=767 vorgegangen.
Bei Arch muss man wirklich sehr viel 'selber machen', doch ist dies
meistens nicht sehr schwer. Zum Verständnis trägt's auf jeden Fall bei.
Lukas K. schrieb:
> Na und? Nicht umsonst legt udev seit geraumer Zeit in
> /dev/disk/by-{label,uuid} eindeutige Verknüpfungen an.
Ich rede vom Setup - dort hast du nur /dev/sdX und wehe, du merkst
nicht, daß er beim nächsten Versuch gerade mal wieder die Karten
gemischt hat ;-)
> Ich bin damals
> erfolgreich nach http://www.pindarsign.de/webblog/?p=767 vorgegangen.
Danke, genau sowas suchte ich.
> Bei Arch muss man wirklich sehr viel 'selber machen', doch ist dies
> meistens nicht sehr schwer. Zum Verständnis trägt's auf jeden Fall bei.
Ja, das sehe ich auch so. Zuweilen ist das Wissen über die Bedienung
irgend welcher GUIs kaum weniger Umfangreich, als das, was man wissen
muß, um die Sache auf der Kommandozeile hinzubekommen.
Mit der Anleitung hab ichs hinbekommen. Vielen Dank.
Jetzt muß ich nur noch das Problem mit den hopsenden /dev-Namen lösen.
Nach der Installation war /dev/sda natürlich prompt /dev/sdb und das
natürlich noch abhängig davon, ob ich das IDE eingeschaltet habe, oder
nicht.
> /dev/disk/by-{label,uuid} eindeutige Verknüpfungen an.
Wo muß ich das wie verdrahten, damit er beim Boot unter allen Umständen
die richtige Platte findet?
Uhu Uhuhu schrieb:
> Wo muß ich das wie verdrahten, damit er beim Boot unter allen Umständen
> die richtige Platte findet?
Meine Kernel-kommandozeile von Grub sieht so aus: 1 | kernel /vmlinuz-linux root=/dev/mapper/store-root cryptdevice=/dev/disk/by-uuid/dcf44679-efd4-442c-b5c2-9e4fc5bd9d83:store ro
|
die cryptdevice-uuid ist die uuid des Luks-containers; :store ist bei
mir der Name der VG, in der das root-Gerät liegt. Das root-gerät kannst
du entweder, wie ich über den Name von VG und LV spezifizieren, oder
über die uuid (UUID=), oder über das LABEL.
In der /etc/fstab mounte ich anhand des Labels; UUID ginge analog. 1 | LABEL=usbhome /home ext2 defaults 0 1
| 2 | LABEL=usboot /boot ext2 defaults 0 1
| 3 | LABEL=usbroot / ext2s defaults 0 1
|
Wie du siehst, mit den wackeligen /dev/sd* braucht man sich wirklich
nichtmehr herumschlagen. Schöne neue Welt.
Ich habe mir die Platte irgendwie geschrottet - sie bootet im Moment
nicht.
Ist in deinem System die uuid von usbroot ==
dcf44679-efd4-442c-b5c2-9e4fc5bd9d83 ?
Wenn nein: Wo finde ich die die uuid des Luks-containers, wenn ich die
Arch Disk nur extern mounten kann?
Die Meldungen, die beim Boot kommen lauten:
1 | ...
| 2 | ::Running Hook [encrypt]
| 3 | Waiting 10 seconds for device /dev/disk/by-uuid/52b2a8a2-024c-4417-912f-1314a22dc903...
| 4 | ::Running Hook [lvm2]
| 5 | Activating volumes...
| 6 | No volume groups found
| 7 | Waiting 10 seconds for device /dev/mapper/Arch01-root...
| 8 | Root device ´/dev/mapper/Arch01-root´ dooesn't exist. Attempting to create it.
| 9 | ERROR: Unable to determine major/minor number of root device ´/dev/mapper/Arch01-root´
|
Ein ls /dev/mapper zeigt nur den control Eintrag.
Der grub-Eintrag lautet: 1 | title Arch Linux
| 2 | root (hd0,0)
| 3 | kernel /vmlinuz-linux root=/dev/mapper/Arch01-root cryptdevice=/dev/disk/by-uuid/52b2a8a2-024c-4417-912f-1314a22dc903:Arch01 ro
| 4 | initrd /initramfs-linux.img
|
in /etc/fstab steht: 1 | UUID=128bb137-2e0f-4ba1-bed9-549b8840d2db /tmp ext4 defaults 0 1
| 2 | UUID=52b2a8a2-024c-4417-912f-1314a22dc903 / ext4 defaults 0 1
| 3 | UUID=9b355707-862f-48ee-8776-92dfc528d1e0 swap swap defaults 0 0
| 4 | UUID=dca62276-5f40-4538-8d26-85ec76813fcd /boot ext2 defaults 0 1
| 5 | UUID=fcb57ca6-24f1-4750-9699-f176fd49359f /home ext4 defaults 0 1
|
Das sieht stark danach aus, daß die uuid für den luks-contrainer nicht
stimmt.
Wenn ich die Platte unter Ubuntu mounte und lvm inspiziere, bekomme ich
folgende Ausgaben: 1 | $ sudo pvscan
| 2 | PV /dev/mapper/udisks-luks-uuid-66fc0e00-de72-4e2b-8a2b-281460f9630c-uid1000 VG Arch01 lvm2 [465.57 GiB / 0 free]
| 3 | PV /dev/mapper/sda5_crypt VG lx5 lvm2 [465.52 GiB / 48.00 MiB free]
| 4 | Total: 2 [931.09 GiB] / in use: 2 [931.09 GiB] / in no VG: 0 [0 ]
| 5 | $ sudo vgscan
| 6 | Reading all physical volumes. This may take a while...
| 7 | Found volume group "Arch01" using metadata type lvm2
| 8 | Found volume group "lx5" using metadata type lvm2
| 9 | $ sudo lvscan
| 10 | ACTIVE '/dev/Arch01/root' [10.00 GiB] inherit
| 11 | ACTIVE '/dev/Arch01/swap' [4.00 GiB] inherit
| 12 | ACTIVE '/dev/Arch01/tmp' [4.00 GiB] inherit
| 13 | ACTIVE '/dev/Arch01/home' [447.57 GiB] inherit
| 14 | ACTIVE '/dev/lx5/root' [448.36 GiB] inherit
| 15 | ACTIVE '/dev/lx5/swap_1' [17.11 GiB] inherit
|
Ich werde jetzt mal 66fc0e00-de72-4e2b-8a2b-281460f9630c für das
cryptdevice bei grub eintragen...
Das wars, jetzt geht die Hütte wieder...
Der Vollständigkeit halber:
Die luks-UUID einer Partition/eines Gerätes kann man mit "cryptsetup
luksDump" bzw. "cryptsetup luksUUID" ermitteln.
Uhu Uhuhu schrieb:
> UUID=128bb137-2e0f-4ba1-bed9-549b8840d2db /tmp ext4 defaults 0 1
Nanun, es ist eigentlich üblich /tmp als tmpfs (ramdisk) zu mounten.
Lukas K. schrieb:
>> UUID=128bb137-2e0f-4ba1-bed9-549b8840d2db /tmp ext4 defaults 0 1
> Nanun, es ist eigentlich üblich /tmp als tmpfs (ramdisk) zu mounten.
Das stand in der fstab, als ich die Platte auf dem Ubuntu-System
gemountet habe. Da habe ich nichts selbst gemacht.
Die /etc/mtab - vom Setup erzeugt - sieht so aus (auch von Ubuntu aus
gesehen): 1 | proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
| 2 | sys /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
| 3 | udev /dev devtmpfs rw,nosuid,relatime,size=10240k,nr_inodes=506742,mode=755 0 0
| 4 | run /run tmpfs rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755 0 0
| 5 | /dev/mapper/Arch01-root / ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
| 6 | devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
| 7 | shm /dev/shm tmpfs rw,nosuid,nodev,relatime 0 0
| 8 | tmpfs /tmp tmpfs rw,nosuid,nodev 0 0
|
Beim Anlegen der Partitionen habe ich an den Blog-Eintrag gehalten - nur
habe ich tmp deutlich größer gemacht, als es dort vorgeschlagen wird.
Komischerweise fehlt die /tmp-Partition in der /etc/fstab für Ubuntu
völlig.
Ich weiß nicht, ob es so geschickt ist, das tmp-Verzeichnis in eine
ram-Disk zu legen - ich benutze es relativ häufig für Dinge, die ich nur
vorübergehend brauche, und mich nicht um Entsorgung kümmern will...
Nachtrag zum tmpfs: Die erste Zeile der /etc/fstab hatte ich oben
weggelassen - es ging mir ja um die uuids. Sie lautet: 1 | tmpfs /tmp tmpfs nodev,nosuid 0 0
|
Welche Folgen die Doppeldefinition hat, ist mir nicht klar.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
|
Thread beobachten
Seitenaufteilung abschalten