Linux Kernel 2.6.32 LTS Reaches End of Life In February 2016 (softpedia.com) 116
An anonymous reader writes: The oldest long-term supported Linux kernel branch finally reaches end of life next month, but before going into the deepest darkest corners of the Internet, it just dropped one more maintenance release, Linux kernel 2.6.32.70 LTS. Willy Tarreau dropped the news about the release of Linux kernel 2.6.32.70 LTS on January 29, 2016, informing all us that this will most likely be the last maintenance release in the series, as starting with February 2016 it will no longer be supported with security patches and bugfixes. Linux 2.6 first came out in December, 2003, and 2.6.16 (the first long-term release) in March 2006.
RHEL6 (Score:2)
What happens to RHEL6?
Re:RHEL6 (Score:4, Insightful)
Red Hat will back port fixes, just like they do with many, many packages.
Re:RHEL6 (Score:5, Informative)
Re: (Score:2)
Much to my chagrin when I have to do out-of-tree stuff that seeks kernel-devel as '2.6.32' and says 'oh, then I need to define stuff that wasn't defined in 2.6.32' only to break the compile because RHEL backported all sorts of stuff, and still call it '2.6.32'. This has always bugged me about RHEL, they end up with something that doesn't map to kernel.org version at *all*, but the version still suggests otherwise.
SuSE stopped that stuff and actually upgraded the kernel when they felt the features were read
Re:RHEL6 (Score:5, Informative)
What happens to RHEL6?
EL6 will still be supported by Red Hat and Scientific Linux for many years to come.
There are alternatives, like Gentoo, but for inexplicable reasons, Gentoo has dropped support for kernel 3.2, which is currently the kernel with the longest remaining support (until May 2018).
4.4, the second most LTS, is too bleeding edge for many. If the goal is to keep a system with max uptime, but still get critical kernel fixes if and only if needed, the best bet might be to stay at EL6 for now.
Re: (Score:2)
Gentoo is a bleeding edge, rolling release distribution. They do not keep old versions of any package around.
Re: (Score:2)
CentOS tracks RHEL completely. For as long as Red Hat supports RHEL6, CentOS 6 will be updated. (New Red Hat-maintained versions of 2.6.18 still show up in CentOS 5 updates, even.)
Re: (Score:2)
As far as I know, they will. However, they do not provide long term support themselves for more than a couple of years, and just mirror upstreams.
ScientificLinux does, but part of that is likely because they also have additional packages in addition to the RHEL base, while CentOS does not have that. All they have to support is logo changes and similar, which can be expected to be long term stable.
Re: (Score:2)
I thought making throw-away posts about faggots was for... well, you know.
Re: (Score:2)
It's open source. That's the great thing. RH can take the code and maintain it themselves if the community doesn't do any thing with it until they retire RHEL6
I'm not sure why people still don't get that the largest part of this so-called "community" is made up of paid Red Hat employees.
Linux isn't really being maintained by a bunch of guys doing it for free out of the goodness of their hearts in their spare time.
Re:RHEL6 (Score:4, Interesting)
Please no. The swallowing of stderr makes it very difficult to troubleshoot startup problems. Just today I had a simple problem that was very hard to find because of systemd:
# systemctl start mongod ; echo $?
0
# journalctl -u mongod
Jan 30 20:58:29 storage3.maui.ascentis-prod.com systemd[1]: Starting SYSV: Mongo is a scalable, document-oriented database....
Jan 30 20:58:29 storage3.maui.ascentis-prod.com runuser[5767]: pam_unix(runuser:session): session opened for user mongod by (uid=0
Jan 30 20:58:29 storage3.maui.ascentis-prod.com mongod[5760]: Starting mongod: [FAILED]
Jan 30 20:58:29 storage3.maui.ascentis-prod.com systemd[1]: mongod.service: control process exited, code=exited status=1
Jan 30 20:58:29 storage3.maui.ascentis-prod.com systemd[1]: Failed to start SYSV: Mongo is a scalable, document-oriented database.
Jan 30 20:58:29 storage3.maui.ascentis-prod.com systemd[1]: Unit mongod.service entered failed state.
Jan 30 20:58:29 storage3.maui.ascentis-prod.com systemd[1]: mongod.service failed.
Notice starting it exited with no error, and there's no clue as to what happened in the journal!
Re: RHEL6 (Score:1)
No. Exit statuses should still be reported for hysterical raisins.
Re: RHEL6 (Score:1, Informative)
Did you have a /var/lib/mongo/mongo.lock file? If so, the problem was your own fault.
Re: RHEL6 (Score:5, Informative)
Did you have a /var/lib/mongo/mongo.lock file? If so, the problem was your own fault.
You are correct. That was the problem, but I still don't think systemd should have exited with a 0 (no error) or swallowed the log message that clearly stated the problem. When I ran "sudo mongod mongod -f /etc/mongod.conf" the problem was clearly output to the console. After deleting the lock file, systemd was able to start MongoDB.
I've seen this problem on dozens of servers since we have nearly 300 MongoDB instances. systemd makes life much harder.
WTF moderators (Score:1)
This guy posts a helpful technical response and gets voted down. I too have run into this same bug.
Re: RHEL6 (Score:5, Insightful)
9 out of 10 times when something goes wrong in your system it's your own damn fault. That's what logs are for, to inform you where you made the mistake.
By your logic, the only output we should get is a segfault to show that the program barfed, for only then it's the programmer's fault and for everything else, well, sucks to be you, why did you make that mistake?
Re: (Score:2, Informative)
or swallowed the log message that clearly stated the problem
Sounds like someone hasn't setup systemd to their liking. In it's most verbose form journald will capture more and log more than any previous system including saving outputs from the console that previously were lost and capturing messages before syslog starts.
But you need to read the manual first, and if you don't like the defaults complain to the maintainer of your distribution, and has nothing to do with systemd itself which will only swallow logs if you tell it to.
Re: RHEL6 (Score:4, Insightful)
or swallowed the log message that clearly stated the problem
Sounds like someone hasn't setup systemd to their liking. In it's most verbose form journald will capture more and log more than any previous system including saving outputs from the console that previously were lost and capturing messages before syslog starts.
But you need to read the manual first, and if you don't like the defaults complain to the maintainer of your distribution, and has nothing to do with systemd itself which will only swallow logs if you tell it to.
The DEFAULT drops errors logged from the historical source errors are reported to.
That's FUCKING STUPID.
It's like putting a land mine in a dog owner's yard, then telling him he should have had a bunch of military engineers sweep his yard for mines before his dog got blown to bits.
NO YOU FUCKING MORON YOU DON'T PLACE THE MINES IN THE FIRST FUCKING PLACE!!!!!
Re: (Score:2)
Sounds like someone hasn't set up systemd to their liking.
Blaming the victim. Unless the purpose of systemd is to elevate system configuration to an art form whose purpose is aesthetics and critique, then that is a problem with systemd.
You know, like every critic of systemd has been saying all along.
Re: (Score:1)
Yeah I understand what you mean. Just the other day I opened up my linux box and was upset to realise that I got a file not found error message when I typed ipconfig /all. I mean we should expect all software to work the same way shouldn't we? Anyway once I found out that I was typing a windows command I finished setting up nginx and got another error that it wouldn't read /etc/apache2/apache2.conf I mean what the hell, it's just a http server right? Worse still it would seem that this server has different
Re: RHEL6 (Score:4, Interesting)
Re: (Score:1)
Unfortunately, in an open source world, documentation can often be a rarity, and good documentation even rarer, and in this area systemd is significantly worse than average.
Re: (Score:2)
systemd is significantly worse than average.
This problem is literally one of not removing the # on a line in system.conf. It is also well described in the man pages for system.conf. It's also well described in the RedHat manual. Okay that's the first 3 google results done, you can go look up some more if you think the documentation is so horrible.
The only bad documentation for systemd is the API documentation. End user configuration is quite adequately described not just in its own man pages, but also in documentation from various distributions.
Re: RHEL6 (Score:2)
Unless someone explicitly did daemon > /var/log/mydaemon.log, a standard log and syslog would just log everything you sent to it by default and the daemon itself could specify where and how it got sent. Journald not only needs the app but also needs itself instructions on its logging level and verbosity in very arcane journald style specifications. If I'm doing a one-off change, I don't even bother with systemd. It takes me 30-40 lines and 5 file changes to set up a simple script that runs every so often
Re: (Score:2)
The issue is that every configuration issue is going to be 'your own fault'. However the point of diagnostic data is to identify when something goes wrong and why. The complaint here is that systemctl exited with rc 0 (so a script to do something to the service wouldn't know there was a problem) and that log data that traditionally would have said in clear terms what went wrong is discarded.
This is like saying it is ok for a compiler to just say 'compile error' and return success because any syntax errors
Re: (Score:2)
Re: (Score:2)
https://www.youtube.com/watch?v=O8cDfnQD0ws
"Mongo only pawn in game of life."
Re: RHEL6 (Score:1)
systemd correctly handles exit statuses even though they're old cruft that should be removed. Your startup script is broken.
Re: (Score:2, Interesting)
Because it (still) points out there is an error? Did exit codes suddenly become deprecated?
Re: (Score:1)
Actually, I'm just shocked that someone got the signal to noise ratio pointed in the right direction. Most people say that exactly backwards. "I like that place. The signal to noise ratio is really low!" Well, they are not necessarily wrong. I'm just not sure why one would prefer an environment where separation of noise and signal is difficult. It is really kind of odd how frequently someone posts it backwards.
NOTE TO MODERATORS (Score:3, Insightful)
I agree, it doesn't really provide useful information on how to track down the issue. Dealing with syslog was a pain in the ass in some ways to track down problems associated with a particular daemon, but I'm not sure systemd solves the issue.
That said, I see a number of AC posts criticizing you for your views on systemd. It seems every night recently, a troll posts a bunch of AC comments in response to an early post, pretending to have a conversation with itself but contributing nothing of substance. Last
Re: (Score:3)
A *troll* would make us laugh or piss us off. The AC poster you're referring to is simply a waste of protoplasm wasting electrons in its too-plentiful spare time.
Re:RHEL6 (Score:5, Funny)
systemctl start mongod
Well there's your problem, you've mangled your languages. If you'd used:
systemctl start mondieu
you'd have got the response you were expecting:
# Bonjour, je m'appelle Linus.
Re: (Score:1)
You're still mangling languages, it is:
$ contrôledusystème démarre mondieu
Re: (Score:2, Informative)
Notice starting it exited with no error, and there's no clue as to what happened in the journal!
Yeah I notice that. Which means either:
a) you didn't setup systemd-system.conf to your liking.
b) mongodb isn't outputting the error.
c) you couldn't be stuffed reading the log file for mongo (not everything logs to syslog or the journal)
d) you assume systemd is magical and the computer will run itself despite configuration problems or coding errors in the software.
e) all of the above.
Re: RHEL6 (Score:2)
Set Type=forking in your service unit (the default is simple, which expects inetd-style services).
Re: (Score:2)
systemd does not swallow stderr, looking at the default mongodb unit file I noticed that some one with a brain damage put this line in there "ExecStart=/usr/bin/mongod --quiet --config /etc/mongodb.conf". See the --quiet flag there? It tells mongodb to not produce any stderr at all, hence why systemd also wouldn't capture it, it cannot capture that which isn't produced.
Re: (Score:2)
Unsure, but it runs Tetris fine.
Oh, wow! (Score:3)
Re: (Score:1)
LMAO
Re: (Score:2)
Oh, yeah. As long as users refuse to upgrade *cough*digital cinema*cough*, there'll be jaw-dropping amongst the community.
Still using 2.6.13 under Fedora. Apparently we users (projectionists) aren't to be trusted with our own equipment, so no root access, and we get an upgrade every three years or so, whenever we scream loud enough and promise to pay for it.
To their credit, the "upgrade" includes a calibration of sound+vision, so there's that.
Still on 2.6.32 because of Distro (Score:3)
I still run an old Ubuntu LTS install with Linux 2.6.32, but that is mostly because so that I would not have to run a Ubuntu version with that abomination called "Unity" or Gnome 3. I could not see that Ubuntu had offered any upgrade path to another LTS release that would not force any of that crap upon me. I also did not want to get a system that was a mix of installs from different sources.
My old Ubuntu has served me well for this time. Time to look around for some other distribution then... Mint?
BTW. At work I installed CentOS 6 on a brand new machine, this Thursday. I installed CentOS 7 first but gave it up because of Gnome 3.
Re: (Score:1)
I recommend just installing XFCE on Ubuntu, but Mint is also an option if you're a Gnome2 fan.
Re:Still on 2.6.32 because of Distro (Score:4, Interesting)
Re: (Score:2)
I'm running ubuntu 14.04 with fvwm. Unity is the default but it's easy to switch. There's no need to run an a ancient system. I'll a almost certainly upgrade to 16.04 when the time comes.
Re:Still on 2.6.32 because of Distro (Score:5, Informative)
I still run an old Ubuntu LTS install with Linux 2.6.32, but that is mostly because so that I would not have to run a Ubuntu version with that abomination called "Unity" or Gnome 3. I could not see that Ubuntu had offered any upgrade path to another LTS release that would not force any of that crap upon me.
My mom runs 10.04 and is a long way away, so I tested in a VM
do-release-upgrade
Which brought the VM to 12.04, then I ran it again, bringing the VM to 14.04.
Then something like
sudo apt-get install mate-desktop
And it worked. I did the entire process multiple times to be sure, and documented it on a web site somewhere.
One issue was in trying to remove Unity via sudo apt-get remove unity.
In one instance it caused an issue, in another it worked. Might have been a mistake I made.
But there is an update path available.
also did not want to get a system that was a mix of installs from different sources.
I did have to add the Mate repo if I recall, but they're pretty trust-worthy; I wouldn't consider it problematic.
Worth a try!
Re: (Score:2)
The lack of updates for upstream 2.6.32 is the least of your worries for running Lucid.
One, unless you were compiling your own kernel, the efforts after April of last year upstream had no bearing on your distro, since they weren't bothering to pull it in anyway.
For another, the kernel is but one of a huge chunk of unmaintained code in a distro that gave up it's last bit of support April last year.
If you want new but familiar, choose a MATE environment. It carries on the traditional experience the best. Yo
Re: (Score:3)
If you're not in a hurry / don't really need to care you may wait for Ubuntu 16.04 (Ubuntu Mate) or Mint 18 Mate.
But will it still run on a 80386? (Score:2)
Re: (Score:1)
By that metric, Linux is indeed a failure.
Re: (Score:2)
2.6.32.70 should. 80386 support was dropped in 3.5.y and further.
Please note that no mainstream distro has supported the 386 in the past couple decades. You'll have to be building all your own stuff to get it working.
What's so special... (Score:2)
Re: (Score:2)
2.6.39 was actually the one that directly preceded 3.0 ;)
Nothing particularly special about 2.6.32 compared to the others, but it just happened to be one release in which all the major enterprise distributions landed on for one release cycle (Debian 6, RHEL 6, SLES 11, ...). That fact alone just kind of drove to keeping it maintained officially, and everyone on those distributions could stay happy with new upstream kernels of that series without breaking any sort of compatibility on their systems (eg, any k
Re: (Score:2)
In fact my own usage in my projects as well as at my company has justified to take it over till last summer. And since Moritz and Ben from the debian LTS team have done an incredible job at feeding me with security backports for free, when Ben told me that debian 6 would be maintained till february, I found it the least I could do to pursue its maintenance for a few extra months to return the favor. So the fact that it's been used by debian has indeed justified 6 more months, which is nice already.
Acute obs
Re:Hey!?!?! (Score:5, Insightful)
Dice no longer own Slashdot [slashdot.org].
Here, let me get you a paper towel or something for you to clean yourself up with--you look a bit foolish with all that foam hanging from your mouth.
Re: (Score:2)
What part of Dice Holdings Inc. no longer own Slashdot are you failing to understand?
Perhaps you should wait until you've sobered up before posting again? You're setting a bad example for the youngsters.