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. Chris Murphy _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
