Connie,

what I'm really after is the ability to install on current hardware
or configurations only supported by the latest quarterly updates.
Examples:

  - 305 saved my neck because it came just in time for some servers
    with a 6x300GB SCSI RAID5, and SL <= 304 had a 1 TB size limit for
    block devices

  - 306 would finally allow me to migrate servers still running DL5
    which have block devices > 1 TB with a single partition on them,
    since SL <= 305 has a 1 TB size limit for partitions

  - 306 would certainly just work on that intel 945 desktop board I
    tested recently - it had an intel NIC too recent for 305 (and 41).

Working around the latter (including getting network installations
going) was straightforward. But adding support for new hardware (I think 
update 6 introduces support for 3ware 9000 controllers) would probably be 
much more complicated. And I have no clue how I would tackle the
partition size problem (remember we've been that SuSE shop for years -
the inner workings of anaconda still are a mystery to me).

Once I get kickstart installs to the point where they execute my %post,
without eating my existing partition tables and filesystems before, I'm 
all set.

Having all RPMs current after basic installation or being able to add my 
own ones isn't nearly as crucial since this can all be worked around in 
%post with little effort. I'm prepared to start spinning my own site 
eventually in order to avoid having the first "yum update" take longer 
than installation itself, and I've done it as an excercise in the past,
but that's merely a convenience.

But my understanding is (and I may be wrong here) that creating a site
will not give me an installer that's equivalent to that coming with the
latest quarterly update. Will it?

Going 4.x is not yet an option here: Almost all of the > 400 systems I
personally have to cater for need a solid AFS client. We'll hopefully get 
there soon, but right now I still need an SL3 working (installing) on the 
current hardware generation and at least moderately large disks.

If there'll be no 306 (it was really nothing but a question), and 
simply creating a site from updated packages  won't do the trick, I'll 
have to fiddle with the installer then.

Cheers,
 	Stephan


On Thu, 29 Sep 2005, Connie Sieh wrote:

> Stephan,
>
> On Thu, 29 Sep 2005, Stephan Wiesand wrote:
>
>> Hi Troy,
>>
>> I think that's the right thing to do. 1.2.13 has proven rock solid here on
>> 32-bit, and amd64. In particular, it put an end to instabilities of our
>> dual Opterons running 64-bit SL we observed with 1.2.11.
>>
>> Even the server packages meanwhile received a fair bit of testing here
>> (32-bit only, though, and these are filservers only, not db), and we
>> haven't observed any problems.
>>
>> In my opinion there's also nothing that needs changing except removing
>> or changing the init info. One thing that could be done is to use the
>> rxdebug check in on_network, because rxdebug since 1.2.13 works on x86_64
>> and probably on ia64 as well, although still I can't check that.
>>
>> There's still the dispute over dynroot, though. But then, CERN seem to
>> be rolling their own anyway (?) and noone else ever seriously complained
>> ;-)
>>
>> Cheers,
>>  	Stephan
>>
>> PS I'm about to build 1.4.0rc5 packages for SL 4.1. Unless someone
>>     beats me to it. They're going to release 1.4 soon, and we should
>>     probably look at it.
>>
>> PPS Are you planning to create a 3.0.6? I'd much appreciate it, but
>>      I also figure it's becoming more tedious with every minor release...
>
> That is a good question.  We have thought about this and we clearly have
> to scale back on what releases we do and not do.  There are 3 30x releases
> and 3 4x releases, Jarek does most of the work for the ia64 but that still
> leaves 4 releases for Troy and myself.  But we also have to do the
> Scientific Linux Fermi releases so that now makes 8 releases plus the
> small amount that we do for the 2 ia64 releases.
>
> So in the 305 and 41 releases Troy added a "bugfix" area in the yum.conf
> file.  It is not enabled by default.  But the thought was that if we did
> NOT make a full release we would rebuild all the new/updated rpms and put
> them in this "bugfix" area that yum/apt could access.  This would enable
> users who wanted to upgrade to the "equivalent" of the new update to do so
> after enabling this area.  For users that just want to upgrade but do not
> want to change yum.conf they could mirror the "errata" tree and move all
> the rpms from the "bugfix" area to the "errata/SL/RPMS/" area .  The only
> things that would be missing with this idea is that new kernel changes and
> new installer changes would not be seen in the installer as the new kernel
> and installer would only be in the "bugfix" area. Of course a user could
> always make a "site" with the new/updated rpms in it and then they would
> have the new kernel as the installer kernel.
>
> So the proposal for 306 is to use this new idea.  Rebuild the new/updated
> rpms and put them in the "bugfix" area where users could have yum/apt
> access to them.  When 42 comes out make a full release out of that.
>
> These could be switched, we just thought that 42 was younger and may need
> those kernel and installer changes more than 306.
>
> Do note that there is some expectation that RHEL 5 will be released late
> 2006.
>
> Comments/suggestions please.
>
> -Connie Sieh
>
>>
>>
>> On Thu, 29 Sep 2005, Troy Dawson wrote:
>>
>>> Howdy,
>>> I want a second or third opinion on this.
>>> Currently, there are 3 different openafs versions on the S.L. 3.0.x versions.
>>> SL 301 - openafs-1.2.10
>>> SL 302,3,4 - openafs-1.2.11
>>> SL 305 - openafs-1.2.13
>>>
>>> I believe I said before, that with the next security kernel update, I'd like
>>> to move them all up to the same version.  If I didn't, I meant to.
>>>
>>> Does this sound like a good idea?  (I still think it does)
>>>
>>> If it does, I was planning on doing openafs-1.2.13-15.17.SL
>>> This is the same openafs as was released in S.L. 3.0.5, but has the init
>>> script fixed to work properly with LSB.
>>>
>>> Any thoughts?
>>>
>>> Troy
>>>
>>>
>>
>>
>

-- 

  ----------------------------------------------------
| Stephan Wiesand  |                                |
|                  |                                |
| DESY     - DV -  | phone  +49 33762 7 7370        |
| Platanenallee 6  | fax    +49 33762 7 7216        |
| 15738 Zeuthen    | mobile +49 171 317 6367        |
| Germany          | email  [log in to unmask] |
  ----------------------------------------------------