Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
titanOffline
Post subject: systemd  PostPosted: 08.07.2014, 10:38



Joined: 2010-09-11
Posts: 77

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).
 
 View user's profile Send private message  
Reply with quote Back to top
finottiOffline
Post subject: RE: systemd  PostPosted: 08.07.2014, 11:29



Joined: 2010-09-12
Posts: 312

Status: Offline
FWIW, I've installed systemd-sysv, rebooted, purged systemd-shim (in my old installation) and all is good.
 
 View user's profile Send private message  
Reply with quote Back to top
titanOffline
Post subject: RE: systemd  PostPosted: 08.07.2014, 12:25



Joined: 2010-09-11
Posts: 77

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.
 
 View user's profile Send private message  
Reply with quote Back to top
ghstryderOffline
Post subject: RE: systemd  PostPosted: 08.07.2014, 17:04



Joined: 2010-09-12
Posts: 95
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).
 
 View user's profile Send private message  
Reply with quote Back to top
titanOffline
Post subject: Re: RE: systemd  PostPosted: 08.07.2014, 18:19



Joined: 2010-09-11
Posts: 77

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.
 
 View user's profile Send private message  
Reply with quote Back to top
slhOffline
Post subject: RE: Re: RE: systemd  PostPosted: 08.07.2014, 21:51



Joined: 2010-08-25
Posts: 737

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.
 
 View user's profile Send private message  
Reply with quote Back to top
titanOffline
Post subject: RE: Re: RE: systemd  PostPosted: 09.07.2014, 08:05



Joined: 2010-09-11
Posts: 77

Status: Offline
Thanks for the full and interesting explanation of the situation with systemd and aptosid much appreciated.
 
 View user's profile Send private message  
Reply with quote Back to top
sid.dhartaOffline
Post subject: RE: Re: RE: systemd  PostPosted: 09.07.2014, 08:48



Joined: 2012-05-02
Posts: 6

Status: Offline
So far so good. Nevertheless the instructions to make a safe d-u may need to be revised, see http://aptosid.com/index.php?name=PNphp ... amp;t=2795
 
 View user's profile Send private message  
Reply with quote Back to top
hyOffline
Post subject:   PostPosted: 02.09.2014, 14:48



Joined: 2010-09-14
Posts: 164
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...
 
 View user's profile Send private message  
Reply with quote Back to top
bfreeOffline
Post subject:   PostPosted: 02.09.2014, 14:56
Team Member


Joined: 2010-08-26
Posts: 255

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.
 
 View user's profile Send private message  
Reply with quote Back to top
hyOffline
Post subject:   PostPosted: 02.09.2014, 15:08



Joined: 2010-09-14
Posts: 164
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...
 
 View user's profile Send private message  
Reply with quote Back to top
bfreeOffline
Post subject:   PostPosted: 02.09.2014, 16:17
Team Member


Joined: 2010-08-26
Posts: 255

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.
 
 View user's profile Send private message  
Reply with quote Back to top
hyOffline
Post subject:   PostPosted: 02.09.2014, 17:04



Joined: 2010-09-14
Posts: 164
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?
 
 View user's profile Send private message  
Reply with quote Back to top
kenyeeOffline
Post subject:   PostPosted: 05.09.2014, 02:05



Joined: 2010-09-29
Posts: 85

Status: Offline
This is seriously the worse Debian breakage I've seen yet for a long time Razz
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 Sad
 
 View user's profile Send private message  
Reply with quote Back to top
bfreeOffline
Post subject:   PostPosted: 05.09.2014, 02:54
Team Member


Joined: 2010-08-26
Posts: 255

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 Sad

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.
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT - 12 Hours
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by Zafenio