[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Support for plain dm-crypt and detached LUKS header

From: Xen
Subject: Re: Support for plain dm-crypt and detached LUKS header
Date: Tue, 11 Apr 2017 10:23:28 +0200
User-agent: Roundcube Webmail/1.2.4

Mat628 schreef op 11-04-2017 7:23:
Am I correct in stating that your patches would only require:

- command line options on each invocation of grub-install to reference a config file of sorts - a config file in a dedicated directory that would allow this config to persist

Xen, yes you are correct. The config file
(${prefix}/etc/mattle_opts.cfg) persists in that directory and is
opened in "read-only" mode by both grub-install and grub-mkconfig

Alright thanks. From the surface of it it seems to me like an agreeable way of doing things.

One peculiar thing is that if the grub boot loader is capable of retrieving the header file using the search.fs directives and all that then why would you need to manually feed it to grub-install? Wouldn't grub-install be capable of doing the same, ie. read the contents of in this case mattle_opts.cfg and also find the header file that way?

You state that the only reason for passing the options to grub-install is for it to know which modules to load based on the actual header file contents.

You also state somewhere that a little bit of a difficulty exists if you want to install to two devices after one another; requiring the editing of mattle_opts.cfg in between.

So this makes me believe at this point that mattle_opts.cfg is authorative in the sense that you will need to match the grub-install parameters with it *anyway*.

Most notably it would seem that in this system it would not be required to pass the options to grub-install since it is going to read /etc/default/grub anyway right? Or is this only read by grub-mkconfig? Confused :p.

I assume grub.cfg is also read by grub-install (or /etc/default/grub or whatever) and even though ${prefix}/etc/mattle_opts.cfg is only (?) referenced in it would just seem to be that you have now two separate types of config that you need to keep in sync?

So as a bystander (I haven't read all of the patches nor do I understand all of the code of luks.c etc) (I have only wrestled with lvm.c and util.c in my 'time' ;-)) that is just what makes me curious, or rather, a question I would personally have on the surface of it.

I know that no additional command line parameters are required for grub-install when installing on a regular LUKS device, ie. you set GRUB_ENABLE_CRYPTODISK and that is basically all that is required for the Grub side of things (not to mention your initrd usually requires a key to the root volume at least to continue booting that I would then put in the initrd itself).

On a Debian system that would be something like:

luks /dev/vda1 /keyfile.bin luks,keyscript=/bin/cat

In the /etc/crypttab and I'm not even sure the keyscript is required there. But anyway. And then it would require a copy key script hook like:


cp /root/keyfile.bin ${DESTDIR}

In the /etc/initramfs-tools/hooks directory.

And that would be everything, three simple steps in that sense.

So if your configuration is already available in your config file I am curious why you would not let grub-install also read it?

The contents of mattle_opts.cfg are fprintf'ed into load.cfg which is
inside core.img.

But that is done by grub-install right.

Pardon my novice-dom here.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]