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