Re: Handling Updates...
- From: Phil Meyer <pmeyer@xxxxxxxxxxxxxxxx>
- Date: Tue, 31 Jul 2007 13:21:33 -0600
semi linux wrote:
I'm looking at moving to F7 for our next generation HW. As an
investigation into the running of F7, I installed it on our old HW to
check it's functionality and prep for the changes.
Right away I got "BUG: warning at
kernel/softirq.c:138/local_bh_enable() (Not tainted)". This bug has
been reported and fixed
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240982)...
The end result is that I have to update the kernel.
The question :: If I'm going to update, how can I freeze on one
particular update (so I ship the same thing today as I do in 1 year)?
We use kickstart already, so updates can be scripted easily enough but
I would imagine that Glibc/gcc and other updates should occur at the
same time as the kernel - What's the proper way to stop this from
being a moving target? Do I just download everything today and hope
it's a good freeze point while scripting it into our kickstart files?
Anyone here solved this problem before?
- G.
Can do.
You may wish to roll your own. This is what we do:
1. Test Fedora until we hit a reasonably stable platform.
2. Freeze the local repositories.
3. Use pungi to roll a release of Fedora containing all of our released software.
4. Install from that release (we put our custom kickstarts on the release) for the next iteration of that service.
5. Unfreeze the repositories and continue testing.
The next time a major release of our product occurs, we re-roll.
This way we stay fairly current, have the best stuff available at the time of release, and have reasonable quality control.
My specific part in this is the testing and rolling out of the platform.
I also manage the development platform to make sure its reasonably current and stable.
My particular fancy is to hand the field tech a USB thumb drive with the latest OS/Application mix, and they install from that without any support or assist from me. Its great. But a DVD based release is also a result of the roll out.
So basically I roll a release every kernel release or major component release (postfix, httpd, etc) and test test test.
So whenever they do a version release of our software, I simply drop their package into my local repository, roll a release (from a previously tested package set) and test it. If all is well I write it to the thumb drive and send it to the field techs.
We use a local repository of the Fedora release, so that it can be 'frozen' at any given time while the new release is produced.
Hope this makes sense.
Good Luck!
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
- References:
- Handling Updates...
- From: semi linux
- Handling Updates...
- Prev by Date: Re: Back Again
- Next by Date: Re: Back Again
- Previous by thread: Re: Handling Updates...
- Index(es):
Relevant Pages
|
