Generating images for custom built kernels
firasuke opened this issue · comments
Hey there, I'm trying to use booster to use initramfs images for a custom built kernel that I built, and I wasn't successful...
Does booster support that in the first place? If it does, how can I point it to the custom built kernel and its modules directory?
Thanks!
Yes, booster supports custom kernel versions. If you want to generate an image for a custom kernel then specify its name with booster --kernel-version $mycustomkernel. See man booster for more information.
This assumes that your custom kernel is installed at /usr/lib/modules/$mycustomkernel
I see.
What if the custom kernel modules were located in a different directory? Is it possible to point booster to look for the custom modules in a different directory?
There is no way to build an image for non-installed kernel. You need to install it, /usr/lib/modules/ is where boot system and booster are looking for kernel modules.
To point to another dir you need to modify this variable
booster/generator/generator.go
Line 65 in 8de6af5
I see.
... is where boot system and booster are looking for kernel modules.
I understand that the boot system looks there, but why can't booster be configured with an option to look elsewhere?
why can't booster be configured with an option to look elsewhere?
nobody really asked about such feature.
what is your use-case? why do you need to build an image for a kernel from non-standard location?
nobody really asked about such feature.
That's weird.
what is your use-case? why do you need to build an image for a kernel from non-standard location?
I'm building an initramfs for a cross compiled system. The cross compiled system can't use files from the host system including the kernel and its modules.
I am actually taking my words back. There is a way to build image for a custom kernel. I use it for non-crosscompile setup; it might work for your case as well.
The are 3 booster build flags that help do it:
--init-binary - specifies custom booster init location, in your case it is one compiled for the target platform.
--modules-dir path to compiled modules e.g. /usr/lib/modules/5.19.11-zen1-1-zen/. This flag currently used for testing and is not present at manpage
--kernel-version - kernel version name (e.g. 5.19.11-zen1-1-zen). This valus is checked against booting kernel to avoid any version mismatch.
At this point, the only directory hardcoded in sources is firmware directory, and is currently set to /usr/lib/firmware/. If it needs to be customizable, I can add a flag for it.
That's interesting, thanks for the suggestion!
I'll try it and report my findings.
In addition, you want to use --universal flag to avoid optimization for the current host; and --config to specify a custom config for your target platform.
At this point, the only directory hardcoded in sources is firmware directory, and is currently set to /usr/lib/firmware/. If it needs to be customizable, I can add a flag for it.
This will prove very helpful, can you please add this option as well, as it'll aid in building initramfses for cross compiled systems greatly!
Also, don't forget to update manpage.md to list these new options.
Just tried the options above:
booster build --config booster.yaml --modules-dir ~/cross/usr/lib/modules/5.19.11 --kernel-version 5.19.11 --universal --strip initramfs.img --forceand I'm happy to say that booster is working and I'm considering using it as the default initramfs creation tool for glaucus:
nice! The next step would be building non-universal (i.e. host-specific) image at a glaucus host.
Given that your setup works without the need for a custom firmware directory flag I consider postponing such flag implementation until it is really needed.
Given that your setup works without the need for a custom firmware directory flag I consider postponing such flag implementation until it is really needed.
It would be better to get the firmware done as well, but I guess I can do without it for now, at least on a non-glaucus host.
Leaving this open until the firmware flag is implemented as well.
Thanks for your time and effort!
Closing this, since it is no longer an issue.