All,
Does anyone have a timeline for the CentOS 5 release candidates and/or final?
Thanks, -Josh
Joshua Kramer wrote:
All,
Does anyone have a timeline for the CentOS 5 release candidates and/or final?
We will aim to have the CentOS-5 Final release within 2 weeks of upstream release. So far, based on news around ETA upstream looks like 15th March.
- KB
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, Feb 16, 2007 at 10:54:05PM +0000, Karanbir Singh wrote:
Joshua Kramer wrote:
All,
Does anyone have a timeline for the CentOS 5 release candidates and/or final?
We will aim to have the CentOS-5 Final release within 2 weeks of upstream release. So far, based on news around ETA upstream looks like 15th March.
Karan, I'm asking, obviously, for a guess here.
How viable do you think it will be to do an upgrade from 4.4 to 5 on a live system, based on what you've seen on the beta ?
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sat, 2007-02-17 at 14:12 -0200, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, Feb 16, 2007 at 10:54:05PM +0000, Karanbir Singh wrote:
Joshua Kramer wrote:
All,
Does anyone have a timeline for the CentOS 5 release candidates and/or final?
We will aim to have the CentOS-5 Final release within 2 weeks of upstream release. So far, based on news around ETA upstream looks like 15th March.
Karan, I'm asking, obviously, for a guess here.
How viable do you think it will be to do an upgrade from 4.4 to 5 on a live system, based on what you've seen on the beta ?
My personal opinion is that it is about the same is an upgrade from CentOS-3 to CentOS-4 ... doable, but painful ... and in the end, probably not worth the effort.
Let's see what KB has to say :P
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Feb 17, 2007 at 02:44:19PM -0600, Johnny Hughes wrote:
Karan, I'm asking, obviously, for a guess here.
How viable do you think it will be to do an upgrade from 4.4 to 5 on a live system, based on what you've seen on the beta ?
My personal opinion is that it is about the same is an upgrade from CentOS-3 to CentOS-4 ... doable, but painful ... and in the end, probably not worth the effort.
I have at least 1 machine I'll have to do it. And, guess what ? It is a remote machine (datacenter in another country).
Should be fun.
Let's see what KB has to say :P
Yup
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
I have at least 1 machine I'll have to do it. And, guess what ? It is a remote machine (datacenter in another country).
Should be fun.
Duplicating the remote setup to a local/virtual machine and giving the upgrade a shot before tinkering with the live server won't hurt. ;)
Ovidiu Lixandru wrote:
Rodrigo Barbosa wrote:
I have at least 1 machine I'll have to do it. And, guess what ? It is a remote machine (datacenter in another country).
Should be fun.
Duplicating the remote setup to a local/virtual machine and giving the upgrade a shot before tinkering with the live server won't hurt. ;)
A killer on remote machines can be when the new kernel detects your NIC cards in a different order and either skips initialization or assigns the wrong IP's. It may be hard to test that unless you have indentical hardware. If you have remote support you may be able to talk someone through the fix anyway.
Les Mikesell wrote:
Ovidiu Lixandru wrote:
Rodrigo Barbosa wrote:
I have at least 1 machine I'll have to do it. And, guess what ? It is a remote machine (datacenter in another country).
Should be fun.
Duplicating the remote setup to a local/virtual machine and giving the upgrade a shot before tinkering with the live server won't hurt. ;)
A killer on remote machines can be when the new kernel detects your NIC cards in a different order and either skips initialization or assigns the wrong IP's. It may be hard to test that unless you have indentical hardware. If you have remote support you may be able to talk someone through the fix anyway.
isnt that why you use hwaddr in your network scripts ?
Karanbir Singh wrote:
Les Mikesell wrote:
Ovidiu Lixandru wrote:
Rodrigo Barbosa wrote:
I have at least 1 machine I'll have to do it. And, guess what ? It is a remote machine (datacenter in another country).
Should be fun.
Duplicating the remote setup to a local/virtual machine and giving the upgrade a shot before tinkering with the live server won't hurt. ;)
A killer on remote machines can be when the new kernel detects your NIC cards in a different order and either skips initialization or assigns the wrong IP's. It may be hard to test that unless you have indentical hardware. If you have remote support you may be able to talk someone through the fix anyway.
isnt that why you use hwaddr in your network scripts ?
That's even worse. All of my remote machines have swappable disks and almost all of them are cloned from a few masters, shipped, and swapped into the destination machine with the IP address set on a temporary box. Somewhere about a year into the life of CentOS 3.x an update fixed an apparent bug that had until then kept it from caring about having the wrong hwaddr in the config files. It wasn't a lot of fun when they suddenly ignored their network interfaces on boot-up. Fortunately I happened to be visiting one of the remote data centers when the first one happened and saw the message on the console screen and was able to fix the others before they were rebooted.
Les Mikesell wrote:
A killer on remote machines can be when the new kernel detects your NIC cards in a different order and either skips initialization or assigns the wrong IP's.
isnt that why you use hwaddr in your network scripts ?
That's even worse. All of my remote machines have swappable disks and almost all of them are cloned from a few masters, shipped, and swapped into the destination machine with the IP address set on a temporary box.
This is your site policy, and is not necessary how everyone runs their machines. I, for one, take it that each drive that is added to a machine is going to be empty - its trivial to remaster a machine on the fly with tools like cobbler+koan and use puppet to manage the machine, Capistrano to manage app rollout.
The concern you raised was about network interfaces not coming up in a predictable manner when people move from centos-4 to centos-5, the answer to which is, use hwaddr's in your network scripts.
- KB
Karanbir Singh wrote:
A killer on remote machines can be when the new kernel detects your NIC cards in a different order and either skips initialization or assigns the wrong IP's.
isnt that why you use hwaddr in your network scripts ?
That's even worse. All of my remote machines have swappable disks and almost all of them are cloned from a few masters, shipped, and swapped into the destination machine with the IP address set on a temporary box.
This is your site policy, and is not necessary how everyone runs their machines. I, for one, take it that each drive that is added to a machine is going to be empty - its trivial to remaster a machine on the fly with tools like cobbler+koan and use puppet to manage the machine, Capistrano to manage app rollout.
I'm not familiar with those tools, but I assume they require a certain amount of nearby infrastructure which would be extra trouble to duplicate and maintain in all our remote locations. And it doesn't cost any more to ship a disk already loaded than empty.
The concern you raised was about network interfaces not coming up in a predictable manner when people move from centos-4 to centos-5, the answer to which is, use hwaddr's in your network scripts.
The concern it more general - more about unpredictable differences. Having seen a difference in what the hwaddr setting does even within a version, I wouldn't count on it to work across versions without testing it first.
Les Mikesell wrote:
The concern it more general - more about unpredictable differences. Having seen a difference in what the hwaddr setting does even within a version, I wouldn't count on it to work across versions without testing it first.
Absolutely, and things get even murkier with Virtualised Interfaces and VM's where there is sometimes no real relation to the MAC Addr at all! Even the Vendor portion cant be relied upon to identify a device.
While still on the same subject of upgrades and testing etc, if someone is creating VM's to migrate a real machine into take a look at vmware's Converter tool ( url: http://www.vmware.com/products/converter/ ). I've not used it myself, but heard from people who have that it does what one would expect from such a tool, and handles most network issues / drive and driver issues fairly cleanly.
- KB
Karanbir Singh wrote:
While still on the same subject of upgrades and testing etc, if someone is creating VM's to migrate a real machine into take a look at vmware's Converter tool ( url: http://www.vmware.com/products/converter/ ). I've not used it myself, but heard from people who have that it does what one would expect from such a tool, and handles most network issues / drive and driver issues fairly cleanly.
That's for windows. With Linux you can use most of the usual backup/ restore procedures that you would use with physical machines (tar,cpio, rsync, etc.) and you have to deal with the same problems of getting a working disk driver in the initrd image and installing grub that you would have with real machines. Is there a generic tool to do those two things easier than booting an install CD in rescue mode and doing it by hand?
Les Mikesell wrote:
Karanbir Singh wrote:
While still on the same subject of upgrades and testing etc, if someone is creating VM's to migrate a real machine into take a look at vmware's Converter tool ( url: http://www.vmware.com/products/converter/ ). I've not used it myself, but heard from people who have that it does what one would expect from such a tool, and handles most network issues / drive and driver issues fairly cleanly.
That's for windows.
humm, I am quite sure that it was a linux machine that I saw migrated - perhaps their free version only does Windows so far, but i am quite sure linux machines are in the pipeline.
With Linux you can use most of the usual backup/ restore procedures that you would use with physical machines (tar,cpio, rsync, etc.) and you have to deal with the same problems of getting a working disk driver in the initrd image and installing grub that you would have with real machines. Is there a generic tool to do those two things easier than booting an install CD in rescue mode and doing it by hand?
I suppose if you knew what modules you are going to need, then doing it at the same time as the VM is created would be possible. If not, then its a bit of a mismatch. Perhaps something to take on as a small weekend project ?
Karanbir Singh wrote:
With Linux you can use most of the usual backup/ restore procedures that you would use with physical machines (tar,cpio, rsync, etc.) and you have to deal with the same problems of getting a working disk driver in the initrd image and installing grub that you would have with real machines. Is there a generic tool to do those two things easier than booting an install CD in rescue mode and doing it by hand?
I suppose if you knew what modules you are going to need, then doing it at the same time as the VM is created would be possible. If not, then its a bit of a mismatch. Perhaps something to take on as a small weekend project ?
The ideal thing would be for the installer to have a re-install mode where it just does the the hardware detect, builds the modprobe.conf file and initrd image, and installs grub on the boot drive assuming that you've already copied an otherwise working system into place. A check the the boot partition really has a kernel in the right place and that /etc/fstab lists labels or partition names that really exist could save a few reboot attempts too. You could run this from the install disk's rescue mode.
Am Sonntag, den 18.02.2007, 04:50 +0000 schrieb Karanbir Singh:
Les Mikesell wrote:
The concern it more general - more about unpredictable differences. Having seen a difference in what the hwaddr setting does even within a version, I wouldn't count on it to work across versions without testing it first.
Absolutely, and things get even murkier with Virtualised Interfaces and VM's where there is sometimes no real relation to the MAC Addr at all!
I did not check the other VMMs, but at least Xen can configure the guest's MACs, for example
vif = [ 'mac=FE:FD:00:DE:AD:04, bridge=br0' ]
So you could simulate the remote upgrade within a local VM using identical HWADDRs. Of course that would not solve probs with other HW (RAID, NIC-driver).
/nils.
Am Sonntag, den 18.02.2007, 02:45 +0200 schrieb Ovidiu Lixandru:
Rodrigo Barbosa wrote:
I have at least 1 machine I'll have to do it. And, guess what ? It is a remote machine (datacenter in another country).
Should be fun.
Duplicating the remote setup to a local/virtual machine and giving the upgrade a shot before tinkering with the live server won't hurt. ;)
As a safety mesurement you could clone the machine ("cp -a") to a blockdevice on the same remote machine (LVM volume, loopfile) before. If upgrading breaks anything except remote access, you could run the broken service inside the chrooted or virtualized clone until you manage to fix its upgraded version.
/nils.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Feb 18, 2007 at 02:51:55PM +0100, Nils Toedtmann wrote:
Am Sonntag, den 18.02.2007, 02:45 +0200 schrieb Ovidiu Lixandru:
Rodrigo Barbosa wrote:
I have at least 1 machine I'll have to do it. And, guess what ? It is a remote machine (datacenter in another country).
Should be fun.
Duplicating the remote setup to a local/virtual machine and giving the upgrade a shot before tinkering with the live server won't hurt. ;)
As a safety mesurement you could clone the machine ("cp -a") to a
"cp -a" for cloning ? Errr, bad mistake.
"dump -0f - / | ( cd /newlocation; restore -f - )" is a much better idea on these cases.
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
As a safety mesurement you could clone the machine ("cp -a") to a
"cp -a" for cloning ? Errr, bad mistake.
"dump -0f - / | ( cd /newlocation; restore -f - )" is a much better idea on these cases.
The results should be pretty much the same on anything with GNU cp except that cp can copy to different filesystem types. It is a good idea to use the --one-file-system option and repeat for each partition.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Feb 18, 2007 at 07:14:16PM -0600, Les Mikesell wrote:
Rodrigo Barbosa wrote:
As a safety mesurement you could clone the machine ("cp -a") to a
"cp -a" for cloning ? Errr, bad mistake.
"dump -0f - / | ( cd /newlocation; restore -f - )" is a much better idea on these cases.
The results should be pretty much the same on anything with GNU cp except that cp can copy to different filesystem types. It is a good idea to use the --one-file-system option and repeat for each partition.
Are you sure ? Last I remember, "cp -a" does not preserve some of the inode data. Also, it does some file reordering.
Yes, most of these are inconsequential on a practical pov, but it is still farther from cloning than using dump/restore.
Of course, if you want real cloning you would have to use "dd", but that is _way_ beside the point here.
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Am Montag, den 19.02.2007, 04:42 -0200 schrieb Rodrigo Barbosa:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Feb 18, 2007 at 07:14:16PM -0600, Les Mikesell wrote:
Rodrigo Barbosa wrote:
As a safety mesurement you could clone the machine ("cp -a") to a
"cp -a" for cloning ? Errr, bad mistake.
"dump -0f - / | ( cd /newlocation; restore -f - )" is a much better idea on these cases.
The results should be pretty much the same on anything with GNU cp except that cp can copy to different filesystem types. It is a good idea to use the --one-file-system option and repeat for each partition.
Are you sure ? Last I remember, "cp -a" does not preserve some of the inode data. Also, it does some file reordering.
Yes, most of these are inconsequential on a practical pov, but it is still farther from cloning than using dump/restore.
Of course, if you want real cloning you would have to use "dd", but that is _way_ beside the point here.
My mistake, i should have provided my definition of "cloning an OS" (not: "cloning a partition"): "making a copy of the OS that is similar enough to its original that it works the same way with no perceivable difference".
"cp -a[x]" does exactly that (at least CentOS' GNU cp; it preserves labels like selinux contexts, too) provided that your apps do not operate directly on the blockdevs ("hexedit /dev/sda1"). I consider it being superior to dd to do this job as it "defrags" the filesystems. I copied several systems and never observed any breakage due to cp forgetting or changing low-level details.
That may have been false back in '91, but things change ;)
/nils.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Feb 18, 2007 at 02:45:28AM +0200, Ovidiu Lixandru wrote:
Rodrigo Barbosa wrote:
I have at least 1 machine I'll have to do it. And, guess what ? It is a remote machine (datacenter in another country).
Should be fun.
Duplicating the remote setup to a local/virtual machine and giving the upgrade a shot before tinkering with the live server won't hurt. ;)
Actually, I'm not very worried about breaking the machine. I have enough experience with Unix (since 91) and Linux (since 92) not to do it. My main worry is if it will be viable, or simply too much work.
But yes, I'll do it localy first, on my notebook. In any case, it is my most messed-up machine, and if I can update it, everything else should be easier.
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sat, Feb 17, 2007 at 06:59:19PM -0200, Rodrigo Barbosa wrote:
I have at least 1 machine I'll have to do it. And, guess what ? It is a remote machine (datacenter in another country).
A recommendation to make this go more smoothly: before the upgrade, uninstall as many packages as possible. Everything that's not needed to run the server, and as many things which are needed but which can be put back with a simple yum install after the upgrade. This will minimize the chances of problems.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Feb 17, 2007 at 08:33:06PM -0500, Matthew Miller wrote:
On Sat, Feb 17, 2007 at 06:59:19PM -0200, Rodrigo Barbosa wrote:
I have at least 1 machine I'll have to do it. And, guess what ? It is a remote machine (datacenter in another country).
A recommendation to make this go more smoothly: before the upgrade, uninstall as many packages as possible. Everything that's not needed to run the server, and as many things which are needed but which can be put back with a simple yum install after the upgrade. This will minimize the chances of problems.
Everything that can be removed should be ok to break. My main concern is glibc, of course. That is where we get NASTY breakages.
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sat, 2007-02-17 at 14:12 -0200, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, Feb 16, 2007 at 10:54:05PM +0000, Karanbir Singh wrote:
Joshua Kramer wrote:
All,
Does anyone have a timeline for the CentOS 5 release candidates and/or final?
We will aim to have the CentOS-5 Final release within 2 weeks of upstream release. So far, based on news around ETA upstream looks like 15th March.
Karan, I'm asking, obviously, for a guess here.
How viable do you think it will be to do an upgrade from 4.4 to 5 on a live system, based on what you've seen on the beta ?
considering where they came from and the kernel versions installed it should be about the same as updating from Fedora Core 3's original release to Fedora Core 6's original release.
It's doable thing but it might take some effort to prune out certain conflicting pkg versions.
I'll be giving it a test when it is out and I'll post my experiences.
-sv
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Feb 17, 2007 at 04:37:21PM -0500, seth vidal wrote:
On Sat, 2007-02-17 at 14:12 -0200, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, Feb 16, 2007 at 10:54:05PM +0000, Karanbir Singh wrote:
Joshua Kramer wrote:
All,
Does anyone have a timeline for the CentOS 5 release candidates and/or final?
We will aim to have the CentOS-5 Final release within 2 weeks of upstream release. So far, based on news around ETA upstream looks like 15th March.
Karan, I'm asking, obviously, for a guess here.
How viable do you think it will be to do an upgrade from 4.4 to 5 on a live system, based on what you've seen on the beta ?
considering where they came from and the kernel versions installed it should be about the same as updating from Fedora Core 3's original release to Fedora Core 6's original release.
FC6 ? Are you sure ? I figured RHEL 5 would be based on FC4, maybe FC5.
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sun, Feb 18, 2007 at 10:36:59PM -0200, Rodrigo Barbosa wrote:
considering where they came from and the kernel versions installed it should be about the same as updating from Fedora Core 3's original release to Fedora Core 6's original release.
FC6 ? Are you sure ? I figured RHEL 5 would be based on FC4, maybe FC5.
If that were the case, it'd have been released last year or the year before.
On Sun, 2007-02-18 at 22:36 -0200, Rodrigo Barbosa wrote:
considering where they came from and the kernel versions installed it should be about the same as updating from Fedora Core 3's original release to Fedora Core 6's original release.
FC6 ? Are you sure ? I figured RHEL 5 would be based on FC4, maybe FC5.
Absolutely positive. rhel5 was branched from fc6 test1 or test2.
-sv
Rodrigo Barbosa wrote:
On Fri, Feb 16, 2007 at 10:54:05PM +0000, Karanbir Singh wrote:
Joshua Kramer wrote:
All,
Does anyone have a timeline for the CentOS 5 release candidates and/or final?
We will aim to have the CentOS-5 Final release within 2 weeks of upstream release. So far, based on news around ETA upstream looks like 15th March.
Karan, I'm asking, obviously, for a guess here.
How viable do you think it will be to do an upgrade from 4.4 to 5 on a live system, based on what you've seen on the beta ?
Ok, there are 2 methods to consider here :
1. doing it with yum on a running machine : its do-able, but requires some $clue. The aim is to proide this $clue via a shell script that anyone can run to 'move' a machine from C-4 to C-5. There are some issues to keep in mind - the only way to handle conflicting packages is by repackaging an existing rpm then rpm -e -justdb removing them, going through the upgrade and then doing the safest cleanup possible at the end.
2. doing it via anaconda's upgradeany method : this is a bit simpler since packages are more or less just installed from scratch onto the same filesystem. The issues that I've had to work with ( and have a couple of patches for ) are when users have CentOS-Plus or CentOS-Extras enabled. Packages from these repo's are not really orphans, and should not be treated as such. Exactly how we handle these is still semi-open-to-discussion. But rather than having that discussion right now, I think lets have that post-c5beta, so we fix real problems rather than hypothetical ones.
Either way, orphans are going to get created - and extra dep's are going to get installed ( in most cases ) - and the best way to work around that, i feel, is to have a firstboot plugin that handles it for anaconda upgradeany upgrades and via a shell script for yum upgrades. Once we have this script running the way we want, we can then drop that into a rpm and moving it into centos-4-extras. Thereby making a move to centos-5 as simple as 'yum install upgrade-to-centos5' from a centos-4 machine
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Feb 18, 2007 at 02:41:58AM +0000, Karanbir Singh wrote:
Rodrigo Barbosa wrote:
On Fri, Feb 16, 2007 at 10:54:05PM +0000, Karanbir Singh wrote:
Joshua Kramer wrote:
All,
Does anyone have a timeline for the CentOS 5 release candidates and/or final?
We will aim to have the CentOS-5 Final release within 2 weeks of upstream release. So far, based on news around ETA upstream looks like 15th March.
Karan, I'm asking, obviously, for a guess here.
How viable do you think it will be to do an upgrade from 4.4 to 5 on a live system, based on what you've seen on the beta ?
Ok, there are 2 methods to consider here :
- doing it with yum on a running machine : its do-able, but requires
some $clue. The aim is to proide this $clue via a shell script that anyone can run to 'move' a machine from C-4 to C-5. There are some issues to keep in mind - the only way to handle conflicting packages is by repackaging an existing rpm then rpm -e -justdb removing them, going through the upgrade and then doing the safest cleanup possible at the end.
Pretty much what I expected, then.
- doing it via anaconda's upgradeany method :
Unfortunatelly, not an option for a live system.
Either way, orphans are going to get created - and extra dep's are going to get installed ( in most cases ) - and the best way to work around that, i feel, is to have a firstboot plugin that handles it for anaconda upgradeany upgrades and via a shell script for yum upgrades. Once we have this script running the way we want, we can then drop that into a rpm and moving it into centos-4-extras. Thereby making a move to centos-5 as simple as 'yum install upgrade-to-centos5' from a centos-4 machine
That would be really nice, if samewhat dangerous.
I'm aware that major upgrades like this are not for the faint of heart. The machine will never be as clean as a new install, also.
And yes, it is always doable, but not always viable.
[]s
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sat, 17 Feb 2007, Rodrigo Barbosa wrote:
How viable do you think it will be to do an upgrade from 4.4 to 5 on a live system, based on what you've seen on the beta ?
I did a c4.4 to SL5 yum test upgrade today, with zero issues in non home-grown packages. My system was a minimal server distro, with selinux disabled. Of course, if you have more packages installed, you're more likely to find conflicts or breakage.
I expect C5 to resemble SL5 quite closely, so if you'd like to start testing, just find an sl5 repository mirror (e.g. http://mirror.cpsc.ucalgary.ca/mirror/scientificlinux.org/5rolling/) and give it a try.
--- Charlie
On Mon, 19 Feb 2007, Charlie Brady wrote:
I did a c4.4 to SL5 yum test upgrade today, with zero issues in non home-grown packages.
I realise I've not told the full story there. I had some anachronisms to correct in my apache, squid and slapd configurations. Of those, only the apache ones could not have been made before the upgrade (some apache modules have been renamed).
--- Charlie
-
Charlie Brady -
John Summerfield -
Johnny Hughes -
Joshua Kramer -
Karanbir Singh -
Les Mikesell -
Matthew Miller -
Nils Toedtmann -
Ovidiu Lixandru -
Rodrigo Barbosa -
seth vidal