Re: kernel rpm split

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

 



On Fri, Feb 7, 2020 at 8:27 AM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
>
> On Fri, Feb 07, 2020 at 12:09:37PM +0000, 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@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