'-I' option are for user to include single files. If you'd like to
merge files into initramfs with its dependencies, you use '*inst*'
family functions. See 'dracut-functions' file.
Thanks, I'll have a good look.
First of all rd_LUKS_KEYDEV_UUID will be changed to 'rd.luks.keydev' and
allow to specify devices by filename in /dev, LABEL or UUID.
It's done a bit more flexible. You can specify 'rd_LUKS_KEYDEV_UUID'
(later 'rd.luks.keydev') and 'rd_LUKS_KEYPATH' (later 'rd.luks.keypath')
several times. For every 'rd.luks.keydev' ALL 'rd.luks'keypaths' are
checked. I know that such approach have some flaws. I'll consider your
proposition (quoted below) for specifying that.
[...]
rd.luks.key=<key_path>:<key_dev>:<luks_dev>
Why this order? <key_path> is always required (obvious). <key_dev>
doesn't have to be required, because it's easy to perform search for
device (and it's done know, it works pretty well, at least with my
latest not yet accepted patch which needs more improvement :-)). The
last is optional too. Forcing user to write down all UUID-s is not
ethical. ;-) It should be automated as far as it makes sense.
Bugger, I forgot about drive labels :-\
In which case using separate rd.luks=<luks_dev> (for password
identification), rd.luks.key for external dev/key authentication and
rd.luks.token for token authentication makes sense. I would reverse the
order though.
The way I see it if you reverse the order to be
<luks_dev>:<key_dev>:<fs>:<key_path> (don't forget the file system,
otherwise how would you know how to mount it to read the key - you may
'assume' that it is either ext2/3, but it might be something else - HFS,
ReifeiserFS etc.) it makes it more consistent with the Fedora's own
Kickstart options (see http://fedoraproject.org/wiki/Anaconda/Kickstart
- scroll further until you find 'ks=').
Examples:
rd.luks.key=/some/file.key:LABEL=cool_keys:UUID=00aabc
rd.luks.key=/some/file.key::UUID=00aabc
rd.luks.key=/some/file.key:LABEL=cool_keys
rd.luks.key=/some/file.key
And probably I'll introduce this scheme in patches I'm improving
recently. Does it satisfy you? :-) And for token it would be:
rd.luks.token=â
Might be?
I'll be happy if you reverse the order and add a file system type as
well - it makes it more consistent with the Fedora Kickstart format,
otherwise is a bit confusing.
I've looked through the dependencies and the package scripts though
there are, among other things, udev rules and config files, which
could complicate matters. Following this I have another query: Does
dracut have (at least read) access to the /boot partition where the
initramfs image is?
No, no. You don't need access to /boot. You put everything in
initramfs using installation functions provided by 'dracut-functions'.
See 'install' and 'check' scripts in some module's directory.
That could spell trouble as for just running pkcs11-tool that requires 2
configuration files which reflect the specific token type and various
parameters. Although 90% of all cases fall into the 'default' mode
scenario there are the rest 10% which do not and have to be properly
catered for.
The parameters and attributes in these files are complex and cannot be
specified in the kernel command line in grub.conf. If these 2
configuration files are embedded into initrd they cannot be changed,
which means that initrd has to be custom-built for each client
configuration which makes this whole exercise largely impractical.
The other possible scenario, as I already mentioned, is to use
configuration files which are outside initrd (separate device or located
in /boot are two possible alternatives)
One other query related to this: if I want to use crypttab for my root
(/) partition how is that handled by dracut?
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
