[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
automatically.
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 grub-mkconfig_lib.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:
#!/bin/sh
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.
Re: Support for plain dm-crypt and detached LUKS header, John Lane, 2017/04/10