User:Pietinger/temp/delete me

@vaukai: please delete this post after use

Some thoughts about

INITRAMFS:

A) WHY ?

Advantage: Because you can do things (at boot-time) a kernel is not able to do. => Give later a LINK to some ot these "Solutions"

Disadvantage: Now you MUST mount root partition within this initramfs because kernel will not do this job anymore.

B) Type of initramfs:

B1) Embedded = built-in into kernel image = result is one bzImage containg kernel itself AND content of initramfs

Advantage: Very easy to build IF user has access to kernel configuratiion.

Disadvantage: If you want change something in your initramfs you must compile the kernel again

B2) external CPIO archive = bzImage is "only" kernel AND you have an additional file containg only initramfs

Advantage: You can change/update to other kernel versions without needing compiling kernel again (if you can use the initramfs for many different kernel versions). Used in binary distributions OR in Linux-Boot-CD.

Disadvantage: You must configure one additional kernel parameter (initrd=)

C) How to build them ?

In every case an INIT file is needed. This can be a compiled C-program or a compiled assembler program (hihi), BUT in MOST cases it is a shell-script OR a busybox-shell-script ! Examples of some INIT files you will find in LINK FROM ABOVE. If it is a busybox-shell-script you will need (in every case) of course sys-apps/busybox (independend if you want an embedded initramfs or an external CPIO archive).

In every case you will need this kernel option:

CONFIG_BLK_DEV_INITRD=y

In every case you need some additional files OR a file-list. What you will need is explained in LINK FROM ABOVE.

C1) Building an embedded initramfs

Here you have (mainly) two ways to go - I begin with the EASIEST method:

C1a) Building an embedded initramfs with a file-list:

Just tell the kernel where to find this file-list AND then compile kernel with "make". This "make" does all automatically. Examples of these file-lists are in LINK FROM ABOVE.

You will need this (additionally) kernel options to do this:

CONFIG_INITRAMFS_SOURCE="/WHAT/YOU/LIKE/anynameyoulike"

In most articles this is used:

CONFIG_INITRAMFS_SOURCE="/usr/src/initramfs/initramfs_list"

C1b) Building an embedded initramfs with a directory where all needed files are copied in there:

Do a "mkdir /WHAT/YOU/LIKE" and copy all needed files directly in there. Then tell kernel to include the content of this directory (as initrmafs) with these kernel options:

CONFIG_INITRAMFS_SOURCE="/WHAT/YOU/LIKE/"

You see the difference to C1a, do you ?

C1c) Building an embedded initramfs with a given CPIO archive (SELDOM used):

You have already an (external) CPIO archive, but you want an embedded solution:

Tell Kernel where to find this CPIO. It will be included after you compile kernel again with "make":

CONFIG_INITRAMFS_SOURCE="/PATH/TO/MY/myinitramfs.cpio"

OR

CONFIG_INITRAMFS_SOURCE="/PATH/TO/MY/myinitramfs.cpio.gz"

It is important to use suffix .cpio so "make" understand it is a CPIO file !

It is important to use suffix .cpio.gz so "make" understand it is an already gzipped CPIO file !

(both is explained in /usr/src/linux/usr/Makefile )

Of course you need for the 2nd case two kernel options (which are usually ENABLED by default; just check it):

[*]  Support initial ramdisk/ramfs compressed using gzip

Built-in initramfs compression mode (Gzip) --->

C2) Building an external CPIO

Name of this CPIO archive can be WHATEVERYOUWANT.WITHORWITHOUTANYSUFFIX ... but you MUST tell kernel later with "initrd=..." this name AND where to find. Example: initrd=/boot/initrd.cpio.gz

C21) Building an external CPIO with a file-list

Description is in Early_Userspace_Mounting

=> compiling manually gen_init_cpio + run manually usr/gen_initramfs.sh + optionally: compressing manually with gzip

Result is an external CPIO archive ... you COULD ... if you want ... also embedd with C1c ... hihi ;-)

C22) Building an external CPIO with a given Directory (where all files are copied in)

Description is here: Custom_Initramfs

=> packing manually Directory into a CPIO archive with:

find. -print0 | cpio --null --create --verbose --format=newc > /boot/custom-initramfs.cpio

OR, IF you want to compress it:

find. -print0 | cpio --null --create --verbose --format=newc | gzip --best > /boot/custom-initramfs.cpio.gz

(Of course you then will need both kernel options for GZIP; see above in C1c)

Some informations about stub kernel, initramfs and kernel command line paramter root=

1. You can have a "normal" kernel wihtout an initramfs. For this you must configure the kernel manually and configure all what kernel needs to find its root partition into kernel. This is the default when working with our AMD64 handbook: Handbook:AMD64/Installation/Kernel

This kernel needs a bootloader / bootmanager (grub is both).

1.a You can use grub (or others)

OR

1.b You have an UEFI system and want that UEFI boots direct kernel without using any bootloader. Then you must configure this kernel as a STUB kernel

