stig mogensen

I'm trying to get rid of the ever growing kernel sources building up
in /usr/src/, to free up discspace.

I Google, to find methods that can show me what kernelversions I have
installed, before I select the ones to emerge -C, but they all use the qpkg
command. This command is deprecated in gentoolkit.

Does anyone have a safe way to remove ALL files belonging to old unused
kernels?.

/Stig

--
* Registered Linux user #291266, with http://counter.li.org.*

j.o. aho

the new command to use is equery, to see isntalled versions do

equery list -i gentoo-sources

another method, which tends to be faster is

emerge -Cp gentoo-sources

but that has it's dangers if you misse to add the 'p'.

if you still want to use qpkg, you can find it in /usr/lib/gentoolkit/bin/ but
thats not for long, think it's completely removed in next stable version, so
copy it somewhere else if you want to keep it, but it may stop working
properly soon.


//Aho

arthur hagen

emerge -p -P sys-kernel/gentoo-sources

But that's not safe if you have emerged but not yet compiled and
installed one or more kernel versions (or emerged them out of order).

Perhaps this one, which will only uninstall versions older than the
currently _running_ kernel:

emerge -p -C "<sys-kernel/gentoo-sources-`uname -r | sed 's/gentoo-//'`"


Remove the -p (--pretend) when satisified it does what you want.

Regards,
--
*Art

darin mcbride

Rather than figure this stuff out, I've just been using kpackage - it seems
to handle portage just fine. Then I can select individual kernels, hit the
uninstall button, type in my root password, and away it goes. I keep the
one I'm running and the latest that I haven't upgraded to - not sure what I
would do if I was already at the latest (i.e., not sure which one I'd
keep), I suppose I'd have to try to remember which one I used to run to
keep that one.

peter jensen

I doubt it'll completely go away any time soon. There is no real
alternative to revdep-rebuild, and it currently depends on qpkg. qpkg
is also still significantly faster than the equivalent equery command.
Compare and contrast:

$ time qpkg -f /usr/bin/revdep-rebuild
app-portage/gentoolkit *

real 0m0.178s
user 0m0.036s
sys 0m0.112s

$ time equery belongs /usr/bin/revdep-rebuild
[ Searching for file(s) /usr/bin/revdep-rebuild in *... ]
app-portage/gentoolkit-0.2.0-r3 (/usr/bin/revdep-rebuild)

real 0m17.861s
user 0m13.173s
sys 0m0.368s

For the sake of fairness, both tests were done a couple of times, so
that file caching did not affect the result. equery consistently takes
much longer, and I doubt that will change any time soon.

--
PeKaJe

Statisticians do it with 95% confidence.

j.o. aho

It was only that when I read the ~x86 version of gentoolkit, it said it was
removed and wasn't part of the package anymore, comparing to the current x86
version where you get the path to the qpkg and which just stated that it would
be removed in the future, thats why I wrote as I wrote.

When it comes to speed, IMHO the whole portage system is painfully slow as
it's written in python. Did think I got a bit of preformance boost when moving
to the cdb hack (can be found in the gentoo wikipedia), but not cared about
compare it that closely.


//Aho

peter jensen

I see that they did indeed remove it, and of course hack revdep-rebuild
further, so that it not require qpkg. It really saddens me to see this
useful tool go. I know that equery is set to replace it, but it's just
way too slow to ever be usable for the qpkg -f command, which is what I
use the most. If they would rethink the way it uses the database, then
I might reconsider. Until then, I'll continue to use qpkg.

It's not as much the fact that portage is written in python (so is
equery, but it's blindingly fast). The big trouble these days is the
portage database layout. It has some advantages, but speed is not one
of them.

--
PeKaJe

Microsoft products are easy to administrate. Anyone can do it!
Even if you don't want them to ... -- Jim Richardson, in COLA

david

This method may not be a "pure" remove, but it has worked for me many
times in practice; before doing this have the new kernel booted and
working of course:

emerge -C <kernel-version>
rm -rf /usr/src/linux-<kernel-version>
rm -rf /lib/modules/<kernel-version>
rm -rf /boot/<bzImage>

~David~

j.o. aho

When looking on comparisons between different "scripting" languages, python
has always been the slowest one on the tests I have seen, perl seems to be up
to 4 times faster, but of course it depends on a bit what the scripts are
doing. I really wish for a static binary + db combination, that would give
best performance, but of course more difficult to code.


//Aho

peter jensen

Yes, but the scripting language itself is not the bottle-neck here.
Look at how the portage system works, and you'll see why it currently
runs quite slow. At any rate, I'd rather have 4 times slower python,
which is actually readable by human beings, than ultra-fast perl scripts
that resemble line noise.

And more error-prone. -- PeKaJe

Then you have the IQ and computer proficiency of a 12 day old
dried lump of donkey feces. -- Philip Callan in COLA