systemd-firstboot.service prevents system from booting up about aoscoslauncher HOT 5 CLOSED

https://github.com/AOSC-Dev/aoscbootstrap/blob/master/assets/cleanup.sh#L43 this line makes /etc/machine-id missing in generated tarball. thus let wsl or the other things hijacked this file, let it become a read-only file.

there is a temporary solution: create a empty file in the tarball.

from aoscoslauncher.

Append: Confirmed and reproduced in AOSC QQ Group. Tried downgrading WSL to 2.0.14 and 2.0.9 and still not working.
The cause seems to be DBus socket not presenting at /run/dbus/system_bus_socket. Running a working distro by side seems to create(?) it and make it work.
The problem is that:

• why they "share" a working socket? or at least, why and how they affect each other?
• why other distros work?

Update

Since the cause of the issue is found and is completely unrelated to dbus itself, this comment is folded. The "sharing" dbus socket is still a fun mystery though :)

Up-update

No. Completely unrelated. Firing up other systemd distro just makes AOSC's firstboot run. Mystery.

from aoscoslauncher.

Noticed that actually the system isn't fully booted up. This is the cause for dbus not starting.
Some dev suggested to disable sshd service, but not working for my env.
I discovered that the boot process stuck at systemd-firstboot.service by running sudo systemctl list-jobs.
Killed it and works.
Changing the issue title...

from aoscoslauncher.

After discovering with that dev, we finally found the cause: /etc/machine-id is mounted RO by WSL.
Last question: why? why not others?

from aoscoslauncher.

Transferring this issue to bootstrap repo...

from aoscoslauncher.