hi,
By now most people would have seen or atleast have spotted the 6.3/cr/ repos are populated and updates there announced to the cr-announce list.
6.4 is a big release, lots of changes and lots of feedback about things ( also, we found in our limited testing that there are some surprises around the corners! )
Most people on the -devel list here should know about how we use the /cr/ repo and its implications - So with that in mind, please test the package payloads and provide feedback on this list. We are going to start working on the isos from today/tomorrow and start testing those right away, but in the mean time it would be great if we could get as wide as possible testing done against 6.3 + cr, and then document into the Release Notes whatever comes through.
And remember, even if the test passes - let us know what you tested and that it passes'. Its important for us to build a coverage model as well.
Thanks
- KB
On 02/28/2013 12:07 AM, Karanbir Singh wrote:
hi,
By now most people would have seen or atleast have spotted the 6.3/cr/ repos are populated and updates there announced to the cr-announce list.
6.4 is a big release, lots of changes and lots of feedback about things ( also, we found in our limited testing that there are some surprises around the corners! )
Most people on the -devel list here should know about how we use the /cr/ repo and its implications - So with that in mind, please test the package payloads and provide feedback on this list. We are going to start working on the isos from today/tomorrow and start testing those right away, but in the mean time it would be great if we could get as wide as possible testing done against 6.3 + cr, and then document into the Release Notes whatever comes through.
And remember, even if the test passes - let us know what you tested and that it passes'. Its important for us to build a coverage model as well.
In this case: 2 days ago - using the tree from QA that was available at the time - I've updated 3 workstations ( 2*x86_64, 1*i386) that use KDE . No issues except for the fact that fonts in certain applications ( facebook, thunderbird ) are smaller than they used to be.
Worth noting might also be - one of them uses kmod-nvidia-310.32-1.el6.elrepo.x86_64 and it behaved exactly as it should, no surprises of any kind - one of the systems was not fully updated ( missing like the last 5-6 weeks ). most notably nss, firefox and tbird were still at older versions.
manuel
On 27.02.2013 22:07, Karanbir Singh wrote:
hi,
By now most people would have seen or atleast have spotted the 6.3/cr/ repos are populated and updates there announced to the cr-announce list.
6.4 is a big release, lots of changes and lots of feedback about things ( also, we found in our limited testing that there are some surprises around the corners! )
Most people on the -devel list here should know about how we use the /cr/ repo and its implications - So with that in mind, please test the package payloads and provide feedback on this list. We are going to start working on the isos from today/tomorrow and start testing those right away, but in the mean time it would be great if we could get as wide as possible testing done against 6.3 + cr, and then document into the Release Notes whatever comes through.
And remember, even if the test passes - let us know what you tested and that it passes'. Its important for us to build a coverage model as well.
Thanks
- KB
After all the updates were applied the filesystem (jbd2/dm-1-8) has gone crazy: http://i.imgur.com/pW5JPkN.png
I tried remounting with noatime or change the commit, but no luck, it still span the heck out of the HDD. Finally stopping the "cgred" service "fixed" it. Don't know what's going on with that or if it's something particular to my setup.; AFAIK I did not customise anything cgroup-wise.
On Wed, 27 Feb 2013 22:07:58 +0000 Karanbir Singh mail-lists@karan.org wrote:
So with that in mind, please test the package payloads and provide feedback on this list. We are going to start working on the isos from today/tomorrow and start testing those right away, but in the mean time it would be great if we could get as wide as possible testing done against 6.3 + cr, and then document into the Release Notes whatever comes through.
And remember, even if the test passes - let us know what you tested and that it passes'. Its important for us to build a coverage model as well.
Thanks
- KB
Hi,
Done some testing over the last Day or Two :-)
I hope there isn't too much information in this email, but you did ask us to report back :-P.
Please note all of these VM's are for testing purposes only. And are not considered "Production Level" prior to testing upgrades. :-)
The following has been tested as Virtual Machines: Centos 6.3 Zimbra Server (Fully Configured), up to date -> CetOS 6.4(sic) Zimbra Server
CentOS 6.3 FreeIPA Server (Fully Configured), stock -> CentOS 6.4 FreeIPA Server
CentOS 6.3 FreeIPA Client (Fully Configured), stock -> CentOS 6.4 FreeIPA Client
CentOS 6.3 HTTP Server Stock -> CentOS 6.4 HTTP Server Stock
Commands used for all upgrades: yum clean all yum install centos-release-cr yum upgrade glibc* rpm* yum* yum upgrade init 6
Virtual Machine Specs: ---------------------- Oracle VirtualBox 4.2.6 ---------------------- CentOS Zimbra Server ---------------------- Cores: 2 RAM: 2048MB NIC: Emulated Intel PRO/1000MT Server NIC: Bridged to host bond0 Options: AMD-V Enabled Updated PKGs: 169
---------------------- CentOS FreeIPA Server ---------------------- Cores: 3 RAM: 2048MB NIC: PCnet-FAST III NIC: Bridged to host bond0 Options: AMD-V Enabled Updated PKGs: 258
---------------------- CentOS FreeIPA Client ---------------------- Cores: 2 RAM: 1024MB NIC: PCnet-FAST III NIC: Bridged to host bond0 Options: AMD-V Enabled Updated PKGs: 358
---------------------- CentOS HTTP Server ---------------------- Cores: 8 Cores RAM: 2048MB NIC: Emulated Intel PRO/1000MT Server NIC: Bridged to host bond0 Options: AMD-V Enabled, LsiLogic SAS 2 HDD's using Soft Raid (in guest), LUKS Encrypted HDD's Updated PKGs: 255
Tools Used: Black Coffee, lots and lots of black coffee! SSH (Command) Screen (Command) top (Command) Shorewall (IPTables Management) Xorg (On Host) BackTrack Linux (Seperate VM)
Basic Test Results: CentOS Zimbra Server: SUCCESSFUL CentOS FreeIPA Server: SUCCESSFUL CentOS FreeIPA Client: SUCCESSFUL+ CentOS HTTP Server: SUCCESSFUL
Detailed Test Results:
---------------------- CentOS Zimbra Server ---------------------- This VM was successfully upgrade without any issues. After rebooting it rebooted to CentOS 6.4 (Though listed it's self as 6.3 still) and was running the CR kernel.
After the reboot I installed and configured Shorewall on the VM to ensure IPTables functionality and management, Shorewall successfully configured IPTables with needed ports, using tools from BackTrack I was able to verify this.
Also did some "stability" testing with Backtrack against the VM and all seemed within normal range :-).
To my surprise Zimbra didn't die however, I was expecting the upgrade to have some form of negative effect on it. But it seemed to function correctly without issue. I was able to browse emails on the server, send them and do various admin management tasks. :-)
As such I consider the upgrade "Successful".
---------------------- CentOS FreeIPA Server ---------------------- The server appeared to function correctly after a reboot, I ran several IPA commands to ensure user database was intact and also to ensure hosts DB was intact.
Again server appeared to be running fine, I checked logs and only found errors moaning about PPM being too high for NTPD.
Further investigation into logs indicated NTP was able to sync time successfully anyway.
This could be due to the Hypervisor's clock.
But aside from that, it appeared to function correctly :-).
So marking as "Successful".
---------------------- CentOS FreeIPA Client ---------------------- After upgrade, everything seemed to work fine, even changing passwords of FreeIPA users which I was quite pleased about (this was a bug in 6.3 due to NAT in VirtualBox used during bridging)
So FreeIPA client was actually working better than it was before upgrade. So that gets a big plus from me :-D.
One thing I did notice is at login it now shows "Your password will expire in 90 days". So the communication between client and server is definetly all there.
It successfully got to Desktop (XFCE, Gnome is not actually installed due to previous testing)
Various other stock CentOS apps appear to be working such as firefox, gimp etc.
So marking this as "Successful+" :-)
---------------------- CentOS HTTP Server ---------------------- With this one I mainly wanted to ensure RAID and LUKS didn't get busted during upgrade (Important things to me).
Again, upgrade successful, booted fine after applying updates.
I played with mdadm a little, marked a virtual drive as failed, removed from array, added it back, make sure it got added correctly and synced etc basic stuff really.
After all that rebooted the VM and luks remained intact, and it booted just fine :-).
So I'd say the upgrade was a success :-)
----
Anyhows, hope these results help you guys :-).
CentOS 6.3 FreeIPA Server (Fully Configured), stock -> CentOS 6.4 FreeIPA Server
<snip>
CentOS FreeIPA Server
The server appeared to function correctly after a reboot, I ran several IPA commands to ensure user database was intact and also to ensure hosts DB was intact.
Again server appeared to be running fine, I checked logs and only found errors moaning about PPM being too high for NTPD.
Further investigation into logs indicated NTP was able to sync time successfully anyway.
This could be due to the Hypervisor's clock.
But aside from that, it appeared to function correctly :-).
So marking as "Successful".
I haven't had time to test from CR as of yet (tbh may not have time before GA even) but as a heads up from the upstream mailing list there does exist a condition where the IPA web interface will fail on an upgrade due to a schema issue:
https://www.redhat.com/archives/freeipa-users/2013-February/msg00391.html
The errata is coming to fix it and it only affects IPA installs that started in 6.2 and were upgraded to 6.3 (so started life at IPA 2.0 topologies) it seems... IPA systems installed in 6.3 initially are reported to be fine and there is a manual workaround.
However upstream is recommending people not update their systems until the errata is out (and I guess include that during the update rather than to the 6.4 'point in time') ...
Depending on when the CentOS 6.4 GA is this might be a required note in the release notes...
On Fri, 1 Mar 2013 13:00:35 +0000 James Hogarth james.hogarth@gmail.com wrote:
CentOS 6.3 FreeIPA Server (Fully Configured), stock -> CentOS 6.4 FreeIPA Server
<snip>
CentOS FreeIPA Server
The server appeared to function correctly after a reboot, I ran several IPA commands to ensure user database was intact and also to ensure hosts DB was intact.
Again server appeared to be running fine, I checked logs and only found errors moaning about PPM being too high for NTPD.
Further investigation into logs indicated NTP was able to sync time successfully anyway.
This could be due to the Hypervisor's clock.
But aside from that, it appeared to function correctly :-).
So marking as "Successful".
I haven't had time to test from CR as of yet (tbh may not have time before GA even) but as a heads up from the upstream mailing list there does exist a condition where the IPA web interface will fail on an upgrade due to a schema issue:
https://www.redhat.com/archives/freeipa-users/2013-February/msg00391.html
The errata is coming to fix it and it only affects IPA installs that started in 6.2 and were upgraded to 6.3 (so started life at IPA 2.0 topologies) it seems... IPA systems installed in 6.3 initially are reported to be fine and there is a manual workaround.
However upstream is recommending people not update their systems until the errata is out (and I guess include that during the update rather than to the 6.4 'point in time') ...
Depending on when the CentOS 6.4 GA is this might be a required note in the release notes...
Thanks for the heads up :-).
All of the VM's I tested started life as CentOS 6.3 (via PXE kickstart) originally which is why it may not have affected me :-).
hi,
By now most people would have seen or atleast have spotted the 6.3/cr/ repos are populated and updates there announced to the cr-announce list.
6.4 is a big release, lots of changes and lots of feedback about things ( also, we found in our limited testing that there are some surprises around the corners! )
I've updated some hosts on real hardware and vms on KVM. There were no big surprises but the following things showed up:
1) On a KVM server, using macvtap with SELinux enabled work now out of the box, with 6.3 it didn't.
2) This bug should now be fixed
https://bugzilla.redhat.com/show_bug.cgi?id=713546
however, instead of the one above I see new issues like described here
https://bugzilla.redhat.com/show_bug.cgi?id=767127
and
https://bugzilla.redhat.com/show_bug.cgi?id=770545
While the system seems to run anyway I'm not sure what to think of it. Does anybody know what #770545 contains. While it is said to be harmless the BZ entry gives me "Access Denied" so I'm wondering if it's really so harmless.
Apart from that things seem fine.
Regards, Simon
On 03/01/2013 09:36 AM, Simon Matter wrote:
hi,
By now most people would have seen or atleast have spotted the 6.3/cr/ repos are populated and updates there announced to the cr-announce list.
6.4 is a big release, lots of changes and lots of feedback about things ( also, we found in our limited testing that there are some surprises around the corners! )
I've updated some hosts on real hardware and vms on KVM. There were no big surprises but the following things showed up:
- On a KVM server, using macvtap with SELinux enabled work now out of the
box, with 6.3 it didn't.
- This bug should now be fixed
I can't see this one ^^
however, instead of the one above I see new issues like described here
Is this with kernel-2.6.32-358.0.1.el6 or kernel-2.6.32-358.el6?
and
I can't see this one ^^
While the system seems to run anyway I'm not sure what to think of it. Does anybody know what #770545 contains. While it is said to be harmless the BZ entry gives me "Access Denied" so I'm wondering if it's really so harmless.
On 03/01/2013 09:36 AM, Simon Matter wrote:
hi,
By now most people would have seen or atleast have spotted the 6.3/cr/ repos are populated and updates there announced to the cr-announce list.
6.4 is a big release, lots of changes and lots of feedback about things ( also, we found in our limited testing that there are some surprises around the corners! )
I've updated some hosts on real hardware and vms on KVM. There were no big surprises but the following things showed up:
- On a KVM server, using macvtap with SELinux enabled work now out of
the box, with 6.3 it didn't.
- This bug should now be fixed
I can't see this one ^^
Ops, you're right it's also 'private' now. Don't remember how I came on the CC list which is why I can see it I guess.
however, instead of the one above I see new issues like described here
Is this with kernel-2.6.32-358.0.1.el6 or kernel-2.6.32-358.el6?
and
I can't see this one ^^
Yes, me too, that's why I was interested to know what it is.
I'm running 2.6.32-358.0.1.el6.x86_64 and I see crap like this in my logs:
Mar 1 17:21:16 archive01 kernel: swapper: page allocation failure. order:1, mode:0x20 Mar 1 17:21:16 archive01 kernel: Pid: 0, comm: swapper Not tainted 2.6.32-358.0.1.el6.x86_64 #1 Mar 1 17:21:16 archive01 kernel: Call Trace: Mar 1 17:21:16 archive01 kernel: <IRQ> [<ffffffff8112c207>] ? __alloc_pages_nodemask+0x757/0x8d0 Mar 1 17:21:16 archive01 kernel: [<ffffffff81166ab2>] ? kmem_getpages+0x62/0x170 Mar 1 17:21:16 archive01 kernel: [<ffffffff811676ca>] ? fallback_alloc+0x1ba/0x270 Mar 1 17:21:16 archive01 kernel: [<ffffffff8116711f>] ? cache_grow+0x2cf/0x320 Mar 1 17:21:16 archive01 kernel: [<ffffffff81167449>] ? ____cache_alloc_node+0x99/0x160 Mar 1 17:21:16 archive01 kernel: [<ffffffff811683cb>] ? kmem_cache_alloc+0x11b/0x190 Mar 1 17:21:16 archive01 kernel: [<ffffffff81439c18>] ? sk_prot_alloc+0x48/0x1c0 Mar 1 17:21:16 archive01 kernel: [<ffffffff8143acf2>] ? sk_clone+0x22/0x2e0 Mar 1 17:21:16 archive01 kernel: [<ffffffff81489bc6>] ? inet_csk_clone+0x16/0xd0 Mar 1 17:21:16 archive01 kernel: [<ffffffff814a2ad3>] ? tcp_create_openreq_child+0x23/0x450 Mar 1 17:21:16 archive01 kernel: [<ffffffff814a02cd>] ? tcp_v4_syn_recv_sock+0x4d/0x310 Mar 1 17:21:16 archive01 kernel: [<ffffffff814a2876>] ? tcp_check_req+0x226/0x460 Mar 1 17:21:16 archive01 kernel: [<ffffffff8149fd6b>] ? tcp_v4_do_rcv+0x35b/0x430 Mar 1 17:21:16 archive01 kernel: [<ffffffff81065c54>] ? enqueue_task_fair+0x64/0x100 Mar 1 17:21:16 archive01 kernel: [<ffffffff814a157e>] ? tcp_v4_rcv+0x4fe/0x8d0 Mar 1 17:21:16 archive01 kernel: [<ffffffff8147f36d>] ? ip_local_deliver_finish+0xdd/0x2d0 Mar 1 17:21:16 archive01 kernel: [<ffffffff8147f5f8>] ? ip_local_deliver+0x98/0xa0 Mar 1 17:21:16 archive01 kernel: [<ffffffff8147eabd>] ? ip_rcv_finish+0x12d/0x440 Mar 1 17:21:16 archive01 kernel: [<ffffffff8147f045>] ? ip_rcv+0x275/0x350 Mar 1 17:21:16 archive01 kernel: [<ffffffff8144827b>] ? __netif_receive_skb+0x4ab/0x750 Mar 1 17:21:16 archive01 kernel: [<ffffffff8149e89a>] ? tcp4_gro_receive+0x5a/0xd0 Mar 1 17:21:16 archive01 kernel: [<ffffffff8144a658>] ? netif_receive_skb+0x58/0x60 Mar 1 17:21:16 archive01 kernel: [<ffffffff8144a760>] ? napi_skb_finish+0x50/0x70 Mar 1 17:21:16 archive01 kernel: [<ffffffff8144cd09>] ? napi_gro_receive+0x39/0x50 Mar 1 17:21:16 archive01 kernel: [<ffffffffa0115bb8>] ? tg3_poll_work+0x788/0xe50 [tg3] Mar 1 17:21:16 archive01 kernel: [<ffffffff810a7b05>] ? tick_dev_program_event+0x65/0xc0 Mar 1 17:21:16 archive01 kernel: [<ffffffffa011df10>] ? tg3_poll+0x70/0x440 [tg3] Mar 1 17:21:16 archive01 kernel: [<ffffffff81076d58>] ? irq_exit+0x48/0x90 Mar 1 17:21:16 archive01 kernel: [<ffffffff8144ce23>] ? net_rx_action+0x103/0x2f0 Mar 1 17:21:16 archive01 kernel: [<ffffffff81076fb1>] ? __do_softirq+0xc1/0x1e0 Mar 1 17:21:16 archive01 kernel: [<ffffffff810e1720>] ? handle_IRQ_event+0x60/0x170 Mar 1 17:21:16 archive01 kernel: [<ffffffff8100c1cc>] ? call_softirq+0x1c/0x30 Mar 1 17:21:16 archive01 kernel: [<ffffffff8100de05>] ? do_softirq+0x65/0xa0 Mar 1 17:21:16 archive01 kernel: [<ffffffff81076d95>] ? irq_exit+0x85/0x90 Mar 1 17:21:16 archive01 kernel: [<ffffffff81516d75>] ? do_IRQ+0x75/0xf0 Mar 1 17:21:16 archive01 kernel: [<ffffffff8100b9d3>] ? ret_from_intr+0x0/0x11 Mar 1 17:21:16 archive01 kernel: <EOI> [<ffffffff8103b90b>] ? native_safe_halt+0xb/0x10 Mar 1 17:21:16 archive01 kernel: [<ffffffff8101495d>] ? default_idle+0x4d/0xb0 Mar 1 17:21:16 archive01 kernel: [<ffffffff81014a5d>] ? c1e_idle+0x9d/0x120 Mar 1 17:21:16 archive01 kernel: [<ffffffff81009fc6>] ? cpu_idle+0xb6/0x110 Mar 1 17:21:16 archive01 kernel: [<ffffffff814f300a>] ? rest_init+0x7a/0x80 Mar 1 17:21:16 archive01 kernel: [<ffffffff81c27f7b>] ? start_kernel+0x424/0x430 Mar 1 17:21:16 archive01 kernel: [<ffffffff81c2733a>] ? x86_64_start_reservations+0x125/0x129 Mar 1 17:21:16 archive01 kernel: [<ffffffff81c27438>] ? x86_64_start_kernel+0xfa/0x109
[root@archive01 ~]# free total used free shared buffers cached Mem: 8059636 7755352 304284 0 6879212 93708 -/+ buffers/cache: 782432 7277204 Swap: 4095992 20432 4075560
I was having this in sysctl.conf for some time without any problems and have removed it now.
# Workaround for https://bugzilla.redhat.com/show_bug.cgi?id=713546 vm.min_free_kbytes = 512000 vm.zone_reclaim_mode = 1
Regards, Simon
On Fri, Mar 1, 2013 at 9:41 AM, Simon Matter simon.matter@invoca.ch wrote:
On 03/01/2013 09:36 AM, Simon Matter wrote:
I can't see this one ^^
Yes, me too, that's why I was interested to know what it is.
I cannot see it either. However, it looks like that BZ is related to this article:
https://access.redhat.com/knowledge/solutions/90883
Akemi
On Fri, Mar 1, 2013 at 9:41 AM, Simon Matter simon.matter@invoca.ch wrote:
On 03/01/2013 09:36 AM, Simon Matter wrote:
I can't see this one ^^
Yes, me too, that's why I was interested to know what it is.
I cannot see it either. However, it looks like that BZ is related to this article:
That's my problem, it's supposed to be fixed with kernel-2.6.32-358.el6 but in my case it doesn't seem so. Maybe I'm missing something but I don't understand what.
Simon
Hi
This was brought up on irc a few days ago, and is now reported in the wild as well, http://bugs.centos.org/view.php?id=6274
- KB
-
Akemi Yagi -
Jake Shipton -
James Hogarth -
Johnny Hughes -
Karanbir Singh -
Karanbir Singh -
Manuel Wolfshant -
Nux! -
Simon Matter