Drop GNU's cpio for bsdcpio [provided by libarchive]

[dslm4515]

GNU's cpio was added to MLFS so that an initramfs can be created for system that require an initramfs image for boot.

Since CMLFS installs libarchive [for elftoolchain], bsdcpio is available. Per this issue, bsdcpio can be used as a replacement for cpio.

However, if I decide to drop elftoolchain for elfutils, then GNU's cpio would have to be installed

[takusuman]

Is Heirloom NG's cpio compatible with initramfs or bsdcpio still a best option?

By the way, is initramfs really needed as an outsourced implementation or there's a way to implement it per our own hands and/or not use it?

[dslm4515]

Is Heirloom NG's cpio compatible with initramfs or bsdcpio still a best option?

I still have to test if bsdcpio [both from libarchive/heirloom] will create an image that the kernel can read.

By the way, is initramfs really needed as an outsourced implementation or there's a way to implement it per our own hands and/or not use it?

Yes. I wanted to use the static binaries from s6-portable-utils or heirloom-ng instead of copying dynamic binaries from the newly built util-linux and coreutils... but I still have trouble understanding how to make the initramfs load as root [file system], load any firmwares [like for GPU's] and then switch the root to the real root stored on a storage device.

A lot what I find online mentions dracut or similar scripts provided by distros

[takusuman]

but I still have trouble understanding how to make the initramfs load as root [file system], load any firmwares [like for GPU's] and then switch the root to the real root stored on a storage device.

I will have to study these too, the problem is to find documentation about it.
Most things about UNIX --- not specifically speaking about Linux, but UNIX-compatible in general --- are open on the Internet because of the "hacker culture" created around it, but the question is what to research and where to find.

[takusuman]

Well, per what I understood, dracut is a tool to create an initramfs, it basically tries to avoid hard-coding scripts into the initramfs and uses udev instead. It kind of sounds like a good implementation idea to be honest, but I think I would try to implement a initramfs maker per myself.
There is this relatively small text on kernel.org Documentation, but it had not been updated in a while. https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
It still available at /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.rst.

[takusuman]

I thought about a design that would be nice to try: a stone minimal initrd with only statically link-edited tools from Heirloom NG and util-linux --- I do not know a both better and stable alternative and, since Copacabana makes use of util-linux for mount, fdisk etc, I would not make such a radical change for now --- along with dash at /bin, bootscripts at /sh/bin.
The rest could be done as usual, but the basics would be just a statically linked binaries and simple, human-readable POSIX shell scripts. I think POSIX shell would be obligatory because firing up KornShell 93 would require, besides 1MB of extra space for its binary, reasonably more resources and it would open an enormous margin for bugs to happen because of its completeness as a language.
Honestly, maybe even Google Go-written programs could be better than workaround'ed shell scripts, but it would take a step further. An interesting idea, indisputably.

To be honest, I'm sort of burnt-out with this end of year, so maybe I could be speculating too much beyond what is actually sane to do.

Just an addition: although a minimal environment for the initrd is necessary, I think it is annoying when you update the kernel and accidentally breaks/forgets some file system module, so you get dropped in this sort of environment where your hands are tied. Better safe than sorry, some say, so we could work on an idea --- if it's not on (Clang) Musl-LFS, but as a side note for someone studying this --- to workaround this when you update the kernel. This happens a lot on Slackware, by the way, principally if you're busy with work and mindlessly restarts your machine before an update.

[dslm4515]

but I think I would try to implement a initramfs maker per myself.

I agree. I mean, my mlfs-based projects aren't exactly tailored for new users, so I'm not looking for something fancy like dracut. I even tried to use it.. but never got it working. I couldn't find enough docs for distro devs.. only for users that have dracut installed or packaged by a distro

There is this relatively small text on kernel.org Documentation, but it had not been updated in a while.

Maybe it's just me, but I read that a few years ago and it seemed awfully vague... nor did it not help its not up-to-date

I thought about a design that would be nice to try: a stone minimal initrd with only statically link-edited tools from Heirloom NG and util-linux

Yeah, I started off thinking of using skarnet's s6-portable-utils and build them statically ... with possibly mdev. As means of a real simple initramfs [just load the CPU microcodes, firmwares, and kernel modules], perhaps heirloom-ng and util-linux may not be needed... but for a "rescue" image for troubleshooting, then definitely yes

maybe even Google Go-written programs could be better than workaround'ed shell scripts, but it would take a step further. An interesting idea, indisputably.

Yes. But I have no experience with go... just enough info to build the compiler and some go projects

I think it is annoying when you update the kernel and accidentally breaks/forgets some file system module

Yes. When building MLFS on my chromebook I had issues booting off the emmc or usb storage device. An initramfs would be helpful if it can drop the user to a shell and possible mount the root filesystem somehow or change kernel images.

[dslm4515]

If curious: I don't want to use s6+s6-rc for the initramfs, hah ha.
Simple scripts should be enough.

[dslm4515]

I have documented how to create an initramfs for loading CPU microcode at boot via my BLFS wiki.

I'm now researching GPU firmware loading. Currently, I just bake the firmware in the kernel image.
But its annoying if i accidentally forget a firmware file. For example, I have a Radeon R5 430 GPU. It requires 7 firmware blobs. I forgot to to list the 7th blob in the the kernel config. Now I have to re-compile kernel

[dslm4515]

@takusuman I was thinking, maybe I should create a new repo for building an initramfs... then add it as a submodule [via git] to MLFS & CMLFS, just like my bootscripts for s6+s6-rc. Maybe ...

LIFS = (L)inux (I)nitramfs (F)rom (S)cratch ... i may have to rethink the name if "LIFS" is already taken

[dslm4515]

Just tested initramfs compressed by bsdcpio: kernel can load/use at boot.

I'll test heirloom-ng next

[takusuman]

As means of a real simple initramfs [just load the CPU microcodes, firmwares, and kernel modules], perhaps heirloom-ng and util-linux may not be needed...

Maybe just some small programs of the set.

but for a "rescue" image for troubleshooting, then definitely yes

Sure, but that could be another entry on GRUB/Limine.

Yes. But I have no experience with go...

I have a little, but I could try to write something with it with some effort.

An initramfs would be helpful if it can drop the user to a shell and possible mount the root filesystem somehow or change kernel images.

I have never figured out how to do it, usually I would chroot on it and regenerate the initrd. 😅
Maybe writing some documentation for this could be enriching for the project as a whole.

[takusuman]

I was thinking, maybe I should create a new repo for building an initramfs... then add it as a submodule [via git] to MLFS & CMLFS, just like my bootscripts for s6+s6-rc.

That is for sure a good idea, I can help designing it if needed.

[takusuman]

Just tested initramfs compressed by bsdcpio: kernel can load/use at boot.

I'll test heirloom-ng next

Great, I will wait for the results.

By the way, I wish a Merry Christmas for you and other contributors in this project.

[dslm4515]

Turns out my custom initramfs with busybox causes problems with my bootscripts.

Initially, the initramfs had the init script in /sbin instead at the root, so kernel never executed the init script.
After I moved the init script to the root of the initramfs, that is when issues popped up... such as empty /dev after system switches roots (from initramfs to real mounted root)