|Summary:||Database out-of-date with system despite regular up2date/rhn_check|
|Product:||Red Hat Satellite 5||Reporter:||Mike Potts <maspotts>|
|Component:||Other||Assignee:||Bret McMillan <bretm>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Red Hat Satellite QA List <satellite-qa-list>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2003-04-14 14:29:01 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Mike Potts 2003-04-08 03:04:48 UTC
From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020916 Description of problem: Using up2date my system is consistent: when a new errata is announced, up2date finds it and applies it. But in the errata view of the Red Hat Network website for this machine I am prompted to apply errata updates which I know have already been applied via update (verified using rpm -q). Version-Release number of selected component (if applicable): up2date-2.8.39-1.7.1 How reproducible: Always Steps to Reproduce: 1. Log into red hat network as maspotts 2. Click on Errata or Packages 3. Observe errata RPMS and compare with system via 'rpm -q' Actual Results: eg. I have: python-1.5.2-43.71 installed, but I see (under Packages) python-1.5.2-43.71.i386.rpm is a critical up2date that has not yet been applied. If I look in the 'List/Remove Packages' screen then it tells me that I have python-1.5.2-42.71 installed. Expected Results: The database should accurately reflect my system, since up2date is working properly and I have run it, and rhn_check today, and regularly in the recent past. Additional info:
Comment 1 Bret McMillan 2003-04-08 03:19:28 UTC
Try running 'up2date -p' from the command line and see if that helps. up2date can function even if RHN does not have your package profile. The website, on the other hand, requires a system's package profile to be useful.
Comment 2 Mike Potts 2003-04-08 05:27:25 UTC
Ran 'update -p', but got usual message about 'demo service disabled'. Problem persists, although last check-in date now matches the 'update -p' time, but I don't know whether the disabled demo service prevented the synchronisation from taking place.
Comment 3 Bret McMillan 2003-04-08 13:42:57 UTC
If the message was along the lines of: Demo service currently disabled due to high load. If you would like to see Red Hat's policies on Demo service, or find out how you can purchase a subscription service and receive priority download access, please go to http://rhn.redhat.com/preview/index.pxt then try again when we're not throttling our servers. Currently, the machines look pretty open, so I'd try again soon.
Comment 4 Mike Potts 2003-04-08 16:28:13 UTC
Servers still throttled this morning; I'll keep trying, on and off...
Comment 5 Bret McMillan 2003-04-09 18:00:00 UTC
Any luck yet?
Comment 6 Mike Potts 2003-04-09 18:32:56 UTC
Still getting demo service disable (roughly 10 attempts since yesterday). I'm still trying sporadically...
Comment 7 Mike Potts 2003-04-11 17:13:27 UTC
Still no luck getting past the "demo service disabled" stage; actually I'm finding rhn almost unusable these days using 'demo' service. Fair enough I guess, although it might be less depressing to simple cancel all non-paid service so I wouldn't be tempted to keep trying!
Comment 8 Mike Potts 2003-04-11 23:21:10 UTC
Got in, finally! After running 'update -p' the database is in sync again. Thanks for the advice. Maybe update should sync the database whenever it checks in to retrieve errata, to avoid this situation?
Comment 9 Josef Komenda 2003-04-14 14:29:01 UTC
Works, closing. The problem has been fixed in an upcoming errata, as well as the RH9 release.