Thanks for the feedback.
First of all, note that I've split this bug into two with the changes to the
regular initramfs-tools scripts (the only change being the sourcing of files
generated by subscripts) going into this bug and the new hook and
local-premount script going into a bug against cryptsetup (bug 358452).
Some of your comments have already been fixed in the scripts I've attached to
that bug, and some have not. I'll CC this mail to that bug to make sure that
this conversation is noticed by anyone reading that report as well.
maximilian attems ([EMAIL PROTECTED]) wrote:
> David Härdeman wrote:
>> * Adds support for changing variables in the main init script, this is
>> performed by checking for the file /dev/.initramfs/source.me after
>> running each script and sourcing it if it does. This is probably
>> necessary if we ever want to support features such as ROOT=probe as it
>> would require changing the ROOT variable as the real root is found.
>
> nacked, this hack is ugly.
> the form you envisaged to do it is really nonobvious.
> the trouble is that you change the ROOT variable to NEWROOT from a
> subscript. need to think of a better way to do this.
Yes it is somewhat ugly. But the alternatives are far uglier. With this hack
it is much easier to support things like
root-on-reiserfs-on-lvm-on-dm-crypt-on-raid or ROOT=probe without having to do
extensive changes to unrelated scripts.
The only alternative that I could think of was to change the main init script
to source the subscripts rather than to execute them, but this would require
much more extensive changes.
I hope I can persuade you that this hack is the way to go :)
> > * Uses the above feature to remove the cryptroot boot option and also
> > makes changes to other files (such as lvm script) unnecessary.
For initrd compability I should probably readd the boot options. Thats an
issue for bug 358452 though.
> nice but missing essential crypto modules, see attached hook file.
I'm working on setting up cryptroot support in debian-installer
(partman-crypto). Since the installer knows which kinds of crypto it has
setup, it can also add the necessary modules. The hook on the other hand
cannot.
Maybe I should add some probing or just add more of the cryptomodules from the
hook (e.g. serpent, blowfish and twofish considering the current patches I
have for partman-crypto).
> also i'm real curious about that cryptgetpw, what's in there?
> mounting usb stick for reading the key?
The idea was to make things a bit more flexible. The user can create a
cryptgetpw script which gets a key from a usb stick, from a cd-rom, via the
network, whatever. As long as it outputs a key to stdout, everything should be
fine.
For example, I have a script which checks for a usbstick containing a
filesystem with a given uuid. It then loads a keyfile from that stick, asks
for a passphrase, hashes said passphrase and XOR's the two together to create
the key for the root partition.
I can clean it up later and submit as an example to put in /usr/share/doc...
> hmm that looks very much in the initrd-tools spirit where you
> putted an script to get executed later.
Is that good or bad? :)
> > for cs_x in ${runlist}; do
> > ${initdir}/${cs_x}
> > + if [ -e /dev/.initramfs/source.me ]; then
> > + . /dev/.initramfs/source.me
> > + rm -f /dev/.initramfs/source.me
> > + fi
> > done
> > }
>
> nack this is really strange, i had to triple look when that would be run.
See the arguments above. This is the only part that remains to be discussed in
this bug report. Would the change be more acceptable if I add a big fat
comment explaining what this does and why?
> > +if [ "$FSTYPE" != "luks" -a -z "$cryptopts" ]; then
> $FSTYPE is not exported so the check fails at this stage,
> also this seems to only work if luks and cryptopts are set,
> which seems not to match the code below.
It should exit if no cryptopts are set and no luks filesystem was found (i.e.
no encrypted root partition).
> > +# Check which cryptosolution we want
> > +if [ "$FSTYPE" = "luks" ]; then
> we need to run fstype to know that.
I'll fix
> hmm the loop broke out with me having typed in a bad password,
> need to recheck that.
I'll check
> need to properly read the initrd-tools report about cryptoroot to know
> what people wants and i guess we can get that working till that weekend.
> i need to check the initrd-tools boot args too as cat /proc/cmdline
> root=/dev/sda2 ro cryptopts=node=sda2
> looks somehow ugly.
Yes, I should take a look at the boot args used by initrd-tools and see if we
can use the same to avoid confusion.
> ps my quick trick to make the attached hook and the attached bootscript
> working was this hack (which doesn't work of course with lvm and md):
This should be fixed in the version of the scripts contained in bug 358452.
Regards,
David
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
