So the question still remains as to how big the initrd image will be assuming it has to have the necessities to mount root on lvm encrypted drive. Any idea?
Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------- Original Message -------- Subject: Re: [coreboot] kernel payload Local Time: May 5, 2017 1:14 PM UTC Time: May 5, 2017 7:14 PM From: coreboot@coreboot.org To: ron minnich rminnich@gmail.com coreboot@coreboot.org coreboot@coreboot.org
Thanks for the offer. I'll think about it once I can get a linux kernel working in my own hardware. :)
There is no dedicated serial port though I guess I could do serial over usb if I needed to.
It makes more sense to me to start by using the kernel I already have if possible and move to a custom kernel once I know that works. I have enough space for a kernel at this point though depending on the combined size of kernel + initrm I may run into a problem. I'm really not sure how big the initrd will end up being or if there is an option to link to the initrd on the hard drive.
Sent with [ProtonMail](https://protonmail.com) Secure Email.
-------- Original Message -------- Subject: Re: [coreboot] kernel payload Local Time: May 5, 2017 12:14 PM UTC Time: May 5, 2017 6:14 PM From: rminnich@gmail.com To: Healer64 Healer64@protonmail.com coreboot@coreboot.org coreboot@coreboot.org
neat! Do you have serial console or just graphics?
We've been doing a lot of this linux payload stuff lately. I assume you can recover from a bad image. If so, I'd recommend building a kernel with kerneltiny config (or whatever it's called -- tinykernel?), add back in console support of your choice, set the command line in menuconfig for earlypintk=tty0 or ttyS0,keep and boot it and see how far it gets. the kerneltiny configf can get you to a 400K bzImage so it's worth the effort to start small and grow it up -- that's how we've done it in my project at Google (not a chromeos project, though I'll be talking about it this fall).
To give you an idea of just how far the tiny kernel stuff goes, it removes all tests for uid != 0 and also all options to set uid to !0. This makes sense in a firmware payload. There's a lot of space saving options in that config and that's how you get a tiny kernel.
Once you get past this point you can then look at what initramfs to add. Or maybe you are past that point, but let's talk. I've been doing this a lot for the past year and I have probably made lots of mistakes I can help you avoid ...
BTW, I'm looking for people to work with on a project embedding Linux and a Go userland in flash, so if anyone out there wants to get involved, please, we need your brains. see u-root.tk.