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

Re: investigation of SYSLINUX booting problems



iwj10@cus.cam.ac.uk (Ian Jackson) said:

> Bruce Perens writes ("Re: investigation of SYSLINUX booting problems "):
> > [...]
> > Which one gets used to create a boot floppy depends on other issues, the
> > most important one of which is whether we're trying to cram the root
> > filesystem on the same disk as the kernel.
> 
> This can be done fairly easily if you use a boot-time uncompressing
> technique: the kernel loads the ramdisk from the floppy, which has a
> filesystem with the kernel as a file.
> 
> Then the kernel runs init, which is actually a wrapper that
> uncompresses and untars whatever fraction of stuff you needed to
> compress to fit the kernel on.  It then runs the real init (or sh or
> whatever).
> 
> Unfortunately you can't easily compress the libc, because tar and gzip
> will need it even if the init wrapper doesn't.  Depending on the size
> of things you can easily get over 300K to spare, and possibly more.

libc?  Why?  Does this have something to do with shared library code?
If so, couldn't non-shared-lib versions of those programs be used?

I was thinking along the line of the following:

 - Boot/root floppy is a lilo-d floppy with one or more kernels
 - Boot/Root floppy contains compressed tar or cpio archive of filesystem
 - Boot/Root floppy also contains /bin, /etc, and whatever is needed to do
   the following

   - LILO'd boot/root floppy is booted
   - system loads ramdisk from boot/root floppy
   - init processing deletes ramdisk copy of the tar or cpio archive
   - init processing deletes ramdisk copy of the kernel(s)
   - init processing mounts boot/root floppy on floppy
   - init processing uncompresses and unpacks floppy copy of the tar or
     cpio archive to root filesystem on ramdisk (there doesn't need to be
     a kernel image in there)
   - init processing unmounts the floppy
   - init processing does whatever further init-time setup is needed
   - init processing puts up the dinstall menu

I haven't tried to do this yet.  There may be obvious holes in this
which I've not been seeing.


Reply to: