:: Re: [DNG] Avoid the merge
Góra strony
Delete this message
Reply to this message
Autor: Didier Kryn
Data:  
Dla: dng
Temat: Re: [DNG] Avoid the merge
Le 13/12/2022 à 16:28, Steve Litt a écrit :
> Didier Kryn said on Tue, 13 Dec 2022 12:33:53 +0100
>
>> Le 12/12/2022 à 23:09, Steve Litt a écrit :
>>> I agree. Not all of us want to use an initramfs. The traditional Unix
>>> way enables one to boot using only a few static programs.
>>     Hi Steve. You should specify what you mean by "static" because
>> one
>> common understanding is "statically linked". Linux distros based on
>> statically linked programs are seldom. Actually I don't know any one.
> I meant statically linked. If you can only open your root partition at
> the start, executables can't depend on loadable libraries. I'm pretty
> sure that "sbin" originally stood for "static binaries".


    'file /sbin/* | grep statically'

>
>>     In /lib, you always find the dynamic libc and the dynamic linker
>> and this allows the whole distro, including init itself to be
>> dynamically linked.
> Putting the libs in /lib is another good way to enable boot before any
> mounts have been completed. And it's probably what's always done today.
>
>> There are no static programs in /bin and /sbin in
>> Debian/Devuan. There might be a few ones in the whole distro,
>> including the dynamic linker itself because of a chicken-and-egg
>> issue. With the merge, all of this goes to /usr of course.
>>
>>     It is possible to build a statically linked  installation
>> compiled
> >from source. It may be convenient for a server with limited
>> functionality but is not easily maintainable.
>>
>>     For what concerns initramfs, it is mandatory because the kernel
>> does not contain the drivers needed to mount the root filesystem (and
>> /usr in case of merge).
> I think it's a shame most distros don't compile the Ext4 driver and
> maybe zfs and a few other common ones into the kernel, so an initramfs
> isn't necessary for simple setups. This is how most distros were set up
> around the turn of the century.

    This is a matter of preferences and you know that the
implementation of ZFS on Linux is "suboptimal" (~:
>
>> I think initramfs and the merge are unrelated
>> questions. Initramfs just hides part of the init work under the hood.
> Hides is a good word for it. It's hard to get a test probe in there to
> troubleshoot early boot problems. Anyway, my point is this: If all
> executables such as the mount command and all the libraries are under
> /usr, and /usr is its own partition, then you're FORCED to have an
> initrams, no matter what drivers you compile into the kernel.


    These executables of /bin, /sbin and /usr are not available when
the init starts in the initramfs. You could as well run this init or
your own script in the root filesystem if it was mounted; you just need
a statically-linked version of Busybox, the same which is in the
initramfs. Busybox contains all the executable you need plus the shell
interpreter. As I said, initramfs hides it, but it also can run without
any mounted filesystem, which is why distros like it - they don't hide
it gratuitously.

    You can do it yourself. You first need to recompile the kernel with
the drivers for SATA, SCSI, and EXT4 statically linked. Then build
Busybox and work out your init script. And at the end of your script,
you exec the Devuan init. You can arrange your script to enter an
interactive session in case of failure; Busybox is then your friend: it
is a comprehensive Linux base system.

--     Didier