On Fri, May 11, 2007 1:38, Frans Pop said: > 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.
Perhaps it's a kernel stack overflow issue? I remember there being a lot of fixes going into the kernel to reduce stack usage when the stack was reduced to 4kB and that many of the patches were against "stacked" filesystems (e.g. anyfs-on-lvm-on-md-on-something). Does dmesg show any interesting kernel messages after the installation barfs? (like stack overflow warnings) -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
