2:33 a.m.
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
8:53 a.m.
-----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(a)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 SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk/8M8wACgkQ6YSQoMYUY96/jQCfY3/IYz+cllJBxN1QxcT0QT29
W/UAoMTwWuAcG1Ki26YIY/2l0+HVOwYq
=lLbM
-----END PGP SIGNATURE-----
12:59 a.m.
On 07/12/2012 04:14 PM, Harald Hoyer wrote:
On Tue, Jul 10, 2012 at 10:20 PM, Joe Zeff <joe(a)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.
7:12 p.m.
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(a)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
6:58 p.m.
On 07/12/2012 04:14 PM, Harald Hoyer wrote:
On Tue, Jul 10, 2012 at 10:20 PM, Joe Zeff <joe(a)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.
6:14 p.m.
On Tue, Jul 10, 2012 at 10:20 PM, Joe Zeff <joe(a)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
4:56 p.m.
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 own
> thread.
Actually, I only mentioned it as an example of needing a backup kernel.
--
sorry, I misunderstood. but now i understand:-)
4:15 p.m.
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(a)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.
4:33 p.m.
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(a)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.
3:56 p.m.
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(a)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.
3:20 p.m.
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.
1:43 p.m.
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?
1:23 p.m.
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
1 p.m.
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?
10 a.m.
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJP/EN8AAoJELauRe7G9dGMC5EH/j/NL1wURavL+rv/Pp7r63Zg
xdSbzM7IORb1l+PuQ+M6bpPXrADKUJr8wElpuP8XosJxwKXvkj6EXDXi20+J2Pgv
8Bb5aPUn1t/pp1YtM/Zi1nv7NShlD3ulEhhGPsR70ELrDXY+9YrVzDmRfU0GRRaR
E9xTzCpoi9pBj9RtT4XAQw5zIhspJQpPRFhMWPfyIaivE/xMfAIBrhFOwtJma1mJ
5sc8xdvORzdSTJLItwcTjMniOPKC0BPs5t5WUBcI2JmnQuYMVtnmVwtOrItdX5If
FJ6clQsKtX9gPXx+fZcbaQN3hkwwqEk0nhOkj+vJ+pf7IR4g6IYEYFM+dqxoEcg=
=RQEV
-----END PGP SIGNATURE-----
8:39 a.m.
On Tue, Jul 10, 2012 at 3:31 PM, Mateusz Marzantowicz
<mmarzantowicz(a)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.
--
Suvayu
Open source is the future. It sets us free.
8:31 a.m.
On 10.07.2012 11:26, Dave Cross wrote:
On 10 July 2012 10:15, Mateusz Marzantowicz
<mmarzantowicz(a)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
4:26 a.m.
On 10 July 2012 10:15, Mateusz Marzantowicz <mmarzantowicz(a)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..
--
Dave Cross :: dave(a)dave.org.uk
http://dave.org.uk/
@davorg
4:23 a.m.
On 10 July 2012 10:15, Mateusz Marzantowicz <mmarzantowicz(a)osdf.com.pl> wrote:
On 10.07.2012 09:47, Ian Malone wrote:
> On 10 July 2012 08:33, Mateusz Marzantowicz <mmarzantowicz(a)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.
--
imalone
http://ibmalone.blogspot.co.uk
4:15 a.m.
On 10.07.2012 09:47, Ian Malone wrote:
On 10 July 2012 08:33, Mateusz Marzantowicz
<mmarzantowicz(a)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
2:47 a.m.
On 10 July 2012 08:33, Mateusz Marzantowicz <mmarzantowicz(a)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).
--
imalone
http://ibmalone.blogspot.co.uk
4278
days inactive
4308
days old
21 comments
11 participants
participants (11)
-
Bryn M. Reeves -
Dave Cross -
Edward M -
Harald Hoyer -
Heinz Diehl -
Ian Malone -
Joe Zeff -
Mateusz Marzantowicz -
Rahul Sundaram -
Reindl Harald -
Suvayu Ali