Re: Rawhide and debug kernels
On Wed, Jan 18, 2023 at 12:04:41PM -0600, Justin Forbes wrote: > For a *very* long time, Rawhide has built rcX kernels as "release" > kernels and daily git snapshots as debug kernels only. This has > brought attention to some issues that might otherwise be missed. > Specifically around things like lockdep. Unfortunately, even without > changing our selected debug options, performance has gotten > considerably worse for these debug kernels due to upstream code > changes. At the same time, we do have some additional automated > testing happening now that was not happening before, which we can > explicitly point at debug kernels. I am wondering if it is time to > switch rawhide to work the way that everything else does, building > both debug and nodebug builds every day, instead of forcing debug > builds 80% of the time. It would mean a reduction in coverage, but I > am not sure by how much, as I get the impression that most rawhide > users are sticking to the nodebug kernels anyway. It would also > allow us to turn on some more debug features for our debug kernels > that are a bit more performance limiting, but extremely useful. We > have left them off in Fedora specifically because they were too heavy > weight for expecting users to run them. > > So, what does the community think? Should we continue as is, or should > we move to a more typical model where both debug and non-debug kernels > are build with every build? If Rawhide is to maximise its usefulness as a distro you can actually run tests on, then its functional behaviour and operation needs to be on a par with the final released distro will have. With the debug kernels provided by default for most of the rawhide cycle, this goal is not achievable today. Having debug kernels available for testing is a good idea, and we could encourage users to try them. I think it is undesirable to force the debug builds onto every install by default though, because their operational behaviour (mostly in terms of performance) is not a match for what will actually be shipped. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Thu, Dec 08, 2022 at 07:59:20PM +0100, drago01 wrote: > On Thursday, December 8, 2022, Adam Williamson > wrote: > > > On Thu, 2022-12-08 at 12:58 +, Peter Robinson wrote: > > > > > > I've done a few passes, dropping a bunch of older firmware upstream > > > that are no longer supported in any stable kernel release, also a > > > bunch of de-dupe and linking of files rather than shipping of multiple > > > copies of the same firmware. It's improved things a bit, unfortunately > > > a lot of the dead firmware was tiny compared to say average modern > > > devices like GPUs or WiFI. > > > > > > The problem with a lot of the firmware, and with the new nvidia "open > > > driver" which shoves a lot of stuff into firmware in order to have an > > > upstreamable driver apparently the firmwares there are going to be > > > 30+Mb each, is that they're needed to bring up graphics/network etc to > > > even just install so I don't know how we can get around this and still > > > have a device work enough to be able to install the needed firmware > > > across the network. > > > > > > Ideas on how to solve that problem welcome. > > > > Sorry if this is way off, but - do we need the GPU firmwares to run a > > graphical install on the fallback path, just using the framebuffer set > > up by the firmware? How crazy would it be to just do that - ship the > > installer env with no GPU firmware? > > > That would be very crazy, as you will have a degraded user experience > (laggy UI, wrong resolution, ...) to save a couple of megabytes that are a > non issue for today's hardware. Please bear in mind the difference between bare metal and virtual machines. The bare metal machine may have 32 GB of RAM, making a 800 MB install image a non-issue. For a public cloud virtual machine though, this could bump your VM sizing up 1 level from 2 GB quota to a 4 GB RAM quota, with correspondingly higher price point. Now most people probably don't run the installer in a public cloud, preferring pre-built disk images. Even in a local machine though, you may be using most of your 32 GB of RAM for other things (well firefox/chrome), so allowing extra for the VM is not without resource cost. If we could figure out a way to knock a few 100 MB off the installer RAM requirements that is valuable. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Small rant: installer environment size
On Wed, Dec 07, 2022 at 04:42:05PM -0800, Adam Williamson wrote: > Hi folks! Today I woke up and found > https://bugzilla.redhat.com/show_bug.cgi?id=2151495 , which diverted me > down a bit of an "installer environment size" rabbit hole. snip > Why does this matter? Well, the images being large is moderately > annoying in itself just in terms of transfer times and so on. But more > importantly, AIUI at least, the entire installer environment is loaded > into RAM at startup - it kinda has to be, we don't have anywhere else > to put it. The bigger it is, the more RAM you need to install Fedora. > The size of the installer environment (for which the size of the > network install image is more or less a perfect proxy) is one of the > two key factors in this, the other being how much RAM DNF uses during > package install. Is there something that can be done to optimize the RAM usage, in spite of the large installer env size ? If we're installing off DVD media, it shouldn't be required to pull all of the content into RAM, since it can be fetched on demand from the media. IOW, 99% of the firmware never need leave the ISO, so shouldn't matter if firmware is GBs in size [1] if we never load it off the media. Same for languages, only the one we actually want to use should ever get into RAM. If we're installing off a network source, we need to pull content into RAM, but that doesn't mean we should pull everything in at once upfront. Is it possible to delay pulling in non-NIC firmware until we have a NIC configured, and just rely on the basic generic framebuffer setup by UEFI/BIOS until we get far enugh to pull in video card firmware ? For localization, is it possible to split the localization into per-language bundles, and delay loading off the network until we know what language we want to load, instead of pre-loading all languages ? With regards, Daniel [1] Yes, I know it matters for user media download size in reality -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
On Tue, Sep 20, 2022 at 03:05:17PM +0200, Gerd Hoffmann wrote: > On Fri, Sep 02, 2022 at 12:07:38PM +0100, Daniel P. Berrangé wrote: > > On Fri, Sep 02, 2022 at 11:21:03AM +0200, Gerd Hoffmann wrote: > > > Hi, > > > > > > > Thus my patch proposed two images, to be distributed in the same > > > > 'kernel-virt-unified' sub-RPM. > > > > > > > > * vmlinuz-virt.efi created using dracut arg > > > > > > > > --kernel-cmdline 'console=ttyS0 console=tty0 quiet rhgb' > > > > > > > > * vmlinuz-virt-verbose.efi created using dracut arg > > > > > > > > --kernel-cmdline 'console=ttyS0 console=tty0' > > > > > > Hmm, I think we should look for a more elegant solution to this problem > > > than having two large, 99% identical images. > > > > > > One option could be to have systemd-stub support multiple .cmdline > > > sections and allowing the user to pick one of them. > > > > > > Another option could be to have a whitelist of options the user is > > > allowed to add/remove which then could include stuff like 'console=' > > > and 'quiet'. > > > > FYI, I filed an RFE with systemd to get their opinion on the idea > > of alternative cmdline entries, and/or validated option lists: > > > > https://github.com/systemd/systemd/issues/24539 > > So, how move forward with this best? Drop the verbose variant for now, > add support for that once systemd-stub support for multiple command > lines is sorted upstream? > > Should we have a Fedora feature page for unified kernel support? I'm not sure we especially want to publicise unified kernel images as a standalone thing to users, as it is more of just a building block. If we're going to show any "feature", I think it probably ought to be oriented around a higher level user solution, of which unified kernel images are just one piece of the puzzle. eg I would see "Trusted boot for cloud images" as a feature, by which I mean publishing cloud images capable of using SecureBoot and vTPM, to do attestable boot on UEFI, without the unsigned initrd hole present as today. So, this would mean uing unified kernel images, either directly launched from shim, or with sd-boot in there to provide a UI selection. Either way not grub, since it is impractical to do attestation with grub's use of PCRs. Also likely mean use of discoverable partitions. I know there's been some desire to move Fedora cloud images to be UEFI only, so it might dovetail with that to some degree. It would likely touch kernel, anaconda, systemd and cloud images, so there's some coordination & discussion needed to agree on the big picture. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
On Wed, Aug 31, 2022 at 02:46:15PM +0200, Gerd Hoffmann wrote:
> Hi,
>
> Here is a little patch series to kick off a discussion on pre-generated
> initrd images and unified kernels. Lets start with a description of the
> patches:
>
> Patch #1 adds a dracut config file, targeting virtual machines. Given
> that most physical machines have either sata or nvme disks these days
> it probably boots most physical systems too.
>
> Patch #2 adds a sub-package with an initrd image.
>
> Patch #3 adds a sub-package with an unified kernel.
I was going to open a merge request in Pagure which just has one
patch doing #1 & #3 at the same time, but since you've started the
discussion here, I'll just point to my branch:
https://src.fedoraproject.org/fork/berrange/rpms/kernel/commits/unified-kernel
with latest commit at time of writing being:
https://src.fedoraproject.org/fork/berrange/rpms/kernel/c/b055ea3932e48fff0dc73647cb0a62e26db13482?branch=unified-kernel
And builds available at
https://koji.fedoraproject.org/koji/taskinfo?taskID=91495327
https://copr.fedorainfracloud.org/coprs/berrange/efi-unified-kernel/builds/
Compared to the patch #3 Gerd included, I've made changes
- Added support for signing of the EFI images create
- Create both vmlinux-virt.efi and vilinuz-virt-verbose.efi
the latter whose cmdline is tailored for debugging
- Install %ghost files at /boot/efi/EFI/Linux, similar to
how existing kernels %ghost /boot/, so that RPM can
validate disk space availability prior to install
> The goal is to move away from initrd images being generated on the
> installed machine. They are generated while building the kernel package
> instead. Main motivation for this move is to make the distro more
> robust and more secure.
More specifically with public clouds most of the big vendors
have a so called "Trusted VM" option which exposes EFI and vTPM,
and allows for remote attestation of the VM. Azure at least has
the attestation service integrated into their portal.
The RHEL images we provide for cloud today can be luacnhced in a
"Trusted VM" setup, but there's no usable trust provided because
the dynamically generated initrd and cmdline are impractical to
attest to. This is further compounded by grub's practice of
writing every single grub.conf statement into the PCRs, which
effectively requires a grub simulator to validate.
More recently clouds have started to work on "Confidential VMs",
which have a fairly high level of overlap with "Trusted VMs" in
terms of what needs to be done to attest the confidentiality of
the boot process. So again we need to measure and attest thue
initrd + cmdline, and any bootloader config.
This is a long winded way of saying that the need for EFI unified
kernel images is just one piece of the puzzle we're working on.
To complement this we'll be looking for either having shim directly
launch the kernel image, or request for sd-boot to be signed and
use that, in both cases eliminating use of grub to simplify the
meausrement+attestation problem significantly.
It is also likely that we'll be looking to make use of things like
the kernel IMA framework to measure+attest to various aspects of
the cloud disk and OS state.
> When shipping the initrd as rpm it is possible to check it with the
> usual tools ('rpm --verify' for example). TPM measurements are much
> more useful because it is possible to pre-calculate the PCR values for a
> given kernel version.
>
> When shipping a unified kernel image (containing kernel, initrd, cmdline
> and signature) we get the additional benefit that the initrd is covered
> by the signature so secure boot will actually be secure.
>
> So, while unified kernels are clearly the better approach it is also the
> one which needs some changes in various packages. For an initrd image
> the hooks needed are in place thanks to CoreOS shipping initrd images
> today. Opt-in by install the sub-rpm and everything JustWorks[tm].
>
> To make unified kernels work smoothly a number of changes are needed
> (beside the kernel rpm changes):
>
> (1) Add support for unified kernels to the kernel update scripts.
> (/usr/lib/kernel/install.d/*).
>
> (2) Add boot loader support for unified kernel images:
> (a) either switch to sd-boot which already supports this.
> (b) or add support to grub2 (improve blscfg downstream patch).
>
> (3) Support /boot being vfat (depending on #2, sd-boot needs this).
Technically in the cloud image scenario we don't need to especially
care about /boot being a dedicated partition. We could do everything
exclusively in the /boot/efi partition which is already vfat, and not
bother creating any /boot partition, since we can ensure /boot/efi is
large enough.
If we forsee the unified EFI kenrels being useful for bare metal,
however, then use of /boot as vfat becomes more important, as we
can't assume the hardware vendor's pre-created /boot/efi is
sufficiently large.
> (4) Remove
Re: [PATCH 0/3] pre-generated initrd and unified kernels
On Fri, Sep 02, 2022 at 11:21:03AM +0200, Gerd Hoffmann wrote: > Hi, > > > Thus my patch proposed two images, to be distributed in the same > > 'kernel-virt-unified' sub-RPM. > > > > * vmlinuz-virt.efi created using dracut arg > > > > --kernel-cmdline 'console=ttyS0 console=tty0 quiet rhgb' > > > > * vmlinuz-virt-verbose.efi created using dracut arg > > > > --kernel-cmdline 'console=ttyS0 console=tty0' > > Hmm, I think we should look for a more elegant solution to this problem > than having two large, 99% identical images. > > One option could be to have systemd-stub support multiple .cmdline > sections and allowing the user to pick one of them. > > Another option could be to have a whitelist of options the user is > allowed to add/remove which then could include stuff like 'console=' > and 'quiet'. FYI, I filed an RFE with systemd to get their opinion on the idea of alternative cmdline entries, and/or validated option lists: https://github.com/systemd/systemd/issues/24539 With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
Incidentally if anyone reading is a moderator for this mailing list, the message Gerd is replying to appears still pending in the moderation queue as the list didn't allow non-members to post... On Fri, Sep 02, 2022 at 10:40:41AM +0100, Daniel P. Berrangé wrote: > On Fri, Sep 02, 2022 at 11:21:03AM +0200, Gerd Hoffmann wrote: > > Hi, > > > > > > (3) Support /boot being vfat (depending on #2, sd-boot needs this). > > > > > > Technically in the cloud image scenario we don't need to especially > > > care about /boot being a dedicated partition. We could do everything > > > exclusively in the /boot/efi partition which is already vfat, and not > > > bother creating any /boot partition, since we can ensure /boot/efi is > > > large enough. > > > > > > If we forsee the unified EFI kenrels being useful for bare metal, > > > however, then use of /boot as vfat becomes more important, as we > > > can't assume the hardware vendor's pre-created /boot/efi is > > > sufficiently large. > > > > Didn't want to open that discussion right now. My impression is that > > Gedora & RHEL settled on the approach to have both /boot and /boot/efi > > everywhere because some cases require this and having only a single > > scheme simplifies development + testing. > > > > Changing this looks not that easy to me, we have RPMs dropping files > > into /boot/efi/EFI and I suspect this is hard-wired in various places > > in anaconda and elsewhere. > > Hmm, yes, it is not worth trying to track down all those places. > > > So, yes, for cloud images we don't really need this as we can make the > > ESP as large as we want, but I have my doubts that deriving from the > > standard way fedora handles things gives us enough benefits to be worth > > the trouble. > > Agreed, removing the restrictions preventing vfat on /boot are > likely the least effort change. > > > > Thus my patch proposed two images, to be distributed in the same > > > 'kernel-virt-unified' sub-RPM. > > > > > > * vmlinuz-virt.efi created using dracut arg > > > > > > --kernel-cmdline 'console=ttyS0 console=tty0 quiet rhgb' > > > > > > * vmlinuz-virt-verbose.efi created using dracut arg > > > > > > --kernel-cmdline 'console=ttyS0 console=tty0' > > > > Hmm, I think we should look for a more elegant solution to this problem > > than having two large, 99% identical images. > > > > One option could be to have systemd-stub support multiple .cmdline > > sections and allowing the user to pick one of them. > > Hmm, interesting idea. That would be attractive because all the > different .cmdline variants would be trivially covered by the > SecureBoot signature still. Would need enhancement in the > bootloader(s) supporting unified image. > > > Another option could be to have a whitelist of options the user is > > allowed to add/remove which then could include stuff like 'console=' > > and 'quiet'. > > The most flexible as it avoids need to predict what users might > like to use, and also avoids the combinatorial expansion problem > from embedding multiple .cmdline, which becomes more important > as the set of safe-to-use options becomes larger. Would need the > bootloader to enforce this, if we're to avoid having to attest > the cmdline specifically after boot. > > Still I like the multiple .cmdline sections as it lets the bootload > give a simple menu choice without needing more interactive editting. > > With regards, > Daniel > -- > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| > |: https://libvirt.org -o-https://fstop138.berrange.com :| > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| > ___ > kernel mailing list -- kernel@lists.fedoraproject.org > To unsubscribe send an email to kernel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
On Fri, Sep 02, 2022 at 11:21:03AM +0200, Gerd Hoffmann wrote: > Hi, > > > > (3) Support /boot being vfat (depending on #2, sd-boot needs this). > > > > Technically in the cloud image scenario we don't need to especially > > care about /boot being a dedicated partition. We could do everything > > exclusively in the /boot/efi partition which is already vfat, and not > > bother creating any /boot partition, since we can ensure /boot/efi is > > large enough. > > > > If we forsee the unified EFI kenrels being useful for bare metal, > > however, then use of /boot as vfat becomes more important, as we > > can't assume the hardware vendor's pre-created /boot/efi is > > sufficiently large. > > Didn't want to open that discussion right now. My impression is that > Gedora & RHEL settled on the approach to have both /boot and /boot/efi > everywhere because some cases require this and having only a single > scheme simplifies development + testing. > > Changing this looks not that easy to me, we have RPMs dropping files > into /boot/efi/EFI and I suspect this is hard-wired in various places > in anaconda and elsewhere. Hmm, yes, it is not worth trying to track down all those places. > So, yes, for cloud images we don't really need this as we can make the > ESP as large as we want, but I have my doubts that deriving from the > standard way fedora handles things gives us enough benefits to be worth > the trouble. Agreed, removing the restrictions preventing vfat on /boot are likely the least effort change. > > Thus my patch proposed two images, to be distributed in the same > > 'kernel-virt-unified' sub-RPM. > > > > * vmlinuz-virt.efi created using dracut arg > > > > --kernel-cmdline 'console=ttyS0 console=tty0 quiet rhgb' > > > > * vmlinuz-virt-verbose.efi created using dracut arg > > > > --kernel-cmdline 'console=ttyS0 console=tty0' > > Hmm, I think we should look for a more elegant solution to this problem > than having two large, 99% identical images. > > One option could be to have systemd-stub support multiple .cmdline > sections and allowing the user to pick one of them. Hmm, interesting idea. That would be attractive because all the different .cmdline variants would be trivially covered by the SecureBoot signature still. Would need enhancement in the bootloader(s) supporting unified image. > Another option could be to have a whitelist of options the user is > allowed to add/remove which then could include stuff like 'console=' > and 'quiet'. The most flexible as it avoids need to predict what users might like to use, and also avoids the combinatorial expansion problem from embedding multiple .cmdline, which becomes more important as the set of safe-to-use options becomes larger. Would need the bootloader to enforce this, if we're to avoid having to attest the cmdline specifically after boot. Still I like the multiple .cmdline sections as it lets the bootload give a simple menu choice without needing more interactive editting. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 0/3] pre-generated initrd and unified kernels
On Thu, Sep 01, 2022 at 10:37:03AM -0400, Prarit Bhargava wrote: > Hey Gerd, > > Thanks for this changeset. > > On 8/31/22 08:46, Gerd Hoffmann wrote: > >Hi, > > > > Here is a little patch series to kick off a discussion on pre-generated > > initrd images and unified kernels. Lets start with a description of the > > patches: > > > >Patch #1 adds a dracut config file, targeting virtual machines. Given > >that most physical machines have either sata or nvme disks these days > >it probably boots most physical systems too. > > No critical objections from me, however, just a few long-term questions > about this approach. > > How are you going to prevent feature-creep in the initrd? What happens when > someone asks us to include "driver X" in this general initrd? How do we > determine whether or "driver X" is or is not appropriate for inclusion? If we limit the targetted usage to only be VMs, then we limit the scope of drivers significantly, since there's a small finite set of hypervisor we care about providing disk images for (VMware, HyperV, Xen, KVM), and thus we know what drivers are needed in order to be able to get out of the initrd into the root fs. If we extend to usage in bare metal scope of drivers becomes a little more open ended potentially, and I don't have a definite answer for what the criteria would be in that case. Worth noting though that systemd has a extension mechanism https://www.freedesktop.org/software/systemd/man/systemd-sysext.html that can be used to augment the pre-built initrd with further content. Fedora could ship certain drivers are separate extension images, or users could build their own extension images (though they would need to deal with their own SecureBoot keys in the latter case). > >Patch #2 adds a sub-package with an initrd image. > > > >Patch #3 adds a sub-package with an unified kernel. > > These will be built all the time. I'm worried about storage, etc., when > adding new sub-packages. Having said that, I do really like the idea ;) and > would definitely argue that it is worth it. For reference, in the kernel-virt-unified sub-RPM that my patches build, I'm created two EFI images, each of which is 40 MB in size, so total of 80 MB size for that new sub-RPM. When -debug builds are enabled, you get the same again for kernel-debug-virt-unified, so 160 MB total. THe overall kernel build output for x86_64 is 2.1 GB though, largely thanks to the enourmous -debuginfo packages, which dwarfs the extra 160 MB for these EFI images. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
