build a fully generic initrd.img without modules
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
Triaged
|
Wishlist
|
Unassigned | ||
initramfs-tools-ubuntu-core (Ubuntu) |
Fix Released
|
Medium
|
Oliver Grawert |
Bug Description
currently our initrd.img on snappy contains modules and is not very generic, this makes porting and maintaining the device tarball harder than it should be, adds massively to the size of the initrd (which the bootloader needs to load into ram during boot, requiring more ram and causing slower boot times if the size is bigger by several megabytes due to the modules) and duplicates the existing modules in the rootfs under /lib/modules.
our initrd should be generic enough that a porter or maintainer of a port does not need to make changes to it for updates of kernel or modules but can just use the binary initrd.img file without modifications.
to not duplicate the modules we should instead ship a "modules.img" file in /boot/$
this has the advantage of having all modules readily available immediately without duplicating any of them and without having to maintain a list of which of them have to be shipped inside the initrd.
once the rootfs partition is mounted the loop mounted img file gets relocated to ${rootmount}
in case we consider making squashfs built into the kernel a requirement, the modules.img file could be a squashfs which could additionally reduce our disk footprint.
implementing the above should only require a few minimal changes to the existing initramfs scripts and some re-consideration of the partition size for /boot (plus some changes to the device-
affects: | livecd-rootfs (Ubuntu) → snappy |
affects: | livecd-rootfs (Ubuntu) → initramfs-tools-ubuntu-core (Ubuntu) |
Changed in snappy: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
affects: | snappy → snapd |
On Sat, Aug 29, 2015 at 08:30:13AM -0000, Oliver Grawert wrote:
> to not duplicate the modules we should instead ship a "modules.img" file bootloader/ a|b/ that the initrd can loop mount on startup.
> in /boot/$
The modules that are shipped in the initramfs are, by definition, those
modules that may be required in order for the kernel to access the root
filesystem. If the modules are not required in order to access the root
filesystem, they should not be included in the initramfs in the first place.
If they *are* required in order to access the root filesystem (in one or
more configurations), then providing these modules in a separate file on the
/boot partition which will be accessed *from the initramfs* is not viable
because the /boot partition is on the same device as the root filesystem and
will require the same drivers in order to access it.
The kernel does support concatenating multiple initramfs into a single
image. This may be a workable option for what you're trying to accomplish.
In any case, the filesystem containing the modules for the initramfs needs
to be loaded by the bootloader, not by the kernel.