* Peter_22@xxxxxx wrote: > * markus reichelt <ml@xxxxxxxxxxxxx> wrote: > > > > This should be no problem. The /proc filesystem is usually > > > mounted by the script and mount -[U|L] relies just on > > > /proc/partitions. > > > > On a sidenote: Have you tried Alon's approach yet? I like the > > idea of using kernel boot parameters to reflect changes in one's > > system. > > What do you mean with "Alon?s approach"? Did I miss a posting? > Manpage for mount says: http://wiki.tuxonice.net/EncryptedSwapAndRoot Yes, it's bloated when it comes to loop-AES alone and confusing, but it offers a promising alternative. Look into it. Nobody I know uses suspend modes whatsoever, it's just another linux fetish, nothing scary ;P Apart from that, I've managed to set up an initrd for my backup machine; you ssh into it and set up the loop device and it just goes on booting the encrypted system; nothing but a proof of concept, unrelated to tux on ice. > "-L label Mount the partition that has the specified label. -U uuid > Mount the partition that has the specified uuid. These two options > require the file /proc/partitions to exist." That's what I meant, see http://mail.nl.linux.org/linux-crypto/2008-01/msg00040.html Did that mail get through? I did not receive a copy. > As no one seems to have done this, I suppose the build-initrd.sh > script can?t build an appropriate initrd for this. The unencrypted > /boot partition is defined like "BOOTDEV=/dev/hda1" and mounted as > /lib. Using UUID would need an initrd mounting /lib with "mount -U" > and then the uuid or label given in the script. I hoped someone had > experience with this and so either tell me that it is a good idea > or just a waste of time to ask for this. This could be done easily, in theory. I haven't tinkered with UUIDs / labels at all (just don't need them at the moment), but it should be a piece of cake adapting build-initrd.sh accordingly. I'd go for the initramfs options, it's easier to adapt. Why don't you try tweaking the script yourself? It's fun. Additionally, when it comes to certain aspects this mailinglist seems like a one-way road. > Most likely I?ll do some testing, also because of this issue with > language support from kernel parameters. Good passphrases > definitely require some µs and euro signs in them. A full graphical > password terminal with mouse support and all UTF-8 characters would > be godlike :-) I'm happy with my standard ASCII 40+ char passphrase ;p -- left blank, right bald
Attachment:
pgp00002.pgp
Description: PGP signature