Siduction Forum

Siduction Forum => Upgrade Warnings => Topic started by: bluelupo on 2014/09/23, 20:54:45

Title: Caution for LUKS encrypted partitions
Post 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.

Title: Re: Caution for LUKS encrypted partitions
Post by: Lanzi on 2014/09/25, 01:06:22
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.
Title: Re: Caution for LUKS encrypted partitions
Post by: bluelupo on 2014/09/25, 10:11:28
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!
Title: Re: Caution for LUKS encrypted partitions
Post by: Lanzi on 2014/09/25, 11:55:12
Ich habe jetzt auf 2 Rechner sowohl als User und auch als Admin versucht reportbug zur Mitarbeit zu bewegen. Er bricht immer wieder ab.

Code: [Select]
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?

 
Title: Re: Caution for LUKS encrypted partitions
Post by: bluelupo on 2014/09/25, 17:38:58
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.
Code: [Select]
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"
Title: Re: Caution for LUKS encrypted partitions
Post by: Lanzi on 2014/09/25, 19:45:33
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!
Title: Re: Caution for LUKS encrypted partitions
Post by: bluelupo on 2014/09/25, 21:57:18
Hi Lanzi,
dann nimm das grafische Tool Reportbug-NG im Menü "System" (evtl. vorher installieren, Paket reportbug-ng).

Code: [Select]
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
Title: Re: Caution for LUKS encrypted partitions
Post by: Lanzi on 2014/09/30, 17:01:51
@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
Title: Re: Caution for LUKS encrypted partitions
Post by: bluelupo on 2014/09/30, 18:46:37
@Lanzi: Super, freut mich das du einen Bugreport verfassen konntest. Hast du einen Link, das dies der geneigte User mitverfolgen kann.
Title: Re: Caution for LUKS encrypted partitions
Post by: Lanzi on 2014/09/30, 19:19:34
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.

Title: Re: Caution for LUKS encrypted partitions
Post by: melmarker on 2014/09/30, 20:11:01
bitte - lasst doch das mailgedöns in reportbug einfach unkonfiguriert, dann erfolgt der fallback auf debian und das geht immer
Title: Re: Caution for LUKS encrypted partitions
Post by: Lanzi on 2014/09/30, 22:10:42
@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.


 

Title: Re: Caution for LUKS encrypted partitions
Post by: bluelupo on 2014/10/01, 12:32:07
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/
Title: Re: Caution for LUKS encrypted partitions
Post by: Lanzi on 2014/10/01, 18:04:33
hast natürlich 100%ig recht :-)
War genervt von der Gesamtsituation.

Die neue Systemd beta brachte übrigens noch nichts.
Title: Re: Caution for LUKS encrypted partitions
Post by: nadar on 2014/10/11, 12:32:26
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.
Title: Re: Caution for LUKS encrypted partitions
Post by: melmarker on 2014/10/11, 15:55:42
nur zum Spass: als root - update-initramfs -u -k all

und dann sollte alles Wölkchen sein.
Title: Re: Caution for LUKS encrypted partitions
Post by: nadar on 2014/10/11, 16:39:29
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.
Title: Re: Caution for LUKS encrypted partitions
Post by: Lanzi on 2014/10/11, 16:52:08
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.
Title: Re: Caution for LUKS encrypted partitions
Post by: nadar on 2014/10/11, 16:56:55
@ Lanzi: try  update-initramfs -u -k <tab>
Title: Re: Caution for LUKS encrypted partitions
Post by: melmarker on 2014/10/11, 17:45:34
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.
Title: Re: Caution for LUKS encrypted partitions
Post by: Lanzi on 2014/10/11, 18:06:41
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!
Title: Re: Caution for LUKS encrypted partitions
Post by: melmarker on 2014/10/11, 20:12:11
@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.
Title: Re: Caution for LUKS encrypted partitions
Post by: nadar on 2014/10/12, 09:18:30
@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.
Title: Re: Caution for LUKS encrypted partitions
Post by: graver on 2014/10/17, 21:28:25
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
Code: [Select]
cryptroot /dev/mapper/vg-crypt none luks
and doing

Code: [Select]
update-initramfs -u -k <latest installed kernel>
Title: Re: Caution for LUKS encrypted partitions
Post by: nadar on 2014/10/18, 11:41:29
@graver: thanks! This worked on my netbook (but I didn't dare to do it on my main box. :) )
Title: Re: Caution for LUKS encrypted partitions
Post by: nadar on 2014/10/29, 20:43:20
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.
Title: Re: Caution for LUKS encrypted partitions
Post by: Lanzi on 2014/11/10, 18:10:26
  @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
Code: [Select]
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:
 
Code: [Select]
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)




 
Title: Re: Caution for LUKS encrypted partitions
Post by: bluelupo on 2014/11/13, 12:42:17
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.
Title: Re: Caution for LUKS encrypted partitions
Post by: hefee on 2014/11/13, 13:48:46
For me it works for months with systemd, but I have only one entry in /etc/cryptab:

