option bootable in setup-storage

[Michael Tautschnig]

> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.uni-koeln.de/pipermail/linux-fai/attachments/20090507/74bca947/attachment.bin