Re: apt-get update segmentation fault

On Sat, Jun 21, 2008 at 14:44:51 +0100, Anton Piatek wrote:
2008/6/21 Florian Kulzer :
On Sat, Jun 21, 2008 at 13:04:54 +0100, Anton Piatek wrote:
Hi,
Does anyone know why apt-get crashes when updating?

Hit http://security.debian.org lenny/updates/main Sources
Hit http://security.debian.org lenny/updates/contrib Sources
Hit http://security.debian.org lenny/updates/non-free Sources
Fetched 9B in 2s (4B/s)
Segmentation faultsts... 60%

Removing a deb source solves the problem (5 sources works, 6 fails).
I have had this happen before, with sarge i think, and upgrading apt
to a newer level solved it, however uprading apt now will require
upgrading libperl
My apt is currently at version 0.7.6 on a mixed lenny/sid system (with
some packages from etch, unison in particular)

I think you are not doing yourself any favors by running your system
like that.

Unfortunately unison is designed such that both client and server
versions must match, so as my servers are etch I need the etch version
on my laptop.

I see. As far as I can tell, you can install the Etch version of unison
on a current Sid system.

I need software from Lenny/Sid on my laptop. I suppose I could move to
complete Sid however I do not want to have to worry about the extra
effort of all the extra updates that I would have to install on Sid
rather than Lenny.

It seems that I may have misunderstood what you meant with "mixed
lenny/sid" system. In any case, the differences are not that great:
Right now, 94% of the packages in Sid are also available in Lenny, and
88% of these shared packages are at the same version in both
repositories.

If you need some of those 6% exclusive-to-Sid packages (or the newest
versions of other packages) then I think it is less of a hassle to move
to Sid completely and be done with it (provided that you use
apt-listbugs, apt-listchanges and keep at least one additional kernel
image around).

I hope this explains my previous remark a bit better.

[...]

It is indeed solved by increasing the apt-cache limit. There does
appear to be a bugreport open, though I doubt I can add much to it
without moving apt up to the unstable level.
Aptitude has the same problem, though is more explicit about why.

It seems that once I run apt with a 20mb limit the problem goes away,
so presumably apt is happy keeping the cache at a larger size once it
gets that big.
I will add the option to my config anyway, so hopefully will not see this again.

Is it worth suggesting that the default cache size be increased?

I suspect that the default cache limit is set such that it is
appropriate for a standard sources.list with only "stable" in it.

--
Regards, | http://users.icfo.es/Florian.Kulzer
Florian |


--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx