[dm-crypt] help mounting partitions in an encrypted disk after first reboot
c-d.hailfinger.devel.2006 at gmx.net
Mon Jun 19 00:26:42 CEST 2017
On 18.06.2017 17:51, Arno Wagner wrote:
> On Sun, Jun 18, 2017 at 17:25:41 CEST, Carl-Daniel Hailfinger wrote:
>> On 18.06.2017 09:25, Michael Kjörling wrote:
>> That (LVM inside a LUKS container) is the standard scheme proposed by
>> Ubuntu for an encrypted installation. It works out of the box (needs
>> just a single click in the Ubuntu installer), is well-tested and
>> supports resizing the encrypted logical volumes at a later date.
> But keep in mind that it makes things a lot more complicated,
> hence violating KISS.
A single click is the very definition of KISS.
> It is easier for doing fully automated
> stuff, like a distro-installer would do, but as soon as you
> do things manually, LVM is more of a problem than a solution.
> We have had many people here on the list that killed their
> LUKS containers by overwriting the headers with LVM or
> as a result of LVM misconfiguration and we had others that
> managed to change the LVM setup and then were unable to
> find their LUKS containers afterwards.
(Not intended as a response to the OP, but rather a general observation.)
To be honest, if people want to work as root on the command line, they
should read all the man pages of the tools they are using as root, and
they should read the man pages in full instead of just copy-pasting
snippets from the EXAMPLES section. Reading the supplementary literature
about the design of those tools is strongly recommended well. At least
that's what I'm doing when I'm using tools to manipulate my disks.
Various graphical tools are available for people who are unable to
understand man pages or who are for some reason unwilling to read man
pages (the latter case applies to me when I'm in a hurry) and those
tools usually have quite a few sanity checks. Last time I checked (~2
years ago), the most user friendly one was the openSUSE YaST Partitioner
followed by the KDE Volume and Partition Manager
<https://sourceforge.net/projects/kvpm/> and finally GParted
<http://gparted.org/>. I haven't checked the KDE Partition Manager,
QTParted and other tools.
> My advice would be to stay away from LVM. In this scenario
> it does not do more than a "partprobe" would do and it has
> no advantages. It is a case of something that looks simple,
> but is not, and that is the worst kind. If the ritual fails
> (and complex things that look simple are usually done by
> ritual, not by understanding), you are screwed.
Oh, traditional MBR partitioning is not simple at all, and it gets worse
with >2 TB disks. Try explaining to someone how primary partitions,
extended partitions and logical partitions work together. The
interaction with GPT partitioning and how the MBR partitioning looks if
GPT is active is the stuff of nightmares. Oh, and repartitioning a disk
with some partitions currently in use is still not really going to yield
satisfying results. Besides that, the students in my IT forensics
lectures usually complain that traditional MBR partitioning is the
weirdest scheme ever.
That said, I think that traditional MBR partitioning is the best choice
if all you want is static partitions without nesting.
Yes, the design of LVM takes some getting used to, but IMHO it is a
pretty good design. That said, I wouldn't use it in scenarios where the
requirement is a simple non-encrypted installation without any plans to
> Of course, in the Windows-world, that approach is standard
> and it has been creeping into Linux for a while now (see,
> e.g. systemd, LVM, udev, etc.). This is probably due to people
> comming into the Linux community that never understood what
> the problem with the Windows-approach is.
I've done my fair share of Linux kernel development, firmware
development, reverse engineering and other fun stuff, and use Linux
exclusively since around 2000. In 1998, I thought people not using the
command line on Linux were heretics. I have changed since then. With the
old MS Windows versions, it was impossible to fix things which were not
supported by graphical tools, and I loved having the chance to fix (and
break) anything on the Linux command line. Back then, I thought
attracting all the new users with "bloatware" like desktop environments
was a bad idea. It took me a while to learn that this stuff was useful
after all. Nowadays I'm not afraid of people who want/use a GUI because
the GUIs have matured to a point where I'd even call them mostly failsafe.
I'm fine with LVM because it's a choice, and I use it on most of my
systems because it's useful for me. I haven't seen zealots trying to get
MBR support removed from Linux distros.
udev made my life easier in some cases, and back then you could use it
systemd and git are useful for some people, but I've lost more time to
each of then than I can ever recover. I could accept that (sunk cost),
were it not for the zealots who will flame anyone questioning the
superiority of their sacred tool. The flaming also serves as a pretty
effective way of killing the motivation of anybody working on competing
solutions. The "you're holding it wrong" mentality of many of those
zealots isn't making them many friends either.
> Sorry for the rant, I just ran into a problem with udev
> (again) an hour ago that makes me want to rip this whole
> crappy "automess" stuff out.
I completely agree that automation can mess things up a lot. I've seen
my forensics students desperately trying to disable the automounter (it
feels like any given distro has a dozen of them, interacting in weird
ways), and you can pretty much rely on any documentation to be either
non-existent, wrong or simply outdated.
That said, I strongly advocate that people should stick as closely as
possible to what their distro has as default because that's where other
more experienced people can easily help.
More information about the dm-crypt