Has anyone tried using booster rather than mkinitcpio? I have a use case for nfsroot and overlayfs, so I switched to dracut, and it works as needed. However, it is not exactly designed for Manjaro. Today I discovered booster, which may work for my use case, so I plan to test it out. Anyone have experience with it, good bad or indifferent?
you have a link?
found it:
It is in the official extra repo, at least it is for the arm-unstable branch. What I see looks good, but I wonder about being able to incorporate a sshd server for the remote unlocking of LUKS drives, similar to dracut-sshd-git in the AUR.
yep, it’s in the repo, that’s where i got the link.
i browsed through it, seems like it tries to auto configure, but i’m sure your going to need to tweak the settings.
The initramfs which was created with my first guess at a configuration resulted in a very minimal initramfs that did not lead to a successful boot. And as I expected, is not “arm sbc ready”. I’ll mess around a bit more with it and see if I get anywhere.
I can vary the contents of the initramfs, so that part seems to be functional. However I have not yet been able to get past the init crashing, just after the multi-device raid 5/6 checks:
fatal error: all goroutines are asleep - deadlock
Then a stack dump from main.go with some references to udev, iirc, so it is trying.
Maybe I need more configuration.
Init exits with an exitcode 0x00000200
Edit: I opened this issue.
Edit 2: adding kernel parameters as requested
Edit 3: After rebuilding the kernel to remove the sha2_ce module, it gets further I think, but hangs here:
After a bit more finagling, my system can now successfully boot with booster.
The following works for a btrfs root filesystem (sha2_ce kernel module disabled):
$ cat /etc/booster.yaml
universal: false
modules: kernel/fs/btrfs/btrfs.ko,kernel/drivers/block/zram/zram.ko
compression: zstd
strip: false
mount_timeout: 40s
extra_files: mount,btrfs,zramctl,busybox
vconsole: true
$ cat /boot/grub/grub.cfg (clipped)
menuentry "Manjaro Booster Test" {
echo "Manjaro Booster Test booting..."
insmod part_gpt
insmod btrfs
linux (hd0,gpt3)/@/boot/kernel8.img root=UUID=da0a03c1-016b-4782-824e-fe85ac1642c7 rw rootflags=rw,suid,dev,exec,async,ssd,compress-force=zstd,subvol=@ rootwait snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=0 console=serial0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=serial0,115200 audit=0
initrd (hd0,gpt3)/@/boot/booster.img
boot
}
I have been staring at the modinfo on the sha2_ce & sha256_arm64 and they are a little confusing:
Both have the same alias: except sha2_ce has one more alias: cpu:type:*:feature:*0006*. Also sha2-ce has: depends: sha256-arm64.
Since sha2_ce will not load and sha256_arm64 will on the pi4 it seems to me that sha2_ce is for a certain arm64 board with a cpu that has specific feature looking at the modinfo diff’s:
As I understand it, Armv8 supports several crypto extensions. However, the RPF did not license all of the crypto extensions for the bcm2711. So yes, it likely is needed/useful for other Armv8, but for the RPi4 it does not seem to be supported. This is my guesswork, I have not confirmed it. I did check to see if it is enabled in the 5.12 bcm2711_defconfig, and it is not.
A new wrinkle. I did not know the the linux kernel provided any code for something that had to be licensed.
Licensed, in the sense of the RPF not paying ARM for the rights to include the extensions on the chip.
Here is a thread on the subject.
@Darksky Would you happen to know if your kernel config will boot an ext4 install without the use of an initramfs? Booster needs more time to mature to handle my odd-ball needs. Dracut works but I would not be sad for it to go away, and mkinitcpio can not do what I need.
It just dawned on me, that for my particular use case, an initramfs may not be required and it might be better without… pending testing of course.
It should as I use the RPi deconfig as a base and they do not use initramfs.
If you added a module to the ramfs to boot what you do then all bets are off.
1 Like
Well… there is one module (overlay). But I can test without using it, and if all goes well, maybe I could approach you to consider changing from m to y. I would like for this setup to stay as stock arm-stable as possible… thus the desire to eliminate dracut.
@Darksky My tests this morning were successful, I was able to successfully boot via nfsroot without an initramfs. Now, the question of the overlay module… is this something you would be willing to consider changing from a module to builtin? I do use the linux-rpi kernel for this setup.
$ modinfo overlay
filename: /lib/modules/5.10.36-1-MANJARO-ARM/kernel/fs/overlayfs/overlay.ko
alias: fs-overlay
license: GPL
description: Overlay filesystem
author: Miklos Szeredi <miklos@szeredi.hu>
srcversion: D1ACB53EC29C73AD0FCB32A
depends:
intree: Y
name: overlay
vermagic: 5.10.36-1-MANJARO-ARM SMP preempt mod_unload modversions aarch64
parm: check_copy_up:Obsolete; does nothing
parm: redirect_max:Maximum length of absolute redirect xattr value (ushort)
parm: redirect_dir:Default to on or off for the redirect_dir feature (bool)
parm: redirect_always_follow:Follow redirects even if redirect_dir feature is turned off (bool)
parm: index:Default to on or off for the inodes index feature (bool)
parm: nfs_export:Default to on or off for the NFS export feature (bool)
parm: xino_auto:Auto enable xino feature (bool)
parm: metacopy:Default to on or off for the metadata only copy up feature (bool)
I think it would probably be ok.
Any plans to use the other kernels assuming you meant linux-rpi4 kernel?
They still have not upgraded their kernel tree yet and have no idea when. If you want to test it clone and compile the kernel the same way I showed you before except clone the linux-rpi4 package tree. Make the change in config and generate new md5sums then build the kernel packages:
git clone https://gitlab.manjaro.org/manjaro-arm/packages/core/linux-rpi4.git
cd linux-rpi4
export MAKEFLAGS="-j4"
edit config file with your change
# Generate new md5sum's and build kernel packages and install
makepkg -g >> PKGBUILD
makepkg -siYes, sorry… the linux-rpi4 kernel. Sure, I will be happy to build and test.
For this particular setup, I could maybe bump up to mainline. I see in arm-stable, currently the linux-rpi4-mainline is at 5.12.3-1. How often is the mainline kernel updated in arm-stable? The RC kernel is too risky for this particular setup.
Another thought is usually an overlay file system is archived. If that is the case with your scenario then what ever the overlay is compressed with then whatever is used to compress it needs to be builltin the kernel also.
They are sporadic. I have no idea. lol