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: