pre-install scripts and syslinux

[David Straub]

Hi,

I would like to ask about two small issues regarding the livecd-tools
package.  First, I noticed that kickstart pre-install scripts are not supported
by the livecd-tools package.  I personally find pre-install scripts to be
useful.  Is there a specific reason for it being excluded that I did not see?

A second minor concern: syslinux is added as a required package for all x86
images.  I have been using the scripts to create rawhide images for
embedded-ish systems where I would like to save as much space as possible on
the image (while still using Fedora, with a minimal number of workarounds). 
Would it be possible/practical to add syslinux--and possibly the other boot
loaders--to the dependencies of livecd-tools to use the system's files, and
remove it from the image's required packages?

I have implemented changes to solve both of these issues for myself and can
send the patches for either if they can be addressed.  If not, it's no problem;
the livecd-tools package saves a lot of time and makes testing more convenient
for me either way.

Thanks,
  Dave

[Jeremy Katz]

On Wed, 2008-11-12 at 19:04 -0500, David Straub wrote:
> I would like to ask about two small issues regarding the livecd-tools
> package.  First, I noticed that kickstart pre-install scripts are not supported
> by the livecd-tools package.  I personally find pre-install scripts to be
> useful.  Is there a specific reason for it being excluded that I did not see?

The main reason has been that there are ... interesting questions about
the environment it should run in.  What are you using them for and maybe
that's enough to talk me into it :-)
> A second minor concern: syslinux is added as a required package for all x86
> images.  I have been using the scripts to create rawhide images for
> embedded-ish systems where I would like to save as much space as possible on
> the image (while still using Fedora, with a minimal number of workarounds). 
> Would it be possible/practical to add syslinux--and possibly the other boot
> loaders--to the dependencies of livecd-tools to use the system's files, and
> remove it from the image's required packages?

The reason you want to use it from within the image is in case you need
a newer version of syslinux for certain functionality.  That then lets
you build images taking advantage of new system features without
requiring updates to your builder.

Jeremy

[David Straub]

On Wed, Nov 12, 2008 10:34 PM Jeremy Katz  wrote:
> The main reason has been that there are ... interesting questions about
> the environment it should run in.  What are you using them for and maybe
> that's enough to talk me into it :-)

Since pykickstart already handles pre-install scripts, I pretty much just
copied the imgcreate functions that deal with the post-install scripts for
consistency.  I suppose this is the important function:
> def __run_pre_scripts(self):
>     for s in kickstart.get_pre_scripts(self.ks):
>         (fd, path) = tempfile.mkstemp(prefix = "ks-script-",
>                                       dir = "/tmp")
>
>         os.write(fd, s.script)
>         os.close(fd)
>         os.chmod(path, 0700)
>
>         env = self._get_pre_scripts_env(s.inChroot)
>
>         env["INSTALL_ROOT"] = self._instroot
>         preexec = None
>         script = path
>
>         try:
>             subprocess.call([s.interp, script],
>                             preexec_fn = preexec, env = env)
>         except OSError, (err, msg):
>             raise CreatorError("Failed to execute %%pre script "
>                                "with '%s' : %s" % (s.interp, msg))
>         finally:
>             os.unlink(path)

I have this called as the first action in the install function, just before
yum runs.  I think the only changes I made to this from the post function are
that I removed the chroot conditional (since %pre is always --nochroot), and
that it writes the temporary script files to the system's /tmp rather than the
image's /tmp (since it doesn't exist at this point).

What were the concerns regarding the environment?  All I needed was the
ability to get at a shell in the install image before yum is called, which is
all that does.

Thanks,
  Dave

[Jeremy Katz]

On Thu, 2008-11-13 at 09:15 -0500, David Straub wrote:
> On Wed, Nov 12, 2008 10:34 PM Jeremy Katz  wrote:
> > The main reason has been that there are ... interesting questions about
> > the environment it should run in.  What are you using them for and maybe
> > that's enough to talk me into it :-)
>
> Since pykickstart already handles pre-install scripts, I pretty much just
> copied the imgcreate functions that deal with the post-install scripts for
> consistency.  I suppose this is the important function:

