search

fosslinux / live-bootstrap

Use of a Linux initramfs to fully automate the bootstrapping process
286 stars 26 forks source link

Upgrade Linux kernel to 4.14.336 #442

Closed Googulator closed 4 months ago

Googulator commented 4 months ago

This is the last LTS version buildable using GCC 4.0.x. The next one, version 4.19, requires at least GCC 4.6.

Fortunately, this is also the first version of the Linux kernel without firmware blobs being included in /firmware, so the FSFLA deblob scripts aren't needed anymore to ensure a fully auditable kernel - the 3 remaining drivers that do include blobs masquerading as source code are removed via a patch, avoiding all the other side effects of the deblob scripts. This doesn't compromise the trustworthiness of the bootstrapped environment, since all the other drivers deblob would remove use the firmware loader mechanism, which does nothing when the actual firmware blobs aren't installed on the system separately. Features dependent on firmware still won't work, but many drivers that load firmware do so only optionally. This includes r8169, the driver for the Realtek gigabit NICs found on many x86 motherboards.

This kernel is considerably larger than 4.9.10, and we build more of it (including drivers that would previously get stripped away by the deblob script, such as r8169), so to accommodate that, Fiwix initrd size is increased by 64MiB, while lowering kexec space by the same amount to ensure enough userspace memory available in Fiwix. Fiwix's maximum open file count is also bumped from 1.5K to 2.5K.

The Documentation folder is deleted before build, to further save space in the ramdisk.

Depends on #438 and https://github.com/oriansj/stage0-posix/pull/78

Fixes #330

fosslinux commented 4 months ago

Config notes:

Googulator commented 4 months ago

Config notes:

* Different types of initramfs compression - do we need to care about anything other than gz?

The xz, lzo, etc. libraries still get included in the kernel for other purposes, so the space saving is minimal; on the flip side, keeping support here means we can in the future easily save RAM in Fiwix by decreasing the kexec buffer size and using higher compression for the initramfs.

  • CONFIG_X86_BIGSMP=n. Should we enable this? Supports >8 "CPUs" which I think in kernel land might mean cores? Someone confirm please. Nice catch, I was wondering why I can't set the max core count higher than 8, this is probably it.
  • "Processor family" for optimisations appears to be set to "Pentium Pro" right now. Do we want to lower this? I think we'd technically support as low as 686 at the moment, so we should probably target that in the kernel. "Pentium Pro" is Intel's trade name for a 686. The kernel offers no option for a "generic 686", as at that point, Intel's and AMD's implementations were diverging significantly. I'd, however, consider upping the requirement (-march) to Pentium 3 and equivalent for AMD, with optimal tuning (-mtune) for Intel Core 2 and higher, since realistically that's as low as we can go, due to RAM requirements (i.e. no 686 can support 2GB+ RAM).
  • I suspect we can disable all mouse support. I don't think we need the savings from that right now, if it's even significant. I'd leave that for a future size reduction opportunity, if ever needed, especially since we already had mice enabled in 4.9.10.
  • I think CONFIG_DRM_I915 can be disabled, that's an X-level driver I believe? CONFIG_DRM_I915 (and other DRM drivers) isn't just for X; DRM drivers are the recommended way of getting a high resolution framebuffer on modern kernels, the plain-FB drivers are deprecated-ish and can even cause problems. In fact, I plan on switching to nouveau/radeon/amdgpu and disabling their FB counterparts, because nvidiafb turned out to be the cause of the green screen freeze bug on newer GeForce cards. (And yes, this functionality works without any firmware loaded; firmware is only required for 3D acceleration.) This will, of course, be a followup PR, especially since it requires additional tricks to keep ramdisk usage under control.
  • Maybe enable CONFIG_KVM, CONFIG_KVM_INTEL, CONFIG_KVM_AMD? I can imagine that one might like to run live-bootstrap within live-bootstrap on a bare metal system to verify they are the same. KVM, unfortunately, doesn't compile with our current toolchain; I tried to patch it out, with no luck. It causes undefined reference to `__compiletime_assert___COUNTER__' errors at the final link, and unlike drm_edid, this doesn't seem to be patchable just by removing BUILD_BUG_ONs.
Googulator commented 4 months ago

With that, I think I will merge this now, and address the config issues in an upcoming 2nd PR, which should include the nvidiafb -> nouveau switch (so we don't lock up hard on newer GeForces, which nvidiafb unfortunately does), alongside other improvements.