Re: Filesystem type survives formatting in debian installer?
On Sat, Mar 03, 2007 at 11:16:21AM +0100, Josef Wolf wrote:
On Fri, Mar 02, 2007 at 09:50:27PM +0100, David Härdeman wrote:
On Fri, Mar 02, 2007 at 06:26:19PM +0100, Josef Wolf wrote:
>On Fri, Mar 02, 2007 at 08:59:01AM +0100, David Härdeman wrote:
[Sorry for the delay, but I had to create a new CD and reinstall from
scratch to find out the version of libklibc just at first reboot]
>>I have verified that mkfs.ext3 does remove the LUKS signature from a
>This is exactly what I wrote in my previos mail: when I run mke2fs by hand,
>everything works. If I choose "reformat with ext3" in partman, it fails.
Sorry, I should have mentioned also that partman uses mkfs.ext3 to
reformat a partition with ext3.
Maybe partman calls mkfs.ext3 with some special parameters?
I think I've found out the real reason for the bug, and the real reason
why I couldn't reproduce it, see below...
I ran the following test yesterday:
Full install, /dev/sda split into /dev/sda1 /dev/sda2, /dev/sda1
unencrypted and containing /boot, /dev/sda2 encrypted and containing a
LVM PV which contained the rest of the filesystems and swap partition.
Can you please try the same test without LVM, but with "cryptsetup
luksFormat" instead? Please note the LUKS. I don't know whether
the problem still happens with LVM (blocks can be remapped, so the
signature might end up on a different position on the partition) or
with different crypt methods (different signature).
>properly. The first reboot (after the base system is installed) fails,
>before any of my scripts are started
>If I (while beeing in partman) switch to a different vterm and run
>mke2fs manually, then go back to partman and continue the installation,
>everything works properly. So a manual mke2fs wipes out the luks
>signature, while "format with ext3" in partman fails to wipe it.
Which libklibc version does your installed system use?
1.4.0-0ubuntu3 at first reboot
1.4.0-0ubuntu after apt-get upgrade
Is this _down_graded by apt-get? Or does "dpkg -l" cut off its output?
Do you think libklibc is causing the problem?
I'm pretty certain that it could, I wrote a number of patches against
klibc to deal with luks partitions in a proper manner, the most
important ones appeared in 1.4.9 and some less important ones appeared
in 1.4.31. One of the fixes was to perform the fs detection in the
correct order (meaning that leftover signatures would not pose a
So, somehow make sure that a newer libklibc is installed to /target
during the late_command phase, and make sure the initramfs is generated
using that klibc.
>>Anyhow, your approach seems quite fragile and contains some potential for
>Can you please activate your verbosity mode? ;-) What potential problems
>do you see?
If you install to one unencrypted partition first, things like
/etc/passwd will be written there.
I don't see a problem here. I install with a default password using
d-i passwd/user-password-crypted password <some-hash>
anyway. When the crypted system is booted the first time, it requests
Then (as far as I've understood from your scripts) you create an
encrypted partition later and move over all the data to that partition.
If so, you must take care to both wipe the old unencrypted partition
(not format it, but wipe it)
Ummm... That is (apart from my added scripts) a default ubuntu install.
No sensitive data there. Why should I take special efforts to wipe
something that you can download from ubuntu.com anyway? The only
sensitive data I can think of are partition information and ssh
Besides, my further plan is to re-use this old partition as (encrypted)
swap space later on. So I will randomize it. But I don't see the need
to shred it or something.
But if you make an installation media which is to be used by others, and
they install a new OS to disk which uses encryption, they will
reasonably expect that any old data from any previous installations will
and before the crypted partition is used, it should also be wiped with
random data to make sure that it is not possible to tell which parts are
in use and which are not.
Finally, you got me. I almost forgot about this one. Unfortunately,
/dev/urandom is soooo sloooow. :-(
Maybe "dd if=/dev/zero of=/dev/mapper/xxx" (using dmcrypt to "randomize")
would be faster. But, OTOH, I bet this method would open some
vulnerabilities (known-plaintext attacks).
I don't think it is. If the output from e.g. aes would be
distinguishable from random data, that would be a strong indication that
aes was broken. Besides, it is basically the method the installer uses
so I really hope it is sane :)
dd if=/dev/zero of=/dev/mapper/xxx has one drawback though, it will
write in blocksized chunks, and I seem to recall that it wouldn't write
the last one if it wouldn't fit. We wrote a very simple c tool to
emulate the same behaviour (which also eliminated the read() calls and
just did write() calls). It's called blockdev-wipe and can be found in
the partman-crypto udeb.