Slashdot Mirror


Linux Kernel 2.6.32 LTS Reaches End of Life In February 2016 (softpedia.com)

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.

7 of 116 comments (clear)

  1. Re:RHEL6 by arth1 · · 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.

  2. Re: RHEL6 by Anonymous Coward · · Score: 1, Informative

    Did you have a /var/lib/mongo/mongo.lock file? If so, the problem was your own fault.

  3. Re:RHEL6 by kthreadd · · Score: 4, Informative

    They already do that. The 2.6.32 kernel that you get in RHEL 6 is not exactly the same 2.6.32 that you get from kernel.org. There are many backported features already implemented that the upstream kernel does not include.

  4. Re: RHEL6 by Anonymous Coward · · 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.

  5. Re:RHEL6 by thegarbz · · Score: 1, 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.

  6. Re: RHEL6 by thegarbz · · 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.

  7. Re:Still on 2.6.32 because of Distro by Maow · · Score: 4, 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!