> Hi, > > Michael Tautschnig wrote on 2009-05-07 06:17:28 +0200 [Re: option bootable in > setup-storage]: > > > [...] > > > I'm just wondering ... what happens if / is on a logical partition or > > > LVM LV? > > > > I do test for / being on a real disk and only set the bootable flag (or > > actually the value in the hash that will later cause the bootable flag to > > be set) only in such cases, so we should be fine. But anyway, thanks for > > looking closely! > > I wasn't really worried about the implementation. I was wondering about the > concept. I don't fully understand the implications of the matter, so maybe my > point is, err, pointless. > > Ideally, the config file specifies which partition (if any) is to be marked > bootable. If none is marked, we have the root partition as default, if (and > only if) it is on a primary partition. Otherwise we have no default. > > The historical purpose of the bootable flag (as I understand it, on x86 > systems) is to tell DOS MBR which partition to boot. With lilo, grub et al. > this is obsolete. I take it some BIOSes make a misguided attempt of > plausibility checking and only boot the MBR if a partition is marked bootable > (this assumption is - possibly incorrectly - deduced from the initial issue > of this thread). Sure, DOS MBR *can* boot a grub stage1 or lilo boot sector > off a primary partition (which would, thus, need to be marked bootable), but > this can just as well be /boot or even /usr/local/foo if someone were inclined > to set it up that way. >
My impression also was that this isn't that much needed anymore, but as the initial author of this thread had problems with such situtations, your analysis seems to be correct: Most of the time it works even without anything being marked bootable, but sometimes it doesn't. > My point is: the default of / can be wrong, there remain cases without a > default, and there are cases where no partition needs to be marked bootable, > so what is the point of providing a default in the first place (which can > really just be a convenience to save typing, but not thinking)? > Put differently: the current solution is complicated to define, which might > mean it is not optimal. > > Then again, I might be missing important facts (especially on non-x86- > platforms) ... > You're definitely right: It is somewhat complicated to define and the defaults might even be wrong. I'm open for either change: Make setup-storage use the currently experimental new "default is /" code, or, instead, change the man-page to match what is currently in FAI 3.2.20. Both solutions are really easy to implement, it's rather a matter of what the majority perfers. Even though a bit bogus, I'll for now leave the situation as is: One possible bugfix is ready, but it stays in experimental. I'll just wait for further feedback. Best, Michael
pgpwvWwNIsqNC.pgp
Description: PGP signature
