| Author |
Message |
titan
|
|
Post subject: systemd
 Posted: 08.07.2014, 10:38
|
|
Joined: 2010-09-11
Posts: 101
Status: Offline
|
|
What is the current aptosid situation with this.A few weeks ago I had to install systemd-shim to allow an upgrade, now slh advice to someone with upgrade problems is to purge systemd-shim. It would be good to get an update from the devs as to how aptosid will change to systemd instead of drip feed of problems
slh from other post
Dist-upgrading from the last release should be fine, just make sure to install systemd-sysv at the end (if not already pulled in automatically) and to purge systemd-shim (if it happens to be installed). |
|
|
| |
|
|
|
 |
|
finotti
|
|
|
Post subject: RE: systemd
Posted: 08.07.2014, 11:29
|
|
Joined: 2010-09-12
Posts: 493
Status: Offline
|
|
| FWIW, I've installed systemd-sysv, rebooted, purged systemd-shim (in my old installation) and all is good. |
|
|
| |
|
|
|
|
|
titan
|
|
|
Post subject: RE: systemd
Posted: 08.07.2014, 12:25
|
|
Joined: 2010-09-11
Posts: 101
Status: Offline
|
|
| Thanks for the info but the problem is that all the post regarding systemd are reactive when users have a problem. Debian is now systemd aptosid is not. A routemap to systemd for aptosid from the devs would be useful. The manual makes no mention of systemd. |
|
|
| |
|
|
|
|
|
ghstryder
|
|
|
Post subject: RE: systemd
Posted: 08.07.2014, 17:04
|
|
Joined: 2010-09-12
Posts: 97
Location: Detroit
Status: Offline
|
|
|
titan wrote:
Thanks for the info but the problem is that all the post regarding systemd are reactive when users have a problem. Debian is now systemd aptosid is not. A routemap to systemd for aptosid from the devs would be useful. The manual makes no mention of systemd.
http://www.aptosid.com/index.php?name=PNphpBB2&file=viewtopic&t=2796&start=0
From the above post, slh stated:
Quote:
systemd-shim is a temporary bandaid, which will break hard once the systemd maintainers upgrade to logind >= 205 (any day now), which isn't a solution and should not be used.
I don't want to speak for the Devs, but I suspect the roadmap is to install systemd-sysv and to purge systemd-shim (if it happens to be installed). |
|
|
| |
|
|
|
|
|
titan
|
|
|
Post subject: Re: RE: systemd
Posted: 08.07.2014, 18:19
|
|
Joined: 2010-09-11
Posts: 101
Status: Offline
|
|
|
ghstryder wrote:
I don't want to speak for the Devs, but I suspect the roadmap is to install systemd-sysv and to purge systemd-shim (if it happens to be installed).
I have read that post which was called "System unbootable after d-u - solved" hardly a roadmap which is a route from A to B or in this case sysvinit to systemd. All the posts regarding the changes are in response to problems users are getting. A sticky post detailing what is needed to keep up with changes would be useful.For example I can't find the new commands for changing run levels, reboot etc, yes I am sure they will be here somewhere buried in some thread but my point is it would be useful if this information was somewhere on this site readily available.Incidentally the basic commands are available in the news section on the siduction forum. |
|
|
| |
|
|
|
|
|
slh
|
|
|
Post subject: RE: Re: RE: systemd
Posted: 08.07.2014, 21:51
|
|
Joined: 2010-08-25
Posts: 962
Status: Offline
|
|
Debian's technical committee (ctte) has decided to switch from sysvinit(-core) to systemd(-sysv), as such aptosid follows that decision. We have no reason to spearhead this switch, nor to block it[0]. For the enduser, it's mostly a transparent implementation detail[1]. For us as package/ distro/ derivative maintainers, it has some more technical consequences and challenges, which need attention before the next release.
Technically speaking, the default hasn't been toggled formally yet (but it's supposed to happen very soon, given that systemd 204-14 has now reached jessie), however the dependency chains of remotely desktop'ish systems already hard-depend on logind, which is part of systemd (and as mentioned elsewhere, systemd-shim is a dead-end with no future[2]).
So yes, there is a strong recommendation[3] for all systems to move over to systemd-sysv and to purge eventually installed systemd-shim packages. The "systemd-sysv" package should be installed, eventual installations of "systemd-shim" need to be purged. In most cases this should have happened automatically, via the dependency chains of all larger desktop environments, but there may be corner cases where the installed package base might have led to a different dependency resolution, this is where manual interaction is advised.
In most cases the migration from sysvinit-core to systemd-sysv is supposed to be smooth and transparent, basically with the only visible effect being there less verbose startup messages (by default). Systemd is stricter when it comes to invalid fstab entries (like long forgotten swap partitions, but also other (syntax) errors are punished by systemd; sysvinit often managing to boot regardless of those is the real error here). Likewise systemd doesn't like dependency loops in system dæmons, this affects a handful of (broken) services (e.g. setserial), which declare conflicting service dependencies and might affect booting.
Avoiding systemd(-sysv) and sticking to sysvinit(-core) is no longer (reasonably) possible, bugs and problems without it are becoming increasingly likely over time (e.g. hotplug detection for removable media is effectively already broken with sysvinit). It may work (to varying degrees of brokeness) for severely stripped down, server-like, installations until Debian's next release, but once jessie goes gold, it's very likely that sysvinit(-core) compatibility will bitrot very soon and regress continuously (non-linux variants of Debian will have a hard time to counter this).
[0] a modern, event based init replacing sysvinit was desperately needed - technically both upstart or systemd could have filled this void equally well. Upstream adoption, as well as the decisions of the other major distributions, has favoured systemd. Given how quickly upstart development has folded, systemd is certainly the better choice - but there is no reason for 'fanboyism' of either side. At the end of the day, this is 'just' an init systemd, destined to do boring stuff behind the curtain.
[1] it has some effects on runlevel management, debugging or service handling, but in general, the systemd packagers have done a magnificent job of retaining compatibility as much as possible.
[2] systemd-shim was conceived as stopgap measure by Ubuntu, in order to start up logind (which has become mandatory by all larger desktop environments) without systemd as pid0. The current bandaid employed is only compatible up to/ including logind 204, once systemd/ logind 205 are uploaded to unstable, this bandaid will explode. Given that Ubuntu has already abandoned upstart for their upcoming release and switched to systemd instead, there is little chance for them to fix up systemd-shim for logind >= 205, no one else stepped in to maintain it yet - and it doesn't appear as if anyone will do so before logind >= 205 enters sid (or at all). The systemd maintainers have already delayed uploading newer systemd version in order to give interested parties the chance to fix up systemd-shim, but this hasn't happened so far.
[3] Doing blanket recommendations for major migrations like this is always a hard decision. If all goes well, there's no visible difference, but there's always an inherent danger of (fatal) breakage on the user's system. Hitting corner cases is more likely when doing in-place upgrades of (long-)existing systems, than installing a fresh system with new defaults. |
|
|
| |
|
|
|
|
|
titan
|
|
|
Post subject: RE: Re: RE: systemd
Posted: 09.07.2014, 08:05
|
|
Joined: 2010-09-11
Posts: 101
Status: Offline
|
|
| Thanks for the full and interesting explanation of the situation with systemd and aptosid much appreciated. |
|
|
| |
|
|
|
|
|
sid.dharta
|
|
|
Post subject: RE: Re: RE: systemd
Posted: 09.07.2014, 08:48
|
|
Joined: 2012-05-02
Posts: 8
Status: Offline
|
|
|
|
|
|
|
hy
|
|
|
Post subject:
Posted: 02.09.2014, 14:48
|
|
Joined: 2010-09-14
Posts: 194
Location: Costa Teguise
Status: Offline
|
|
Did a d-u today and afterwards I installed systemd-sysv and removed systemd-shim.
Result: system unbootable (Emergency console - without error)
I removed systemd-sysv and reinstalled systemd-shim - everything works.
Except for sleep and hibernate which is gone... |
|
|
| |
|
|
|
|
|
bfree
|
|
|
Post subject:
Posted: 02.09.2014, 14:56
|
|
Team Member
Joined: 2010-08-26
Posts: 267
Status: Offline
|
|
| The most common cause of failure's to boot with systemd-sysv is a bad entry in /etc/fstab which sysvinit just ignored but systemd "breaks" on. |
|
|
| |
|
|
|
|
|
hy
|
|
|
Post subject:
Posted: 02.09.2014, 15:08
|
|
Joined: 2010-09-14
Posts: 194
Location: Costa Teguise
Status: Offline
|
|
There is no "bad" entry in /etc/fstab
another question: viewing the logfiles I found in
/var/log/dmesg
Code:
Warning: nss-myhostname is not installed. Changing the local hostname might make it unresolveable. Please install nss-myhostname
But there is no package nss-myhostname
[edit:] there is a crypted disk in /etc/fstab that is bound to /dev/mapper/<something> which doesn't exist at startup... |
|
|
| |
|
|
|
|
|
bfree
|
|
|
Post subject:
Posted: 02.09.2014, 16:17
|
|
Team Member
Joined: 2010-08-26
Posts: 267
Status: Offline
|
|
nss-myhostname is not in Debian (yet) and it's only a warning. Heed it if you want to change your hostname but otherwise no need to worry about it.
That crypted disk that doesn't exist (I'm guessing until you manually bring up the crypt device) probably stopped systemd in it's tracks on boot. If fstab says something should be mounted but systemd can't do it then systemd will stop and throw you into the emergency console where sysvinit would just carry on without it. |
|
|
| |
|
|
|
|
|
hy
|
|
|
Post subject:
Posted: 02.09.2014, 17:04
|
|
Joined: 2010-09-14
Posts: 194
Location: Costa Teguise
Status: Offline
|
|
Thanks bfree for clearing the matter.
Another question (hoping I do not get too much off topic):
After todays d-u I noticed that system hangs for about 20 sec. on booting after the message
Code:
waiting for udev to be fully populated
udev.d[387] timeout net.agent
How to get rid of that? |
|
|
| |
|
|
|
|
|
kenyee
|
|
|
Post subject:
Posted: 05.09.2014, 02:05
|
|
Joined: 2010-09-29
Posts: 100
Status: Offline
|
|
This is seriously the worse Debian breakage I've seen yet for a long time 
I'm in emergency mode after a dist-upgrade..haven't even rebooted yet, but I can't get a command shell or ssh into the box. Any suggestions?
I presume rebooted will get me into the broken state where I have to reinstall  |
|
|
| |
|
|
|
|
|
bfree
|
|
|
Post subject:
Posted: 05.09.2014, 02:54
|
|
Team Member
Joined: 2010-08-26
Posts: 267
Status: Offline
|
|
|
kenyee wrote:
I'm in emergency mode after a dist-upgrade..haven't even rebooted yet, but I can't get a command shell or ssh into the box. Any suggestions?
I've no idea where you are now, not seen or heard of this happening to anyone before. You haven't given us any clues or hope of guessing what has happened either, not even if this was your first d-u since systemd arrived or if you last d-u'd yesterday.
Quote:
I presume rebooted will get me into the broken state where I have to reinstall
Unlikely and if it is the case then odds are you can't save it before you reboot either. Probably the worst case is you boot from an aptosid cd or usb-stick from which you can chroot in and try and figure out what the problem is and sort it out. |
|
|
| |
|
|
|
|
|
|
