NetBSD-Bugs archive

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

Re: kern/47030 (Installation stalls during set extraction)

The following reply was made to PR kern/47030; it has been noted by GNATS.

From: Andreas Gustafsson <>
Subject: Re: kern/47030 (Installation stalls during set extraction)
Date: Mon, 14 Nov 2016 20:13:33 +0200 wrote:
 > I can repeat the problem using 6.1 isos using qemu 2.7.0 from pkgsrc, but not
 > any more with 7.0.1. Also on my test machine I can't repeat it any more
 > after NVMe driver fixes. So I think this problem is actually fixed by changes
 > in 7.x.
 > Please confirm if you still see this problem with recent kernels.
 I don't have an easy way of testing just a recent kernel with a system
 otherwise identical to the the one the bug was originally reported for.
 Instead, I'm testing full release builds from date-based checkouts of
 mainline sources, as that is what I have an automated setup for.
 I did some initial tests with NetBSD/sparc under qemu-current but they
 failed to produce a conclusive result because I kept getting "esp0:
 !TC on DATA XFER" errors, aka PR 46530.
 I then switched to NetBSD/i386, running under qemu-current with 32M
 virtual RAM and a 2G virtual disk.  After some bisections, it looks
 like the problems of installations stalling disappeared with the
  2012. jakllsch src/distrib/utils/sysinst/Attic/bsddisklabel.c 1.57
 This commit disabled WAPBL by default.  In other words, the problem
 appears to be triggered by installing on a file system with WAPBL
 To confirm this, I tested installing -current/i386 (source date
 2016. with following patch to re-enable WAPBL:
 Index: src/usr.sbin/sysinst/bsddisklabel.c
 RCS file: /bracket/repo/src/usr.sbin/sysinst/bsddisklabel.c,v
 retrieving revision 1.2
 diff -u -r1.2 bsddisklabel.c
 --- src/usr.sbin/sysinst/bsddisklabel.c	3 Aug 2014 16:09:38 -0000	1.2
 +++ src/usr.sbin/sysinst/bsddisklabel.c	14 Nov 2016 15:32:54 -0000
 @@ -133,8 +133,9 @@
  			asprintf(&buf, "%s", mountpt);
  		strlcpy(p->pi_mount, buf, sizeof p->pi_mount);
  		p->pi_flags |= PIF_MOUNT;
 -		/* Default to UFS2. */
 +		/* Default to logging, UFS2. */
  		if (p->pi_fstype == FS_BSDFFS) {
 +			p->pi_flags |= PIF_LOG;
  #ifdef DEFAULT_UFS2
  #ifndef HAVE_UFS2_BOOT
  			if (strcmp(mountpt, "/") != 0)
 and the installation once again stalled.
 So, my conclusion is that the bug is still there in the -current
 kernel, but is hidden by WAPBL no longer being enabled by default in
 Andreas Gustafsson,

Home | Main Index | Thread Index | Old Index