Hi David, Glad to see you back from holidays. One general note: we really do have to be careful with this. As we are now working towards RC releases of d-i, we cannot afford to implement really risky changes. The initial feedback from beta 3 shows there is still some work to do on partman-crypto itself, so I'm fairly happy we made the decision to not offer p-a-c yet. There are also some important open issues for LVM itself. I'd rather spend energy on perfecting the base functionality than on adding p-a-c if we have to choose what to do before Etch. I'd also very much hate it if we would find we had important regressions in partman for RC1 because of rushing implementation of p-a-c and partman-auto RAID support. There is always post-Etch to implement major new features... On Saturday 19 August 2006 20:56, David Härdeman wrote: > 1) Swap on LVM in partman-auto-lvm > I sent an RFC on this more than a month ago. Not much discussion > resulted, I got a few positive comments and no negative comments. Is > this ok to commit? Yes, I would say it is OK to enable that ASAP, at least on a trial basis. > 2) Concerns over an overcrowded partman-auto menu > FJP suggested in the RFC thread on partman-auto-crypto that the > partman-auto main menu might need to change to accomodate the large > number of options. The following example was given: [...] > However, I think that we should split it into two screens: I have been thinking about this a bit too and I agree this is probably better. Note that there is one more option that needs to be accommodated: Use largest available free space (or something like that) That option is only shown if there is free space on a disk and is currently only supported for standard partitioning. There can in theory be multiple disks that have free space you could choose from. Maybe it would be good to explicitly show the free space blocks and their sizes on the next dialog instead of blindly selecting the largest. > If you select "Erase disk and create new partitions" you'd then get: > > <example> > Please select the disk to erase: > SCSI1 (0.0.0) (sda) - 2.1 GB VMware, ... > SCSI2 (0.0.1) (sdb) - 2.1 GB VMware, ... > SCSI2 (0.0.1) (sdc) - 2.1 GB VMware, ... > </example> This screen could probably either be skipped or, better, replaced by a message warning which disk will be used if only one disk is detected. Have to work out how that would work with preseeding though. > Where you can select a single disk, whereas the "Erase disk(s); use LVM > for new partitions" would show: > > <example> > Please select the disk(s) to erase and use with LVM: > > [*] SCSI1 (0.0.0) (sda) - 2.1 GB VMware, ... > [ ] SCSI2 (0.0.1) (sdb) - 2.1 GB VMware, ... > [ ] SCSI2 (0.0.1) (sdc) - 2.1 GB VMware, ... > </example> > > This allows multiple disks to be used for LVM or RAID and should > simplify the preseeding to use two values: method and disks to use. What RAID level(s) are you assuming/wanting to support here? I guess you have seen the commit by Simon Huggins to support RAID1? It would be great if that could be integrated with this. > Not something that is very important to me though, as long as some > progress can be made on adding partman-auto-crypto :) Without yet having looked at the code... For p-a-c, what I have been wondering about is which partitions should be encrypted by default for the different schemes. From comments in earlier threads I understand that having e.g. /usr encrypted isn't all that useful. So what partitions does p-a-c set up encrypted currently? I could imagine something like ("<c>" indicates encryption): "atomic": / <c>, /boot, swap <c> "home": /, /boot, /home <c>, swap <c> (so, / not encrypted) "multi": /, /boot, /tmp <c>, /usr, /var <c>, /home <c>, swap <c> (maybe / should be encrypted too in this case) This could be set in the recipes fairly easily by using a "$encrypt { }" flag or something for partitions to be encrypted. Something like this would possibly be needed anyway for arches that have special bootloader partitions (see for example the "palo" partition in recipes-hppa). Or do you already have a different method for dealing with those? Take care when uploading. I'm not sure the committed auto-RAID stuff is ready yet. Cheers, FJP
Attachment:
pgpYAJipN_Cgr.pgp
Description: PGP signature