[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Grub installation. First potential Fedora killer



On 01/09/2014 03:41 AM, Chris Murphy wrote:
On Jan 8, 2014, at 9:52 PM, Adam Williamson <awilliam redhat com> wrote:
but while playing around with this and writing up a blog post, I did
think of a possible scenario where someone might really really not want
us to install a bootloader at all - if they're using a shared /boot.
Yes it's a valid question, but it's also a matter of folklore and chicken bones. You do it, and it breaks something, the doctor will just say, "yeah, duh, don't do that." And if it doesn't break, the doctor shrugs and says, "so what's your question?"

Is that a case we want to care about? There are ways to do it...we
*could* always set it up so that you can do a full bootloader install,
config but no MBR install, and no bootloader stuff at all, but that's
adding more complexity to bootloader UI again so it might not be wanted.

We could also, I suppose, put in some 'smarts' so that if you 'disable'
bootloader installation you get 'configuration but no MBR install' if
the partition containing /boot is being created/formatted, or 'no
bootloader stuff at all' if it's being re-used. That doesn't add any
more UI complexity, but it adds some code complexity.

Anyone have thoughts on this?
I'd say this is not a user domain question. If the installer is willing to climb into someone else's sandbox, it must have a no overwrite policy. It can add, but it can't delete or overwrite. I'd even say by default it shouldn't overwrite the MBR. grubby will look for every possibly location of every bootloader config file, and would simply add a Fedora entry to whatever is already being used as a bootloader on that system, anaconda doesn't need to do anything to make that happen.

On the other hand if anaconda can't avoid stepping on other people's stuff in the sandbox, then it shouldn't climb in and therefore ought to only support a new or reformatted /boot.

If I had to pick one, I'd say don't support shared boot. There's no partition shortage, at least from a GRUB point of view.


OK, here are some additional thoughts/considerations ...

1. What this does for grub2 also applies to when syslinux/extlinux is the bootloader. There are some situations when it is desireable to have anaconda do all the configuration it now does but not do the extlinux --install or install a new MBR or change the active/bootable flag on the partition.

2. There may be a need for a new kickstart command which specifies a directory where the /boot files would be installed (kernel, initramfs, syslinux/extlinux, etc.). In a regular gui install, this directory could default to using the machine-id with the result that everything for this install goes into /boot/<machine-id>/ rather than /boot. Yes, this can be done with a complicated post-install script or after install process but it would be a lot easier if there were some enabling capabilities.

3. There appears to be a lot of effort going into support of UEFI and currently grub2 is the bootloader because it alone supported EFI. That is no longer the case since syslinux-6.02 supports the "old" bios as well as efi64 and efi32.

Gene


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]