Preparing Change Proposal: Modular Kernel Packaging for Cloud - Feedback?
In the past ~24h, I've been preparing the Modular Kernel Packaging for Cloud change. Before I submit it to the wrangler, I'm looking for everyone's feedback. Note this is my first change proposal so I might have misunderstood things or whatever. https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud Note, that I haven't yet reached out to the Anaconda team (regarding the possibility to install kernel-core instead of kernel) but will do so now. They don't seem critical to the change, though but just to the way we're implementing it when creating the images. (Assuming we will use Anaconda to build F21 images). Thanks, Sandro ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Modular Kernel Packaging for Cloud
On Fri, Mar 14, 2014 at 11:00 PM, Bruno Wolff III br...@wolff.to wrote: On Fri, Mar 14, 2014 at 16:42:11 +0900, Sandro \red\ Mathys r...@fedoraproject.org wrote: Okay, I poked around in the yum source, yum docs and kernel packages a bit. So yum (and some testing confirms, dnf too) does not check the package names but the provides (obviously, thinking about it). The actual magic being that both kernel and kernel-core provide kernel. If that is still the case once the patch is merged from copr to Fedora, no changes to yum or dnf should become necessary. Which would probably leave us with anaconda must allow for installing only just kernel-core instead of kernel (when kickstarting) as the only necessary change to Fedora. I guess. The behavior is controlled by the installonlypkgs setting in yum.conf. From the man page: installonlypkgs List of package provides that should only ever be installed, never updated. Kernels in particular fall into this category. Defaults to kernel, kernel-bigmem, kernel-enter‐ prise, kernel-smp, kernel-modules, kernel-debug, kernel-unsup‐ ported, kernel-source, kernel-devel, kernel-PAE, kernel-PAE- debug. I believe kernel-modules-extra also got added to the default relatively recently. But that change doesn't seem to have made it to the documentation. (That package provides installonlypkgs(kernel-module), so there might be some extra magic related to that provide.) kernel-modules-extra hasn't been added, but installonlypkgs(kernel-module) has been. Well, at least that's what I see in the current code on git. And kernel-drivers also provides installonlypkgs(kernel-module). -- Sandro ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Modular Kernel Packaging for Cloud
On Fri, Mar 14, 2014 at 11:25 AM, Sandro red Mathys r...@fedoraproject.org wrote: On Sat, Mar 15, 2014 at 12:06 AM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Mar 14, 2014 at 03:46:02PM +0900, Sandro red Mathys wrote: Yesterday, I updated to Josh's 2.5 kernel, then I removed kernel and kernel-drivers, only leaving kernel-core. Today, I again updates, this time 3.8 being available. Now guess what? The install instead of update magic worked. I know have both kernel-core packages. So I figure yum works this magic with any kernel* package. And this is why I should read all the mail before responding. :) How about the removal protection? Oh, good catch. Also, that's a funny one. So, you can't remove the currently running kernel-core. As expected. BUT, you can remove the currently running kernel/kernel-drivers. That's good because we want those packages to be optionally (un)installable but bad because if you actually require kernel-drivers, well, it's obviously bad. Require is the word that needs further definition. Not sure if there's a good fix to this. We'd either limit people to only being able to get rid of kernel-drivers with some dancing around with different kernel versions and some rebooting, etc. Or we allow people to remove the kernel-drivers of the running kernel which defeats the purpose of the protection. #leSigh I don't think we want to over-complicate things here. Removing -drivers from a machine, whether it's running the corresponding kernel or not, shouldn't be a huge deal. They might not have support for some hotplugged device in that case. Also, it's not really going to be a common case for people to do. Oh (#2), and here, dnf actually differs from yum. dnf protects *none* of the packages. So that's definitely a bug and I'll report it once we know exactly what behavior we want (so that yum and dnf will do the same thing). That's not a bug. They did that on purpose. There was a big thread about it on the devel list a while ago. josh ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Modular Kernel Packaging for Cloud
On Sat, Mar 15, 2014 at 12:25:48AM +0900, Sandro red Mathys wrote: Not sure if there's a good fix to this. We'd either limit people to only being able to get rid of kernel-drivers with some dancing around with different kernel versions and some rebooting, etc. Or we allow people to remove the kernel-drivers of the running kernel which defeats the purpose of the protection. #leSigh I think the first is preferable; the main case where you get a kernel without the drivers package is when you're building something intended to be small, and going downwards isn't the way to really do that. Oh (#2), and here, dnf actually differs from yum. dnf protects *none* of the packages. So that's definitely a bug and I'll report it once we know exactly what behavior we want (so that yum and dnf will do the same thing). Apparently this is by design in dnf; it's one of the features they didn't see as valuable. Which is funny to me because that was the case with yum initially too (we wrote it as a plugin for that reason) but over time it became a core feature). -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
Re: Preparing Change Proposal: Modular Kernel Packaging for Cloud - Feedback?
On Sat, Mar 15, 2014 at 12:04 AM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Mar 14, 2014 at 09:52:15PM +0900, Sandro red Mathys wrote: In the past ~24h, I've been preparing the Modular Kernel Packaging for Cloud change. Before I submit it to the wrangler, I'm looking for everyone's feedback. Note this is my first change proposal so I might have misunderstood things or whatever. https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud Looks basically good to me. I added the additional benefit about possibly reduced need for security updaes. Thanks. If we are not including Anaconda developers as owners, I think that goes under the dependency section. Right, I didn't add it as the kernel split itself does not technically depend on Anaconda. But on the otherhand, I required the adoption in the scope. So I now added a note to the scope that it's not absolutely critical for the actual change and added it as a soft dependency, too. I know, we absolutely do want it (and I think the Anaconda team has already taken the necessary steps) but technically splitting the kernel does not depend on it. Have you tested how yum/dnf work with upgrades (and with yum's feature for protecting the running kernel from being removed)? Those might need to go in scope and deps too. Continuing this discussion in the other thread. :) -- Sandro ___ kernel mailing list kernel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kernel
