Re: Why is /sbin/init dynamically linked?

On Fri, 21 Aug 2026 09:09:14 -0700
Bakul Shah <bakul@iitbombay.org> wrote:

> > 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?

I'd rather ask - why those syscalls are required by init at all? For decades,
init was rock-stable, with as less changes as possible, what happened since
then, in recent times?..

While static /rescue/init can workaround problem, it's still not clear what is
the root cause.

-- 
WBR, @nuclight