On Sun, 2017-08-27 at 16:38 -0700, Noah Meyerhans wrote: > On Sat, Aug 26, 2017 at 05:18:45PM +0100, Ben Hutchings wrote: > > > Thomas, can you elaborate why you think this a good idea? Is this about > > > boot time of the kernel image? The thing I really do not want to have is > > > additional kernel source uploads to the archive for just those cloud > > > kernel images, but you already considered that a bad idea (from what I > > > read between your lines). > > > > When the Google Cloud people talked to me about slow booting, it turned > > out that reconfiguring initramfs-tools to MODULES=dep made a big > > improvement. That is likely to be a sensible configuration for most > > cloud images. > > I'm not sure that'll work for us. The image generation is not generally > expected to occur on cloud instances (though in practice it certainly > may). That discussion was about the images provided by Google, not by Debian. You're quite right that it won't be suitable for images that may be built in a different VM configuration. > OTOH, the list of required modules may be small enough for us to > enumerate the ones we need for booting in /etc/initramfs-tools/modules. ...and then you could use MODULES=list. initramfs-tools will still follow module static dependencies in this case. > I will look into this, and we'll see what it does to boot times. Note that the saving will mainly be in time to load the initramfs - which on Google Compute Engine is done through BIOS disk services that have very low performance. The mere presence of the unneeded modules in the initramfs won't cause them to be loaded into the kernel and shouldn't make much difference to the time taken to boot after this point. Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else.
Attachment:
signature.asc
Description: This is a digitally signed message part