Corrections and clarifications scattered throughout
On Tue, 2001-11-27 at 06:06, rpjday wrote:
> what you start with:
>
> RedHat/
> RPMS/
> (all your RPMs)
>
> what you finish with:
>
> dosutils/*
> images/*
> RedHat/
> RPMS/
> (all your RPMs)
> base/
> hdstg1.img
> netstg1.img
> stage2.img
The dosutils directory is not autogenerated. You need to already have
it there (if you care about it that is); the images under
dosutils/autoboot are autogenerated though.
[snip basic invocation]
> curious issues
> ------- ------
>
> 1) the buildinstall script refers to "COMPNAME=dist-7.0" and a default
> VERSION of 7.1. should this be updated to reflect 7.2? if not, what
> do they refer to?
This is only used by the internal process which hooks into our build
system for building trees. It is of no real relevance to anyone in the
outside world.
> 2) sadly, it appears that you have to run buildinstall as root, even if
> you wanted to do all this under a non-root user account. bummer.
There's lots of arbitrary loopback mounting of files within
buildinstall, which unfortunately does require root access.
> 3) buildinstall eventually calls "mk-images", which in turn calls
> "mk-images.{ARCH}" for your architecture to build the files in the
> images/ directory. does that same script also build the installer
> images under base/ ??
mk-images itself creates the installer images under base (with help from
upd-instroot)
> 4) note that you don't have to say anything about the modules you want
> to include, either in boot.img or the installer images. i'm assuming
> that this is all done automatically, since running buildinstall
> generates a slew of messages like
See mk-images.i386 (or other architectures appropriately). Searching
for MODULES works nicely :)
> Module dmx319ld not found in kernel rpm
> Module fcal not found in kernel rpm
> Module pluto not found in kernel rpm
> Module qlogicpti not found in kernel rpm
>
> i'm assuming that these are perfectly normal, right? and no cause
> for alarm.
This is because these modules are referenced from within the module-info
file but don't exist for the architecture in question. Safely
ignorable.
> so do you have any control over which modules are included? if you
> run buildinstall normally, it appears not.
See above :)
> 5) (tricky) this appears to be a bug, or at least an annoying feature,
> of buildinstall. consider the code excerpt near the top:
[snip bits of buildinstall]
> what the above is doing is giving you the freedom to copy the
> upd-instroot script into the build directory. if you do, it will be
> used for the subsequent build. why do you care? you might want
> to customize it, or (as i did) put debugging statements into it to
> see what was going on. if that script isn't there, buildinstall
> just extracts it from the anaconda-runtime RPM.
>
> the same thing is done for the mk-images script, in case you want
> to make some changes to that one. *however*, if for one reason or
> another, you make a copy of the mk-images* scripts but *not* the
> upd-instroot script, buildinstall will not use your personal copy
> of mk-images, since it will already have "cd"ed into the BUILDINSTDIR
> directory to get its own copy of upd-instroot. in short, the first "cd"
> to get a copy of upd-instroot will mess up the subsequent test to see
> if you have your own copy of mk-images.
>
> should i be annoyed by this? or should i have expected it?
> comments?
This is the expected behavior. The expected situation is that you have
an anaconda tree (rpm -ivh anaconda*.src.rpm ; rpm -bp anaconda.spec)
that you're working on and you can then work directly on these scripts
from the scripts/ directory. Invaluable when we're making major changes
to anaconda, less useful for the rest of the world probably since if you
really want to tweak anaconda yourself and get reproducible tree builds,
you should probably patch and rebuild the anaconda package and then use
that package.
Cheers,
Jeremy
