On 01/09/2014 03:41 AM, Chris Murphy wrote:
On Jan 8, 2014, at 9:52 PM, Adam Williamson <awilliam@xxxxxxxxxx> 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
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
