1:05 p.m.
Virt-p2v is a physical-to-virtual migration tool, for turning physical
computers into virtual machines running under some virtualization
environment like Xen.
The tool is packaged as a live CD, based on a Fedora 8 distribution, and
using livecd-creator to build the ISO.
Main page: http://et.redhat.com/~rjones/virt-p2v/
Source repo: http://hg.et.redhat.com/virt/applications/virt-p2v--devel
I'm posting here to see if anyone has any comments about the way I did
this live CD. The kickstart script uses a rather complex %post section,
which adds a few files to the filesystem, instead of building RPMs or
modifying existing RPMs.
I've also investigated how to attach stuff to the end of the ISO image,
and the way I've come up with allows me to update an ISO with a new
script quite easily, and much more quickly than waiting for
livecd-creator to rerun. This great (a) for rapid development and (b)
to send new updates to users without forcing them to download another
170 MB ISO.
I'd like to package this for Fedora. Obviously I don't want to package
the binary live CD, but instead package the kickstart file and some
tools to allow people to easily build custom live CDs. If anyone has
any ideas or examples of this I'd be interested to hear.
Thanks,
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
4:21 p.m.
On Mon, 2008-02-04 at 19:05 +0000, Richard W.M. Jones wrote:
I'm posting here to see if anyone has any comments about the way
I did
this live CD. The kickstart script uses a rather complex %post section,
which adds a few files to the filesystem, instead of building RPMs or
modifying existing RPMs.
From a maintainability point of view, you're going to be happier
in the
long run if you actually package up things into RPMs as opposed to just
concatenating piles of scripts. I've already gotten pretty frustrated
with just the initscript we're using in the desktop case on a few
occasions.
I've also investigated how to attach stuff to the end of the ISO
image,
and the way I've come up with allows me to update an ISO with a new
script quite easily, and much more quickly than waiting for
livecd-creator to rerun. This great (a) for rapid development and (b)
to send new updates to users without forcing them to download another
170 MB ISO.
Ewwww :)
Jeremy
6:37 p.m.
As a not-quite-counter argument, I've found that if each change is small
(e.g. three sed commands to tweak a config), a longer kickstart can make
a lot of sense. Beyond short stuff, I will agree completely with
Jeremy. RPMs are not too hard to pull off if you have a little patience
on the first one. Guru labs has a nice tutorial you can google (the
examples are google-able, too ... they just arn't in the same place)
On embedding stuff in the kickstart, one suggestion. Use some sort of
really really obvious delimiter and extra white space between each chunk
(see the example below). I've got a kickstart that tweaks a bunch of
odds & ends in %post and this approached has saved my sanity and made
maintenance and improvement much easier.
Tim Wood
##############################
#
# tweak the config for foo
[some lines]
##############################
#
# copy the files for bar
[some lines]
Jeremy Katz wrote:
On Mon, 2008-02-04 at 19:05 +0000, Richard W.M. Jones wrote:
> I'm posting here to see if anyone has any comments about the way I did
> this live CD. The kickstart script uses a rather complex %post section,
> which adds a few files to the filesystem, instead of building RPMs or
> modifying existing RPMs.
>
>From a maintainability point of view, you're going to be happier in the
long run if you actually package up things into RPMs as opposed to just
concatenating piles of scripts. I've already gotten pretty frustrated
with just the initscript we're using in the desktop case on a few
occasions.
> I've also investigated how to attach stuff to the end of the ISO image,
> and the way I've come up with allows me to update an ISO with a new
> script quite easily, and much more quickly than waiting for
> livecd-creator to rerun. This great (a) for rapid development and (b)
> to send new updates to users without forcing them to download another
> 170 MB ISO.
>
Ewwww :)
Jeremy
--
Fedora-livecd-list mailing list
Fedora-livecd-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-livecd-list
--
_________________________________
Tim Wood, CLP, RHCT
719.338.7484 (tel)
The Data Wranglers
Web, Database & more since since 1994
www.datawranglers.com
4:22 a.m.
Jeremy Katz wrote:
On Mon, 2008-02-04 at 19:05 +0000, Richard W.M. Jones wrote:
> I'm posting here to see if anyone has any comments about the way I did
> this live CD. The kickstart script uses a rather complex %post section,
> which adds a few files to the filesystem, instead of building RPMs or
> modifying existing RPMs.
>From a maintainability point of view, you're going to be happier in the
long run if you actually package up things into RPMs as opposed to just
concatenating piles of scripts. I've already gotten pretty frustrated
with just the initscript we're using in the desktop case on a few
occasions.
So there are two genuine issues with using RPMs:
(1) I need to replace existing files -- in particular I need a new
/etc/inittab. AIUI to do this with RPMs would involve building a custom
'initscripts' RPM and maintaining it, but let me know if I've got that
wrong.
(2) I'd like users to be able to download the source tarball and do:
./configure
make
to build an ISO. However the intermediate step -- building RPMs --
requires a full RPM build root inside the user's home directory, so
they'd need to set that up and create the ~/.rpmmacros file, and specify
where it is to ./configure. Again, that's AIUI, please correct me if
I'm wrong.
> I've also investigated how to attach stuff to the end of the
ISO image,
> and the way I've come up with allows me to update an ISO with a new
> script quite easily, and much more quickly than waiting for
> livecd-creator to rerun. This great (a) for rapid development and (b)
> to send new updates to users without forcing them to download another
> 170 MB ISO.
Ewwww :)
OK funny, but there's a genuine reason for doing this.
P2V is extremely difficult to test; I'd like to compare it to debugging
software in outer space. In all cases where someone has reported a bug
to me I've had no access to the hardware, and no way to build comparable
hardware at home (often it's because they're using some oddball SCSI
controller or RAID array). I'm relying on a third party to give me as
many details as possible. I then run the program through on paper to
see if there are any scenarios which would give rise to the same bug. I
then make a small change to the script, and send them another ISO to test.
The problem is that it takes an hour and a half to upload a 170MB ISO,
and another 15 minutes for the third party to download it.
The only change may be a couple of lines in a 1,000 line script which I
could send to them by email in seconds.
ISO attachments allow much more interactive testing.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
9:59 a.m.
On Tue, 2008-02-05 at 10:22 +0000, Richard W.M. Jones wrote:
Jeremy Katz wrote:
> On Mon, 2008-02-04 at 19:05 +0000, Richard W.M. Jones wrote:
>> I'm posting here to see if anyone has any comments about the way I did
>> this live CD. The kickstart script uses a rather complex %post section,
>> which adds a few files to the filesystem, instead of building RPMs or
>> modifying existing RPMs.
>
>>From a maintainability point of view, you're going to be happier in the
> long run if you actually package up things into RPMs as opposed to just
> concatenating piles of scripts. I've already gotten pretty frustrated
> with just the initscript we're using in the desktop case on a few
> occasions.
So there are two genuine issues with using RPMs:
(1) I need to replace existing files -- in particular I need a new
/etc/inittab. AIUI to do this with RPMs would involve building a custom
'initscripts' RPM and maintaining it, but let me know if I've got that
wrong.
An entirely new inittab seems... overkill. Is an initscript to run your
functionality not good enough?
(2) I'd like users to be able to download the source tarball and
do:
./configure
make
to build an ISO. However the intermediate step -- building RPMs --
requires a full RPM build root inside the user's home directory, so
they'd need to set that up and create the ~/.rpmmacros file, and specify
where it is to ./configure. Again, that's AIUI, please correct me if
I'm wrong.
--define _builddir, etc on the rpmbuild command line works. And you can
then put it under a mktemp'd directory.
>> I've also investigated how to attach stuff to the end of
the ISO image,
>> and the way I've come up with allows me to update an ISO with a new
>> script quite easily, and much more quickly than waiting for
>> livecd-creator to rerun. This great (a) for rapid development and (b)
>> to send new updates to users without forcing them to download another
>> 170 MB ISO.
>
> Ewwww :)
OK funny, but there's a genuine reason for doing this.
Sure, but it's going to be pretty fragile and I know I'd rather have
something more dependable. Why not just use something like xdelta
between isos? A little more time-consuming to create, but I suspect
that time difference is already made up with the time you spent writing
the ocaml script :-)
Jeremy
10:51 a.m.
Jeremy Katz wrote:
An entirely new inittab seems... overkill. Is an initscript to run
your
functionality not good enough?
No, I used to do it like that, and it was problematic.
This was many months ago so I'm a bit vague on the exact details but it
would have been something to do with either getting stdin/stdout to the
tty or having /sbin/init unexpectedly put up a prompt during or after my
initscript running.
The current method (modifying inittab) works well anyway.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
England and Wales under Company Registration No. 03798903
5933
days inactive
5934
days old
livecd@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Jeremy Katz -
Richard W.M. Jones -
Tim Wood