-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow to configure Linux kernel image package type #178
Comments
With linux-image-cloud-amd64 we only need ~96MB of disk space, whereas the corresponding linux-image-amd64 takes about 317MB of disk space. Also there's usually no need to install linux-headers and firmware packages inside a VM, so skip those as well. Closes: #178
I like that idea! I just gave it a quick shot (untested!), maybe you wanna test 43406e8 and let me know if that would solve your use case and works as intended? |
Thank you. I am going to test it later. Looking at the implementation, this would make it harder for people wanting to build a virtual machine image for desktop use as most drivers are missing. I would not mind, but it should be properly documented. |
Hm, are "virtual machine images for desktop use" really a thing? :) How's that typically used? (Really wondering about it, because I'm coming mainly from the server side of things) I agree with that this change might be kind of unexpected, and we might consider making it configurable (possibly through a cmdline option) or at least properly document it of course. But the more configuration options we provide, the harder it is to test and makes it less maintainable, so overall I'm very reluctant to make all bits and pieces optional. Furthermore I'd like to have package lists per Debian/release (see e.g. #76), and am wondering which sane defaults users expect for such kind of things, and what customization should be left for further custom/user provided hooks/scripts instead. |
Sorry for the late reply. I can’t remember, what I meant. Probably, that the resulting image is dd’ed to an actual disk. As I built a VM image again with grml-debootstrap, optimizing the boot time, I was hit by this problem again. First I installed tiny-initramfs, but then remembered for an ext4 filesystem I shouldn’t need an initramfs/initrd at all, but this failed as the drivers are not built into the standard Linux kernel image. So it’d be really great to get this patch in. PS: tiny-initramfs currently also fails with:
|
Hm ok, 43406e8 would be need to be rebased on current master. Maybe @adrelanos is already interested in this feature? |
For virtual machine images instead of the standard package linux-image-amd64 the package linux-image-cloud-amd64 with a smaller image and built-in ext4 file system driver to boot without an initrd might be wanted. It’d be great, if that could be configured using an option or the configuration file, so it does not have to be done using the script hooks.
The text was updated successfully, but these errors were encountered: