On Sunday 06 January 2008 15:47, David Boles wrote: > -----BEGIN PGP SIGNED MESSAGE----- > 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. <snip> > 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 line. installonly_limit=0 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) 2.6.10-0.4.rdt.rhfc2.ccrma 2.6.10-2.1.ll.rhfc2.ccrma 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 Apt) 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) cdroms. Looking at Etch, I have the following kernels installed. 2.4.27... 2.6.8... 2.6.17 2.6.18-3 2.6.18-4 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. 2.6.21-rt4 2.6.21.5-rt18 2.6.23.1-rt4 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 others. 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. Nigel.