Code: [Select]
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)...
Title: Re: Caution for LUKS encrypted partitions
Post by: hefee on 2014/11/13, 14:36:29
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.
Title: Re: Caution for LUKS encrypted partitions
Post by: Lanzi on 2014/11/13, 16:14:25
@Bluelupo: steht oben direkt über deinem Posting unter "My Crypttab"

Title: Re: Caution for LUKS encrypted partitions
Post by: bluelupo on 2014/11/13, 19:51:18
@Lanzi: Hast du jetzt aktuell noch ein Problem mit den verschlüsselten Disks, das geht aus den Postings nicht so deutlich hervor?
Title: Re: Caution for LUKS encrypted partitions
Post by: Lanzi on 2014/11/13, 21:14:00
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!
Title: Re: Caution for LUKS encrypted partitions
Post by: Lanzi on 2014/11/14, 15:41:32
One question before I reboot: installing plymouth removed console-common. Is that okay? I do not want a unbootable system ;-)
Title: Re: Caution for LUKS encrypted partitions
Post by: nadar on 2014/11/17, 20:17:21
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
Title: Re: Caution for LUKS encrypted partitions
Post by: bluelupo on 2014/11/17, 21:04:15
@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.
Title: Re: Caution for LUKS encrypted partitions
Post by: melmarker on 2014/11/17, 21:39:39
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

Title: Re: Caution for LUKS encrypted partitions
Post by: hefee on 2014/11/18, 12:18:46
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 :)
Title: Re: Caution for LUKS encrypted partitions
Post by: nadar on 2014/11/19, 10:06:04
@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.
Title: Re: Caution for LUKS encrypted partitions
Post by: bad_aptitude on 2014/12/09, 04:23:58
 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?
Title: Re: Caution for LUKS encrypted partitions
Post by: devil on 2014/12/09, 06:47:34
Getting your package set upgraded while sticking to that kernel sounds like a good idea (while having backups at the same time)


greetz
devil
Title: Re: Caution for LUKS encrypted partitions
Post by: bad_aptitude on 2014/12/09, 18:29:22
Devil,


Thanks
Title: Re: Caution for LUKS encrypted partitions
Post by: bad_aptitude on 2014/12/12, 00:31:55
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?
Title: Re: Caution for LUKS encrypted partitions
Post by: melmarker on 2014/12/12, 09:06:23
sure you can - you will need systemd-shim to do so
Title: Re: Caution for LUKS encrypted partitions
Post by: ralul on 2014/12/15, 11:54:55
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 ...
Title: Re: Caution for LUKS encrypted partitions
Post by: melmarker on 2014/12/15, 17:28:23
there are pills for such fears ...
Title: Re: Caution for LUKS encrypted partitions
Post by: walter on 2015/01/31, 23:37:48
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

Code: [Select]
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:

Code: [Select]
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:

Code: [Select]
$ su
2. Das root-Verzeichnis aus dem verschlüsselten Container einbinden:

Code: [Select]
# 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:

Code: [Select]
# vgscan
# vgchange -a y

Nun sollte man in /dev/mapper neben dem Cryptocontainer auch die logischen Volumes finden und mounten können.

Code: [Select]
# 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:

Code: [Select]
# 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.

Code: [Select]
# 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:

Code: [Select]
# chroot /mnt/

4. Die eigentliche "Reparatur"
In die Datei /etc/crypttab trägt man die folgende Zeile ein:

Code: [Select]
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:

Code: [Select]
# 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.
Title: Re: Caution for LUKS encrypted partitions
Post by: bluelupo on 2015/02/01, 21:07:30
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:
Code: [Select]
# 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   
Title: Re: Caution for LUKS encrypted partitions
Post by: walter on 2015/02/02, 22:56:14
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:

Code: [Select]
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:

Code: [Select]
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

Code: [Select]
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.


Title: Re: Caution for LUKS encrypted partitions
Post by: bluelupo on 2015/02/03, 09:11:40
Hi walter,
hmmm, also deine crypttab dürfte so nicht funktionieren:

Code: [Select]
cryptroot       /dev/mapper/cryptroot           none    luks

Die hingegen muss funktionieren:
Code: [Select]
platte       /dev/sda2        none     luks

Teste mal und berichte. Was sagt denn "cryptsetup status cryptroot" bzw. "cryptsetup status platte"?