Systemd[1]: Failed to start Indicate boot is done

Bug Reports
1

REPRODUCIBILITY: ~50%
OS VERSION: 5.1.0.11
HARDWARE: Sony Xperia 10 III
UI LANGUAGE: En
REGRESSION: (edit: yes! see post #3)

DESCRIPTION:

Quite often the device starts up the home screen but remains there with a spinning circle.
Swiping left/right is not possible, opening the app drawer is not possible.
Getting ssh connectivity via USB cable is not possible.
Pulling down the top menu is possible. only this allows me to start the Settings app and try to restart a few things via Utilities. Nothing helps.

PRECONDITIONS:

None that I know of

STEPS TO REPRODUCE:

  1. Boot the phone
  2. Enter credentials, first (b/w) and second (color)

EXPECTED RESULT:

A normally working home screen with all functionality

ACTUAL RESULT:

Extremely reduced functionality as described in Description

MODIFICATIONS:

Patchmanager, Openrepos, Chum, some manual tweaks

ADDITIONAL INFORMATION:

This doesn’t happen every time; I suspect some race condition.
When I finally got a normal boot I went pouring over the journal (persistent logging was already enabled) and noticed something that 100% represents the failed boots & reboots I just went through.

journalctl --unit=init-done.service
-- Logs begin at Fri 2026-08-21 21:54:10 EEST, end at Sat 2026-08-22 13:25:43 EEST. --
Aug 22 02:08:44 Xperia10III systemd[1]: Stopped Indicate boot is done.
-- Reboot --
Aug 22 12:30:58 Xperia10III systemd[1]: Starting Indicate boot is done...
Aug 22 12:30:58 Xperia10III systemd[1358]: init-done.service: Failed to execute command: No such file or directory
Aug 22 12:30:58 Xperia10III systemd[1358]: init-done.service: Failed at step EXEC spawning /usr/lib/startup/wait-for-file: No such file or directory
Aug 22 12:30:58 Xperia10III systemd[1]: init-done.service: Control process exited, code=exited status=203
Aug 22 12:30:58 Xperia10III systemd[1]: init-done.service: Failed with result 'exit-code'.
Aug 22 12:30:58 Xperia10III systemd[1]: Failed to start Indicate boot is done.
-- Reboot --
Aug 22 12:48:11 Xperia10III systemd[1]: Starting Indicate boot is done...
Aug 22 12:48:11 Xperia10III systemd[1341]: init-done.service: Failed to execute command: No such file or directory
Aug 22 12:48:11 Xperia10III systemd[1341]: init-done.service: Failed at step EXEC spawning /usr/lib/startup/wait-for-file: No such file or directory
Aug 22 12:48:11 Xperia10III systemd[1]: init-done.service: Control process exited, code=exited status=203
Aug 22 12:48:11 Xperia10III systemd[1]: init-done.service: Failed with result 'exit-code'.
Aug 22 12:48:11 Xperia10III systemd[1]: Failed to start Indicate boot is done.
-- Reboot --
Aug 22 13:00:39 Xperia10III systemd[1]: Starting Indicate boot is done...
Aug 22 13:02:53 Xperia10III wait-for-file[1346]: Found /run/user-session/user-init-done.flag file
Aug 22 13:02:53 Xperia10III init-done[4622]: INIT DONE in 142.27 s
Aug 22 13:02:53 Xperia10III systemd[1]: Started Indicate boot is done.

Unfortunately the forum does not display the red color.
To explain: on 2 successive boots init-done.service failed, on the third it succeeded.

The init-done service simply waits for the file /run/user-session/user-init-done.flag to appear, then does executes some runlevel dbus stuff, see shell script /usr/lib/startup/init-done.

Of course the question is why it fails.

Right now I have no working theory but I have saved the current journal, i.e. one succesful boot and 2 failed boots.

Any thought/theory/suspicion that can be followed up is welcome.

1 Like
2

Do any of the mentioned modifications of tweaks include custom systemd units?

3

Yes, they do!

Although none of them ever fail.
They all start long after init-done.service fails.

Except one.

I’ve been using it for 5 years or so, never a problem so far.

[Unit]
Description=Make sure /bin/sh and /usr/bin/sh are linked to busybox

[Service]
Type=oneshot
ExecStart=/bin/ln -sf /usr/bin/busybox /bin/sh
ExecStart=/bin/ln -sf /usr/bin/busybox /usr/bin/sh

[Install]
WantedBy=local-fs.target

After many reboots and edits, I’m guessing that Type=oneshot had sth to do with it. I changed the unit now thusly:

[Unit]
Description=Make sure /bin/sh and /usr/bin/sh are linked to busybox
After=local-fs.target
DefaultDependencies=no

[Service]
# the default:
Type=simple
# yes, it is possible to start sh shortly before force-symlinking it
ExecStart=/bin/sh -c '/bin/ln -sf /usr/bin/busybox /bin/sh; /bin/ln -sf /usr/bin/busybox /usr/bin/sh; exit 0'

[Install]
WantedBy=local-fs.target

The idea is that the service starts & systemd immediately assumes it succeeded & forgets about it.
Comparing the old output to the new output seems to confirm this.

Old:

journalctl -b -D b29dff9d827f45d6ad6e35fc049068d1/ -u symlink-sh
-- Logs begin at Fri 2026-08-21 21:54:10 EEST, end at Sat 2026-08-22 13:56:10 EEST. --
Aug 22 13:00:39 Xperia10III systemd[1]: Starting Make sure /bin/sh and /usr/bin/sh are linked to busybox...
Aug 22 13:00:39 Xperia10III systemd[1]: Started Make sure /bin/sh and /usr/bin/sh are linked to busybox.

New:

journalctl -b -u symlink-sh
-- Logs begin at Thu 2026-08-27 14:30:45 EEST, end at Thu 2026-08-27 15:30:42 EEST. --
Aug 27 15:26:11 Xperia10III systemd[1]: Started Make sure /bin/sh and /usr/bin/sh are linked to busybox.

So far, it works. Knock on wood.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

I still consider this an issue though: such a simplistic and working (!) unit should not affect the boot-up process in such a way, so intransparently, and esp. after it did not do so for years.

Not sure who would be the right person to ping on this, maybe @rainemak @keto @Jolla ?

4

For me this links exists out of the box at my JP2. Just w/o your service. Mayby skip it.

By the way: changing the boot process means on own risk?

5

Agreed. Why are you messing with the default shell?
That’s like super high risk of fucking something up.

What if you install a package which depends on gnu-bash? It will remove the symlinks and replace them with symlinks to proper bash, which you then later overwrite.

What if that package also has a systemd unit which requires the shell to be bash not busybox (hence the dep on gnu-bash, not /bin/sh)?

Answer: breakage.

6

Of course it’s my own risk, but I maintain that the boot process should be as transparent and, well, tweakable as possible, as with all other parts of the OS, and should not break on something so trivial.

I’m invested in a true Linux phone. This includes all aspects of the OS. That doesn’t end once I leave $HOME.

Everything is that if you don’t know what you’re doing.

This service is born from the following:

If I install gnu-bash /bin/sh links to bash, which is wrong, and potentially lengthens the boot process:

rpm -ql gnu-bash
/bin/bash
/bin/sh
/etc/skel/.bash_logout
/etc/skel/.bash_profile
/etc/skel/.bashrc
/usr/bin/bash
/usr/bin/sh
/usr/share/licenses/gnu-bash-5.0.18+git2
/usr/share/licenses/gnu-bash-5.0.18+git2/COPYING

It ensures that sh always defaults to a simple shell, in this case busybox.

PS: if we continue this discussion I know it will come up so I’ll just say it here: this issue does not compare to my very obvious fuck-up during the early days of hosts-block.