last day (25 days later) » 

11:22 AM
0
A: btrfs root filesystem on raspbian

PiskvorRaspbian kernel doesn't include support btrfs by default; the initial boot stages run normally, but when the kernel loads, it won't see any filesystem which it could mount - and panics. A solution exists: add btrfs as a kernel module, in initramfs. Largely thanks to three different articles, I ha...

 
With the first sudo apt upgrade if it also upgrade the kernel this setup will fail dramatically on boot because the new kernel tries to load the old initramfs that will fail and the kernel cannot load btrfs drivers. And it is not an easy way to fix it, at least with a chroot on an armhf system.
 
Wouldn't update-initramfs be invoked on kernel upgrade?
...and it will generate a new initramfs, under a different name, which won't match the one in config.txt. Good catch, that was a huge blind spot.
 
No, default Raspbian fails to generate a new initramfs. It isn't configured for this. You always have to monitor with your eyes what apt upgrade is doing and have do generate an initramfs by hand if required - before booting the new kernel. Not a doable task for a beginner because failing it is dramatic. You may have a look at How can I use an init ramdisk (initramfs) on boot up Raspberry Pi?
 
Excellent, thank you; that looks like a good starting point.
 
It has a little bug I have just found but not fixed so far. The kernel supports two models, e.g. 4.14.98+ and 4.14.98-v7+. If update-initramfs is triggered by a kernel update it will generate two initrd.img*, one for each model. This does not fit on the /boot partition (error - out of space) and generation does not finish.
 
11:22 AM
/boot can be resized (impractical) or initramfs generated elsewhere and then copied (the method I use when generating manually - more coding required).
 
Sure, but my goal is to make it running on default Raspbian, flashed from the image. Another way is to configure initramfs-tools just to pack only the needed driver, not all by default. Can be defined in /etc/initramfs-tools/initramfs.conf.
 
MODULES=dep helps, but a) not a lot and b) two initramfs-s still wouldn't fit into my /boot
 
I consider to use MODULES=list.
 
Ah, that would help, too. As for "runs on default" - I guess the easiest way would be to make this into an installable package. Still not entirely out-of-the-box, but could be installed in an unattended way.
 
We are getting more and more of topic so let's continue here. Yes I have thought of an package, or next step: setup a repository ;-)
 
11:35 AM
Sure; a repo would work, even better. As for the script: I think the currenttype="${currentversion: -4}" check breaks on old pis (w/o -v[78]\+). My current version is 4.14.34+ , therefore it would compare on ".34+" and fail to ever generate for any other kernel...
 
 
2 hours later…
1:38 PM
Ok, I made my changes into github.com/Piskvor/custom-rpi-initramfs , with the most relevant commit being github.com/Piskvor/custom-rpi-initramfs/commit/…
That should handle both old, new, and newest RPis now. Still thinking how to do the initramfs-update-too-large thing, and how to handle update-rpi-initramfs if used with -b (not generating into /boot)
 
1:54 PM
OK, will look at your commit but also just testing with: echo "4.14.98+" | grep -P '^\d+\.\d+\.\d+\+$|^\d+\.\d+\.\d+-v[78]\+$'. Then looking for $?
 
That matches, I suppose, but not sure how to switch to "{old/new} kernel" code branch based on this.
 

  last day (25 days later) »