Re: kernel rpm split
On Tue, Feb 11, 2020 at 10:09:52AM -0600, Justin Forbes wrote: > On Tue, Feb 11, 2020 at 7:16 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Mon, Feb 10, 2020 at 02:37:13PM -0500, John Florian wrote: > > > Can this be improved? I'm sure it can be. I'm genuinely curious > > > what dracut does that an rpm couldn't ship. I'd also hate to lose > > > the versatility that we have at the present. I've been very > > > successful with what Fedora has offered, but I've always been scared > > > of autonomous nodes building/booting their own special initrd's and > > > hoping all just works. > > > > Hi, > > > > I think this discussion has gone further than intended. I'm not > > proposing Fedora changes the way initramfs is being done; it's way too > > early for this at this point. Rather, I was asking for making the > > packaging of kernel more flexible. One of the uses might the initramfs > > stuff, but this type of changes is generally useful for minimization, > > e.g. for VM images. I think other cases would pop up too. > > > > As to the question of the flexibility of dracut: it is flexible. But > > this flexibility is completely orthogonal to how the image is put > > together: if the image was built by installing some rpms, it'd still > > be possible to do whatever changes from a plugin after those rpms > > have been installed. Please consider e.g. how os-build does this (there > > was a nice talk at devconf). > > > > This is all relevant discussion though, as we really do need to know > a) exactly how people are wanting the kernel split up, and b) what is > the exact benefit of doing so. Here's the thing. People ask for the > kernel to be split up in various ways almost yearly at this point. > Everyone wants something different. Splitting the kernel is a hard > thing to do without messing up people's systems, and it can get out of > hand *very* quickly. I am not opposed to changing the kernel > packaging if we can prove real benefit to doing so, AND can prove it > isn't going to cause problems for existing users, or an ongoing > nightmare for maintainers. Ack. I'll come back with a more concrete proposal. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: kernel rpm split
On Tue, Feb 11, 2020 at 7:16 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Mon, Feb 10, 2020 at 02:37:13PM -0500, John Florian wrote: > > Can this be improved? I'm sure it can be. I'm genuinely curious > > what dracut does that an rpm couldn't ship. I'd also hate to lose > > the versatility that we have at the present. I've been very > > successful with what Fedora has offered, but I've always been scared > > of autonomous nodes building/booting their own special initrd's and > > hoping all just works. > > Hi, > > I think this discussion has gone further than intended. I'm not > proposing Fedora changes the way initramfs is being done; it's way too > early for this at this point. Rather, I was asking for making the > packaging of kernel more flexible. One of the uses might the initramfs > stuff, but this type of changes is generally useful for minimization, > e.g. for VM images. I think other cases would pop up too. > > As to the question of the flexibility of dracut: it is flexible. But > this flexibility is completely orthogonal to how the image is put > together: if the image was built by installing some rpms, it'd still > be possible to do whatever changes from a plugin after those rpms > have been installed. Please consider e.g. how os-build does this (there > was a nice talk at devconf). > This is all relevant discussion though, as we really do need to know a) exactly how people are wanting the kernel split up, and b) what is the exact benefit of doing so. Here's the thing. People ask for the kernel to be split up in various ways almost yearly at this point. Everyone wants something different. Splitting the kernel is a hard thing to do without messing up people's systems, and it can get out of hand *very* quickly. I am not opposed to changing the kernel packaging if we can prove real benefit to doing so, AND can prove it isn't going to cause problems for existing users, or an ongoing nightmare for maintainers. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: kernel rpm split
On Mon, Feb 10, 2020 at 02:37:13PM -0500, John Florian wrote: > Can this be improved? I'm sure it can be. I'm genuinely curious > what dracut does that an rpm couldn't ship. I'd also hate to lose > the versatility that we have at the present. I've been very > successful with what Fedora has offered, but I've always been scared > of autonomous nodes building/booting their own special initrd's and > hoping all just works. Hi, I think this discussion has gone further than intended. I'm not proposing Fedora changes the way initramfs is being done; it's way too early for this at this point. Rather, I was asking for making the packaging of kernel more flexible. One of the uses might the initramfs stuff, but this type of changes is generally useful for minimization, e.g. for VM images. I think other cases would pop up too. As to the question of the flexibility of dracut: it is flexible. But this flexibility is completely orthogonal to how the image is put together: if the image was built by installing some rpms, it'd still be possible to do whatever changes from a plugin after those rpms have been installed. Please consider e.g. how os-build does this (there was a nice talk at devconf). Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: kernel rpm split
On Thu, 2020-02-06 at 14:13 -0500, Josh Boyer wrote: > On Thu, Feb 6, 2020 at 1:56 PM Zbigniew Jędrzejewski-Szmek > wrote: > > Hello kernel maintainers, hello Fedora developers, > > > > I'm looking into the split of kernel packages. The split into > > subpackages > > seems interesting, but there are many dependencies between the > > packages, > > so it is usual to end up with all of them installed. > > > > E.g. for a simple VM, by design, kernel-core contains a basic set > > of > > modules that should be enough to boot. I see that in a standard > > libvirt guest, the only modules from kernel-modules that are loaded > > are for sound hardware and "usbnet", all which I'd be fine without. > > > > Another example: we'd like to explore building an initramfs > > directly > > from rpms, without dracut, only systemd and a standard packages to > > bring up the hardware. Some modules need to be installed, so the > > kernel can load the from the initramfs, but the kernel itself > > should > > not, since it is provided "externally" by the boot loader. > > > > But: > > the basic modules are in one rpm with kernel-core > > kernel-core Requires linux-firmware (which is 240MB) > > kernel-modules Requires kernel-uname-r, which is provided by > > kernel-core > > kernel Requires kernel-core-uname-r, kernel-modules-uname-r > > > > Would it be possible to make some changes: > > > > - split out the modules from kernel-core package into a new > > subpackage > > kernel-basic-modules, kernel-core can Recommend or Require it > > There has to be a *really* good benefit to do this, and I haven't > seen > one described. The more splitting we do, the more management both on > the client machines and for the kernel maintainers themselves. The > way modules are filtered is terrible (I wrote it, so I can say that) > and requires people to keep it updated as the upstream kernel changes > module dependencies. > The way modules are filtered is indeed difficult and requires a lot of human care and attention, but perhaps this is a good opportunity to rethink how it works a bit. I'm obviously not crazy about advocating for something that makes my job harder, but I'm willing to entertain doing some work so I can later not do any work in that area again. Furthermore, this particular issue is on my radar anyway due to my last run-in with it. All that to say that I *hope* we can improve how we divvy up modules enough that it won't be a blocker for this proposal (and kernel maintainers will live in a land filled with sunshine and rainbows). > Can you describe in more detail why you need something smaller than > kernel-core? I'm not understanding your usecase. > > > - remove the Requires on kernel-core (or change to Recommends) from > > kernel-modules, so it can be installed standalone > > That makes no sense. The modules are unusable without the main > vmlinux binary. Why would we do that and risk people making their > machines unbootable? > > > - move the Requires:linux-firmware (or change to Recommends) from > > kernel-core, > > have kernel Requires:linux-firmware > > > > I think this would be useful for playing with various minimization > > scenarios. > > This one might be feasible. We did the split before Recommends > support was present. It's often been requested for the VM case. I > do > still have concerns that it can lead to unbootable physical machines, > but if dnf defaults to installing Recommended packages that might be > possible. > > josh > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: kernel rpm split
On 2020-02-07 09:56, Stephen John Smoogen wrote: On Fri, 7 Feb 2020 at 09:28, Zbigniew Jędrzejewski-Szmek mailto:zbys...@in.waw.pl>> wrote: On Fri, Feb 07, 2020 at 08:37:05AM -0500, Neal Gompa wrote: > On Fri, Feb 7, 2020 at 8:27 AM Zbigniew Jędrzejewski-Szmek > mailto:zbys...@in.waw.pl>> wrote: > > > > On Fri, Feb 07, 2020 at 12:09:37PM +, Richard W.M. Jones wrote: > > > > > > I'd strongly suggest you look at supermin before going any further. > > > > Supermin is an interesting project, but at this point we're not > > looking for a tool to craft the image. We're still at an earlier stage > > of changing how we do some rpm packages so that it is easy to do an > > installation that is small without custom logic. > > > > The idea is that the initramfs, once you include lvm, md, dm, encryption, > > networking, clevis, emergency utilities, scsi, iscsi, raid in various > > flavours, some graphics drivers, usb, bluetooth, etc, is a lot like a > > the full distribution. Things would be a lot easier if we could just > > use the same tools and daemons from the same packages as in the > > host. Supermin (and other tools) have support for creating something > > custom and small, and here the goal is the opposite: to do "standard". > > > > Fedora currently uses dracut, and the problem is that nobody has a > > good grasp on what goes in dracut. There's a lot of custom logic and > > custom code and reimplementation of things, and people who deal with > > the same functionality in the host system don't necessarily know what > > happens in the initramfs. In the past such a setup made sense, but now > > it seems that the tradeoffs are different. > > > > I'm genuinely surprised by this. [...] The main problem with > dracut is the same problem with all initramfs generators: it has to > prepare an environment that works in the worst circumstances. It's > compounded by the restriction that everything is written in shell, and > POSIX shell at that (because Debian). Well, look at it from the other side: the host machine also needs to work in the same circumstances, since we need things to work also after we switch to the host. And the actual code that we use in the host — the libraries, the binaries, configuration — is the same, since we don't do different compilations for the initramfs. In the host we have switched away from the shell for machine boot, but for some reason we still keep it for the initramfs, along with a large amount of custom logic. > The dracut package, while very large, > has a pretty understandable framework model. Sure, it *can* be understood, but should it? Do we gain anything by having the initramfs so different from the host? The initial My problem here is that we continually get told we are full of Not Invented Here(NIH) solutions by people in other communities and we should be doing something Debian and different communities use.. And here is one of the places we do agree with other distributions, but it is now a "bah its crap and you can do something better that works with your tools." We knew that years ago and we have known that time and time again. The issue is that we end up with another 'NIH' tool which our limited manpower are going to know and as soon as XYZ developer walks off to $ABC startup we have an unbootable and unmaintained mess. AKA where we were before dracut. If we are hell bent on repeating history, please let us try to learn from it first. Please allow me to weigh in here, whilst I straddle this fence since I have a vested stake here, though I only have $0.02 to vote with just like anyone else. On one hand, I like the idea being proposed. I mean, it shouldn't be that different of an environment than what you're trying to boot into. The whole process has a a lot of complexity that seems wasteful in some cases but affords flexibility in others. Nobody likes waiting for dracut to do its thing. I've literally done so hundreds of times in the last few weeks as I prepare for an in-service, in-place upgrade of several hundred nodes running a custom Fedora Live spin to a newer custom Fedora Live spin. I've done so successfully shepherding them from Fedora 10 to 25 and am about to jump them all to F29. The magic all happens via a custom initrd that does a switcheraroo of the LiveOS and syslinux directories. So, one reboot into the magic initrd to do the switch and another reboot from there into the new distro. (I should note, that the hundreds of dracut runs are its fault, but instead for dev work related to how the new payload is managed. Nonetheless, I've done a lot of waiting in testing due to dracut runs.) On the other hand, I remember the madness of trying to maintain local patches t
Re: kernel rpm split
On Fri, 7 Feb 2020 at 09:28, Zbigniew Jędrzejewski-Szmek wrote: > On Fri, Feb 07, 2020 at 08:37:05AM -0500, Neal Gompa wrote: > > On Fri, Feb 7, 2020 at 8:27 AM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Fri, Feb 07, 2020 at 12:09:37PM +, Richard W.M. Jones wrote: > > > > > > > > I'd strongly suggest you look at supermin before going any further. > > > > > > Supermin is an interesting project, but at this point we're not > > > looking for a tool to craft the image. We're still at an earlier stage > > > of changing how we do some rpm packages so that it is easy to do an > > > installation that is small without custom logic. > > > > > > The idea is that the initramfs, once you include lvm, md, dm, > encryption, > > > networking, clevis, emergency utilities, scsi, iscsi, raid in various > > > flavours, some graphics drivers, usb, bluetooth, etc, is a lot like a > > > the full distribution. Things would be a lot easier if we could just > > > use the same tools and daemons from the same packages as in the > > > host. Supermin (and other tools) have support for creating something > > > custom and small, and here the goal is the opposite: to do "standard". > > > > > > Fedora currently uses dracut, and the problem is that nobody has a > > > good grasp on what goes in dracut. There's a lot of custom logic and > > > custom code and reimplementation of things, and people who deal with > > > the same functionality in the host system don't necessarily know what > > > happens in the initramfs. In the past such a setup made sense, but now > > > it seems that the tradeoffs are different. > > > > > > > I'm genuinely surprised by this. [...] The main problem with > > dracut is the same problem with all initramfs generators: it has to > > prepare an environment that works in the worst circumstances. It's > > compounded by the restriction that everything is written in shell, and > > POSIX shell at that (because Debian). > > Well, look at it from the other side: the host machine also needs to > work in the same circumstances, since we need things to work also after > we switch to the host. And the actual code that we use in the host > — the libraries, the binaries, configuration — is the same, since we > don't do different compilations for the initramfs. > In the host we have switched away from the shell for machine boot, but > for some reason we still keep it for the initramfs, along with a large > amount of custom logic. > > > The dracut package, while very large, > > has a pretty understandable framework model. > Sure, it *can* be understood, but should it? Do we gain anything by > having the initramfs so different from the host? The initial > My problem here is that we continually get told we are full of Not Invented Here(NIH) solutions by people in other communities and we should be doing something Debian and different communities use.. And here is one of the places we do agree with other distributions, but it is now a "bah its crap and you can do something better that works with your tools." We knew that years ago and we have known that time and time again. The issue is that we end up with another 'NIH' tool which our limited manpower are going to know and as soon as XYZ developer walks off to $ABC startup we have an unbootable and unmaintained mess. AKA where we were before dracut. If we are hell bent on repeating history, please let us try to learn from it first. -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: kernel rpm split
On Fri, Feb 07, 2020 at 08:37:05AM -0500, Neal Gompa wrote: > On Fri, Feb 7, 2020 at 8:27 AM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Fri, Feb 07, 2020 at 12:09:37PM +, Richard W.M. Jones wrote: > > > > > > I'd strongly suggest you look at supermin before going any further. > > > > Supermin is an interesting project, but at this point we're not > > looking for a tool to craft the image. We're still at an earlier stage > > of changing how we do some rpm packages so that it is easy to do an > > installation that is small without custom logic. > > > > The idea is that the initramfs, once you include lvm, md, dm, encryption, > > networking, clevis, emergency utilities, scsi, iscsi, raid in various > > flavours, some graphics drivers, usb, bluetooth, etc, is a lot like a > > the full distribution. Things would be a lot easier if we could just > > use the same tools and daemons from the same packages as in the > > host. Supermin (and other tools) have support for creating something > > custom and small, and here the goal is the opposite: to do "standard". > > > > Fedora currently uses dracut, and the problem is that nobody has a > > good grasp on what goes in dracut. There's a lot of custom logic and > > custom code and reimplementation of things, and people who deal with > > the same functionality in the host system don't necessarily know what > > happens in the initramfs. In the past such a setup made sense, but now > > it seems that the tradeoffs are different. > > > > I'm genuinely surprised by this. [...] The main problem with > dracut is the same problem with all initramfs generators: it has to > prepare an environment that works in the worst circumstances. It's > compounded by the restriction that everything is written in shell, and > POSIX shell at that (because Debian). Well, look at it from the other side: the host machine also needs to work in the same circumstances, since we need things to work also after we switch to the host. And the actual code that we use in the host — the libraries, the binaries, configuration — is the same, since we don't do different compilations for the initramfs. In the host we have switched away from the shell for machine boot, but for some reason we still keep it for the initramfs, along with a large amount of custom logic. > The dracut package, while very large, > has a pretty understandable framework model. Sure, it *can* be understood, but should it? Do we gain anything by having the initramfs so different from the host? The initial experiments with initramfs built from rpms directly give something that a) already works fine for some common cases without any tweaking, b) is actually faster to boot. Currently the size increase is not acceptable, but if we consider that the binaries and libs will take the same amount of space no matter how we build the image, this issue should be surmountable. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: kernel rpm split
On Fri, Feb 7, 2020 at 8:27 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Fri, Feb 07, 2020 at 12:09:37PM +, Richard W.M. Jones wrote: > > > > I'd strongly suggest you look at supermin before going any further. > > Supermin is an interesting project, but at this point we're not > looking for a tool to craft the image. We're still at an earlier stage > of changing how we do some rpm packages so that it is easy to do an > installation that is small without custom logic. > > The idea is that the initramfs, once you include lvm, md, dm, encryption, > networking, clevis, emergency utilities, scsi, iscsi, raid in various > flavours, some graphics drivers, usb, bluetooth, etc, is a lot like a > the full distribution. Things would be a lot easier if we could just > use the same tools and daemons from the same packages as in the > host. Supermin (and other tools) have support for creating something > custom and small, and here the goal is the opposite: to do "standard". > > Fedora currently uses dracut, and the problem is that nobody has a > good grasp on what goes in dracut. There's a lot of custom logic and > custom code and reimplementation of things, and people who deal with > the same functionality in the host system don't necessarily know what > happens in the initramfs. In the past such a setup made sense, but now > it seems that the tradeoffs are different. > I'm genuinely surprised by this. The dracut package, while very large, has a pretty understandable framework model. The main problem with dracut is the same problem with all initramfs generators: it has to prepare an environment that works in the worst circumstances. It's compounded by the restriction that everything is written in shell, and POSIX shell at that (because Debian). It does take a bit of a mental bend (mainly to understand POSIX shell), but it's not difficult to understand what's happening. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: kernel rpm split
On Fri, Feb 07, 2020 at 12:09:37PM +, Richard W.M. Jones wrote: > > I'd strongly suggest you look at supermin before going any further. Supermin is an interesting project, but at this point we're not looking for a tool to craft the image. We're still at an earlier stage of changing how we do some rpm packages so that it is easy to do an installation that is small without custom logic. The idea is that the initramfs, once you include lvm, md, dm, encryption, networking, clevis, emergency utilities, scsi, iscsi, raid in various flavours, some graphics drivers, usb, bluetooth, etc, is a lot like a the full distribution. Things would be a lot easier if we could just use the same tools and daemons from the same packages as in the host. Supermin (and other tools) have support for creating something custom and small, and here the goal is the opposite: to do "standard". Fedora currently uses dracut, and the problem is that nobody has a good grasp on what goes in dracut. There's a lot of custom logic and custom code and reimplementation of things, and people who deal with the same functionality in the host system don't necessarily know what happens in the initramfs. In the past such a setup made sense, but now it seems that the tradeoffs are different. As to how to actually construct the image, that's an open question for now. Doing it "by hand" is not too onerous, but in the long term some tool we'll most likely be used. Whether it's supermin, os-build, or something else doesn't matter at this point. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: kernel rpm split
Dne 07. 02. 20 v 13:47 Neal Gompa napsal(a): On Fri, Feb 7, 2020 at 4:00 AM Daniel Mach wrote >> Dne 06. 02. 20 v 19:54 Zbigniew Jędrzejewski-Szmek napsal(a): - move the Requires:linux-firmware (or change to Recommends) from kernel-core, have kernel Requires:linux-firmware It would be nice to introduce hardware specific Requires implemented. If you have the hardware, a Provide would be dynamically generated (an udev rule?) and used in rich dependencies to pull the firmware package you need. I believe SUSE is doing something similar already, but I don't quite like references to PCI-IDs, for example: Supplements: (kernel-default and namespace:modalias(pci:v80EEdBEEFsv*sd*bc*sc*i*)) We already have kmods generate modalias provides if they're associated with hardware, I think? So it wouldn't be that bad to have DNF trigger inject virtual supplements that would pull in kernel modules. I'm not opposed to that as long as someone outside the DNF team manages the rules. We are in the package management business and know only a little about hardware, firmware, kmods and how they relate to each other. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: kernel rpm split
On Fri, Feb 7, 2020 at 4:00 AM Daniel Mach wrote: > > > > Dne 06. 02. 20 v 19:54 Zbigniew Jędrzejewski-Szmek napsal(a): > > Hello kernel maintainers, hello Fedora developers, > > > > I'm looking into the split of kernel packages. The split into subpackages > > seems interesting, but there are many dependencies between the packages, > > so it is usual to end up with all of them installed. > > > > E.g. for a simple VM, by design, kernel-core contains a basic set of > > modules that should be enough to boot. I see that in a standard > > libvirt guest, the only modules from kernel-modules that are loaded > > are for sound hardware and "usbnet", all which I'd be fine without. > > > > Another example: we'd like to explore building an initramfs directly > > from rpms, without dracut, only systemd and a standard packages to > > bring up the hardware. Some modules need to be installed, so the > > kernel can load the from the initramfs, but the kernel itself should > > not, since it is provided "externally" by the boot loader. > > > > But: > > the basic modules are in one rpm with kernel-core > > kernel-core Requires linux-firmware (which is 240MB) > > kernel-modules Requires kernel-uname-r, which is provided by kernel-core > > kernel Requires kernel-core-uname-r, kernel-modules-uname-r > > > > Would it be possible to make some changes: > > > > - split out the modules from kernel-core package into a new subpackage > >kernel-basic-modules, kernel-core can Recommend or Require it > If you're after generating a minimal initramfs, this still doesn't solve > the problem. In many cases you need kernel-core *and* several modules. > > An option would be splitting the modules into individual RPMs and > installing only those we need. But it is a bad idea (remember texlive > and it's subpackage explosion). > > I was thinking if you couldn't look into using a similar approach to the > %_install_langs macro - simply define modules you want installed, the > others would be skipped. > > > > > - remove the Requires on kernel-core (or change to Recommends) from > >kernel-modules, so it can be installed standalone > > > > - move the Requires:linux-firmware (or change to Recommends) from > > kernel-core, > >have kernel Requires:linux-firmware > It would be nice to introduce hardware specific Requires implemented. > If you have the hardware, a Provide would be dynamically generated (an > udev rule?) and used in rich dependencies to pull the firmware package > you need. > > I believe SUSE is doing something similar already, but I don't quite > like references to PCI-IDs, for example: > Supplements: (kernel-default and > namespace:modalias(pci:v80EEdBEEFsv*sd*bc*sc*i*)) > > We already have kmods generate modalias provides if they're associated with hardware, I think? So it wouldn't be that bad to have DNF trigger inject virtual supplements that would pull in kernel modules. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: kernel rpm split
I'd strongly suggest you look at supermin before going any further. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: kernel rpm split
Dne 06. 02. 20 v 19:54 Zbigniew Jędrzejewski-Szmek napsal(a): Hello kernel maintainers, hello Fedora developers, I'm looking into the split of kernel packages. The split into subpackages seems interesting, but there are many dependencies between the packages, so it is usual to end up with all of them installed. E.g. for a simple VM, by design, kernel-core contains a basic set of modules that should be enough to boot. I see that in a standard libvirt guest, the only modules from kernel-modules that are loaded are for sound hardware and "usbnet", all which I'd be fine without. Another example: we'd like to explore building an initramfs directly from rpms, without dracut, only systemd and a standard packages to bring up the hardware. Some modules need to be installed, so the kernel can load the from the initramfs, but the kernel itself should not, since it is provided "externally" by the boot loader. But: the basic modules are in one rpm with kernel-core kernel-core Requires linux-firmware (which is 240MB) kernel-modules Requires kernel-uname-r, which is provided by kernel-core kernel Requires kernel-core-uname-r, kernel-modules-uname-r Would it be possible to make some changes: - split out the modules from kernel-core package into a new subpackage kernel-basic-modules, kernel-core can Recommend or Require it If you're after generating a minimal initramfs, this still doesn't solve the problem. In many cases you need kernel-core *and* several modules. An option would be splitting the modules into individual RPMs and installing only those we need. But it is a bad idea (remember texlive and it's subpackage explosion). I was thinking if you couldn't look into using a similar approach to the %_install_langs macro - simply define modules you want installed, the others would be skipped. - remove the Requires on kernel-core (or change to Recommends) from kernel-modules, so it can be installed standalone - move the Requires:linux-firmware (or change to Recommends) from kernel-core, have kernel Requires:linux-firmware It would be nice to introduce hardware specific Requires implemented. If you have the hardware, a Provide would be dynamically generated (an udev rule?) and used in rich dependencies to pull the firmware package you need. I believe SUSE is doing something similar already, but I don't quite like references to PCI-IDs, for example: Supplements: (kernel-default and namespace:modalias(pci:v80EEdBEEFsv*sd*bc*sc*i*)) I think this would be useful for playing with various minimization scenarios. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: kernel rpm split
On Thu, Feb 06, 2020 at 03:09:53PM -0500, Josh Boyer wrote: > On Thu, Feb 6, 2020 at 2:40 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Thu, Feb 06, 2020 at 02:13:25PM -0500, Josh Boyer wrote: > > > On Thu, Feb 6, 2020 at 1:56 PM Zbigniew Jędrzejewski-Szmek > > > wrote: > > > > > > > > Hello kernel maintainers, hello Fedora developers, > > > > > > > > I'm looking into the split of kernel packages. The split into > > > > subpackages > > > > seems interesting, but there are many dependencies between the packages, > > > > so it is usual to end up with all of them installed. > > > > > > > > E.g. for a simple VM, by design, kernel-core contains a basic set of > > > > modules that should be enough to boot. I see that in a standard > > > > libvirt guest, the only modules from kernel-modules that are loaded > > > > are for sound hardware and "usbnet", all which I'd be fine without. > > > > > > > > Another example: we'd like to explore building an initramfs directly > > > > from rpms, without dracut, only systemd and a standard packages to > > > > bring up the hardware. Some modules need to be installed, so the > > > > kernel can load the from the initramfs, but the kernel itself should > > > > not, since it is provided "externally" by the boot loader. > > > > > > > > But: > > > > the basic modules are in one rpm with kernel-core > > > > kernel-core Requires linux-firmware (which is 240MB) > > > > kernel-modules Requires kernel-uname-r, which is provided by kernel-core > > > > kernel Requires kernel-core-uname-r, kernel-modules-uname-r > > > > > > > > Would it be possible to make some changes: > > > > > > > > - split out the modules from kernel-core package into a new subpackage > > > > kernel-basic-modules, kernel-core can Recommend or Require it > > > > > > There has to be a *really* good benefit to do this, and I haven't seen > > > one described. The more splitting we do, the more management both on > > > the client machines and for the kernel maintainers themselves. The > > > way modules are filtered is terrible (I wrote it, so I can say that) > > > and requires people to keep it updated as the upstream kernel changes > > > module dependencies. > > > > > Can you describe in more detail why you need something smaller than > > > kernel-core? I'm not understanding your usecase. > > > > The initramfs built from rpms was described above. > > I don't understand the description of the initramfs build from rpms as > described above. Can you be more verbose with the usecase of that, > how it would work, what hardware it would target, etc? Dracut builds initramfs by (in great simplification) - picking a list of files to copy from the host filesystem (along with dependencies, e.g. all libraries used by the binaries) - adding a layer of shell scripts and custom logic to manage the boot sequence. This means that the initramfs is a) dependent on the host installation, including any local modifications and errors, b) very fragile because a list of files to copy must be carefully curated. The general idea is to instead the equivalent of dnf --installroot=/tmp/foo install systemd kernel-modules lvmd ... cp /usr/lib/os-release /tmp/foo/etc/initrd-release and create a squashfs from /tmp/foo and use that as the initramfs. This already works well enough to boot normal Fedora installations, but certainly not many custom cases. The initramfs is also ~10 larger. The prospective advantages though are pretty significant: - no need to maintain a list of files to install, just use normal rpm packaging and deps - the initramfs is created from pristine files from rpm - no custom logic and shell scripts, just plain systemd > > A different example: a VM is booted with 'qemu -kernel foo'. Then > > we vmlinuz binary is not necessary in the guest, just the modules. > > > > > > - remove the Requires on kernel-core (or change to Recommends) from > > > > kernel-modules, so it can be installed standalone > > > > > > That makes no sense. The modules are unusable without the main > > > vmlinux binary. Why would we do that and risk people making their > > > machines unbootable? > > > > See above, there are cases where the modules are usable without vmlinuz > > being _installed_. People who just want to have the safe thing, should > > install kernel.rpm and have it pull in all the dependencies. The split > > into subpackages is for power users. > > Hm. I see. So you're really asking for the vmlinuz to be packaged > all by itself. Both ways: for some cases I want just the modules, for some just vmlinuz and a very small list of modules. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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
Re: kernel rpm split
On Thu, Feb 6, 2020 at 2:40 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Feb 06, 2020 at 02:13:25PM -0500, Josh Boyer wrote: > > On Thu, Feb 6, 2020 at 1:56 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > Hello kernel maintainers, hello Fedora developers, > > > > > > I'm looking into the split of kernel packages. The split into subpackages > > > seems interesting, but there are many dependencies between the packages, > > > so it is usual to end up with all of them installed. > > > > > > E.g. for a simple VM, by design, kernel-core contains a basic set of > > > modules that should be enough to boot. I see that in a standard > > > libvirt guest, the only modules from kernel-modules that are loaded > > > are for sound hardware and "usbnet", all which I'd be fine without. > > > > > > Another example: we'd like to explore building an initramfs directly > > > from rpms, without dracut, only systemd and a standard packages to > > > bring up the hardware. Some modules need to be installed, so the > > > kernel can load the from the initramfs, but the kernel itself should > > > not, since it is provided "externally" by the boot loader. > > > > > > But: > > > the basic modules are in one rpm with kernel-core > > > kernel-core Requires linux-firmware (which is 240MB) > > > kernel-modules Requires kernel-uname-r, which is provided by kernel-core > > > kernel Requires kernel-core-uname-r, kernel-modules-uname-r > > > > > > Would it be possible to make some changes: > > > > > > - split out the modules from kernel-core package into a new subpackage > > > kernel-basic-modules, kernel-core can Recommend or Require it > > > > There has to be a *really* good benefit to do this, and I haven't seen > > one described. The more splitting we do, the more management both on > > the client machines and for the kernel maintainers themselves. The > > way modules are filtered is terrible (I wrote it, so I can say that) > > and requires people to keep it updated as the upstream kernel changes > > module dependencies. > > > Can you describe in more detail why you need something smaller than > > kernel-core? I'm not understanding your usecase. > > The initramfs built from rpms was described above. > > A different example: a VM is booted with 'qemu -kernel foo'. Then > we vmlinuz binary is not necessary in the guest, just the modules. > > > > - remove the Requires on kernel-core (or change to Recommends) from > > > kernel-modules, so it can be installed standalone > > > > That makes no sense. The modules are unusable without the main > > vmlinux binary. Why would we do that and risk people making their > > machines unbootable? > > See above, there are cases where the modules are usable without vmlinuz > being _installed_. People who just want to have the safe thing, should > install kernel.rpm and have it pull in all the dependencies. The split > into subpackages is for power users. > > (Proposed changes don't fundamentally change anything: it was already > possible to uninstall kernel-modules and kernel-firmware, just keeping > kernel-core, and make the machine unbootable.) > The changes you're asking for would make this possible. It's currently not possible to completely break your system this way. I've previously experimented with some further splitting for minimization purposes and I haven't really seen much benefit to it. It also adds a lot of surprises for what functionality is expected to work. > > > - move the Requires:linux-firmware (or change to Recommends) from > > > kernel-core, > > > have kernel Requires:linux-firmware > > > > > > I think this would be useful for playing with various minimization > > > scenarios. > > > > This one might be feasible. We did the split before Recommends > > support was present. It's often been requested for the VM case. I do > > still have concerns that it can lead to unbootable physical machines, > > but if dnf defaults to installing Recommended packages that might be > > possible. > Cool, that'd be a good start, since the firmware package is so large. > Yes, dnf does install Recommends by default. I wish we could have linux-firmware get pulled in conditionally by DNF if it detects hardware that needs it. That said, downgrading the dependency to Recommends means that the kickstarts will need adjustment to compensate for the fact that it'll no longer be pulled in by default. Alternatively, have you considered having the kernel package produce a stub subpackage (e.g kernel-no-firmware) to install no firmware and satisfy a kernel-firmware virtual dependency that it requires? Then the kernel-core package could have a "Suggests: (kernel-no-firmware if (fedora-release-cloud or fedora-release-container) or linux-firmware)". -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https:/
Re: kernel rpm split
On Thu, Feb 6, 2020 at 2:40 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Feb 06, 2020 at 02:13:25PM -0500, Josh Boyer wrote: > > On Thu, Feb 6, 2020 at 1:56 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > Hello kernel maintainers, hello Fedora developers, > > > > > > I'm looking into the split of kernel packages. The split into subpackages > > > seems interesting, but there are many dependencies between the packages, > > > so it is usual to end up with all of them installed. > > > > > > E.g. for a simple VM, by design, kernel-core contains a basic set of > > > modules that should be enough to boot. I see that in a standard > > > libvirt guest, the only modules from kernel-modules that are loaded > > > are for sound hardware and "usbnet", all which I'd be fine without. > > > > > > Another example: we'd like to explore building an initramfs directly > > > from rpms, without dracut, only systemd and a standard packages to > > > bring up the hardware. Some modules need to be installed, so the > > > kernel can load the from the initramfs, but the kernel itself should > > > not, since it is provided "externally" by the boot loader. > > > > > > But: > > > the basic modules are in one rpm with kernel-core > > > kernel-core Requires linux-firmware (which is 240MB) > > > kernel-modules Requires kernel-uname-r, which is provided by kernel-core > > > kernel Requires kernel-core-uname-r, kernel-modules-uname-r > > > > > > Would it be possible to make some changes: > > > > > > - split out the modules from kernel-core package into a new subpackage > > > kernel-basic-modules, kernel-core can Recommend or Require it > > > > There has to be a *really* good benefit to do this, and I haven't seen > > one described. The more splitting we do, the more management both on > > the client machines and for the kernel maintainers themselves. The > > way modules are filtered is terrible (I wrote it, so I can say that) > > and requires people to keep it updated as the upstream kernel changes > > module dependencies. > > > Can you describe in more detail why you need something smaller than > > kernel-core? I'm not understanding your usecase. > > The initramfs built from rpms was described above. I don't understand the description of the initramfs build from rpms as described above. Can you be more verbose with the usecase of that, how it would work, what hardware it would target, etc? > A different example: a VM is booted with 'qemu -kernel foo'. Then > we vmlinuz binary is not necessary in the guest, just the modules. > > > > - remove the Requires on kernel-core (or change to Recommends) from > > > kernel-modules, so it can be installed standalone > > > > That makes no sense. The modules are unusable without the main > > vmlinux binary. Why would we do that and risk people making their > > machines unbootable? > > See above, there are cases where the modules are usable without vmlinuz > being _installed_. People who just want to have the safe thing, should > install kernel.rpm and have it pull in all the dependencies. The split > into subpackages is for power users. Hm. I see. So you're really asking for the vmlinuz to be packaged all by itself. josh > (Proposed changes don't fundamentally change anything: it was already > possible to uninstall kernel-modules and kernel-firmware, just keeping > kernel-core, and make the machine unbootable.) > > > > - move the Requires:linux-firmware (or change to Recommends) from > > > kernel-core, > > > have kernel Requires:linux-firmware > > > > > > I think this would be useful for playing with various minimization > > > scenarios. > > > > This one might be feasible. We did the split before Recommends > > support was present. It's often been requested for the VM case. I do > > still have concerns that it can lead to unbootable physical machines, > > but if dnf defaults to installing Recommended packages that might be > > possible. > Cool, that'd be a good start, since the firmware package is so large. > Yes, dnf does install Recommends by default. > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: kernel rpm split
On Thu, Feb 06, 2020 at 02:13:25PM -0500, Josh Boyer wrote: > On Thu, Feb 6, 2020 at 1:56 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > Hello kernel maintainers, hello Fedora developers, > > > > I'm looking into the split of kernel packages. The split into subpackages > > seems interesting, but there are many dependencies between the packages, > > so it is usual to end up with all of them installed. > > > > E.g. for a simple VM, by design, kernel-core contains a basic set of > > modules that should be enough to boot. I see that in a standard > > libvirt guest, the only modules from kernel-modules that are loaded > > are for sound hardware and "usbnet", all which I'd be fine without. > > > > Another example: we'd like to explore building an initramfs directly > > from rpms, without dracut, only systemd and a standard packages to > > bring up the hardware. Some modules need to be installed, so the > > kernel can load the from the initramfs, but the kernel itself should > > not, since it is provided "externally" by the boot loader. > > > > But: > > the basic modules are in one rpm with kernel-core > > kernel-core Requires linux-firmware (which is 240MB) > > kernel-modules Requires kernel-uname-r, which is provided by kernel-core > > kernel Requires kernel-core-uname-r, kernel-modules-uname-r > > > > Would it be possible to make some changes: > > > > - split out the modules from kernel-core package into a new subpackage > > kernel-basic-modules, kernel-core can Recommend or Require it > > There has to be a *really* good benefit to do this, and I haven't seen > one described. The more splitting we do, the more management both on > the client machines and for the kernel maintainers themselves. The > way modules are filtered is terrible (I wrote it, so I can say that) > and requires people to keep it updated as the upstream kernel changes > module dependencies. > Can you describe in more detail why you need something smaller than > kernel-core? I'm not understanding your usecase. The initramfs built from rpms was described above. A different example: a VM is booted with 'qemu -kernel foo'. Then we vmlinuz binary is not necessary in the guest, just the modules. > > - remove the Requires on kernel-core (or change to Recommends) from > > kernel-modules, so it can be installed standalone > > That makes no sense. The modules are unusable without the main > vmlinux binary. Why would we do that and risk people making their > machines unbootable? See above, there are cases where the modules are usable without vmlinuz being _installed_. People who just want to have the safe thing, should install kernel.rpm and have it pull in all the dependencies. The split into subpackages is for power users. (Proposed changes don't fundamentally change anything: it was already possible to uninstall kernel-modules and kernel-firmware, just keeping kernel-core, and make the machine unbootable.) > > - move the Requires:linux-firmware (or change to Recommends) from > > kernel-core, > > have kernel Requires:linux-firmware > > > > I think this would be useful for playing with various minimization > > scenarios. > > This one might be feasible. We did the split before Recommends > support was present. It's often been requested for the VM case. I do > still have concerns that it can lead to unbootable physical machines, > but if dnf defaults to installing Recommended packages that might be > possible. Cool, that'd be a good start, since the firmware package is so large. Yes, dnf does install Recommends by default. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
Re: kernel rpm split
On Thu, Feb 6, 2020 at 1:56 PM Zbigniew Jędrzejewski-Szmek wrote: > > Hello kernel maintainers, hello Fedora developers, > > I'm looking into the split of kernel packages. The split into subpackages > seems interesting, but there are many dependencies between the packages, > so it is usual to end up with all of them installed. > > E.g. for a simple VM, by design, kernel-core contains a basic set of > modules that should be enough to boot. I see that in a standard > libvirt guest, the only modules from kernel-modules that are loaded > are for sound hardware and "usbnet", all which I'd be fine without. > > Another example: we'd like to explore building an initramfs directly > from rpms, without dracut, only systemd and a standard packages to > bring up the hardware. Some modules need to be installed, so the > kernel can load the from the initramfs, but the kernel itself should > not, since it is provided "externally" by the boot loader. > > But: > the basic modules are in one rpm with kernel-core > kernel-core Requires linux-firmware (which is 240MB) > kernel-modules Requires kernel-uname-r, which is provided by kernel-core > kernel Requires kernel-core-uname-r, kernel-modules-uname-r > > Would it be possible to make some changes: > > - split out the modules from kernel-core package into a new subpackage > kernel-basic-modules, kernel-core can Recommend or Require it There has to be a *really* good benefit to do this, and I haven't seen one described. The more splitting we do, the more management both on the client machines and for the kernel maintainers themselves. The way modules are filtered is terrible (I wrote it, so I can say that) and requires people to keep it updated as the upstream kernel changes module dependencies. Can you describe in more detail why you need something smaller than kernel-core? I'm not understanding your usecase. > - remove the Requires on kernel-core (or change to Recommends) from > kernel-modules, so it can be installed standalone That makes no sense. The modules are unusable without the main vmlinux binary. Why would we do that and risk people making their machines unbootable? > - move the Requires:linux-firmware (or change to Recommends) from kernel-core, > have kernel Requires:linux-firmware > > I think this would be useful for playing with various minimization scenarios. This one might be feasible. We did the split before Recommends support was present. It's often been requested for the VM case. I do still have concerns that it can lead to unbootable physical machines, but if dnf defaults to installing Recommended packages that might be possible. josh ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
kernel rpm split
Hello kernel maintainers, hello Fedora developers, I'm looking into the split of kernel packages. The split into subpackages seems interesting, but there are many dependencies between the packages, so it is usual to end up with all of them installed. E.g. for a simple VM, by design, kernel-core contains a basic set of modules that should be enough to boot. I see that in a standard libvirt guest, the only modules from kernel-modules that are loaded are for sound hardware and "usbnet", all which I'd be fine without. Another example: we'd like to explore building an initramfs directly from rpms, without dracut, only systemd and a standard packages to bring up the hardware. Some modules need to be installed, so the kernel can load the from the initramfs, but the kernel itself should not, since it is provided "externally" by the boot loader. But: the basic modules are in one rpm with kernel-core kernel-core Requires linux-firmware (which is 240MB) kernel-modules Requires kernel-uname-r, which is provided by kernel-core kernel Requires kernel-core-uname-r, kernel-modules-uname-r Would it be possible to make some changes: - split out the modules from kernel-core package into a new subpackage kernel-basic-modules, kernel-core can Recommend or Require it - remove the Requires on kernel-core (or change to Recommends) from kernel-modules, so it can be installed standalone - move the Requires:linux-firmware (or change to Recommends) from kernel-core, have kernel Requires:linux-firmware I think this would be useful for playing with various minimization scenarios. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-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/devel@lists.fedoraproject.org