(dont forget: grub CAN start a stub kernel ALSO; but this is solution 1a and NOT 1b; because grub is involved)

In both sitations kernel needs information WHERE to find its root partition. You have two choices for both situation:

1.a.1: grub gives this information to kernel

1.a.2: You do "hardcode" this INTO the kernel in "BUILT-IN Kernel Command Line" WITH: root=/dev/sdXY OR root=PARTUUID=...

1.b.1: You do "hardcode" this INTO the kernel in "BUILT-IN Kernel Command Line" WITH: root=/dev/sdXY OR root=PARTUUID=...

1.b.2: You configure UEFI to give this information to kernel (seldom; because some UEFI are not capable for this) But if used we need also: root=/dev/sdXY OR root=PARTUUID=...

2. You can use an initramfs doing some stuff.

Here we have two choices:

B.1. It is embedded INTO the kernel

This is easier, because the Kernel needs only information about root partition (same as always).

B.2. It is an external CPIO archiv

Here Kernel needs information about root partition AND where to find this external CPIO archiv !!!

What an initramfs ALWAYS MUST do is: Mounting the root partition ! Because: As soon as kernel knows we have an initramfs THEN kernel will NOT mount the root partition; it is the job of initramfs now. So, now, it depends HOW intitramfs is programmed to find our root partition:

In every case you can use root=/dev/sdXY ... This will ALWAYS work ... but it is not recommended (because you can have troubles when you have accicently an USB stick in your computer).

a) If this script uses external mount command, then it is able to use also root=PARTUUID=... (because "normal" mount command understand this).

b) If this script uses internal mount command from busybox, then you can use only additionally root=LABEL=... OR root=UUID=... (Tested with busybox version 1.34.1)

In this script Early_Userspace_Mounting internal mount command from busybox is used, and it would fail if you use root=PARTUUID=...

(Maybe our gen-kernel uses normal mount command is therefore able to use root=PARTUUID=...; this I dont know)

Now lets combine 1 and 2:

B.1.a.1: Grub gives kernel command line to initramfs (via kernel; kernel gives information to initramfs)

B.1.a.2: You do "hardcode" this INTO the kernel in "BUILT-IN Kernel Command Line" WITH: root=/dev/sdXY OR root=LABEL=... OR root=UUID=..

B.1.b.1: You do "hardcode" this INTO the kernel in "BUILT-IN Kernel Command Line" WITH: root=/dev/sdXY OR root=LABEL=... OR root=UUID=..

B.1.b.2: You configure UEFI to give this information to kernel (seldom; because some UEFI are not capable for this) also root=/dev/sdXY OR root=LABEL=... OR root=UUID=...

Now it goes crazy, because we have two informations for kernel: Where is root partition ? And: Where is external CPIO archiv ? Why it is crazy ? Because you can "put" one information in grub / UEFI and the other information in BUILT-IN kernel command line .... hahaha ....

B.2.a.1: grub gives both informations to kernel (root= initrd=)

B.2.a.2: grub gives only where to find root; initrd= is in builtin kernel command line

B.2.a.3: grub gives info about external CPIO; root= is in builtin kernel command line

B.2.a.4: Both informations are in builtin kernel command line (root= initrd=)

For B.2.b.1 until B.2.b.4 it is the same; just replace grub with UEFI

Now what is described in EFI_stub ?

This line:

efibootmgr --create --part 1 --disk /dev/sda --label "Gentoo" --loader '\efi\gentoo\bzImage-4.9.76-r1.efi' -u 'initrd=\efi\gentoo\initramfs.img'

tell us there is an external CPIO (so its clearly B.2) but there is no "root=", so it is B.2.b.3:

- external CPIO

- Stub kernel

- UEFI gives info about external CPIO

- root= is in builtin kernel command lin

If you dont like so a "mixed" solution, you can also use a B.2.b.1 solution (UEFI gives both to kernel):

efibootmgr --create --part 1 --disk /dev/sda --label "Gentoo" --loader '\efi\gentoo\bzImage-4.9.76-r1.efi' -u 'initrd=\efi\gentoo\initramfs.img root=UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'

OR

a B.2.b.4 solution (both is in builtin kernel command line):

[*] Built-in kernel command line

(root=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx initrd=\efi\gentoo\initramfs.img) Built-in kernel command string

If we now would do an embedded initramfs (instead an external CPIO), then we would not need the initrd= parameter and then we would have only B.1.b.1 or B.1.b.2 as choice.

Late edit: Another example is our bin-kernel ...

In EFI_stub it is said to use this (because user can not edit kernel config = builtin kernel command line):

efibootmgr -c -L "Gentoo Linux" -l '\EFI\Gentoo\bootx64.efi' -u 'root=PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX'

This means it is either a B.1.b.2 solution OR a B.2.b.2 solution (I really dont know if bin-kernel uses an external initramfs or a builtin)