Bug 868999

Summary:	Attempting to update via yum -C produces database error Check uncompressed DB failed
Product:	[Fedora] Fedora	Reporter:	Josh Trutwin <jtrutwin>
Component:	yum	Assignee:	Fedora Packaging Toolset Team <packaging-team>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	17	CC:	admiller, ffesti, james.antill, packaging-team, tim.lauridsen, zpavlas
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-11-26 18:00:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Josh Trutwin 2012-10-22 17:37:08 UTC

Description of problem:


Hi - I'm not sure if this is a bug or feature as intended - but starting with a bug report...

I upgraded a number of lab computers from Fedora 14 to Fedora 17 this summer and a process I used to push patches out to them en mass no longer works.

What I used to do was:

yum --downloadonly --security update

Then I would copy /var/cache/yum to a shared NFS drive and from each client run an update script that would include:

rm -rf /var/cache/yum
cp -pR /nfs/yum-cache /var/cache/yum
yum -C -y --security update

In fedora 14 this would run the yum update from the local cache (-C option) without prompting via -y so I could script/push security patches to all my clients.  I use this method as occasionally some of the clients are offline and need to be manually started up - this way I can be sure each client has the exact same patches.

In fedora 17 when I do this I get the following error message when running the yum -C command on the client:

[Error -1] Check uncompressed DB failed

Is this a bug or is this process simply not allowed anymore?  If not is there an alternate way to do what I'm attempting?

Thank you!



Version-Release number of selected component (if applicable):


Fedora 17 - x86_64


How reproducible:


On system 1:

yum --downloadonly update

On system 2:

rm -rf /var/cache/yum
scp -r system1:/var/cache/yum /var/cache
yum -C -y update


  
Actual results:


[Error -1] Check uncompressed DB failed


Expected results:


yum updates applied


Additional info:


Worked on Fedora 14 - did not try 15/16.

Let me know if any needed.

Comment 1 Zdeněk Pavlas 2012-10-24 09:31:06 UTC

Just a quick guess: cachedir has moved from /var/cache/yum/ to /var/cache/yum/$basearch/$releasever between F14 and F17..

Comment 2 James Antill 2012-10-24 16:49:49 UTC

I'd also suggest you look at "yum load-transaction", which is pretty much designed for your usecase.

Comment 3 Josh Trutwin 2012-10-24 16:58:48 UTC

(In reply to comment #1)
> Just a quick guess: cachedir has moved from /var/cache/yum/ to
> /var/cache/yum/$basearch/$releasever between F14 and F17..

Actually both my fedora 14 and 17 systems have identical directory structures (other than 14 being 17)

Comment 4 Josh Trutwin 2012-10-24 17:16:16 UTC

(In reply to comment #2)
> I'd also suggest you look at "yum load-transaction", which is pretty much
> designed for your usecase.

Thanks for the pointer - the man page doesn't go into much detail, does this cause it to download on each system?  The nice thing with copying the cache around is it avoided all the extra downloading.  Is there any way to get this to work using the steps above?  I unfortunately am also in the situation where I have NEARLY identical systems where a few might have one or two single additional RPMs installed, when reading up on load transation is says: "Note, however that the rpmdb version stored in the file must be identical to the version on the target system." which would make the load-transaction command fail.

Comment 5 James Antill 2012-10-26 15:03:08 UTC

(In reply to comment #4)
> (In reply to comment #2)
> > I'd also suggest you look at "yum load-transaction", which is pretty much
> > designed for your usecase.
> 
> Thanks for the pointer - the man page doesn't go into much detail, does this
> cause it to download on each system?

Yes, load-transaction only does the actual transaction and not the rpms. So you still need to copy the cache of rpms about.

I also noticed that you are copying the cache around with "scp -r" this is likely the root of the problem you are hitting. You need to preserve timestamps, so use "rsync -a -e ssh" (generally much easier/faster for things like this) or at worst "scp -rp".

>                                       The nice thing with copying the cache
> around is it avoided all the extra downloading.  Is there any way to get
> this to work using the steps above?  I unfortunately am also in the
> situation where I have NEARLY identical systems where a few might have one
> or two single additional RPMs installed, when reading up on load transation
> is says: "Note, however that the rpmdb version stored in the file must be
> identical to the version on the target system." which would make the
> load-transaction command fail.

Yes, I would recommend you not do this. Just install the extra rpms on all the computers so that "yum version" is the same on all of them, this will make your life a lot easier and less painful.

Comment 6 Josh Trutwin 2012-11-26 18:00:16 UTC

Just a followup, the -p to scp/cp was the problem.  Sorry for the noise.