> It's not clear to me _when_ this program is used. If you package it as
> an rpm and installed on the target system, then Anaconda can run it from
> there, but should chroot() to do so.
Reipl is called after anaconda has finished installing the target system
but before a reboot is performed.
> If it might be used during the ordinary use of a Linux guest (as it
> might be, if you have a recovery disk to IPL, repair something, then IPL
> that something in the same VM), then packaging it and installing to
> /usr/sbin or /usr/bin is sensible. If it's only to be used at install
> time, then you need to consider how it gets into the install image.
> Someone else might address that, I'm not very good with that snake either.
Reipl can be used duing install and it can be run at any time by a system
adminstrator. It doesn't cause a reboot itself. It only tells VM where
to reboot from if it ever were to reboot.
> /sbin and /bin should be used for executables required before /usr gets
> mounted. See www.pathname.com where the FHS might be found.
Ah, thanks. I did not consider that possibility. But it shouldn't
affect this patch as Reipl lives in the stage 2 image and not on the
target's system for the installation case.
> I could not see where reipl executes any external program (but my python
> is strictly limited). If it's not executing other programs, PATH is
> unimportant.
> Did you get the idea I'm writing this backwards? You should have:-)
Well, sys.path also controls where Python modules are looked for when
doing an import.
Reipl is a Python module that also contains a main.
Anaconda only needs to call one function from Reipl. And then notify loader
how it went.
Mark
Common Information Model/Web-Based Enterprise Management at http://www.openpegasus.org/
Take a look at the Linux Omni Printer Driver Framework at http://omniprint.sourceforge.net/
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
