No. I was spammed w/ the end-of-the quarter work and am picking this
back up now.
So, the options to get where we need to go are:
* RHEL 5.x w/ JBoss Developer Studio (JBDS) (This would best, but
I don't think RHEL 5 can do LiveCD + Persistence. JBDS includes
license for RHEL 5.x)
* F8 w/ JBoss Tools (Free solution for the community at large, but
much more work for us.)
* F8 w/ JBDS (Easiest path, but the OS is not the same one they
are going to deploy on, but close enough?)
Which one of the combinations or all of them can we pull off? Can we
get RHEL 5.x to do Live CD/DVD + Persistence? What do you think?
Another question is, how do we update/patch JBDS if we have a read-only
Live CD image? Can we apply the updates to the "persistence" part of
the thumb drive or are are we going to have to spin another LIve CD
image?
Q: Why do we need to do this? A: Too many Java developers are using
Windoz to develop on and then deploying on Linux/Solaris/HPUX.... Given
that we have an Open Source OS, JVM, Application Server, DB, and
Development Environment, we can give them a really exciting "cool" way
to get their whole development environment on a thumb drive for very
little to no cost. That way their development environment is the
same/similar too their deployment environment and they can use it at
home or on the road and have EVERYTHING they need wherever they are.
Who else could do this? Nobody. It's a big deal if we can get it done.
I will have to look up your script you sent me and start to get smart on
this. Can I use a F8 Live CD/DVD to do this to a thumb drive, or am I
going to have to upgrade my laptop from FC6 to F8?
MikeD
On Fri, 2007-12-14 at 13:21 -0600, Douglas McClendon wrote:
Mike Dickson wrote:
> Is there any chance of getting a current version of RHEL into the Live
> CD + Persistence game?
Were you ever able to test those patches I sent you a couple months back
(on fedora)? (and for the most part, posted to this list)
For me, they do basically work in trivial testing scenarios.
The main problem I have mustering any enjoyment developing them is the
utter grossness of what it takes to patch the standard /etc/rc.d/init.d
halt and functions file. (which is needed to defer unmounting of
persistence device until after readonly remounting of rootfs).
I do have an alternate distribution method of the feature, which makes
it more of a proof of concept "live iso patch" to the official f8
livecd, but it's still the same code and mechanism.
The same fragility may still apply to my method that I mentioned months
ago, i.e. that it may become unrecoverably corrupted if not shutdown
cleanly. But I suspect that if I can make the distribution of it as
easy as a 'patch' to apply to the f8 livecd, and get some testers, that
that problem can be solved (pure speculation).
My time estimates are usually overly ambitious, but I'll try to get that
iso-patch posted in a couple hours.
And as I responded long ago to the original criticism of the ugliness of
the halt&functions patching- I totally agree, and am open to suggestions.
Attached is the last patch I sent Mike, which is pretty close to what I
last posted to this list. It's still useful if anyone is interested in
trying to understand the method I'm using. The main thing to simplify
reading it, is
a) ignore the 'overlay=auto' code path. It's a nice feature, but
complexity that should wait for the future when the base case is well
understood, tested and stable. The base case being
b) assume the only use of the patch is with the modified
livecd-iso-to-disk. I.e. the new usage would be
livecd-iso-to-disk --overlay-size-mb 128 /path/to/f8.iso /dev/sdb1
which would initialize a 128M persistence file and cause the bootloader
on the liveusb to use it. I.e. the syslinux append line goes from
root=UUID=abcd-1234
to
root=UUID=abcd-1234 overlay=UUID=abcd-1234
Then, try to ignore the horrendously ugly selinux magic act required to
patch halt&functions, and just look at the contents of the halt.patch
and functions.patch.
-dmc