Re: BIOS boot - an alternative approach
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 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: BIOS boot - an alternative approach
On Mon, Apr 18, 2022 at 11:26 AM Ian Pilcher 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! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
