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

Bug#422255: [etch] Installing with root on JFS in LVM fails

reassign 422255 linux-2.6 2.6.18.dfsg.1-11
retitle 422255 [etch] Installing with root on JFS in LVM fails
severity 422255 important

On Friday 04 May 2007 16:27, Mikkel Fahnøe Jørgensen wrote:
> Guided LVM encryption where I change ext3 root filesystem to jfs.
> The entire disk (5GB) is chosen.
> After entering encryption password, root password and user password,
> the system starts installing the base system.
> After 20-33% the system stops progressing, for example while installing
> bash. This is reproducible - but freeze doesn't happen exactly the same
> place each time, hence 20-33%. It could be progress would happen
> eventually, since it also pauses for shorter periods before 20%.

I have just tried two encrypted LVM installs using jfs on /.

The first was using a daily build of the installer (with a workaround for 
an unrelated issue that affects crypto installs) and that was successful.

The second was using an Etch netinst image, and there I can reliably 
reproduce the hangs you are seeing. They seem to occur during the 
unpacking of tarballs. At least, in both cases the last command that is 
visible in the output of 'ps' is "tar -xf -" (obviously a pipe from 
another command).

I've seen two hangs (in different installs):
- one at 31%; ps shows:
     zcat /usr/lib/debootstrap/devices.tar.gz | tar -xf -
- one at 28% "extracting tzdata"; no 'zcat' visible in ps, just:
     tar -xf - (in state D)

State "D" is "Uninterruptible sleep (usually IO)"; there is no processor 
activity; killing processes does not help, the system remains frozen.

I've also tried a normal install (no crypto, no LVM) with / on jfs, and 
that succeeded without problems.
However, with jfs on / using LVM without crypto, I can also reproduce the 
problem, so the fact that encryption was used is irrelevant. The issue 
seems to be with using jfs in LVM (or maybe jfs with device-mapper).

It does look like we've got a kernel issue here in the 2.6.18 kernel that 
has apparently been fixed in 2.6.20.


Attachment: pgpLdR3Akv9i5.pgp
Description: PGP signature

Reply to: