On 2020-02-07 09:56, Stephen John Smoogen wrote:
On Fri, 7 Feb 2020 at 09:28, Zbigniew Jędrzejewski-Szmek
<zbys...@in.waw.pl <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
> <zbys...@in.waw.pl <mailto:zbys...@in.waw.pl>> 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 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 to work with the contemporary initrd generation process that
predated dracut and it was awful. Every iteration required tweaks.
Dracut was another tweak, a big one. But you know what? Once my process
adapted to dracut, it really hasn't needed to change since -- thanks to
a beautiful plugin setup. Adoption wasn't too hard either thanks to
easy-to-read shell script (some of the best I've seen).
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.
I guess I just split my $0.02 in half.
_______________________________________________
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
