root auf Software raid 1, cryptsetup-luks, LVM, mit lilo

[smiler]

Hallo Leute,

Ich moechte mein bestehendes Debian 4.0 Lenny(?) auf ein Software Raid 1 umstellen. Derzeit laeuft das System auf /dev/hda. Ich habe jetzt zusaetzlich eine Platte in /dev/hdc gesteckt und erstam die RAID Devices mit einer PLatte angelegt:

Code: Alles auswählen

gandalf:~# cat /proc/mdstat 
Personalities : [raid1] 
md2 : active raid1 hdc3[1]
      79224448 blocks [2/1] [_U]
      
md1 : active raid1 hdc2[1]
      987904 blocks [2/1] [_U]
      
md0 : active raid1 hdc1[1]
      200704 blocks [2/1] [_U]
      
unused devices: <none>
gandalf:~# 

/boot soll später mal /dev/md0 werden, jetzt bleibt es erstmal auf /dev/hda1. Swap wird /dev/md1
Auf /dev/md2 habe ich jetzt mit cryptsetup ein Luks-Device ("system-crypt) und auf diesem Device ein LVM erstellt ("LVM-system"). Dort hinein drei logische Volumes (lv-root, lv-home, lv-tmp), relvant erstmal nur lv-root.
Gebootet wird mit lilo.

Verzichte ich auf das luks-device,und lege das lVM direkt auf /dev/md2 funktioniert es. ich kann problemlos das software raid booten. Lege ich nun das luksdevice an, bleibt er beim booten haengen. Ich vermute beim mounten des root-devices, ich kann es nicht genau sagen, die Meldungen kommen zu schnell und die SATA und USB-Meldungen scrollen den Rest heraus. Ich muss jedenfalls kein Passwort eingeben. Auf Jeden Fall lande ich in Busybox und dort kann ich auchmit cryptsetup das luksdevice öffnen und mit vhchange das LVM aktivieren. aber weiter weiss ich nicht.

Hat jemand so eine Kombination am laufen? Kann mir jemand weiterhelfen, mit Tips oder ähnlichem? Hier noch die /etc/fstab, die /etc/crypttab

Code: Alles auswählen

gandalf:/mnt/raid-root# cat etc/fstab |grep -v ^#
proc            /proc           proc    defaults        0       0
/dev/hda1       /boot           ext2    defaults        0       2
/dev/disk/by-uuid/84BE-2329        /media/usb0     auto    rw,user,noauto  0       0
/dev/md1			none			swap	sw,pri=1	0	0	
/dev/LVM-system/LV-root		/		ext3	defaults,noauto		0 0	

Code: Alles auswählen

gandalf:/mnt/raid-root# cat etc/crypttab 
# <target name>	<source device>		<key file>	<options>
swap	          /dev/md1		/dev/urandom		swap
system-crypt	/dev/md2	none	luks
gandalf:/mnt/raid-root# 

Irgendwelche Idenn

Vielen Dank schonmal

smiler

[meti]

Sind alle notwendigen Module in der initrd eingebaut?

[smiler]

Hi,

danke fuer die schnelle antowrt. Aber ich denke dass alle module eingebaut sind. Wenn ich im busybox vom initramfs lande kann ich die benötigten Befehle ausführen, um das luks device und das lvm darin zu aktivieren. das initrd ist das debian standard initrd.

Gruss

smiler

[pluvo]

Hi,

danke fuer die schnelle antowrt. Aber ich denke dass alle module eingebaut sind. Wenn ich im busybox vom initramfs lande kann ich die benötigten Befehle ausführen, um das luks device und das lvm darin zu aktivieren. das initrd ist das debian standard initrd.

Gruss

smiler

Hast du das initramfs neugebaut, nachdem du die Datei "/etc/crypttab" angepasst hast?

Code: Alles auswählen

update-initramfs -u -v

mfg pluvo

[smiler]

HI,

bloede Frage: muss ich dass wirklich?
Hast DU so eine INstallation wie ichsie anstrebe ud musstest DU die initrd neu bauen?

Gruss

smiler

[pluvo]

bloede Frage: muss ich dass wirklich?

Naja woher soll denn denn Debian beim booten wissen, dass deine Root-Partition verschlüsselt ist. Das steht nun mal in der "/etc/crypttab". Und diese Datei kann ja erst garnicht gelesen werden, weil sie verschlüsselt ist.

Wenn du das initramfs neubaust, wird auch die "/etc/crypttab" einbezogen.

mfg pluvo

[smiler]

Hi,

es klingt logisch was du sagst. das neu bausne der initrd muss ich aber im neuen Root machen, oder? Also per chroot reinwechseln und dann ausfuehren. Ich hatte schon ein paar Versuche, aber dananch wollte mein System immer nicht mehr booten. Ich versuche es einfach mal wieder

Danke erstmal

gruss smiler

[pluvo]

das neu bausne der initrd muss ich aber im neuen Root machen, oder? Also per chroot reinwechseln und dann ausfuehren.

Ja. Falls irgendetwas schief geht, gibt es immer noch ein Backup des initramfs.
https://www.debianforum.de/forum/viewto ... 34#p552634
Du solltest "update-initramfs" nicht zweimal hintereinander ausführen. Ansonsten hast du kein funktionierendes Backup mehr

Chroot:

Code: Alles auswählen

chroot /target
mount /proc
update-initramfs -u -v
umount /proc
exit

Vielleicht hilft dir dieser Thread:
https://www.debianforum.de/forum/viewto ... 12&t=98746

Mir fällt gerade noch ein, wie sieht deine "/etc/default/cryptdisks"-Datei aus?

Code: Alles auswählen

...
CRYPTDISKS_ENABLE=Yes
...

mfg pluvo


Edit: Um noch eine mögliche Fehlerquelle auszuschließen: Vergiss nicht die /boot-Partition vorher richtig in dein System einzubinden, bevor du mit chroot anfängst

[smiler]

Hi Pluvo,

nochmal danke fuer Deine Hilfe, aber leider wr ich am Wochenende nicht erfolgreich.
Das Updaten der initrd hatte ich genauso gemacht, wie in deinem letzten Post empfohlen. Bisher hatte ich es mit mkinitramfs gemacht, so hatte ich gehofft, dass es mit update-initramfs besser wird, aber leider erfolglos.

Ich habe debian jetzt wenigstens dazu gebracht nach dem Passwort der luks-partition zu fragen, aber nur uber MItgabe von "cryptopts=target=system-crypt,source=/dev/md2,cipher=sha256" als append in lilo.conf
Vorher wollte er auch kein Passwort von mir wissen.

Wenn die Debian-bootskripte und die initramfs Scripte es ueberhaupt unterstützen, dass das LVM auf einem verschluesseltem Device aufsetzt (tun sie das ueberhaupt?)
...
O.K. deinen link zu dem anderen Thread gelesen,also scheint es irgendwie gehen zu müssen, aber wie?

update-initramfs scheint den Zusammenhang zwischen dem EIntrag in /etc/crypttab und dem LVM auf dem letztendlich das Rootdevice aufsetzt nicht zu erkennen.

Beim Booten versucht Debian nun nach existierenden LVM-Devices zu scannen, erkennt keine, logisch sind ja alle im cryptodevice, dann greift wahrscheinlich der Bootparameter und ich muss das Passwort fuer das Device eingeben, o.k. dananch mach er aber keinen vgchange -a y mehr, sonernd ich lande merh oder weiniger gleich in busybox.

Irgendwelche Ideen, wo ich ansetzen könnte.
(Irgendwo habe ich auch mal was von dem parameter lvm=<lvm-vg> gelesen, die man in der crypptab angeben kann/soll. war auch nicht von Erfolg gekrönt.


Ich bin mit meiner Weisheit ziemlich am Ende.

Viele Gruesse

Smiler

Edit: Ich habe jetzt mal das initrd-Image ausgepackt und nirgendwo einen Hinweis auf die LVM-Devices bzw, auch das Luks-Device gefunden.Sollte es da nicht irgendwie hinetrlegt werden? Wenn ja, wo denn?

[Dm6GWYbA]

Hallo smiler,

habe auf 3 Platten verteilt 2 Softraids (R0,R5;ide;3 controller) zu laufen und / auf lvm verschlüsselt (Deb 4.). Kombiniert Ausfallsicherheit mit Datensicherheit. Allerdings verwende ich grub. Trotzdem interessiert?

Gruß
Dm6GWYbA

[pluvo]

Wenn die Debian-bootskripte und die initramfs Scripte es ueberhaupt unterstützen, dass das LVM auf einem verschluesseltem Device aufsetzt (tun sie das ueberhaupt?)

Ja, habe mehrere Systeme am laufen (Und der Debian-Installer macht das auch so.)

Beim Booten versucht Debian nun nach existierenden LVM-Devices zu scannen, erkennt keine, logisch sind ja alle im cryptodevice, dann greift wahrscheinlich der Bootparameter und ich muss das Passwort fuer das Device eingeben, o.k. dananch mach er aber keinen vgchange -a y mehr, sonernd ich lande merh oder weiniger gleich in busybox.

Ich kenne das, dass vor der Abfrage der Passphrase Debian einen LVM-Scan macht.

Edit: Ich habe jetzt mal das initrd-Image ausgepackt und nirgendwo einen Hinweis auf die LVM-Devices bzw, auch das Luks-Device gefunden.Sollte es da nicht irgendwie hinetrlegt werden? Wenn ja, wo denn?

Eigentlich schon. Bei mir steht das in der Datei cryptroot.

/tmp/initram-entpackt/conf/conf.d/cryptroot

Code: Alles auswählen

target=sda9_crypt,source=/dev/sda9,key=none,lvm=vg00-lvroot
target=sda9_crypt,source=/dev/sda9,key=none,lvm=vg00-lvswap

(Btw: Warum setzt du eigentlich Lilo ein?)

mfg pluvo

[smiler]

Hallo Leute,

danke nochmal an Euch fuer eure Antworten und hilfreichen Tips.
Das problem lag aber ganz woanders. Lilo war der Schuldige. Bei mir gab es in etwa ein aehnliches Problem wie in folgendem Bugreport beschrieben:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428329

und zwar besonders dieser Abschnitt:

> >(initramfs) _
> >(initramfs) cat /proc/cmdline
> >
> >auto BOOT_IMAGE=Linux ro root=fe01 (The information which you request)

The problem here seems to be that either lilo or lilo-installer fails to set
root to the correct path (/dev/mapper/*) and falls back to the major/minor
representation.
I doubt fixing this will be a priority for anybody (lilo seems to be pretty
much in maintenance mode), but patches are of course welcome.

> Aha! root=fe01 means that root is on the block device with major 254
> (0xfe) and minor 1 (0x01). Major 254 is device-mapper and devices are
> dynamically allocated minor numbers starting from 0. This means that
> when you setup the devices in debian-installer, you got the following
> layout:
>
> /dev/mapper/sda2_crypt (swap), major 254, minor 0
> /dev/mapper/sda3_crypt (root), major 254, minor 1
>
> Root is on /dev/mapper/sda3_crypt so lilo encoded root=fe01, but the
> next time you boot, /dev/mapper/sda3_crypt is brought up first, which
> gives it major 254, minor 0, which is why it can't be found.
>
> I'm pretty certain that everything would have worked if the root device
> would have been created first during installation
> (making it /dev/mapper/sda2_crypt with major 254, minor 0) and swap
> second.

Also so wie ich es verstanden hatte, nummeriert der Devicemapper einfach so durch, wenn er Geraete erkennt. Da ich schon einen verschluesselten Swap und TMP-Bereich hatte. Wurde der nun von mir angelegte verschluesselte Root-Bereich einfach hintendran gehängt. Und mit der so vergebenen Nummer von Lilo im Bootsektor reingeschrieben.
Wurde nun gebootet, war das Root-device logischerweise das zuerst erkannte (Device-Mapper-)Device und bekamm die niedrigste Nummer. die nun nicht mehr mit der von Lilo erwarteten Devicenummer übereinstimmte. Somit landete ich in Busybox. Mountete ich nun manuell und entschluesselte die Partition und mountete das root devices konnte ich nach Eingabe von "exit" in Busybox weiterbooten.
Die Lösung war einfach mal ohne verschluesslten swap und temp das Ausgangssystem zu booten. Dann hatte das zukuenftige Root-device die gleiche Nummer wie beim naechsten Booten. Dann musste nur noch lilo aufgerufen werden und alles war o.k. als ob es nie ein Problem gegeben haette.

Mein verschluessltes LVM laeuft nun wunderbar auf softareraid. Danke nochmal an alle.

Warum ich lilo benutze? Nach allem was ich gehoert habe kann grub doch erst ab Grub2 "richtig" vom Raid 1 booten, oder bin ich da veraltet? Und fuer grub2 habe ich nicht so die richtige Doku gefunden fuer ein Aufsetzen von Raid/LVM-Boot. Ausserdem ist Grub2 noch ziemlich neu (das zwar schon ziemlich lange, aber ich hoffe, die Entwicklung wird nochmal fertig). Grub ist mir schon lieber als lilo

@Dm6GWYbA:
Du machst SW Raid5?
Was hast Du fuer ein System und wie bist Du mit der Datenrate zufrieden? Ich will fuer den Datenbereich auch noch ein Raid5 aufsetzen (verschluesselt) und bin mir nicht sicher, ob mein Athlon 700 mit 256 MB Ram da nicht heillos ueberfordert ist. Wobei ein Grossteil des Traffics eh ueber wlan geht, also ich habe kein GBit Netzwerk. Ist SW Raid 5 von der Performance akzeptabel?

Viele Gruesse Smiler

[pluvo]

Hallo smiler,

Warum ich lilo benutze? Nach allem was ich gehoert habe kann grub doch erst ab Grub2 "richtig" vom Raid 1 booten, oder bin ich da veraltet?

Grub (0.97) kann von RAID1 booten. Allerdings kann Grub (0.97) noch nicht von RAID5 booten.
(So habe ich das mal in einer Red Hat Doku gelesen. Irgendwo hier: http://www.redhat.com/docs/manuals/)

Das heißt, dass deine /boot-Partition (die ja sowieso ein zusätzliche Partition ist, wegen der Verschlüsselung) als RAID1 laufen muss/sollte.

mfg pluvo

[smiler]

Hi pluvo,

hm naja booten von Raid 1 kann grub, o.k. aber fuehrt folgender Text:

Important

If GRUB is installed on a RAID 1 array, the system may become unbootable in the event of disk failure. An unsupported workaround is provided online at the following URL:

http://www.dur.ac.uk/a.d.stribblehill/m ... _grub.html

(Der Link ist uebrigens tot)
unter http://www.redhat.com/docs/en-US/Red_Ha ... lling.html

den Sinn eines Raids nicht ad absurdum?



Gruss

smiler

[Dm6GWYbA]

@Dm6GWYbA:
Du machst SW Raid5?
Was hast Du fuer ein System und wie bist Du mit der Datenrate zufrieden? Ich will fuer den Datenbereich auch noch ein Raid5 aufsetzen (verschluesselt) und bin mir nicht sicher, ob mein Athlon 700 mit 256 MB Ram da nicht heillos ueberfordert ist. Wobei ein Grossteil des Traffics eh ueber wlan geht, also ich habe kein GBit Netzwerk. Ist SW Raid 5 von der Performance akzeptabel?

Also ich bin mit der Performance zufrieden. Cpu ist:
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 10
cpu MHz : 1005.083
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse up
bogomips : 2011.56

MD5-Raid liefert:
Timing cached reads: 272 MB in 2.01 seconds = 135.35 MB/sec
Timing buffered disk reads: 98 MB in 3.04 seconds = 32.25 MB/sec

Falls mal ne Platte ausfällt, dauert das Rebuild (220 GB) ca. 50 Minuten.

RAM =512 mb; durcschnittl 80 mb belegt; Cpu im Schnitt bei 8% Last