Douglas, I'm going to stirfry your email in responding
While nothing I'm about to say helps you now, here is a reiteration
of my theoretical QA plan to mitigate similar problems in the future-
A) install livecd-tools and revisor by default in a standard spin.
developer spin seems like the right place. I don't think either
will bring in many new dependencies, i.e. take up signifcant space.
B) have a dedicated QA server spinning up daily spins of (A).
These QA spins would be served via bittorrent. This server would
be f7(stable) pulling in updates via yum daily. After being
created, these spins would be booted under headless qemu,
displaying to a vnc recorded session. These boot-videos would be
available via bittorrent as well, as well as basic boot-speed
timing analysis, and logfiles from the boot.
C) have another server like (B), except which is a rawhide, updated
daily system, running git livecd-tools, doing exactly the same thing.
I'm using vmware in places of qemu. Since I only have two physical
machines to use for everything, I have one virtual machine that
handles just development of LiveCDs with Revisor and a second that's
used for testing. The nice thing is that if an RPM ever does blow up
my LiveCD creation machine, building another one (if I can ever
figure out how to get one that stays working) doesn't take much
time. Of course that LiveCD with Revisor on it that I asked about a
week ago would make things very cool.
Starting in the middle of the process, what I do is:
* boot the last livecd image
* based on what I find in testing, adjust the kickstart file and my
custom rpm. I'll continue the testing/tweaking project until I've
made enough changes that there's a significant divergance between the
original and the next rev
* create another livecd
* wash rinse repeat
FWIW, I haven't noticed any similar problems lately, but I use
livecd-creator, and not revisor, which apparently utilizes a
significantly forked version of livecd-creator.
[snip]
Certainly F8 doesn't exist yet, so one must not have the
expectation that it can be used for a stable development system.
Revisor blows up randomly. When it blows up it takes far too long to
get a system that works. It usually entails creating a kickstart all
over again to get one that creates LiveCDs. Each rev seems to bring
new quirks such as buttons that do nothing but blow up Revisor.
Fedora 8 is currently in Beta 2; usually a stage where a major button
causes everything to blow up.
As far as livecd-creator... after I posted my email I realized that
if no one has any ideas after three days on the MBR problem, they're
probably not going to have suggestions on a broader question like how
to make Revisor work on an ongoing basis in a reasonable amount of
time. If I'm going to have a shot at getting this put to bed before
my next big paying project comes in (and causes me to shelf this for
somewhere between 2 months and the end of time), I'm going to have to
switch to another way of getting there. Strangely... google had just
gotten me backed into livecd-creator when your email popped in. I'm
going to try that. If I ever get around to creating that LiveCD for
mastering LiveCDs, it'll probably be livecd-creator.
Tim
--
Fedora-livecd-list mailing list
Fedora-livecd-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
