Siduction Forum
Siduction Forum => Upgrade Warnings => Topic started by: bluelupo on 2014/09/23, 20:54:45
-
Hallo zusammen,
momentan ist Vorsicht beim d-u bei Einsatz von verschlüsselten LUKS/dm-crypt Partitionen oder verschlüsselten Logical Volume (LVM) angesagt. Mindestens zwei User berichten von unbootbaren Systemen. Es liegt der Verdacht nahe das der aktuelle systemd mit LUKS/dm-crypt Probleme hat, d.h. es kann kein verschlüsseltes Volume geöffnet werden beim Booten. Ein manuelles öffnen und nachfolgenden mounten funktioniert jedoch unter Umständen.
---Translated with Google ---
Hi all,
Currently you should be careful running d-u when you use LUKS/dm-crypt encrypted partitions or logical volumes (LVM).
At least two users report of unbootable systems. There is the suspicion that the current systemd with LUKS/dm-crypt has problems, ie it can not open an encrypted partition or volume at boot time. Opening and mounting manually may work under certain circumstances.
-
Mein momentaner Workaround: Livesystem booten, alles ind er Crypttab mit Lattenzaun (#) deaktiveren und das System neu starten. Dann alle Partitionen per luksOpen öffnen und dann einzeln mounten.
My way to deal with it at the moment: Boot live-system and deactivate everything in crypttab with # .
Then reboot and open every single partition with luksOpen and then mount all drives.
-
Hi Lanzi,
hast du schon einen Bugreport dazu eröffnet? Wenn nein bitte einen erstellen. Danke!
Hi Lanzi,
Have you ever opened a bug report on this? If not please create one. Thank you!
-
Ich habe jetzt auf 2 Rechner sowohl als User und auch als Admin versucht reportbug zur Mitarbeit zu bewegen. Er bricht immer wieder ab.
reportbug --configure
Attempt to unlock mutex that was not locked
Die einzige Angabe, die eventuell meinerseits falsch sein könnte ist der proxy/firewall (seltsam, dass das gleichgesetzt wird). Ich gebe hier die Adresse miener Fritzbox ein: http://192.168.178.1
Habe auch schon "Enter" als Eingabe versucht... mutex bleibt unverschlossen... was auch immer das heißt...
Geht das auch anders? An welche Email kann ich meine Bugs senden?
-
Hi Lanzi,
bitte in deinem $HOME die .reportbugrc löschen und danach sollte nochmals die Config durchlaufen werden (nicht als root) wenn du reportbug aufrufst (.reportbugrc wird dann erstellt).
Hier meine funktionierende .reportbugrc.
reportbug_version "3.48"
mode standard
ui text
offline
email "deine_mail@adresse.de"
smtphost "smtp_server_deines_providers"
smtpuser "dein_smtp_user_beim_mailprovider"
-
die Datei oder das Verzeichnis gibt es auf meinem Rechner nicht! Vermutlich wirde sie noch nicht angelegt.
apt-get purge bringt auch nichts, nach einem erneuten Installieren ist die Fehlermeldung immer noch da!
-
Hi Lanzi,
dann nimm das grafische Tool Reportbug-NG im Menü "System" (evtl. vorher installieren, Paket reportbug-ng).
Package: reportbug-ng
Version: 1.31
Installed-Size: 344
Maintainer: Bastian Venthur <venthur@debian.org>
Architecture: all
Depends: python, python:any (>= 2.7.5-5~), python-debianbts (>= 1.0), python-qt4, xdg-utils, xterm, python-apt (>= 0.7.93)
Description-en: Easy to use alternative to Debian's classic reportbug
Reportbug-NG is a graphical interface using Qt for searching, filtering,
reporting or manipulating bugs in Debian's Bug Tracking System.
Description-md5: fbec04b054bf33e3b5925e1d920fc888
Homepage: http://reportbug-ng.alioth.debian.org/
Section: utils
Priority: optional
Filename: pool/main/r/reportbug-ng/reportbug-ng_1.31_all.deb
Size: 64426
MD5sum: f553f2ed5803a97bf03788a7d6a43c0c
SHA1: cc2f10f6bb00da931fd898ce89a015a42f94c562
SHA256: 245c0eea4610d1a9a6814a45764dbc73413a9f6d2c6c8c6f3e940863d0a6ea1e
-
@bluelupo: habe ich letzte Woche noch getan. mit NG klappte es besser.
ANsonsten habe ich hier noch genatwortet: http://forum.siduction.org/index.php?topic=4967.new#new
-
@Lanzi: Super, freut mich das du einen Bugreport verfassen konntest. Hast du einen Link, das dies der geneigte User mitverfolgen kann.
-
ehrlich gesagt nein... ich hatte die Email nicht aus dem Programm senden können (der wollte irgendwie nicht auf den web.de smpt zugreifen), sondern habe sie kopiert und mit thunderbird abgesendet.
-
bitte - lasst doch das mailgedöns in reportbug einfach unkonfiguriert, dann erfolgt der fallback auf debian und das geht immer
-
@Alf:
ja, das ist wohl zu spät...
Ist einfach ein sperriges und dickköpfiges Programm. Fallback gib g mit reportbug garnicht, mit NG musste ich nen Mailprovider angeben. Alles toll für Freaks und Leute die ganz viel Zeit haben das 10 mal zu probieren, bis mal irgendeine Konfiguration geht...
Sorry, wenn der Frust gerade hier ausbricht, aber zu all meinen Problemen, die ich hatte/ habe ist die Motivation mich mit dem (sehr wichtigen) Bigreportprogramm rumzuschlagen ehrlich gesagt letzte Woche nicht sehr hoch gewesen.
Ich habe nen Job, der hin nd wieder sehr viel zeit kostete und dazu ein sehr wichtiges WOE gehabt... da kann ich nicht mehr als 90min mit dem Verfassen eines Bugreports verbringen.
-
Hi Lanzi,
ich kann deine Gründe nachvollziehen, aber Bugreports erstellen ist wichtig bei der Beseitung des Fehlers durch den Entwickler. Klar ist es nervig wenn etwas nicht funktioniert so wie es eigentlich sein sollte. Wenn du es einmal erfolgreich durchgefürhrt hast klappt's beim nächsten Bugreport schon deutlich stressfreier ;-)
Hier ein paar Links zum Handling für das Erstellen von Fehlerberichten:
http://got-tty.org/archives/debian-eine-kleine-anleitung-fuer-das-bugreporting.html
https://wiki.debian.org/HowtoUseBTS
http://raphaelhertzog.com/2011/07/11/7-tips-to-file-useful-debian-bug-reports-and-get-your-problem-solved/
-
hast natürlich 100%ig recht :-)
War genervt von der Gesamtsituation.
Die neue Systemd beta brachte übrigens noch nichts.
-
Regarding the OP:
IMHO the problem is not systemd but the initramfs – at least in my case
Reasoning: During d-u, kernel, initramfs and systemd get updated.
After d-u I cannot boot with new kernel but with the old kernel – and the new systemd. Besides the error occurs before systemd is invoked.
Looking at the screenshots it seems that initramfs is missing essential stuff to handle cryptsetup.
I attach two screenshots with cryptsetup broken (kernel 3.16.3) and working (kernel 3.15.6).
For the crappy quality of the screenshots: the board software is set to allow maximum 192kbyte of attachments.
Hinsichtlich des OPs:
Meiner Meinung nach ist das kein Problem von systemd sondern von initramfs – zumindest in meinem Fall
Begründung: Während eines d-u werden kernel, initramfs und systemd aktualisiert.
Nach dem d-u kann ich mit dem neuen Kernel nicht booten – aber mit dem alten Kernel und dem neuen systemd. Zudem tritt der Fehler auf, bevor systemd zum Tragen kommt.
Beim Betrachten der Screenshots scheint es, dass initramfs Essentielles fehlt, um cryptsetup zu handhaben.
Ich hänge zwei Screenshots mit nicht-funktionierendem (Kernel 3.16.3) und funktionierendem cryptsetup (Kernel 3.15.6).
Zur schlechten Qualität der Bilder: die Forensoftware gestattet derzeit eine maximal Anhanggröße von 192kbyte insgesamt.
-
nur zum Spass: als root - update-initramfs -u -k all
und dann sollte alles Wölkchen sein.
-
Der Vorsicht halber aktualisierte ich initramfs nur für den neuesten Kernel. Resultat: unverändertes Verhalten.
Being careful I only updated the latest kernel. Result: nothing changed.
-
How can I use melmarkers command only for the last kernel?
I tried an older Kernel 3.15 and it didnt't change anything.
Hier keine Änderung mit altem Kernel.
Wie muss ich Alfs Konsolenbefehl verändern, damit es nur den aktuellen Kernel anpasst.
-
@ Lanzi: try update-initramfs -u -k <tab>
-
so if the behaviour not change after the update i would suggest to examine the working and not working initrd's - unpack and diff them may be a good idea. Only a wild guess, eventually one should add a few modules to grub too with the new initramfs-tools.
Saying so, we like the new initramfs-tools, but it was a jump from stone-edge to now within a release, so there may be bugs.
-
I know, its not necessary to say, but to quote a german saying: better say thank you one time to many - then one time to few! (poorly translated from german: Es ist immer besser sich einemal zu viel zu bedanken, als einmal zu wenig!)
Thanks for the help everybody here is giving freely and the patience that is surely sometimes difficult to find.
Even if we have sometimes problems with our belovered distribution, there is always a helping hand very close, and if I may add, to nearly every hour of the day!
So thanks to everybody, and I am surewe will fix this problem one day!
-
@nadar: das ist kein longstanding bug mit den Bildern, das ist gewollt so
ein über verschiedene Foren-SW gleicher bug ist unwahrscheinlich, oder. Man kann das aber mit mediacru.sh etc pp umgehen, die Bilder müssen nicht auf unserem Server rumgammeln
EDIT: zum ursprünglichen Problem: in fixes liegt noch ein initramfs-tools 0.117.2~really.. rum. Eventuell das mal probieren.
-
@melmarker: Falls du dich auf meine Kommentare im IRC beziehst: Ich glaube nicht dass es gewollt ist, dass die Forensoftware bemängelt, dass die Anhänge zu groß sind – und gleichzeitig allen eingegebenen Text unwiederbringlich verliert.
Zudem finde ich es sinnvoller, Bilder am gleichen Platz zu hosten wie die anderen Inhalte. Ich sehe gelegentlich ältere Forenthreads, die Bilder (nicht mehr) beinhalten, die bei irgendwelchen Hostern hinterlegt worden waren.
OnTopic: initramfs-tools_0.117.2~really~0.116_all.deb habe ich bereits gestern Vormittag installiert. Hat nichts gebracht.
-
I had this problem. Installed paintitblack on a laptop with enctypted root, swap and home using lvm containers, following the instructions in the siduction manual (using same names for volumes). For a while, I was forced to select the distribution kernel from the grub menu when booting, until I found time to look into the problem.
update-initramfs was complaining of no entry in /etc/crypttab, and failing to install cryptsetup to the initrd. Looking through /usr/share/initramfs-tools/hooks/cryptroot, I saw a reference to /usr/share/doc/crtyptsetup/README.initramfs, and read it.
Can now boot with newer kernels since adding the following to my empty /etc/crypttab
cryptroot /dev/mapper/vg-crypt none luks
and doing
update-initramfs -u -k <latest installed kernel>
-
@graver: thanks! This worked on my netbook (but I didn't dare to do it on my main box. :) )
-
tl;dr: doesn't work for more then one crypted LVM
On the main box where I have two encrypted LVM and up to now only the non-root is in the crypttab.
I added the cryptroot to the crypttab before a d-u where a new kernel was to be installed. Alone during the d-u I was asked for the password for cryptroot 6 times. After restarting the box it still could not unlock cryptroot.
At booting with kernel 3.15-7 I needed several attempts. Although unlocking from Initramfs worked fine it seemed that systemd asked mostly for the passwords of both crypted LVMs at the same time and so I had to guess which password to enter first. After finally having the box booting I removed cryptroot from crypttab again. Doing so I was asked two times more the password for the cryptroot while using a root shell.
-
@graver: please could you help:
The situation gets worse from DU to DU, no I have only to trys to enter the password, after that keyboardcommands are ignored. So I mount everything now after starting, wich is a pain in the... fingers... ;-)
I read the manual and your post, but i do not understand everything, since my crypttab is very different!
You wrote yours is empty???
My crypttab
disk1 UUID=xxxxx170-212d-4deb-9878-75ca6e0e5133 none luks
disk2 UUID=xxxxx66b-3cf6-42d5-a93c-b91d95a71f2a none luks
disk1-backup UUID=xxxxx7cc-c63a-41af-b7a9-6515b19b835e none luks
disk2-backup UUID=xxxxx872-4be8-40c4-8ba5-b4e6b89eb877 none luks
So when I add your line, it should be something like this, I suppose:
cryptroot /dev/mapper/disk1 none luks
cryptroot /dev/mapper/disk2 none luks
Should I enter this below my entries? Should I delete my entries??? (which does not make any sense to me)
-
Hi Lanzi,
welche Einträge hast du in deiner crypttab drinnen aktuell? Ohne wird es nicht funktionieren :-(
---EN---
Hi Lanzi,
which entries you have currently entered in your crypttab? Without it will not work.
-
For me it works for months with systemd, but I have only one entry in /etc/cryptab:
blub UUID=x[...]x none luks
Maybe you have things in /etc/initramfs-tools? I cleanup the dir to the default. (there where days, when it was nessary to modify the files form initramfs-tools)...
-
Okay the point that is relevant is full-encryption:
full-encrypted system with only one crypted container is safe, casue the pw quetion is triggered before anything elese can go on ('cause it needs an root).
If you use mutiple disks with encryption, systemd do not serialize the input and you get the problem you just reported. tanguy has the same problem:
http://tanguy.ortolo.eu/blog/article133/re-about-choice
http://tanguy.ortolo.eu/blog/article132/trying-systemd-back-to-sysv
A workaround is mentioned in the comments: install plymouth to serialize the input.
Der relvante Punkt ist Vollverschlüsselung:
Vollverschlüsselte Systeme mit nur einem verschlüsselten Container, haben kein Problem, weil die Passwortabfrage kommt, bevor es überhaupt weitergehen kann ( er braucht ja ein root)
Bei mehreren verschlüsselte Platten, kommt zum Tragen dass systemd die Eingaben nicht serialisiert und du genau dein beshriebens Problem bekommst. tanguy beschreibt das selbe Problem:
http://tanguy.ortolo.eu/blog/article133/re-about-choice
http://tanguy.ortolo.eu/blog/article132/trying-systemd-back-to-sysv
Als temporäre Lösung wird in den Kommentaren vorgeschlagen: plymouth installieren, um die Eingaben zu serialisieren.
-
@Bluelupo: steht oben direkt über deinem Posting unter "My Crypttab"
-
@Lanzi: Hast du jetzt aktuell noch ein Problem mit den verschlüsselten Disks, das geht aus den Postings nicht so deutlich hervor?
-
ja, massiv! Es wird tendenziel immer noch schlimmer!
Habe jetzt mal plymouth installiert, aber noch nicht neu gestartet. Habe momentan nicht die Zeit, und lasse alles laufen.
evtl. morgen.
Melde mich dann!
Vielen Dank!
-
One question before I reboot: installing plymouth removed console-common. Is that okay? I do not want a unbootable system ;-)
-
so if the behaviour not change after the update i would suggest to examine the working and not working initrd's - unpack and diff them may be a good idea. Only a wild guess, eventually one should add a few modules to grub too with the new initramfs-tools.
Im Anhang ein Screenshot von tkdirdiff, das die Initrds von 3.15-7, 3.16-3 und 3.17-3 vergleicht.
Der in allen außer 3.15.7 fehlende Ordner lib/cryptsetup enthält das Binary askpass.
3.15-7 ist mein letzter funktionierender Kernel, 3.16-3 und 3.17-3 funktionieren nicht.
Here is a screenshot of tkdirdiff comparing the Initrds of 3.15-7, 3.16-3 and 3.17-3.
The missing folder lib/cryptsetup in all except 3.15.7 contains the Binary askpass.
3.15-7 is my latest working kernel, 3.16-3 und 3.17-3 don't boot.
hth debugging
-
@nadar, hast du deine Erkenntnisse in einem Bugreport gemeldet? Ich denke das ist eine wichtige Information für die Entwickler von LUKS/dm-crypt.
---
@nadar, you have reported your findings in a bug report? I think this is important information for developers LUKS / dm-crypt.
-
hmm - one could add the missed binary and all things are ok - but i consider it a major bug with the new initramfs-utils - and this information should be a grave bug against initramfs-utils - if not there right now.
----
Nadar, wenn das noch niemand getan hat, würde ein Bugreport gegen initramfs-utils oder wie die Dinger auch heissen, sehr hilfreich sein. für die Zeit bis zum fix kannst Du natürlich das askpass auch der initrd hinzufügen, wäre mal interessant zu sehen, ob das dann klappt
-
Well maybe the autodetect is now better :) If someone do not use a full encrypted system, than askpass and libcrypt is not needed in the initramfs. We should really seperate the two systems:
crypted root
-> everthing for decryption is needed inside initramfs
-> systemd is coming afterwards, if there was only cryptocontainer, than everything works like charm
non crypted root / multiple cryptocontainers
-> rootfs can be used directly
-> no need to have anything for encryption inside initramfs
-> systemd handles the decryption
-> we hit the problem of parallation of opening the cryptocontainers in parallel
but trying to put the missing things inside initramfs is a good idea - maybe I'm wrong :)
--
Vielleicht ist die autodetection besser geworden :) Wenn jemand kein vollverschlüsseltes System verwendet, dann muss askpass und libcrypt nicht ins initramfs. Wir sollten auch die beiden systeme nicht miteinander verwechseln:
verschlüsseltes root:
-> alls fürs entschlüsseln muss in initramfs
-> systemd kommt danach; wenn es nur einen cryptocontainer gibt, dann läuft alles wie gewohnt
nicht verschlüsseltes root/ mehere cryptocontainer:
-> auf rootfs kann direkt zugegriffen werden
-> deswegen brauchen wir keine tools zum entschlüsseln
-> systemd kümmert sich ums entschlüsseln
-> und tada wir haben das Problem der Parallelisierung, und der versuch die Cryptocontainer parallel zu öffnen
aber es zu probieren die fehlenden sachen mal ins intramfs zu packen ist auf alle Fälle eine gute idee, nicht dasss ich einfach falsch liege :)
-
@nadar, you have reported your findings in a bug report? I think this is important information for developers LUKS / dm-crypt.
(also @melmarker) Not jet. Where to report? (I have no clue)
@hefee: I have a crypted root and a crypted LVM for data consisting of several HDDs.
-
I have a LUKS encrypted system set up pretty much as recommended in the siduction manual using
an encrypted LVM which contains root,home and swap.
I would like to wait until the problem of systemd and LUKS which happened with kernels
after 3.15-0.towo.2-siduction-amd64 is solved.
I have done one dist upgrade with kernel 3.16-3 and was unable to open my LUKS encrypted
system. So I reverted back to kernel 3.15-0 which still works fine.
My worry is that my system will become too obsolete and thus unworkable.
Should I keep doing dist upgrades and rolling back my kernel or should I just sit tight
with my current version or should I venture forward with a workaround?
-
Getting your package set upgraded while sticking to that kernel sounds like a good idea (while having backups at the same time)
greetz
devil
-
Devil,
Thanks
-
Unfortunately my distribution upgrade borked my system so I will have to reinstall.
I'm wondering if it is worth doing an encrypted installation again. I assume that if I use systemd I will be faced with the same issues again.
So my question is:
Can I continue to use init instead of systemd until such time as systemd has its LUKS problems solved?
-
sure you can - you will need systemd-shim to do so
-
I'm wondering if it is worth doing an encrypted installation again.
/me ever wonders: Why a full encrypted system?
/me thinks: a seperate /home encrypted is a safe house for all your private data.
But:
If you fear having some spyware running on parallel windows which can write
on your ext4 root partition some additional trojan horse.
Or:
If you have to go through customs of England and you politicaly support Snowden ...
-
there are pills for such fears ...
-
Die Upgrade Warnung für User mit verschlüsselten Festplatten ist nach wie vor aktuell.
Deshalb möchte ich meinen Workaroud, den ich mit sachkundiger Unterstützung aus dem IRC-Channel gefunden hab, hier skizzieren.
Die Ausgangssituation: Eine Festplatte mit zwei physikalischen Partitionen (sda1 und sda2). sda1 ist eine kleine, unverschlüsselte Partition, die /boot/ beherbergt und sda1 den Rest der HD. Diese Partition ist verschlüsselt mit luks. In der verschlüsselten Partition verwaltet lvm den Platz und enthält mehrere logische Volumes, u.a. root / und swap.
Mein System bootete nach einem dist-upgrade nicht mehr, ich kam nicht einmal mehr bis zur Passwortabfrage. Die Lösung des Problems hat graver am 24.10.2014 in diesem thread veröffentlicht und verweist auf die Datei /usr/share/doc/crtyptsetup/README.initramfs. Allerdings ist sein Vorgehen etwas anders als in der angegebenen Datei: Graver fügt die Zeile
cryptroot /dev/mapper/vg-crypt none luks
in die Datei /etc/crypttab ein. In der o.a. Datei README.initramfs sieht die Zeile so aus:
cryptroot /dev/sda2 none luks
Warum die von graver angegebene Zeile die richtige ist, weiß ich nicht, aber bei mir hat es funktioniert.
Ich beschreibe nun das Vorgehen, mit dem ich mein System wieder zum Laufen bekam, ausgehend von einem gebooteten Live-System.
1. Man werde in einer shell (ich hab ein tty benutzt) zum superuser:
$ su
2. Das root-Verzeichnis aus dem verschlüsselten Container einbinden:
# cryptsetup luksOpen /dev/sda2 geheim
Dabei ist geheim der Name, mit dem der verschlüsselte Container beim mapper angemeldet wird. Es wird später wichtig, dass hier der selbe Name gewählt wird wie im regulären System. Falls man diesen Namen nicht parat hat: In den Ausgaben und Fehlermeldungen beim (erfolglosen) Bootvorgang des darniederliegenden regulären Systems findet man den Namen. Ist nun die Entschlüsselung vollzogen, müssen noch die logischen Volumes aktiviert werden:
# vgscan
# vgchange -a y
Nun sollte man in /dev/mapper neben dem Cryptocontainer auch die logischen Volumes finden und mounten können.
# mount /dev/mapper/meinevolumegroup-meine_rootpartition /mnt
Eventuell müssen hier noch spezielle Optionen fürs Dateisystem angegeben werden, bei den ext-Dateisystemen ist das aber meist nicht nötig.
3. Das reguläre System mit chroot betreten
Die root-shell ins reguläre System will gut vorbereitet sein, /sys/, /proc/, /dev/ und /boot müssen eingebunden werden:
# mount /dev/sda1 /mnt/boot/
Die physikalische Bootpartition muss auch dann eingebunden werden, wenn sie nach dem Einbinden des Volumes mit dem rootverzeichnis vorhanden zu sein scheint, selbst dann wenn /boot/ bzw. /mnt/boot/ gefüllt ist/gefüllt zu sein scheint mit allem, was man in /boot/ erwartet.
# mount -o bind /dev/ /mnt/dev/
# mount -o bind /proc/ /mnt/proc/
# mount -o bind /sys/ /mnt/sys/
Nun kann man das reguläre System betreten:
# chroot /mnt/
4. Die eigentliche "Reparatur"
In die Datei /etc/crypttab trägt man die folgende Zeile ein:
cryptroot /dev/mapper/geheim none luks
Der vorletzte Eintrag steht für ein mögliches keyfile, bei mir eben keins.
In der root-shell muss nur dieser eine Befehl abgesetzt werden:
# update-initramfs -c -k 3.15-1.towo-siduction-amd64
Für update-initramfs kann man -c für create oder -u für update verwenden. Bei -c versagt update-initramfs den Dienst, wenn für den Kernel schon ein entsprechendes initrd-file vorhanden ist, man müßte also das alte initrd-file verschieben/umbenennen.
Hat man bereits update-initramfs -c -k eingegeben, funktioniert die aus der shell bekannte und beliebte tab-kompletion, so dass man aus der Liste der vorhandenen Kernel auswählen kann.
Es kommt hier zu Fehlermeldungen, wenn der Container in /etc/crypttab nicht genauso heißt wie der in /dev/mapper/, weshalb beim Einhängen mit cryptsetup (s.o.) der gleiche Name wie im Standardsystem verwendet wurde.
update-initramfs gibt auch im Erfolgsfall Warnungen von mdadm aus, die aber getrost ignoriert werden können, sofern man kein raid-system oder ähnliches hat, auf jeden Fall aber, wenn man nur eine HD im Rechner hat.
Kommen also nur diese Warnungen von mdadm, dann kann man die rootshell und das Live-System verlassen und wie gewohnt das reguläre System booten.
-
Hi walter,
wenn in der /etc/crypttab der falsche Bezeichner bzw. das falsche Diskdevice steht, ist das klar das die LUKS-verschlüsselte Disk nicht gefunden wird. Der bei der initialen Erstellung gewählte Devicename, sowie der Pfad zum verschlüsselten Device wird zwingend von LUKS/dm-crypt benötigt.
Der Fehler ist auch einleuchtend, da nicht ein LVM-Device innerhalb der verschlüsselten Partition angegeben werden kann sondern das übergeordnete Diskdevice (/dev/sda2).
LUKS/dm-crypt ist in der logischen Schicht vor den (LVM) Devices angeordnet, sozusagen als Container für die LVM-Devices. Mit dem Kommando lsblk kann man die Hirarchie gut sehen.
Hier mein LUKS/dm-crypt System:
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 223,6G 0 disk
├─sda1 8:1 0 200M 0 part /boot
└─sda2 8:2 0 223,4G 0 part
└─cryptsda2 254:0 0 223,4G 0 crypt
├─VGsys-LVroot 254:1 0 6G 0 lvm /
├─VGsys-LVvar 254:2 0 3G 0 lvm /var
├─VGsys-LVhome 254:3 0 2G 0 lvm /home
└─VGsys-LVswap 254:4 0 2G 0 lvm [SWAP]
sr0 11:0 1 1024M 0 rom
-
Hallo bluelupo,
je genauer ich hinschaue, desto weniger verstehe ich, warum der crypttab-Eintrag bei mir funktioniert hat bzw. gewinne den Ein druck, dass es egal ist, was in /etc/crypttab steht, hier die Ausgaben von meinem System:
walter@siductionbox:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931,5G 0 disk
├─sda1 8:1 0 150M 0 part /boot
└─sda2 8:2 0 931,4G 0 part
└─platte 253:0 0 931,4G 0 crypt
├─willisvolumegroup-lvol0 253:1 0 2G 0 lvm [SWAP]
├─willisvolumegroup-lvol1 253:2 0 400G 0 lvm /mnt/crypt
└─willisvolumegroup-siduc 253:3 0 350G 0 lvm /
sdf 8:80 1 14,9G 0 disk
└─sdf1 8:81 1 14,9G 0 part
sr0 11:0 1 1024M 0 rom
walter@siductionbox:~$
und dazu (un)passend:
walter@siductionbox:~$ cat /etc/crypttab
cryptroot /dev/mapper/cryptroot none luks
walter@siductionbox:~$
Laut manpage zu crypttab soll im ersten Feld der Bezeichner, also bei mir platte und im zweiten Feld das physikalische device, also bei mir /dev/sda2 stehen, also sollte die eine Zeile in /etc/crypttab[/tt lauten
platte /dev/sda2 none luks
sofern ich alles richtig verstanden habe.
Ich werde, wenn ich Zeit dazu finde, verschiedene Einträge in /etc/crypttab bzw. daraus erstellte initrds auf ihre bootfähigkeit testen.
-
Hi walter,
hmmm, also deine crypttab dürfte so nicht funktionieren:
cryptroot /dev/mapper/cryptroot none luks
Die hingegen muss funktionieren:
platte /dev/sda2 none luks
Teste mal und berichte. Was sagt denn "cryptsetup status cryptroot" bzw. "cryptsetup status platte"?