back to article Debian upgrades Wheezy and Jessie with a combined 372 updates

Popular GNU/Linux distribution Debian published the second update to its “Jessie” stable release over the weekend and the ninth update for its older “Wheezy” edition. Debian Jessie 8.2 “mainly adds corrections for security problems to the stable release, along with a few adjustments for serious problems”, according to the …

  1. Creslin

    Wheezy remains in production, as system-d still not fully stable compounds this

    We've tried several times to jump to Jesse and at every turn found niggling but time consuming and therefore hacky bespoke work-around/fixes for deployments all related to SystemD

    These are mostly on the edge use-cases, rsyslog, cacti, etc etc

    But my point is we, and a lot of other shops, are sticking with wheezy for the time being till the system-d dust settles throughout the apt repositories. Somewhat compounding the whole Sec support issue for wheezy. An exception should be made, maintain wheezy for a couple years till the user-land catches up with SysD dependencies.

    The whole rationale of Debian stable (as I viewed the OS landscape) was it was old, tested to death, not cutting edge -- but bullet proof on a server with apps a mere key stroke away. System-D ran roughshod over the whole unstable to stable process.

    We need wheezy and we're lazy, but we're not the only ones..

    1. John Hughes

      Re: Wheezy remains in production, as system-d still not fully stable compounds this

      So support Debian LTS then.

      (Preferably with money).

    2. John Hughes

      Re: Wheezy remains in production, as system-d still not fully stable compounds this

      These are mostly on the edge use-cases, rsyslog, cacti, etc etc

      What do you need to do for rsyslog? My understanding is that it should just work as-is.

      1. Tim Brown 1

        Re: Wheezy remains in production, as system-d still not fully stable compounds this

        systemd causes problems with rsyslog because on boot it starts it late and on shutdown it kills it too early. Thus you miss (possibly important) startup/shutdown messages.

        1. John Hughes

          Re: Wheezy remains in production, as system-d still not fully stable compounds this

          Well, no.

          AFAIK (please correct me if I'm wrong) syslogd is started and stopped at more or less the same time with sysvinit and systemd.

          However with systemd messages are logged to journald, not syslogd. journald will pass them on to syslogd when syslogd starts up, so more messages are logged at startup.

          1. Tim Brown 1

            Re: Wheezy remains in production, as system-d still not fully stable compounds this

            My own experience, when I did a default upgrade from Wheezy to Jessie on a test box was that syslog was no longer showing important shutdown messages from Mysql, so it wasn't clear if the database process had exited cleanly. These messages may well have gone to journald, but the default setup was not saving the previous journald on a reboot so I had no way of knowing without diving into the systemd configuration.

            Quite frankly I was extremely fed-up that an upgrade should mess around with logging in this way. It was not something I wanted. i was relieved to discover a way to do the upgrade on live without getting systemd.

            IMHO such a fundemental change should not have been a default option when upgrading in the first place. It's equivalent to telling Postfix users to use Exim instead "just because we say so"

    3. Tim Brown 1
      Thumb Up

      Re: Wheezy remains in production, as system-d still not fully stable compounds this

      To upgrade from Wheezy to Jessie without having systemd take over your system, then before you upgrade put in a file in /etc/apt/preferences.d/

      Package: systemd-sysv

      Pin: release o=Debian

      Pin-Priority: -1

      Your upgrade should then be pretty painless.

  2. Chronos
    Joke

    Bloody systemd!

    NFS mounts are still in a race condition with the remote filesystem target! It's unacceptable, I tell you! /lib/systemd/system, add "After=nfs-common.service" to remote-fs-pre.target and all should then be well.

    Joking aside, this stuff should be in nfs-common's run control files. The reason it can't be is that nfs-common still uses an old style init script. As Creslin says, we're waiting for the legacy stuff to go away before everything starts to just work again.

    1. Anonymous Coward
      Anonymous Coward

      Re: Bloody systemd!

      > ...we're waiting for the legacy stuff to go away before everything starts to just work again

      Well a lot of us are waiting for the "promised"* SystemD free next version after Jessie. Lets just say I'm not holding my breath.

      * As I read various "discussions" prior to the "we're going SystemD and if you don't like it you can shove it" decision, one of the concessions was along the lines of "don't worry, while we can't 'fix' it right now, we'll fix it in the next release". When I saw that, I never believed it, and I still don't believe they'll ever rid Debian of that cancer.

      Latest I've read is that "there's a problem with 'su'" - to which the answer for everyone else would be "fix 'su'", but for SystemD the only possible answer is "include something like 'su' that's both more complicated to use and merged into the 'blob'".

      1. John Hughes

        Re: Bloody systemd!

        Well a lot of us are waiting for the "promised"* SystemD free next version after Jessie. Lets just say I'm not holding my breath.

        Are you talking about Devuan? Why bother waiting, just install sysvinit on Jessie instead of systemd.

    2. John Hughes

      Re: Bloody systemd!

      /lib/systemd/system, add "After=nfs-common.service" to remote-fs-pre.target and all should then be well.

      Shouldn't you be pitting a new file in /etc/systemd/system instead of modifying the existing one in /lib/systemd/system?

      1. Chronos

        Re: Bloody systemd!

        Shouldn't you be pitting a new file in /etc/systemd/system instead of modifying the existing one in /lib/systemd/system?

        Not at the moment, no. I deliberately put that there so that when (if) nfs-common gets the update to a proper unit file, the next systemd update will wipe out my changes which then allows systemd updates to make other changes to that file without my modification becoming persistent. Method in the madness.

        I don't want custom stuff hanging around that could potentially screw up rc ordering unless it's absolutely necessary. I had enough of that on FreeBSD, thanks. At least if it gets wiped out before nfs-common is dragged up to date I'll have known behaviour to go on. rc ordering screwups, on the other hand, are fast-tracks to male pattern baldness.

        Also and probably mainly, I'm lazy ;-)

  3. druck Silver badge
    Happy

    Ok here

    I took the plunge and updated my Rapberry Pi 2 from Wheezy to Jessie, and have not looked back. The updated Mate desktop is particularly worthwhile. Just installing those updates now...

    1. paulc

      Re: Ok here

      Just wish there was a proper official download of Jessie on the Raspberry Pi website...

      I'm not exactly enamored of forum postings that give instructions for doing it yourself but loads of posts from people who've had nothing but trouble trying it...

      1. Anonymous Coward
        Anonymous Coward

        Re: Ok here

        Raspi is one thing, production servers are quite another...

        Happy coincidence: I finally started my transition to FreeBSD last week. So far, so good... pretty sure I'll be off of Linux servers by the time wheezy falls into neglect.

  4. Anonymous Coward
    Anonymous Coward

    for YEAR in 201{0,1,2,3,4,5,6,7,8,9}; do

    echo "So is ${YEAR} the year of Linux on the desktop?"

    done

  5. Anonymous Coward
    Anonymous Coward

    At the risk of starting a small war,  "of course Debian is Linux so even if you have been tardy, upgrading to the new releases doesn't need much more than a quick bit of sudo action" isn't really true. Particularly if you have been tardy and are more than one revision behind, in which case advice seems to be to reinstall.

    1. John Hughes

      Who's advice?

      You might like to do the update one version at a time if you were paranoid (I am) but a reinstall? Why?

  6. tom dial Silver badge

    The last paragraph suggests that Wheezy users were at increased risk due to the long interval between the 7.8 and 7.9 releases. This is not so if they applied updates regularly. I have two remaining Wheezy systems, both set to download and apply security packages automatically. That gave the following update history.

    System A B

    No. updates before 7.9 91 68

    No. packages installed before 7.9 855 511

    No. packages installed with 7.9 42 24

  7. Loud Speaker

    I have spent most of yesterday trying to install one or the other on an SSD system. Both collapse in a heap because of race conditions. In one case, there is a realtek wireless card, and Jessie goes into a tail spin failing to install the firmware (Its probably corrupt, but after N tries it should abort). AND why can't I just tell it not to try Networking during the install anyway?

    Wheezy fails because it can't install Busybox (???) because the installer is locked while something else is installed!

    Come on guys! This is MS quality software. Surely you can do better!

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like

Biting the hand that feeds IT © 1998–2022