From owner-freebsd-current@FreeBSD.ORG Mon Dec 9 09:56:21 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78729C2D; Mon, 9 Dec 2013 09:56:21 +0000 (UTC) Received: from web1.unixengines.com (web1.unixengines.com [88.198.32.73]) by mx1.freebsd.org (Postfix) with ESMTP id F0BA317EC; Mon, 9 Dec 2013 09:56:20 +0000 (UTC) Received: from [92.86.79.170] (helo=MacMac.local) by web1.unixengines.com with esmtpa (Exim 4.69) (envelope-from ) id 1VpuBt-000Q01-IU; Mon, 09 Dec 2013 08:19:37 +0200 Message-ID: <52A58A48.7000605@freebsdonline.com> Date: Mon, 09 Dec 2013 11:15:52 +0200 From: freebsdonline User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22.1 MIME-Version: 1.0 To: Stefan Hegnauer , 'Konstantin Belousov' Subject: Re: nanobsd / dd problem? References: <52a4ad05.892ee50a.41cd.084aSMTPIN_ADDED_BROKEN@mx.google.com> <20131209044239.GS59496@kib.kiev.ua> <000b01cef4ac$d717b350$854719f0$@hegnauer@gmx.ch> In-Reply-To: <000b01cef4ac$d717b350$854719f0$@hegnauer@gmx.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mav@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 09:56:21 -0000 Stefan Hegnauer wrote: > On Monday, December 09, 2013 at 5:43 AM Konstantin Belousov wrote: > > >> On Sun, Dec 08, 2013 at 06:31:36PM +0100, Stefan Hegnauer wrote: >>> Hi, >>> >>> >>> >>> I am using freebsd-current (FreeBSD BUILDMASTER 11.0-CURRENT FreeBSD >>> 11.0-CURRENT #0 r259095: Sun Dec 8 10:20:40 CET 2013 >>> root@BUILDMASTER:/usr/obj/usr/src/sys/ASUS i386) in a VirtualBox as >> a build >>> machine for nanobsd images to be used on pc-engines.ch alix boards. >> The only >>> difference to GENERIC is the inclusion of 'march=geode' and disabling >> of >>> most debugging switches (malloc, Witness etc). Worked like a charm in >> the >>> past. >>> >>> >>> >>> Since late summer - sorry, no exact date / svn revision - nanobsd.sh >> fails >>> at the last stage when building the disk image, e.g. with >>> >>> ... >>> >>> 00:00:25 ### log: /usr/obj/nanobsd.alixpf//_.di >>> >>> # >>> >>> >>> >>> Looking a bit closer it seems that dd(1) returns with an I/O error >> whenever >>> the input is a file created with mdconfig(8): >>> >>> # dd if=/dev/zero of=somebackingfile bs=1k count=5k >>> >>> # mdconfig -f somebackingfile -u md0 >>> >>> # newfs -U /dev/md0 >>> >>> # dd if=/dev/md0 of=/dev/null >>> >>> dd: /dev/md0: Input/output error >>> >>> 10241+0 records in >>> >>> 10241+0 records out >>> >>> 5243392 bytes transferred in 3.240345 secs (1618159 bytes/sec) >>> >>> >>> >>> The outputfile in nanobsd.sh seems to be error-free. >> It should be one block larger than the right size. >> \ >>> Anyone else seen similar behaviour? How to proceed/fix it? >>> >> The following patch should clear the error. >> >> The issue is that kern_physio() incorrectly detects EOF due to >> incorrect >> calculation of bio bio_resid after the bio_length was clipped by the >> 'excess' code in g_io_check(). Both bio_length and bio_resid appear >> to be 0 in the pre-last dd transfer, which starts exactly and the >> mediasize, and kern_physio() thinks that it transferred one more block >> than was transferred. >> >> I _suspect_ that it was caused by 'excess' code moving in r256880, >> but I am really not in the right condition to analyze it. If somebody >> could try the same dd experiment to confirm or deny my suspicion, it >> would be useful. >> >> The patch below should be a right thing to do anyway. >> >> diff --git a/sys/kern/vfs_bio.c b/sys/kern/vfs_bio.c >> index c23a74b..b7c4d60 100644 >> --- a/sys/kern/vfs_bio.c >> +++ b/sys/kern/vfs_bio.c >> @@ -3679,7 +3679,6 @@ bufdonebio(struct bio *bip) >> >> bp = bip->bio_caller2; >> bp->b_resid = bp->b_bcount - bip->bio_completed; >> - bp->b_resid = bip->bio_resid; /* XXX: remove */ >> bp->b_ioflags = bip->bio_flags; >> bp->b_error = bip->bio_error; >> if (bp->b_error) > Works for me - please commit! > Thanks a lot! > > -Stefan > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I have a similar problem with nanobsd.sh on FreeBSD 10.x. I am able to build the image but sometimes (could not figured out the reason why) the image is build incorrectly. For example on an incorrectly built image when I boot i got: Trying to mount root from ufs:/dev/ada0s1a [ro]... mount: /dev/ada0s3: Invalid argument mount -o ro /dev/ada0s3 /conf/default/etc failed: dropping into /bin/sh It seems the partition that hold config files cannot be accessed. Hope your fix will fix this problem too (asumming you will also commit on 10.x). Theres also an issue with package management, the nanobsd script still uses pkg_add instead of pkg. ovi