On Thursday 07 February 2008 09:58:52 am Cris Rhea wrote:
> On Thu, Feb 07, 2008 at 09:24:53AM -0800, dwight at
supercomputer.org wrote:
> > Here's an obscure bit of trivia. Why is it not one, not two, not
> > four, but three syncs?
>
> Because the system will have done the first sync by the time you
> finished typing the other two.
What if you're a fast typer? As in using an alias or shell function?
In over 30 years of dealing with *NIX, I've never met anyone
who could give an empirical answer (though many sound reasonable),
or who would (note I didn't say "could") show via the code as to
why it's three syncs, not two, or four+.
IMHO, it's lore based upon actual experience, because it has
matched my experience as well. Even with modern Linux kernels
and very slow IO devices (though the Linux kernel is certainly
far better in this regard).
Anyway, pardon the digression. Hopefully it was amusing.
> Yup... perhaps anaconda is getting confused by the number of
> "onpart" file systems I'm defining or something equally as
> bizarre.
I'm surprised to hear that anaconda isn't handling the onpart
directive correctly, with a pre-existing partition table. I would
think that more people would see it. One has to wonder if
anaconda's defaults are somehow kicking in and getting in the way?
> How does one build a minstg2.img file? Can I just change *that*
> one file or do I also have to change more (i.e., doesn't Anaconda
> call all sorts of Python libs located elsewhere)?
Well, since no one else is answering, I'll supply what I know
about it. If someone with more expertise in this area cares
to comment or correct, please do so. It would be appreciated.
>From what I've grokked from looking at the images and source
code, the first starting point would be the (say) PXE boot
initrd that you've set up, which came from the CD/DVD image
under the images/pxeboot directory.
If you unroll the initrd image, say via:
mkdir root; cd root; zcat .../initrd.img | cpio -iv
then you'll see a few things of interest. The first is that
there's not much there. Mostly it's just /sbin/init, /sbin/loader
and several symlinks to the latter. I assume that init calls
loader directly, as strings(1) explicitly shows "/sbin/loader".
The loader program appears to come from the loader2 directory
in the anaconda source code package itself. This is the next thing
that you want to look at, and it's full of all sorts of goodies.
Just grab the anaconda source rpm, install it, build
it via `rpmbuild -bp` and you'll have the source code.
One interesting thing, as per your question, is that it loads
in a second image, the minstg2 image. Presumably this is where
anaconda is kept, as /sbin/loader will fork(2)/exec(2) anaconda.
Now here's an interesting point. The loader code does a
waitpid(2) after the fork(2) without closing any file descriptors.
So, if a disk has somehow been opened, then the child process
(anaconda) won't be able to do a final close on the device.
I didn't see anything obvious, but some of that code appears to
call kudzu-related functions(!), and I have to wonder if something
there is keeping any devices open in the parent process.
To muck with the minstg2 image, you need to be running on a
squashfs-capable kernel. Here's a link:
http://squashfs.sourceforge.net/
With that, you should be able to mount up the minstg2 image
on a loopback device and play around with it.
Alternatively, if you look at the loader source code, you'll
see that it just expects to find /usr/bin/anaconda, so I would
think that you could keep it all on one single initrd image.
Note that the minstg2 image is 31 MB, and there used to be
a problem with loading large initrd images. But that doesn't
seem to be the case anymore.
I too am a little surprised that this isn't documented better.
Would there be any interest in a Wiki page on this? It might
help getting anaconda bugs fixed faster, if people knew what to do.
-dwight-
_______________________________________________
Kickstart-list mailing list
Kickstart-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/kickstart-list
