Closed ummon29 closed 6 years ago
The fix could use more extensive testing, but at least the phone seems to boot up without issues and the systemd-udev-settle.service failure is gone.
I've encountered this problem as well. There is no update containing #68 in Jolla Store, and I didn't know that I have to manually add OBS repo to get further updates.
So, I had to investigate and found the following.
The problem can also be worked around by increasing timeout in systemd-udev-settle.service
(by specifying -t 300
args to udevadm
and by changing TimeoutSec
parameter 310
). This makes udevd
to proceed further after about 200 seconds, but it complains that toh-core.0
takes too long. And this adds extra 200 seconds to startup time, obviously.
Journal for tohkbd2.service
shows that it starts after the timeout. This is an indication that there is some kind of dependency loop that is not detected by systemd
because it doesn't know that systemd-udev-settle.service
waits for harbour-tohkbd2.service
.
No networking problem is caused by connman.service
to dependent recursively on droid-hal-init.service
(that doesn't start at all) and then on systemd-udev-settle.service
(that doesn't start because its ExecStart
command fails). Not starting droid-hal-init.service
causes many other problems (like no bluetooth adapter detected).
I think, this confirms that systemd
wants droid-hal-init.service
to finish before harbour-tohkbd2.service
:
[root@Sailfish nemo]# systemctl --no-pager -l list-dependencies --recursive --before droid-hal-init.service
droid-hal-init.service
● ├─bluetooth.service
● ├─ftd.service
● ├─ofono.service
● ├─sensord.service
● ├─basic.target
● │ ├─alien-service-manager.service
● │ ├─alien-settings.service
● │ ├─aliendalvik.service
● │ ├─autologin@100000.service
● │ ├─bluetooth.service
● │ ├─connman-vpn.service
● │ ├─connman.service
● │ ├─display.service
● │ ├─fastdormancy.service
● │ ├─ftd.service
● │ ├─harbour-tohkbd2.service
● │ ├─init-actdead-cpu.service
● │ ├─init-done.service
● │ ├─jolla-devicelock-encpartition.service
● │ ├─limit-cpu.service
● │ ├─mount-sd@mmcblk1.service
● │ ├─odnpd.service
● │ ├─ofono.service
● │ ├─oneshot-root-late.service
● │ ├─oneshot-root.service
● │ ├─policies-setup.service
● │ ├─rescue-password-off.service
● │ ├─runlevel-actdead-done.service
● │ ├─runlevel-user-done.service
● │ ├─sailfish-hciwait.service
● │ ├─sensorfwd.service
● │ ├─sshd.service
● │ ├─start-user-session.service
● │ ├─systemd-ask-password-wall.service
● │ ├─systemd-hostnamed.service
● │ ├─systemd-logind.service
● │ ├─systemd-user-sessions.service
● │ ├─tohd.service
● │ ├─udisks2.service
● │ ├─user@100000.service
● │ ├─wayland.service
● │ ├─wpa_supplicant.service
● │ ├─actdead-pre.target
● │ │ └─actdead.target
● │ ├─factory-test.target
● │ └─multi-user.target
● │ └─graphical.target
● └─network.target
● ├─aliendalvik.service
● └─multi-user.target
● └─graphical.target
Hence, it waits because droid-hal-init.service
has:
Wants=systemd-udev-settle.service
After=local-fs.target systemd-udev-settle.service
Please note Wants
directive that means that droid-hal-init.service
doesn't start after systemd-udev-settle.service
fails, but it doesn't invalidate the whole transaction, and harbour-tohkbd2.service
starts eventually, but it's too late.
Of course, my knowledge of systemd
unit dependencies is limited, so I'm not absolutely sure if my analysis is completely right. But if it's right, fix in #68 is the right one because it breaks this dependency loop and allows delayed start of harbour-tohkbd2.service
without timing out udev
rule that makes systemd-udev-settle.service
to time out and fail.
Finally, I'd like to suggest that it would be better if updated version of harbour-ambience-tohkbd2
was published in Jolla Store to make those who installed it from there to have fixed version automatically.
Release 0.5.26 in harbour contains #68
Looks like I have a problem with Jolla Store on my phone as well. I was recovering it from botched upgrade, so it may still have issues unrelated to this one.
Having the TOHKBD2 (or any other Other Half) attached during bootup results in an Jolla1 without working WLAN or mobile connection. If the TOHKBD2 is attached after the booting everything (including the TOHKBD2) is working as expected. Without much of an investigation on my side, the most plausible explanation I have found is that a systemd update causes trouble with the module loading order during bootup.
There are some reports on together.jolla.com and talk.maemo.org. This one for example: https://together.jolla.com/question/164495/21123-o-mobile-connection-nor-wlan-on-j1/
Best regards and thanks for all your Work