BIOS boot - an alternative approach

[Ian Pilcher]

I'm not a Fedora developer, just a long time interested user, so take
this for what it's worth.  I'd like to suggest an alternative approach
to the BIOS boot (and potentially other similar boot issues), or at
least suggest that this approach be discussed.

Basically, I suggest that Fedora stop worrying about BIOS boot or other
"weird" boot configurations.  Instead, provide a truly manual
installation path where all boot and storage configuration is the
responsibility of the user.

This would include:

* Installing and configuring the boot loader.

* Updating the boot loader configuration when new kernels are installed
   (although anyone who desires should obviously be free to contribute
   packages that automate this for particular boot loaders).

* All storage configuration - creating partitions, RAID devices, logical
   volumes, etc.  (I.e. the Fedora wouldn't perform any sort of discovery
   of storage devices; the user would be responsible for selecting
   devices that already exist in /proc/partitions.)

* Booting *something* that can run the Fedora installer.

AFAIK, it's still possible to skip boot loader installation during
Fedora installation, and the live media installation path exists, so I
believe that the main work here would be to package the installer and
its associated runtimes, libraries, etc. into some sort of self-
contained package that is as independent as possible from the OS on
which it is running.

Not only would this provide a path for BIOS boot, and similar issues,
but it would also support other complex configurations.  (I can't even
count the number of Anaconda crashes I had back in the day with LVM on
MD-RAID.)

As I said, I'm not a Fedora developer, but I see this approach as
potentially eliminating a lot of work and increasing Fedora's
"flexibility" over the long term.

OK, now tear this apart.  :-)

-- 
========================================================================
Google                                      Where SkyNet meets Idiocracy
========================================================================

[Neal Gompa]

On Mon, Apr 18, 2022 at 11:26 AM Ian Pilcher <arequipeno(a)gmail.com&gt; wrote:
>  I'm not a Fedora developer, just a long time interested user, so take
>  this for what it's worth.  I'd like to suggest an alternative approach
>  to the BIOS boot (and potentially other similar boot issues), or at
>  least suggest that this approach be discussed.
>
>  Basically, I suggest that Fedora stop worrying about BIOS boot or other
>  "weird" boot configurations.  Instead, provide a truly manual
>  installation path where all boot and storage configuration is the
>  responsibility of the user.
>
>  This would include:
>
>  * Installing and configuring the boot loader.
>
>  * Updating the boot loader configuration when new kernels are installed
>     (although anyone who desires should obviously be free to contribute
>     packages that automate this for particular boot loaders).
>
>  * All storage configuration - creating partitions, RAID devices, logical
>     volumes, etc.  (I.e. the Fedora wouldn't perform any sort of discovery
>     of storage devices; the user would be responsible for selecting
>     devices that already exist in /proc/partitions.)
>
>  * Booting *something* that can run the Fedora installer.
>
>  AFAIK, it's still possible to skip boot loader installation during
>  Fedora installation, and the live media installation path exists, so I
>  believe that the main work here would be to package the installer and
>  its associated runtimes, libraries, etc. into some sort of self-
>  contained package that is as independent as possible from the OS on
>  which it is running.
>
>  Not only would this provide a path for BIOS boot, and similar issues,
>  but it would also support other complex configurations.  (I can't even
>  count the number of Anaconda crashes I had back in the day with LVM on
>  MD-RAID.)
>
>  As I said, I'm not a Fedora developer, but I see this approach as
>  potentially eliminating a lot of work and increasing Fedora's
>  "flexibility" over the long term.
>
>  OK, now tear this apart.  :-)
>  
Setting up boot stuff correctly for the myriad of configurations is an
area where Fedora provides significant value, so it only sounds good
to do this if we expect people to be able to manually do this. The
majority of people will not be capable of doing this properly, even
many advanced users won't be able to.

If you want to have an Arch-like installation process, the live media
does provide a way to do this in the form of all the partitioning
tools and DNF being available on the media. We don't provide an
Arch/Gentoo-style "minimal" media that people can use to run these
things, but pretty much any live media can be used for this purpose.

And frankly, I don't want to support some complex boot configurations
at a Fedora distribution level, such as /boot on LVM+LUKS. If someone
wants to set that up, fine, but it has enough pitfalls that it's not
worth broadly supporting.

Any "manual" installation process comes with the important caveat of
"we can't test it, so we can't support it" for whatever definition of
support you'd like to apply. :)

-- 
真実はいつも一つ！/ Always, there's only one truth!

[Alek Paunov]

On 2022-04-18 18:25, Ian Pilcher wrote:
>  ...
>  
>  Basically, I suggest that Fedora stop worrying about BIOS boot or other
>  "weird" boot configurations.  Instead, provide a truly manual
>  installation path where all boot and storage configuration is the
>  responsibility of the user.
>  
>  ...
>   
I am using Fedora in the way very close to your suggestion, except the
installer part. Since I am producing bunch of os instances of all types
regularly (for me and my users), many years ago, I replaced
Anaconda/kickstarts with ansible inventory per site (pure-man CMDB)
abusing the ansible groups inheritance as tool for quick instance
description. On top of these inventory calculations I have few stupid
playbooks:
* efi/legacy-pxeboot, lio-iscsi lease: optional, needed when the machine
   being installed is physical and blank (no ssh)
* disk-layout: gpt (sfdisk), mdraids, lvm groups/pools/volumes (direct
   commands, build in ansible modules are incomplete), mkfs/mkswap
   invocations.
* base fedora-image: systemd-nspawn+dnf (package list as sum of the
   classes in which the instance belongs),
   systemd.mount/swap/netdev/network, locale, etc.
* efi-boot/bios-boot (extlinux/pxelinux based in both cases): initial
   copy of the kernal/initramfs, extlinux --install, initial
   extlinux.conf - it is simple.

Then with the live (ssh accessible) freshly baked image - the usual
ansible setup (subsystems, users, user profiles), according the
instance purpose. When the new instance is a "upgrade", merge and
restore configuration overlay from previous system using fossil VCS at
/. On kernel updates, stupid python script in /etc/kernel/install.d/ for
keeping extlinux.conf in sync. Nowadays the extlinux.conf script is
superfluous - extlinux config could be generated on the fly form
systemd's /boot/loader/entries/ with a Lua script (syslinux have Lua
module), but I don't have written it yet.

So, not much drama, for the sites with a some techy guy around, there is
no shortage of variants (for both legacies support and efficient setup
methods). The really hard problem which Anaconda is supposed to solve,
are the new, non-tech users - somewhere in the Internet, alone, guided
by incomplete/wrong recipes, found on a random forum/blog by google :-).

Kind regards,
Alek