On Wed, 1 Nov 2017 at 15:27:48 -0400 Steve Litt <sl...@troubleshooters.com> wrote:
> On Tue, 31 Oct 2017 11:47:51 +0100 > Martin Steigerwald <mar...@lichtvoll.de> wrote: > >> Steve Litt - 30.10.17, 12:08: >>> On Mon, 30 Oct 2017 12:53:45 +0100 >>> >>> Martin Steigerwald <mar...@lichtvoll.de> 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. It's just a (sometimes compressed) cpio archive. > You can't debug it directly: What do you mean by this? > 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? Initramfs is indispensable when you boot a system: *) on an encrypted root partition; *) having a merged root and usr partitions and /usr on it's own partition; *) both of the above. I fact most embedded Linux systems do not have it. Red Hat used dracut to manage initramfs, De*an and like distros use initramfs-tools. Alessandro _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
