8:34 p.m.
I decided to clean up some old crud.
# rpm -e kernel-2.6.6-1.435.2.1 kernel-2.6.6-1.435.2.3 kernel-2.6.8-1.521
kernel-2.6.7-1.494.2.2 kernel-2.6.9-1.3_FC2 kernel-2.6.9-1.6_FC2
kernel-2.6.9-1.11_FC2
I was watching this with top(1).
This command took six minutes to complete, with rpm taking up 100% CPU for
six minutes straight.
Yes, these are large packages that are being removed. No, even with all
that, taking six minutes, a dual Opteron box, with SCSI RAID, is
unreasonable.
5:27 a.m.
On Tue, 15 Feb 2005, Sam Varshavchik wrote:
I decided to clean up some old crud.
# rpm -e kernel-2.6.6-1.435.2.1 kernel-2.6.6-1.435.2.3 kernel-2.6.8-1.521
kernel-2.6.7-1.494.2.2 kernel-2.6.9-1.3_FC2 kernel-2.6.9-1.6_FC2
kernel-2.6.9-1.11_FC2
I was watching this with top(1).
This command took six minutes to complete, with rpm taking up 100% CPU for
six minutes straight.
Yes, these are large packages that are being removed. No, even with all
that, taking six minutes, a dual Opteron box, with SCSI RAID, is
unreasonable.
The kernel package runs hardlink on /lib/modules/*/build/ in %post to save
space on FC2 and FC3, that's what's taking so long when installing and
removing kernels. That's no longer the case on devel tree kernels where
the headers have been split out to separate kernel-devel package for those
who need it. Kernel-devel still does the hardlink, but that doesn't
affect nearly as many people.
- Panu -
5:36 a.m.
On Wed, 2005-02-16 at 13:27 +0200, Panu Matilainen wrote:
On Tue, 15 Feb 2005, Sam Varshavchik wrote:
> I decided to clean up some old crud.
>
> # rpm -e kernel-2.6.6-1.435.2.1 kernel-2.6.6-1.435.2.3 kernel-2.6.8-1.521
> kernel-2.6.7-1.494.2.2 kernel-2.6.9-1.3_FC2 kernel-2.6.9-1.6_FC2
> kernel-2.6.9-1.11_FC2
>
> I was watching this with top(1).
>
> This command took six minutes to complete, with rpm taking up 100% CPU for
> six minutes straight.
>
> Yes, these are large packages that are being removed. No, even with all
> that, taking six minutes, a dual Opteron box, with SCSI RAID, is
> unreasonable.
The kernel package runs hardlink on /lib/modules/*/build/ in %post to save
space on FC2 and FC3, that's what's taking so long when installing and
removing kernels. That's no longer the case on devel tree kernels where
the headers have been split out to separate kernel-devel package for those
who need it. Kernel-devel still does the hardlink, but that doesn't
affect nearly as many people.
actually the hardlink doesn't matter for rpm -e, only for rpm -i.
9:37 p.m.
--On Wednesday, February 16, 2005 1:27 PM +0200 Panu Matilainen
<pmatilai(a)welho.com> wrote:
The kernel package runs hardlink on /lib/modules/*/build/ in %post
to
save space on FC2 and FC3, that's what's taking so long when installing
and removing kernels.
What does hardlink do? There appears to be no man page or other
documentation for it in kernel-utils.
9:47 p.m.
Kenneth Porter wrote:
--On Wednesday, February 16, 2005 1:27 PM +0200 Panu Matilainen
<pmatilai(a)welho.com> wrote:
> The kernel package runs hardlink on /lib/modules/*/build/ in %post to
> save space on FC2 and FC3, that's what's taking so long when installing
> and removing kernels.
What does hardlink do? There appears to be no man page or other
documentation for it in kernel-utils.
Hardlinks's identical files to save space.
73 de Jeff
4:29 a.m.
--- Ralf Ertzinger <fedora-devel(a)camperquake.de>
wrote:
Hi.
Jeff Johnson <n3npq(a)nc.rr.com> wrote:
> Hardlinks's identical files to save space.
Does this really pay off? I for one would be glad
for a switch to disable
this.
it does pay off in a big way for systems having a lot
of kernels installed in them which seems to be pretty
typical esp for fedora
=====
Regards
Rahul Sundaram
__________________________________
Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
4:37 a.m.
Hi.
Rahul Sundaram <rahulsundaram(a)yahoo.co.in> wrote:
it does pay off in a big way for systems having a lot
of kernels installed in them which seems to be pretty
typical esp for fedora
What is "a lot"? I currently have the last 6 kernels on this machine.
Given that the hard disk is not the fastest one around, I'd rather
spend the 12MB or so per -devel package than wait ages for hardlink
to finish it's grind though /lib/modules.
--
"What's the use of logic in a world where everyone talks about the
sun setting, when it's really the horizon rising?"
-- Iain Street <eo75(a)dial.pipex.com>
7:26 a.m.
fedora-devel(a)camperquake.de (Ralf Ertzinger) writes:
Does this really pay off? I for one would be glad for a switch to
disable
this.
The only time it's really a real pain imho is when you run your own kernel
because hardlinks is going to update your kernel tree and change ownership
to root on a bunch of files.
--
Mathieu Chouquet-Stringer E-Mail: ml2news(a)optonline.net
"Le disparu, si l'on vénère sa mémoire, est plus présent et
plus puissant que le vivant".
-- Antoine de Saint-Exupéry, Citadelle --
3:36 p.m.
On Thu, 17 Feb 2005 11:22:57 +0100, Ralf Ertzinger
<fedora-devel(a)camperquake.de> wrote:
Hi.
Jeff Johnson <n3npq(a)nc.rr.com> wrote:
> Hardlinks's identical files to save space.
Does this really pay off? I for one would be glad for a switch to disable
this.
An option to disable this would be really nice.
I have kernel sources in a bk repo, and some kernels built from these
in grub.conf.
Whenever hardlink runs, I guess it's hardlinking with the files in the
bk repo, which are read-only (seems to be only Makefiles), and
changing them to rw-r--r--. This causes bk to complain.
Or is there something I could do to make this problem go away?
Thanks -- Andy
10:49 a.m.
tor, 17.02.2005 kl. 04.47 skrev Jeff Johnson:
Kenneth Porter wrote:
> --On Wednesday, February 16, 2005 1:27 PM +0200 Panu Matilainen
> <pmatilai(a)welho.com> wrote:
>
>> The kernel package runs hardlink on /lib/modules/*/build/ in %post to
>> save space on FC2 and FC3, that's what's taking so long when installing
>> and removing kernels.
>
>
> What does hardlink do? There appears to be no man page or other
> documentation for it in kernel-utils.
Hardlinks's identical files to save space.
Why are hardlinks chosen over symlinks here?
10:59 a.m.
On Thu, Feb 17, 2005 at 05:49:50PM +0100, Kyrre Ness Sjobak wrote:
Why are hardlinks chosen over symlinks here?
That's what hardlinks are for. Multiple file system entries to the
same datablocks on disk, so the disk allocation disappears when the
last entry is unlink()ed. Symlinks can not do this.
11 a.m.
On Thu, 2005-02-17 at 17:49 +0100, Kyrre Ness Sjobak wrote:
--
Sean Middleditch <elanthis(a)awesomeplay.com
Why are hardlinks chosen over symlinks here?
If you used
symlinks, then when you removed a kernel, you migth end up
removing the only real copy of a file. With hardlinks, you remove a
kernel, it'll only remove one instance of the file, and the others will
remain, until all kernels using that file are removed.
11 a.m.
On Thu, 2005-02-17 at 17:49 +0100, Kyrre Ness Sjobak wrote:
Why are hardlinks chosen over symlinks here?
Short answer:
Think what happens when you delete a package.
Longer answer:
install kernel-1.0-1 - modules are just put into /lib/mod...
install kernel-1.0-2 - modules added, then converted to symlinks
[now rpm -Vv fails because there are symlinks, not files]
remove kernel-1.0-1
now kernel-1.0-2 has dangling symlinks
(oh, and you can't boot either)
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham(a)InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
12:04 p.m.
Hi.
Nigel Metheringham <Nigel.Metheringham(a)dev.intechnology.co.uk> wrote:
(oh, and you can't boot either)
Huh? What files (except those covered in kernel-devel now) are being
hardlinked? I thought all module files are versioned, so modules from
different kernel builds are not identical.
--
Ergometer = Schlussfolgerungsmessgeraet
12:58 p.m.
Kyrre Ness Sjobak wrote:
tor, 17.02.2005 kl. 04.47 skrev Jeff Johnson:
>Kenneth Porter wrote:
>
>
>
>>--On Wednesday, February 16, 2005 1:27 PM +0200 Panu Matilainen
>><pmatilai(a)welho.com> wrote:
>>
>>
>>
>>>The kernel package runs hardlink on /lib/modules/*/build/ in %post to
>>>save space on FC2 and FC3, that's what's taking so long when
installing
>>>and removing kernels.
>>>
>>>
>>What does hardlink do? There appears to be no man page or other
>>documentation for it in kernel-utils.
>>
>>
>Hardlinks's identical files to save space.
>
>
Why are hardlinks chosen over symlinks here?
Because symlinks behave differently than files in vcertain contexts,
hardlinks are always the same as files.
Look there's a really simple answer to hardlinks and rpm and more:
Choose a kernel, use that.
Chose another kernel, use that, get rid of previous.
With one (or very few) kernels installed, hardlink and rpm performance
is a non-issue.
73 de Jeff
1:16 p.m.
Jeff Johnson wrote:
Kyrre Ness Sjobak wrote:
> tor, 17.02.2005 kl. 04.47 skrev Jeff Johnson:
>
>
>> Kenneth Porter wrote:
>>
>>
>>
>>> --On Wednesday, February 16, 2005 1:27 PM +0200 Panu Matilainen
>>> <pmatilai(a)welho.com> wrote:
>>>
>>>
>>>
>>>> The kernel package runs hardlink on /lib/modules/*/build/ in %post to
>>>> save space on FC2 and FC3, that's what's taking so long when
>>>> installing
>>>> and removing kernels.
>>>>
>>>
>>> What does hardlink do? There appears to be no man page or other
>>> documentation for it in kernel-utils.
>>>
>>
>> Hardlinks's identical files to save space.
>>
>
>
> Why are hardlinks chosen over symlinks here?
>
Look there's a really simple answer to hardlinks and rpm and more:
Choose a kernel, use that.
Chose another kernel, use that, get rid of previous.
With one (or very few) kernels installed, hardlink and rpm performance
is a non-issue.
At a cursory glance, arbitrarily limiting the ability to rollback kernel
upgrades (to a small or larger extent) seems a poor fix. Discovering
kernel flaws or bugs doenst necessarily happen the first time you use
the new kernel and may lay hidden for some time. In my company dictating
acceptable use (outside of normal operating bounds, and without very
good reason) is seen as a red herring of poor design (no implications
intended). I suppose you could just go find and download the older
kernels to test but i honestly dont know where to find archived versions
of kernel updates (that is: not base and not most recent update).
Perhaps i am the only one who doesnt know where to find such things or
maybe information on that subject will reduce the need to keep the
kernels installed. I dont know the issues involved but i hesitate when i
hear answers like the above suggestion to problems like these.
-mf
1:33 p.m.
Michael Favia wrote:
Jeff Johnson wrote:
> Kyrre Ness Sjobak wrote:
>
>> tor, 17.02.2005 kl. 04.47 skrev Jeff Johnson:
>>
>>
>>> Kenneth Porter wrote:
>>>
>>>
>>>
>>>> --On Wednesday, February 16, 2005 1:27 PM +0200 Panu Matilainen
>>>> <pmatilai(a)welho.com> wrote:
>>>>
>>>>
>>>>
>>>>> The kernel package runs hardlink on /lib/modules/*/build/ in
>>>>> %post to
>>>>> save space on FC2 and FC3, that's what's taking so long when
>>>>> installing
>>>>> and removing kernels.
>>>>>
>>>>
>>>>
>>>> What does hardlink do? There appears to be no man page or other
>>>> documentation for it in kernel-utils.
>>>>
>>>
>>>
>>> Hardlinks's identical files to save space.
>>>
>>
>>
>>
>> Why are hardlinks chosen over symlinks here?
>>
>
> Look there's a really simple answer to hardlinks and rpm and more:
>
> Choose a kernel, use that.
>
> Chose another kernel, use that, get rid of previous.
>
> With one (or very few) kernels installed, hardlink and rpm
> performance is a non-issue.
At a cursory glance, arbitrarily limiting the ability to rollback
kernel upgrades (to a small or larger extent) seems a poor fix.
Discovering kernel flaws or bugs doenst necessarily happen the first
time you use the new kernel and may lay hidden for some time. In my
company dictating acceptable use (outside of normal operating bounds,
and without very good reason) is seen as a red herring of poor design
(no implications intended). I suppose you could just go find and
download the older kernels to test but i honestly dont know where to
find archived versions of kernel updates (that is: not base and not
most recent update). Perhaps i am the only one who doesnt know where
to find such things or maybe information on that subject will reduce
the need to keep the kernels installed. I dont know the issues
involved but i hesitate when i hear answers like the above suggestion
to problems like these.
All very well known problems.
As long as you can boot off *some* kernel, any desired kernel package
can be installed.
So "choose" carefully. And if you miss, well, always keep some way to
boot, and copy
available kernel packages out of /var/cache/yum somewhere so the yum
clean does not nuke.
Or have every possible bleeping kernel already pre-installed and never
remove anything.
Unfortunately, that exercises known deficiencies with both rpm and
hardlinks, and is
slower than optimal, so take valium and be patient.
Entirely up to you, it's your machine.
73 de Jeff
1:45 p.m.
On Thu, 17 Feb 2005 14:33:24 -0500, Jeff Johnson <n3npq(a)nc.rr.com> wrote:
Or have every possible bleeping kernel already pre-installed and
never
remove anything.
Unfortunately, that exercises known deficiencies with both rpm and
hardlinks, and is
slower than optimal, so take valium and be patient.
The question becomes... can someone expose reasonable sane default
behavior of some tool to do old kernel pruning... to avoid normal
fedora users from encountering these deficiencies when you have 17 or
so update kernels installed.
-jef
1:58 p.m.
On Thu, 2005-02-17 at 14:45 -0500, Jeff Spaleta wrote:
On Thu, 17 Feb 2005 14:33:24 -0500, Jeff Johnson
<n3npq(a)nc.rr.com> wrote:
> Or have every possible bleeping kernel already pre-installed and never
> remove anything.
> Unfortunately, that exercises known deficiencies with both rpm and
> hardlinks, and is
> slower than optimal, so take valium and be patient.
The question becomes... can someone expose reasonable sane default
behavior of some tool to do old kernel pruning... to avoid normal
fedora users from encountering these deficiencies when you have 17 or
so update kernels installed.
I may be able to do so.
keep the kernel you're running and all newer than that.
older kernels, remove.
have a text file which can specify kernels-versions to keep/ignore from
removal.
-sv
2:07 p.m.
seth vidal wrote:
keep the kernel you're running and all newer than that.
older kernels, remove.
have a text file which can specify kernels-versions to keep/ignore
from removal.
I'd rather see "keep the kernel you're running, and the most recent."
If I run yum regularly but only reboot every couple of months, I can end
up with half a dozen kernels on my disk that I have not yet ever booted,
and now never will.
--
Jamie Zawinski jwz(a)jwz.org http://www.jwz.org/
jwz(a)dnalounge.com http://www.dnalounge.com/
http://jwz.livejournal.com/
5:24 p.m.
On Thu, 17 Feb 2005 14:58:09 -0500, seth vidal <skvidal(a)phy.duke.edu> wrote:
I may be able to do so.
keep the kernel you're running and all newer than that.
older kernels, remove.
have a text file which can specify kernels-versions to keep/ignore from
removal.
would it make sense to enshrine the mechanism variable(s) in
/etc/sysconfig/kernel?
something like:
PRUNEOLDKERNEL=yes/no
DONTFRELLINGPRUNETHISLIST= space seperate list of kernel versions
-jef
7:29 p.m.
On Thu, 17 Feb 2005 18:24:12 -0500, Jeff Spaleta wrote:
On Thu, 17 Feb 2005 14:58:09 -0500, seth vidal
<skvidal(a)phy.duke.edu>
wrote:
> I may be able to do so.
>
> keep the kernel you're running and all newer than that.
>
> older kernels, remove.
>
> have a text file which can specify kernels-versions to keep/ignore from
> removal.
would it make sense to enshrine the mechanism variable(s) in
/etc/sysconfig/kernel?
something like:
PRUNEOLDKERNEL=yes/no
DONTFRELLINGPRUNETHISLIST= space seperate list of kernel versions
-jef
FWIW, and since no one commented, it makes sense to mere lurking users
like me. And the follow-on is that the prune job would probably best be
done by new-kernel-pkg (and would therefore be independent of the
updater-of-choice). But since Mr. Yum is volunteering, power to him.
--Jack
3:18 a.m.
On Thu, 17 Feb 2005, seth vidal wrote:
On Thu, 2005-02-17 at 14:45 -0500, Jeff Spaleta wrote:
> The question becomes... can someone expose reasonable sane default
> behavior of some tool to do old kernel pruning... to avoid normal
> fedora users from encountering these deficiencies when you have 17 or
> so update kernels installed.
I may be able to do so.
keep the kernel you're running and all newer than that.
older kernels, remove.
Apt's kernel-upgrade lua-thingy at some point had something like this:
keep latest kernel and the one you're running. It got lost when I rewrote
the thing and nobody has missed it so I never bothered to add it back...
have a text file which can specify kernels-versions to keep/ignore from
removal.
That's probably an overkill. People who want to play around with several
kernels can disable the automatic pruning and do so manually, for the rest
of us "current running and latest" ought to be enough.
- Panu -
2:06 p.m.
On Thu, 2005-02-17 at 14:45 -0500, Jeff Spaleta wrote:
On Thu, 17 Feb 2005 14:33:24 -0500, Jeff Johnson
<n3npq(a)nc.rr.com> wrote:
> Or have every possible bleeping kernel already pre-installed and never
> remove anything.
> Unfortunately, that exercises known deficiencies with both rpm and
> hardlinks, and is
> slower than optimal, so take valium and be patient.
The question becomes... can someone expose reasonable sane default
behavior of some tool to do old kernel pruning... to avoid normal
fedora users from encountering these deficiencies when you have 17 or
so update kernels installed.
This is a script I've been using on two Rawhide boxes. (Well, actually,
it's the version I use on this box; the version on the other box is
different and a bit better, but it's not online right now.) It displays
a list of installed kernels, except for the newest kernel and the
currently running kernel, and lets you pick the ones you want to remove.
It's graphical (uses Zenity), but could easily be changed to be
console-only if someone really wanted to. The other version I have knew
how to remove some related packages like kernel-devel, but it also
wasn't quite as bright about some other things; it's been a while, I
forget what all the differences between the two scripts were.
This is definitely not the ideal tool for the problem, but it's
something other Rawhide users might find useful, so here it is.
-jef
--
Sean Middleditch <elanthis(a)awesomeplay.com>
2:14 p.m.
Jeff Spaleta wrote:
On Thu, 17 Feb 2005 14:33:24 -0500, Jeff Johnson
<n3npq(a)nc.rr.com> wrote:
>Or have every possible bleeping kernel already pre-installed and never
>remove anything.
>Unfortunately, that exercises known deficiencies with both rpm and
>hardlinks, and is
>slower than optimal, so take valium and be patient.
>
>
The question becomes... can someone expose reasonable sane default
behavior of some tool to do old kernel pruning... to avoid normal
fedora users from encountering these deficiencies when you have 17 or
so update kernels installed.
For me this issue and others (plugins, kernel modules,
missingok/optional features) seem to bolster the claim for a more
interactive Yum or at least yum mode. A yum that poses a few simple
question to the user like:
You have 7 kernels installed we recommend that you keep the number of
kernels installed concurrently fewer than 3 would you like to remove
some of them?
Yes all but the most recent 3.
No keep your grimy hands off my kernels.
or
Mplayer-plugin requires either mozilla or firefox to be present which
would you like to install?
Mozilla (X Megs)
Firefox (X Megs)
or
The followng plugins depend on gaim but are not installed woudl you like
to add these features?
I am only halfheartedly trying to make these make sense and the last one
might require a rpm flag or something, but the functioanlity would be
appreciated by a great numebr of users i think. Managing the changes so
that users arent overwhelmed with options and confused is the key to
adding this functionality sanely but i think that it can be done and
should be done eventually. Obvioulsy a Yum based GUI tool would handle
this type of interactivity more adeptly becuase of the multiple
selections that are made by the user. If there is genuine interest id be
happy to mockup an User interaction model that might help ease some of
these and other pains while providing the user with a simple and useful
software upgrade interface. IMO as the number of packages continue to
increase we need to be able to provide users with this type of
information instead otf the raw data we are asking them to sort through
right now.
-mf
2:23 p.m.
On Thu, 2005-02-17 at 14:14 -0600, Michael Favia wrote:
For me this issue and others (plugins, kernel modules,
missingok/optional features) seem to bolster the claim for a more
interactive Yum or at least yum mode. A yum that poses a few simple
question to the user like:
You have 7 kernels installed we recommend that you keep the number of
kernels installed concurrently fewer than 3 would you like to remove
some of them?
Yes all but the most recent 3.
No keep your grimy hands off my kernels.
I wouldn't exactly describe this as a "simple question" ;-)
The right approach is to just have a default garbage collection policy,
and for the 0.25% or less of the world that wants something else have a
config file where you can disable kernel GC entirely or pin certain
versions so they won't be removed.
Havoc
2:24 p.m.
Once upon a time, Havoc Pennington <hp(a)redhat.com> said:
The right approach is to just have a default garbage collection
policy,
and for the 0.25% or less of the world that wants something else have a
config file where you can disable kernel GC entirely or pin certain
versions so they won't be removed.
How about something like a default cron job (that can be easily
disabled) that looks at how long you've been running a particular
kernel? If you've been running for more than X days, remove everything
older.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
2:50 p.m.
Havoc Pennington wrote:
On Thu, 2005-02-17 at 14:14 -0600, Michael Favia wrote:
>For me this issue and others (plugins, kernel modules,
>missingok/optional features) seem to bolster the claim for a more
>interactive Yum or at least yum mode. A yum that poses a few simple
>question to the user like:
>
>You have 7 kernels installed we recommend that you keep the number of
>kernels installed concurrently fewer than 3 would you like to remove
>some of them?
> Yes all but the most recent 3.
> No keep your grimy hands off my kernels.
>
>
I wouldn't exactly describe this as a "simple question" ;-)
Like i said half heartedly. And im not proposing this be a default
operation but possible a mode of operation. Like the work on yum
interactive that is going on right now.
The right approach is to just have a default garbage collection
policy,
and for the 0.25% or less of the world that wants something else have a
config file where you can disable kernel GC entirely or pin certain
versions so they won't be removed.
I agree. A good default behavior is in perfect line with my suggestion.
Essentially i am proposing to have a system where the default operation
satisfies most of the user base and you only enter interactive mode (in
CLI or GUI) if you try a transaction and you dont like the suggestions
or would like to know more options (like adding plugins to newly
installed apps or choosing which 1 of the two applications that provide
the same functionality (firefox, mozilla). To be prefectly clear i am
not trying to punt the decision to the user. I wanted a good default
option (current plus highest sounds best) with the ability for a user to
make decisions should they desire to do so in this and other cases like
i mentioned. The kernel argument isnt a huge one for this interactive
mode. It just seemed to be one more piece that lended slightly to the
argument for me. And im not proposing the interactive mode as default
behavior but i think that there are a lot of issues like unknown plugins
(to the user), and plugins that require either X or Y and i dont know
how they are resolved at this time and i thought that it might be nice
to try to flesh out a unified solution that simplifies the process using
package management tools instead of cron jobs and scripts. Many new
users to fedora dont know they need to download plugins to enhance
programs and i was trying to give them a way to "discover" fedora using
the same tool that they use to manage the installation of the new
application.
-mf
2:25 p.m.
On Thu, 2005-02-17 at 14:14 -0600, Michael Favia wrote:
Jeff Spaleta wrote:
>On Thu, 17 Feb 2005 14:33:24 -0500, Jeff Johnson <n3npq(a)nc.rr.com> wrote:
>
>
>>Or have every possible bleeping kernel already pre-installed and never
>>remove anything.
>>Unfortunately, that exercises known deficiencies with both rpm and
>>hardlinks, and is
>>slower than optimal, so take valium and be patient.
>>
>>
>
>
>The question becomes... can someone expose reasonable sane default
>behavior of some tool to do old kernel pruning... to avoid normal
>fedora users from encountering these deficiencies when you have 17 or
>so update kernels installed.
>
>
For me this issue and others (plugins, kernel modules,
missingok/optional features) seem to bolster the claim for a more
interactive Yum or at least yum mode. A yum that poses a few simple
question to the user like:
You have 7 kernels installed we recommend that you keep the number of
kernels installed concurrently fewer than 3 would you like to remove
some of them?
Yes all but the most recent 3.
No keep your grimy hands off my kernels.
I'd much, much rather just see the proper and most correct behavior be
added to Yum, instead of punting the issue and making the user handle
it. Especially given the number of users that don't know, or want to
know, the correct answer.
Really, there's only two kernels you'd ever need, aside from specialty
cases that normal users don't have to worry about. Those kernels are
the currently running kernel, and the kernel you plan on getting on your
next boot (i.e., the newest kernel).
Simply making that the default behavior, with options or features for
more advanced users to pin kernels or disable the behavior, would be far
more beneficial for the average user, as well as greatly simplify the
life of yum front-end and library users.
or
Mplayer-plugin requires either mozilla or firefox to be present which
would you like to install?
Mozilla (X Megs)
Firefox (X Megs)
Same deal here. Better to just come up with a policy for picking one
automatically. If a user is advanced enough to know which they want,
they can install it explicitly with the plugin/add-on.
or
The followng plugins depend on gaim but are not installed woudl you like
to add these features?
Now this is somewhat of a different issue. Being able to mark a package
as an "add-on" to another could *really* help user-oriented package
management tools. For example, if I open up the Application Manager, I
*only* expect to see applications - not plugins or libraries or anything
else. If I click on GAIM, it could then display a list of plugin
package that are installed or available.
By default, though, when initially installing GAIM, I dont' think you
should ask the user, unless the user has explicitly stated that they
want the control (i.e., a "confirm suggested packages" option that is
off by default). Something like a "Suggests" field might work - those
are the packages that GAIM doesn't need, but recommends are installed
with it, which would be default behavior.
--
Sean Middleditch <elanthis(a)awesomeplay.com>
5:29 p.m.
Jeff Johnson writes:
Look there's a really simple answer to hardlinks and rpm and
more:
Choose a kernel, use that.
Chose another kernel, use that, get rid of previous.
This might've been a prudent approach for the days long gone. But, in the
age of Fedora, I'm not that optimistic.
Just recently I had to temporarily roll back a few kernel builds. Something
broke in usb-storage. I didn't notice it for a while, because I don't use
my digital camera that often.
I now keep a minimum of current+three previous versions of the kernel. Plus
-smp.
6:26 p.m.
Sam Varshavchik wrote:
Jeff Johnson writes:
> Look there's a really simple answer to hardlinks and rpm and more:
>
> Choose a kernel, use that.
>
> Chose another kernel, use that, get rid of previous.
This might've been a prudent approach for the days long gone. But, in
the age of Fedora, I'm not that optimistic.
It's still a prudent approach, not much has changed with FC-devel nee
rawhide, for a very long time.
FC-devel is a development tree, there is breakage. If you want to see
the breakage, well it's there
for all to see.
Just recently I had to temporarily roll back a few kernel builds.
Something broke in usb-storage. I didn't notice it for a while,
because I don't use my digital camera that often.
What has changed is expectations, a couple years back you wouldn't have
even noticed if your
digital camera broke.
What has also changed is the flood of kernels and the rate of change.
The bits are still borken.
I now keep a minimum of current+three previous versions of the
kernel. Plus -smp.
There's an optimum point between prudence and keeping every kernel ever
pushed
through yum installed. If that is 3 for you, that's fine, rpm and
hardlink prolly have tolerable
performance there.
73 de Jeff
12:47 a.m.
--On Thursday, February 17, 2005 6:29 PM -0500 Sam Varshavchik
<mrsam(a)courier-mta.com> wrote:
Just recently I had to temporarily roll back a few kernel builds.
Something broke in usb-storage. I didn't notice it for a while, because
I don't use my digital camera that often.
Did that keep you from booting? I thought the point of keeping the previous
kernel installed was in case the new one didn't allow one to boot.
Presumably you'd have older kernel RPMs in your yum cache to deal with
non-boot issues.
5:31 a.m.
On Wednesday 16 February 2005 10:34, Sam Varshavchik wrote:
Yes, these are large packages that are being removed. No, even with
all that, taking six minutes, a dual Opteron box, with SCSI RAID, is
unreasonable.
Check strace, %preun, %post, %postun, and other related trigger
operations and post your results where the bottlenecks are. Could be
rpm, could be db, could be scriptlets .. who knows.
Maybe use the bootchart except retune it to read strace/ltrace output
and produce analysis. valgrind and others work too.
have fun,
--
-jeff
6:13 a.m.
Jeff Pitman writes:
On Wednesday 16 February 2005 10:34, Sam Varshavchik wrote:
> Yes, these are large packages that are being removed. No, even with
> all that, taking six minutes, a dual Opteron box, with SCSI RAID, is
> unreasonable.
Check strace, %preun, %post, %postun, and other related trigger
operations and post your results where the bottlenecks are. Could be
rpm, could be db, could be scriptlets .. who knows.
It's neither of these. According to top, all the CPU was being charged to
the rpm process alone. The kernel package's %preun consists of:
/sbin/modprobe loop 2> /dev/null > /dev/null || :
[ -x /sbin/new-kernel-pkg ] && /sbin/new-kernel-pkg --rminitrd --rmmoddep --remove
2.6.10-1.12_FC2
Which is nothing.
rpm was eating CPU like there's no tomorrow. strace was showing lots of
read/writes, likely its database.
7:27 a.m.
Sam Varshavchik wrote:
Jeff Pitman writes:
> On Wednesday 16 February 2005 10:34, Sam Varshavchik wrote:
>
>> Yes, these are large packages that are being removed. No, even with
>> all that, taking six minutes, a dual Opteron box, with SCSI RAID, is
>> unreasonable.
>
>
> Check strace, %preun, %post, %postun, and other related trigger
> operations and post your results where the bottlenecks are. Could be
> rpm, could be db, could be scriptlets .. who knows.
It's neither of these. According to top, all the CPU was being
charged to the rpm process alone. The kernel package's %preun
consists of:
/sbin/modprobe loop 2> /dev/null > /dev/null || :
[ -x /sbin/new-kernel-pkg ] && /sbin/new-kernel-pkg --rminitrd
--rmmoddep --remove 2.6.10-1.12_FC2
Which is nothing.
rpm was eating CPU like there's no tomorrow. strace was showing lots
of read/writes, likely its database.
Yep.
There's a busted algorithm in rpm that goes badly when there are
numerous duplicate basenames that is triggered
by installing lots and lots of kernels (with 18K+ duplicate basenames
each) onto client machines.
Keep fewer kernels installed is the only answer I have at the moment.
A real fix is non-trivial and has been blocked (because not prioritized)
for many years now. There has been
little need to "fix" the problem because behavior has been acceptable
except for certain problem areas like
LC_MESSAGES in glibc-common.
Now there are often 10+ kernels are present on each and every client.
There is certainly
no "need" for 10+ kernels on most client machines that I'm aware of.
I'd also suggest better install policies for kernels would help.
Note that multilib installs are forcing multiple duplicate file
basenames onto lots of machines as well.
The same slow behavior will be seen, just not as bad as kernel packages
because fewer files involved.
73 de Jeff
7026
days inactive
7032
days old
36 comments
21 participants
participants (21)
-
Andrew Grover -
Arjan van de Ven -
Chris Adams -
David Woodhouse -
Havoc Pennington -
Jack Spaar -
Jamie Zawinski -
Jef Spaleta -
Jeff Johnson -
Jeff Pitman -
Kenneth Porter -
Kyrre Ness Sjobak -
Mathieu Chouquet-Stringer -
Michael Favia -
Nigel Metheringham -
Panu Matilainen -
Rahul Sundaram -
Ralf Ertzinger -
Sam Varshavchik -
Sean Middleditch -
seth vidal