Re: boot-floppies package
On Fri, 10 Apr 1998, Dale Scheetz wrote:
[ snip ]
: > Furthermore, it might become necessary to change the available modules
: > (I honestly don't know whether this is the case), and I don't believe
: > the rescue disk has device files for ESDI disks. They are /dev/ed[ab],
: > correct? Vincent Renardias says the 1.3 boot disks support MCA (they
: > do) and ESDI (I never found /dev/ed[ab] devices). No Debian boot disk
: > supports IBM MCA/SCSI afaik.
: >
: The SCSI drivers are usually "built-in" to the kernel, so this is just
: another kernel issue.
Yes, you're correct. I've built a kernel that works fine, and as you
mentioned if I unpack the root fs I could add the device files (some of
this is becoming more clear as I go on)
: > Finally, I'd really like to *know* how to build these things! Why is it
: > so opaque?
:
: Building the root file system is a non-trivial problem. The boot-floppies
: package builds everything that you find in a disks-i386 directory, so it
: is a bit complex.
:
: The cryptic instructions that you indicated previously are an indication
: of the place to tailor the package to your system. If memory serves, there
: are two paths defined in the top of the make file. One is the path to the
: kernel image (note: not a kernel package...I think), while the other is
: the path to your archive (used to built the root fs)
Well, looking at the Makefile, there is a directive for the archive
base. I have a local mirror mounted via NFS, so I specified that. No
problem.
Further perusal of the Makefile reveals that it is indeed looking for a
kernel-image deb ... aren't the kernel-image-<version> files built with
kernel-package? I thought they were ...
At any rate, if I run ``make'' without modifying the Makefile, I end up
with a set of floppy images. However, if I change the ``kernel''
definition to point at my own kernel-image deb, make bombs out with "No
rule to make target `kernel-image-2.0.33_2.0.33-6.deb', needed by
`linux'. Stop" which indicates to me that I don't have a clue what's
happening here.
: Also, I don't believe that there are any modules installed on the root fs
: of the rescue disk. It is assumed that any other drivers will be installed
: from the drivers disk. This disk just contains a tarball of the modules
: directories.
Indeed. That was my motivation for using the boot floppies script in
the first place: if I roll a new kernel, with a different set of
modules, and then want that to be usable for others I need to distribute
the rescue disk *and* the drivers disk, right? I figured I would use
the tool provided for the job rather than doing it all by hand. Perhaps
this was an error.
: For my last custom CD I rebuilt the rescue and drivers disks to use the
: 2.0.33 kernel. This was simply a matter of replacing the drivers disk
: tarball with one built from the 2.0.33 kernel modules directories, and
: replacing the kernel image on the rescue floppy with the kernel image from
: the 2.0.33 kernel. I did both of these things to the image files
: (resc1440.bin, resc1200.bin, drv1440.bin, and drv1200.bin) which could
: then be used by the installer to build rescue and drivers disks.
This is more or less the functionality I'm looking for. Are there
compatibility issues with different kernel versions vs. the "base" disks
themselves?
: I don't see where you gain any needed functionality by doing this job with
: the boot-floppies package. In addition, you stand the chance of building
: an unusable root file system if the archive you build it from is different
: from the one used to build the original. As you don't need anything
: changed in the root fs (as far as I can tell) why take the chance of
: making it non-functional?
I don't understand this part. Could you explain this a bit more, if you
have time? Private email is fine ... I feel terribly stupid but I just
don't quite get why the filesystem would be "unusable"
Having said that, you are probably correct as far as the usefulness of
boot-floppies for this project. I'm probably trying to kill a gnat with
a shotgun ...
Thanks for your time :)
--
Nathan Norman
MidcoNet - 410 South Phillips Avenue - Sioux Falls, SD 57104
mailto://finn@midco.net http://www.midco.net
finger finn@kepler.midco.net for PGP Key: (0xA33B86E9)
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: