Novell Changes Enterprise Linux Kernel Mid-Stream

← Back to Stories (view on slashdot.org)

Novell Changes Enterprise Linux Kernel Mid-Stream

Posted by timothy on Thursday May 20, 2010 @05:38AM from the this-will-dominate-the-evening-news dept.

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.'"

96 comments

Min score:

Reason:

Sort:

Why not just call it SuSE 12? by Lurching · 2010-05-20 05:42 · Score: 1

That would be more consistant.
1. Re:Why not just call it SuSE 12? by Anonymous Coward · 2010-05-20 05:50 · Score: 0
  
  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.
2. Re:Why not just call it SuSE 12? by Anonymous Coward · 2010-05-20 06:14 · Score: 1, Informative
  
  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.
3. Re:Why not just call it SuSE 12? by Anonymous Coward · 2010-05-20 07:15 · Score: 0
  
  GI?
4. Re:Why not just call it SuSE 12? by colourmyeyes · 2010-05-20 15:38 · Score: 1
  
  Gastrointestinal.
  
  --
  My grandmother used anecdotal evidence all the time, and she lived to be 120 years old.
Big jump by arth1 · 2010-05-20 05:43 · Score: 1

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?)
1. Re:Big jump by cynyr · 2010-05-20 06:03 · Score: 1
  
  why are you updating that package on production servers then? maybe the test/dev box.
  
  --
  All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
2. Re:Big jump by think_nix · 2010-05-20 06:09 · Score: 1
  
  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.
3. Re:Big jump by neurovish · 2010-05-20 06:30 · Score: 1
  
  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?
4. Re:Big jump by think_nix · 2010-05-20 06:43 · Score: 1
  
  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.
5. Re:Big jump by spun · 2010-05-20 07:33 · Score: 1
  
  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.
  
  --
  - None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
6. Re:Big jump by think_nix · 2010-05-20 07:54 · Score: 1
  
  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.
7. Re:Big jump by twilightzero · 2010-05-20 08:38 · Score: 2, Interesting
  
  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 start on page 18
  
  --
  
  "Christ what a design! I could eat a handful of iron filings and PUKE a better emergency pump than that!"
8. Re:Big jump by Vairon · 2010-05-20 08:52 · Score: 1
  
  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~
  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
  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.
9. Re:Big jump by markus+o'farkus · 2010-05-20 09:08 · Score: 1
  
  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.
10. Re:Big jump by spun · 2010-05-20 09:11 · Score: 1
  
  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.
  
  --
  - None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
11. Re:Big jump by spun · 2010-05-20 09:17 · Score: 1
  
  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.
  
  --
  - None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
12. Re:Big jump by spun · 2010-05-20 09:31 · Score: 1
  
  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.
  
  --
  - None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
13. Re:Big jump by bill_mcgonigle · 2010-05-20 10:33 · Score: 1
  
  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.
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
14. Re:Big jump by bjourne · 2010-05-20 10:58 · Score: 1
  
  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.
  
  --
  Football Odds
15. Re:Big jump by jschrod · 2010-05-20 11:46 · Score: 1
  
  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.
  
  --
  Joachim
  
  People don't write Manifestos any more -- what's going on in this world? [Frank Zappa]
16. Re:Big jump by bill_mcgonigle · 2010-05-20 11:48 · Score: 1
  
  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).
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
17. Re:Big jump by think_nix · 2010-05-20 12:46 · Score: 1
  
  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.
18. Re:Big jump by spun · 2010-05-21 02:15 · Score: 1
  
  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.
  
  --
  - None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
19. Re:Big jump by spun · 2010-05-21 02:17 · Score: 1
  
  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.
  
  --
  - None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
20. Re:Big jump by jschrod · 2010-05-21 02:26 · Score: 1
  
  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.
  
  --
  Joachim
  
  People don't write Manifestos any more -- what's going on in this world? [Frank Zappa]
21. Re:Big jump by spun · 2010-05-21 02:46 · Score: 1
  
  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 :(
  
  --
  - None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Stability versus ABI by Josh+Triplett · 2010-05-20 05:47 · Score: 2, Funny

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.
1. Re:Stability versus ABI by cynyr · 2010-05-20 06:05 · Score: 4, Informative
  
  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.
  
  --
  All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
2. Re:Stability versus ABI by Anonymous Coward · 2010-05-20 06:24 · Score: 1, Insightful
  
  Kernel developers should use and support a stable ABI. This has been said many times by everyone else.
3. Re:Stability versus ABI by Anonymous Coward · 2010-05-20 06:58 · Score: 0
  
  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.
4. Re:Stability versus ABI by Sycraft-fu · 2010-05-20 07:26 · Score: 1, Insightful
  
  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.
5. Re:Stability versus ABI by Kjella · 2010-05-20 08:39 · Score: 1
  
  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.
  
  --
  Live today, because you never know what tomorrow brings
6. Re:Stability versus ABI by simpz · 2010-05-20 12:55 · Score: 1
  
  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.
7. Re:Stability versus ABI by Anonymous Coward · 2010-05-20 14:27 · Score: 0
  
  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.
8. Re:Stability versus ABI by Anonymous Coward · 2010-05-20 14:58 · Score: 0
  
  DKMS
9. Re:Stability versus ABI by xouumalperxe · 2010-05-21 03:11 · Score: 1
  
  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.
outrageous! by nomadic · 2010-05-20 05:48 · Score: 5, Funny

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.
1. Re:outrageous! by Ethanol-fueled · 2010-05-20 06:05 · Score: 3, Insightful
  
  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.
2. Re:outrageous! by quantumplacet · 2010-05-20 06:25 · Score: 1, Flamebait
  
  https://wiki.ubuntu.com/Releases
  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.
3. Re:outrageous! by Anonymous Coward · 2010-05-20 07:49 · Score: 2, Interesting
  
  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.
4. Re:outrageous! by quantumplacet · 2010-05-20 08:39 · Score: 0, Flamebait
  
  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.
5. Re:outrageous! by nomadic · 2010-05-20 09:37 · Score: 4, Funny
  
  I think the animal adjectives should have to reflect the actual Ubuntu release, like Unstable Urchin, or Dependency-Breaking Duck.
6. Re:outrageous! by Anonymous Coward · 2010-05-20 09:50 · Score: 1, Funny
  
  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.
7. Re:outrageous! by AdamTheBastard · 2010-05-20 11:03 · Score: 1
  
  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.
8. Re:outrageous! by Curmudgeonlyoldbloke · 2010-05-20 12:12 · Score: 1
  
  So cartoon characters is an improvement is it?
  Hell, I use Debian but would much prefer it if they just stuck to numbers.
9. Re:outrageous! by standbypowerguy · 2010-05-20 13:57 · Score: 1
  
  ROFLMAO! It's times like these I wish I had mod points... Mod parent up!
  
  --
  This isn't the sig you're looking for... Move along.
10. Re:outrageous! by colourmyeyes · 2010-05-20 15:51 · Score: 1
  
  $ cat /etc/slackware-version
  
  --
  My grandmother used anecdotal evidence all the time, and she lived to be 120 years old.
Good idea? Bad Idea? by bernywork · 2010-05-20 05:49 · Score: 5, Insightful

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

--
Curiosity was framed; ignorance killed the cat. -- Author unknown
1. Re:Good idea? Bad Idea? by cynyr · 2010-05-20 06:01 · Score: 0, Troll
  
  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.
  
  --
  All of the above was encrypted with a Quad ROT-13 method. Unauthorized decryption is in violation of the DMCA.
2. Re:Good idea? Bad Idea? by talcite · 2010-05-20 07:38 · Score: 2, Interesting
  
  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.
3. Re:Good idea? Bad Idea? by Engeekneer · 2010-05-20 19:39 · Score: 1
  
  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.
4. Re:Good idea? Bad Idea? by bernywork · 2010-05-20 23:42 · Score: 1
  
  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
  
  --
  Curiosity was framed; ignorance killed the cat. -- Author unknown
Funny, they couldn't figure out the old system by H1pp13 · 2010-05-20 05:50 · Score: 2, Interesting

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.
1. Re:Funny, they couldn't figure out the old system by neurovish · 2010-05-20 06:42 · Score: 1
  
  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!
2. Re:Funny, they couldn't figure out the old system by Anonymous Coward · 2010-05-20 09:08 · Score: 0
  
  http://en.opensuse.org/SUSE_Package_Conventions/RPM_Style#1.8._Version_Tag
  http://en.opensuse.org/SUSE_Package_Conventions/RPM_Style#1.9._Release_Tag
Not suprising by Anonymous Coward · 2010-05-20 05:51 · Score: 0, Troll

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 by Anonymous Coward · 2010-05-20 05:56 · Score: 0

In licensing terms, what is different about the Novell Kernel as compared to the Linux kernel?
1. Re:Novell Linux kernel by $RANDOMLUSER · 2010-05-20 06:03 · Score: 0, Troll
  
  The Novell kernel is Approved By Microsoft(TM).
  
  --
  No folly is more costly than the folly of intolerant idealism. - Winston Churchill
iscsi support ? by think_nix · 2010-05-20 05:57 · Score: 1

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.
1. Re:iscsi support ? by Anonymous Coward · 2010-05-20 07:00 · Score: 0
  
  I repacked a butt plug.
Suse Linux Enterprise FAIL by Anonymous Coward · 2010-05-20 06:06 · Score: 1, Insightful

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
1. Re:Suse Linux Enterprise FAIL by coolsnowmen · 2010-05-20 06:37 · Score: 1
  
  Our of curiosity, why will it fail? Isn't OCFS2 part of main line kernel now?
2. Re:Suse Linux Enterprise FAIL by Billly+Gates · 2010-05-20 07:48 · Score: 1
  
  How is that different from Windows Server service packs?
  
  --
  http://saveie6.com/
3. Re:Suse Linux Enterprise FAIL by twilightzero · 2010-05-20 08:41 · Score: 1
  
  ^^^ +10 sad but true
  
  --
  
  "Christ what a design! I could eat a handful of iron filings and PUKE a better emergency pump than that!"
4. Re:Suse Linux Enterprise FAIL by markus+o'farkus · 2010-05-20 09:29 · Score: 1
  
  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?
5. Re:Suse Linux Enterprise FAIL by simpz · 2010-05-20 12:47 · Score: 1
  
  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.
.32 is the long term support release by Anonymous Coward · 2010-05-20 06:26 · Score: 0

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
Re:I was wondering when the influence would show by JohnnyDoh · 2010-05-20 06:57 · Score: 0

Oh Lord! Did someone put on their tinfoil hat too tightly today? I seriously doubt Steve Ballmer pressured Ron Hovesepian into changing kernels...
Backporting? by Billly+Gates · 2010-05-20 07:55 · Score: 1

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?

--
http://saveie6.com/
1. Re:Backporting? by dag · 2010-05-20 09:41 · Score: 1
  
  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...
2. Re:Backporting? by Anonymous Coward · 2010-05-21 02:04 · Score: 0
  
  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 by Anonymous Coward · 2010-05-20 09:10 · Score: 1, Informative

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.
1. Re:More honest than Redhat by dag · 2010-05-20 09:31 · Score: 2, Insightful
  
  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...
2. Re:More honest than Redhat by bill_mcgonigle · 2010-05-20 10:19 · Score: 1
  
  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.
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
3. Re:More honest than Redhat by shutdown+-p+now · 2010-05-20 10:47 · Score: 1
  
  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.
4. Re:More honest than Redhat by palegray.net · 2010-05-20 11:17 · Score: 1
  
  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...
  
  --
  512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
5. Re:More honest than Redhat by Junta · 2010-05-20 11:29 · Score: 1
  
  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.
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
6. Re:More honest than Redhat by Junta · 2010-05-20 11:30 · Score: 1
  
  'ABI' compatibility in the kernel is not preserved. The kernel header files changed so that not only did drivers need recompile, they needed recoding.
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
7. Re:More honest than Redhat by bill_mcgonigle · 2010-05-20 11:37 · Score: 1
  
  '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.
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
8. Re:More honest than Redhat by simpz · 2010-05-20 12:38 · Score: 1
  
  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.
9. Re:More honest than Redhat by bill_mcgonigle · 2010-05-20 13:37 · Score: 1
  
  Excellent point. It feels like there's an obvious solution to the problem that I'm not seeing.
  
  --
  My God, it's Full of Source!
  OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
10. Re:More honest than Redhat by dag · 2010-05-20 20:49 · Score: 1
  
  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.
11. Re:More honest than Redhat by Anonymous Coward · 2010-05-21 01:50 · Score: 0
  
  And it is very rare for kernel/user API/ABI to be changed. So applications just work.
12. Re:More honest than Redhat by neurovish · 2010-05-21 02:20 · Score: 1
  
  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.
13. Re:More honest than Redhat by Junta · 2010-05-21 10:40 · Score: 1
  
  I don't think the kernel factors into the application ABI/API overmuch. I have binaries from very old kernels with no issue.
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
14. Re:More honest than Redhat by Junta · 2010-05-21 10:48 · Score: 1
  
  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.
  
  --
  XML is like violence. If it doesn't solve the problem, use more.
15. Re:More honest than Redhat by dag · 2010-05-27 07:20 · Score: 1
  
  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.
16. Re:More honest than Redhat by dag · 2010-05-27 07:24 · Score: 1
  
  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
new kernel version? by marafa · 2010-05-20 18:31 · Score: 0

did novell lose their kernel guru or something?

--
_ In Egypt Networks: Network Solutions with a Twist
Debian did this with 4.0 'Etch' by thegoldenear · 2010-05-20 19:59 · Score: 1

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
Pete Boyd
1. Re:Debian did this with 4.0 'Etch' by JonJ · 2010-05-20 20:37 · Score: 1
  
  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.
  
  --
  -- Linux user #369862
Finally, the horrror ends! by internet-redstar · 2010-05-20 21:08 · Score: 2, Insightful

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.