Date: Sat, 26 Apr 2008 18:40:48 +0200 From: David Naylor <naylor.b.david@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: boot failed with gzip'ed modules Message-ID: <200804261840.52978.naylor.b.david@gmail.com> In-Reply-To: <200804260822.47763.jhb@freebsd.org> References: <200804252320.39121.naylor.b.david@gmail.com> <200804260822.47763.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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 line > > 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 down the problem... Except I do not know any cvs commands (I just use csup, which I don't think is powerful enough in this case), also is there an easy way to check the commit history (www.freshbsd.org doesn't allow the commit messages to be filtered on a subset of the files...) Is it only sys/boot and lib/libstand that are involved with loader? If so, unless revision 1.13 to lib/libstand/ntp.c broke it, it is probably that sys/boot is the cause. However sys/boot is rather involved and will take me a bit longer to check the commits using cvsweb... This is not possibly caused by having an amd64 system? Other then csup from about a month ago the only other change I did was switch from i386 to amd64. Since the boot loader is i386 in any case I do not think it will have an impact. > > > Oh, on an aside. What is the BTX and why is the bootloader i386 even for > > 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 geom_uzip? If not is there a good reason why it is avoided or just a case of lacking developer interest (or time)? Thank you for the quick reply David [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBIE1sUUaaFgP9pFrIRAquYAJ91FHCMJxxSoblT5tqMxAatcrCnZwCffgMS 21bboBqi3sZaGYgrkte+Q68= =7QPm -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200804261840.52978.naylor.b.david>