systemd skip troublesome target at boot

MobiusHorizons · 2014-10-25 16:10:56

Hello all,

I installed gnome-software-git from the AUR, and attempted a (reboot and install upgrades). Unfortunately when it gets to (Reached target System Update), it hangs and won't continue.
Unfortunately, I don't have any bootable linux media available at the moment, so I am wondering is there a way (either from kernel commandline or while booting) to skip a troublesome systemd target?

PS. may I add that the registration process for arch forums should not contain the troublesome 'what is the result of "date -u +V%$(uname)|sha256sum|sed 's/\W//g'"?" I was forced to run this in jslinux(linux in a browser) since sha256sum was unavailable. I also had to be in windows because my arch install is currently not bootable (the reason I needed to register on the forums)

tomk · 2014-10-25 16:15:17

Boot into single user mode, disable the problem target, reboot, fix.

MobiusHorizons · 2014-10-25 17:00:28

Thanks single user mode got me in to be able to modify the system, however, if anyone runs into the same issue, It turns out I was unable to disable system-update.target using the command
`systemctl disable system-update.target` as expected

In order to fix it I had to enable packagekit offline upgrades as seen in this bug .

I do wish there was a default timeout for non-critical targets, or a way to change default target from the kernel command line.

falconindy · 2014-10-25 17:11:01

If you understand what targets are, you'll realize that they cannot possibly timeout. Individual dependencies of a target can timeout, but it makes no sense to say that a target has any sort of timeout associated with it. It's just a logical grouping of units, with no active functionality of its own.

In fact, by your own logging, system-update.target was in fact reached -- it didn't timeout. Something else did (which you probably didn't wait for, given the default 15m startup timeout).

MobiusHorizons · 2014-10-25 18:44:39

Thanks for the explanation. However, I did give it 20 minutes or so, and saw no timeout. I suppose it must have been waiting for packagekit offline upgrade which had not been enabled.

I am curious, however, why the target could not be disabled. Does anyone know?

branch · 2014-10-25 23:42:55

Targets cannot be disabled because they are effectively always disabled and are only started if they are a depencency of another unit. If you run "systemctl status multi-user.target" for example, where you would normally see "enabled" or "disabled" you see "static" instead. You can see what depends on a target with "systemctl show ${target}", look at the "WantedBy" and/or "RequiredBy" lines.

MobiusHorizons · 2014-10-26 04:04:25

Thanks. That helps me understand better. I'm still pretty new to systemd.

Arch Linux

#1 2014-10-25 16:10:56

systemd skip troublesome target at boot

#2 2014-10-25 16:15:17

Re: systemd skip troublesome target at boot

#3 2014-10-25 17:00:28

Re: systemd skip troublesome target at boot

#4 2014-10-25 17:11:01

Re: systemd skip troublesome target at boot

#5 2014-10-25 18:44:39

Re: systemd skip troublesome target at boot

#6 2014-10-25 23:42:55

Re: systemd skip troublesome target at boot

#7 2014-10-26 04:04:25

Re: systemd skip troublesome target at boot

Board footer