From owner-freebsd-current@FreeBSD.ORG Sat Apr 26 16:41:19 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C050B1065682 for ; Sat, 26 Apr 2008 16:41:19 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by mx1.freebsd.org (Postfix) with ESMTP id 432678FC0A for ; Sat, 26 Apr 2008 16:41:18 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so4655790fgg.35 for ; Sat, 26 Apr 2008 09:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:message-id; bh=pwdfheYu1w19qq0LD9LWgCJzG/ZvVb3b4SbajbNp/jI=; b=DsyfArxsZ3DIXg+Tr3iQdSp4okrNEltRzi+MTSQtQXSnigO7ASUN/AfjpLY2vqUVefaYiptCDPrpgUgmDv/5mZlos/CUPk+1tGDUEl9q3A26F9jkEyNJ4gLjsJ1uQkoxicFUpCTNRH+FSGdSpj8kd+1b2yCX897piZte/hwWc4g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:references:in-reply-to:cc:mime-version:content-type:content-transfer-encoding:message-id; b=BqlS22a+SHB1mQAY4bfgraN71tVxr06bJ9Wg/xzIFTRpRJR6GaD1xhpb/jg4xC+2R1fiCaWpbCFnFHWrVMfQxOt74rffGsAdPkW2tNQ+lEDu4m8h0UHnZpuY4Z+c99oaZ9sRDRxe7IoPyZh33NYyVursaPwzbj02f/wkybHaLWA= Received: by 10.86.49.6 with SMTP id w6mr3791313fgw.59.1209228077703; Sat, 26 Apr 2008 09:41:17 -0700 (PDT) Received: from ?0.0.0.0? ( [196.34.241.123]) by mx.google.com with ESMTPS id p9sm6299098fkb.14.2008.04.26.09.41.12 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Apr 2008 09:41:15 -0700 (PDT) From: David Naylor Organization: Private To: John Baldwin Date: Sat, 26 Apr 2008 18:40:48 +0200 User-Agent: KMail/1.9.7 References: <200804252320.39121.naylor.b.david@gmail.com> <200804260822.47763.jhb@freebsd.org> In-Reply-To: <200804260822.47763.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1816743.Pd8ge130TP"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200804261840.52978.naylor.b.david@gmail.com> X-Mailman-Approved-At: Sat, 26 Apr 2008 17:12:29 +0000 Cc: freebsd-current@freebsd.org Subject: Re: boot failed with gzip'ed modules X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 26 Apr 2008 16:41:19 -0000 --nextPart1816743.Pd8ge130TP Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 26 April 2008 14:22:47 you wrote: > On Friday 25 April 2008 05:20:34 pm David Naylor wrote: > > Hi, > > > > I have a live CD that has a GENERIC kernel and that loads some modules > > before booting. They have been gzip'ed to save space however suddenly > > the booting has stopped. The kernel loads and then after the first li= ne > > of the modules to load it stops: > > I've seen reports of problems with gzip'd modules on 7.0. You'll probably > have to add debugging or look at the diffs between 6.3 and 7.0 of the boot > code (sys/boot and lib/libstand) to narrow down things to try. (For > example, did moving malloc up above 1MB break it somehow.) I think the break happened to HEAD in the last month, I can easily track do= wn=20 the problem... Except I do not know any cvs commands (I just use csup, whic= h=20 I don't think is powerful enough in this case), also is there an easy way t= o=20 check the commit history (www.freshbsd.org doesn't allow the commit message= s=20 to be filtered on a subset of the files...) Is it only sys/boot and lib/libstand that are involved with loader? If so,= =20 unless revision 1.13 to lib/libstand/ntp.c broke it, it is probably that=20 sys/boot is the cause. However sys/boot is rather involved and will take m= e=20 a bit longer to check the commits using cvsweb... This is not possibly caused by having an amd64 system? Other then csup fro= m=20 about a month ago the only other change I did was switch from i386 to amd64= =2E =20 Since the boot loader is i386 in any case I do not think it will have an=20 impact. =20 > > > Oh, on an aside. What is the BTX and why is the bootloader i386 even f= or > > an amd64 system (I suspect it is because there is no need for an amd64 > > bootloader [unless kernels and modules suddenly exceed 4GB 8-/ ])? > > 1) BTX is a mini-kernel that the boot code uses. This lets us write the > boot loader as a 32-bit app in C rather than assembly. Nice :-) > 2) Yes, the amd64 code uses the i386 bootstrap. amd64 CPUs start up in > real mode just like i386 and you can't easily call the BIOS from long mode > anyway, so a different bootstrap for amd64 would be rather gratuitous. Thought so... Is there any plan to add bzip2 to loader (i.e. bzip2 modules and kernel) or= to=20 geom_uzip? If not is there a good reason why it is avoided or just a case = of=20 lacking developer interest (or time)? =20 Thank you for the quick reply David --nextPart1816743.Pd8ge130TP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBIE1sUUaaFgP9pFrIRAquYAJ91FHCMJxxSoblT5tqMxAatcrCnZwCffgMS 21bboBqi3sZaGYgrkte+Q68= =7QPm -----END PGP SIGNATURE----- --nextPart1816743.Pd8ge130TP--