Re: kernel rpm split

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> <zbyszek@xxxxxxxxx> 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
> > > <zbyszek@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux