[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: prevent yum deleting downloaded updates

On Sunday 06 January 2008 15:47, David Boles wrote:
> Hash: SHA1
> Tim wrote:
> | On Sat, 2008-01-05 at 13:26 -0500, David Boles wrote:
> |> I have to ask you Nigel. Why would you want to keep more that two
> |> kernels when you have the one that is currently running and the
> |> previous one that was running when the current one was installed?
> |
> | You mightn't notice that a kernel has *some* problems for a while, if
> | you don't use all the features all the time.  Later on, when you have
> | some problem, it can be handy to have more than one alternative to test
> | with.
> |
> | Occasionally there'll be a very quick release of a kernel update shortly
> | after another kernel update.  That could end up deleting the only good
> | kernel.
> I have never had, touch wood, a kernel problem like that. I have no unusual
> hardware. All of it is supported natively by Linux. I don't need special
> drivers, non OSS software, or third party anything. Fedora, and all of the
> other distributions that I have tried, installs with no problems and just
> works on first reboot.

> And since I know how to quickly and easily fix a problem such as this,
> should one arise, I feel that the default of two kernels if enough for me.
> That is why I asked.
> - --
> ~  David

Hi David. On FC2 I was installing all the latest low latency realtime kernels 
from planetccrma. The advice from Fernando at planetccrma was to disable the 
installonlyn plugin, which you now have to do in /etc/yum.conf, by adding the 

As I've already said, I use Apt, but all the same went through this procedure 
with Yum, just in case I had an Apt problem, and had to use Yum, and didn't 
want to lose kernels.

Some of the kernels from planetccrma were quite experimental, and some 
wouldn't even boot on my machine. The kernels were coming fast and furious 
from planetccrma, and if I hadn't disabled the installonlyn plugin, I would 
have lost my Fedora kernels if I'd been using Yum. Also on the FC2 machine 
that I'm e-mailing from, the planetccrma realtime kernels have a problem with 
NTP, and I use this machine for getting my time from the Internet. If I had 
been using Yum with it's 2 kernel limit, I'd have found myself with 2 
planetccrma lowlatency realtime kernels that were having problems with NTP, 
and resulted in the clock simply stopping after a short time, until the mouse 
was moved. Don't ask me why, as I have no idea.

As it is on this FC2 machine, I have 4 kernels available, as below.
2.6.5-1.358   (the original from the install disks)
2.6.10-2.3.legacy_FC2  (the latest from fedora legacy before it shutdown)

I don't use the planetccrma ones, because as I've said they cause problems 
with NTP, but it's nice to have them, if I want to try some music app with a 
lowlatency realtime kernel.

Forgive me. This is not a rant on the importance of keeping all kernels, but 
just the way I like to work. It's nice to have the choice of removing an 
unwanted kernel, rather than Yum deciding for me. (not my problem as I use 

Just one other example for the sake of it. Not Fedora, but my Debian installs.

Now Debian uses Apt, as you know, but if it used Yum with the default 
settings, I'd have lost a lot of kernels that personally I want to have 
access to.

My Debian installs have been continuously upgraded from my 3.0.r2 (Woody) 

Looking at Etch, I have the following kernels installed.
2.6.18-5  (this one is still being updated with later revisions)

With Yum as default, I'd have lost all but 2 of these.

Most recently on Etch, I've installed some realtime kernels from the Musix 
repo, to see if I can get realtime working on Etch, and yes, realtime does 
work, but am getting everything locking up from time to time, so it's nice to 
be able to boot a kernel that I know works with no problems. Realtime kernels 
as below.

Again, if I'd being using Yum (though not available on Debian) I'd have found 
myself with just 2 of the realtime kernels, and would have lost all the 

Maybe this is just Fedora trying to make it easy for Ex windows users, who are 
usually ignorant as to what is going on when updating, and don't want to know 
anyway. A just "let the updates get on with it attitude".

Getting back to my original reply to the OP's question, which was to do with 
preventing Yum from trashing the cache.

I'm on dialup, and often install another instance of a Fedora version. Again, 
as I use Apt, I save all the updates from /var/cache/apt/archives from 
whichever Fedora version to a Fat32 partition on another harddrive. That way 
I can install another instance of whichever Fedora version, copy the archives 
back into /var/cache/apt, which will overwrite an empty archives directory, 
and don't have to suffer downloading all the updates again. An apt-get update 
will retrieve the package lists, and an apt-get dist-upgrade will use the 
already downloaded packages that are available in /var/cache/apt/archives on 
the new Fedora instance that I want to update.

Trashing the cache may be ok for broadband users, but if you're on dialup, 
it's not so funny having to download the same stuff again, and that's apart 
from the abuse of Internet bandwidth. We'll leave the spammers out of the 
equation. I'd love to stop them, but there's not much chance of that. Saving 
the cache/downloaded updates can save bandwidth if you are going to install 
another instance of the same Fedora version. Also if you remove an app for 
whatever reason, and want to re-install it, it's already downloaded, and can 
just re-install it with a "yum install <package name>".

Sorry, but that last bit sounded like a rant, but that's just the way I feel 
as a dialup user, and also sickened by the type of spam that turns up in 
Kmails wastebin courtesy of bogofilter. These spammers must be seriously 
sick. as 80% of it centres on the mail sex organ.

I usually flick through the wastebin to see that there are no ham mails 
wrongly identified, but am even getting sick of doing that, and bogofilter 
hasn't made any errors yet.

End of rant.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]