Re: [Fedora-livecd-list] LiveCD Issues

Jeremy,

Thanks for the feedback.  Couple of quick follow-up comments below...

---- Jeremy Katz <katzj(a)redhat.com&gt; wrote: 
>  On Thu, 2007-09-20 at 09:34 -0400, asmith11(a)cox.net wrote:
>  > 1) Installing to Live Image vs. Installing to System
>  > 
>  > Is there a good way (or best practice) in my kickstart %post section
>  > to determine whether I am installing to a live image vs. installing to
>  > a system (or said differently whether the installation is happening
>  > via the GUI installer vs. the livecd-creator?  We have certain
>  > operations we'd like to perform (format some large partitions, etc.)
>  > that don't really make sense for the live image but we would like
>  > installed on the real target system as part of a "real"
>  > installation.  
>  
>  Hrmm -- there's nothing at the moment.  But I can definitely see it
>  making some sense.  And being able to differentiate for pungi as well.
>  It would be easy enough to set an environment variable if that would
>  help.  I guess you could also key off of the existence
>  of /root/anaconda-ks.cfg for it being an anaconda install, but that's
>  definitely into heuristics territory 
This was basically the direction we were thinking we would end up heading.  We're
biased towards what we are calling the "real" installation because the live
image is primarily a pretty installation vehicle for us.  

>  
>  > 2) Redhat Enterprise 5 Problem
>  > 
>  > We've been able to successfully bundle RHEL5 as a live image.  Things
>  > are generally working pretty well.  We have been using LiveCD Tools
>  > 008 and 009 up till now.  When we tried to upgrade to LiveCD tools 011
>  > the images we created would no longer boot (in QEMU or via CD/DVD if
>  > burned to a disk).  The error we see at boot is the one where it says
>  > that "/dev/root" is missing and that we should create the link and
>  > then exit the shell.  This has normally been working fine.  Is this a
>  > problem with a missing kernel module?  Any ideas on how to fix this?
>  
>  Yeah, if you look in livecd-creator, you'll see that we now write out
>  things like "=ata" as the modules to use.  Which won't work for RHEL5 as
>  it doesn't have the file to do that mapping.  At the same time, I really
>  don't want to have to keep around the list of all of the pata/sata
>  modules and have to keep updating it as the list changes over time :-/.
>  Open to suggestions, though. 
I took a look at the livecd-creator script modules section that you mentioned and I
understand now why this is no longer working for RHEL5.  I think we can just modify that
section of livecd-creator to add the specific modules we'll need. 

It raises the question though, how should a livecd-creator user customize the set of
modules that they need installed (in a case like this one).  Obvious options would be:

1) livecd-creator command-line parameters (requires livecd-creator changes)

2) modify livecd-creator to taste on a case-by-case basis (yuck)

3) kickstart syntax (I don't know if this is really a valid option)

Any thoughts?

Thanks,

-Andy

>  
>  Jeremy
>  
>  --
>  Fedora-livecd-list mailing list
>  Fedora-livecd-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-livecd-list

LiveCD Issues

[Jeremy Katz]

On Thu, 2007-09-20 at 11:46 -0400, asmith11(a)cox.net wrote:
>  ---- Jeremy Katz <katzj(a)redhat.com&gt; wrote: 
>  > On Thu, 2007-09-20 at 09:34 -0400, asmith11(a)cox.net wrote:
>  > > We've been able to successfully bundle RHEL5 as a live image.  Things
>  > > are generally working pretty well.  We have been using LiveCD Tools
>  > > 008 and 009 up till now.  When we tried to upgrade to LiveCD tools 011
>  > > the images we created would no longer boot (in QEMU or via CD/DVD if
>  > > burned to a disk).  The error we see at boot is the one where it says
>  > > that "/dev/root" is missing and that we should create the link and
>  > > then exit the shell.  This has normally been working fine.  Is this a
>  > > problem with a missing kernel module?  Any ideas on how to fix this?
>  > 
>  > Yeah, if you look in livecd-creator, you'll see that we now write out
>  > things like "=ata" as the modules to use.  Which won't work for RHEL5
> as
>  > it doesn't have the file to do that mapping.  At the same time, I really
>  > don't want to have to keep around the list of all of the pata/sata
>  > modules and have to keep updating it as the list changes over time :-/.
>  > Open to suggestions, though.
>  
>  I took a look at the livecd-creator script modules section that you
>  mentioned and I understand now why this is no longer working for
>  RHEL5.  I think we can just modify that section of livecd-creator to
>  add the specific modules we'll need.  
Yeah, that definitely works as a short-term.  

>  It raises the question though, how should a livecd-creator user
>  customize the set of modules that they need installed (in a case like
>  this one).  Obvious options would be: 
Well, overall, that's one reason why things changed was so that we could
have the information encoded more in the packages being installed rather
than squirreled away in livecd-creator.

>  1) livecd-creator command-line parameters (requires livecd-creator
>  changes) 
This is pretty bad from my point of view as it leads to a live CD which
you need to know the magic command line option used if you want to
recreate it.

>  2) modify livecd-creator to taste on a case-by-case basis (yuck)
It definitely works, but yeah, definitely yuck too :)

>  3) kickstart syntax (I don't know if this is really a valid
> option) 
Could be doable, although feels like it's kind of unfortunate to have to
do as we should in most cases "just do teh right thing".  Then again,
there is the device keyword and we could just overload the use of it.
That's probably not that far from the intent with a real install,
either, where device leads to modules being loaded.

The fourth option is that you have a package to drop a file
(either /etc/mayflower.conf or another file which is sourced by
mayflower) to add modules.  In fact, in any case, this is simple enough
that I'll make it work even if it's not the "best" answer.

Jeremy