[PATCH]: Fix --base-on

[Chris Lalancette]

All,
     I'm working with the latest version of livecd-creator available in rawhide,
which is livecd-tools-012-1.fc8.  I noticed a bug when using the --base-on
option; basically, it is testing for the existence of the squashfs.img, but that
path can't possibly exist until the ISO has been loopback mounted.  The attached
patch moves the mounting of the ISO before the check to see if the squashfs
filesystem exists.  With this patch, I am able to successfully use the --base-on
option.

Signed-off-by: Chris Lalancette <clalance(a)redhat.com&gt;

[Douglas McClendon]

Chris Lalancette wrote:
>  All,
>       I'm working with the latest version of livecd-creator available in rawhide,
>  which is livecd-tools-012-1.fc8.  I noticed a bug when using the --base-on
>  option; basically, it is testing for the existence of the squashfs.img, but that
>  path can't possibly exist until the ISO has been loopback mounted.  The attached
>  patch moves the mounting of the ISO before the check to see if the squashfs
>  filesystem exists.  With this patch, I am able to successfully use the --base-on
>  option. 
TODO: since livecd-tools was added to the dev-spin, it seems like the 
most obvious minimal QA that should be done is to boot an RC of the 
dev-livecd, mount some tmpspace, and then run livecd-creator (with 
--tmpdir) with --base-on pointing at /dev/live, to see if you can easily 
perform some minimal respin.  E.g. perhaps just kickstart that adds a 
couple new packages, maybe adds a 3rd party repo, and changes the 
isolinux splash.  And as a second QA test, respin itself without the 
base-on option.

And I would love it if the dev-livecd could include qemu (space 
impact?), so that the resulting livecd's could be virtually test booted 
trivially.

-dmc

[Jeremy Katz]

On Tue, 2007-10-23 at 17:58 -0500, Douglas McClendon wrote:
>  TODO: since livecd-tools was added to the dev-spin, it seems like the
>
>  most obvious minimal QA that should be done is to boot an RC of the 
>  dev-livecd, mount some tmpspace, and then run livecd-creator (with 
>  --tmpdir) with --base-on pointing at /dev/live, to see if you can easily 
>  perform some minimal respin.  E.g. perhaps just kickstart that adds a 
>  couple new packages, maybe adds a 3rd party repo, and changes the 
>  isolinux splash.  And as a second QA test, respin itself without the 
>  base-on option. 
Accepting patches :-)   I think the biggest thing is being able to
(easily) hook in something automated to run as part of the live boot.
While it's easy enough to add something to run anaconda as Rahul asked
about, being able to run anything generically is a bit trickier.

>  And I would love it if the dev-livecd could include qemu (space 
>  impact?), so that the resulting livecd's could be virtually test booted 
>  trivially. 
The developer config includes the virtualization group and thus should
have qemu and kvm as well as virt-manager

Jeremy

[Douglas McClendon]

Jeremy Katz wrote:
>  On Tue, 2007-10-23 at 17:58 -0500, Douglas McClendon wrote:
> > TODO: since livecd-tools was added to the dev-spin, it seems like the 
> > most obvious minimal QA that should be done is to boot an RC of the 
> > dev-livecd, mount some tmpspace, and then run livecd-creator (with 
> > --tmpdir) with --base-on pointing at /dev/live, to see if you can easily 
> > perform some minimal respin.  E.g. perhaps just kickstart that adds a 
> > couple new packages, maybe adds a 3rd party repo, and changes the 
> > isolinux splash.  And as a second QA test, respin itself without the 
> > base-on option.
>  
>  Accepting patches :-)   I think the biggest thing is being able to
>  (easily) hook in something automated to run as part of the live boot.
>  While it's easy enough to add something to run anaconda as Rahul asked
>  about, being able to run anything generically is a bit trickier. 
Hmm.  I wasn't talking about any patches in the above, unless of course 
the QA shows that something doesn't work.

As for what you said, and Rahul- It sounded like he wanted something 
akin to the traditional installer.  I.e. anaconda fullscreen with no 
windowmanager or desktop.  Can you give an example or two of things that 
would be supported in the generic case that you speak of?  Are we 
talking something crazy like a kernel cmdline of

"autorun='firefox file:///usr/share/doc/fedora/releasenotes'"

I'm just don't quite understand what you were getting at.

>  
> > And I would love it if the dev-livecd could include qemu (space 
> > impact?), so that the resulting livecd's could be virtually test booted 
> > trivially.
>  
>  The developer config includes the virtualization group and thus should
>  have qemu and kvm as well as virt-manager 
cool.  I was lazy and just did a grep qemu.

