How can I reduce the number of installed kernels to only one on my Fedora 17 systems? I'm asking about automated approach without the need of manual package removal.
I haven't compiled new kernels myself for a very long time so I don't think I'll need more then one kernel installed.
Now, I'm using package-cleanup --oldkernel but it's still cleaning up the mess that I want to avoid.
Mateusz Marzantowicz
On 10 July 2012 08:33, Mateusz Marzantowicz mmarzantowicz@osdf.com.pl wrote:
How can I reduce the number of installed kernels to only one on my Fedora 17 systems? I'm asking about automated approach without the need of manual package removal.
I haven't compiled new kernels myself for a very long time so I don't think I'll need more then one kernel installed.
Now, I'm using package-cleanup --oldkernel but it's still cleaning up the mess that I want to avoid.
You do want two kernels installed at least in case an update fails to boot. The installonly_limit parameter in /etc/yum.conf manages it, if you changed it to 1 then all older kernels would be removed by a yum update. Actually, I think possibly the running kernel will not be removed, so maybe it's not possible to get down to 1 that way. Maybe create a service for startup which does the cleanup? That way the old kernel wouldn't be removed until you successfully booted into the new one (but that still wouldn't catch things like broken video drivers or needing to add kernel parameters to work around a problem).
On 10.07.2012 09:47, Ian Malone wrote:
On 10 July 2012 08:33, Mateusz Marzantowicz mmarzantowicz@osdf.com.pl wrote:
How can I reduce the number of installed kernels to only one on my Fedora 17 systems? I'm asking about automated approach without the need of manual package removal.
I haven't compiled new kernels myself for a very long time so I don't think I'll need more then one kernel installed.
Now, I'm using package-cleanup --oldkernel but it's still cleaning up the mess that I want to avoid.
You do want two kernels installed at least in case an update fails to boot. The installonly_limit parameter in /etc/yum.conf manages it, if you changed it to 1 then all older kernels would be removed by a yum update. Actually, I think possibly the running kernel will not be removed, so maybe it's not possible to get down to 1 that way. Maybe create a service for startup which does the cleanup? That way the old kernel wouldn't be removed until you successfully booted into the new one (but that still wouldn't catch things like broken video drivers or needing to add kernel parameters to work around a problem).
Thanks, a lot. But now one thing bothers me even more. Is it possible that broken kernel which won't boot or cause any other serious problems is released in Fedora 16 or 17? I know that in Rawhide something might go wrong, but in 16, 17?
Mateusz Marzantowicz
On 10 July 2012 10:15, Mateusz Marzantowicz mmarzantowicz@osdf.com.pl wrote:
On 10.07.2012 09:47, Ian Malone wrote:
On 10 July 2012 08:33, Mateusz Marzantowicz mmarzantowicz@osdf.com.pl wrote:
How can I reduce the number of installed kernels to only one on my Fedora 17 systems? I'm asking about automated approach without the need of manual package removal.
I haven't compiled new kernels myself for a very long time so I don't think I'll need more then one kernel installed.
Now, I'm using package-cleanup --oldkernel but it's still cleaning up the mess that I want to avoid.
You do want two kernels installed at least in case an update fails to boot. The installonly_limit parameter in /etc/yum.conf manages it, if you changed it to 1 then all older kernels would be removed by a yum update. Actually, I think possibly the running kernel will not be removed, so maybe it's not possible to get down to 1 that way. Maybe create a service for startup which does the cleanup? That way the old kernel wouldn't be removed until you successfully booted into the new one (but that still wouldn't catch things like broken video drivers or needing to add kernel parameters to work around a problem).
Thanks, a lot. But now one thing bothers me even more. Is it possible that broken kernel which won't boot or cause any other serious problems is released in Fedora 16 or 17? I know that in Rawhide something might go wrong, but in 16, 17?
In general kernels will boot, they wouldn't get past the updates-testing and karma procedures otherwise. However it's possible that a change is introduced which will fail on your hardware. For example my laptop is currently on the F17 release kernel because of this bug https://bugzilla.redhat.com/show_bug.cgi?id=834318. The install_only limit keeps that number of kernels installed, so you can roll back if that does happen.
Additionally if you use a binary module for any reason (cue posts saying you shouldn't) then any given kernel update might break it.
On 10 July 2012 10:15, Mateusz Marzantowicz mmarzantowicz@osdf.com.pl wrote:
Is it possible that broken kernel which won't boot or cause any other serious problems is released in Fedora 16 or 17? I know that in Rawhide something might go wrong, but in 16, 17?
It's happened to me more often than I'd like. Probably once per release (and I've been using Fedora right from the start).
Often it's just drivers that haven't been updated, so it's just a case of waiting a couple of days until another yum update fixes it. But I'd be screwed if I didn't always keep the last known working kernel around.
Dave..
On 10.07.2012 11:26, Dave Cross wrote:
On 10 July 2012 10:15, Mateusz Marzantowicz mmarzantowicz@osdf.com.pl wrote:
Is it possible that broken kernel which won't boot or cause any other serious problems is released in Fedora 16 or 17? I know that in Rawhide something might go wrong, but in 16, 17?
It's happened to me more often than I'd like. Probably once per release (and I've been using Fedora right from the start).
Lucky me, I can't remember going into such unpleasant situation with different Linux distros so I thought only one kernel will be enough.
Often it's just drivers that haven't been updated, so it's just a case of waiting a couple of days until another yum update fixes it. But I'd be screwed if I didn't always keep the last known working kernel around.
Dave..
Maybe having two kernels installed is more comfortable, you'll never know when something breaks. I must reconsider my initial idea. Thanks a lot for any thoughts.
Mateusz Marzantowicz
On Tue, Jul 10, 2012 at 3:31 PM, Mateusz Marzantowicz mmarzantowicz@osdf.com.pl wrote:
Maybe having two kernels installed is more comfortable, you'll never know when something breaks. I must reconsider my initial idea. Thanks a lot for any thoughts.
The boot images are about 20-30 MBs each, so I keep 5.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/10/2012 02:31 PM, Mateusz Marzantowicz wrote:
On 10.07.2012 11:26, Dave Cross wrote:
On 10 July 2012 10:15, Mateusz Marzantowicz mmarzantowicz@osdf.com.pl wrote:
Is it possible that broken kernel which won't boot or cause any other serious problems is released in Fedora 16 or 17? I know that in Rawhide something might go wrong, but in 16, 17?
It's happened to me more often than I'd like. Probably once per release (and I've been using Fedora right from the start).
Lucky me, I can't remember going into such unpleasant situation with different Linux distros so I thought only one kernel will be enough.
I don't recall the last time that it happened to me but of course everyone's mileage varies.
Maybe having two kernels installed is more comfortable, you'll never know when something breaks. I must reconsider my initial idea. Thanks a lot for any thoughts.
This has long been considered best practice - when I was teaching RHCE classes 8+ years ago we always advised a kernel update procedure like:
- - install new kernel - - reboot to test - - remove old kernel
That way you have a get out if for any reason the new kernel will not boot or proves unreliable.
Of course, there's rarely any harm in skipping the last step and not removing the kernel until later. This was back in the days of manual updates with rpm -i/F but it carries over to yum equally well (there was a yum plugin, installonlyn, that used to automate this but I don't see it at the moment).
Regards, Bryn.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/10/2012 07:23 PM, Bryn M. Reeves wrote:
Of course, there's rarely any harm in skipping the last step and not removing the kernel until later. This was back in the days of manual updates with rpm -i/F but it carries over to yum equally well (there was a yum plugin, installonlyn, that used to automate this but I don't see it at the moment).
Thats because this functionality got extended and merged in yum long back. man yum.conf and refer to installonly_limit and installonlypkgs
Rahul
On 07/10/2012 02:15 AM, Mateusz Marzantowicz wrote:
Thanks, a lot. But now one thing bothers me even more. Is it possible that broken kernel which won't boot or cause any other serious problems is released in Fedora 16 or 17? I know that in Rawhide something might go wrong, but in 16, 17?
My laptop is running F17 with a kernel from F14 because every F16 kernel I've tried on it fails to boot with the exact same problem. Does that answer your question?
On 10.07.2012 20:00, Joe Zeff wrote:
On 07/10/2012 02:15 AM, Mateusz Marzantowicz wrote:
Thanks, a lot. But now one thing bothers me even more. Is it possible that broken kernel which won't boot or cause any other serious problems is released in Fedora 16 or 17? I know that in Rawhide something might go wrong, but in 16, 17?
My laptop is running F17 with a kernel from F14 because every F16 kernel I've tried on it fails to boot with the exact same problem. Does that answer your question?
Sorry, but no. This only exposes serious problems with kernel quality in Fedora. Personally I've never run in such problems and I hope I'll never will. Regular Linux users should never be forced to deal with kernel issues. I think it's RHEL policy, but not Fedora's for some reason.
Mateusz Marzantowicz
On 10.07.2012, Joe Zeff wrote:
My laptop is running F17 with a kernel from F14 because every F16 kernel I've tried on it fails to boot with the exact same problem.
Do you have any information on this problem? What did you try to solve it?
So far, I've never used any Fedora-kernel longer than for installation, and have never encountered major problems with linux-vanilla. Your problem could be hardware-dependend. Have you tried a fresh 3.4.4 from kernel.org?
On 07/10/2012 11:43 AM, Heinz Diehl wrote:
Do you have any information on this problem? What did you try to solve it?
See https://bugzilla.redhat.com/show_bug.cgi?id=769747 for details. Note that I'm not the original reporter, and I seem to be the only one who can't boot because of it. I reported this here when it first struck, but nobody responded and you'd have no reason to remember it. Any suggestions will be welcomed but remember: once I start booting into a 3.x kernel, the only control I have over what happens is using ^Alt-Delete to reboot.
On 10.07.2012, Joe Zeff wrote:
See https://bugzilla.redhat.com/show_bug.cgi?id=769747 for details. Note that I'm not the original reporter, and I seem to be the only one who can't boot because of it.
I think you should compile a completely fresh 3.4.4. from kernel.org and report this on linux-kernel@vger.kernel.org, if the problem persists. You could use the Fedora .config from /boot as a starting point, if you're not used to compile your own kernels.
On 07/10/2012 01:56 PM, Heinz Diehl wrote:
I think you should compile a completely fresh 3.4.4. from kernel.org and report this onlinux-kernel@vger.kernel.org, if the problem persists. You could use the Fedora .config from /boot as a starting point, if you're not used to compile your own kernels.
I don't think I've compiled a kernel of my own since F6, and I don't see any reason to do it now. The laptop is a secondary machine, only used sporadically and never has anything on it that I'd be afraid to have compromised except for passwords. Yes, I'd much rather be using the latest kernel, but it's not that big a deal. Of course, if you'd suggested some boot params to try, that'd be different.
On 07/10/2012 02:15 PM, Joe Zeff wrote:
On 07/10/2012 01:56 PM, Heinz Diehl wrote:
I think you should compile a completely fresh 3.4.4. from kernel.org and report this onlinux-kernel@vger.kernel.org, if the problem persists. You could use the Fedora .config from /boot as a starting point, if you're not used to compile your own kernels.
I don't think I've compiled a kernel of my own since F6, and I don't see any reason to do it now. The laptop is a secondary machine, only used sporadically and never has anything on it that I'd be afraid to have compromised except for passwords. Yes, I'd much rather be using the latest kernel, but it's not that big a deal. Of course, if you'd suggested some boot params to try, that'd be different.
just a suggestion:-) this thread appears is getting hijacked, may want to start your own thread.
On 07/10/2012 02:31 PM, Joe Zeff wrote:
On 07/10/2012 02:33 PM, Edward M wrote:
just a suggestion:-) this thread appears is getting hijacked, may want to start your ownthread.
Actually, I only mentioned it as an example of needing a backup kernel.
sorry, I misunderstood. but now i understand:-)
On Tue, Jul 10, 2012 at 10:20 PM, Joe Zeff joe@zeff.us wrote:
On 07/10/2012 11:43 AM, Heinz Diehl wrote:
Do you have any information on this problem? What did you try to solve it?
See https://bugzilla.redhat.com/show_bug.cgi?id=769747 for details. Note that I'm not the original reporter, and I seem to be the only one who can't boot because of it. I reported this here when it first struck, but nobody responded and you'd have no reason to remember it. Any suggestions will be welcomed but remember: once I start booting into a 3.x kernel, the only control I have over what happens is using ^Alt-Delete to reboot.
"rd.driver.blacklist=ums_realtek blacklist=ums_realtek" to prevent loading in the initramfs and installer...
For the real root:
# echo "blacklist ums_realtek" > /etc/modprobe.d/realtek.conf
On 07/12/2012 04:14 PM, Harald Hoyer wrote:
On Tue, Jul 10, 2012 at 10:20 PM, Joe Zeff joe@zeff.us wrote:
On 07/10/2012 11:43 AM, Heinz Diehl wrote:
Do you have any information on this problem? What did you try to solve it?
See https://bugzilla.redhat.com/show_bug.cgi?id=769747 for details. Note that I'm not the original reporter, and I seem to be the only one who can't boot because of it. I reported this here when it first struck, but nobody responded and you'd have no reason to remember it. Any suggestions will be welcomed but remember: once I start booting into a 3.x kernel, the only control I have over what happens is using ^Alt-Delete to reboot.
"rd.driver.blacklist=ums_realtek blacklist=ums_realtek" to prevent loading in the initramfs and installer...
For the real root:
# echo "blacklist ums_realtek" > /etc/modprobe.d/realtek.conf
One question before I try this: would this completely disable my card reader? I ask because the USB port on my camera has stopped working and that card reader's the only access I have right now to the photos.
Am 13.07.2012 01:58, schrieb Joe Zeff:
On 07/12/2012 04:14 PM, Harald Hoyer wrote:
On Tue, Jul 10, 2012 at 10:20 PM, Joe Zeff joe@zeff.us wrote:
On 07/10/2012 11:43 AM, Heinz Diehl wrote:
Do you have any information on this problem? What did you try to solve it?
See https://bugzilla.redhat.com/show_bug.cgi?id=769747 for details. Note that I'm not the original reporter, and I seem to be the only one who can't boot because of it. I reported this here when it first struck, but nobody responded and you'd have no reason to remember it. Any suggestions will be welcomed but remember: once I start booting into a 3.x kernel, the only control I have over what happens is using ^Alt-Delete to reboot.
"rd.driver.blacklist=ums_realtek blacklist=ums_realtek" to prevent loading in the initramfs and installer...
For the real root:
# echo "blacklist ums_realtek" > /etc/modprobe.d/realtek.conf
One question before I try this: would this completely disable my card reader? I ask because the USB port on my camera has stopped working and that card reader's the only access I have right now to the photos
why do you not try it out? this is nothing that can't be reverted
On 07/12/2012 04:14 PM, Harald Hoyer wrote:
On Tue, Jul 10, 2012 at 10:20 PM, Joe Zeff joe@zeff.us wrote:
On 07/10/2012 11:43 AM, Heinz Diehl wrote:
Do you have any information on this problem? What did you try to solve it?
See https://bugzilla.redhat.com/show_bug.cgi?id=769747 for details. Note that I'm not the original reporter, and I seem to be the only one who can't boot because of it. I reported this here when it first struck, but nobody responded and you'd have no reason to remember it. Any suggestions will be welcomed but remember: once I start booting into a 3.x kernel, the only control I have over what happens is using ^Alt-Delete to reboot.
"rd.driver.blacklist=ums_realtek blacklist=ums_realtek" to prevent loading in the initramfs and installer...
Sorry for the delay, but I've not had any reason to use the laptop recently. Now, I'm away from home for several days and have ample time to experiment. Adding the above to the kernel line (I added it to grub.conf to make sure I got it right.) simply hung the boot until I rebooted.
For the real root:
# echo "blacklist ums_realtek" > /etc/modprobe.d/realtek.conf
Did absolutely nothing. Thanx anyway.
-
Bryn M. Reeves -
Dave Cross -
Edward M -
Harald Hoyer -
Heinz Diehl -
Ian Malone -
Joe Zeff -
Mateusz Marzantowicz -
Rahul Sundaram -
Reindl Harald -
Suvayu Ali