Hi Bernard, On Thursday 27 September 2007 00:15, Bernard Li wrote: > On 9/26/07, Erich Focht <[EMAIL PROTECTED]> wrote: > > > in an OSCAR image created the conventional way the initrd is usually > > generated in the %post scriptlet of the RPM. This happens on the > > Okay, I think you are talking about the distro-provided initrd, but I > am talking about the SystemConfigurator generated initrd (sc-initrd*) > -- these are generated by SystemConfigurator when run with --configrd. > Sorry for not being clearer.
So you want to add the sc-initrd-* name into the systemconfig.conf? That's fine, of course. It won't help during a deployment but will help later, when sc is called again. > > master node at image creation time, inside a chroot on possibly completely > > different hardware. Therefore the existing initrd can be completely bogus. > > Re-generating it at install time gives the user or some API scripts the > > chance to adapt /etc/systemconfig/systemconfig.conf and /etc/modprobe.conf > > inside the image and get a more appropriate result. > > I am a bit confused here. As far as I know SystemConfigurator is only > called on the client after it has been imaged via SystemImager. The > image only has the distro-provided ramdisks and does not contain > ramdisks generated by SystemConfigurator (sc-initrd*). Therefore when > SystemConfigurator is called, there should be no existing sc-generated > ramdisks. Yes. > This is my understanding, unless something has changed in the code > which I am not aware of. > > Is SystemConfigurator actually used on the headnode? Not from scripts belonging to OSCAR. > BTW, I grepped for "systemconfigurator" in packages/sis/scripts/* in > my old checkout of trunk, and the script post_rpm_nochroot came up. > However, this script seems to have been removed from trunk via this > changeset: > > http://svn.oscar.openclustergroup.org/trac/oscar/changeset/6044 > > with no apparent transfer of code to the new API scripts. You might > want to take a look. I verified this, it is true. It actually throws away the per image SIS configuration option. I'd guess this was a mistake and will re-add it under the new API name. There was some time when the opkg converter didn't deal correctly with post_rpm_nochroot. Thanks for finding this! Best regards, Erich ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ sisuite-devel mailing list sisuite-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sisuite-devel
