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.
Just a quick guess: cachedir has moved from /var/cache/yum/ to /var/cache/yum/$basearch/$releasever between F14 and F17..
I'd also suggest you look at "yum load-transaction", which is pretty much designed for your usecase.
(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)
(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.
(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.
Just a followup, the -p to scp/cp was the problem. Sorry for the noise.