Le 17/01/2023 à 16:38, Didier Kryn a écrit :
> Le 17/01/2023 à 14:34, ael via Dng a écrit :
>> On Tue, Jan 17, 2023 at 10:12:23AM +0100, marc wrote:
>>> And here is where the "re-invent it poorly" comes in: Linux
>>> has shifted some of this work into the initrd or initramfs. My
>>> view is that the initramfs is a mess:
>>>
>>> - it differs between distributions
>>> - it is brittle to update (a complex build tool is needed)
>>> - it is redundant (needs to copy loads of files around. Maybe
>>> not an issue on the 100TB system you have, but the smartwatch or
>>> smartbulb builder might see it differently)
>>> - configurations are duplicated, hardcoded or non-obvious.
>>> - it is opaque - not easy to look in to with ls.
>>> - its system recovery utilities are deficient
>>> - as are the interactive tools
>> This is probably drifting somewhat from the (/,/usr) topic,
>> but I have one problem with eliminating initramfs: CPU firmware
>> update. I much prefer to avoid initramfs, and always used to
>> compile my own kernels with the necessary 'boot' modules installed.
>> But then there seems to be no easy way to patch the CPU firmware
>> which is needed not least for security: you need to reboot with the
>> new firmware runing, and initramfs is the simplest existing way to achieve that.
>>
>> I posted much the same comment on this list long ago and had no
>> reaction.
>>
>> Are people not risking security, not to mention performance and maybe
>> bugs if you don't use initramfs or something else to update the firmware?
>>
>> What am I missing? Is there a way to update CPU firwmare on the fly?
>>
>> ael
>
> Managing the early init is certainly something you can do. It
> means that you keep using Devuan and its package management for all
> the system but for the init stage: you do not install the kernel image
> and the Grub package; you need to compile both on your own from source.
>
> The process is the following:
>
> 1) create a filesystem and build a FSH in your future / partition
> with all the utilities needed to boot eg Busybox
>
> 2) write a script named /sbin/init which will perform the tasks
> explained below
>
> 3) compile your kernel with the drivers you need to mount the root
> partition
>
> 4) install your kernel in /boot of your new partition, and the
> collection of modules in /lib
>
> 5) chroot into the new partition and perform the steps necessary
> to install Grub on the MBR of the disk
>
> 6) install the debootstrap package on your host and use it to
> perform the initial installation of Devuan on your target / or just
> install the executable in the target, to invoke it later from your new
> system.
>
> The init script must perform a number of task to reach the status
> that the Devuan init expects to find:
>
> mount /proc, /sys and /dev
> execute a hotplugger, eg mdev
> create a mountpoint for your target root partition eg /mnt
> mount your target root partition on /mnt
> mount /mnt/proc, /mnt/sys, /mnt/dev /mnt/dev/pts with the proper
> filesystems (proc, sysfs, devtmpfs, devpts)
> create /run and eventualy some symlinks from /etc to files/dirs in
> /run (I don't remember which)
> then enter an interactive session.
> try 'exec switch-root /mnt /usr/sbin/init' . Don't forget "exec"
> because only pid1 can switch-root.
> If it fails, it means you or/and I have forgotten something
>
> When it all works, include the switch-root command into your script.
>
> You can then complete the installation of your Devuan system - I
> think at least apt-get is available at this stage. Install all you
> need but the linux-image and Grub packages: these packages *must not
> be installed*. You don't need to often update kernel because updates
> are mostly bug corrections. Rebuilding the kernel is essentially
> needed when changing release. It takes some learning but it is all
> manageable.
>
CAVEAT: you don't need to mount anything on /mnt: it's already the
root partition, and you don't need switch-root, just
'exec /usr/sbin/init'. What I wrote is what you do in the initramfs.