sys-kernel/linux-image: support generating initramfs

[PF4Public]

Implementing (someday…) support for generating initramfs in sys-kernel/linux-image would be nice.

[keks24]

@PF4Public
Maybe you can use this? :) https://github.com/keks24/update-initramfs

[PF4Public]

Quite probable! Your script could be a separate ebuild, which could be a conditional build-time dependency for sys-kernel/linux-image.
I'm not using initramfs on my systems however, so I'm not planning on implementing it in an immediate future by myself, but your script looks very… passend, ehm… suitable.

[keks24]

Great idea to create an ebuild out of that!
I actually made a gentoo overlay for the first time recently and my plan is to create an ebuild for torbrowser-launcher-bash.

If you are using Gentoo and your current Kernel directory points to or is /usr/src/linux/, you should be able to use the script update_initramfs out of the box. It is just preparing everything in /usr/src/iniramfs/ and the the compressed cpio gzip archive will be in /usr/src/. The installation itself is intentionally done manually.

In my opinion update-initramfs is not quite finished yet: I am still looking for a decent way to implement graphics drivers, so you do not have to use the EFI driver thingy, which only can provide a resolution of 1024x768.

Hö. Wir könnten uns hier theoretisch auf Deutsch unterhalten und nur wenige Leute würden uns hier verstehen. 😄

[PF4Public]

Great idea to create an ebuild out of that!

And for it to be invoked from another ebuild (like sys-kernel/linux-image for instance) or by end-user, it needs to be modified a bit to become more universal.

If you are using Gentoo and your current Kernel directory points to or is /usr/src/linux/, you should be able to use the script update_initramfs out of the box. It is just preparing everything in /usr/src/iniramfs/ and the the compressed cpio gzip archive will be in /usr/src/. The installation itself is intentionally done manually.

Indeed, that's what I'm writing about. You have a lot of variables hardcoded. So, if I'm using you script to build an initramfs for sys-kernel/linux-image, it might not go well, as portage jails every compilation into a sandbox with limited outside interactions, so the assumption of kernel location in /usr/src/linux would be wrong. Furthermore, due to sandbox restrictions even if one's script does not touch anything outside sandbox, other scripts, that get called, could and most definitely would do so, breaking the compilation in the end. That is actually the reason, why I have to copy sources into the sandbox before compiling kernel.

Hö. Wir könnten uns hier theoretisch auf Deutsch unterhalten und nur wenige Leute würden uns hier verstehen.

… und andere würden sich den Kopf darüber zerbrechen, worum es doch geht. :D Es wäre aber nicht so nett von uns, besonders wenn alle englisch schreiben. ;)

[keks24]

… und andere würden sich den Kopf darüber zerbrechen, worum es doch geht. :D Es wäre aber nicht so nett von uns, besonders wenn alle englisch schreiben. ;)

Yes, let's keep it real. :)

Indeed, that's what I'm writing about. You have a lot of variables hardcoded.

Oh yes, I know what you mean, like having the opportunity to define the compression method and so forth.

So, if I'm using you script to build an initramfs for sys-kernel/linux-image, it might not go well, as portage jails every compilation into a sandbox with limited outside interactions, so the assumption of kernel location in /usr/src/linux would be wrong. Furthermore, due to sandbox restrictions even if one's script does not touch anything outside sandbox, other scripts, that get called, could and most definitely would do so, breaking the compilation in the end. That is actually the reason, why I have to copy sources into the sandbox before compiling kernel.

Yeah, the sandbox. But it has its purpose to not screw things up on the actual filesystem, which is good!

When I get there to create an ebuild, I will see what I have to adapt. I am still new to this topic and I am using your repository as inspiration source already. :D

Alright, I will come back sooner or later about this topic!

-keks24

[PF4Public]

Yeah, the sandbox. But it has its purpose to not screw things up on the actual filesystem, which is good!

Exactly! You either play by the rules, or else need to implement ugly kludges in your code.

inspiration source already

You might also find interesting (and hopefully useful) this ebuild and a corresponding source repository. I mean, for the inspiration purposes, I have no idea, whether those scripts themselves are useful for you.

[PF4Public]

Recently I discovered that with CONFIG_INITRAMFS_SOURCE kernel could create initramfs during the build. I suppose, this could be useful.

The config option CONFIG_INITRAMFS_SOURCE (in General Setup in menuconfig,
and living in usr/Kconfig) can be used to specify a source for the
initramfs archive, which will automatically be incorporated into the
resulting binary. This option can point to an existing gzipped cpio
archive, a directory containing files to be archived, or a text file
specification such as the following example:

dir /dev 755 0 0
nod /dev/console 644 0 0 c 5 1
nod /dev/loop0 644 0 0 b 7 0
dir /bin 755 1000 1000
slink /bin/sh busybox 777 0 0
file /bin/busybox initramfs/busybox 755 0 0
dir /proc 755 0 0
dir /sys 755 0 0
dir /mnt 755 0 0
file /init initramfs/init.sh 755 0 0

I mean, this way kernel compilation and initramfs generation could be separated and not depended on each other.

[keks24]

I mean, this way kernel compilation and initramfs generation could be separated and not depended on each other.

It is actually the opposite. If you specify a gzipped cpio archive file, a directory containing files to be archived or a text file specification, the files must exist before compiling the kernel. So you are giving it an external dependency more or less. Moreover the initramfs will be incorporated into the resulting binary, which I wanted to avoid with update_initramfs.

[PF4Public]

Moreover the initramfs will be incorporated into the resulting binary, which I wanted to avoid with update_initramfs.

Quite reasonable. There must be a configurable option then.

[Techwolf]

sys-kernel/gentoo-kernel::gentoo does build and install the kernel with initramfs USE flag. Can use custom .config if needed.

More info at https://wiki.gentoo.org/wiki/Kernel and https://wiki.gentoo.org/wiki/Project:Distribution_Kernel

I use this as a backup kernel along with my custom config zen kernel that I use all the time.

[PF4Public]

@Techwolf That's right! Unfortunately it cannot build a kernel without loadable modules support and as such I cannot use it.