Bug#656710: partman-crypto: Preseeding the passphrase
Hi everyone, On Wed, Jul 30, 2014 at 11:23:28AM +0200, Raphael Hertzog wrote: I have been using this patch in Kali (on top of wheezy's partman-crypto), it would be nice to have this patch merged in time for Jessie. Dimitrijs, Max or Christian? (You ar listed in Uploaders) Two things come to my mind: - The feature should have some documentation to explain to users that any preseeded passphrase is to be considered insecure and must be changed after installation, like Olaf suggested perhaps the preseeding template could be a good place. - I have a vague memory of needing to clear the template value for partman-crypto/passphrase (and passphrase-again) to ensure the passphrase does not end up in the debconf database of the installed system. Could you verify if this is (still?) true? Other than that, I am happy with the change. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140730100409.ga11...@x201t.vpn.hinterhof.net
[rfc] Dropping loop-aes from d-i
Hey all, a couple of factors which make me consider dropping support for loop-aes from d-i (mostly partman-crypto). - No binary module debs (and therefore udebs) available after the removal of linux-modules-extra. - Root on loop-aes gets little testing these days; I don't use it myself anymore. - The reasons I had for preferring loop-aes over dm-crypt have mostly dissolved. Does anyone mind and want to work on a solution to keep it? Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331105351.gc1...@quark.vpn.nusquama.org
Re: [rfc] Dropping loop-aes from d-i
On Wed, Mar 31, 2010 at 01:10:57PM +0200, Frans Pop wrote: On Wednesday 31 March 2010, Max Vozeler wrote: a couple of factors which make me consider dropping support for loop-aes from d-i (mostly partman-crypto). So what should people now use for encrypted swap without passphrase? Debian cryptdisk scripts support that as well. Hmmm. OTOH, I do have that on one laptop and it works fine with upstream kernels (at least, I've never noticed a problem). Wonder what exactly I did there. In partman-crypto, IIRC we just configure the encrypted mapping to use /dev/urandom as keyfile and add the swap option in crypttab. That ensures mkswap is run. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100331125534.ga9...@quark.vpn.nusquama.org
Bug#547939: installation-reports: is the encryption key size in bits or bytes?
reassign 547939 partman-crypto severity 547939 wishlist thanks Hi Marc, On Tue, Sep 22, 2009 at 07:03:40PM +0200, Marc Haber wrote: when installing cryptography, one can choose whether the encryption key for a partition is 128, 192 or 256 big. Is this bits or bytes? The key sizes are in bits. Now I do sense a suggestion behind the question, :-) Even though it is very unusual to specify key sizes in any other unit, the dialog does not actually say which unit is used. Makes sense to explictly mention it. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#547731: Please include b43 in nic-wireless-modules
On Mon, Sep 21, 2009 at 11:58:35PM +0200, Max Vozeler wrote: Seems reasonable to include b43 in nic-wireless-modules. I checked the changes this implies with 2.6.30-1-amd64: - Depends on two other modules: rng-core, ssb - Installed-Size of nic-wireless-modules grows by 292k total - b43 depends on pcmcia, so nic-wireless-modules will need to depend no pcmcia-modules. Does this sound reasonable? Max Index: kernel-wedge/debian/changelog === --- kernel-wedge/debian/changelog (Revision 60823) +++ kernel-wedge/debian/changelog (Arbeitskopie) @@ -1,3 +1,10 @@ +kernel-wedge (2.63) UNRELEASED; urgency=low + + [ Max Vozeler ] + * Add b43 to nic-wireless-modules. Closes: #547731. + + -- Max Vozeler x...@debian.org Tue, 22 Sep 2009 00:29:21 +0200 + kernel-wedge (2.62) unstable; urgency=low [ Colin Watson ] Index: kernel-wedge/modules/nic-wireless-modules === --- kernel-wedge/modules/nic-wireless-modules (Revision 60823) +++ kernel-wedge/modules/nic-wireless-modules (Arbeitskopie) @@ -17,6 +17,7 @@ ath5k ? iwl3945 ? iwl4965 ? +b43 ? # rt2x00 drivers rt2500pci ?
Bug#541823: installation-reports: Acer Aspire 3690
Hi Celejar, On Mon, Aug 17, 2009 at 10:04:00AM +0200, Christian Perrier wrote: 4) I was unable to delete a LUKS encrypted disk that I had created on a partition. The installer refused to delete the partition since it was used by the encrypted disk, but it also apparently offered no way to delete the encrypted disk. That one also. Hopefully Max will look at it in details. Yeah, that's a known missing feature in partman-crypto. It is not possible to remove encrypted volumes right know. Tracked in Debian bug #381892. 5) The showstopper: I installed the entire system (except for /boot) onto LVM volumes in a vg on top of a LUKS volume created out of a primary partition. When I rebooted, the system wouldn't bring up the LUKS volume. The eventual fix that worked is to add this line to /boot/grub/menu.lst: # kopt=cryptopts=target=hda4_crypt,source=/dev/hda4,lvm=lizzie-root root=/dev/mapper/lizzie-root ro This is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492790 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522041 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507721 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503062 Hmmm. This certainly *should* work. Celejar, did you configure a label on the root filesystem, or remember setting anything unusual? There are different issues that could lead to such symptoms, as can be seen in the different bug reports you referenced, but (AFAICT) none of those should affect current installer builds. It occurs to me that you might have hit a temporary problem we had in daily builds after we switched to UUID by default. This could lead to exactly those symptoms, and has since been fixed. Any chance you could retry the installation with a current image and try to reproduce it there? I do realize this may not be possible, but asking can't hurt. :-) Otherwise I think we should assume this was caused by the problem we already fixed - unless someone sees this with a current image. Either way, thanks for sending in the installation report. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541823: installation-reports: Acer Aspire 3690
On Mon, Sep 21, 2009 at 04:16:48PM -0400, Celejar wrote: On Mon, 21 Sep 2009 22:03:57 +0200 Max Vozeler x...@debian.org wrote: Any chance you could retry the installation with a current image and try to reproduce it there? I do realize this may not be possible, but asking can't hurt. :-) Tell you what - I happen to have a lot of space on an external USB HDD that I use for backup and storage. It should be easy enough to do another install onto that disk, and I've been meaning to do so anyway to have a spare installation for when my main one breaks, so when I can find the time, perhaps I'll try it. I suppose that the conditions won't be quite the same as the original install, but let me know if it will still be useful. It certainly would be useful. (If you can spare the time.) I'm semi-regularily doing installs with root-on-crypto, so I'm fairly confident that it is not completely broken right now, but there are always interesting corner cases. So if we could confirm the problem (or confirm it being solved), that would definitely be useful! Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541823: installation-reports: Acer Aspire 3690
clone 541823 -1 reassign -1 kernel-wedge retitle -1 Please include b43 in nic-wireless-modules thanks 3) AFAICT, the installer kernel doesn't include b43. Why? I understand that we can't ship non-free firmware, but why not include the driver for those of us who are able and willing to provide firmware? This one I leave to other maintainers Seems reasonable to include b43 in nic-wireless-modules. I think some of the other kernel modules we include there today also need non-free firmware (ipw*?). Reassigning to kernel-wedge. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541823: installation-reports: Acer Aspire 3690
reassign 541823 partman-crypto tags 541823 + moreinfo retitle 541823 Installed system with root on crypto-pv fails to boot thanks Hi again, since it seems the crypto-root is the only remaining topic in this installation report, I'm reassigning it to partman-crypto so we don't lose it amongst the 2000(?) other reports. To highlight the remaining issue: On Mon, Sep 21, 2009 at 04:16:48PM -0400, Celejar wrote: On Mon, 21 Sep 2009 22:03:57 +0200 Max Vozeler x...@debian.org wrote: 5) The showstopper: I installed the entire system (except for /boot) onto LVM volumes in a vg on top of a LUKS volume created out of a primary partition. When I rebooted, the system wouldn't bring up the LUKS volume. The eventual fix that worked is to add this line to /boot/grub/menu.lst: # kopt=cryptopts=target=hda4_crypt,source=/dev/hda4,lvm=lizzie-root # root=/dev/mapper/lizzie-root ro This is: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=492790 and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=522041 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=507721 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503062 Hmmm. This certainly *should* work. Celejar, did you configure a label on the root filesystem, or remember setting anything unusual? Don't think so. There are different issues that could lead to such symptoms, as can be seen in the different bug reports you referenced, but (AFAICT) none of those should affect current installer builds. It occurs to me that you might have hit a temporary problem we had in daily builds after we switched to UUID by default. This could lead to exactly those symptoms, and has since been fixed. Any chance you could retry the installation with a current image and try to reproduce it there? I do realize this may not be possible, but asking can't hurt. :-) Tell you what - I happen to have a lot of space on an external USB HDD that I use for backup and storage. It should be easy enough to do another install onto that disk, and I've been meaning to do so anyway to have a spare installation for when my main one breaks, so when I can find the time, perhaps I'll try it. I suppose that the conditions won't be quite the same as the original install, but let me know if it will still be useful. Otherwise I think we should assume this was caused by the problem we already fixed - unless someone sees this with a current image. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[PATCH] warn about boot from ext4 with no bootloader support
Note: untested patch for comments.
This adds a check.d script to partman-target to try and warn
the user if they configure ext4 for the boot device on an architecture
with no bootloaders known to handle it.
Does this seem like the right approach?
Max
Index: partman-ext3/debian/changelog
===
--- partman-ext3/debian/changelog (revision 60823)
+++ partman-ext3/debian/changelog (working copy)
@@ -1,7 +1,12 @@
partman-ext3 (59) UNRELEASED; urgency=low
+ [ Colin Watson ]
* Upgrade to debhelper v7.
+ [ Max Vozeler ]
+ * Warn user if configured to boot from ext4 on an arch without
+bootloaders known to support it.
+
-- Colin Watson cjwat...@debian.org Tue, 01 Sep 2009 02:13:13 +0100
partman-ext3 (58) unstable; urgency=low
Index: partman-ext3/check.d/_numbers
===
--- partman-ext3/check.d/_numbers (revision 60823)
+++ partman-ext3/check.d/_numbers (working copy)
@@ -1,2 +1,3 @@
09 nomountpoint_ext3
10 ext2_or_ext3_boot
+11 ext4_bootloader
Index: partman-ext3/check.d/ext4_bootloader
===
--- partman-ext3/check.d/ext4_bootloader (revision 0)
+++ partman-ext3/check.d/ext4_bootloader (revision 0)
@@ -0,0 +1,72 @@
+#!/bin/sh
+# Check that if the user configured to boot from ext4 this
+# arch has a choice of bootloader which can handle it.
+
+. /lib/partman/lib/base.sh
+
+for dev in $DEVICES/*; do
+ [ -d $dev ] || continue
+ cd $dev
+ open_dialog PARTITIONS
+ while { read_line num id size type fs path name; [ $id ]; }; do
+ [ $fs != free ] || continue
+ [ -f $id/method ] || continue
+ [ -f $id/acting_filesystem ] || continue
+ [ -f $id/mountpoint ] || continue
+ mountpoint=$(cat $id/mountpoint)
+ filesystem=$(cat $id/acting_filesystem)
+ if [ $mountpoint = / ]; then
+ root_fs=$filesystem
+ root_type=$type
+ root_path=$path
+ elif [ $mountpoint = /boot ]; then
+ boot_fs=$filesystem
+ boot_type=$type
+ boot_path=$path
+ fi
+ done
+ close_dialog
+done
+
+# If no separate boot partition exists root acts as boot
+if [ -z $boot_path ]; then
+ boot_fs=$root_fs
+ boot_type=$root_type
+ boot_path=$root_path
+fi
+
+# Only make further checks if this is ext4
+if [ $boot_fs != ext4 ]; then
+ exit 0
+fi
+
+# Duplicates decisions from the bootloader installers, but
+# we cannot wait until those happen.
+handles_ext4=
+
+ARCH=$(udpkg --print-architecture)
+case $ARCH in
+ i386|amd64)
+ # Those archs have lilo,grub,grub2 which are fine
+ handles_ext4=true
+ ;;
+ powerpc)
+ # May work, but untested
+ handles_ext4=true
+ ;;
+ alpha|powerpc|mips|sparc|mips|mipsel|hppa|*)
+ # Archs without bootloaders known to grok ext4
+ ;;
+esac
+
+if [ -z $handles_ext4 ]; then
+ ## XX show warning
+ db_set partman-ext3/boot_not_ext2_or_ext3 true
+ db_input critical partman-ext3/boot_not_ext2_or_ext3 || true
+ db_go || true
+ db_get partman-ext3/boot_not_ext2_or_ext3
+ if [ $RET = true ]; then
+ exit 1
+ fi
+fi
+
Property changes on: partman-ext3/check.d/ext4_bootloader
___
Added: svn:executable
+ *
Bug#543786: partman-auto-raid: having to name devices explicitly is clumsy
Hi Colin,
On Fri, Aug 28, 2009 at 02:12:55PM +0100, Colin Watson wrote:
On Fri, Aug 28, 2009 at 02:53:56PM +0200, Max Vozeler wrote:
On Wed, Aug 26, 2009 at 11:09:47PM +0100, Colin Watson wrote:
Attached is a patch which introduces new syntax, looking like this:
Any comments? I think this is a noticeable improvement, so I'll commit
it next week or so if there are no objections.
The change looks good to me, but note that I only read through
the patch and I haven't actually tested it.
===
--- README(revision 60467)
+++ README(working copy)
@@ -38,13 +38,12 @@
d-i partman-auto/disk string /dev/sda /dev/sdb
+# raidid can be anything, as long as it doesn't contain spaces or slashes
+# and matches something in raidid{ } in partman-auto/expert_recipe. You can
+# use hash separated lists of ordinary device names instead if you prefer.
d-i partman-auto-raid/recipe string \
- 1 2 0 ext3 /boot\
- /dev/sda1#/dev/sdb1 \
- . \
- 1 2 0 lvm - \
- /dev/sda5#/dev/sdb5 \
- .
+ 1 2 0 ext3 /boot raidid=1 . \
+ 1 2 0 lvm - raidid=2 .
A question, and a more general, potentially crazy one:
Currently partman-auto-* are limited in how complex block
devices can be preseeded and combined. Single depth is no
problem, but stacking complex block devices gets tricky.
(Or brings with it a coupling of unrelated parts which may
not be necessary, e.g. partman-auto-crypto and LVM.)
Reading your patch, it seemed to me that raidid actually
does two things, even though only the first may be intended:
One, it provides a stable and easily accessible identifier.
Second, (here starts crazy): It expresses something which
could be considered a dependency.
It could be taken to mean: Make sure whatever device provides
ID 2 is setup before doing anything else implied by this
preseeded partition.
Do you think the raidid could, usefully, be generalized to
something like deviceid= to allow for a future dependency-
based preseeding of complex block devices?
Or is that overengineering?
Max
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
Hi Guido, On Sun, Aug 09, 2009 at 01:32:42PM +0200, Guido Günther wrote: What's the reasoning for using UUID= instead of /dev/disk/by-uuid/ in fstab? Non udev systems? I wanted to research this question, took me a bit. The non-udev case you mentioned is the only reason I could make out for going with UUID= rather than /dev/disk/by-uuid/. Those systems rely on mount using blkid to find the matching partition and mount only does it itself when the UUID= notation is used in fstab. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543786: partman-auto-raid: having to name devices explicitly is clumsy
On Wed, Aug 26, 2009 at 11:09:47PM +0100, Colin Watson wrote: Attached is a patch which introduces new syntax, looking like this: Any comments? I think this is a noticeable improvement, so I'll commit it next week or so if there are no objections. ENOPATCH. :-) The concept sounds good to me. It might be applicable to other parts of partman, too. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Keymap problems in D-I (was: Re: Bugs in the latest Debian Sid installer)
Christian, On Sun, Aug 23, 2009 at 08:29:44PM +0200, Christian Perrier wrote: ... Thanks and repect for reacting in such a calm way. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[REMINDER] Installer Team meeting today 20:00 UTC
Hello everyone, On Mon, Aug 10, 2009 at 09:23:54AM +0200, Christian Perrier wrote: Given our current schedule, a team meetign hould happen on August 17th. [...] If there are enough people around, it would be good to have a meeting, still, as many things happened since the last one (live at Debconf). Indeed, lots of stuff happened! Five people have indicated that they would be around. I think thats fine for (at least a short) meeting. Time/place, just as reminder: ***Today***, August 17th, 20:00 UTC #debian-boot (irc.debian.org (oftc)) @Otavio: Couldnt find you on IRC. Time OK for you? See you tonight, Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541115: busybox: No longer creates tty[1-4] devices on s390
On Tue, Aug 11, 2009 at 09:56:43PM +0200, Frans Pop wrote: It looks like busybox also causes a failure on i386. If I boot a daily mini.iso, the boot hangs when executing the last line from /sbin/init: exec /usr/sbin/chroot . /bin/busybox init /dev/console /dev/console 21 I'm seeing this also on amd64. Replacing busybox-udeb with the older 1.13.3-1 results in a working installer. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
On Sat, Aug 08, 2009 at 04:03:38PM +0200, Max Vozeler wrote:
If there is rough concensus about this, I would go ahead and make
the change to use /dev/mapper in partman-target.
OK, it seem there is consensus. (last chance to protest! :) )
I have committed the attached change to partman-target which
makes d-i use /dev/mapper in the generated fstab.
Thanks for the advice everyone.
Max
Author: xam
Date: Thu Aug 13 00:15:38 2009
New Revision: 60137
Log:
Use /dev/mapper/ paths instead of UUID to refer to device
mapper devices in /etc/fstab.
Those names are meant to be stable and result in simpler
and clearer fstab entries.
Discussion leading to this change:
http://lists.debian.org/debian-boot/2009/08/msg00166.html
Modified:
trunk/packages/partman/partman-target/debian/changelog
trunk/packages/partman/partman-target/finish.d/fstab_hd_entries
Modified: trunk/packages/partman/partman-target/debian/changelog
==
--- trunk/packages/partman/partman-target/debian/changelog Wed Aug 12
23:46:18 2009(r60136)
+++ trunk/packages/partman/partman-target/debian/changelog Thu Aug 13
00:15:38 2009(r60137)
@@ -1,5 +1,7 @@
partman-target (63) UNRELEASED; urgency=low
+ * Use /dev/mapper/ paths instead of UUID to refer to device
+mapper devices in /etc/fstab.
* Use LABEL rather than UUID for entries in /etc/fstab if the
label was explicitly configured by the user.
Modified: trunk/packages/partman/partman-target/finish.d/fstab_hd_entries
==
--- trunk/packages/partman/partman-target/finish.d/fstab_hd_entries Wed Aug
12 23:46:18 2009(r60136)
+++ trunk/packages/partman/partman-target/finish.d/fstab_hd_entries Thu Aug
13 00:15:38 2009(r60137)
@@ -31,7 +31,7 @@
sort |
while read mp fs type options dump pass; do
case $fs in
- (/dev/disk/*|/dev/fd[0-9]*|/dev/mapper/*_crypt)
+ (/dev/disk/*|/dev/fd[0-9]*|/dev/mapper/*)
addfstab $(mapdevfs $fs) ${mp} $type $options
$dump $pass
;;
(/*)
Re: UUID in fstab for device mapper devices?
Hi all, Attempt to summarize the discussion so far (please correct): 1) We should use /dev/mapper/ paths rather than UUID in the fstab entries for all device mapper devices. 2) For some type of device mapper devices (multipath), using the /dev/disk/by-id/ symlinks would be better than /dev/mapper/. If there is rough concensus about this, I would go ahead and make the change to use /dev/mapper in partman-target. I would like to do so soon, because the current use of UUIDs breaks rootLV-on-cryptoPV (Encrypted LVM) installs in d-i. The /dev/disk/by-id/ improvement for specific types can then be considered and worked on separately. Sounds good? Objections? Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [PATCH 2/4] easy-build.sh: use getopts instead of rolling our own option parsing.
On Fri, Aug 07, 2009 at 02:05:52PM +0200, Frans Pop wrote: On Friday 07 August 2009, Ian Campbell wrote: +while getopts d:h OPT ; do Is getopts also supported in dash? Yes, and in POSIX. Maybe it would be good to also support --help if -h is added. getopts can't do longoptions. I'd say supporting --help is probably not worth the extra code. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
UUID in fstab for device mapper devices?
Hello fellow maintainers, we recently changed d-i (partman-target, to be precise) to use UUIDs in fstab in order to get stable device naming. Currently UUIDs are used for all devices except - /dev/fd* - cryptsetup mappings - those specified by explicit /dev/disk/by-* paths Since then, we concluded that it is preferable to go back to plain /dev/mapper/ paths for LVM LVs because those already provide stable device naming (and are more descriptive). What about your types of devices? (dmraid, multipath) Should we refer to them by UUID or with the /dev/mapper/ paths? Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
UUID in fstab for device mapper devices?
[Resend to @packages.debian.org] Hello fellow maintainers, we recently changed d-i (partman-target, to be precise) to use UUIDs in fstab in order to get stable device naming. Currently UUIDs are used for all devices except - /dev/fd* - cryptsetup mappings - those specified by explicit /dev/disk/by-* paths Since then, we concluded that it is preferable to go back to plain /dev/mapper/ paths for LVM LVs because those already provide stable device naming (and are more descriptive). What about your types of devices? (dmraid, multipath) Should we refer to them by UUID or with the /dev/mapper/ paths? Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
Hi Guido,
On Fri, Aug 07, 2009 at 05:15:06PM +0200, Guido Günther wrote:
we recently changed d-i (partman-target, to be precise) to use
UUIDs in fstab in order to get stable device naming.
So you're using /dev/disk/by-uuid/uuid in /etc/fstab?
Just plain UUID=. From a recent test install:
# / was on /dev/vda2 during installation
UUID=c08d38bd-90d8-4fea-b4c5-624600254667 / ext3
errors=remount-ro 0 1
Currently UUIDs are used for all devices except
- /dev/fd*
- cryptsetup mappings
- those specified by explicit /dev/disk/by-* paths
I'm confused. Doesn't every disk have symlnks in /dev/disk/by-id (even
LVM LVs)?
Yes, I would think so.
I meant that partman-target will keep any device paths that
start with /dev/disk/ without changing them to use UUID.
It is useful for the device paths for multipath you describe
below; If we get partman to use the /dev/disk/by-id/ device paths
in the first place, they will end up in fstab unchanged.
Since then, we concluded that it is preferable to go back to plain
/dev/mapper/ paths for LVM LVs because those already provide stable
device naming (and are more descriptive).
What about your types of devices? (dmraid, multipath)
multipath.udev sets up these links for persistent device naming:
# Create persistent links for multipath tables
ENV{DM_UUID}==mpath-*, \
SYMLINK+=disk/by-id/$env{DM_TYPE}-$env{DM_NAME}
# Create persistent links for dmraid tables
ENV{DM_UUID}==dmraid-*, \
SYMLINK+=disk/by-id/$env{DM_TYPE}-$env{DM_NAME}
# Create persistent links for partitions
ENV{DM_PART}==?*, \
SYMLINK+=disk/by-id/$env{DM_TYPE}-$env{DM_NAME}-part$env{DM_PART}
This is what should idealy be used in d-i for multipath device naming.
We could then start to remove the hacks that use /dev/mapper/mpath* to
reference multipath devices then.
Sounds good!
One way to do this could be to change the device path to
/dev/disk/by-id/.. in partman-base/init.d/parted if the device
is a multipath device.
This would save us from having to map the device name from
/dev/mapper/... to /dev/disk/by-id/.. later on.
Max
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [pkg-cryptsetup-devel] UUID in fstab for device mapper devices?
Hi Jonas, On Fri, Aug 07, 2009 at 05:01:30PM +0200, Jonas Meurer wrote: i suggest to go the same way for all device-mapper devices. at least the same argument (stable device names and more descriptive) holds for all of them. so i don't see a reason why to treat lvm devices different from dmraid or dm-crypt devices. I was secretly hoping to get away with doing just that. :-) The case seems pretty clear for - cryptsetup mappings - LVM LVs I'm less sure about dmraid. From what I learned the device paths there are stable, but controller dependent. So you would have invalid paths after moving disks to another controller. This might be an argument in favour of UUIDs for dmraid? For multipath, as I understood Guido, it is preferrable to refer to them via /dev/disk/by-id/ symlinks. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic partition setup in partman-{lvm,md,crypto}
On Tue, Jul 28, 2009 at 07:47:14PM +0100, Colin Watson wrote: Otavio told me that you and he and Joey had agreed it would be a good idea to upload what we have in trunk now and refine from there. Your patches look basically along the right lines - I'll review them when I have a chance ... I found some time to test the cleanups, and since they appeared to work with no obvious problems, I went ahead and committed them to trunk. Review very much appreciated when you find the time. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [RFC] rootcmd for d-i Makefile
On Sun, Jul 26, 2009 at 01:27:41PM -0300, Otavio Salvador wrote: On Sun, Jul 26, 2009 at 12:42 PM, Max Vozelerx...@debian.org wrote: I've been using this change locally for a few days. It allows to just do make as a regular user without having to remember to call it with fakeroot. I enjoy a lot the idea; if people do not have problems with it I'm 100% in favor of having it commited. I went over it once more and tried to think of possible problems, but didn't manage to come up with any. Take that for whatever it may be worth. :-) Based on that and the positive feedback, committed it to trunk. Please tell me if anything breaks, I will take care of it. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Kernel BoF, 29th July
Maks, On Wed, Jul 29, 2009 at 10:51:04PM +0200, maximilian attems wrote: even more if it is loop-aes which show a long history of hostily of the module owner versus linux-2.6 upstream. That's not true. There are several reasons why loop-AES has not been merged upstream, and has very little chance of getting upstream in the current form at all. But hostility of the loop-AES upstream author towards linux-2.6 upstream is definately not the case. I'd like to ask you to take more care before making such statements. Anyways, on a constructive point, looking forward: I'm about to submit a patchset that adds support for the loop-AES crypto modes to the upstream kernel, so that it can be used with plain dm-crypt and cryptsetup. I hope this will reduce the need for using the OOT module in the medium term, and will allow us in d-i to drop the reliance on the OOT module builds for fully featured crypto support. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539228: partman freezes with encrypted partitions
severity 539228 important thanks Hello, On Thu, Jul 30, 2009 at 12:43:04AM +0200, da jedall wrote: When i try to install debian squeeze on usb key (netinstall) and when i try to create installation over encrypted fs in partman,partman reload and freeze at 52% of loading. The installation is in french ,partman works in french until the bug occurs. Next partman crashes,and i have a message saying loading partman 52% (in english this time!!) and all stay freezed at this point. I will try to reproduce this and figure out what happens. For the moment I'm lowering severity to important because the partitioning (with and without crypto) seems to be working fine in general for the setups I tested today. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Automatic partition setup in partman-{lvm,md,crypto}
On Thu, Jul 23, 2009 at 02:58:12PM +0100, Colin Watson wrote: Talking through this with Max Vozeler identified several problems that I'd still like to fix: * There are several common chunks of code that should be moved into partman-base. I think I'll be working on some of that today. Expect RFC patches after lunch. :-) * There's some weird bug in handling of locked devices; the LVM menu, at least, offers the underlying devices of configured encrypted volumes when it shouldn't. That's fixed now in trunk. If you'd like to try this out, then I guess a reasonable way to do so would be to play with a current Ubuntu installation image: For people wanting to try it out, there is also a i386 image with the changes as they currently exist in trunk: http://people.debian.org/~xam/d-i/partman-newui_i386.iso Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[PATCH 1/2] partman: Add ask_active_partition to lib/base.sh
From: Max Vozeler m...@nusquama.org
This replaces shared code in partman-base, -crypto and -partitioning.
The only non-mechanical change is the one to partman-partitioning,
which would change the behaviour in case we have a bug somewhere that
makes us not clear the state of a deleted partition.
[Not yet tested, only for review.]
---
.../choose_partition/partition_tree/do_option | 34 +++
packages/partman/partman-base/lib/base.sh | 33 ++
packages/partman/partman-crypto/lib/crypto-base.sh | 36 +++-
.../partman-partitioning/free_space/new/do_option | 15 +++-
4 files changed, 48 insertions(+), 70 deletions(-)
diff --git
a/packages/partman/partman-base/choose_partition/partition_tree/do_option
b/packages/partman/partman-base/choose_partition/partition_tree/do_option
index a8031b0..ebd68a2 100755
--- a/packages/partman/partman-base/choose_partition/partition_tree/do_option
+++ b/packages/partman/partman-base/choose_partition/partition_tree/do_option
@@ -75,35 +75,11 @@ else
*)
while true; do
set +e
- device=$(humandev $(cat device))
- db_subst partman/active_partition DEVICE $device
- db_subst partman/active_partition PARTITION $num
- if [ -f $id/detected_filesystem ]; then
- filesystem=$(cat $id/detected_filesystem)
- RET=''
- db_metaget
partman/filesystem_long/$filesystem description || RET=''
- if [ $RET ]; then
- filesystem=$RET
- fi
- db_subst partman/text/there_is_detected
FILESYSTEM $filesystem
- db_metaget partman/text/there_is_detected
description
- else
- db_metaget partman/text/none_detected
description
- fi
- db_subst partman/active_partition OTHERINFO ${RET}
-
- if [ -f $id/detected_filesystem ] [ -f $id/format ];
then
- db_metaget partman/text/destroyed description
- db_subst partman/active_partition DESTROYED
${RET}
- else
- db_subst partman/active_partition DESTROYED ''
- fi
-
- ask_user /lib/partman/active_partition $dev $id
- exitcode=$?
- if [ $exitcode -ge 128 ] [ $exitcode -lt 192 ];
then
- exit $exitcode # killed by signal
- elif [ $exitcode -ge 100 ]; then
+ local code=0
+ ask_active_partition $dev $id $num || code=$?
+ if [ $code -ge 128 ] [ $code -lt 192 ]; then
+ exit $code # killed by signal
+ elif [ $code -ge 100 ]; then
break
fi
set -e
diff --git a/packages/partman/partman-base/lib/base.sh
b/packages/partman/partman-base/lib/base.sh
index 3b38d7e..95ff807 100644
--- a/packages/partman/partman-base/lib/base.sh
+++ b/packages/partman/partman-base/lib/base.sh
@@ -201,6 +201,39 @@ ask_user () {
return 0
}
+ask_active_partition () {
+ local dev=$1
+ local id=$2
+ local num=$3
+ local RET
+
+ db_subst partman/active_partition DEVICE $(humandev $(cat device))
+ db_subst partman/active_partition PARTITION $num
+
+ if [ -f $id/detected_filesystem ]; then
+ local filesystem=$(cat $id/detected_filesystem)
+ RET=''
+ db_metaget partman/filesystem_long/$filesystem description ||
RET=''
+ if [ $RET ]; then
+ filesystem=$RET
+ fi
+ db_subst partman/text/there_is_detected FILESYSTEM $filesystem
+ db_metaget partman/text/there_is_detected description
+ else
+ db_metaget partman/text/none_detected description
+ fi
+ db_subst partman/active_partition OTHERINFO ${RET}
+
+ if [ -f $id/detected_filesystem ] [ -f $id/format ]; then
+ db_metaget partman/text/destroyed description
+ db_subst partman/active_partition DESTROYED ${RET}
+ else
+ db_subst partman/active_partition DESTROYED ''
+ fi
+
+ ask_user /lib/partman/active_partition $dev $id || return $?
+}
+
partition_tree_choices () {
local IFS
for dev in $DEVICES/*; do
diff --git a/packages/partman/partman-crypto/lib/crypto-base.sh
b/packages/partman/partman-crypto/lib/crypto-base.sh
index 25d204b..82e16de 100644
--- a/packages
[PATCH 2/2] partman: Add partman_list_allowed() and use it in -crypto, -lvm, -md
From: Max Vozeler m...@nusquama.org
Consolidates identical code.
[Not yet tested, only for review.]
---
packages/partman/partman-base/lib/base.sh | 33 ++
packages/partman/partman-crypto/lib/crypto-base.sh | 36 +---
packages/partman/partman-lvm/lib/lvm-base.sh | 29 +---
packages/partman/partman-md/lib/md-base.sh | 29 +---
4 files changed, 44 insertions(+), 83 deletions(-)
diff --git a/packages/partman/partman-base/lib/base.sh
b/packages/partman/partman-base/lib/base.sh
index 95ff807..8c91aed 100644
--- a/packages/partman/partman-base/lib/base.sh
+++ b/packages/partman/partman-base/lib/base.sh
@@ -1103,6 +1103,39 @@ partman_unlock_unit() {
cd $cwd
}
+partman_list_allowed() {
+ local allowed_func=$1
+ local IFS
+ local partitions
+ local freenum=1
+ for dev in $DEVICES/*; do
+ [ -d $dev ] || continue
+ cd $dev
+
+ open_dialog PARTITIONS
+ partitions=$(read_paragraph)
+ close_dialog
+
+ local id size fs path
+ IFS=$TAB
+ echo $partitions |
+ while { read x1 id size x4 fs path x7; [ $id ]; }; do
+ restore_ifs
+ if $allowed_func $dev $id; then
+ if [ $fs = free ]; then
+ printf %s\t%s\t%s\t%s free #%d\n
$dev $id $size $(mapdevfs $(cat $dev/device)) $freenum
+ freenum=$(($freenum + 1))
+ else
+ printf %s\t%s\t%s\t%s\n $dev $id
$size $(mapdevfs $path)
+ fi
+ fi
+ IFS=$TAB
+ done
+ restore_ifs
+ done
+}
+
+
[ $PARTMAN_TEST ] || log
'***'
# Local Variables:
diff --git a/packages/partman/partman-crypto/lib/crypto-base.sh
b/packages/partman/partman-crypto/lib/crypto-base.sh
index 82e16de..0d28e21 100644
--- a/packages/partman/partman-crypto/lib/crypto-base.sh
+++ b/packages/partman/partman-crypto/lib/crypto-base.sh
@@ -1,35 +1,17 @@
. /lib/partman/lib/base.sh
. /lib/partman/lib/commit.sh
-crypto_list_allowed() {
- local IFS
- local partitions
- local freenum=1
- for dev in $DEVICES/*; do
- if [ ! -d $dev ] || [ -f $dev/crypt_realdev ]; then
- continue
- fi
- cd $dev
+# Would this partition be allowed as a physical volume for crypto?
+crypto_allowed() {
+ local dev=$1
+ local id=$2
- open_dialog PARTITIONS
- partitions=$(read_paragraph)
- close_dialog
+ # Allow unless this is a crypto device
+ [ ! -f $dev/crypto_realdev ]
+}
- local id size fs path
- IFS=$TAB
- echo $partitions |
- while { read x1 id size x4 fs path x7; [ $id ]; }; do
- restore_ifs
- if [ $fs = free ]; then
- printf %s\t%s\t%s\t%s free #%d\n $dev $id
$size $(mapdevfs $(cat $dev/device)) $freenum
- freenum=$(($freenum + 1))
- else
- printf %s\t%s\t%s\t%s\n $dev $id $size
$(mapdevfs $path)
- fi
- IFS=$TAB
- done
- restore_ifs
- done
+crypto_list_allowed() {
+ partman_list_allowed crypto_allowed
}
crypto_list_allowed_free() {
diff --git a/packages/partman/partman-lvm/lib/lvm-base.sh
b/packages/partman/partman-lvm/lib/lvm-base.sh
index 97aeb0b..a1425d9 100644
--- a/packages/partman/partman-lvm/lib/lvm-base.sh
+++ b/packages/partman/partman-lvm/lib/lvm-base.sh
@@ -241,34 +241,7 @@ pv_allowed () {
}
pv_list_allowed () {
- local IFS
- local partitions
- local freenum=1
- for dev in $DEVICES/*; do
- [ -d $dev ] || continue
- cd $dev
-
- open_dialog PARTITIONS
- partitions=$(read_paragraph)
- close_dialog
-
- local id size fs path
- IFS=$TAB
- echo $partitions |
- while { read x1 id size x4 fs path x7; [ $id ]; }; do
- restore_ifs
- if pv_allowed $dev $id; then
- if [ $fs = free ]; then
- printf %s\t%s\t%s\t%s free #%d\n
$dev $id $size $(mapdevfs $(cat $dev/device)) $freenum
- freenum=$(($freenum + 1))
- else
- printf %s\t%s\t%s\t%s\n $dev $id
$size $(mapdevfs $path
[RFC] rootcmd for d-i Makefile
Hi all,
I've been using this change locally for a few days. It
allows to just do make as a regular user without having
to remember to call it with fakeroot.
--- a/installer/build/Makefile
+++ b/installer/build/Makefile
@@ -95,9 +95,13 @@ include config/dir
export KEYRING
export KERNELVERSION
+ifneq ($(shell id -u),0)
+ ROOTCMD ?= fakeroot
+endif
+
# Useful command sequences
define submake
- $(MAKE) --no-print-directory
+ $(ROOTCMD) $(MAKE) --no-print-directory
endef
This likey doesn't cover all scenarios, e.g. I think
there would be a problem if some parts expect the fakeroot
to persist between different submake invokations.
That said, it works for me in the simple cases I frequently
use (build_{netboot,monolithic}, rebuild_netboot, clean_\
netboot, reallyclean) and does save me some typing.
What you do you guys think?
Max
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531572: backport of mkswap UUID support from git
.
++ * rand() is guaranteed to generate at least [0, 2^15) range,
++ * but lowest bits in some libc are not so random. */
++ srand(monotonic_us());
++ pid = getpid();
++ while (1) {
++ for (i = 0; i 16; i++)
++ buf[i] ^= rand() 5;
++ if (pid == 0)
++ break;
++ srand(pid);
++ pid = 0;
++ }
++
++ /* version = 4 */
++ buf[4 + 2] = (buf[4 + 2] 0x0f) | 0x40;
++ /* variant = 10x */
++ buf[4 + 2 + 2] = (buf[4 + 2 + 2] 0x3f) | 0x80;
++
++ bin2hex(uuid_string, (void*) buf, 16);
++ /* f.e. UUID=dfd9c173-be52-4d27-99a5-c34c6c2ff55f */
++ printf(UUID=%.8s -%.4s-%.4s-%.4s-%.12s\n,
++ uuid_string,
++ uuid_string+8,
++ uuid_string+8+4,
++ uuid_string+8+4+4,
++ uuid_string+8+4+4+4
++ );
++}
++#else
++# define mkswap_generate_uuid(buf) ((void)0)
+ #endif
+
+ #if 0 /* from Linux 2.6.23 */
+@@ -113,10 +190,10 @@ int mkswap_main(int argc, char **argv)
+ // Make a header. hdr is zero-filled so far...
+ hdr[0] = 1;
+ hdr[1] = (len / pagesize) - 1;
++ mkswap_generate_uuid((void*) hdr[3]);
+
+ // Write the header. Sync to disk because some kernel versions check
+ // signature on disk (not in cache) during swapon.
+-
+ xlseek(fd, 1024, SEEK_SET);
+ xwrite(fd, hdr, NWORDS * 4);
+ xlseek(fd, pagesize - 10, SEEK_SET);
Index: trunk/debian/patches/series
===
--- trunk/debian/patches/series (revision 59555)
+++ trunk/debian/patches/series (working copy)
@@ -4,3 +4,4 @@
version.patch
init-console.patch
strip.patch
+mkswap-uuid.patch
Index: trunk/debian/changelog
===
--- trunk/debian/changelog (revision 59555)
+++ trunk/debian/changelog (working copy)
@@ -7,6 +7,10 @@
[ Otavio Salvador ]
* [udeb] Add an udhcpc script to be used by netcfg.
+ [ Max Vozeler ]
+ * Backport mkswap UUID support. (closes: #531572)
+ * [udeb] Enable mkswap UUID support.
+
-- Otavio Salvador ota...@ossystems.com.br Sun, 19 Jul 2009 14:43:18 -0300
busybox (1:1.13.3-1) unstable; urgency=low
Bug#515249: installation-reports: Various issues on IBM Power5 (lvm, multipath, yaboot.conf)
severity 515249 normal clone 515249 -1 retitle -1 manual: Mention console=hvc0 for ppc? reassign -1 installation-guide thanks On Sun, Feb 15, 2009 at 10:49:36AM +, Paul McEnery wrote: Comments/Problems: Initial boot: Maybe not soe much an error, I had to specify the console at the boot prompt console=hvc0,38400 There is no mention of hvc0 in the powerpc installation guide, so it might be useful to add a mention there. Is it common to have hvc0 on ppc? I know it only wrt. XEN. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Debian installer session at Debcamp
During Debcamp this year, people interested in the installer will meet to work and have a fun time together. We will be extra happy to have both new people and oldtimers take part! There is a wiki page for this year's Installer session at Debcamp which already contains some ideas and plans from people: http://wiki.debian.org/DebianInstaller/WorkSessions/DebCamp9 If you like to come, please add you name and ideas to the wiki page. There will be enough oldtimers around to talk about ideas, help guide newcomers into working on the installer and help with questions. The SqueezeGoals wiki page has some existing tasks that could be a good start for anyone who likes to get involved with the installer: Work to pick up section on http://wiki.debian.org/DebianInstaller/SqueezeGoals So, interested in how the installer works, meeting people involved and contributing to some area of the installer that interests you? Then come to Debcamp and join the fun... :-) Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#530904: calls udevinfo which no longer exists
tags 530904 + patch
thanks
On Fri, May 29, 2009 at 09:44:37AM -0300, Otavio Salvador wrote:
On Thu, May 28, 2009 at 2:52 PM, Martin Michlmayr t...@cyrius.com wrote:
Package: partman-target
Version: 59
Severity: serious
finish.d/fstab_removable_media_entries calls udevinfo which no longer
exists in udev 0.141-1.
In order to find out whether this should be fixed in partman-target or
in udev, I grepped through d-i to see who still uses udevinfo. As it
turns out, nobootloader/debian/postinst, debian-installer-utils/list-devices
and os-prober/os-prober all check for udevadm and use that when it's
available.
Yes, it needs to be fixed in partman-target.
This fixes it in a way similar to d-i-u/list-devices.
Max
Index: partman-target/debian/changelog
===
--- partman-target/debian/changelog (Revision 58701)
+++ partman-target/debian/changelog (Arbeitskopie)
@@ -1,5 +1,6 @@
partman-target (60) UNRELEASED; urgency=low
+ [ Colin Watson ]
* Merge from Ubuntu:
- Escape spaces, tabs, newlines, and backslashes in fstab according to
the procedure described in getmntent(3) (LP: #38224).
@@ -16,6 +17,9 @@
* Fix proper_mountpoints check to cope with mountpoints containing commas.
* Use block-attr from di-utils 1.68.
+ [ Max Vozeler ]
+ * Use udevadm instead of udevinfo if available (closes: #530904).
+
-- Colin Watson cjwat...@debian.org Fri, 20 Feb 2009 13:20:43 +
partman-target (59) unstable; urgency=high
Index: partman-target/finish.d/fstab_removable_media_entries
===
--- partman-target/finish.d/fstab_removable_media_entries (Revision 58701)
+++ partman-target/finish.d/fstab_removable_media_entries (Arbeitskopie)
@@ -93,19 +93,22 @@
founddevs=
if [ -d /sys/block ]; then
if type udevadm /dev/null 21; then
- disk_containing () {
- dirname $(udevadm info -q path -n $dev)
+ device_info () {
+ udevadm info $@
}
elif type udevinfo /dev/null 21; then
- disk_containing () {
- dirname $(udevinfo -q path -n $dev)
+ device_info () {
+ udevinfo $@
}
fi
fi
-if type disk_containing /dev/null 21; then
+if type device_info /dev/null 21; then
+ disk_containing () {
+ dirname $(device_info -q path -n $dev)
+ }
partitions=$(list-devices partition)
for dev in $partitions; do
- if ! udevinfo -q env -n $dev | grep -q '^ID_BUS=usb$'; then
+ if ! device_info -q env -n $dev | grep -q '^ID_BUS=usb$'; then
continue
fi
disk=$(disk_containing $dev)
Re: status persistent naming of devices for disks
On Mon, May 18, 2009 at 10:51:02PM +0200, Luk Claes wrote: There were some commits related to this AFAIR, though it's unclear what the exact status is. Is it time to start testing or are there still some issues left? Just one bit I noticed: partman-target (60) UNRELEASED needs an upload. It sets the default to generating UUID= entries. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529363: grub-installer: make sure grub-pc gets used when ext4 is chosen
tags 529363 - wontfix thanks Hi all, this is a proposed patch to make grub-installer use grub-pc if bootfstype is ext4. For grub-of and grub-efi, I assume they can handle ext4 just as well as grub-pc since they are also built from grub2? This change just covers cases in which we would use GRUB Legacy but found ext4. Max Index: grub-installer/debian/changelog === --- grub-installer/debian/changelog (revision 58603) +++ grub-installer/debian/changelog (working copy) @@ -1,8 +1,12 @@ grub-installer (1.38) UNRELEASED; urgency=low + [ Colin Watson ] * Make findfs use the last of any mounts found, in case there's more than one due to pilot error in the partitioner (LP: #289101). + [ Max Vozeler ] + * Use grub2 when ext4 is chosen (closes: #529363). + -- Colin Watson cjwat...@debian.org Thu, 14 May 2009 13:08:03 +0100 grub-installer (1.37) unstable; urgency=low Index: grub-installer/grub-installer === --- grub-installer/grub-installer (revision 58603) +++ grub-installer/grub-installer (working copy) @@ -337,6 +337,10 @@ grub_package=grub-pc fi ;; +ext4:*:grub) + # We boot from ext4, requires grub2 + grub_package=grub-pc + ;; *:*:grub) db_input low grub-installer/grub2_instead_of_grub_legacy || [ $? -eq 30 ] db_go || true
Bug#425648: Fixed in QEMU Subversion repository
reassign 425648 qemu tags 425648 - wontfix thanks Reassigning from grub-installer to qemu. On Sat, Jan 10, 2009 at 11:17:08PM +0100, Håkon Stordahl wrote: Hello. This problem appears to be the result of a bug in QEMU that have been fixed in the Subversion repository, as the following log message indicates: r5963 | aurel32 | 2008-12-10 16:02:16 +0100 (Wed, 10 Dec 2008) | 12 lines target-i386: Fix jmp im on x86_64 when executing 32-bit code When running grub-install (32-bit) on an x86_64 Linux system in qemu, it hangs on a pagefault forever, because an integer overflow occurs on the IP on jmp im. This patch masks overflows for 32 bit IPs on a 64 bit system, just like it is done for 16 bit IPs already. Using this patch, x86_64 openSUSE installation works again. Signed-off-by: Alexander Graf ag...@suse.de Signed-off-by: Kevin Wolf kw...@suse.de Signed-off-by: Aurelien Jarno aurel...@aurel32.net Could this fix be applied for a Lenny update? Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Log from the D-I team meeting of May 18th 2009
The meeting log is now available on http://wiki.debian.org/DebianInstaller/Meetings (Trying to fill in for our regular and all-time favourite coordinator bubulle who couldn't attend today. :-) ) Next meeting will be in two weeks time, on the 1st of June 20:00 UTC. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517471: ability to configure the random key encryption of tmp partitions during installaion
reassign 517471 partman-crypto thanks On Fri, Feb 27, 2009 at 06:25:23PM -0500, M. McGowan wrote: It is possible to encrypt loop-aes and dm-crypt tmp (like /tmp or /var/tmp) partitions with a random key at boot time, but the Debian installer will not configure this. The installer will only configure swap partitions like that. Have you tried configuring the partition with a random key, and then setting Use as of the encrypted partition to e.g. ext2 ? The installer should take care of setting the fstab/ crypttab flags as appropriate for tmp. If that doesn't work, it would indicate a bug we need to fix in partman-crypto. It is supposed to work for both loop-AES and dm-crypt. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: The future of the D-I team
On Thu, Feb 26, 2009 at 09:49:58PM +0100, Christian Perrier wrote: Now that the lenny release is over, I think it's time for all of us to gather and discuss what the D-I team currently is and what should be done for the lenny-squeeze release cycle (not technically speaking but first more on organisational issues). If we organize something called a team meeting to talk about this, who would attend? I'm hoping to get more actively involved again now that squeeze development has opened. At the very least, I'll be taking care of crypto. Count me in on the meeting unless I'm busy/away on the particular date. Max -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Please unblock loop-aes-utils 2.13.1-4
Hi release team, please unblock loop-aes-utils 2.13.1-4; the only change in -4 is an RC bugfix. CCing -boot because it includes an udeb. Max Closes: 495682 Changes: loop-aes-utils (2.13.1-4) unstable; urgency=low . * patches/losetup_add_option_f.dpatch: - Added to support find next free loop in losetup. (closes: #495682) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Some love for partman-md
Hi all, On Fri, May 30, 2008 at 09:52:39PM +0200, Max Vozeler wrote: Note that I haven't actually tested the changes so far but I'm planning to do a few test installs later today. I got around to testing it just now. I used the following netboot mini.iso with -base, -md and mdcfg with your changes included in the initrd: http://nusquama.org/~max/tmp/mdtest1.iso (i386) I'm attaching my notes. To summarize: I did a rather complex setup involving RAID0, RAID1 and crypto and it worked without a glitch. It correctly recovered from partman restarts, retained crypto configuration after configuring RAID and is currently installing the base system. I'll send an update once qemu is finished ;-) The change preventing resize and deletion of partitions on loop-type devices worked fine. Things explicitly not tested: - Inactive/deactiveated RAID devices - I didn't know how to test it. - RAID on crypto (not a useful setup, or is it?) If you'd ask me, I'd say lets commit those changes and make sure to include them in beta3. One risk I'm seeing is that we're effectively enabeling setups that were previously not possible - perhaps there are some bugs to be shaken out. Things like root-on-crypto-on-raid probably need testing. I just remember there was indeed one odd thing: After I finished partitioning the mdcfg dialog came up again. Not sure what was happening there. Max Notes during partitioning hda hda1 100MB ext2 boot hda2 100MB raid hda3 800MB raid hdb hdb1 100MB crypto hdb2 100MB raid hdb3 800MB raid --- Configure encrypted volumes - Enter passphrase - partman restarts Encrypted volume hdb1_crypt appears - Use as ext3 - Mountpoint /opt Configure software RAID - Create MD device - RAID1 - Number of devices: 2 - Number of spares: 0 - Select hda2, hdb2 - Finish - partman restarts RAID1 device appears - The encrypted volume is still there, all settings kept :-) - Select RAID1 device - Use as physical volume for encryption - Type dm-crypt - Done (Here I accidentally exited partman by pressing ESC. Select partman again from main-menu. It starts and all settings are correctly remembered :-)) Configure encrypted volumes - Enter passphrase - partman restarts Encrypted volume md0_crypt appears - Select, use as ext3 - Mountpoint /home Configure software RAID - Create MD device - RAID0 - Select hda3, hdb3 - Finish - partman restarts (Here qemu started hanging with near 100% system cpu on the host system. I suspect this is a problem with kqemu. I closed qemu and started over). Starting over.. Partman starts - Manual partitioning - Both RAID0 and RAID1 devices detected automatically Select hda1 - Use as ext2 - Mountpoint /boot Select RAID1 device - Use as physical volume for encryption - Encryption type dm-crypt Configure encrypted volumes - Enter passphrase - partman restarts Encrypted volume md0_crypt appears - Select, use as ext3 - Mountpoint /home - Done Select RAID0 device - Use as ext3 - Mountpoint / Select hdb1 - Use as physical volume for encryption - Encryption type dm-crypt - Random key Configure encrypted volumes - Enter passphrase - partman restarts Encrypted volume hdb1_crypt appears - Use as swap Finish partitioning and write changes to disk Configure MD devices comes up !?!? - Select Finish Base install starts mdadm asks which arrays should be started during early boot. Keep default all.
Re: [RFC] Some love for partman-md
On Sat, May 31, 2008 at 02:59:51PM +0200, Max Vozeler wrote: It correctly recovered from partman restarts, retained crypto configuration after configuring RAID and is currently installing the base system. I'll send an update once qemu is finished ;-) Addendum: The system came up just fine :-) / was correctly mounted from the RAID0 array md1 /home was correctly mounted from the dm-crypt volume stored on the RAID1 array md0. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Some love for partman-md
On Sat, May 31, 2008 at 02:59:51PM +0200, Max Vozeler wrote: Things explicitly not tested: - Inactive/deactiveated RAID devices - I didn't know how to test it. - RAID on crypto (not a useful setup, or is it?) Also untested: - partman-auto-raid Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Some love for partman-md
Hi Frans, On Sat, May 31, 2008 at 03:35:42PM +0200, Frans Pop wrote: I just remember there was indeed one odd thing: After I finished partitioning the mdcfg dialog came up again. Not sure what was happening there. That would be a major bug! I could reproduce it. It seems mdcfg postinst is started by main menu after partman has finished: May 31 13:45:01 main-menu[803]: Menu item 'mdcfg' selected I'm not seeing how Jérémy's changes would have caused that to happen though. Also, I'm not sure what is supposed to happen - should mdcfg be started by main-menu? Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Some love for partman-md
On Sat, May 31, 2008 at 03:56:24PM +0200, Max Vozeler wrote: On Sat, May 31, 2008 at 03:35:42PM +0200, Frans Pop wrote: I just remember there was indeed one odd thing: After I finished partitioning the mdcfg dialog came up again. Not sure what was happening there. That would be a major bug! I could reproduce it. It seems mdcfg postinst is started by main menu after partman has finished: I suppose this was caused by me including 'mdcfg' (rather than just 'mdcfg-utils') in the initrd. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#482092: XTS and LRW mode of operation
Hi Alberto, On Tue, May 20, 2008 at 08:41:19PM +0200, Alberto wrote: Please add aes-lrw-benbi and aes-xts-plain to the list of available mode of operation. XTS is the upcoming standard. Thanks for the suggestion. I think offering those modes in partman-crypto is very desirable. Before we can do it we will need to make some non-trivial code changes though to account for the different key sizes that are valid in combination with those modes. The kernel Kconfig help suggests that for LRW we'd need to add 128 bits and for XTS to double the key size: aes-lrw-benbi: 256/320/384 bits aes-xts-plain: 256/384/512 bits I wonder how we should best handle this difference. We could try to offer the valid key sizes only after the user has chosen the iv-algorithm, but that is more involved because users may currently change parameters in any order. Perhaps we should just offer the regular key sizes (128, 192, 256 bits) and adjust them (adding 128 or doubling it) depending on the iv-algorithm selected. The latter seems more flexible, but may be surprising for people who are aware of the different requirements. They may wonder why they can select 128-bit AES with aes-lrb-benbi, for example. Do you think this could be a problem? Another question comes to mind: Since XTS is considered to be the successor to LRW (at least for IEEE P1619 standard), are there reasons to offer any LRW modes? Are you aware of any practical advantages over XTS? Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478598: partman-crypto: make clearer that changing method resets defaults
Hi Frans,
On Fri, May 30, 2008 at 07:23:32PM +0200, Frans Pop wrote:
What about this patch for partman-crypto.templates?
@@ -48,6 +48,8 @@ _Description: Encryption method:
Template: partman-crypto/crypto_type
Type: select
Choices: ${CHOICES}
# :sl3:
_Description: Encryption method for this partition:
+ Changing the encryption method will set other encryption related fields
+ to their defaults values for the new encryption method.
Sounds good to me. Thanks!
N.B. I just saw that if the encryption method dialog is displayed, but the
value is not actually changed, the other fields are _also_ reset to
defaults. I would say that is a bug.
Agreed. I'll look into fixing this.
Max
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Some love for partman-md
Hi Jérémy,
Attached you will find an attempt to do so. The changeset is only broke
down in two patches:
* The first is a bit invasive (partman-md, partman-base, mdcfg) and
improve globally the way MD devices are initialized and from my tests
fix 10 bugs at ounce (counting merged ones).
Impressive. Thanks for doing this work :-)
Apart from one change which I'm not sure is correct, I
couldn't spot any significant problems. More comments
below inline with the patches.
Note that I haven't actually tested the changes so far
but I'm planning to do a few test installs later today.
* The second is in partman-partitioning and prevent deletion and
resizing for MD, LVM and crypto devices as they do not work correctly
for any of these devices.
This one is obviously correct.
I would actually suggest to commit it straight away,
independent of the more invasive changes above.
...
diff --git a/packages/mdcfg/md-init.sh b/packages/mdcfg/md-init.sh
new file mode 100755
index 000..53645f8
--- /dev/null
+++ b/packages/mdcfg/md-init.sh
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+if [ -e /proc/mdstat ]; then
+ exit 0
+fi
+
+# Try to load the necesarry modules.
(Typo - necessary)
+# Supported schemes: RAID 0, RAID 1, RAID 5
+depmod -a /dev/null 21
+modprobe md /dev/null 21 || modprobe md-mod /dev/null 21
+modprobe raid0 /dev/null 21
+modprobe raid1 /dev/null 21
+# kernels =2.6.18 have raid456
+modprobe raid456 /dev/null 21 || modprobe raid5 /dev/null 21
A thought unrelated to your changes since this code is
just moved from mdcfg.sh:
Should we use something like
load_module() {
log-output modprobe $1
}
load_module md || load_module md-mod
.. etc
To know when there are problems loading the modules?
diff --git a/packages/partman/partman-base/debian/changelog
b/packages/partman/partman-base/debian/changelog
index 2d63730..31b93af 100644
--- a/packages/partman/partman-base/debian/changelog
+++ b/packages/partman/partman-base/debian/changelog
@@ -1,3 +1,11 @@
+partman-base (121) UNRELEASED; urgency=low
+
+ [ Jérémy Bobbio ]
+ * Instead of skipping every MD devices during partman initialization, we
+know only skip the ones that are deactivated.
Typo s/know/now/ ?
+
+ -- Jérémy Bobbio [EMAIL PROTECTED] Thu, 29 May 2008 16:07:37 +
+
partman-base (120) unstable; urgency=high
[ Jérémy Bobbio ]
diff --git a/packages/partman/partman-base/init.d/parted
b/packages/partman/partman-base/init.d/parted
index 346170a..f7cfe30 100755
--- a/packages/partman/partman-base/init.d/parted
+++ b/packages/partman/partman-base/init.d/parted
...
part_of_sataraid () {
local raiddev
for raiddev in $(dmraid -r -c); do
@@ -52,8 +61,7 @@ if [ ! -f /var/run/parted_server.pid ]; then
IFS=$NL
for partdev in $(parted_devices |
- grep -v '^/dev/md' |
- sed 's,^/dev/\(ide\|scsi\|[hs]d\),!/dev/\1,' |
+ sed 's,^/dev/\(ide\|scsi\|[hsm]d\),!/dev/\1,' |
Could be renamed to part_of_raid() or something after the change?
diff --git a/packages/partman/partman-md/debian/changelog
b/packages/partman/partman-md/debian/changelog
index e93fc37..384d64a 100644
--- a/packages/partman/partman-md/debian/changelog
+++ b/packages/partman/partman-md/debian/changelog
@@ -1,3 +1,16 @@
+partman-md (42) UNRELEASED; urgency=low
+
+ [ Jérémy Bobbio ]
+ * Clean up the initialization of MD devices. Together with the changes
+introduced in partman-base ( 120), setup of RAID devices won't be lost
+accross partman restarts anymore.
+(Closes: #391479, #391483, #393728, #398668)
s/accross/across/
+ * Load the necassary modules and scan RAID arrays during partman
+initialization. (Closes: #391474)
s/necassary/necessary/
+Requires mdcfg-utils ( 1.26).
+
+ -- Jérémy Bobbio [EMAIL PROTECTED] Thu, 29 May 2008 16:02:39 +
+
partman-md (41) unstable; urgency=low
[ Frans Pop ]
diff --git a/packages/partman/partman-md/init.d/md
b/packages/partman/partman-md/init.d/md
index e5024f2..96b0b52 100755
--- a/packages/partman/partman-md/init.d/md
+++ b/packages/partman/partman-md/init.d/md
@@ -2,16 +2,25 @@
. /lib/partman/lib/base.sh
-# Load modules
-#depmod -a 1/dev/null 21
-#modprobe md 1/dev/null 21 || modprobe md-mod 1/dev/null 21
-#
-## Load supported personalities
-#modprobe raid1 1/dev/null 21
-#
-## Detect and start MD devices
-#/sbin/mdadm --examine --scan --config=partitions /tmp/mdadm.conf
-#/sbin/mdadm --assemble --scan --run --config=/tmp/mdadm.conf --auto=yes
+# Check if we have RAID
+if [ ! -f /proc/mdstat ]; then
+ exit 0
+fi
+
+# Obtain the size of an MD device
+get_size () {
+ while [ -z $(echo $line | grep ^md$NUMBER :) ]; do
+ read line
+ [ $? -eq 1 ] break # EOF
+ done
+ read line
+ size=$(echo $line | sed -e 's/ blocks.*//')
+ # If the sed failed, the
Re: [PATCH] Enable partman-crypto to work with keys on removable devices
Hi David,
On Tue, May 13, 2008 at 08:02:28PM +0200, David Härdeman wrote:
In the setup encrypted volumes stage of partman, the user will be
given a list of partitions known to partman and after selecting one, a
path must be entered. If that file already exists on the device, it will
be used as the keyfile, otherwise a new keyfile will be created.
Nice work. This will allow us to close #381894.
I've done a test install using qemu (with a secondary qemu harddisk as
the removable device) and a SVN version of cryptsetup (which has the
necessary mountdev keyscript). Also, due to a bug in klibc, only ext3
is supported for now (bug reported, will be fixed before the next upload
of cryptsetup which will allow any common fs to be used).
Sounds like we should hold off until cryptsetup is ready.
My d-i knowledge is rusty so a review of the patch would be much
appreciated. (I've also been out of the loop wrt. d-i development,
deadlines for the next release, etc...so I have no idea how suitable
this patch is right now in the bigger picture)
Otavio, could you advise? Is it okay to commit such new
features to trunk soon and then upload after beta2?
I'm also planning to use some of the infrastructure of the patch to add
support for two-factor keys (ask a passphrase, hash it, get a keyfile
from usb stick, xor the two together, use that as the key) and
smartcards (I've already ordered the hardware, dunno when I'll get it).
Great. Looking forward to it :-)
+Template: partman-crypto/removable-source-path
+Template: partman-crypto/removable-source-partition
+Template: partman-crypto/removable-confirm-create
+Template: partman-crypto/removable-bad-keyfile
The names of those *removable* templates confused me a bit
when I was reading the code. Perhaps we could find more
specific and self-descriptive names?
Hm. This is what I came up with. Not sure I acutally like
them better, but they are more specific:
removabledev-partition
removabledev-key-path
removabledev-key-confirm-create
removabledev-key-badformat
+Template: partman-crypto/removable-confirm-create
+Type: boolean
+Default: false
+# :sl3:
+_Description: Create new key?
+ No key was found on ${DEVICE} at path ${PATH}, do you wish to create
+ a new key?
s/at path/in path/ ?
+Template: partman-crypto/removable-bad-keyfile
+Type: error
+# :sl3:
+_Description: Invalid encryption key
+ You have selected a pre-existing key file which is not suitable as a
+ crypto key as it is not large enough. Please try using a different
+ key file.
Terminology - key vs. crypto key vs encryption key.
We should use one term consistently. Personally, I think
I'd go for encryption key.
Index: finish.d/crypto_config
===
--- finish.d/crypto_config(revision 53290) +++ finish.d/crypto_config
(working copy)
@@ -96,6 +96,27 @@
keyfile=/dev/urandom
elif [ $keytype = passphrase ]; then
keyfile=none
+ elif [ $keytype = removabledev ]; then
+ local keydev keypath udevlinks tmp
+ keypath=$(cat $realdevdir/keypath)
+ keydev=$(cat $realdevdir/keydev)
+
+ # We need to use stable device names as using e.g. /dev/hda2
+ # will break the boot if a second USB key is present.
+ udevlinks=
+ for tmp in by-id by-uuid by-label by-path; do
+ if [ -d /dev/disk/$tmp ]; then
+ udevlinks=$udevlinks /dev/disk/$tmp/*
+ fi
+ done
+ for tmp in $udevlinks; do
+ if [ $(readlink -f $tmp) = $keydev ]; then
+ keydev=$tmp
+ break;
+ fi
+ done
I think this should be broken out into a generic
persistent_device_name() in partman-base.
Such a function for mapping devices to persistent names
will be useful when we start using persistent device
names in other parts of partman.
Once that happens, we might also want to make all the
persistent device names use the same mechanism (e.g. by-id).
Last I remember the discussion was still undecided about
which mechanism was most suitable.
Index: blockdev-keygen
===
--- blockdev-keygen (revision 53290)
+++ blockdev-keygen (working copy)
@@ -192,6 +192,110 @@
return 0
}
The below would rather fit into crypto-base.sh than
blockdev-keygen IMO.
- It creates files in the device directory.
- The debconf interaction is about getting the right
removable device and the final path to store the key.
No reason blockdev-keygen should care about those.
+# Create or load an already created keyfile on a user-specified device
+create_removable_keyfile() {
+ local keyfile keybytes noninteractive source_dev source_id
Re: [PATCH] Enable partman-crypto to work with keys on removable devices
Hi David, On Tue, May 13, 2008 at 08:02:28PM +0200, David Härdeman wrote: after a long hiatus I decided to do some d-i hacking again. Good to see you back. ... My d-i knowledge is rusty so a review of the patch would be much appreciated. (I've also been out of the loop wrt. d-i development, deadlines for the next release, etc...so I have no idea how suitable this patch is right now in the bigger picture) Unfortunately I'm swamped with $JOB right now - I will find time for review on thursday, hopefully. Just a thought on quick reading: I'm also planning to use some of the infrastructure of the patch to add support for two-factor keys (ask a passphrase, hash it, get a keyfile from usb stick, xor the two together, use that as the key) and smartcards (I've already ordered the hardware, dunno when I'll get it). That's great. If we plan to add second factors do you reckon we should still support non-wrapped plain keys? I worry a bit that the security implications of plain keys will be difficult to convey to users inside the partman UI, and so they might get a wrong sense of security. Plain keys on removable device - Decrypt by access to the device Passphrase - Decrypt by access to your head GnuPG keyfiles - Decrypt by access to your head, plus file GnuPG keyfile on removable device - Decrypt by access to your head, plus file on device etc. Will the user instinctly grasp the implications correctly? If not, perhaps we should a) not offer plain keys at all? b) offer plain keys only to be stored on encrypted devices? c) name it Plain key on removable device (DONOTUSEUNLESSYOUKNOWWHATYOUAREDOING!) or something? ;-) Just a thought. ? Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#478591: cdebconf-entropy: Dialog texts and buttons
On Sat, May 03, 2008 at 06:24:21PM +0200, Jérémy Bobbio wrote: On Wed, Apr 30, 2008 at 01:43:20AM +0200, Frans Pop wrote: Looks like the Continue button becomes active automatically after enough entropy has been gathered (same dialog remains displayed, but its text changes and the button becomes active). Maybe it should just be hidden while entropy is still being gathered. I had a look today, and due to newt current limitations, this would be hard to do in a nice way. So I think this is pretty wontfix. Me too - I've played around with newt but came to essentially the same conclusion. I think that having a Go back button to break off the process of gathering entropy would make more sense. This could still be useful. The entropy plugins add a Go Back button when the backup capability is set. This was not actually the case before version 29, where cdebconf-newt-entropy was always adding the Go Back button. So we have a regression here if it's not shown during the installation. :D We did have a regression there. Already fixed in SVN. :_) Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] cdebconf: Fix build of ncurses,bogl,slang frontends
Hi Jérémy, On Mon, May 05, 2008 at 10:15:15PM +0200, Jérémy Bobbio wrote: On Sun, May 04, 2008 at 03:25:47PM +0200, Max Vozeler wrote: They need to be adapted to the changed API for q_get_* etc. The attached patch should be obviously correct and safe to apply, but I'm sending it here for review just in case. Well… It's been quite some time that I wonder if we should keep this outdated and unused frontend in cdebconf source. If we remove them from the tree, they could still be resurected from the subversion history. Whether to keep them - I have no strong opinion. I noticed because they are enabled by default if you don't set the frontends explicitly (./configure; make) and those API changes broke the build. If noone objects, let's make them able to build again and take the question whether to keep them separately. Can anyone see any reasons to actually keep them? They may serve as interesting example code? For one thing, they are much smaller than the other frontends, although they may just be incomplete. Are they already outdated and broken? Do they present actual maintainance burden? If we do remove them now and keep changing the API, it will be significantly more difficult to ressurrect them later than if we just drag them along. Just thinking aloud, since I'm not actually doing any work on cdebconf ... Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478591: cdebconf-entropy: Dialog texts and buttons
On Sun, May 04, 2008 at 05:50:34PM +0200, Frans Pop wrote: On Sunday 04 May 2008, Max Vozeler wrote: Patch attached - Hmm. Should the string not also be changed in the templates and .c code of cdebconf-entropy for all frontends? Yep, you are right. Other issues: o Variable expansion is not done for the fallback strings provided in the frontends themselves. o It seems like variable expansion is not done for template snippets like partman-crypto/entropy-success (?) At least it didn't work in my testing. Not sure why. From a quick reading of the code, it uses question_get_text() on the template, which I understand should do the expansion. Also, that does not cover the other suggestion I had for a string change. We should probably do both at the same time. ! I also suggest changing: ! Enter random characters or move mouse randomly ! to: ! Enter random characters or make random movements with your mouse I'm neutral about this change; Both versions sound good to my non-native ear. +_Description: You can help speed up the process by entering random +characters on the keyboard or by making random movements with the mouse, +or just wait until enough key data has been collected (which can take a +long time). And today I noticed something else. When no action is taken (keyboard or mouse) no entropy is gathered _at all_. So the last part of the sentence above (or just wait ...) is IMO not correct. Indeed. We should probably reword the templates to drop any mention of just wait. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[PATCH] cdebconf: Fix build of ncurses,bogl,slang frontends
Hi all,
They need to be adapted to the changed API for q_get_* etc.
The attached patch should be obviously correct and safe to apply,
but I'm sending it here for review just in case.
Max
Index: debian/changelog
===
--- debian/changelog (Revision 53045)
+++ debian/changelog (Arbeitskopie)
@@ -1,8 +1,13 @@
cdebconf (0.131) UNRELEASED; urgency=low
+ [ Frans Pop ]
* gtk frontend: remove special handling for countrychooser/country-name as
that template no longer exists. Requires: localechooser (= 2.02).
+ [ Max Vozeler ]
+ * src/modules/frontend/{ncurses,slang,bogl}: Adapt to API changes made in
+cdebconf 0.129 - q_get_*() and question_get_value().
+
-- Frans Pop [EMAIL PROTECTED] Sun, 20 Apr 2008 18:21:40 +0200
cdebconf (0.130) unstable; urgency=low
Index: src/modules/frontend/ncurses/ncurses.c
===
--- src/modules/frontend/ncurses/ncurses.c (Revision 53045)
+++ src/modules/frontend/ncurses/ncurses.c (Arbeitskopie)
@@ -225,8 +225,8 @@
{
WINDOW *qrywin = UIDATA(ui)-qrywin;
WINDOW *descwin = UIDATA(ui)-descwin;
- char *descr = q_get_description(q);
- char *ext_descr = q_get_extended_description(q);
+ char *descr = q_get_description(ui, q);
+ char *ext_descr = q_get_extended_description(ui, q);
drawframe(ui, WIN_QUERY, ui-title);
wrapprint(qrywin, descr, 0, COLS-2);
@@ -369,13 +369,13 @@
WINDOW *win = UIDATA(ui)-qrywin;
/* Parse out all the choices */
- count = strchoicesplit(q_get_choices_vals(q), choices, DIM(choices));
+ count = strchoicesplit(q_get_choices_vals(ui, q), choices, DIM(choices));
if (count = 0) return DC_NOTOK;
if (count == 1)
defval = choices[0];
- strchoicesplit(q_get_choices(q), choices_translated, DIM(choices_translated));
- dcount = strchoicesplit(question_get_field(q, C, value), defaults, DIM(defaults));
+ strchoicesplit(q_get_choices(ui, q), choices_translated, DIM(choices_translated));
+ dcount = strchoicesplit(question_get_field(ui, q, C, value), defaults, DIM(defaults));
/* See what the currently selected value should be -- either a
* previously selected value, or the default for the question
Index: src/modules/frontend/slang/slang.c
===
--- src/modules/frontend/slang/slang.c (Revision 53045)
+++ src/modules/frontend/slang/slang.c (Arbeitskopie)
@@ -202,8 +202,8 @@
static void slang_drawdesc(struct frontend *ui, struct question *q)
{
struct uidata *uid = UIDATA(ui);
- char *descr = q_get_description(q);
- char *ext_descr = q_get_extended_description(q);
+ char *descr = q_get_description(ui, q);
+ char *ext_descr = q_get_extended_description(ui, q);
/* Clear the windows */
slang_drawwin(uid-qrywin);
@@ -290,14 +290,14 @@
static char *get_text(struct frontend *obj, const char *template, char *fallback)
{
struct question *q = obj-qdb-methods.get(obj-qdb, template);
-return q ? q_get_description(q) : fallback;
+return q ? q_get_description(obj, q) : fallback;
}
static char *button_text(struct frontend *obj, const char *template, char *fallback)
{
char text[50];
struct question *q = obj-qdb-methods.get(obj-qdb, template);
- sprintf(text, %s , q ? q_get_description(q) : fallback);
+ sprintf(text, %s , q ? q_get_description(obj, q) : fallback);
return strdup(text);
}
@@ -368,7 +368,7 @@
if (!yes_text) yes_text = get_text(ui, debconf/button-yes, Yes);
if (!no_text) no_text = get_text(ui, debconf/button-no, No);
- value = question_get_field(q, C, value);
+ value = question_get_field(ui, q, C, value);
ans = (strcmp(value, true) == 0);
pos = (ans ? 2 : 3);
@@ -428,24 +428,24 @@
char *selected;
char answer[1024] = {0};
int *tindex = NULL;
- const char *indices = q_get_indices(q);
+ const char *indices = q_get_indices(ui, q);
int i, j, count, dcount, ret = 0, val = 0, pos = 2, xpos, ypos;
int top, bottom, longest, ch;
struct uidata *uid = UIDATA(ui);
struct slwindow *win = uid-qrywin;
/* Parse out all the choices */
- count = strgetargc(q_get_choices_vals(q));
+ count = strgetargc(q_get_choices_vals(ui, q));
if (count = 0)
return DC_NOTOK;
choices = malloc(sizeof(char *) * count);
choices_translated = malloc(sizeof(char *) * count);
tindex = malloc(sizeof(int) * count);
- if (strchoicesplitsort(q_get_choices_vals(q), q_get_choices(q), indices, choices, choices_translated, tindex, count) != count)
+ if (strchoicesplitsort(q_get_choices_vals(ui, q), q_get_choices(ui, q), indices, choices, choices_translated, tindex, count) != count)
return DC_NOTOK;
defaults = malloc(sizeof(char *) * count);
- dcount = strchoicesplit(question_get_field(q, C, value), defaults, count);
+ dcount = strchoicesplit(question_get_field(ui, q, C, value), defaults, count);
INFO(INFO_VERBOSE, Parsed out %d choices, %d defaults, count, dcount);
if (dcount
Bug#478591: cdebconf-entropy: Dialog texts and buttons
On Sat, May 03, 2008 at 10:12:05PM +0200, Max Vozeler wrote: I think that having a Go back button to break off the process of gathering entropy would make more sense. This could still be useful. Agreed here too. I'll change the newt frontend to allow aborting. Strange - we already do, but the cancel button is not shown. We show it only if the frontend indicates that it can go back (newt_can_go_back()). I'm currently lost as to why the frontend would not have the BACKUP capability. It does when I build cdebconf locally. Any ideas? Else I will try to dig deeper.. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[PATCH] cdebconf: Fix *_can_align() signatures to match the prototype
Hi all,
gcc correctly warns about a pointer mismatch assigning to
methods.can_align for newt and the generic default:
struct frontend_module {
..
bool (*can_align)(struct frontend *, struct question *);
vs.
static bool newt_can_align(struct frontend *obj)
static bool frontend_can_align(struct frontend *ui)
The attached patch fixes those two to take the additional
struct question * parameter.
Max
diff -r fce562ac73a5 debian/changelog
--- a/debian/changelog Sun May 04 15:32:01 2008 +0200
+++ b/debian/changelog Sun May 04 15:33:29 2008 +0200
@@ -7,6 +7,7 @@
[ Max Vozeler ]
* src/modules/frontend/{ncurses,slang,bogl}: Adapt to API changes made in
cdebconf 0.129 - q_get_*() and question_get_value().
+ * Fix *_can_align() function signatures to match the prototype.
-- Frans Pop [EMAIL PROTECTED] Sun, 20 Apr 2008 18:21:40 +0200
diff -r fce562ac73a5 src/frontend.c
--- a/src/frontend.c Sun May 04 15:32:01 2008 +0200
+++ b/src/frontend.c Sun May 04 15:33:29 2008 +0200
@@ -108,7 +108,7 @@
return false;
}
-static bool frontend_can_align(struct frontend *ui)
+static bool frontend_can_align(struct frontend *ui, struct question *q)
{
return false;
}
diff -r fce562ac73a5 src/modules/frontend/newt/newt.c
--- a/src/modules/frontend/newt/newt.c Sun May 04 15:32:01 2008 +0200
+++ b/src/modules/frontend/newt/newt.c Sun May 04 15:33:29 2008 +0200
@@ -1148,7 +1148,7 @@
}
static bool
-newt_can_align(struct frontend *obj)
+newt_can_align(struct frontend *obj, struct question *q)
{
return (obj-capability DCF_CAPB_ALIGN);
}
Bug#478591: cdebconf-entropy: Dialog texts and buttons
tags 478591 + patch
thanks
On Sat, May 03, 2008 at 10:45:22PM +0200, Frans Pop wrote:
On Saturday 03 May 2008, Max Vozeler wrote:
How do we go about changing the string? Should we ask for review
from -l10n-english first?
IMO not needed. It would be good to post the patch to the BR first for
review though.
Patch attached - Review is much appreciated :-)
Note that Otavio has just started preparations for Beta2 and I think we
should delay this string change until just after that.
Okay. Let's delay it.
Max
Index: partman-crypto/debian/partman-crypto.templates
===
--- partman-crypto/debian/partman-crypto.templates (revision 53030)
+++ partman-crypto/debian/partman-crypto.templates (working copy)
@@ -361,7 +361,7 @@
Template: partman-crypto/entropy-success
Type: text
# :sl3:
-_Description: Key data has been created successfully.
+_Description: The encryption key for ${DEVICE} has been created successfully.
Template: partman-crypto/keyfile-problem
Type: error
Bug#478591: cdebconf-entropy: Dialog texts and buttons
On Sun, May 04, 2008 at 03:19:19PM +0200, Max Vozeler wrote: On Sat, May 03, 2008 at 10:12:05PM +0200, Max Vozeler wrote: I think that having a Go back button to break off the process of gathering entropy would make more sense. This could still be useful. Agreed here too. I'll change the newt frontend to allow aborting. Strange - we already do, but the cancel button is not shown. We show it only if the frontend indicates that it can go back (newt_can_go_back()). I'm currently lost as to why the frontend would not have the BACKUP capability. It does when I build cdebconf locally. Any ideas? Else I will try to dig deeper.. That was just missing a call to db_capb backup :-) Fixed in SVN. The entropy dialog can now be cancelled. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478598: partman-crypto: problems with using random keys
Hey there Frans, On Wed, Apr 30, 2008 at 01:04:35AM +0200, Frans Pop wrote: make the swap partition use loop-aes with random key. Correct method: - select the swap partition - choose Use as: physical volume for encryption - choose Encryption method: Loopback - choose Encryption key: Random key - choose Erase data: no - Done setting up partition - Proceed with Configure encrypted volumes, OK to write changes to disk. After this the process completes immediately, apparently successfully. I do *not* get the dialog asking to enter random keys. This seems like it could be a bug, especially given that I am asked to do so with the next example. Not a bug - When you select Random key for loop-AES, the actual keys are generated from /dev/urandom by mount or swapon. We don't use cdebconf-entropy for such setups. Incorrect method: - select the swap partition - choose Use as: physical volume for encryption - choose Encryption key: Random key - choose Encryption method: Loopback Note that I now select the key type before the method. - choose Erase data: no - Done setting up partition - Proceed with Configure encrypted volumes, OK to write changes to disk. After this I am first asked to enter an encryption passphrase, even though there is no partition that uses one. This is a bug. Indeed, this is arguably non-intuitive. Your earlier choice of random keytype was reset to the default for loop-AES, gnupg keyfile, when you changed the encryption method. FWIW, the partman dialog should reflect the reset keytype after switching the encryption type. I think we should be able to retain all settings except cipher and keysize - I'll check and adapt the code. After that I *am* asked to enter random characters, with the progress bar at only 2%. Getting sufficient entropy litterally takes ages: getting from 5 to 10% takes 20 seconds. I don't remember it taking that long with previous tests I've done. Were the earlier tests done in the same environment? Lots of factors contribute to how well (or how badly) the entropy pool is being fed by device drivers. IIRC some disk drivers do, some don't, some network drivers do, others don't etc. Apart from that I don't recall any changes that should have made key generation more painful than it already was. :-/ FWIW, I'm doing most of my testing with d-i preseed/early_command string mount --bind /dev/urandom /dev/random Question Is Random key a valid choice when using dm-crypt? It is. The interface does allow it, but I seem to remember that supporting random keys was the reason why we still needed support for loop-aes. No. loop-AES is not a legacy for lack of features in dm-crypt. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478591: cdebconf-entropy: Dialog texts and buttons
On Wed, Apr 30, 2008 at 01:43:20AM +0200, Frans Pop wrote: On Wednesday 30 April 2008, Frans Pop wrote: Is the Continue button defined at all? What happens if it is clicked? Does it even make sense to have a Continue button? It would effectively leave the installer with insufficient entropy to actually continue. Looks like the Continue button becomes active automatically after enough entropy has been gathered (same dialog remains displayed, but its text changes and the button becomes active). Maybe it should just be hidden while entropy is still being gathered. Agreed. I think that having a Go back button to break off the process of gathering entropy would make more sense. This could still be useful. Agreed here too. I'll change the newt frontend to allow aborting. Jérémy, does the gtk frontent already offer to abort or would it also have to be adapted? Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478591: cdebconf-entropy: Dialog texts and buttons
On Wed, Apr 30, 2008 at 01:40:21AM +0200, Frans Pop wrote: On Wednesday 30 April 2008, Frans Pop wrote: I would suggest to replace it with a different dialog (that is possibly displayed at a later point in the code) that simply says: The random key has been created successfully. Maybe even: The encryption key for disk, partition has been created successfully. That would match the intro text in the dialog to enter random characters. Good suggestion - thanks! Saying that the encryption key has been created is a lot more meaningful than talking about key data. (Talking about Random key here might be confusing, as we already use the term in the Key type option with a different meaning. Here we mean: The persistent encryption key has been created from a random source. For the key type, we mean The key is non-persistent and will be recreated from a random source (and data will effectively destroyed) each time it is used.) How do we go about changing the string? Should we ask for review from -l10n-english first? Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#478598: partman-crypto: problems with using random keys
Hey Frans, On Sat, May 03, 2008 at 10:56:31PM +0200, Frans Pop wrote: On Saturday 03 May 2008, Max Vozeler wrote: When you select Random key for loop-AES, the actual keys are generated from /dev/urandom by mount or swapon. We don't use cdebconf-entropy for such setups. Does that mean that I should not have been shown *either* of the two dialogs (passphrase and random typing) with the incorrect method? No. By switching encryption methods, you got the default of the selected method (loop-AES), which is keyfile. It involves asking for a passphrase and getting random input. Should cdebconf-entropy be used only with dm-crypt? No. Here is a table to clear up any misunderstandings: Method | Type | Key generation -- dm-crypt | passphrase| persistent key from /dev/urandom, wrapped || with passphrase dm-crypt | random| volatile key from /dev/random loop-AES | keyfile | persistent key from /dev/random, wrapped with GnuPG loop-AES | random| volatile key from /dev/urandom In all cases that involve /dev/random rather than /dev/urandom, we use cdebconf-entropy to help key generation, because random blocks when the kernel is running out of entropy. These cases use cdebconf-entropy: dm-crypt random loop-AES keyfile These cases ask for a passphrase: dm-crypt passphrase loop-AES keyfile The other cases show neither dialogs, because they generate volatile keys from /dev/urandom with no passphrase: loop-AES random BTW: We can and should switch the dm-crypt random case to just use /dev/urandom, since it is sufficient for a volatile one-time encryption key. If that is the case then the current logic is _really_ broken... ... FWIW, the partman dialog should reflect the reset keytype after switching the encryption type. IIRC it did not. My test should be trivial to reproduce though. It does - I just verified it. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475399: partman-crypto: fails to configure multiple encrypted devices
Hi Jérémy, On Mon, Apr 14, 2008 at 10:16:35AM +0200, Jérémy Bobbio wrote: On Mon, Apr 14, 2008 at 12:11:48AM +0200, Max Vozeler wrote: On Thu, Apr 10, 2008 at 03:58:55PM +0200, Frans Pop wrote: The first volumes were loop-aes with random key. The last one was with gnupg key file. While configuring the last, partman and the debconf frontend crashed. That crash is caused by an API and ABI change in cdebconf 0.129: -char *question_get_field(const struct question *q, const char *lang, +char *question_get_raw_field(const struct question *q, const char *lang, const char *field); +char *question_get_field(struct frontend *obj, const struct question *q, +const char *lang, const char *field); Currently cdebconf-entropy (or any other plugin) crashes cdebconf when it tries to use this function. Damn. I should really have thought about this, and I apologies. :( No bad feelings - such things happen! Especially since we have no clear boundary between an cdebconf-internal API and something like a plugin module API. We'll need to adapt plugins and rebuild them. Unfortunately I have a very busy work week ahead of me and won't be able to do anything about it before next weekend. Jérémy, could you maybe have a look? This situation is further complicated by missing strutl.h in libdebconfclient0-dev 0.129, which currently prevents plugins from building against that version. I'd like to fix this today, and upload the recent changes in cdebconf-entropy at the same time, if you feel fine with it. That's fine with me - thanks. Max
Bug#475399: partman-crypto: fails to configure multiple encrypted devices
On Thu, Apr 10, 2008 at 03:58:55PM +0200, Frans Pop wrote: The first volumes were loop-aes with random key. The last one was with gnupg key file. While configuring the last, partman and the debconf frontend crashed. That crash is caused by an API and ABI change in cdebconf 0.129: -char *question_get_field(const struct question *q, const char *lang, +char *question_get_raw_field(const struct question *q, const char *lang, const char *field); +char *question_get_field(struct frontend *obj, const struct question *q, +const char *lang, const char *field); Currently cdebconf-entropy (or any other plugin) crashes cdebconf when it tries to use this function. We'll need to adapt plugins and rebuild them. Unfortunately I have a very busy work week ahead of me and won't be able to do anything about it before next weekend. Jérémy, could you maybe have a look? This situation is further complicated by missing strutl.h in libdebconfclient0-dev 0.129, which currently prevents plugins from building against that version. Max
Re: [RFC] entropy plugin rework + support for the graphical installer
Hey Jérémy,
On Sun, Mar 23, 2008 at 10:27:50PM +0100, Jérémy Bobbio wrote:
On Thu, Mar 13, 2008 at 11:42:24PM +0100, Max Vozeler wrote:
The implementation looks fine from a quick glance. Please
feel free to add integrate it into cdebconf-entropy when
you are happy with it.
Attached is a patchset which makes various changes to the current
cdebconf-entropy package in order to support other frontends than newt,
adds support for the GTK+ frontend, and update partman-crypto
accordingly.
These are good improvements, thanks!
I have reviewed your patches and couldn't spot any problems from
the code and packaging side.
The following points probably need someone with more knowledge
of translations and better feeling than I can offer for both
english and template wording to comment on:
* AFAIK, the string displayed after gathering enough entropy was not
translated before, as partman-crypto/entropy-text-success was not
defined anywhere. So please comment on the newly introduced
partman-crypto/entropy-success.
Key data has been created successfully.
This seems okay to me. FWIW. I'm not a native speaker, and I'm
probably blindfolded as I wrote this string initially ;-)
* debconf/entropy/success is the fallback template when SUCCESS has not
been substituted to a more relevant template. As it should not
normally appear in d-i, I have put it under sublevel 5. Please
comment on the wording nevertheless. :)
_Description: Enough entropy has been gathered.
This too seems okay to me.
* No string changes actually happened, but as the previous
partman-crypto/entropy-text content has been splitted between
debconf/entropy/text/{action,help} and partman-crypto/entropy,
I would be glad to know the best way to update po files directly
instead of putting more burden on translators shoulders.
bubulle, could you offer advice?
* debconf/entropy/gtk/* are slights variations of
debconf/entropy/text/* mentioning the mouse and might benefit from
better wording as well.
Here IMHO bubulle's suggested wording sounds very good.
I have tested these changes by putting the affected udebs directly in
netboot images, so I am unsure if the changes in dependencies and
dynamic retrieval of crypto packages are correct. I would be glad if
someone could test that. :)
AFAICS, the switch to a virtual package cdebconf-entropy is
the only change that carries some risk..
Because we cannot do versioned depends on virtual packages, we
need to manually keep those two packages in sync when uploading
and for testing migration.
Overall, I think we should go ahead with these changes - they
seem safe enough for me even during this beta stage.
As I said on IRC, thanks for your work :-)
Max
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470951: grub-installer: serial console broken for words!=8 and flow control
Package: grub-installer
Tags: patch
I was surprised by grub not showing up on the serial
console after an installation over serial with kernel
option console=ttyS0,11520n8r
The grub menu.lst contained
serial --unit=1 --speed=115200 --word=r --parity=no --stop=1
But 'r' is an invalid value for word (it takes 5-8).
It turns out the parsing in grub_serial_console() doesn't
handle options strings correctly that specify a word size != 8
or a flow control parameter (or both).
grub_serial_console() interprets the third character after
the baud rate as value for 'word'. serial-console.txt in
linux-2.6/Documentation, OTOH, says:
options: depend on the driver. For the serial port this
defines the baudrate/parity/bits/flow control of
the port, in the format PNF, where is the
speed, P is parity (n/o/e), N is number of bits,
and F is flow control ('r' for RTS). Default is
9600n8. The maximum baudrate is 115200.
So it should actually take the second character as value
for word and ignore any third character, because grub doesn't
seem to offer any option for setting flow control.
The attached patch makes it work for me and fixes both word
and flow control handling. I've checked the results against
Alex' test script [1], and the results look good to me.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=416310#25
Max
Index: grub-installer/debian/changelog
===
--- grub-installer/debian/changelog (Revision 51918)
+++ grub-installer/debian/changelog (Arbeitskopie)
@@ -9,6 +9,10 @@
[ Guido Guenther ]
* Add multipath support modelled after dmraid. Closes: #468832.
+ [ Max Vozeler ]
+ * Fix serial console setup for console= options that include either a
+word size != 8 or a flow control parameter.
+
-- Guido Guenther [EMAIL PROTECTED] Mon, 10 Mar 2008 13:29:51 +0100
grub-installer (1.29) unstable; urgency=low
Index: grub-installer/grub-installer
===
--- grub-installer/grub-installer (Revision 51918)
+++ grub-installer/grub-installer (Arbeitskopie)
@@ -53,10 +53,10 @@
options=${serconsole##*,}
fi
local speed=$(echo $options | sed -e 's/^\([0-9]*\).*$/\1/')
- # Take optional 1st (parity) and 3rd (word) characters after speed
+ # Take optional 1st (parity) and 2nd (word) characters after speed
options=${options##${speed}}
local parity=$(echo $options | sed 's/^\(.\?\).*$/\1/')
- local word=$(echo $options | sed 's/^.\?.\?\(.\?\).*$/\1/')
+ local word=$(echo $options | sed 's/^.\?\(.\?\).*$/\1/')
if [ -z $speed ]; then
speed=9600
fi
grub_serial_console console=ttyS0
serial --unit=0 --speed=9600 --stop=1
grub_serial_console console=ttyS1
serial --unit=1 --speed=9600 --stop=1
grub_serial_console console=ttyS0,9600
serial --unit=0 --speed=9600 --stop=1
grub_serial_console console=ttyS0,115200
serial --unit=0 --speed=115200 --stop=1
grub_serial_console console=ttyS1,9600
serial --unit=1 --speed=9600 --stop=1
grub_serial_console console=ttyS1,115200
serial --unit=1 --speed=115200 --stop=1
grub_serial_console console=ttyS1,9600n
serial --unit=1 --speed=9600 --parity=no --stop=1
grub_serial_console console=ttyS1,115200n
serial --unit=1 --speed=115200 --parity=no --stop=1
grub_serial_console console=ttyS1,9600e
serial --unit=1 --speed=9600 --parity=even --stop=1
grub_serial_console console=ttyS1,115200e
serial --unit=1 --speed=115200 --parity=even --stop=1
grub_serial_console console=ttyS1,9600o
serial --unit=1 --speed=9600 --parity=odd --stop=1
grub_serial_console console=ttyS1,115200o
serial --unit=1 --speed=115200 --parity=odd --stop=1
grub_serial_console console=ttyS1,9600n8
serial --unit=1 --speed=9600 --parity=no --stop=1
grub_serial_console console=ttyS1,115200n8
serial --unit=1 --speed=115200 --parity=no --stop=1
grub_serial_console console=ttyS1,9600n7
serial --unit=1 --speed=9600 --parity=no --stop=1
grub_serial_console console=ttyS1,115200n7
serial --unit=1 --speed=115200 --parity=no --stop=1
grub_serial_console console=ttyS1,9600n8r
serial --unit=1 --speed=9600 --word=r --parity=no --stop=1
grub_serial_console console=ttyS1,115200n8r
serial --unit=1 --speed=115200 --word=r --parity=no --stop=1
grub_serial_console console=ttyS1,9600n7r
serial --unit=1 --speed=9600 --word=r --parity=no --stop=1
grub_serial_console console=ttyS1,115200n7r
serial --unit=1 --speed=115200 --word=r --parity=no --stop=1
grub_serial_console console=ttyS1,9600o8
serial --unit=1 --speed=9600 --parity=odd --stop=1
grub_serial_console console=ttyS1,115200o8
serial --unit=1 --speed=115200 --parity=odd --stop=1
grub_serial_console console=ttyS1,9600o7
serial --unit=1 --speed=9600 --parity=odd --stop=1
grub_serial_console console=ttyS1,115200o7
serial --unit=1 --speed=115200 --parity=odd --stop=1
grub_serial_console console=ttyS1,9600o8r
serial --unit=1 --speed=9600
Re: r51921 - in trunk/packages/partman/partman-crypto: debian finish-install.d
Hi Frans, On Fri, Mar 14, 2008 at 08:34:58PM +0100, Frans Pop wrote: Log: Regenerate the initramfs for root on loop-AES. [...] +++ trunk/packages/partman/partman-crypto/finish-install.d/05crypto [...] Couldn't this be done in post-base-installer.d instead so there is no need to regenerate the initramfs? Unfortunately, I don't think it can. At the point post-base-installer.d runs the kernel has not yet been selected. It's a bit of a catch-22 situation. Before the kernel is installed, we can't install the modules (we don't know the flavour, and the module package depend on the kernel image package). After the kernel has been installed, its postinst has already generated initramfs once. I've thought about this for some time, but I don't see a solution short of using something like triggers for all update-initramfs invokations. Another thing I considered was to have some kind of queue mechanism which we could tell: Please install foo-modules-%KERNEL% at the same time as the kernel itself. But AFAICS that wouldn't help either - there is no guarantee that the module package will have been unpacked before the kernel postinst runs. That's about as far as I got before I sort of gave up and added the brute-force approach above. Any ideas for a better approach? I'm happy to invest some time getting it to work, but right know I can't think of anything else that would work. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdebconf-entropy plugin: usage, templates and strings
Hey Jérémy,
On Thu, Mar 06, 2008 at 01:44:45PM +0100, Jérémy Bobbio wrote:
The first plugin to be written, obviously, is the graphical sibling to
the plugin gathering entropy, used in partman-crypto. The code for this
plugin was actually written while working on the rest of the GTK+
frontend [1] but as yet to be integrated properly.
[1] http://people.debian.org/~lunar/fe_gtk-plugin-entropy.c
Thanks for your work on this!
The implementation looks fine from a quick glance. Please
feel free to add integrate it into cdebconf-entropy when
you are happy with it.
I think it would make more sense to make a single question type, for
both frontend, named entropy, and to have a single question template
in partman-crypto and a single code path handling both frontends.
Agreed.
I thought about using the newly introduced debconf directives, but I
might just wanna play with a new toy here. So I really want to know
other advices before hacking… Here is the proposed implementation,
though:
Using directives would make the previous template look like:
_Description: ${!ENTROPY_SHORT_TITLE}
The encryption key for ${DEVICE} is now being created.
.
${!ENTROPY_GENERATE_MORE}
A new text template would be introduced in each plugin built by
cdebconf-entropy. Its short description would be used for
ENTROPY_SHORT_TITLE and ENTROPY_GENERATE_MORE would be its extended
description.
The approach sounds fine.
I'm not familiar with the new debconf directive mechanism.
Is there any documentation I could look at? Any pointers
would be appreciated. :-)
If directives weren't available, I would probably have
gone for a similar but slightly diffent solution - we could
have partman-crypto provide a description fragment
_Description: The encryption key for ${DEVICE} is now being created.
The different 'entropy' type frontend plugins would take
the fragment and integrate it with the appropriate frontend-
specific text to form a complete dialog.
IOW, if directives are a good fit for this use, I see no
reason to not go ahead with the proposal you outlined.
Max
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#456154: debian-installer: amd64 re-boot fails due to missing /etc/crypttab
On Thu, Dec 13, 2007 at 10:54:44AM +0100, Torsten Neumann wrote: The setup I tried is a md setup with everything crypted except /boot .. Examining the install I found out that there was only an empty /etc/crypttab, adding the entry for /dev/md1 manually I could mount all the devices and then the system boots normally. This sounds a lot like the crypto-raid interop problem documented here: http://wiki.debian.org/DebianInstaller/RAIDvsCrypto The wiki page lists some known workarounds. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partman reorganization - day 2
Hi Frans, On Thu, Dec 06, 2007 at 05:55:52PM +0100, Frans Pop wrote: [1] Commit log entry: Dynamically load support for LVM and crypto Only load components for LVM and crypto support when there is sufficient free memory. For crypto this only loads base support components; additional crypto components will only be loaded on demand. ... No problems spotted from pure code review. I'm doing tests now with these and yesterdays changes. MAx -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partman reorganization - day 1
Hi Frans, On Wed, Dec 05, 2007 at 09:59:29PM +0100, Frans Pop wrote: I also committed this change in partman/Makefile because dpkg-shlibdeps gave a warning that libld.so.2 was unused: -LIBS=-lparted -ldl +LIBS=-lparted If someone knows this to be incorrect, please shout. Seems fine; Currently no code in partman uses anything related to libdl. Overview of the reorganization == Most commits are just moving files containing library functions around, including updates for all scripts that source them: partman-base: ./definitions.sh- ./lib/base.sh Checking dependencies, The following packages use base.sh but can't depend on partman-base because they are themselves explicitly or implicitly depended on by -base partman-basicfilesystems partman-basicmethods partman-ext2r0 partman-ext3 partman-jfs partman-partitioning partman-reiserfs partman-target partman-xfs The versioned dependency of -auto-crypto on -crypto was off by one (= 24 should be = 25; fixed). partman-lvm: ./lvm_tools.sh - ./lib/lvm-base.sh partman-crypto: ./crypto_tools.sh - ./lib/crypto-base.sh Unless there are plans to further split up lvm and crypto I would name those just lvm.sh and crypto.sh. Then there are two commits that add a 'memfree' function in base.sh and updates partman-crypto to use that. I intend to also use that function tomorrow to dynamically load LVM and crypto support only if there is sufficient memory. Looks good. The last commit is by far the most invasive. It is based on a change proposed by Jérémy in #396023, but takes his suggestion a bit further. The commit moves everything that has to do with disk labels (including four templates) from partman-base to partman-partitioning. No problems spotted. Among others it moves the default_disk_label function from base.sh in p-base to a new function library file new-label.sh [1] in p-partitioning. Main reason is that this function is only called from a few specific places and thus having it in base.sh is just not efficient, especially given that it is ~150 lines of code. The new function create_new_label is now only used from p-partitioning itself, but intention is to also use it from partman-auto when using guided partitioning of a whole disk. I'll work on that tomorrow as well. Looks good overall. Thanks for working on this. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Erase LVM/crypto issues and proposed partman reorg
Hi Frans, On Tue, Dec 04, 2007 at 04:39:38PM +0100, Frans Pop wrote: 1) Rename current wipe functions For partman-crypto I have a patch that renames the existing functions to include the crypto namespace: - wipe - crypto_do_wipe - dev_wipe - crypto_wipe_device Good change, agreed. In fact I have a patch sitting here that does the exact same change, among others. OK. Attached my version of the patch that also includes some other minor cleanups. Let me know if I should commit this or that you want to commit your own version. However, I will commit my version before I start on the reorganization (see below). Your version seems fine, please commit. Mine is dependent on a few other cleanups that should wait until after the reorganization. I'm willing to put in some work to help deal with the implementation and fallout of this and the other proposed changes, (and eventually contribute to the reimplementation of the removal of crypto devices). I'm happy to set aside some time this weekend and review or test changes. That's great. I don't expect much fallout, but some extra testing is always welcome. And help with the re-implementation is especially welcome. I will start work on this tomorrow. If anybody has any pending changes for partman (that are solid enough), please commit them before then. OK. I will monitor the list and commits for anything to do. I'll have limited time until friday, but feel free to send anything to me directly as well, if you like. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Refactoring commit_changes in partman
On Tue, Dec 04, 2007 at 04:40:03PM +0100, Frans Pop wrote: On Tuesday 04 December 2007, Frans Pop wrote: On Tuesday 04 December 2007, Max Vozeler wrote: Yes, I've tested -auto-crypto, -auto-lvm, -md, -lvm, -crypto and -partitioning by doing some random setups and injected the two error cases with failing commit.d/init.d scripts. Perfect. And please commit today so it's in before I start the restructuring. OK, I've commited the changes. I think it would be useful to do a quick round of uploads before starting the reorganization, so that we have a known baseline to compare to and can tell any problems resulting from this change. What do you think? If you agree, could you do them before starting reorga, or should I do them tonight? (I probably won't have time for it tomorrow). Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Refactoring commit_changes in partman
Hi Frans, On Mon, Dec 03, 2007 at 10:37:32AM +0100, Frans Pop wrote: On Monday 03 December 2007, Max Vozeler wrote: I've carefully gone through them and noted the differences, hoping to replace them all with a common commit_changes in partman-base/definition.sh I agree that factoring this out makes sense. I've looked over your patch and the thorough analysis and can't see any holes in it. Have you done any testing with the new code? Would be great if you could do that before committing. Yes, I've tested -auto-crypto, -auto-lvm, -md, -lvm, -crypto and -partitioning by doing some random setups and injected the two error cases with failing commit.d/init.d scripts. I didn't test -dmraid because I couldn't figure out how, :-) Does dmraid require special hardware? The only problem I see is that it is not possible to add a versioned depends on -base (= 113) in -partitioning, because -base depends on -partitioning and this would introduce a circular dependency. I don't think a circular dependency would do any harm in this case. Suggest you just add it. Tried this and ended up with a Deep recursion configuring partman-base (dep loop?) (IIRC) from main-menu. It seems that main-menu tries to configure partman-base and all its dependencies, and this fails. Some nitpicks. The changelog entry for partman-base could be a bit more elaborate IMO and should include an explanation why the function was added. Agreed, I'll try to write something more of an explanation. Thanks for your review. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Erase LVM/crypto issues and proposed partman reorg
On Mon, Dec 03, 2007 at 11:26:22AM +0100, Frans Pop wrote: I therefore suggest reverting David's changes (which luckily is quite straightforward) and then first do some refactoring of existing code as preparation for a reimplementation of support for erasing encrypted volumes. I tend to agree. The existing code is indeed a bit messy and difficult to follow. Starting to untangle the scripts and cleaning up the code now seems a good idea. David's changes include good code that can be reintroduced later on to a large extent when we can start from a more maintainable code base. 1) Rename current wipe functions For partman-crypto I have a patch that renames the existing functions to include the crypto namespace: - wipe - crypto_do_wipe - dev_wipe - crypto_wipe_device Good change, agreed. In fact I have a patch sitting here that does the exact same change, among others. 2) Reorder function libraries I suggest we move all function libraries into /lib/partman/lib/ [1]. definitions.sh could be renamed to just base.sh. The various *_tools.sh files could be renamed to lvm-base.sh, lvm-*.sh, auto-base, etc. This would also lower the barrier to introduce additional new function libraries when that is warranted. Yep, this seems worthwile. I'm willing to put in some work to help deal with the implementation and fallout of this and the other proposed changes, (and eventually contribute to the reimplementation of the removal of crypto devices). I'm happy to set aside some time this weekend and review or test changes. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Refactoring commit_changes in partman
Hey all,
most of the partman-* packages provide their own slightly
different version of commit_changes.
I've carefully gone through them and noted the differences,
hoping to replace them all with a common commit_changes in
partman-base/definition.sh
o I plan to apply the attached path if noone voices
objections. I've carefully read the code to make sure
that the changes are safe and given the changed
packages basic testing.
o Shrinks the scripts in partman-* by a bit more than
1k (1257 bytes) in total size.
o Some error templates were previously shown with high
priority, while others used critical for essentially
the same error condition. This change makes them
consistently use priority critical.
The only problem I see is that it is not possible to
add a versioned depends on -base (= 113) in -partitioning,
because -base depends on -partitioning and this would
introduce a circular dependency.
I'm attaching my more detailed notes in case anyone wants
to review or double-check.
Max
Index: partman-crypto/debian/control
===
--- partman-crypto/debian/control (Revision 50294)
+++ partman-crypto/debian/control (Arbeitskopie)
@@ -9,7 +9,7 @@
Package: partman-crypto
XC-Package-Type: udeb
Architecture: any
-Depends: partman-base (= 106), ${shlibs:Depends}, ${misc:Depends}
+Depends: partman-base (= 113), ${shlibs:Depends}, ${misc:Depends}
Description: Add to partman support for block device encryption
Package: partman-crypto-dm
Index: partman-crypto/debian/changelog
===
--- partman-crypto/debian/changelog (Revision 50294)
+++ partman-crypto/debian/changelog (Arbeitskopie)
@@ -1,3 +1,9 @@
+partman-crypto (24) UNRELEASED; urgency=low
+
+ * Use commit_changes from partman-base (= 113)
+
+ -- Max Vozeler [EMAIL PROTECTED] Sun, 02 Dec 2007 13:31:49 +0100
+
partman-crypto (23) unstable; urgency=low
[ Colin Watson ]
Index: partman-crypto/crypto_tools.sh
===
--- partman-crypto/crypto_tools.sh (Revision 50294)
+++ partman-crypto/crypto_tools.sh (Arbeitskopie)
@@ -721,21 +721,7 @@
interactive=yes
fi
- # Commit the changes
- for s in /lib/partman/commit.d/*; do
- if [ -x $s ]; then
- $s || {
- db_input high partman-crypto/commit_failed || true
- db_go || true
- for s in /lib/partman/init.d/*; do
- if [ -x $s ]; then
- $s || return 255
- fi
- done
- return 0
- }
- fi
- done
+ commit_changes partman-crypto/commit_failed || return $?
if ! swap_is_safe; then
db_fset partman-crypto/unsafe_swap seen false
Index: partman-auto-raid/debian/control
===
--- partman-auto-raid/debian/control (Revision 50293)
+++ partman-auto-raid/debian/control (Arbeitskopie)
@@ -9,5 +9,5 @@
Package: partman-auto-raid
XC-Package-Type: udeb
Architecture: all
-Depends: ${misc:Depends}, partman-base (= 99), partman-basicfilesystems, partman-ext3, partman-auto (= 58), partman-md
+Depends: ${misc:Depends}, partman-base (= 113), partman-basicfilesystems, partman-ext3, partman-auto (= 58), partman-md
Description: Allow preseeded RAID installs
Index: partman-auto-raid/debian/changelog
===
--- partman-auto-raid/debian/changelog (Revision 50293)
+++ partman-auto-raid/debian/changelog (Arbeitskopie)
@@ -1,3 +1,9 @@
+partman-auto-raid (7) UNRELEASED; urgency=low
+
+ * Use commit_changes from partman-base (= 113)
+
+ -- Max Vozeler [EMAIL PROTECTED] Sun, 02 Dec 2007 13:34:18 +0100
+
partman-auto-raid (6) unstable; urgency=low
[ Frans Pop ]
Index: partman-auto-raid/display.d/initial_auto_raid
===
--- partman-auto-raid/display.d/initial_auto_raid (Revision 50293)
+++ partman-auto-raid/display.d/initial_auto_raid (Arbeitskopie)
@@ -35,21 +35,7 @@
confirm_changes partman-md || exit 1
-# Commit the changes
-for s in /lib/partman/commit.d/*; do
-if [ -x $s ]; then
- $s || {
- db_input critical partman/text/commit_failed || true
- db_go || true
- for s in /lib/partman/init.d/*; do
- if [ -x $s ]; then
- $s || exit 255
- fi
- done
- exit 1
- }
-fi
-done
+commit_changes partman/text/commit_failed || exit $?
stop_parted_server
Index: partman-lvm/debian/control
===
--- partman-lvm/debian/control (Revision 50293)
+++ partman-lvm/debian/control (Arbeitskopie)
@@ -9,6 +9,6 @@
Package: partman-lvm
XC-Package-Type: udeb
Architecture: all
-Depends: ${misc:Depends}, partman-base (= 87), di-utils (= 1.14), md-modules, lvm2-udeb
+Depends: ${misc:Depends}, partman-base (= 113), di-utils (= 1.14), md-modules, lvm2-udeb
Description: Adds support for LVM to partman
Index
Re: Refactoring commit_changes in partman
Hey all,
On Mon, Dec 03, 2007 at 12:10:45AM +0100, Max Vozeler wrote:
o I plan to apply the attached path if noone voices
objections. ..
Sorry, I attached an earlier revision of the patch.
Please see this one instead.
Max
Index: partman-crypto/debian/control
===
--- partman-crypto/debian/control (revision 50294)
+++ partman-crypto/debian/control (working copy)
@@ -9,7 +9,7 @@
Package: partman-crypto
XC-Package-Type: udeb
Architecture: any
-Depends: partman-base (= 106), ${shlibs:Depends}, ${misc:Depends}
+Depends: partman-base (= 113), ${shlibs:Depends}, ${misc:Depends}
Description: Add to partman support for block device encryption
Package: partman-crypto-dm
Index: partman-crypto/debian/changelog
===
--- partman-crypto/debian/changelog (revision 50294)
+++ partman-crypto/debian/changelog (working copy)
@@ -1,3 +1,9 @@
+partman-crypto (24) UNRELEASED; urgency=low
+
+ * Use commit_changes from partman-base (= 113)
+
+ -- Max Vozeler [EMAIL PROTECTED] Sun, 02 Dec 2007 13:31:49 +0100
+
partman-crypto (23) unstable; urgency=low
[ Colin Watson ]
Index: partman-crypto/crypto_tools.sh
===
--- partman-crypto/crypto_tools.sh (revision 50294)
+++ partman-crypto/crypto_tools.sh (working copy)
@@ -721,21 +721,7 @@
interactive=yes
fi
- # Commit the changes
- for s in /lib/partman/commit.d/*; do
- if [ -x $s ]; then
- $s || {
- db_input high partman-crypto/commit_failed || true
- db_go || true
- for s in /lib/partman/init.d/*; do
- if [ -x $s ]; then
- $s || return 255
- fi
- done
- return 0
- }
- fi
- done
+ commit_changes partman-crypto/commit_failed || return $?
if ! swap_is_safe; then
db_fset partman-crypto/unsafe_swap seen false
Index: partman-auto-raid/debian/control
===
--- partman-auto-raid/debian/control(revision 50293)
+++ partman-auto-raid/debian/control(working copy)
@@ -9,5 +9,5 @@
Package: partman-auto-raid
XC-Package-Type: udeb
Architecture: all
-Depends: ${misc:Depends}, partman-base (= 99), partman-basicfilesystems,
partman-ext3, partman-auto (= 58), partman-md
+Depends: ${misc:Depends}, partman-base (= 113), partman-basicfilesystems,
partman-ext3, partman-auto (= 58), partman-md
Description: Allow preseeded RAID installs
Index: partman-auto-raid/debian/changelog
===
--- partman-auto-raid/debian/changelog (revision 50293)
+++ partman-auto-raid/debian/changelog (working copy)
@@ -1,3 +1,9 @@
+partman-auto-raid (7) UNRELEASED; urgency=low
+
+ * Use commit_changes from partman-base (= 113)
+
+ -- Max Vozeler [EMAIL PROTECTED] Sun, 02 Dec 2007 13:34:18 +0100
+
partman-auto-raid (6) unstable; urgency=low
[ Frans Pop ]
Index: partman-auto-raid/display.d/initial_auto_raid
===
--- partman-auto-raid/display.d/initial_auto_raid (revision 50293)
+++ partman-auto-raid/display.d/initial_auto_raid (working copy)
@@ -35,21 +35,7 @@
confirm_changes partman-md || exit 1
-# Commit the changes
-for s in /lib/partman/commit.d/*; do
-if [ -x $s ]; then
- $s || {
- db_input critical partman/text/commit_failed || true
- db_go || true
- for s in /lib/partman/init.d/*; do
- if [ -x $s ]; then
- $s || exit 255
- fi
- done
- exit 1
- }
-fi
-done
+commit_changes partman/text/commit_failed || exit $?
stop_parted_server
Index: partman-lvm/debian/control
===
--- partman-lvm/debian/control (revision 50293)
+++ partman-lvm/debian/control (working copy)
@@ -9,6 +9,6 @@
Package: partman-lvm
XC-Package-Type: udeb
Architecture: all
-Depends: ${misc:Depends}, partman-base (= 87), di-utils (= 1.14),
md-modules, lvm2-udeb
+Depends: ${misc:Depends}, partman-base (= 113), di-utils (= 1.14),
md-modules, lvm2-udeb
Description: Adds support for LVM to partman
Index: partman-lvm/debian/changelog
===
--- partman-lvm/debian/changelog(revision 50293)
+++ partman-lvm/debian/changelog(working copy)
@@ -1,5 +1,6 @@
partman-lvm (56) UNRELEASED; urgency=low
+ [ Frans Pop ]
* Only check partition flags if we've not already determined the device is
used for LVM.
* Don't create label and partition for LVM volumes
Re: [RFC] Allow block device providers to veto file systems
Thanks for the review Frans. I've gone ahead now and commited the patch as reviewed with one typo fixed. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414448: #414448: partman-crypto: allow to use unencrytped swap
tags 414448 + wontfix thanks I feel that this is too dangerous an option to allow without requiring the user to jump through hoops to configure it themselves. There is no way this can be safe, and thus no way for it to make sense except for test setups where you don't really care if the encryption is severly weakened. For such test setups, it is IMO easy enough to install with encrypted swap or without swap at all and just change the swap setup afterwards. I'm happy to discuss arguments why it does make sense and why we should introduce the option, but for now I just don't see them; hence tagging the bug +wontfix. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Allow block device providers to veto file systems
Hi Frans,
On Fri, Nov 30, 2007 at 06:39:50PM +0100, Frans Pop wrote:
On Friday 30 November 2007, Max Vozeler wrote:
Why pipe them and not just pass them as a parameter?
Call the script as '$i $dev $id $filesystems' and in the script have
'filesystems=$3'.
That's what I tried first.
I changed to piping because otherwise we'd have to do
comparably complex list comparisons. E.g. either:
Hmm. I don't get this. You could still echo back the valid options, same as
you do now. You just pass them _in_ as a parameter which avoids the (IMO)
ugly 'cat' commands in the veto script.
AFAICT my suggestion does not fundamentally change your solution.
Ah, yes, you are right. I though into a different direction.
This is indeed easier and should be more robust.
I personally prefer the style I originally used because
it saves one level of (to me) not meaningful indentation,
but that's a matter of taste. I'm happy to change it :-)
No, it does not cost a level of indentation because the conditions are
indented by only 4 spaces so their code is still only indented by a single
tab. Indenting the conditions by spaces has the advantage that the total
case-esac block is better recognizable.
This exception to using only tabs for indentation is documented in the D-I
coding style document.
OK, fair enough. I've changed it and updated the patch to
include the other suggestions. (Attached)
Max
Index: partman-basicmethods/choose_method/filesystem/choices
===
--- partman-basicmethods/choose_method/filesystem/choices (Revision 50282)
+++ partman-basicmethods/choose_method/filesystem/choices (Arbeitskopie)
@@ -13,7 +13,13 @@
done
)
-for fs in $filesystems; do
+allowed=$filesystems
+for i in /lib/partman/test_valid_filesystems/*; do
+[ -x $i ] || continue
+allowed=$($i $dev $id $allowed)
+done
+
+for fs in $allowed; do
db_metaget partman/filesystem_long/$fs description || RET=''
RET=${RET:-$fs}
printf ${fs}\t${RET}\n
Index: partman-basicmethods/debian/changelog
===
--- partman-basicmethods/debian/changelog (Revision 50282)
+++ partman-basicmethods/debian/changelog (Arbeitskopie)
@@ -7,8 +7,13 @@
[ Colin Watson ]
* Use 'mkdir -p' rather than more awkward test-then-create constructions.
- -- Frans Pop [EMAIL PROTECTED] Sun, 13 May 2007 04:05:35 +0200
+ [ Max Vozeler ]
+ * choose_method/filesystem/choices: Allow scripts in
+test_valid_filesystems to prevent certain filesystems
+from being offered.
+ -- Max Vozeler [EMAIL PROTECTED] Fri, 30 Nov 2007 14:10:02 +
+
partman-basicmethods (35) unstable; urgency=low
* Move sanity-checking scripts from finish.d to check.d. Requires
Index: partman-crypto/debian/changelog
===
--- partman-crypto/debian/changelog (Revision 50283)
+++ partman-crypto/debian/changelog (Arbeitskopie)
@@ -6,6 +6,10 @@
[ Max Vozeler ]
* Correct dependencies in base64/Makefile; Thanks to
Robert Millan for report + patch. Closes: #452830
+
+ * Use test_valid_filesystems to allow only ext2 on crypto
+devices with random keys. Closes: #414638. This is only
+effective with partman-basicmethods 36 or later.
* Drop use of the obsolete /dev/loop/ directory
Index: partman-crypto/debian/rules
===
--- partman-crypto/debian/rules (Revision 50282)
+++ partman-crypto/debian/rules (Arbeitskopie)
@@ -48,6 +48,7 @@
dh_install base64/base64 bin/
dh_install blockdev-keygen bin/
dh_install blockdev-wipe/blockdev-wipe bin/
+ dh_install test_valid_filesystems lib/partman
rm -rf `find debian/$(PACKAGE) -name .svn`
binary-indep: install-indep
Index: partman-crypto/test_valid_filesystems/crypto
===
--- partman-crypto/test_valid_filesystems/crypto(Revision 0)
+++ partman-crypto/test_valid_filesystems/crypto(Revision 0)
@@ -0,0 +1,39 @@
+#!/bin/sh
+# Veto filesystems unsuitable for certain crypto setups
+
+dev=$1
+id=$2
+filesystems=$3
+
+filesystems_veto ()
+{
+ [ -f $dev/crypt_realdev ] || return 1
+
+ # Get to the underlying crypto device directory
+ r=$(cat $dev/crypt_realdev)
+ cryptodev=${r##*:}
+
+ [ -f $cryptodev/method ] || return 1
+ method=$(cat $cryptodev/method)
+
+ if [ $method = crypto ]; then
+ [ -f $cryptodev/keytype ] || return 1
+ keytype=$(cat $cryptodev/keytype)
+
+ if [ $keytype = random ]; then
+ # Veto anything but ext2
+ for fs in $filesystems; do
+ case fs in
+ ext2) echo $fs
Please unblock loop-aes-utils
Hi release team, please unblock loop-aes-utils 2.13-2 (frozen due to udeb) provided that d-i RMs agree. I think it should be safe because mount-aes-udeb is not included in any initrds. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Allow block device providers to veto file systems
Hi Frans,
On Fri, Nov 30, 2007 at 05:01:35PM +0100, Frans Pop wrote:
On Friday 30 November 2007, Max Vozeler wrote:
I've spent some time thinking about possible solutions
for #414638 which all essentially worked around the fact
that partman offers file systems (via valid_filesystems)
that are not actually valid for certain crypto setups.
Could you elaborate a bit? The report talks about the 'tmp' setting
in /etc/crypttab. Is that equivalent to using random keys?
The problem exists with any kind of file system on
crypto with random keys (please see below). The tmp
option is added only if the underlying crypto device
uses random keys, but is is just one symptom.
Why is use of random keys so restricted?
It is limited by the capabilities of the cryptdisks
script in cryptsetup and the phash=random handling in
loop-AES. Both just create an ext2 unconditionally.
Hence, if you want to have file system on an encrypted
device with random keys that is re-created each time
automatically, your choice is limited to ext2.
Also, isn't swap also allowed with random keys?
Yes, fortunately there is no choice of swap type to
be made there. Both loop-AES and cryptdisks know that
they need to run mkswap on the device and that this is
enough to make the device usable as swap space.
I've pondered different ways of implementing this, and
ended up with the attached patch. There are two things
I don't like about it: Since we are piping the list of
filesystems through the veto scripts, any error in them
can cause the list to end up empty. The scripts have to
be extra careful not to consume stdin by accident.
Why pipe them and not just pass them as a parameter?
Call the script as '$i $dev $id $filesystems' and in the script have
'filesystems=$3'.
That's what I tried first.
I changed to piping because otherwise we'd have to do
comparably complex list comparisons. E.g. either:
foreach filesystem
foreach veto script
is vetoed
skip
else
offer in dialog
Which needs to run the veto script(s) many times
and is slower, or
foreach veto script
run with filesystems as parameter
get vetoed file systems, add to list
foreach filesystem
if filesystem in veto list
skip
else
offer in dialog
where the if thing in list is a little cumbersome
to do in shell. But I think it can be done if there
is consensus that it is more robust.
The second thing I don't like but couldn't come up with
anything better is the name 'valid_filesystems_veto'. If
the basic idea is sound, and anyone has suggestions for
a better name of the directory, I'm all ears :-)
{test,check}_valid_filesystems ?
I like check_valid_filesystems, but it could be confused
with check filesystem as in fsck. Perhaps test_ is
better since it is unambiguous.
+ for fs in $(cat); do
+ case fs in
+ ext2)
+ echo $fs
+ ;;
+ esac
+ done
The preferred indentation for case statements is:
case fs in
ext2)
echo $fs
;;
esac
In this case I'd just use:
case fs in
ext2) echo $fs ;;
esac
OK, that's fine.
I personally prefer the style I originally used because
it saves one level of (to me) not meaningful indentation,
but that's a matter of taste. I'm happy to change it :-)
Thanks for you feedback.
Max
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[RFC] Allow block device providers to veto file systems
Hey all,
I've spent some time thinking about possible solutions
for #414638 which all essentially worked around the fact
that partman offers file systems (via valid_filesystems)
that are not actually valid for certain crypto setups.
So I thought it would be useful to have a mechanism for
providers of block devices to veto the use of certain
file systems on the devices they provide, because they
know that those choices won't work [1].
I've pondered different ways of implementing this, and
ended up with the attached patch. There are two things
I don't like about it: Since we are piping the list of
filesystems through the veto scripts, any error in them
can cause the list to end up empty. The scripts have to
be extra careful not to consume stdin by accident.
The second thing I don't like but couldn't come up with
anything better is the name 'valid_filesystems_veto'. If
the basic idea is sound, and anyone has suggestions for
a better name of the directory, I'm all ears :-)
Max
--
[1] Otherwise we have to catch those invalid choices
in e.g. check.d or finish.d scripts, warn the user and
tell them to go back and fix it themselves. I feel we
already have too many of those rather user-unfriendly
checks in partman-crypto. If we can, we should IMO try
prevent invalid choices in the first place.
Index: partman-basicmethods/choose_method/filesystem/choices
===
--- partman-basicmethods/choose_method/filesystem/choices (revision 50282)
+++ partman-basicmethods/choose_method/filesystem/choices (working copy)
@@ -13,7 +13,13 @@
done
)
-for fs in $filesystems; do
+allowed=$filesystems
+for i in /lib/partman/valid_filesystems_veto/*; do
+[ -x $i ] || continue
+allowed=$(echo $allowed | $i $dev $id)
+done
+
+for fs in $allowed; do
db_metaget partman/filesystem_long/$fs description || RET=''
RET=${RET:-$fs}
printf ${fs}\t${RET}\n
Index: partman-basicmethods/debian/changelog
===
--- partman-basicmethods/debian/changelog (revision 50282)
+++ partman-basicmethods/debian/changelog (working copy)
@@ -7,8 +7,13 @@
[ Colin Watson ]
* Use 'mkdir -p' rather than more awkward test-then-create constructions.
- -- Frans Pop [EMAIL PROTECTED] Sun, 13 May 2007 04:05:35 +0200
+ [ Max Vozeler ]
+ * choose_method/filesystem/choices: Allow scripts in
+valid_filesystems_veto to prevent certain filesystems
+from being offered.
+ -- Max Vozeler [EMAIL PROTECTED] Fri, 30 Nov 2007 14:10:02 +
+
partman-basicmethods (35) unstable; urgency=low
* Move sanity-checking scripts from finish.d to check.d. Requires
Index: partman-crypto/debian/changelog
===
--- partman-crypto/debian/changelog (revision 50282)
+++ partman-crypto/debian/changelog (working copy)
@@ -6,8 +6,13 @@
[ Max Vozeler ]
* Correct dependencies in base64/Makefile; Thanks to
Robert Millan for report + patch. Closes: #452830
+
* Drop use of the obsolete /dev/loop/ directory
+ * Use valid_filesystems_veto to allow only ext2 on crypto
+devices with random keys. Closes: #414638. This is only
+effective with partman-basicmethods 36 or later.
+
-- Max Vozeler [EMAIL PROTECTED] Sun, 25 Nov 2007 17:01:43 +0100
partman-crypto (22) unstable; urgency=low
Index: partman-crypto/debian/rules
===
--- partman-crypto/debian/rules (revision 50282)
+++ partman-crypto/debian/rules (working copy)
@@ -48,6 +48,7 @@
dh_install base64/base64 bin/
dh_install blockdev-keygen bin/
dh_install blockdev-wipe/blockdev-wipe bin/
+ dh_install valid_filesystems_veto lib/partman
rm -rf `find debian/$(PACKAGE) -name .svn`
binary-indep: install-indep
Index: partman-crypto/valid_filesystems_veto/crypto
===
--- partman-crypto/valid_filesystems_veto/crypto (revision 0)
+++ partman-crypto/valid_filesystems_veto/crypto (revision 0)
@@ -0,0 +1,40 @@
+#!/bin/sh
+# Veto filesystems unsuitable for certain crypto setups
+
+dev=$1
+id=$2
+
+filesystems_veto ()
+{
+ [ -f $dev/crypt_realdev ] || return 1
+
+ # Get to the underlying crypto device directory
+ r=$(cat $dev/crypt_realdev)
+ cryptodev=${r##*:}
+
+ [ -f $cryptodev/method ] || return 1
+ method=$(cat $cryptodev/method)
+
+ if [ $method = crypto ]; then
+ [ -f $cryptodev/keytype ] || return 1
+ keytype=$(cat $cryptodev/keytype)
+
+ if [ $keytype = random ]; then
+ # Veto anything but ext2
+ for fs in $(cat); do
+case fs in
+ext2)
+ echo $fs
+ ;;
+esac
+ done
+ return 0
+ fi
+ fi
+
+ return 1
+}
+
+filesystems_veto || cat
+
+exit 0
Re: Bug#452830: FTBFS (race condition with -j2)
On Mon, Nov 26, 2007 at 09:25:56AM -0200, Otavio Salvador wrote: Robert Millan [EMAIL PROTECTED] writes: Package: partman-crypto Version: svn Severity: important Tags: patch FTBFS when building with two threads (dpkg-buildpackage -j2). Ack. Please commit. I have commited it. Thanks Robert. My last mail to the bug report apparently got lost.. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to create crypted partition in d-i?
Hello, On Wed, Sep 05, 2007 at 09:43:45PM +0200, Josef Wolf wrote: I tried to create an encrypted partition from d-i on etch. So I select use as crypted partition and can modify crypto parameters. All good and well. But where do I assign the mount point for the crypted partition? You first need to select Configure encrypted volumes near the top of the partman main menu to setup the encrypted partitions. After that, they should appear as separate devices with a single partition on them, for which you can then configure the file system type, mountpoint etc. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to create crypted partition in d-i?
Hello, On Thu, Sep 06, 2007 at 12:01:22AM +0200, Josef Wolf wrote: On Wed, Sep 05, 2007 at 10:45:03PM +0200, Max Vozeler wrote: You first need to select Configure encrypted volumes near the top of the partman main menu to setup the encrypted partitions. I realize that my wording (You first need to) may have been misleading. Let me try again :-) The setup goes like this, essentially: o Select Manual o Select a partition that you want to encrypt o Select Use as, choose physical volume for encryption o Set encryption options o Select Done setting up the partition o Repeat for other to-be-encrypted partitions Now another choice should appear near the top of the menu, titled Configure encrypted volumes. When you select this choice, you'll be asked for the passphrase(s) and partman will proceed to setup the encrypted partitions. Afterwards there should be new entries for each encrypted partition, similar to the entries for a normal disk, which you can select and configure like a normal partition, setting the file system, mount point, etc. Hope this clarifies. Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414309: cannot configure encrypted volume if stray swap exists
reassign 414309 partman-crypto thanks Hi Stephen, Thanks for your bug report. On Sat, Mar 10, 2007 at 03:03:20PM -0500, Stephen Gildea wrote: In the Partition disks step, using the Manual partitioning method, I cannot configure encrypted volumes. I create a partition, for use as a physical volume for encryption. When I try to Configure encrypted volumes, I get the error screen Unsafe swap space detected and cannot proceed. The error screen suggests running swapoff. I press Alt-F2 RET and type swapoff -a to the shell there; it does not help. (But it should, yes? Is this another bug?) Sounds like another bug. The normal swapoff in util-linux looks at /proc/swaps when called with -a and deconfigures all swap devices listed therein. I'll need to check what busybox swapoff does. It also works to, in the partitioner, edit the swap partition on the other disk and set its Use as field to do not use. It took me a while to figure this out, and I feel this step should not be necessary. I don't think we can skip this step if we still want to automatically configure existing swap partitions on the system, but I agree that it should be easier to handle. What we could try: Find out how much normal memory is available and whether the system really needs the swap space, then, if possible, offer to deconfigure the swap partitions automatically. This change is too big to happen before etch is released, but definitely something I'll look at afterwards. If the above should turn out to be impossible or too much work, I'll try to improve the error template to mention that one can set the Use as field rather than switch to a different VT and use swapoff to deconfigure it manually. (This is post-etch as well) If I select Guided partitioning and ask for Guided - encrypted LVM, it works fine. Somehow this method gets rid of the unwanted swap device. I would guess that this is because guided partitioning doesn't try to automatically setup existing swap partitions, but I'm not sure about that. cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.18-9
Hi all, On Sun, Dec 17, 2006 at 02:43:57AM -0800, Steve Langasek wrote: On Fri, Dec 15, 2006 at 06:08:08PM +0100, Frederik Schueler wrote: This update bears 3 ABI breaking changes. While the vserver patch might be adaptable, the PAE migration of i386 Xen is not. But we need this change as a workaround for #399113, otherwise the i386 Xen kernels will be broken in the release, and require an immediate update. And since we are already planning an ABI bump, we can add the missing changeset of 2.6.18.5, too. The first two ABI changes are specific to extra kernel flavors that aren't relevant to the installer and have few (if any?) extra modules built for them. Actually, quite a few modules packages are being built for the vserver and xen flavours : main: spca5xx (linux-modules-extra-2.6) redhat-cluster (linux-modules-extra-2.6) squashfs(linux-modules-extra-2.6) loop-aes(loop-aes) contrib: ipw2100 (linux-modules-contrib-2.6) ipw2200 (linux-modules-contrib-2.6) ipw3945 (linux-modules-contrib-2.6) non-free: kqemu (linux-modules-nonfree-2.6) Unless I missed some, I think this concerns four source packages. I'm not sure if it would be possible to binNMU / force rebuild of those, but since linux-modules-* are maintained by the kernel team and loop-aes by myself, I think we could react quickly and rebuild them via normal sourceful uploads as well. cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393919: partman-crypto: should provide separate short description
Hi Frans,
On Sun, Oct 22, 2006 at 03:50:44PM +0200, Frans Pop wrote:
On Saturday 21 October 2006 23:17, Max Vozeler wrote:
I've seen this problem during installs in german locale (#381968),
and this is really something that could be improved. Overall though,
I think having at least a chance to associate the backing device
with the encrypted device is more important than having the minor
glitch of a cut-off string.
The only problem is that in the screenshot I gave as example, _all_ the
really usefull info is cut off. So the actual gain is exactly zero.
Yes, this is also what I experienced in german locale. I meant at
least a chance to associate in that works at least for languages
where the translation is not as long as for dutch or german, whereas
replacing it with crypto would make it impossible in any case.
If you want to make sure some mapping info is visible, then we
should make sure the string is short enough so that it actually
_will_ be useful. For example by _only_ listing sda5_crypt,
without the Encrypted volume bit.
Using just the device name as you described seems very practical and
I think actually solves this problem. The device name is mentioned
in the humandev string of the encrypted device, so it can be asso-
ciated easily. I'm currently testing a patch like the attached which
puts string like loop0 or sda5_crypt in the last column. Will
followup once I've confirmed that it works.
cheers,
Max
Index: update.d/crypto_visuals
===
--- update.d/crypto_visuals (Revision 41879)
+++ update.d/crypto_visuals (Arbeitskopie)
@@ -20,12 +20,29 @@
[ -f $id/method ] || exit 0
method=$(cat $id/method)
+cryptdev_shortname ()
+{
+ case $1 in
+ /dev/loop*)
+ n=${1#/dev/loop}
+ n=${n#/}
+ echo loop${n}
+ ;;
+ /dev/mapper/*)
+ echo ${1#/dev/mapper}
+ ;;
+ *)
+ echo $1
+ ;;
+ esac
+}
+
if [ $method = crypto ]; then
db_metaget partman/method_short/$method description || RET=''
echo ${RET:-crypto} $id/visual_filesystem
if [ -f $id/crypt_active ]; then
- RET=$(humandev $(cat $id/crypt_active))
+ RET=$(cryptdev_shortname $(cat $id/crypt_active))
else
db_metaget partman-crypto/text/not_active description || RET=''
fi
Bug#393919: partman-crypto: should provide separate short description
On Sun, Oct 22, 2006 at 05:30:55PM +0200, Max Vozeler wrote:
Using just the device name as you described seems very practical and
I think actually solves this problem. The device name is mentioned
in the humandev string of the encrypted device, so it can be asso-
ciated easily. I'm currently testing a patch like the attached which
puts string like loop0 or sda5_crypt in the last column. Will
followup once I've confirmed that it works.
This is what it looks like:
http://nusquama.org/~max/scratch/cryptdev_shortname.png
Index: update.d/crypto_visuals
===
--- update.d/crypto_visuals (Revision 41879)
+++ update.d/crypto_visuals (Arbeitskopie)
+cryptdev_shortname ()
+{
+ case $1 in
+ /dev/loop*)
+ n=${1#/dev/loop}
+ n=${n#/}
+ echo loop${n}
+ ;;
+ /dev/mapper/*)
+ echo ${1#/dev/mapper}
echo ${1#/dev/mapper/}
I've made this minor adjustment to the patch (stripping an
superflous slash for /dev/mapper/ devices). Otherwise it is tested
and working as expected. I think the change is low-risk. Do you
reckon this is OK to commit wrt the rc1 commit-freeze?
cheers,
Max
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394681: installation-report: Some installation problems
On Sun, Oct 22, 2006 at 05:17:11PM +0200, Milan Zamazal wrote: - I tried to use encrypted block device (dm-crypt with default settings). The partioning tool looked like I could create multiple partitions inside a single dm-crypt area, but actually any attempts to create both a root partition and swap there resulted in refusing to create the swap partition. This is expected, or could be a bug, depending on whether I understood your description correctly. :-) partman creates what looks like a single partition inside the encrypted device. This is really a virtual partition though, because it is not possible to create partitions on a dm-crypt or loop-AES encrypted device (it can be done with LVM). If one deletes that partition and creates a smaller one in it's place, partman should show the remaining space as unusable like in this screenshot: http://nusquama.org/~max/scratch/unusable.png Does this match what you saw? If not, could you describe in more detail what the screen looked like? Thanks. cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393919: partman-crypto: should provide separate short description
Hi Frans, On Wed, Oct 18, 2006 at 03:21:40PM +0200, Frans Pop wrote: Currently the same string is used for both listing encrypted partitions as devices and as a short description after the encrypted partition itself. For the short description the current string is too long which leads to it being cut off as can be seen in: http://people.debian.org/~fjp/d-i/partman-crypto_cut-string.png on the line for SCSI1 (0,0,0); #5. It would be good to use a separate string for the short description, maybe just crypto, just like is done for swap. The reason I originally included $(humandev $dev) in there was to make it possible for users to associate the encrypted device with the backing device. For dm-crypt, this is partially obsolete as we choose the name of the encrypted volume based on the backing device, e.g. sda5_crypt. The string sda5 never appears in the interface though, so this still requires users to think: Ok, partition #5 of SCSI1 (0,0,0) is likely to be sda5. This is more difficult for loop-AES encrypted devices as we cannot choose an arbitrary name, but only /dev/loop[0-n]. Without the humandev string, there is currently no way to tell which encrypted device is associated with which real device. We have the same problem with LVM and RAID devices, which don't show which belongs to which, but in case of encrypted devices, there are likely to be multiple, so I think associating them is more important. I've seen this problem during installs in german locale (#381968), and this is really something that could be improved. Overall though, I think having at least a chance to associate the backing device with the encrypted device is more important than having the minor glitch of a cut-off string. IMHO of course. Ideally we could find a generic way to make it possible for the user to tell which abstract devices correspond to which real devices that can also be used for LVM and RAID. I think that would be very useful. :-) cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393728: dm-crypt on raid does not play nicely
Hi all, On Tue, Oct 17, 2006 at 05:35:24PM +0200, Miroslav Kure wrote: I installed from today's i386 netinst (20061016) with the following setup: /dev/hda1 16MB /boot /dev/hda2 500MB physical volume for raid /dev/hdb1 16MB unused /dev/hdb2 500MB physical volume for raid RAID 1 was created from /dev/hda2 and /dev/hdb2 and on the top of it dm-crypt partition was created with all defaults. After returning from Configure encrypted volumes the new device md0_crypt was created as expected, but there was no partition inside it to use. I had to press enter on the md0_crypt device itself and it offered me to create new partition table, which in turn created free space, which then I was able to partition. (Quite surprised as I did not see this with partman-crypto yet.) I think I've tracked down at least part of the problem. When you select Configure encrypted volumes, partman-crypto creates the dm-crypt mapping, creates a crypt_active file inside the partman directory of /dev/md0 and goes to restart partman. Normally the partman device directories are then restored in init.d/30parted, but /dev/md* are explicitly excluded from it. The directories for /dev/md* are instead recreated from scratch in init.d/31md-devices. This looses all settings stored in the directory, including the method and crypt_active files, which serve as indicator for init.d/51crypto that it needs to create a partman disk along with a loop-type partition table on it. Instead, it just ignores the device and leaves detecting it to partman. Since there is no existing partition table, partman asks to create a new one. Unless you selected a loop-type partition table, this can in turn allow to create multiple partitions on the dm-crypt device - which I think is not actually possible to do with plain dm-crypt devices (without LVM, that is). So I think this at least explains why partman allowed but handled this setup incorrectly. I'm not sure how we can fix this, though. The current way -md works is to recreate partman devices on each restart, while -crypto relies on them being restored. Changing this, I think, implies fundamental changes to either -dm or -crypto, which is probably out of scope for the moment, at least before the etch release. For the moment, I actually think it would be best to not offer crypto-on-dm setups to prevent this problem. cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392285: partman-crypto: Fails to cause cryptomount to be loaded
tags 392285 + confirmed pending thanks Hi James, On Tue, Oct 10, 2006 at 07:40:18PM +0100, James Westby wrote: I had the first partition for / unencrypted, then two partitions, a random key for swap, and a GPG encrypted key for /home. I used twofish128 for minimum impact while testing. The install went fine, until I rebooted. I was asked for my passphrase, and when I entered it I was told /home couldn't be mounted. The following message accompanied it. LOOP_SET_STATUS: Invalid argument, requested cipher or key length (128 bits) not supported by kernel. I googled the error, and found a message written by Max indicating that another module was needed. I modprobed cryptoloop, and it changed the error message. So it seems like some magic chould be done to load this module at boot time. That's only partially correct. :-) The above error is shown if the LOOP_SET_STATUS/64 ioctl failed for the chosen combination of cipher/keysize. In this case, it indicates that the kernel had no support for loopback crypto as neither the cryptoloop nor a loop-AES module was loaded. As shown by the second error you quoted below, however, the newer crypto modes of loop-AES are not supported by the old cryptoloop module, so it can not be used as a replacement for the loop-AES module. After adding cryptoloop I get the error message LOOP_MULTI_KEY_SETUP_V3: Invalid argument #318944 suggests this is because a v3 key was used with a v2 module, but I have a v3 module installed. Yes, this indeed used to be a frequent cause for similar errors. In this case though, I think the reason is likely to be that the cryptoloop module doesn't know about multi-key modes and therefor doesn't handle this particular ioctl. Apologies if I am doing something stupid here, please punish me if I am. Also I don't know what version I am supposed to put for these, but I am using the daily image downloaded 8th October, and installed the day after. I have loop-aes-2.6.16-2-686 3.1d+3+3 installed by the installer. ^^ I strongly suspect that this is the problem. The default kernel currently installed by daily builds is 2.6.17-2, but loop-aes-* is only available in testing for 2.6.16-2. The installer likely tried to install the meta package loop-aes-2.6-686 and so ended up with the old modules package. If you still have the VM, you should be able to verify by installing loop-aes-2.6.17-2-686 from unstable. time warp So I have just completed a test install and can confirm that this is indeed reproducible and can be fixed by installing the package loop-aes-2.6.17-2-686. The problem will exist until we manage to migrate loop-aes modules for 2.6.17-2 to testing (hopefully soon), or until the 2.6.18 kernel becomes the default kernel in testing along with new loop-AES modules. cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385629: debian-installer: Encrypted filesystem setup and swap
clone 385629 -1 retitle -1 Swap check fails for swap-on-LVM-on-crypto thanks Hi James, On Mon, Oct 09, 2006 at 11:59:55PM +0100, James Westby wrote: I am playing around with the installer and I believe I have hit this problem. If I select automatically set up LVM and crypto I get a good setup, but if I then go to Configure encrypted partitions I am told I can't as swap is not encrypted. The swap is an LVM partition on a dm-crypt device, so I think partman-crypto's detection of encrypted swap in this case is not working. Ah, good catch. Our swap check takes the swap device and checks if it's an encrypted loop (using losetup) or dm device (dmsetup). In case of swap-on-LVM-on-crypto, the check only sees swap-on-LVM and so concludes that the setup is unsafe. [Also it seems that I cannot delete an encrypted partition, even if I get to free space on it, it still says In use for ..., is there a way to do this? It was annoying having to restart the installer every time I wanted to try something different. Could you point me to the apprpriate package for this, I'm not sure it is partman-crypto] Deleting encrypted partitions has not been implemented. The relevant package is partman-crypto. cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#391664: partman-auto-crypto: Some questions and issues
Hi all, On Tue, Oct 10, 2006 at 01:51:34AM +0200, David Härdeman wrote: The loop is there because it needs to look not for the $dev device but the virtual device-mapper device which has been created ontop of the device pointed to by $dev after the crypto_setup step. It should be a bit smarter and make sure the virtual-$dev - $dev mapping is correct thoughand it should probably exit the loop once that is established...but I don't think the loop can be removed... Just a quick thought before I rush to work: Couldn't we use the $part/crypt_active file after crypto_setup? part=$(dev_to_devdir $dev) [ -f $part/crypt_active) ] || problem cryptdev=$(cat $part/crypt_active) cryptdevdir=$(dev_to_devdir $cryptdev) cheers, Max
Bug#381875: loop-AES key generation requires tiresome typing
Hi James, On Tue, Oct 10, 2006 at 08:39:07PM +0100, James Westby wrote: 1) Make a game that involves typing, I was reminded of a game called Daley Thompson's Decathlon, which involved bashng two keys in turn as quickly as possible, while this wouldn't be good I thought some sort of game might be. Bear with mw while I outline an idea, Implement tetris (hmm, I'm not really volunteering for this bit.) then the user is making key presses, and is more happy to spend the time. The progress bar could be inverted to count down, then it is score as many points as possible before it runs out. Yeah it's probably not workable, but I thought it was quite fun anyway. I like the idea a lot. In fact, this was my first approach before cdebconf-entropy. :-) I actually started to implement EntroPong (classic pong) in newt; I should still have the sources somewhere. I got a bit discouraged because it turned out that the amount of entropy contributed to the kernel pool was very low. IIRC (should check) what contributes entropy are the inter-keypress timings, not the actual keys pressed, so the concept of Decathlon you describe could in fact be very suitable. 2) Use a source of entropy on another machine. There are sites (I forget the name, you probably know them), that provide entropy across the Internet. While I'm not that sure of the idea, it would solve the problem some what. I think there are two implications to this: First, we would need to trust the provider of the random data to never look at it and/or clear all records of it after transmission. If you had a particular randomn- ness provider you trust, this could be feasible. Except that we'd transfer the random bits over the network, where anyone could look at them. My understanding is that mixing in such a source cannot hurt the resulting random output, but overall I think such input would not actually help us for encryption key generation. 3) Allow randomness/key to be retrieved from elsewhere. Similar to preseeding, either grab a file of a disk or server that has entropy or the keys. Obviously it needs to be done right, but I think this should perhaps be done anyway to help with multiple installs. You can have the file in any format you like (cat /dev/random file or actually create GPG encrypted keys), and provide a script to create one on a running machine. This seems like the most practical solution. I suppose it would be easiest to just generate complete GPG keys on another machine; That would save us from having to worry about secure transport of the random data. There is a small script loop-aes-keygen(1) in package loop-aes-utils which can be used to create GPG-wrapped encryption keys on another system. They could be stored on some removable medium and get loaded by partman-crypto. 4) Make d-i harder to use. If entropy is gathered during the install, it should be made harder, so that more key presses are required before partman-crypto is reached, and so increasing the entropy in the pool without the user realising it is for encryption. :-) cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i beta3, raid, loop-aes and lvm
Hi Philipp, On Thu, Oct 05, 2006 at 01:27:41AM +0200, Philipp Engel wrote: Am 03.10.2006 um 15:32 schrieb David Härdeman: On Tue, October 3, 2006 15:16, Philipp Engel said: Is that a bug, or is it just not possible? If memory serves me right, the loop-AES utils do not have support (yet) for automatically setting up the LVM volume after the encrypted module has been setup. In addition the loop-AES tools lack the initramfs integration to do the work (in the initramfs) for setting up the root partition. Max talks about only having to tell partman-lvm that it may consider loop devices as valid backing devices. Your description of the solution in contrast sounds far more time consuming and difficult...:) So, can you tell me what's to do? It is probably both. :-) David correctly points out that there is no special handling for LVM on loop-AES devices in the installed system. This could mean that LVM setup happens before there is a chance to setup loop-AES. The change to partman-lvm is probably required for partman-crypto to actually offer this kind of setup, regardless of whether it would work or not. I have little idea what's actually missing though as I have never tried. About what can be done: In case you decide to build such a setup manually, you could take notes of the steps that were required to get a working setup and all problems you encountered; I think such notes would be extremely useful for documentation on the wiki or so, but even more because they would tell us exactly what needs to be done in order to add support for it to partman-crypto and the loop-aes init scripts. I have checked out the source code of the debian installer and am currently reading the documentation, which is a good amount of text. I will see if I can manage to create my own boot disk, that will be an adventure already :) Good luck. Feel welcome to ask any questions on this list (or off-list if they concern only loop-AES in the installed system). cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
