Created attachment 322648 [details] Crash dump of pirut launch Description of problem: pirut (pup) crashes on launch with the following message. Component: pirut Summary: TB9536d0ca <string>:64:__iter__:SyntaxError: mismatched tag: line 53386, column 8 This happens no matter how the application is launched. I have seen this now on two different RHEL5 systems. Yum and up2date both appear fine, and yum lists the following updates ready for my system. kernel.i686 2.6.18-92.1.17.el5 rhel-i386-server kernel-devel.i686 2.6.18-92.1.17.el5 rhel-i386-server kernel-headers.i386 2.6.18-92.1.17.el5 rhel-i386-server net-snmp-libs.i386 1:5.3.1-24.el5_2.2 rhel-i386-server systemtap.i386 0.6.2-1.el5_2.2 rhel-i386-server systemtap-runtime.i386 0.6.2-1.el5_2.2 rhel-i386-server tzdata.noarch 2008i-1.el5 rhel-i386-server Version-Release number of selected component (if applicable): How reproducible: Every time pup is launched, this is happening. I first noticed this this morning when the updater notification appeared and said that I was no longer getting updates. When I clicked it, pup started, the window was drawn, and then it crashed. On the other system I have, I just tried to launch pup from the applications->system tools->Software Updates. Same crash from command line. Steps to Reproduce: 1. Launch pup Actual results: crash Expected results: list of available updates. Additional info: Yum appears fine. Ran "yum clean all" hoping it was a cache issue, but not. "yum check-update" returns the above list of packages.
Created attachment 322651 [details] The pirut generated update list.
The /var/cache/yum/rhel-i386-server-5/updateinfo.xml.gz file is not being created correctly? It also generates an error when opening with firefox, at the next location in the file from where pirut errors at. The version of pirut that is installed on both my machines is: 1.3.28-13.el5
Upon further inspection (sorry, I'm new at this). When looking closer at the xml file (go vim), it is this section that pirut is barfing on. <reference href="http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=467105" id="467105" type="bugzilla"> ['xm trigger <domain> init causes kernel panic.'] </reference> It appears that both pirut and firefox believe that the bug description has a malformed piece of XML <domain> instead of an escaped comment.
I have verified that updating the kernel package that contains the problematic text using yum does indeed "fix" this crash. However, the mis-parsing/generation of the updateinfo.xml.gz file does appear to be a genuine bug.
Thanks, there isn't anything yum/pirut/etc. can do about this ... reassigning to the RHN people.
*** Bug 470091 has been marked as a duplicate of this bug. ***
added user story http://wwwapps.rdu.redhat.com:8080/xplanner/do/view/userstory?oid=59468
*** Bug 470349 has been marked as a duplicate of this bug. ***
I am the Linux Platform Coordinator at MIT, and can report two additional facts about this bug: 1. It also manifests as a scary pop-up message from the software updater applet in the menu bar. It says that the system is not receiving updates, and tells the user to check the network connection or register for updates. This is going to be VERY upsetting to anyone using Satellite server. 2. This bug will be biting hundreds of desktop RHEL users at MIT. Please note that we have mentioned this bugzilla in a Service Request, but we don't have a TAM. Any expedited examination of this bug would be MOST welcome. -Bill Cattey
Question for Jim who originally reported this problem: Are you getting RHN from a version 4.2 Satellite Server or from some other RHN source?
I finally had the software updater applet run. Here is the actual text of the scary message: System is not receiving updates Your system is currently not receiving software updates. Please check your network connection and/or set up software updates. [Don't notify me again ]
I (shamefully) have no idea what the details of the Satellite Server that I am connecting to are. The University of Washington has excellent instructions posted to get a RHEL system connected to their RHN servers. I have just set up this up and didn't worry about it until it broke. I have asked for elaboration, and will forward any information as I receive it.
Also experiencing this issue with clients talking to a Satellite 5.0.2 server. Does someone here already have an SR open for this? Attaching the traceback we received.
Created attachment 323211 [details] Traceback from RHEL5.2 x86_64 machine
I have confirmed that the University of Washington RHN satellite server is version 4.2.
Created attachment 323362 [details] Crash report pirut Pirut is crashing again as of this morning with the same error. Attached is the crash file. It appears that the kernel package was updated on 11/11/2008, and the malformed text is still in the package. The following packages are ready for me to update at the moment: dmraid.i386 1.0.0.rc13-14.el5_2.1 rhel-i386-server gnutls.i386 1.4.1-3.el5_2.1 rhel-i386-server gnutls-devel.i386 1.4.1-3.el5_2.1 rhel-i386-server httpd.i386 2.2.3-11.el5_2.4 rhel-i386-server httpd-manual.i386 2.2.3-11.el5_2.4 rhel-i386-server kernel.i686 2.6.18-92.1.18.el5 rhel-i386-server kernel-devel.i686 2.6.18-92.1.18.el5 rhel-i386-server kernel-headers.i386 2.6.18-92.1.18.el5 rhel-i386-server lvm2.i386 2.02.32-4.el5_2.1 rhel-i386-server mod_ssl.i386 1:2.2.3-11.el5_2.4 rhel-i386-server
*** Bug 471379 has been marked as a duplicate of this bug. ***
There are two places to fix this: 1. Make RHN generate correct XML so that pirut will not choke. 2. Make pirut robust against mal-formed XML. Red Hat is working the problem from the RHN side. The relevant bugzillas for the Satellite Server component of the RHN product are: 428819 and 470932. QUESTION: Is a fix to pirut to be more robust against mal-formed XML comment, or is the traceback the best we can get? If no change to pirut is possible or cost effective, this bug should be closed, and people should be pointed to the relevant hotfix for their Satellite Server. Sites with Satellite Server that are experiencing this problem should contact Red Hat for help in any event. Tell them to refer to the MIT Service Request 1871768 to come up to speed quickly.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1434.html