On Tue, Apr 13, 2021 at 11:36:11AM +0200, Bastian Blank wrote: > > > Where was that discussed? > > It was discussed in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947759 > > , with responses from both Ben and Noah. > > As this is incomplete at best, I intend to revert that change. > > Otherwise it at least needs in addition: > - hyperv pci support (for nvme), > - hyperv block and > - virtio-scsi. This should probably be discussed in depth outside of this bug, but I do not think this is the right approach. The kernel config changes have been in place for over a year, and were merged only after discussion both on salsa and the BTS. They accomplish the desired effect, which is to allow the cloud kernel to boot without an initrd on common cloud instance types (specifically AWS Nitro instance types). While this is not the default behavior for any of our cloud images, it is simple for users to enable it on derivative images if they can benefit from the reduced boot time. If we want to support initrd-less booting on instances aside from Nitro instance types, that's great, and we should consider doing that. That would be much more beneficial to our users than reverting the change. > However this bug is about dhcp support. If there is no network device > support available, how does it do dhcp? I'd also argue that NIC drivers (in particular ena.ko, used on Nitro instances) should be left configured as modules, even if we do want to support initrd-less booting. AWS publishes an out-of-tree variant of the ENA driver that may be ahead of what's in the stable kernel tree, and some users may have a need to run that. noah
Attachment:
signature.asc
Description: PGP signature