1

I am learning Linux. For testing whether kernel will invoke init through boot process, I did:

sudo rm /sbin/init 

and rebooted. As I expected, Ubuntu was not able to boot successfully since /sbin/init didn't exist. Then, to fix it, I used a bootable usb to mount, chroot...finally re-symbol-linked it:

ln -s /lib/systemd/systemd /sbin/init 

rebooted...My Ubuntu boot successfully again.

But, It doesn't work in Arch by the same way above. How to explain this ? (Arch and Ubuntu both use systemd as init, and I install them in only one partition separately.)

(After removing /sbin/init in Arch, it showed ERROR: Root device mounted successfully, but /sbin/init does not exist. I did it as root)

SOLVE: In Arch

ln -s ../lib/systemd/systemd /sbin/init 

(Thank terdon ♦)

10
  • What happened when you tried this with Arch? What errors did you get? Also, what user ran the ln command? Did you confirm that after the ln you had a /sbin/init -> ../lib/systemd/systemd symlink? What permissions did the link have? Does it work if you try this instead: sudo ln -s ../lib/systemd/systemd /sbin/init? Commented Jul 28, 2021 at 17:07
  • After removing /sbin/init in Arch, it showed ERROR: Root device mounted successfully, but /sbin/init does not exist. .I did this as root user. Commented Jul 28, 2021 at 17:11
  • OK. Please edit your question and include that (we always need to know the exact errors). Then also show us the output of ls -l /sbin/init so 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 Commented Jul 28, 2021 at 17:14
  • Oh. Your method works. But how to explain this? Commented Jul 28, 2021 at 17:42
  • Please edit all this into your question. I can guess the reason, but I don't know enough about how systemd works to be sure. My guess is that it isn't actually mounted under /lib when booting, but the files are made accessible in some other way. I know the symlink on my Arch is pointing to ../lib/systemd/systemd which 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. Commented Jul 28, 2021 at 18:02

1 Answer 1

1

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.

1
  • The links are very helpful since I didn't know these details of Arch boot. Thanks. Commented Jul 30, 2021 at 2:45

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.