Re: investigation of SYSLINUX booting problems
Bill Mitchell writes ("Re: investigation of SYSLINUX booting problems"):
> email@example.com (Ian Jackson) said:
> > [ much description of self-uncompressing ramdisk init
> > wrapper arrangement deleted - iwj ]
> > 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 *meant* the shared library code. You could make statically linked
versions of gzip and tar, but you'd probably use more space on the
duplicated code than you saved by being able to compress the rest of
> 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
This business about mounting and unmounting the floppy is silly. You
can just load the tarfile into memory you get from malloc(). See my
original description for how to do it.
Your repetition of the phrase `init processing' suggests to me that
you need to study further the way Linux starts up. I'll save you the
trouble of rooting through kernel source code by telling you that when
the kernel has initialised all the device drivers &c it creates a
process, pid 1, and causes that process to exec /sbin/init (there is
actually a list of places it will look).
> I haven't tried to do this yet. There may be obvious holes in this
> which I've not been seeing.
My description in my other message is what what emergency floppy set
actually *does*. I've used that floppy set to restore my system from
tape after disk repartitioning, so I know it works. No guesswork is