breezy: initramfs-tools support for encrypted root

[Ilkka Tuohela]

su, 2005-10-09 kello 18:08 -0700, Karl Hegbloom kirjoitti:
> On Sat, 2005-10-08 at 10:52 +0300, Ilkka Tuohela wrote:
> > I opened a bug about the problem that we don't have encrypted root fs
> > support in breezy at all,...
> 
> Without even looking at your patch yet, I'm wondering if it really
> requires a patch, or if it could be done by a drop-in package that
> installs the right hook script and initramfs script?

Well, I think it can't be drop-in package because scripts/local-top/lvm 
is trying to handle device mapper files as well, and fails: the
encrypted root node is in /dev/mapper, after all.

the encrypted= cmdline parsing could be don in init-top (and should be 
there, I think - I put it directly to init while I was anyway modifying
it)

Otherwise it could easily be drop-in package as well. I didn't actually
check what the lvm script does unmodified, it might be that actually we 
can just let it fail and run cryptoroot script after it: if this works, 
the patch could be rewritten as drop-in package, and I really think it
should be one after all.

> For a user upgrading from Hoary to Breezy, I would assume that the
> upgrade is being done from a live system using one of the package
> manager tools, and so the extra package could easily be selected for
> installation at that time.

Well, only thing I'm worrying about are users who don't read upgrade
instructions ;) 

> Perhaps for Dapper, the support could be there by default... what would
> it take to create a d-i udeb that allows installing to encrypted file
> systems and swap?  That would be a valuable addition to Ubuntu, IMO.  It
> won't happen unless somebody spends the time to develop it...  Any
> volunteers?  ;-)  I move that a bounty be put on this one.  (Can I do
> that?)

I'll do the udeb, no problem. Cryptsetup package just has to move to 
main first. 

Off-topic LUKS discussion:

Another thing which I've been thinking about is that the luks patches
for cryptsetup are a little bit 'ugly': why do I need to 
- use luksOpen instead of just 'create' and 'remove' as usual: the code
  _can_ recognize luks header, so it could always try it first and fall
  back to raw partition encryption if no header is available
- give dm-crypt name and raw device in reverse order vs. other such 
  tools - it's always confusing.

Actually, with LUKS, IMO we should patch mount to check for luks header
and be able to ask passphrase if the partition is encrypted. pmount LUKS
support is good but I for example have one partition on hda with no
automatic setup: I should be able to say 'mount /work' and get hda9 set
up with encryption and mounted. Of course, if this partition would just
show up in nautilus and ask passphrase whenever I need to mount it ... 

	*hile*