Re: boot failed with gzip'ed modules

> From: David Naylor <naylor.b.david_at_gmail.com>
> Date: Sat, 26 Apr 2008 18:40:48 +0200
> Sender: owner-freebsd-current_at_freebsd.org
> 
> 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
 I can't comment on the problem, but I can comment on the csup part. It
is fully capable of tracking this down, especially if you have a good
time window on when the commit happened.

Use the date= option in your subfile to set the appropriate date and
use -i to only update the files you need to update.

For example, edit the supfile to contain:
src-all date=2008.01.23.15.00.00

and issue the command:
csup -i src/sys/amd64 current-supfile

This will change only files in the specified directory and those below it.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman_at_es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751