[gentoo-user] Corrupt portage cache

[gentoo-user] Corrupt portage cache

[Mick]

Hi All,

I am trying to update/upgrade a box that has been standing for the
last year or so and this is what I have up to:
====================================
# emerge --metadata -v

>>> Updating Portage cache:      Traceback (most recent call last):
  File "/usr/bin/emerge", line 4049, in ?
    emerge_main()
  File "/usr/bin/emerge", line 4008, in emerge_main
    action_metadata(settings, portdb, myopts)
  File "/usr/bin/emerge", line 3019, in action_metadata
    eclass_cache=ec, verbose_instance=noise_maker)
  File "/usr/lib/portage/pym/cache/util.py", line 47, in mirror_cache
    if trg and not write_it:
  File "/usr/lib/python2.4/UserDict.py", line 170, in __len__
    return len(self.keys())
  File "/usr/lib/portage/pym/cache/mappings.py", line 54, in keys
    return list(self.__iter__())
  File "/usr/lib/portage/pym/cache/mappings.py", line 48, in __iter__
    for k in self.orig.iterkeys():
  File "/usr/lib/python2.4/UserDict.py", line 103, in iterkeys
    return self.__iter__()
  File "/usr/lib/portage/pym/cache/mappings.py", line 83, in __iter__
    return iter(self.keys())
  File "/usr/lib/portage/pym/cache/mappings.py", line 87, in keys
    self.d.update(self.pull())
  File "/usr/lib/portage/pym/cache/flat_hash.py", line 29, in callit
    return args[0](*args[1:]+args2)
  File "/usr/lib/portage/pym/cache/flat_hash.py", line 47, in _pull
    raise cache_errors.CacheCorruption(cpv, e)
cache.cache_errors.CacheCorruption:
app-accessibility/SphinxTrain-0.9.1-r1 is corrupt: dictionary update
sequence element #0 has length 1; 2 is required
====================================

Any idea how to fix it?
-- 
Regards,
Mick
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Corrupt portage cache

[Fabrice Delliaux]

Le Sun, 26 Nov 2006 11:56:43 +0000,
Mick a écrit :

> Hi All,

Hi,

> I am trying to update/upgrade a box that has been standing for the
> last year or so and this is what I have up to:
> ====================================
> # emerge --metadata -v

[...]

> 
> Any idea how to fix it?

Try :

  # rm -rf /usr/portage/metadata/cache/* && emerge --sync

Assumed that /usr/portage is the current location of your portage tree.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Corrupt portage cache

[Mick]

[-- Attachment #1: Type: text/plain, Size: 486 bytes --]

On Sunday 26 November 2006 12:20, Fabrice Delliaux wrote:
> Le Sun, 26 Nov 2006 11:56:43 +0000,
>
> Mick a écrit :

> > I am trying to update/upgrade a box that has been standing for the
> > last year or so and this is what I have up to:
> > ====================================
> > # emerge --metadata -v
>
> [...]
>
> > Any idea how to fix it?
>
> Try :
>
>   # rm -rf /usr/portage/metadata/cache/* && emerge --sync

Thanks!  That fixed it.

-- 
Regards,
Mick

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: Corrupt portage cache

[Harm Geerts]

On Sunday 26 November 2006 13:20, Fabrice Delliaux wrote:
> Le Sun, 26 Nov 2006 11:56:43 +0000,
> > Any idea how to fix it?
>
> Try :
>
>   # rm -rf /usr/portage/metadata/cache/* && emerge --sync
>
> Assumed that /usr/portage is the current location of your portage tree.

This is not the way to fix it.
This only forces portage to retrieve *all* of portage's metadata from the 
server *again*. If the corruption is local, a normal rsync will fix this. If 
the corruption is on the upstream rsync mirror, you will retrieve the same 
corrupt metadata again.

removing the metadata from the portage tree only results in more data 
transfers from the rsync mirror.

This error will resolve itself when the corruption is synced out, upstream or 
local. To speed that process up, you can switch to a different rsync mirror 
and sync against that. That will eliminate both possible corruptions.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Corrupt portage cache

[Fabrice Delliaux]

Le Sun, 26 Nov 2006 13:41:56 +0100,
Harm Geerts a écrit :
> This only forces portage to retrieve *all* of portage's metadata from
> the server *again*.

Yes.

> If the corruption is local, a normal rsync will fix this.

Not necessarily. See bug #145482.
Synchronization again and again (on several days) didn't resolve this.
I removed the entire cache, as suggested, and it magically worked.
And I discovered later that the filesystem was corrupted.

> If the corruption is on the upstream rsync mirror, you will retrieve
> the same corrupt metadata again.

I've never seen that case.

> removing the metadata from the portage tree only results in more data 
> transfers from the rsync mirror.

Yes, but obviously, you must not do it every day.

@Mick : I suggest that you run a fsck on your filesystem.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Corrupt portage cache

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1265 bytes --]

On Sunday 26 November 2006 13:33, Fabrice Delliaux wrote:
> Le Sun, 26 Nov 2006 13:41:56 +0100,
>
> Harm Geerts a écrit :
> > This only forces portage to retrieve *all* of portage's metadata from
> > the server *again*.
>
> Yes.
>
> > If the corruption is local, a normal rsync will fix this.
>
> Not necessarily. See bug #145482.
> Synchronization again and again (on several days) didn't resolve this.
> I removed the entire cache, as suggested, and it magically worked.
> And I discovered later that the filesystem was corrupted.
>
> > If the corruption is on the upstream rsync mirror, you will retrieve
> > the same corrupt metadata again.
>
> I've never seen that case.
>
> > removing the metadata from the portage tree only results in more data
> > transfers from the rsync mirror.
>
> Yes, but obviously, you must not do it every day.
>
> @Mick : I suggest that you run a fsck on your filesystem.

Thanks.  I did run fsck and everything seems fine.  However, although 
emerge --metadata worked, the following emerge --sync failed with the same 
old error.

So, this time I did emerge --regen and when it finished the emerge --sync 
worked without any more problems.

Thanks for all the suggestions.
-- 
Regards,
Mick

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]