Remove the minimal initramfs and make initramfs-extra opt-in
Compare changes
Files
80@@ -3,13 +3,13 @@
@@ -24,6 +24,6 @@ package() {
We previously forked the initramfs into a minimal variant for highly space constrained devices. This was done to allow the normal variant to gain additional functionality like the debug-shell (With OSK). Initially the hope was that only a handful of devices would need the minimal variant, but in practise this has not been the case.
Trying to maintain two diverging forks of the initramfs is absoutely unsustainable and (to be frank) a bit silly.
Based on discussion with @craftyguy and @Newbyte, let's re-architect the initramfs to run in two stages, with the second stage being part of initramfs-extra.
In addition, add support for https://gitlab.com/postmarketOS/postmarketos-mkinitfs/-/merge_requests/48 and set deviceinfo_create_initfs_extra="true" for all the devices that did depend on the minimal initramfs.
This means that the majority of devices (those which aren't using the minimal variant) will no longer depend on the boot partition being discovered and mounted inside the initramfs so that initramfs-extra can be loaded. However, it is still currently necessary to ensure that the boot partition is available because we still support existing installations which don't have a valid /etc/fstab (see #2800, @Newbyte's Librem 5 is an example of this!), and we support the usecase where the boot partition is a subpartition while root isn't (cc @Minecrell). I think we should investigate generating an fstab for the former case, and maybe breaking the latter case to simplify things a bit.
From a high level the initramfs now works as follows:
The new init_2nd.sh script does exactly what the initramfs did before. mount_subpartitions is adjusted to be a nop once the boot and root partitions have been discovered (since it's called twice when deviceinfo_create_initfs_extra is true)
I have tried to split out the functions that are only available in the second stage. It is still necessary to be wary of the two possible contexts we might be running in but for the most part I think this is reasonable to comprehend.
Cc: @jenneron