Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Novell Changes Enterprise Linux Kernel Mid-Stream

timothy posted more than 4 years ago | from the this-will-dominate-the-evening-news dept.

SuSE 96

darthcamaro writes "Enterprise Linux kernels, from Red Hat or Novell, don't change version numbers inside of a release, right? While that has been the case for the last decade of Red Hat and Novell releases, Novell is breaking the mold with SUSE Linux Enterprise 11 service pack one. Instead of backporting new kernel features to the kernel they originally shipped with — which maintains software and hardware vendor certification — they've re-based their Linux kernel version altogether. '"There were some things that led us to update the kernel itself, which is something that we normally don't do: Neither SLES 9 or SLES 10 got a kernel update," Markus Rex, director of open platform solutions at Novell, told InternetNews.com. "But in this particular case, after deep discussion with our ISV and hardware vendors that gave us certifications, we felt in this case a kernel update was the appropriate step to take.'"

cancel ×

96 comments

Sorry! There are no comments related to the filter you selected.

Why not just call it SuSE 12? (1)

Lurching (1242238) | more than 4 years ago | (#32282210)

That would be more consistant.

Re:Why not just call it SuSE 12? (0)

Anonymous Coward | more than 4 years ago | (#32282316)

cause then the issue of whether or not to use version #13 would be on the horizon and the stock price of the holding companies would hiccup.

Re:Why not just call it SuSE 12? (1, Informative)

Anonymous Coward | more than 4 years ago | (#32282700)

12 is going to have a major update to the GI, and some other obvious changes to make it more marketable. on the back end they have several teams working on projects with XEN, SAP... and they dont want to deviate for the timeline that they have presented.

Re:Why not just call it SuSE 12? (0)

Anonymous Coward | more than 4 years ago | (#32283530)

GI?

Re:Why not just call it SuSE 12? (1)

colourmyeyes (1028804) | more than 4 years ago | (#32288888)

Gastrointestinal.

Big jump (1)

arth1 (260657) | more than 4 years ago | (#32282212)

It's not like it's a small jump either -- it's from 2.6.27 to 2.6.32, which means a whole boatload of changes, some of which can really mess up a production environment (IME, anyone?)

Re:Big jump (1)

cynyr (703126) | more than 4 years ago | (#32282528)

why are you updating that package on production servers then? maybe the test/dev box.

Re:Big jump (1)

think_nix (1467471) | more than 4 years ago | (#32282626)

And what do you do about security updates and sometimes dependancy nightmare when yast throughs in SP1 as a dependancy.

TFA:"The biggest thing is that, as a server operating system, we have to make sure that we run on the appropriate server chips," Rex said. "So the key decision factor for us was that we wanted to make sure we supported the newest hardware to the maximum capabilities."

First part sounds cocky to me . Second is understandable as long as Hardware vendors play ball. Whole thing smells fishy to me.

Re:Big jump (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#32282724)

if it sounds like a cock, and smells like a fish.......

Re:Big jump (1)

neurovish (315867) | more than 4 years ago | (#32282906)

And what do you do about security updates and sometimes dependancy nightmare when yast throughs in SP1 as a dependancy.

The easiest way to fix that is by upgrading sles servers to redhat. Does Novell still use 3 separate and incompatible update mechanisms?

Re:Big jump (1)

think_nix (1467471) | more than 4 years ago | (#32283096)

The easiest way to fix that is by upgrading sles servers to redhat. Does Novell still use 3 separate and incompatible update mechanisms?

Exactly I always recommend RHEL for Enterprise. Personally I really don't care for Novell , especially with all their Red Hat bashing of late. Novell support sucks , and the community forum is not much better.

To get back to your question asfaik it is only zypper now which is also used in the opensuse world. Which obsoletes rug zmd(formerly red carpet) and zypper +yast frontend which made 9 and 10 such a mess.

Re:Big jump (1)

spun (1352) | more than 4 years ago | (#32283822)

Are you seriously using 11 on production servers? We've yet to upgrade to SP3 of 10. 11 breaks a lot of things. Where did HA go? Replaced by some proprietary package. Will VMware tools work with the 11 kernel? Nope, sorry. Does it add anything in the way of security or stability? Ah, not so much.

Re:Big jump (1)

think_nix (1467471) | more than 4 years ago | (#32284202)

Im not , but some customers of mine are, what I was told had to do with licensing between sles and the oes version of sles.

Re:Big jump (2, Interesting)

twilightzero (244291) | more than 4 years ago | (#32284940)

We're using SLES 11 on production servers with no problems. We decided to jump straight to 11 after getting burned for being 9.4 too long and nobody in the world supports it any more.

As far as VMware Tools support on SLES 11, according to VMWare's official documentation it is:

http://www.vmware.com/pdf/osp_install_guide.pdf [vmware.com] start on page 18

Re:Big jump (1)

spun (1352) | more than 4 years ago | (#32285518)

We upgraded all our SLES 9 to SLES 10 a few years ago and have been pretty happy with it.

As for the tools, ah, have you tried it? The tools they provide for 11 are the new, mostly untested and unfinished open source tools. They don't work right for me, vmxnet3 is broken and the tools come up as 'unmanaged' in VSphere Center. Time synch seems broken, too, but that may be a different problem. In any case, they seem like open beta quality, not production ready. Don't get me wrong, I'm glad VMWare is open sourcing their tools, but I don't want to play beta tester with our production servers.

Re:Big jump (1)

jschrod (172610) | more than 4 years ago | (#32287290)

The broken time sync is a VMware problem that's independent of the respective distribution. A lot of my customers have it with RHEL as well.

Interestingly, newer VMware workstation products don't have it any more, while the server products still have that issue. Lately, I'm sincerely waiting for other virtualization products to catch up, to be able to evaluate a switch.

Re:Big jump (1)

spun (1352) | more than 4 years ago | (#32292912)

The broken time synch is a kernel timekeeping issue, you can change the Mhz setting for interrupts to something around 100 instead of 250 or 1000. This allows the simulated clock hardware to keep up. The newer kernels use different timekeeping methods and should not have the same problem.

Re:Big jump (1)

jschrod (172610) | more than 4 years ago | (#32293076)

Changing the MHz setting doesn't help always; sometimes the clock source (hpet vs. pit) is an issue as well. Sometimes none of the methods listed in VMware's tech note about timekeeping issues helps.

Re:Big jump (1)

spun (1352) | more than 4 years ago | (#32293326)

Yup, I've had luck with pmtmr. But if your Mhz setting is 1000, as it is with some older SLES and Red hat kernels, nothing will work. We used to have some servers that were running ntpdate every minute as a cron job :(

Re:Big jump (1)

Vairon (17314) | more than 4 years ago | (#32285144)

What did 11 break? It's broken nothing for me.

SLES 11 HAE is not some proprietary package. It's 100% OSS. It's made up of:
Pacemaker (http://www.clusterlabs.org/)
OpenAIS (http://www.openais.org/doku.php)
DRBD (http://www.drbd.org/)
OCFS2 (http://oss.oracle.com/projects/ocfs2/)

You can get it here: http://download.novell.com/Download?buildid=jC1wpkedb7A~ [novell.com]

VMware tools DO work with the SLES 11 kernel. You can get them here:
http://packages.vmware.com/tools/esx/4.0latest/sles11/index.html [vmware.com]

As for security, it adds selinux availability, TPM support, more locked down defaults and a YaST security module for easier configuration.

While it's anecdotal, I've never had a SLES 11 server lock up whereas due to hardware/driver bugs I've had SLES 10 SP2 lockup on new HP hardware plenty of times until we upgraded the kernel.

Re:Big jump (1)

spun (1352) | more than 4 years ago | (#32285444)

Hmph. Thanks for making me look like an amateur, buddy. :P

I meant that the HA in 11 is not drop in compatible with 10. I thought it was a proprietary package, glad it isn't.

And the vmware tools don't work 'out of the box,' like you point out, you have to go download them. And have you looked at them? Tried using them? Those are the new open source vmware tools, they will compile, yes, but they have not worked correctly with Vsphere center, at least not for me. The tools still come up as 'unmanaged' in the summary, and the network drivers don't work correctly with the vmxnet3 flexible adapter.

We haven't had any hardware problems on 10sp2, on IBM blades running VSphere. In any case, our upgrade path looks like vmware->4.1, then SLES 10sp3, THEN 11. We're a state agency, so, you know, we don't exactly move at the speed of light.

More importantly, now I've met another Slashdotter that uses SLES, which is cool. We are a Netware shop, and that led to SLES Linux, which led to management witnessing open source 'just work,' which led to our replacing a lot of closed source systems with open source. Which has saved the sate, by my estimation, over $200,000 per year so far. After we replace Sybase, it will be even more.

All that goes to show that, despite any negative connotations I may have conveyed earlier, I absolutely love SLES and Novell.

Re:Big jump (1)

think_nix (1467471) | more than 4 years ago | (#32287838)

Try going Red Hat , maintenance/update licenses are cheaper and your e-Directory will run on that also. Also runs on Solaris. Plus you have a lot less headaches linux wise with Red Hat. Do yourself a favor look into it, sles isnt all that. Although If your using their proprietary stuff then you have vendor lock in , their NSS Filesystems come to mind since you mentioned Netwhere.

Re:Big jump (1)

spun (1352) | more than 4 years ago | (#32292936)

As we have a Novell Netware contract (which isn't going away), we get about 60 Linux licenses for free, so, no. Not going to Red Hat. Not that I think it's any better anyway. I like SuSE. I'd prefer something Debian based if I was going to switch.

Re:Big jump (1)

markus o'farkus (98120) | more than 4 years ago | (#32285402)

Are you seriously using 11 on production servers? We've yet to upgrade to SP3 of 10. 11 breaks a lot of things. Where did HA go? Replaced by some proprietary package.

HA was not replaced by a proprietary package at all. It was moved out of the default SLES install into an "add-on product" called SLES 11 HAE (HA Extension). It's still based on 100% open source components. Of course, it's an enterprise release and subscriptions are licensed separately. That's really the big difference, it's not included with SLES any longer. I believe this is the same model RHEL/RHCS uses. For what it's worth, she HAE actually one of the best improvements in SLES 11. Now based on OpenAIS instead of HeartBeat and is much more functional and configurable compared to SLES 10 HA (or Red Hat Cluster Suite for that matter). And I'll just add that RHEL still doesn't offer a supported DRBD implementation.

Will VMware tools work with the 11 kernel? Nope, sorry.

VMware tools work fine with the 11 kernel. I can't tell you how many SLES 11 images I have set up with both VMware Workstation or ESX, dozens at least, and I installed VMware-tools on all of them. I have seen an issue with some ESX 3.5 tool package builds. It doesn't happen in every case, if I recall, but when it does you'll see an error enabling the "paravirtualized scsi driver". One fix for this I know will work is to update your ESX to version 4. I believe this only happens with certain builds of 3.5.

We've yet to upgrade to SP3 of 10. 11 breaks a lot of things.

On the subject of stability, you shouldn't be waiting to update your SLES 10 to SP3. Many stability improvements in SP3. Honestly 11 seems pretty rock solid to me, but it's hard to tell since a lot of customers wait for the first SP to be released and tested a little before deploying to production.

Re:Big jump (1)

spun (1352) | more than 4 years ago | (#32285778)

We are on version 4, and I can state with certainty the tools will not compile and work correctly. While the new open source VMware tools will work slightly better, they still do not function correctly.

As we are a state agency, our upgrade time tables are a little slow. We're testing SP3 now. We had to upgrade a test server to VMWare 4.1 to get the tools to work, the downloadable open source tools package for SP3 does not work as advertised, and the tools available on VSphere 4 do not work at all. If you see that the paravirtualized scsi driver does not compile, there will be other, more severe problems as well. The vmxnet3 driver won't work either, and that is a deal breaker for us.

Re:Big jump (1)

bill_mcgonigle (4333) | more than 4 years ago | (#32286520)

TFA:"The biggest thing is that, as a server operating system, we have to make sure that we run on the appropriate server chips," Rex said. "So the key decision factor for us was that we wanted to make sure we supported the newest hardware to the maximum capabilities."

To the maximum capabilities

That sounds suspiciously like, "we could backport to support all the hardware that RHEL supports, but that's hard, expensive work we can skip if we just drop in a newer kernel. Yeah, so we're passing on our costs to our users, but here's one optimization we can hang our hat on that's not in RHEL's kernel, so that's really why we're doing it. Wink wink, nudge nudge."

Look, I run Fedora on my personal machines, new kernels are great, but my clients want to have some known period of stable kernel ABI's so they can plan their business infrastructure.

Maybe what Novell really needs to do is become a downstream of CentOS and add its value-added technology on top of that. Then they can save costs and still target the 'enterprise' crowd. As is, they're effectively scaring away all those potential customers. Unless they want to define a new niche of just-in-time enterprise IT planning - stranger things have happened.

Re:Big jump (1)

bjourne (1034822) | more than 4 years ago | (#32286814)

I used to work with Novells ancient backported to death 2.6.8 kernels. Thousands of patches applied over a period of over five years. Supposedly, rock-solid, enterprise grade, robust, deployment-ready, yadda yadda, kernels. Except they weren't. They kernel oopsed much more frequently than the 2.6.20 kernels that were bleeding edge at the time. And good luck trying to debug the crashes. Because there were two totally different development lines, the Novell and the mainline one, it was impossible to know if the bug was fixed in a later version of the mainline kernel or even if it was any of Novell's patches that caused the problem in the first place.

Plus, when a regular linux kernel crashes, usually you can ask for help debugging the problem on a mailing list. Or open a ticket on a public bug tracker. But a problem in a insanely patched Novell kernel? No one except Novell themselves can fix it.

Re:Big jump (1)

bill_mcgonigle (4333) | more than 4 years ago | (#32287330)

Good info, thanks. Was there a lack of testing that led to the instability? No offence, but poor coding practices or lack of skill among some contributors?

I won't argue against the superiority of the open model for a second, but many customers want a buck-stops-here solution. I'll readily grant that commercial distro support doesn't always get you that either (sometimes I pick up work filling in those gaps).

Stability versus ABI (2, Funny)

Josh Triplett (874994) | more than 4 years ago | (#32282266)

Enterprise distributions avoid kernel version upgrades for two distinct reasons: perceived stability and fixed API/ABI for third-party modules. In this case, upgrading from 2.6.27 to 2.6.32 may well improve stability, particularly since many other distributions plan to ship 2.6.32 in their next release as well. As always, any upgrade can lead to the occasional regression that enterprise customers hate, but hey, paid support means they'll get a fix. So, that just leaves API/ABI issues, hence the discussions with ISVs and such. Third-party modules keep becoming less and less important with each new kernel version, and I can readily believe that the pain of dealing with API/ABI issues no longer outweighs the benefits of new hardware support and features provided by 2.6.32.

Re:Stability versus ABI (4, Informative)

cynyr (703126) | more than 4 years ago | (#32282548)

Third partys should be working to get their code included in the kernel, or should just deal with the changes. This has been said many times by the kernel developers.

Re:Stability versus ABI (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32282852)

Kernel developers should use and support a stable ABI. This has been said many times by everyone else.

Re:Stability versus ABI (1, Insightful)

Sycraft-fu (314770) | more than 4 years ago | (#32283696)

The kernel devs can say that all they like. 3rd parties are then free to say "Fuck you," and either not support Linux or do it poorly.

Maybe there's something to be said for not being jerks about it and trying to meet people half way. Try to give the hardware companies what they want, maybe they support your OS more.

Re:Stability versus ABI (0)

Anonymous Coward | more than 4 years ago | (#32288526)

Umm, isn't it the other way around? GNU/Linux doesn't support a particular peace of hardware than you'll just buy from a competitor that does.

Re:Stability versus ABI (1)

xouumalperxe (815707) | more than 4 years ago | (#32293662)

Both happen. Sure, if I want to use Linux, so I'll pick hardware that works with it. But on the other end of the deal the hardware manufacturers look at the trouble that producing linux drivers gives them versus the number of users they gain, and might decide to move away if there aren't enough users to gain for all that trouble. Not enough demand to produce an offer and all that.

Re:Stability versus ABI (0)

Anonymous Coward | more than 4 years ago | (#32283304)

Enterprise distributions avoid kernel version upgrades for one reason: so that end users have a need to upgrade.

Otherwise, it would never be necessary and each vendor would have to support their old crappy releases forever.

Speaking from inside the firewall here.

Re:Stability versus ABI (1)

Kjella (173770) | more than 4 years ago | (#32284970)

Enterprise distributions avoid kernel version upgrades for two distinct reasons: perceived stability and fixed API/ABI for third-party modules.

No, if it fixes 2% of your servers and breaks 1% it's more stable, but the reason they don't is because you don't break something that works. Oh sure, everybody will complain a little over things that have never worked, but the real anger comes when you get "I upgraded to $foo and now my sound/wireless/suspend/whatever is BROKEN!!!". That is pretty much the whole difference between service packs and an upgrade, if you have to start worry about your server breaking between upgrades then it's time to switch distro ASAP.

Re:Stability versus ABI (1)

simpz (978228) | more than 4 years ago | (#32287896)

Enterprise distributions avoid kernel version upgrades for two distinct reasons: perceived stability and fixed API/ABI for third-party modules.

Not true and most everyone has missed the point. Enterprise distributions avoid kernel upgrades for the stability of the Application ABI/API, not kernel modules ABI.
This is all RH guarantees, you will be building a new NVIDIA driver with every minor RHEL kernel change for example.

Enterprises want a stable base for their applications with no surprises.

Re:Stability versus ABI (0)

Anonymous Coward | more than 4 years ago | (#32288680)

DKMS

outrageous! (5, Funny)

nomadic (141991) | more than 4 years ago | (#32282268)

This is unconscionable and fills me with deep, passionate rage. I can't believe a company followed a nonstandard numbering convention for one of their releases. That's the most evil think I've ever heard and it heralds the downfall of modern society.

Re:outrageous! (3, Insightful)

Ethanol-fueled (1125189) | more than 4 years ago | (#32282554)

What is unconscionable and fills me with deep, passionate rage is when the guys who run a distro think it's cute to name their releases after animals.

Nothing's more annoying than checking a forum only to have to google a bunch of stupid animal names to see which version I have installed.

Re:outrageous! (1, Flamebait)

quantumplacet (1195335) | more than 4 years ago | (#32282856)

https://wiki.ubuntu.com/Releases [ubuntu.com]

bookmark this. now you never have to go through the agony of googling a bunch of stupid animal names again. think of what you can do with all that free time.

Re:outrageous! (2, Interesting)

Anonymous Coward | more than 4 years ago | (#32284100)

http://debian.org

bookmark this. now you never have to go through the agony of googling a bunch of stupid animal names again. think of what you can do with all that free time.

Fixed.

Re:outrageous! (0, Flamebait)

quantumplacet (1195335) | more than 4 years ago | (#32284956)

Now, I've used both Debian and Ubuntu quite a bit, and don't want to get into which is better, but when it comes to naming conventions you can't really point to either one as being good or professional. Debian uses Toy Story characters for christ sake. And yes, I know they're 'codenames' not release names, but the GP's point is unaffected by this; when you're in Debian forums people constantly refer to the codename. The only reason that Debian names are any easier to remember is because they don't change for 5 years.

Re:outrageous! (-1)

Anonymous Coward | more than 4 years ago | (#32284976)

http://www.apple.com/macosx/

bookmark this. now you never have to go through the agony of googling a bunch of stupid animal names again. think of what you can do with all that free time.

Fixed.

Fixed.

Re:outrageous! (1, Funny)

Anonymous Coward | more than 4 years ago | (#32286014)

http://www.microsoft.com/windows/

bookmark this. now you never have to go through the agony of googling a bunch of stupid animal names again. think of what you can do with all that free time.

Fixed.

Fixed.

Broken.

Re:outrageous! (1)

Curmudgeonlyoldbloke (850482) | more than 4 years ago | (#32287564)

So cartoon characters is an improvement is it?

Hell, I use Debian but would much prefer it if they just stuck to numbers.

Re:outrageous! (4, Funny)

nomadic (141991) | more than 4 years ago | (#32285872)

I think the animal adjectives should have to reflect the actual Ubuntu release, like Unstable Urchin, or Dependency-Breaking Duck.

Re:outrageous! (1)

standbypowerguy (698339) | more than 4 years ago | (#32288328)

ROFLMAO! It's times like these I wish I had mod points... Mod parent up!

Re:outrageous! (1)

AdamTheBastard (532937) | more than 4 years ago | (#32286886)

Most of the distro's I have used include a file in /etc which tells you what version you have installed. I also use a distro that thinks it's cute to name their releases after animals. On that machine I can run the following to get the info I need.

> cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.10
DISTRIB_CODENAME=karmic
DISTRIB_DESCRIPTION="Ubuntu 9.10"

On another system based on some hatted fellow's distro I can run the following to get the info I need.

$ cat /etc/redhat-release
CentOS release 5.4 (Final)

On other systems you could start with `cat /etc/*-release` and see where that gets you.

Re:outrageous! (1)

colourmyeyes (1028804) | more than 4 years ago | (#32288974)

$ cat /etc/slackware-version

Good idea? Bad Idea? (5, Insightful)

bernywork (57298) | more than 4 years ago | (#32282294)

The biggest reason why everyone froze their kernels for a major release and back ported was the create what was effectively a driver binary interface. So if a hardware vendor (Yes, I'm looking at you Nvidia) wanted to create a binary driver release for a codebase, that driver release would work for the whole period of support for that codebase. This is because Linux doesn't have a driver ABI.

So getting back to what Novell have done here...It's a hard one, I guess, if they spoke to their ISVs and they said they don't care, then it doesn't matter. If HP / Dell / Lenovo don't care either then, again, that's no problem.

I guess there is always going to be someone out there who hasn't qualified their drivers with Novell for SLES 11 and just does self certification and was expecting their release to keep working (Which was tested against the earlier release) and now has to upgrade their driver because the Linux ABI is a rapidly moving target. On the other hand, a lot of people rely on on Novell / RedHat etc for driver support and don't go back to Dell / HP / Lenovo; if there is problems they point fingers at their Linux vendor first.

Time will tell if this was a good idea or not. Personally, I'm not against it, more hardware support out of the box is better for me, if I run into a problem and have to run older hardware on an older kernel and just upgrade RPMs on my older systems then so be it. I guess that's what versioning in builds is for really isn't it?

Berny

Re:Good idea? Bad Idea? (0, Troll)

cynyr (703126) | more than 4 years ago | (#32282490)

yep, "./configure ${OPTIONS} && make && make install" is hard. Also if it's hardware, the kernel devs have said that the ABI changes to support new features, remove cruft, and improve use. If you want your driver to just always work, get it in mainline. See the linux kernel driver project by greg K. H.

Re:Good idea? Bad Idea? (1)

bernywork (57298) | more than 4 years ago | (#32291388)

I don't disagree with what the devs are doing, in fact I fully support it, it's an open source product, you're getting benefit from it, submit your driver. Unfortunately, for someone like Nvidia, it doesn't work that well because of the amount of work arounds that they are doing in the driver. They would also end up maintaining a tree and be under someone else's release schedule, as well as a few other drawbacks that I just don't think they would go for....

MODS: Why was the parent modded troll? +1 informative pls

Re:Good idea? Bad Idea? (2, Interesting)

talcite (1258586) | more than 4 years ago | (#32283888)

I think the biggest surprise here is the update to Xen 4.

Xen 4.0 has barely been released for 3 months and they're moving to it for SLES? Insanity. There's barely any time to determine known bugs. What production environment would want to risk everything from downtime to data loss by using practically untested code?

That said, Xen 4.0 has some really nice features with regards to the Remus checkpointing project. It essentially provides instant failover (with persistent network connections) to commodity hardware. Definitely a feature to keep your eyes on for upcoming RHEL/SLES versions.

Re:Good idea? Bad Idea? (1)

Engeekneer (1564917) | more than 4 years ago | (#32290174)

Yup, the move to Xen4 is pretty interesting. Most other distros go towards KVM, and I tell you, it's not completely trivial to run xen on Ubuntu 10.04. At least stable production systems.

I know.. KVM shoud be better and all that, but that still needs the HW support. This makes reusing older HW tricky.

Funny, they couldn't figure out the old system (2, Interesting)

H1pp13 (666379) | more than 4 years ago | (#32282322)

That's funny. I ran a SLES shop for 3 years and for the entire time, I had a request in to Novell to explain the minor numbering for their kernels in an attempt to keep EMC happy with updates. They put it off saying that they were trying to find a Linux Engineer there to explain. For 3 years!! I do not miss Novell. Not one bit.

Re:Funny, they couldn't figure out the old system (1)

neurovish (315867) | more than 4 years ago | (#32283088)

That's funny. I ran a SLES shop for 3 years and for the entire time, I had a request in to Novell to explain the minor numbering for their kernels in an attempt to keep EMC happy with updates. They put it off saying that they were trying to find a Linux Engineer there to explain. For 3 years!!

I do not miss Novell. Not one bit.

Man, that sounds really familiar. I could see Oracle throwing a fit over them changing the kernel release. They freakout when you only give a server 8GB of swap space!

Not suprising (0, Troll)

Anonymous Coward | more than 4 years ago | (#32282334)

That's why people who wants a stable and reliable server OS chooses Red Hat instead (note that Red Hat offers more recent kernels as an experimental alternative, but it's that, experimental) Of course, there're a lot of people who will be happy with Novell including a new kernel, and that's fine. I guess that's why both exist.

Novell Linux kernel (0)

Anonymous Coward | more than 4 years ago | (#32282414)

In licensing terms, what is different about the Novell Kernel as compared to the Linux kernel?

Re:Novell Linux kernel (0, Troll)

$RANDOMLUSER (804576) | more than 4 years ago | (#32282522)

The Novell kernel is Approved By Microsoft(TM).

iscsi support ? (1)

think_nix (1467471) | more than 4 years ago | (#32282430)

Any Idea if they will repack the 'hotplug' or '_netdev' (like RHEL) in fstab for SP1. This was a major show stopper in SLES 11 when wanting to automount iscsi LUNS at boot time.

Re:iscsi support ? (0)

Anonymous Coward | more than 4 years ago | (#32283336)

I repacked a butt plug.

Suse Linux Enterprise FAIL (1, Insightful)

Anonymous Coward | more than 4 years ago | (#32282572)

This really SUX!
this means upgrading HA Clusters with ocfs2 or any servers with 3rd party SAN,EMC,Powerpath will just FAIL

And of course Novell support will say they have nothing to do with any 3rd party modules "it's your problem now"

If i want to worry about all this things I'll just use free ubuntu and not paid "enterprise" version

just my $0.01

Re:Suse Linux Enterprise FAIL (1)

coolsnowmen (695297) | more than 4 years ago | (#32283022)

Our of curiosity, why will it fail? Isn't OCFS2 part of main line kernel now?

Re:Suse Linux Enterprise FAIL (1)

Billly Gates (198444) | more than 4 years ago | (#32284094)

How is that different from Windows Server service packs?

Re:Suse Linux Enterprise FAIL (1)

twilightzero (244291) | more than 4 years ago | (#32284992)

^^^ +10 sad but true

Re:Suse Linux Enterprise FAIL (1)

simpz (978228) | more than 4 years ago | (#32287850)

It's so different from Windows service pack. MS don't change the API/ABI that applications use. This will. Maybe they think they can keep this problem small but it violates the Enterprise computing no surprises rule.

There's a reason RH is the biggest Linux vendor for corporations. They guarantee not to change the application ABI/API and that is vital if you are running an internal mission critical bespoke app. And suddenly the ground shifts under you.

Maybe won't cause an issue for most or everyone even, but would make me shift uneasily on my seat installing that kernel if I ran SUSE.

Re:Suse Linux Enterprise FAIL (1)

markus o'farkus (98120) | more than 4 years ago | (#32285740)

a) my understanding is that newer versions of powerpath will detect kernel updates and recompile/reinstall themselves. don't know for sure. not a big fan of PP.
b) yeah, how come Novell doesn't support EMC's software? what creeps.
c) ocfs2 will be fine it's in the kernel.
d) best solution: drop powerpath and use native linux mpio and never have to worry about that kind of shit again. the performance gains that powerpath provides are marginal in most scenarios. afaik, it really comes down to "true load balancing" (according to EMC) vs. "round robin". Usually not a an issue when most loads wouldn't saturate one HBA, much less two. For most cases, multipath is really more about failover. So why add the extra layer of support confustion?

.32 is the long term support release (0)

Anonymous Coward | more than 4 years ago | (#32282866)

and .27 support is ending: http://www.h-online.com/open/news/item/Kernel-Log-Long-term-maintenance-for-2-6-32-util-linux-ng-extended-910616.html

I was wondering when the influence would show (-1, Flamebait)

gearloos (816828) | more than 4 years ago | (#32283178)

I have been waiting for some time to see some real proof that the Novel/Microsoft agreement would really start to influence SuSE.. There you go..

Re:I was wondering when the influence would show (1)

JohnnyDoh (1057238) | more than 4 years ago | (#32283296)

Oh Lord! Did someone put on their tinfoil hat too tightly today? I seriously doubt Steve Ballmer pressured Ron Hovesepian into changing kernels...

Backporting? (1)

Billly Gates (198444) | more than 4 years ago | (#32284220)

How can you backport minor updates? Backporting minor revisions and bug fixes is the same as patching ... which is the same as upgrading your kernel.

I can see backporting makes sense when you had kernel 2.4 and 2.6 had neat incompatible features that you wanted to use. I would guess you are making something less stable than just downloading the kernel itself if you have your own custom patches that have limited tested. Why not use what everyone else is ... just a few revisions behind?

 

Re:Backporting? (1)

dag (2586) | more than 4 years ago | (#32285908)

Tell that to the Ubuntu guy that had filesystem problems and required Red Hat's assistance to get it fixed. Ubuntu was impacted, Fedora was impacted, Red Hat's kernel was not. Why ? Because they were not running the latest and greatest. But a kernel that has been selectively patched and improved, by kernel developers that know exactly what they are doing. It can't get better than that...

There are more systems running RHEL and CentOS kernels than there are systems running the latest. Not only because the total number of systems running RHEL/CentOS is much larger than any given distribution, but also because that kernel is the same kernel, while every Ubuntu or Fedora user is using their own kernel (9.10, 10.04, F11, F12) and not updating it at the same time. Whereas RHEL5 has had the same 2.6.18 kernel with the same track-record for the past 3 years.

So if you want to run what everyone else is running, you're better off with a patched and improved CentOS/RHEL 2.6.18 kernel.

Sorry the burst your bubble there...

Re:Backporting? (0)

Anonymous Coward | more than 4 years ago | (#32292764)

umm. nope. you seem to have this backwards.

The RHEL5 kernel did not have that issue simply because it never had the feature in place which had the bug. It would have impacted any _new_ distribution, enterprise or not. What was important was that Red Hat had the right folks to look at it once it got reported and have it fixed as soon as possible.

The lesson to be learnt is, when you pay for it, you get the service, which is why you have RHEL/SLES in place. If you do not pay for it, you get sucky stuff like ubuntu.

More honest than Redhat (1, Informative)

Anonymous Coward | more than 4 years ago | (#32285428)

At least renumbering the kernel is more honest than backporting the fuck out of kernel that's 3 or 4 years old, and leaving the version number the same.

Re:More honest than Redhat (2, Insightful)

dag (2586) | more than 4 years ago | (#32285760)

What does this have to do with honesty ?

Red Hat is backporting the stuff their customers are demanding _and_ what they feel confident to support in a production environment _without_ breaking existing setups. That's the goal.

You don't do that by updating your complete kernel for one or two features you like to have. That would be insane.

Red Hat never promised you that 2.6.18-192.el5 has any resemblance or compatibility with the original vanilla 2.6.18. That would make your kernel ancient and not fit for newer hardware.

The whole "backporting is ugly/dishonest" comes from people that have no clue about Enterprise computing or have hidden agendas. A bit of common sense goes a long way...

Re:More honest than Redhat (1)

bill_mcgonigle (4333) | more than 4 years ago | (#32286358)

Red Hat never promised you that 2.6.18-192.el5 has any resemblance or compatibility with the original vanilla 2.6.18. That would make your kernel ancient and not fit for newer hardware.

Well, you get ABI compatibility, but the AC's poor little mind apparently can't handle the idea of branches.

Oh, hey, thanks for the Drupal book review, I was just thinking about figuring that out myself, this will help.

Re:More honest than Redhat (1)

shutdown -p now (807394) | more than 4 years ago | (#32286686)

The problem with backporting is that it introduces a lot of hidden potential for a major mess, compared to a straightforward version upgrade. I can trust RedHat guys to do backports right, because they have some of the most prominent Linux kernel hackers on the payroll. But this is an exception rather than rule. I don't know much about SUSE resources in that department, but I sure as hell don't want Ubuntu to backport or patch upstream stuff - more often than not, these kinds of things is precisely why Ubuntu is so broken lately.

Re:More honest than Redhat (1)

palegray.net (1195047) | more than 4 years ago | (#32287018)

If it helps any, Novell has been around for a very long time, and does employ lots of very smart people. Considering the fact that they've based their modern business almost exclusively on Linux, I have a high degree of confidence in their competence. Ubuntu (Canonical) is another matter entirely, depending on how you define competence of course...

Re:More honest than Redhat (1)

neurovish (315867) | more than 4 years ago | (#32292972)

If it helps any, Novell has been around for a very long time, and does employ lots of very smart people. Considering the fact that they've based their modern business almost exclusively on Linux, I have a high degree of confidence in their competence. Ubuntu (Canonical) is another matter entirely, depending on how you define competence of course...

Correct, they've been losing money almost as long as Red Hat has been a public corporation! After firsthand experience working with Novell, I have absolutely no confidence in their competence. They do employ some very smart people (I'm not sure about "a lot"..I've only met two or three I would consider smart), but I have no idea what they're doing. It does not seem like they work on creating any of Novell's products. Novell needs to go and pimp themselves out to the highest bidder while the company has still has any residual value.

Re:More honest than Redhat (1)

bill_mcgonigle (4333) | more than 4 years ago | (#32288166)

Excellent point. It feels like there's an obvious solution to the problem that I'm not seeing.

Re:More honest than Redhat (1)

Junta (36770) | more than 4 years ago | (#32287140)

'ABI' compatibility in the kernel is not preserved. The kernel header files changed so that not only did drivers need recompile, they needed recoding.

Re:More honest than Redhat (1)

bill_mcgonigle (4333) | more than 4 years ago | (#32287200)

'ABI' compatibility in the kernel is not preserved. The kernel header files changed so that not only did drivers need recompile, they needed recoding.

Among RHEL major-number releases? Sorry I lost the context.

Re:More honest than Redhat (1)

simpz (978228) | more than 4 years ago | (#32287784)

On RHEL only the application API/ABI is guaranteed between kernel versions. You still have to rebuild 3rd party drivers (e.g NVIDIA) between on any kernel updates. But the guaranteed application API/ABI is what businesses really pay for with RHEL i.e no surprises.

  Not sure how Novell hopes to achieve this now.

Re:More honest than Redhat (0)

Anonymous Coward | more than 4 years ago | (#32292538)

And it is very rare for kernel/user API/ABI to be changed. So applications just work.

Re:More honest than Redhat (1)

Junta (36770) | more than 4 years ago | (#32300222)

I don't think the kernel factors into the application ABI/API overmuch. I have binaries from very old kernels with no issue.

Re:More honest than Redhat (1)

dag (2586) | more than 4 years ago | (#32366700)

Not true, there is a whitelist kABI for interfaces that are guaranteed to not change. If I recall correctly, even the nvidia driver worked fine going from a RHEL5.4 kernel to a RHEL5.5 kernel. So it's not guaranteed that all drivers keep on working on any 2.6.18 kernel, but the large majority simply do.

Visit the ELRepo project page (http://elrepo.org/) or read the following document to learn how it works:

http://dup.et.redhat.com/presentations/DriverUpdateProgramTechnical.pdf

Re:More honest than Redhat (1)

Junta (36770) | more than 4 years ago | (#32287132)

I have to agree with the sentiment of the above, even if 'honesty' isn't the right word. They backport stuff from 2.6.32 to 2.6.18. They break the kernel module interfaces (drivers have had to change their source code to follow the 5.x series). The resultant thing tends to exhibit some of the worse of both worlds.

Re:More honest than Redhat (1)

dag (2586) | more than 4 years ago | (#32290588)

As one of the members of the ELRepo project (http://elrepo.org/), I would like you to take a look at the collection of drivers (kernel modules) that the project has backported to the RHEL5 2.6.18 kernel. In total more than 400 drivers have been ported and a large majority of these drivers work for every 2.6.18 kernel that was released (from 2.6.18-8.el5 until 2.6.18-199.el5), thanks to the kABI whitelist. Including exotic stuff like nvidia or video4linux.

So I fail to see the worse of both worlds. But then again, I may be biased of actually using, deploying and working with those kernels.

Re:More honest than Redhat (1)

Junta (36770) | more than 4 years ago | (#32300314)

Are you saying that a kernel module written against 2.6.18-8.el5 without any knowledge of what will happen up to 199 would compile without issue, because I call BS. I have dealt with RHEL5.2->5.3 and other such transitions and had to get new vendor source code as some include files changed in the kernel. Could that new source code compile against the old tree, sure, but it's easy to make the code have the right #ifdefs after the fact.

I'm not saying ignoring the new drivers is good, but 'pretending' that it even resembles '2.6.18' with all the backport is just that, pretending. I could understand if RH didn't change subsystem-wide aspects and managed to get drivers to work, but they do change certain things. I wouldn't begrudge them saying the nature of linux forces jumps in the version number to reasonably provide value, but the '2.6.18' is misleading.

Re:More honest than Redhat (1)

dag (2586) | more than 4 years ago | (#32366606)

You could have saved yourself the embarrassment if you would have visited the ELRepo website (http://elrepo.org/) and tested it for yourself, or you could have googled for kABI or kABI-tracking modules. (Welcome in 2010 !)

The large majority of the drivers compiled against one kernel do indeed work for *all* 2.6.18 kernels. Only a few of them (those that do not use what's inside the kABI whitelist) have to be recompiled against a new major release kernel if an interface did change.

http://dup.et.redhat.com/presentations/DriverUpdateProgramTechnical.pdf

The kABI whitelist is an evolving list based on feedback from vendors, customers and the community.

new kernel version? (1)

marafa (745042) | more than 4 years ago | (#32289856)

did novell lose their kernel guru or something?

Debian did this with 4.0 'Etch' (1)

thegoldenear (323630) | more than 4 years ago | (#32290310)

This is what Debian did with 'Etch'n'Half', in the 4.0 'Etch' stable distribution, going from 2.6.18 to 2.6.24, which was alarming because, in their words:

        * "Debian does not guarantee that all hardware that is supported by the default etch 2.6.18 kernel is also supported by the 2.6.24 kernel, nor that all software included in etch will work correctly with the newer kernel.
        * Migrating from the 2.6.18 etch kernel to the 2.6.24 "etch-and-a-half" kernel will work in many cases, but is not guaranteed to succeed. Upgrades from both the 2.6.18 and 2.6.24 kernels to the kernel provided by the next stable release ("lenny") will be supported.
        * Not all features of the etch 2.6.18 kernel are available in the 2.6.24 images, this includes the Xen and linux virtual server flavors.
        * Out-of-tree kernel module source packages that were provided in etch are not guaranteed to function properly with the 2.6.24 kernel.
        * The current "etch-and-a-half" installation images based on Debian Installer Lenny RC1 use a newer kernel (2.6.26) than the version that was included in the "etch-and-a-half" release and is installed for the target system (2.6.24). In some cases this can mean that hardware which is supported during the installation does not work after the reboot into the installed system because support for it was added after the 2.6.24 version."
http://www.debian.org/releases/etch/etchnhalf [debian.org]

Pete Boyd

Re:Debian did this with 4.0 'Etch' (1)

JonJ (907502) | more than 4 years ago | (#32290526)

This is what Debian did with 'Etch'n'Half', in the 4.0 'Etch' stable distribution, going from 2.6.18 to 2.6.24, which was alarming because, in their words:

Not really, those packages were completely optional. I'm guessing the first question when you try to get support from Novell is "Have you tried upgrading to the latest version?" So it's not the same, it's actually a rather poor comparison.

Finally, the horrror ends! (2, Insightful)

internet-redstar (552612) | more than 4 years ago | (#32290674)

Old Linux guys like me remember the time when they introduced this in 'enterprise kernels'. At that time it made sence, because in the 2.4 series there were good and... well _bad_ kernels. Some may argue that that still was the case in the early 2.6 tree. But that has been a long time in the past...

The current situation is that the backporting policy basically sucks _bigtime_.
It means that new hardware isn't out of the box supported by the 'enterprise distros' and that installing ubuntu with a new kernel is a no-brainer. It also means that - especially in the case of Red Hat, the kernel is so heavily patched, that it can lead to stability problems and introduces 'unusual problems' as opposed to the vanilla kernel.

Backporting things for an old kernel and overly patching the vanilla kernel is basically saying: 'we know it better than the kernel developers'. And, sorry, that simply isn't true!

As someone being heavily involved in Linux Enterprise support since 1998, and thus shaping it too, I can only hope that this is a sign of better things to come and an abandonment of the outdated, stupid and un-enterprise policy which only makes Linux look bad.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>