This is FC5T1 (with some updates from devel).
If I try to run yum update, it says: Removing: kernel x86_64 2.6.14-1.1696_FC5 installed 84 M kernel x86_64 2.6.15-1.1826.2.9_FC5 installed 82 M
Seems to be acting as if it doesn't recognize these as kernel packages that should be installonly.
The yum config is stock FC5T1.
Neal Becker wrote:
This is FC5T1 (with some updates from devel).
If I try to run yum update, it says: Removing: kernel x86_64 2.6.14-1.1696_FC5 installed 84 M kernel x86_64 2.6.15-1.1826.2.9_FC5 installed 82 M
Seems to be acting as if it doesn't recognize these as kernel packages that should be installonly.
The yum config is stock FC5T1.
There is a plugin included in yum which will keep the running kernel (hopefully) and the newly installed kernel. It will remove the previous versions that add up to more than two kernels. Hopefully the yum plugin goes by information from uname and not just the oldest kernel versions. People might be running from the oler kernel while the newest kernel is inoperable.
Jim
On Sunday 15 January 2006 02:46, Jim Cornette wrote:
There is a plugin included in yum which will keep the running kernel (hopefully) and the newly installed kernel. It will remove the previous versions that add up to more than two kernels.
I'm not sure I've understood this thread, but in my view the default should be to keep the current, working kernel as the default (as I believe it used to be). Also I don't see why any old kernels should be removed automatically. Surely it is easy enough to do that if one wants to?
I run yum automatically on a remote machine, and have had some problems with new kernels being installed and run automatically.
Have a look here http://clunixchit.blogspot.com/2006/01/updating-kernel-removing-old-ones.htm... and read the comments as well
On 1/16/06, Timothy Murphy tim@birdsnest.maths.tcd.ie wrote:
but in my view the default should be to keep the current, working kernel as the default (as I believe it used to be).
This makes for a very poor default for systems managed by novice fedora users. Novice users may not realize that they need to reconfigure their grub to take advantage of a security update kernel. Its very important that the default configuration is one that makes booting into security kernel updates as automatic as possible. For people with enough experience using Fedora to competently manage multiple remote systems, the configuration file /etc/sysconfig/kernel can be used to disable this default.
Also I don't see why any old kernels should be removed automatically. Surely it is easy enough to do that if one wants to?
Its actually not as easy as you think for novice users. The kernel is rather special in a lot of ways, including the parallel package installation mechanism which is used to install kernel packages. Novice fedora users may not understand that the package managers are handling the kernels in a special way compared to other packages. Novice fedora users may never realize that there are multiple kernels installed and it is quite possible in the lifetime of a normal fedora release to install so many kernels that /boot runs out of space if the default partitioning is used. This sort of out of space condition leads to confusion, confusion that can very well lead to big problems when a novice user attempts to clean up the space. Watching novice users come into #fedora looking for help cleaning up there system because they attempted to remove kernels correctly isn't fun at all. It's a lot easier to explain to them how to boot into their older kernel from the grub menu and help them troubleshoot the new kernel, if the new kernel fails to boot correctly.
For people, including myself, who want to keep older kernels around the configuration file /etc/yum/pluginconf.d/installonlyn.conf is provided in which the defaults can be overridden.
I run yum automatically on a remote machine, and have had some problems with new kernels being installed and run automatically.
Please understand that your situation isn't the situation that is designed for when defaults are established. You have the ability to reconfigure both the installonlyn plugin in yum which removes old kernels as well as th ability to reconfigure whether the new kernel is the new boot default in grub by reconfiguring /etc/sysconfig/kernel.
-jef
On Monday 16 January 2006 16:12, Jeff Spaleta wrote:
but in my view the default should be to keep the current, working kernel as the default (as I believe it used to be).
This makes for a very poor default for systems managed by novice fedora users. Novice users may not realize that they need to reconfigure their grub to take advantage of a security update kernel. Its very important that the default configuration is one that makes booting into security kernel updates as automatic as possible. For people with enough experience using Fedora to competently manage multiple remote systems, the configuration file /etc/sysconfig/kernel can be used to disable this default.
I still think it is a bad idea to install the new kernel automatically. The worst thing that can happen for a newbie is that he turns on his laptop and it doesn't work.
There have been several occasions where that has happened to me with Fedora kernel updates - to mention three: an xorg update which did not work on my Sony Picturebook, a kernel update which did not work on an AMD-64 machine, a SCSI update which did not work on a SCSI-only machine.
I regard kernel and distribution as orthogonal, and would rather keep them separate. I don't find it very onerous to go through the Grub menu, and choose the kernel (or OS) I want.
The most important issue for a newbie (and for me) is that whatever OS I am using should work with the least possible trouble. Everything else - including security - can come later.
Timothy Murphy wrote:
On Monday 16 January 2006 16:12, Jeff Spaleta wrote:
but in my view the default should be to keep the current, working kernel as the default (as I believe it used to be).
This makes for a very poor default for systems managed by novice fedora users. Novice users may not realize that they need to reconfigure their grub to take advantage of a security update kernel. Its very important that the default configuration is one that makes booting into security kernel updates as automatic as possible. For people with enough experience using Fedora to competently manage multiple remote systems, the configuration file /etc/sysconfig/kernel can be used to disable this default.
I still think it is a bad idea to install the new kernel automatically. The worst thing that can happen for a newbie is that he turns on his laptop and it doesn't work
New kernels should never result in major regressions. We need to work on that instead of providing workarounds. What users can do is help checking updates-testing repository and making sure that it works. More feedback would definitely help increase the robustness of updates.
On Sunday 22 January 2006 16:55, Rahul Sundaram wrote:
but in my view the default should be to keep the current, working kernel as the default (as I believe it used to be).
I still think it is a bad idea to install the new kernel automatically. The worst thing that can happen for a newbie is that he turns on his laptop and it doesn't work
New kernels should never result in major regressions. We need to work on that instead of providing workarounds. What users can do is help checking updates-testing repository and making sure that it works. More feedback would definitely help increase the robustness of updates.
I'm very happy with yum - in fact I think it is the best thing about Fedora - but aren't you being excessively idealistic in thinking that any kernel update will work on every machine running Fedora?
As for feedback, I've found it very difficult to report on problems I've had, and when I have managed to do this there has never been any useful response. I think bugzilla should be made simpler to use if more feedback is desired.
By contrast, I've always had a good response when writing to this list.
Timothy Murphy wrote:
On Sunday 22 January 2006 16:55, Rahul Sundaram wrote:
but in my view the default should be to keep the current, working kernel as the default (as I believe it used to be).
I still think it is a bad idea to install the new kernel automatically. The worst thing that can happen for a newbie is that he turns on his laptop and it doesn't work
New kernels should never result in major regressions. We need to work on that instead of providing workarounds. What users can do is help checking updates-testing repository and making sure that it works. More feedback would definitely help increase the robustness of updates.
I'm very happy with yum - in fact I think it is the best thing about Fedora - but aren't you being excessively idealistic in thinking that any kernel update will work on every machine running Fedora?
We should shoot in for the best we can. We just cant afford to have users running any insecure kernel and thereby invalidating all the other security features[1] implemented..
As for feedback, I've found it very difficult to report on problems I've had, and when I have managed to do this there has never been any useful response. I think bugzilla should be made simpler to use if more feedback is desired.
There is some discussions going on towards this. Meanwhile bug buddy using xmlrpc in the future is good news.
By contrast, I've always had a good response when writing to this list.
Bugzilla is just more efficient as a tracking system. Developers might respond here and just forget about it. Bugzilla is a open TODO list.
On Sun, 2006-01-22 at 16:52 +0000, Timothy Murphy wrote:
On Monday 16 January 2006 16:12, Jeff Spaleta wrote:
but in my view the default should be to keep the current, working kernel as the default (as I believe it used to be).
This makes for a very poor default for systems managed by novice fedora users. Novice users may not realize that they need to reconfigure their grub to take advantage of a security update kernel. Its very important that the default configuration is one that makes booting into security kernel updates as automatic as possible. For people with enough experience using Fedora to competently manage multiple remote systems, the configuration file /etc/sysconfig/kernel can be used to disable this default.
I still think it is a bad idea to install the new kernel automatically. The worst thing that can happen for a newbie is that he turns on his laptop and it doesn't work.
the alternative sucks just as much: there's a severe security hole and the user thinks he's safe because he enabled the yum cronjob. (in your "turn on the laptop" scenario you boot often enough that running the stale kernel isn't an issue, it can be in other circumstances.
To be honest, the kernel breaking shouldn't happen too much. And as long as there is a known working kernel also in grub the damage is less than that of a severe break-in. So I'm arguing for a secure default versus the "has a small chance of breaking" trade-off you make into the other direction.
I think chosing for secure is the right approach. It's hard enough to get people to apply security updates (hey this should be asked in firstboot: "Enable automatic (security) upadates?"); but if they do then it'd suck to then give them only a false sense of "I'm secure because I'm updated".
Dnia 01/22/2006 06:05 PM, Użytkownik Arjan van de Ven napisał:
I think chosing for secure is the right approach.
Talking about security... What's the current status of FORTIFY_SOURCE in the kernel? You proposed this feature in this mail → https://www.redhat.com/archives/fedora-devel-list/2005-June/msg00012.html Patch is also available → http://lkml.org/lkml/2005/5/25/46 but it's not included in the Fedora's kernels → http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/ (why?)
Does it cause some problems (for instance performance loss or something)?
Thanks, Dawid
Dawid Gajownik wrote:
Dnia 01/22/2006 06:05 PM, Użytkownik Arjan van de Ven napisał:
I think chosing for secure is the right approach.
Talking about security... What's the current status of FORTIFY_SOURCE in the kernel? You proposed this feature in this mail → https://www.redhat.com/archives/fedora-devel-list/2005-June/msg00012.html Patch is also available → http://lkml.org/lkml/2005/5/25/46 but it's not included in the Fedora's kernels → http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/ (why?)
Its already available in FC4 and above. See http://fedoraproject.org/wiki/Security for features, status etc. Fedora might very well the best open source secure operating system you can get your hands on.
Rahul Sundaram wrote:
Dawid Gajownik wrote:
Dnia 01/22/2006 06:05 PM, Użytkownik Arjan van de Ven napisał:
I think chosing for secure is the right approach.
Talking about security... What's the current status of FORTIFY_SOURCE in the kernel? You proposed this feature in this mail → https://www.redhat.com/archives/fedora-devel-list/2005-June/msg00012.html
Patch is also available → http://lkml.org/lkml/2005/5/25/46 but it's not included in the Fedora's kernels → http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/ (why?)
Its already available in FC4 and above. See http://fedoraproject.org/wiki/Security for features, status etc. Fedora might very well the best open source secure operating system you can get your hands on.
Oh wait. I am not sure about the kernel.
On Sun, 2006-01-22 at 21:33 +0100, Dawid Gajownik wrote:
Dnia 01/22/2006 06:05 PM, Użytkownik Arjan van de Ven napisał:
I think chosing for secure is the right approach.
Talking about security... What's the current status of FORTIFY_SOURCE in the kernel? You proposed this feature in this mail → https://www.redhat.com/archives/fedora-devel-list/2005-June/msg00012.html Patch is also available → http://lkml.org/lkml/2005/5/25/46 but it's not included in the Fedora's kernels → http://cvs.fedora.redhat.com/viewcvs/rpms/kernel/devel/ (why?)
(I'm not working for Red Hat nor do I have any "put this in the kernel rpm" rights)
we investigated all places where it'd have any effect, and all of them were correct already (eg used the proper tests). The reason for this is simple: the kernel has a really tiny stack, so stack buffers are rare, really rare. And gcc doesn't know that "kmalloc" is like malloc, so fixed size allocations via kmalloc aren't recognized... so the value of the protection for now was basically zero ;-(
Dawid Gajownik wrote:
Dnia 01/22/2006 09:46 PM, Użytkownik Arjan van de Ven napisał:
(I'm not working for Red Hat nor do I have any "put this in the kernel rpm" rights)
What a pity :(
Yeah. He is all over the fedora-lists, #fedora-devel and lkml so life hasnt changed much ;-)
On 1/22/06, Timothy Murphy tim@birdsnest.maths.tcd.ie wrote:
I still think it is a bad idea to install the new kernel automatically. The worst thing that can happen for a newbie is that he turns on his laptop and it doesn't work.
I regard kernel and distribution as orthogonal, and would rather keep them separate. I don't find it very onerous to go through the Grub menu, and choose the kernel (or OS) I want.
If you don't find it difficult to use the grub menu to find the kernel you want.. why is it so bad if the new updates become the default?
new kernel comes out with security fixes... it gets installed and becomes the default it has a regression.. user notices the regression and then boots into the backup kernel from the grub menu... user then reports bugs about the regression. I don't see the problem with this picture. Regressions suck.. but the backup kernel is still on the system to use if someone runs into regressions. Unless people hit those regressions and report those regressions back to the maintainer there's very little hope that those functionality regressions will be fixed. Security kernel updates are very important, I don't see it as an appropriate trade off to make the security update kernels optional to avoid potential regressions. Anyone running a system which needs to avoid reboots into kernel updates because of ciritical production situations should configure their system appropriately at install time and should be aware of the impact on security by not using the security update kernels.
if the new kernel comes out and isn't the default.. how many users will "remember" to use the grub menu to select the new kernel.. instead of just booting in the kernel that was the default?
The most important issue for a newbie (and for me) is that whatever OS I am using should work with the least possible trouble. Everything else - including security - can come later.
Its interesting that you don't include closing known security vulnerabilities in your "least possible trouble" definition. From where I sit, known security vulnerabilities are trouble.
I disagree with your ranking of priorities... its very easy to reboot into the backup kernel if there is a regression. its not so easy for users to understand the implications of security and how much "trouble" vulnerabilities mayb cause. I think its in the userbase's best interest for the updates to prefer known security updates over unknown stability issues.
-jef
Jeff Spaleta wrote:
On 1/22/06, Timothy Murphy tim@birdsnest.maths.tcd.ie wrote:
The most important issue for a newbie (and for me) is that whatever OS I am using should work with the least possible trouble. Everything else - including security - can come later.
the world/internet do not need more insecure machines. (microsoft != macrohard)
[...] I disagree with your ranking of priorities [...]
thanks :-)
On Sunday 22 January 2006 17:14, Jeff Spaleta wrote:
I regard kernel and distribution as orthogonal, and would rather keep them separate. I don't find it very onerous to go through the Grub menu, and choose the kernel (or OS) I want.
If you don't find it difficult to use the grub menu to find the kernel you want.. why is it so bad if the new updates become the default?
I'm not a newbie. I don't think most newbies would know what to do if Linux fails to start.
Actually, the responses to my posting simply confirm in my mind the enormous gap between developers and typical (ie home) Fedora users.
Security kernel updates are very important, I don't see it as an appropriate trade off to make the security update kernels optional to avoid potential regressions. Anyone running a system which needs to avoid reboots into kernel updates because of ciritical production situations should configure their system appropriately at install time and should be aware of the impact on security by not using the security update kernels.
Sadly, I've disabled SELinux on my machine(s), simply because when I enabled it my laptop stopped working properly. I spent a couple of hours looking at selinux documentation but didn't find anything very helpul - amazingly, there appear to have been major changes in SELinux which haven't been documented.
Actually, I don't find security a major priority, and neither I believe would most home Fedora users. I'm running shorewall, and as far as I can see that is sufficient for normal use.
My philosophy is that if an application is not properly documented, and does not run in a more-or-less self-evident way, then it is not worth worrying about unless it is essential for my needs. I'm a Linux user rather than a devotee.
Timothy Murphy wrote:
On Sunday 22 January 2006 17:14, Jeff Spaleta wrote:
I regard kernel and distribution as orthogonal, and would rather keep them separate. I don't find it very onerous to go through the Grub menu, and choose the kernel (or OS) I want.
If you don't find it difficult to use the grub menu to find the kernel you want.. why is it so bad if the new updates become the default?
I'm not a newbie. I don't think most newbies would know what to do if Linux fails to start.
Actually, the responses to my posting simply confirm in my mind the enormous gap between developers and typical (ie home) Fedora users.
Security kernel updates are very important, I don't see it as an appropriate trade off to make the security update kernels optional to avoid potential regressions. Anyone running a system which needs to avoid reboots into kernel updates because of ciritical production situations should configure their system appropriately at install time and should be aware of the impact on security by not using the security update kernels.
...
How about coding a situtation (previously seen in w95 auto scandisk), that when a new kernel is installed, a mark is placed somewhere indicating that it has not yet booted and run. When the default new kernel is booted, it writes to the disk(/boot? ro!) early in the boot to state that it is trying to start kernel x., and if it achieves runlevel 3/5 or login screen, a process could clear the "not yet booted and run bit". And the user could be given a one time autorun stating that a s/he is now running a new kernel (umm a bit scarry - unless the right words found), and if new problems are found to use the grub boot menu to choose an older kernel. (or only if they / detection method) run the the non-current kernel.
I guess if the kernel sees the "not yet booted and run" flag for it's own version, it would set the default grub item to the previous kernel (in case it fails to boot). Then if it completes boot the grub entry is re-changed back to what it needs to be.
This could be pretty transparent to the user, but would provide a nice fall back in the rare cases where stuff happens...
I understand Timothy's point, I admin a dell 2650 server, where updated smp kernels would hang during boot. But as it is a production machine, the only thing to do is get it working as fast as you can... choosing the single kernel, or previous kernel gets you back in action again, it would have been nice for the kernel to "detect it's own failure" and go back to the last happy kernel. It is important that this last kernel is still installed !
On Sat, 2006-01-14 at 21:33 -0500, Neal Becker wrote:
This is FC5T1 (with some updates from devel).
If I try to run yum update, it says: Removing: kernel x86_64 2.6.14-1.1696_FC5 installed 84 M kernel x86_64 2.6.15-1.1826.2.9_FC5 installed 82 M
Seems to be acting as if it doesn't recognize these as kernel packages that should be installonly.
The installonly means it will only *install* (as in, along with the other package versions), and not *upgrade* (as in, that would be the only version of the package).
I believe what you are seeing is yum removing the oldest kernels (older than the last two releases on your computer, not counting what kernel your booted up with), and leaving the latest two (or something to that effect).
On 1/14/06, Neal Becker ndbecker2@gmail.com wrote:
Seems to be acting as if it doesn't recognize these as kernel packages that should be installonly.
The yum config is stock FC5T1.
You are misunderstanding what is happening. To be as specific as possible..... the begging of your yum session log you should see: "Loading "installonlyn" plugin"
the "installonlyn" plugin is use to automatically remove older kernels. the configuration of this plugin is found at: /etc/yum/pluginconf.d/installonlyn.conf
I personally change the defaults on my rawhide box for this plugin so that tokeep=4, so I can do some additional troubleshooting of kernels.
If you want to understanding how this works take a look at /usr/lib/yum-plugins/installonlyn.py
-jef