[snip]
> I have this called as the first action in the install function, just before
> yum runs.  I think the only changes I made to this from the post function are
> that I removed the chroot conditional (since %pre is always --nochroot), and
> that it writes the temporary script files to the system's /tmp rather than the
> image's /tmp (since it doesn't exist at this point).
>
> What were the concerns regarding the environment?  All I needed was the
> ability to get at a shell in the install image before yum is called, which is
> all that does.

Yeah, the code is clearly trivial.  But if we're to correspond with the
other case that %pre is used (the installer), then we need to run the
script before we get any install roots or similar created.  At which
point, the question is what are you trying to accomplish with the %pre
and is there a better way?

For the installer case, the "typical" use of pre is either doing more
complicated formatting or doing some sort of system determination and
then writing out pieces of the ks.cfg to later be %include'd

Jeremy

[David Straub]

On Thu, Nov 13, 2008 10:37 AM Jeremy Katz  wrote:
> Yeah, the code is clearly trivial.  But if we're to correspond with the
> other case that %pre is used (the installer), then we need to run the
> script before we get any install roots or similar created.  At which
> point, the question is what are you trying to accomplish with the %pre
> and is there a better way?

Sorry, I probably should have mentioned that first to explain the change.  It
was intentional ... but now I see where concerns would arise regarding the %pre
environment.

What I am trying to accomplish is essentially what partition directives do in a
"real" install.  If I recall correctly, livecd-tools only acknowledges the root
partition.  I used %pre to create disk images and mount them over points in the
install directory so I could keep the main image's size low.  Then while
running on a system, the main image (a few MB) is loaded into memory and the
non-essential images are mounted from a slower medium if needed.  (I am running
some "special" systems.)

I know this isn't exactly the intended purpose of livecd-tools, but
nevertheless, I thought it would be more acceptable to implement an
install-root-aware %pre section rather than trying to have partition directives
create disk images.  I am probably the only person on Earth who uses the
package for this purpose, so perhaps I should just keep my own local fork of
the scripts if compatibility with the installer is important.  (In this case I
think I will create disk images for partition directives.)

As for the question of a better way: If there is one, I don't know of it.  I am
certainly open to suggestions.

Thanks,
  Dave

[Jeremy Katz]

On Thu, 2008-11-13 at 12:30 -0500, David Straub wrote:
> On Thu, Nov 13, 2008 10:37 AM Jeremy Katz  wrote:
> > Yeah, the code is clearly trivial.  But if we're to correspond with the
> > other case that %pre is used (the installer), then we need to run the
> > script before we get any install roots or similar created.  At which
> > point, the question is what are you trying to accomplish with the %pre
> > and is there a better way?
>
> Sorry, I probably should have mentioned that first to explain the change.  It
> was intentional ... but now I see where concerns would arise regarding the %pre
> environment.
>
> What I am trying to accomplish is essentially what partition directives do in a
> "real" install.  If I recall correctly, livecd-tools only acknowledges the root
> partition.  I used %pre to create disk images and mount them over points in the
> install directory so I could keep the main image's size low.  Then while
> running on a system, the main image (a few MB) is loaded into memory and the
> non-essential images are mounted from a slower medium if needed.  (I am running
> some "special" systems.)
>
> I know this isn't exactly the intended purpose of livecd-tools, but
> nevertheless, I thought it would be more acceptable to implement an
> install-root-aware %pre section rather than trying to have partition directives
> create disk images.  I am probably the only person on Earth who uses the
> package for this purpose, so perhaps I should just keep my own local fork of
> the scripts if compatibility with the installer is important.  (In this case I
> think I will create disk images for partition directives.)
>
> As for the question of a better way: If there is one, I don't know of it.  I am
> certainly open to suggestions.

It sounds like for what you're doing, some of the functionality in the
appliance-creator tool (should be in some of the thincrust.net related
packages) will give you exactly what you're looking for.  It already
uses directives in the ks.cfg for setting up partitions and then it's
using the exact same backend (imgcreate) as livecd-creator

Jeremy

Jeremy Katz wrote:
> It sounds like for what you're doing, some of the functionality in the
> appliance-creator tool (should be in some of the thincrust.net related
> packages) will give you exactly what you're looking for.  It already
> uses directives in the ks.cfg for setting up partitions and then it's
> using the exact same backend (imgcreate) as livecd-creator

yeah, that's appliance-creator use-case and appliance-tools RPM is in Fedora 10 and 9 now:
yum install appliance-tools
and look at docs and examples on thincrust.net