RHEL 5.1 was announced today (Nov 7, 2007). So here, I posted the soon-to-be-the-most-frequently-asked question for those who are eagerly waiting for this point release. Therefore, please do not start a new one.

EDIT: forgot to refer to the announcement. If you are interested in What's New:

https://www.redhat.com/archives/rhelv5-announce/2007-November/msg00000.html

Soon.

(The most common answer to this type of question)

The second most common is: when it's ready.

Most realistic answer:

"Sometime before it's ready."

And now for the real answer

http://www.centos.org/modules/smartfaq/faq.php?faqid=7

We have goals for release ... our goals are:

First time release (for example, 3.0, 4.0, 5.0): Our target goal is 1 month. This is obviously the longest situation as this is a BRANCH or version of CentOS that has never been tested and it requires much QA and usability tests, etc.

Update set release (for example, 3.9, 4.5, 5.1): Our target goal is two weeks. This type of update normally changes 10%-30% of the packages in it's tree and requires more QA than individual releases but less time to test than a whole new tree. Longest time has been one month.

Normal security or bugfix updates between update sets: Our target goal is 72 hours and we normally complete these within 24 hours.

So ... for 5.1 (and the upcoming 4.6) our goal for each is 2 weeks to finish the updates and get an ISO set. Then 2-3 days to get them synced to all the internal mirrors and another 2-3 days to get them to all the external public mirrors. At that point there will be a release announcement.

The realistic date that I would expect the release announcement (if we have no unforeseen problems) would be in the neighborhood of 26-30 November 2007.

Hello!

I was wondering if it will be possible to cleanly (without the dependecy hell) upgrade from CentOS 5.0 to 5.1?

Is it possible or maybe to prefer a simple clean install?

Minor version updates have been painless for me in the the 4.x range. I would expect the same painless updates for the 5.x.

If you just run yum update (or have the daily yum cron running), 5.0 should become 5.1 automatically. In other words, the latest point release will always become the default. This is not the case with a major release upgrade (from CentOS 4 to 5, for example).

Quote:

If that is the case awesome! I don't want to pay my provider for another OS install.

This a very informative thread. Thanks to all. I see that the 'vga=xxx' bug will be fixed, and I'm really looking forward to that

This is a list of bugs fixed for those that haven't seen it yet.

http://rhn.redhat.com/errata/RHBA-2007-0959.html

As already stated elsewhere in this thread (but I want to make sure people understand this too ) upgrades between minor versions (the y in CentOS-X.y) in the same major release (the X in CentOS-X.y) should always be doable via yum with no real problems...

That means upgrading from 3.1 to 3.9, 4.3 to 4.6, 5.0 to 5.1 all require nothing more than a yum update (I use yum upgrade ... but on new versions it is the same).

What is not supported in yum updates is changing Major releases...

That means upgrades from 3.9 to 4.5 ...OR... upgrades from 4.5 to 5.1 can NOT be accomplished via yum.

Hopefully this is clear

Will this include a kernel update, or will it still include 2.6.18? I had problems with my SATA controller (ATI SB600) once I upgrade to 4GB. Upgrading the kernel to 2.6.23 fixed it.

Also, I heard that it will include several updates to the e1000 driver for Intel Gigabit network cards. Can anyone ellaborate on? I currently have 4 Intel cards that do not work with 4GB RAM installed. I get Tx Unit Hang errors. I have upgraded to the latest kernel (2.6.23, x86_64 compiled), and the most recent stable version of the driver (downloaded from sourceforge, as directed by Intel). They still don't work. Anyone know if these issues will be resolved in the 5.1 update?

Following up on hughesjr's comments (post #11), if you have modified or replaced /etc/yum.repos.d/CentOS-Base.repo (e.g., you are using a local mirror), there is one thing to watch for when making a minor release yum update.


The minor release yum update will update the centos-release package, which typically results in either the updating/creation of /etc/yum.repos.d/CentOS-Base.repo or the creation of /etc/yum.repos.d/CentOS-Base.repo.rpmnew.

If you are like me and create a new .repo file for the local mirror and hide/remove the CentOS-Base.repo, updating centos-release will cause each centos repo to be defined twice, once for the local mirror and once for the centos mirrors. The simple fix is to move/remove the new /etc/yum.repos.d/CentOS-Base.repo.

If you have modified /etc/yum.repos.d/CentOS-Base.repo, it is likely that updating the centos-release package will cause the creation of /etc/yum.repos.d/CentOS-Base.repo.rpmnew. Any improvements in the .rpmnew version should be incorporated into your locally defined .repo file. It is also possible that the centos-release updating will overwrite your locally modified CentOS-Base.repo file.


My practice is to first update the centos-release package and then to resolve issues in /etc/yum.repos.d before proceeding with the other updates.

You've earned one point for this excellent note

Quote:
RHEL 5.1 comes with kernel-2.6.18-53. In general, all minor releases are supposed to be fully binary-compatible. This includes having the same version of all the major components, including the kernel.

CentOS 4.6 will be out after 5.1. There is a separate thread for it. Please see:

http://www.centos.org/modules/newbb/viewtopic.php?topic_id=11242&forum=27

Status update for CentOS 5.1:

http://www.karan.org/blog/index.php/2007/11/16/update_on_the_status_of_centos_5_1

Quote:

Thanks toracat

Quote:

As a general rule, the Upstream Guys backport a LOT of stuff into the kernel, even if it remains labeled 2.6.18. I too have a SATA bug (the device is sata_nv) with 5.0 which is fixed in Fedora 7, and the 5.1 kernel will contain a SATA version which is newer than FC7.

-- greg

Right. For example, the 5.1 kernel that should be out very soon contains more than 1000 patches against the vanilla kernel 2.6.18. They are security patches, bug fixes, etc. Many of them are from upstream (kernel engineers) and some are RedHat's own.