Re: Why is /sbin/init dynamically linked?

> On Aug 21, 2026, at 8:49 AM, Alan Somers <asomers@freebsd.org> wrote:
> 
> On Fri, Aug 21, 2026 at 9:45 AM Bakul Shah <bakul@iitbombay.org> wrote:
>> 
>> I was surprised to see this:
>> 
>> $ ldd /sbin/init
>> /sbin/init:
>>        libutil.so.10 => /lib/libutil.so.10 (0x3f6d9f550000)
>>        libcrypt.so.5 => /lib/libcrypt.so.5 (0x3f6d9f669000)
>>        libc.so.7 => /lib/libc.so.7 (0x3f6da0c00000)
>>        libmd.so.7 => /lib/libmd.so.7 (0x3f6da01b6000)
>>        libsys.so.7 => /lib/libsys.so.7 (0x3f6da3370000)
>> 
>> Why was this change made? [Seems to be after 15.1-release]
>> 
>> When one of these libraries breaks, you can't even boot
>> single user. In this case why even bother with /rescue.
>> 
>> [Discovered this when init crashed for someone]
> 
> Looks like this:
> https://github.com/freebsd/freebsd-src/commit/24d887436dcd5b6c18a7505e477c79cae3002c3a

from the commit log:

This makes it easier to downgrade kernel when it stops
providing some syscall required by libc. In this case, it is
enough to downgrade libc as well, our crt1 delegates all
non-trivial work to libc::__libc_start1(). With static init,
the /sbin/init should be downgraded as well, which might be
not easy. This does not mean that we support forward
compatibility.

I don't understand what this is trying to say. At any rate how *often*
does a kernel have to be "downgraded" that we are making init more fragile? Why can't the "downgrading" be done by providing a stub
syscall implementation (for a duration) that always returns an error?