On Tue, 31 Oct 2017 11:47:51 +0100
Martin Steigerwald <martin@???> wrote:

> Steve Litt - 30.10.17, 12:08:
> > On Mon, 30 Oct 2017 12:53:45 +0100
> >
> > Martin Steigerwald <martin@???> wrote:
> > > Actually I´d make firmware pretty dumb and implement as much as I
> > > can in loaded software. Just enough firmware to actually
> > > install / boot a bootloader which loads an operating kernel and
> > > initial ram disk.
> >
> > Which is pretty much what we had in MBR. Which is why I always try
> > to boot MBR.
>
> I now read through the slides about NERF and well… it appears that
> with non extensible they have simplicity in mind. They relay all the
> extensibility to the go based user space Initramfs. I am not sure
> whether some go based thing would have been needed her but I am
> thankful for any efforts to rid systems of proprietary firmware crap.
> Even better tough: Not putting in the crap in the first place. No
> crap inside? No effort needed to rip it out again.

Initramfs is another mess. You can't debug it directly: You sort of
have to take a time machine back (or forward) to ultra-early boot.

I've lost the battle to keep your average Linux distro sans-initramfs,
so now I'm fighting a lesser battle: How much stuff do you want in your
initramfs, where realtime debugging is increasingly difficult and
increasingly owned by Redhat?

The stated purpose of initramfs is to boot far enough to mount the root
partition, after which everything else can be mounted via /etc/fstab.
Unless the executables do do such mounting have been placed off the
root's tree, in which case those must be available on the initramfs.
The more that goes in initramfs, the higher the barrier to entry for
the DIY Linux person.

SteveT

Steve Litt
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21