option bootable in setup-storage

Michael Tautschnig mt at debian.org
Thu May 7 20:38:11 CEST 2009

> 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


-------------- 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 

More information about the linux-fai mailing list