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 …
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..
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.
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"
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.
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.
> ...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'".
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 ;-)
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.
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
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!
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
