[dm-crypt] help mounting partitions in an encrypted disk after first reboot
c-d.hailfinger.devel.2006 at gmx.net
Mon Jun 19 21:02:24 CEST 2017
On 19.06.2017 01:01, Arno Wagner wrote:
> On Mon, Jun 19, 2017 at 00:26:42 CEST, Carl-Daniel Hailfinger wrote:
>> 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.
> Not at all. KISS does not refer to what the user does, it
> refers to what the system does. Hence a single click triggering
> a complex operation is about at the largest distance from KISS
> that you can get.
> I though that was obvious.
Actually, no, I don't think that's obvious at all. According to your
definition, using a hex editor for editing the MBR partition definitions
could be KISS because (I'm quoting you) "KISS does not refer to what the
However, according to your definition "KISS [...] refers to what the
system does" the on-disk representation of MBR partitions is definitely
not KISS. There are complex rules about whether a partition definition
is an entry in an array, or an entry in a singly linked list pointed to
by an array entry, how the on-disk ordering of the partitions has to
correspond with the type of entry, and of course (and totally
non-obvious) that one type of partition is assumed to never host a file
system, and all partitioning tools will declare said type of partition
as free space although it differs from actual free space not covered by
a partition. Oh, and try explaining to people why the second usable
partition on a Linux system usually is sda5 and not sda2.
> Pressing a button is a ritual. Simplicity of the rituals
> used has no benefit when you need to understand what is
> actually happening. A ritual does not give you any insight
> into the nature of what is going on and computing is not
> (and will not be for a long time) at a point where basically
> everything can be done by ritual in a secure and reliable
Insight ist often not necessary to use something. In many cases, it
doesn't even help. A newborn baby drinking from a bottle neither needs
to understand the complex chemical processes involved in creation of
milk and digestion of milk, nor would such a baby benefit from that
If insight is desired by someone, more power to them.
>>> 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.
> Well, yes. And that is were KISS comes in: A system that is simple
> and clear is far easier to understand than one that is convoluted,
> complex and full of details and exceptions.
> Good engineering makes understanding things easy, bad engineering
> makes it hard. And bad engineering is full of surprises and
> "emergent properties", and hence unreliable, insecure, hard
> to maintain and use. That is the basis of where the KISS
> requirement for good engineering comes from.
I think you're conflating "complex" and "convoluted" here. High
precision clockwork movements can be really complex, but being
convoluted is not something I'd associate with them.
> There is a school of though that seems to think things should
> be complex in order to show off the superior skill of the
> person that created them and then blame the user if they
> have trouble to understand what is going on.
> I consider that juvenile and a sign of gross incompetence. It
> is far harder to design a system to be simple than to be complex.
> For complex you just throw in everything and the kitchen sink.
> For simple, you actually need to understand the problem you are
> trying to solve and its very core nature.
Yes, and sometimes problems are complex and need complex solutions.
> People that do not try for simplicity have no business creating
> infrastructure in general use. Also, these people waste my time
> because of their mismatch between ego and skill. And I will
> freely admit that their lack of skill offends me.
> I will stop answering here, because I have no clue what you
> want to say with the rest below.
> Also, raving about your credentials
I didn't rave about my credentials, I tried to explain that although my
opinion a few years ago was pretty close to yours right now, there are
reasons I've changed since then.
> does nothing for me, except
> making me think they are not nearly as good as you try to make
> them sound. That is the usual case.
My apologies. I thought you value such credentials greatly because you
list yours in your email signature of every email. Thank you for your
insight about "the usual case". Does it apply to you as well?
> Does give me a laugh though, as it reminds me of the one time
> where some guy in a newsgroup actually looked me up and then
> accused me of being the janitor using my computer to post
> things after having broken into my office. Ah, good times ;-)
I fail to see how this is related to our conversation.
> Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at wagner.name
> GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718
>> 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
>> resize partitions.
>>> 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