[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Filesystem type survives formatting in debian installer?



On Fri, Mar 02, 2007 at 08:59:01AM +0100, David Härdeman wrote:
> On Fri, March 2, 2007 1:17, Josef Wolf said:
> > The error occures on the first reboot (before any of my scripts
> > mentioned above come into the game).
> >
> >   fsck.ext3: Unable to resolve 'UUID=xxxxxxxxx'
> >   fsck died with exit status 8
> 
> If you get this error on the first reboot, then you have already managed
> to hose something prior to the first reboot.

The only thing I do prior the first reboot is to install my scripts
in /etc/rcS.d/S9Xfoobar, so they would be run at the end of the boot
process:

  d-i preseed/late_command string \
    cp /cdrom/preseed/postinstall.sh  /target; \
    cp -a /cdrom/preseed/cryptsetup.d /target; \
    ln -s /postinstall.sh        /target/etc/rcS.d/S98postinstall; \
    ln -s /cryptsetup.d/setup.pl /target/etc/rcS.d/S99cryptsetup

I do _not_ create any crypt filesystems before the reboot.  The partitions
contained crypted filesystems in the _previous_ install.  But those should
not be recognized as crypted filesystems anymore because I advised partman
to reformat them with ext3.

> As far as I know the ubuntu
> initramfs scripts default to identifying the root fs via the UUID.

This happens for _any_ fs, not only for root fs.

> > Then I get dropped into the initramfs shell:
> >
> >   # mount /dev/hda7 /mnt
> >   mount: unknown filesystem type 'crypto_LUKS'
> >   # mount -t ext3 /dev/hda7 /mnt
> >   #
> 
> There is something wrong with your scripts.

As I noted above, the error occures before any of my scripts are started
They _would_ be started later in the boot process (as they are installed
as /etc/rcS.d/S99foobar) if only the error would not occur.

How can the scripts screw up anything if they are not even started?

> I have verified that mkfs.ext3 does remove the LUKS signature from a
> device,

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.

> so somehow you have actually
> setup a crypto filesystem on /dev/hda7 at some stage or you haven't
> actually created an ext3 fs on /dev/hda7 at some stage.

Yes, there actually _is_ a luks filesystem from the _previous_ install.
But on the fresh install I advice partman to _reformat_ this partition
with ext3.  And partman actually reformats it.  But it does it _not_
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.

> Anyhow, your approach seems quite fragile and contains some potential for
> information leaks,

Can you please activate your verbosity mode? ;-)  What potential problems
do you see?

> may I suggest that you work with the Ubuntu community
> to get the Debian crypto features (partman-crypto, partman-auto-crypto,
> cryptsetup-udeb and cryptsetup with initramfs scripts) properly ported to
> Ubuntu's version of the installer?

That will probably be the best.  But please note that the problem from
this thread is not really related to crypto features.



Reply to: