7:59 a.m.
Hello all,
During the last couple of weeks 2.6.19 and 2.6.20 were pushed to
fc6-updates.
With the push, all older kernel updates (2.6.18-xxx) were removed from
the main, and mirror servers.
Due to lack of sleep I removed the old 2.6.18 kernel I had on my
development machine (rpm -e $(rpm -qa | grep 2.6.18) should not be done
@5am... ;)) - just to find out that vmware-server dies a horrible death
(taking the host with it) when combined with kernels >= 2.6.19.
Now, I'm left with a problem, I cleared the yum cache and there are no
2.6.18 RPMs available from any official source (beyond the initial
-core RPMs), and using 2.6.19/20 will most likely send me to the loony
bin. (Eating my software raid5 with it)
My request is simple *, keep the old -updates kernels, or at least the
latest 5 of them, on the servers - just in-case something goes horribly
wrong and some people need an old kernel. Unlike other packages, the
kernel tends to push forward quite rapidly - breaking things from time
to time (binary modules - mostly). While I know that Fedora != RHEL,
and doesn't maintain a stable kernel-ABI, I doubt that keeping older
versions of the kernel (just in-case someone needs them) will generate
too much noise/problems/over-head.
As for me, I'm back to the original -core kernel (2798?) waiting for a
vmware fix... :(
- Gilboa
* Or so it seems to me.
9:31 a.m.
Dnia 09-04-2007, pon o godzinie 15:59 +0300, Gilboa Davara napisał(a):
vmware-server dies a horrible death
(taking the host with it) when combined with kernels >= 2.6.19.
Now, I'm left with a problem
I'm not affiliated with VMware, but it's
obvious for anyone who have
ever used their free products, that:
http://ftp.cvut.cz/vmware/
contains vmware-any-any-update*, which makes VMware server compile even
under -rc series kernels and is updated pretty often.
Anyhow, supporting old versions of software indefinitely, because they
can break some proprietary other piece of software, is totally against
Fedora goals. Go to VMware and make them put their modules into the
official kernel or learn how to fix things yourself (which in this
particular case is very easy, thanks to VMware, which aren't that evil
after all).
Lam
10:31 a.m.
Leszek Matok wrote:
Anyhow, supporting old versions of software indefinitely, because
they
can break some proprietary other piece of software, is totally against
Fedora goals. Go to VMware and make them put their modules into the
official kernel or learn how to fix things yourself (which in this
particular case is very easy, thanks to VMware, which aren't that evil
after all).
Lam
Not running any proprietary software here. Pure vanilla Fedora Core 6.
(Not even
livna enabled at the moment.) However, kernel-2.6.20-1.2933.fc6 broke
syslog.
Still investigating. Currently suspect a race condition in udev which
fails to create
a node sufficiently "soon" for the normal start of syslog. Currently
only a hypothesis
though. Actual problem may be something else. It has shown up on at
least one
other machine, based on an exchange on fedora-list. We'll see whether there
are more widespread reports as more people notice that /var/log/messages is
empty.
My solution is to: first disable the yum-updatesd service. Second,
change in
/etc/yum/pluginconf.d/installonlyn.conf the line
enabled=1
to
enabled=0
This means that I run "yum update" regularly at an appropriate time
(just after
a backup) and regularly do a "df" to see whether I need (space in /boot
is critical)
to manually remove ("yum remove") some old kernels ("rpm -q kernel"
for
a list).
Obviously, manually minding the store is not possible for everyone.
10:39 a.m.
On Mon, 2007-04-09 at 16:31 +0200, Leszek Matok wrote:
Dnia 09-04-2007, pon o godzinie 15:59 +0300, Gilboa Davara
napisał(a):
> vmware-server dies a horrible death
> (taking the host with it) when combined with kernels >= 2.6.19.
> Now, I'm left with a problem
I'm not affiliated with VMware, but it's obvious for anyone who have
ever used their free products, that:
http://ftp.cvut.cz/vmware/
contains vmware-any-any-update*, which makes VMware server compile even
under -rc series kernels and is updated pretty often.
Anyhow, supporting old versions of software indefinitely, because they
can break some proprietary other piece of software, is totally against
Fedora goals. Go to VMware and make them put their modules into the
official kernel or learn how to fix things yourself (which in this
particular case is very easy, thanks to VMware, which aren't that evil
after all).
Lam
First, the automated "Supporting old versions of software .. break some
proprietary .. is totally against Fedora goals" response has nothing to
do with my post.
I said -nothing- about support, I was talking about keeping the older
kernels -on the servers- instead of deleting them once they are two
weeks old.
Second, I'm wasn't talking about "software", I was talking about the
kernel and the kernel only. (Simply because the kernels changes very
frequently tends to break a lot of software/hardware - proprietary or
not.)
A couple of examples: (From the last couple of weeks)
1. Recent FC5 kernels (coupled with FC5's mkinird) generate invalid
initrd images on my software raid based file server. While easily solved
(I -can- generate the initrd file by hand), only older 2.6.17.fc5
kernels work out of the box.
2. My brother's Athlon64/3800x2 machine does not boot with 2.6.19 kernel
due to ACPI/BIOS problems.
3. Older fc6/xen kernel crashed a couple of my servers.
And I can continue.
As I said. I'm not asking for support. I'm not asking for stable ABI.
Just keep the files on the server. It's -that- simple.
- Gilboa
11:56 a.m.
At 4:31 PM +0200 4/9/07, Leszek Matok wrote:
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="=-uwdQO9JtMDynuRAryFXq"
Dnia 09-04-2007, pon o godzinie 15:59 +0300, Gilboa Davara napisa?(a):
> vmware-server dies a horrible death
> (taking the host with it) when combined with kernels >= 2.6.19.
> Now, I'm left with a problem
I'm not affiliated with VMware, but it's obvious for anyone who have
ever used their free products, that:
http://ftp.cvut.cz/vmware/
contains vmware-any-any-update*, which makes VMware server compile even
under -rc series kernels and is updated pretty often.
Anyhow, supporting old versions of software indefinitely, because they
can break some proprietary other piece of software, is totally against
Fedora goals. Go to VMware and make them put their modules into the
official kernel or learn how to fix things yourself (which in this
particular case is very easy, thanks to VMware, which aren't that evil
after all).
There are many good reasons for needing an older kernel, including
fulfilling a request for testing a bug against a kernel older than is
currently installed. Although it would be best for Fedora users if all
updated packages were retained and available for downgrading, certainly the
kernel deserves special consideration, as changes to the kernel can prevent
the entire system from working.
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
12:07 p.m.
On Monday 09 April 2007 12:56:59 Tony Nelson wrote:
Although it would be best for Fedora users if all
updated packages were retained and available for downgrading, certainly the
kernel deserves special consideration, as changes to the kernel can prevent
the entire system from working.
And where do we find this mythical beast of unlimited storage?
--
Jesse Keating
Release Engineer: Fedora
12:08 p.m.
On Mon, Apr 09, 2007 at 01:07:52PM -0400, Jesse Keating wrote:
> Although it would be best for Fedora users if all
> updated packages were retained and available for downgrading, certainly the
> kernel deserves special consideration, as changes to the kernel can prevent
> the entire system from working.
And where do we find this mythical beast of unlimited storage?
gmail.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
1:13 p.m.
On 4/9/07, Jesse Keating <jkeating(a)redhat.com> wrote:
On Monday 09 April 2007 12:56:59 Tony Nelson wrote:
> Although it would be best for Fedora users if all
> updated packages were retained and available for downgrading, certainly the
> kernel deserves special consideration, as changes to the kernel can prevent
> the entire system from working.
And where do we find this mythical beast of unlimited storage?
Instead of leaving the old versions in the updates repository which
uses space on all the mirrors, I wonder if it would make sense to have
a separate repository for old versions. The archives repository would
only need to be on the master server or could even be a separate
server. People who needed old packages could enable the repository.
- Ian
2:10 p.m.
On Mon, 2007-04-09 at 13:07 -0400, Jesse Keating wrote:
On Monday 09 April 2007 12:56:59 Tony Nelson wrote:
> Although it would be best for Fedora users if all
> updated packages were retained and available for downgrading, certainly the
> kernel deserves special consideration, as changes to the kernel can prevent
> the entire system from working.
And where do we find this mythical beast of unlimited storage?
... and this is why open discussions always turn into spam fights.
I asked for a special consideration concerning old kernel releases (!)
that -were- released as an update for -active- fedora releases. (Read:
F-Current, F-Current - 1).
Soon Mr Matok turned the "kernel" into "software", and the need to
keep
the kernel -on the server- into supporting proprietary non-GPL (!!!)
kernel modules (!!!) and from there on, we need mythical beast with
unlimited storage and hordes of men to support the 2.4.x kernel Fedora
Core 1 just because nVidia/ATI/VMWare/etc/<insert binary module name>
refuses to fix their bugs.
If I can be allowed to stick to the subject, lets talk about numbers.
Each kernel release (x86_64 in my case, including the
kernel-devel.[i686/i586], xen and kdump) eats around 80MB.
Keeping the 5 latest releases translates to 400MB.
In comparison, each OO release is ~600MB. (660MB to be exact)
-updates currently hold two OO releases - add -core to the mix, and OO
alone eats 1800MB.
Now I may be dead wrong, and wasting 400MB of old kernels (for released
versions only - not rawhide/test releases) is way-above-and-beyond
Fedora's current capacity.
Maybe Fedora should store the last released kernel of each minor
release. (2.6.17-xxx, 2.6.18-xxx, etc) - I don't know, lets here some
open discussion about it.
... Somehow I doubt that writing off my post as "not enough storage,
against policy - good bye" can be considered constructive in any type or
form.
- Gilboa
2:19 p.m.
On Mon, 2007-04-09 at 22:17 +0300, Gilboa Davara wrote:
On Mon, 2007-04-09 at 13:07 -0400, Jesse Keating wrote:
> On Monday 09 April 2007 12:56:59 Tony Nelson wrote:
> > Although it would be best for Fedora users if all
> > updated packages were retained and available for downgrading, certainly the
> > kernel deserves special consideration, as changes to the kernel can prevent
> > the entire system from working.
>
> And where do we find this mythical beast of unlimited storage?
... and this is why open discussions always turn into spam fights.
I asked for a special consideration concerning old kernel releases (!)
that -were- released as an update for -active- fedora releases. (Read:
F-Current, F-Current - 1).
Soon Mr Matok turned the "kernel" into "software", and the need to
keep
the kernel -on the server- into supporting proprietary non-GPL (!!!)
kernel modules (!!!) and from there on, we need mythical beast with
unlimited storage and hordes of men to support the 2.4.x kernel Fedora
Core 1 just because nVidia/ATI/VMWare/etc/<insert binary module name>
refuses to fix their bugs.
If I can be allowed to stick to the subject, lets talk about numbers.
Each kernel release (x86_64 in my case, including the
kernel-devel.[i686/i586], xen and kdump) eats around 80MB.
Keeping the 5 latest releases translates to 400MB.
In comparison, each OO release is ~600MB. (660MB to be exact)
-updates currently hold two OO releases - add -core to the mix, and OO
alone eats 1800MB.
Now I may be dead wrong, and wasting 400MB of old kernels (for released
versions only - not rawhide/test releases) is way-above-and-beyond
Fedora's current capacity.
Maybe Fedora should store the last released kernel of each minor
release. (2.6.17-xxx, 2.6.18-xxx, etc) - I don't know, lets here some
open discussion about it.
... Somehow I doubt that writing off my post as "not enough storage,
against policy - good bye" can be considered constructive in any type or
form.
- Gilboa
s/lets here/lets hear/g
As I said, 5am... :(
- Gilboa
3:24 p.m.
On Monday 09 April 2007 15:10:56 Gilboa Davara wrote:
Now I may be dead wrong, and wasting 400MB of old kernels (for
released
versions only - not rawhide/test releases) is way-above-and-beyond
Fedora's current capacity.
Maybe Fedora should store the last released kernel of each minor
release. (2.6.17-xxx, 2.6.18-xxx, etc) - I don't know, lets here some
open discussion about it.
... Somehow I doubt that writing off my post as "not enough storage,
against policy - good bye" can be considered constructive in any type or
form.
Once we merge and start using koji as the buildsystem externally, we'll have
public access to the old builds that were shipped. They won't be on the
mirrors but they will be obtainable. This should satisfy any need.
--
Jesse Keating
Release Engineer: Fedora
4:24 p.m.
On Mon, 2007-04-09 at 16:24 -0400, Jesse Keating wrote:
On Monday 09 April 2007 15:10:56 Gilboa Davara wrote:
> Now I may be dead wrong, and wasting 400MB of old kernels (for released
> versions only - not rawhide/test releases) is way-above-and-beyond
> Fedora's current capacity.
> Maybe Fedora should store the last released kernel of each minor
> release. (2.6.17-xxx, 2.6.18-xxx, etc) - I don't know, lets here some
> open discussion about it.
> ... Somehow I doubt that writing off my post as "not enough storage,
> against policy - good bye" can be considered constructive in any type or
> form.
Once we merge and start using koji as the buildsystem externally, we'll have
public access to the old builds that were shipped. They won't be on the
mirrors but they will be obtainable. This should satisfy any need.
Good enough.
I (we?) don't need the old RPMs to be mirrored.
I (... we) need them obtainable.
- Gilboa
12:30 a.m.
At 12:24 AM +0300 4/10/07, Gilboa Davara wrote:
On Mon, 2007-04-09 at 16:24 -0400, Jesse Keating wrote:
> On Monday 09 April 2007 15:10:56 Gilboa Davara wrote:
> > Now I may be dead wrong, and wasting 400MB of old kernels (for released
> > versions only - not rawhide/test releases) is way-above-and-beyond
> > Fedora's current capacity.
> > Maybe Fedora should store the last released kernel of each minor
> > release. (2.6.17-xxx, 2.6.18-xxx, etc) - I don't know, lets here some
> > open discussion about it.
> > ... Somehow I doubt that writing off my post as "not enough storage,
> > against policy - good bye" can be considered constructive in any type or
> > form.
>
> Once we merge and start using koji as the buildsystem externally, we'll have
> public access to the old builds that were shipped. They won't be on the
> mirrors but they will be obtainable. This should satisfy any need.
Good enough.
I (we?) don't need the old RPMs to be mirrored.
I (... we) need them obtainable.
<metoo> Yes. </metoo>
--
____________________________________________________________________
TonyN.:' <mailto:tonynelson@georgeanelson.com>
' <http://www.georgeanelson.com/>
1:33 p.m.
Dnia 09-04-2007, pon o godzinie 12:56 -0400, Tony Nelson napisał(a):
Although it would be best for Fedora users if all
updated packages were retained and available for downgrading, certainly the
kernel deserves special consideration, as changes to the kernel can prevent
the entire system from working.
That's what "installonlyn" plugin is
for. That's why the default
behavior (without the plugin or when using apt instead of yum) is even
better and can be summarized as "keep as many kernels as the disk can
lift".
Seriously, the whole thread started when Gilboa did that:
Due to lack of sleep I removed the old 2.6.18 kernel I had on my
development machine (rpm -e $(rpm -qa | grep 2.6.18) should not be
done @5am... ;))
So you see, there's nothing in Fedora's handling of kernel
upgrades that
can break your system... apart from the user.
I for myself keep my system from upgrading ~20 packages (including the
kernel, not because of regressions, but my own patches which I'm too
lazy to maintain as part of my own RPM) and Fedora policy of not keeping
every older version of every package doesn't bother me.
Lam
9:31 a.m.
Howdy,
On Apr 9, 2007, at 15:59, Gilboa Davara wrote:
As for me, I'm back to the original -core kernel (2798?) waiting for a
vmware fix... :(
This is actually old issue already. (.../linux/config.h disappeared
among
other things with 2.8.19 and some other macros changed which broke
quite a buch of drivers)
You can use following unofficial patch to fix it.
http://ftp.cvut.cz/vmware/vmware-any-any-update108.tar.gz
If you install brand new (Vmware) system, you need to
first try vmware-config.pl and once it starts prompting you
that your kernel is /usr/src/linux/... just interrupt it with ^C,
unpack the above archive, enter the directory and start
runme.pl. That will solve the issue.
Oh, and the vmware-tools-any*.tar.gz is for fixing the
client (emulated vm) side tools.
Cheers,
:-) riku
--
[ this .signature intentionally left blank ]
9:50 a.m.
New subject: Mirror/server RFE: Do not remove old kernel from updates. (vmware)
On Mon, 2007-04-09 at 15:59 +0300, Gilboa Davara wrote:
Hello all,
During the last couple of weeks 2.6.19 and 2.6.20 were pushed to
fc6-updates.
With the push, all older kernel updates (2.6.18-xxx) were removed from
the main, and mirror servers.
Due to lack of sleep I removed the old 2.6.18 kernel I had on my
development machine (rpm -e $(rpm -qa | grep 2.6.18) should not be done
@5am... ;)) - just to find out that vmware-server dies a horrible death
(taking the host with it) when combined with kernels >= 2.6.19.
Now, I'm left with a problem, I cleared the yum cache and there are no
2.6.18 RPMs available from any official source (beyond the initial
-core RPMs), and using 2.6.19/20 will most likely send me to the loony
bin. (Eating my software raid5 with it)
Just to reduce the number of vmware-related comments - the problem is
not config.h, vmmon/compat-kernel.h or vmnet/checksum or anything
vmware-config.pl...
The vmware's vmmon kernel module seems to crash and burn when combined
with new(er) kernels. Read: The vmmon kernel modules dies, taking the
host system with it.
Applying vmware-any-to-any patch may get the vmmon/vmnet compiled again
(I rather do it by hand - but that's me), but it stop it from crash the
host system's kernel.
- Gilboa
6270
days inactive
6271
days old
15 comments
8 participants
participants (8)
-
Gilboa Davara -
Ian Burrell -
Jesse Keating -
John DeDourek -
Leszek Matok -
Matthew Miller -
Riku Meskanen -
Tony Nelson