I figured it out:
$ ls -l /tmp/sbin lrwxrwxrwx 1 tom tom 7 Jul 29 23:32 /tmp/sbin -> usr/bin $ ls -l /tmp/lib ls: cannot access '/tmp/lib': No such file or directory $ ls -l /tmp/usr/ total 0 drwxr-xr-x 2 tom tom 80 Jul 29 23:34 bin drwxr-xr-x 3 tom tom 60 Jul 29 23:34 lib $ ls -l /tmp/usr/bin/ total 0 lrwxrwxrwx 1 tom tom 20 Jul 29 23:33 inita -> /lib/systemd/systemd lrwxrwxrwx 1 tom tom 22 Jul 29 23:33 initb -> ../lib/systemd/systemd $ ls -l /tmp/usr/lib/ total 0 drwxr-xr-x 2 tom tom 60 Jul 29 23:34 systemd $ ls -l /tmp/usr/lib/systemd/ total 0 -rwxr-xr-x 1 tom tom 0 Jul 29 23:34 systemd $ realpath /tmp/sbin/init{a,b} /usr/lib/systemd/systemd /tmp/usr/lib/systemd/systemd
And then take a look at these lines of the "early" init (script) that used by default in Arch:
https://github.com/archlinux/mkinitcpio/blob/v30/init#L5
https://github.com/archlinux/mkinitcpio/blob/v30/init#L57
Consider /tmp in the above to be /new_root. You should then see why it's wrong to use init(a) -> /lib/systemd/systemd:
/ (root) refers to a totally different thing before and after it switches root.
Before it's just a ramfs (or maybe actually, tmpfs?) where the content of the initramfs / initcpio are extracted to. After it's the filesystem that is used for the "real root" (i.e. what is mounted on /new_root).
Since the check is done before it switches root:
https://github.com/archlinux/mkinitcpio/blob/v30/init#L76
It will not find /usr/lib/systemd/systemd.
I don't know what exactly is used as the early init in Ubuntu. There's a chance that it is systemd (mkinitcpio allows you to do so in Arch as well. You just need to include the systemd hook.) Probably systemd will not use /sbin/init or /usr/bin/init to locate its copy in the real root, but rather simply /lib/systemd/systemd or /usr/lib/systemd/systemd.
P.S. Since when you use the systemd hook, a copy of usr/lib/systemd/systemd (in the real root) will be added to the initramfs / initcpio. If it also includes (which I didn't bother to check) a lib -> usr/lib symlink, sbin/init (usr/bin/init) will ultimately lead to the usr/lib/systemd/systemd (in the aforementioned ramfs / tmpfs) even if it points to /lib/systemd/systemd. (There's a reason that I removed all leading / in all paths but /lib/systemd/systemd. See if you can understand why.)
P.S. You might wonder why realpath /tmp/sbin/inita in my test returned /usr/lib/systemd/systemd even when I didn't have a /tmp/lib pointing to usr/lib. The reason is /tmp/sbin/inita is resolved into /tmp/usr/bin/inita which points to /lib/systemd/systemd which is resolved to /usr/lib/systemd/systemd.
lncommand? Did you confirm that after thelnyou had a/sbin/init -> ../lib/systemd/systemdsymlink? What permissions did the link have? Does it work if you try this instead:sudo ln -s ../lib/systemd/systemd /sbin/init?Arch, it showedERROR: Root device mounted successfully, but /sbin/init does not exist..I did this as root user.ls -l /sbin/initso we can see if there is such a file, if it is a symlink, and what it is pointing to. Al;so tell us if it works if you try my suggestion instead:sudo ln -s ../lib/systemd/systemd /sbin/init/libwhen booting, but the files are made accessible in some other way. I know the symlink on my Arch is pointing to../lib/systemd/systemdwhich suggests they had a good reason to use relative paths. However, someone else will need to explain exactly why one system works this way and the other does not, but they will need to see this info in the question.