This sorta off topic, but it's Slackware based and Sparc
inclusive, so it seems fitting for here, anyway.
I'm putting together my dual-architecture bootable CD builder.
While working on this, I've come up with some questions which
are primarily of a nature regarding how people might use it
(as opposed to deeply technical questions).
First a bit of background. In addition to being able to build
a CD which can boot from either Intel (using El Torito floppy
image and syslinux loader) or Sparc (using SILO loader), I am
also integrating a different way to initialize the system with
a special init program to handle it. The way this works is my
program is the only file in the initial ramdisk, and runs with
the name /sbin/init. It builds a ramfs, finds the CDROM, mounts
the CDROM as /ramfs/cdrom, and executes the 2nd stage of my init
program from the CDROM itself. The 2nd init runs tar to read a
tar file from the CDROM and populates /ramfs. Then it pivots
the root so /ramfs becomes / and the previous / becomes /mnt and
is then unmounted and deleted. Finally it executes the real
init from name selections just like the kernel does. There are
a few other minor details handled, but this should give the main
idea of what is going on.
The advantage I see in my approach is that I can have a much
larger quantity of data in a ram based filesystem, and do not
have to worry about pre-establishing the size of that space.
This would apply to both architectures.
However, I want to make that scheme only an optional part of the
overall bootable CD builder. I want the more traditional way to
build a bootable CD to also work, where the / files primarily
came from the initial ramdisk. To that end I am splitting the
building process into 2 major stages. The first is the stage
where the programmer collects multiple file sets (with a way to
pick which sets are used) into a master file tree, and the 2nd
stage is the actual building which transforms this tree into
the final ISO file. The idea for the split is that the first
stage will incorporate my new CD/ramfs initialization scheme
while the 2nd stage will not be dependent on it and can work
with other approaches (as long as they build the appropriate
file trees).
The question I have mostly involves the Sparc architecture and
primarily affects the programmers ease of building a custom
system to run from CDROM.
For Intel, files like the kernel image and the ramdisk image
(be it large or small) are integrated into the boot.img file
during the 2nd stage, and do not need to reside within the
CDROM in any other form (though they may for the benefit of
the end user). However, for Sparc, the flexibility of SILO
means these files are actually left on the CDROM as files, and
the silo.conf file will point to both of them by name (only
the 2nd stage boot loader needs to be referenced by blocks).
What this means is that the kernel and ramdisk images will be
handled by the programmer doing the customizing of the system
in potentially different ways. My concern is how that effects
the way I divide up the operations that integrate them between
the two building stages. For Intel, the 2nd stage always does
the handling of the kernel and ramdisk, and finds them outside
the main file trees. The programmer places those files where
expected and if she also wants a copy inside the CDROM somewhere,
she simply copies them appropriately during stage 1 configuration
(which can be a stage 1 builder component script or component
tree or tarball). The programmer may want more control over the
naming/placement of these files for Sparc, and hence may be doing
this via stage 1, even though normally stage 2 will integrate
them. What I end up with is that some work done to integrate
these files falls into stage 1 for Sparc and stage 2 for Intel.
This is a kind of inconsistency that bothers me, and I'm looking
for a way out of it.
Perhaps my assumptions are wrong. Perhaps the assumptions about
what a programmer building a CD based system will need is not
quite right.
Perhaps my new approach to initializing is so much better that
no one will seriously need to use the old way anymore, and I
could just integrate the two building stages together into one.
The catch is that my new scheme requires the 2.4 kernel in order
to get the new pivot_root() syscall (unless someone has back
patched it that I'm not aware of).
Perhaps I should just push Sparc kernel and ramdisk locations
into the 2nd stage builder and require that they be placed by
whatever 1st stage builder is being used (be that mine or some
other) in certain locations. This decreases flexibility to
the programmer.
What do you Sparc users think about all this?
Here's the organization I am currently working with for this:
In the Initial Ramdisk filesystem is this one directory and file:
sbin/
sbin/init
This is not the real init, but instead is the stage 1 initializer
for the CD system. It creates a ramfs filesystem as /ramfs and
a basic set of subdirectories within it, and searches for the
CDROM to be mounted as /ramfs/cdrom (with /ramfs/dev/cdrom being
a special device file with the appropriate major,minor numbers).
The CDROM is actually mounted via /dev/cdrom so that the kernel
records the device string that way instead of /ramfs/dev/cdrom.
This is done by making 2 special device files, one used to mount
the CDROM and one provided for the running system to reference.
Finally, /ramfs/cdinit-(arch) is executed to go to stage 2 so that
the initial ramdisk can be unmounted and deleted.
In the CD-ROM root directory are found these files and directories:
boot/boot.img
boot/boot.catalog
This is the El Torito boot image file for the Intel 386 architecture
and the catalog file produced by mkisofs. It uses syslinux as the
loader, and contains the ldlinux loader, configuration, boot message,
kernel, and the initial ramdisk.
boot/silo.conf
boot/initrd-sparc.gz
This is the SILO config file for the Sun Sparc architecture, and
The compressed initial ramdisk image referenced by silo.conf for SILO
to load with the kernel for the Sun Sparc architecture. The Intel
386 initial ramdisk is inside the boot.img file (Remember this by
reciting "Intel Inside [tm]").
boot/cdinit2-i386
boot/cdinit2-sparc
This is the stage 2 initializer for the appropriate architecture.
It runs after the stage 1 initializer in the initial ramdisk finds
and mounts the CDROM as /ramfs/cdrom. The stage 2 initializer
extracts the contents of the appropriate root-arch.tar file into
the /ramfs filesystem, pivots that filesystem to be root, deletes
the initial ramdisk, sets up the /usr symlink, then executes the
normal /sbin/init.
boot/root-i386.tar
boot/root-sparc.tar
This is the tar file read by the stage 2 initializer to populate
the ramfs root filesystem.
usr-i386 ( /usr -> cdrom/usr-i386 )
usr-sparc ( /usr -> cdrom/usr-sparc )
This is the directory targeted by a symlink named /usr. Everything
that is needed, but not in the ramfs root, is here somewhere. Other
directories normally at / or files within them may be symlinked to
one or more directories or files within this directory (maybe via
the /usr symlink).
usr-i386/etc/pre-init
usr-sparc/etc/pre-init
If this executeable exists, it is executed in its own process by the
stage 2 initializer just before executing /sbin/init. This allows
adding extra customization without having to patch and recompile
the cdinit programs. It could be a binary or a script.
usr-i386/sbin/init
usr-i386/etc/init
usr-i386/bin/init
usr-i386/bin/sh
usr-sparc/sbin/init
usr-sparc/etc/init
usr-sparc/bin/init
usr-sparc/bin/sh
Whichever file in the list for the appropriate architecture is first
found and executeable is executed by the stage 2 initializer to take
over process ID 1. This is usually the normal init program, but of
course a CD can be put together with any custom program in its place.
-- ----------------------------------------------------------------- | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | phil-nospam@ipal.net | Texas, USA | http://phil.ipal.org/ | -----------------------------------------------------------------
This archive was generated by hypermail 2b30 : Thu Sep 19 2002 - 11:00:02 PDT