-dmc

[Jeremy Katz]

On Tue, 2007-10-23 at 20:14 -0500, Douglas McClendon wrote:
>  Jeremy Katz wrote:
>  > On Tue, 2007-10-23 at 17:58 -0500, Douglas McClendon wrote:
>  >> TODO: since livecd-tools was added to the dev-spin, it seems like the 
>  >> most obvious minimal QA that should be done is to boot an RC of the 
>  >> dev-livecd, mount some tmpspace, and then run livecd-creator (with 
>  >> --tmpdir) with --base-on pointing at /dev/live, to see if you can easily 
>  >> perform some minimal respin.  E.g. perhaps just kickstart that adds a 
>  >> couple new packages, maybe adds a 3rd party repo, and changes the 
>  >> isolinux splash.  And as a second QA test, respin itself without the 
>  >> base-on option.
>  > 
>  > Accepting patches :-)   I think the biggest thing is being able to
>  > (easily) hook in something automated to run as part of the live boot.
>  > While it's easy enough to add something to run anaconda as Rahul asked
>  > about, being able to run anything generically is a bit trickier.
>  
>  Hmm.  I wasn't talking about any patches in the above, unless of course 
>  the QA shows that something doesn't work.
>
>  As for what you said, and Rahul- It sounded like he wanted something 
>  akin to the traditional installer.  I.e. anaconda fullscreen with no 
>  windowmanager or desktop.  
Right -- the two are different.  The main connection is "args coming
from the command line".  And I'm trying something now which would do
Rahul's request.  If it works, it might be worth having available and
undocumented.

>   Can you give an example or two of things that 
>  would be supported in the generic case that you speak of?  Are we 
>  talking something crazy like a kernel cmdline of 
>  "autorun='firefox file:///usr/share/doc/fedora/releasenotes'" 
Something like that.  Or perhaps to run an arbitrary dogtail script
after the user logs in.  Yes, really crazy.  But if we want to get to
where the QA is being done in an automated fashion, crazy is probably
the only way to get there :-/

Jeremy

[Douglas McClendon]

Jeremy Katz wrote:
>  On Tue, 2007-10-23 at 20:14 -0500, Douglas McClendon wrote:
> > Jeremy Katz wrote: 
> > As for what you said, and Rahul- It sounded like he wanted
> something 
> > akin to the traditional installer.  I.e. anaconda fullscreen with no 
> > windowmanager or desktop. 
>  
>  Right -- the two are different.  The main connection is "args coming
>  from the command line".  And I'm trying something now which would do
>  Rahul's request.  If it works, it might be worth having available and
>  undocumented.
>  
> >  Can you give an example or two of things that 
> > would be supported in the generic case that you speak of?  Are we 
> > talking something crazy like a kernel cmdline of 
> > "autorun='firefox file:///usr/share/doc/fedora/releasenotes'"
>  
>  Something like that.  Or perhaps to run an arbitrary dogtail script
>  after the user logs in.  Yes, really crazy.  But if we want to get to
>  where the QA is being done in an automated fashion, crazy is probably
>  the only way to get there :-/ 
Thanks, now it is clear.  It all sounds good.

Keep in mind the coolness that is-

a) use isodump to extract the kernel, initrd, and syslinux.cfg from a 
recently spun livecd iso

b) grab the default append string from the syslinux.cfg

c) add your dogtail invocation args to that append string

d) launch qemu with -kernel -initrd -append, and -vnc, and using vncrec 
to record the session

e) post the vnc video transcoded to a popular format (mpg, swf) to a 
website.  (for times when an optional visual inspection pass of dogtail 
test results will be useful in addition to any completely automated 
pass/fail test scripts)

-dmc

[Jeremy Katz]

On Tue, 2007-10-23 at 17:45 -0400, Chris Lalancette wrote:
>       I'm working with the latest version of livecd-creator
> available in rawhide,
>  which is livecd-tools-012-1.fc8.  I noticed a bug when using the --base-on
>  option; basically, it is testing for the existence of the squashfs.img, but that
>  path can't possibly exist until the ISO has been loopback mounted.  The attached
>  patch moves the mounting of the ISO before the check to see if the squashfs
>  filesystem exists.  With this patch, I am able to successfully use the --base-on
>  option. 
Thanks for the patch; applied and will be in 013 (which I'm hoping will
be the final build for F8 and that I can build tomorrow)

Jeremy