On Wed, Jan 09, 2008 at 02:07:20PM +0100, Jan Nieuwenhuizen wrote:
> Robert Millan writes:
>
> > The problem with that is it can't really solve the problem, only provide a
> > half-baked solution. If you include pc and gpt, you're misusing space in
> > a component where it's really critical, and you still don't support all
> > partitions GRUB might be installed on. For that, you'd have to load _all_
> > partition maps, which means even more space.
>
> I understand, and I've been wondering about this. As I do not have much
> if any knowledge for the sizing constraints of a bootloader, so I cannot
> appreciate the efforts of reducing space.
The mission of core.img is being able to access /boot/grub, from where you can
load anything you want. It has to be as small as possible, because if it won't
fit in partition boot record, this can be a significant inconvenient.
Ironicaly, the big problem is for LVM/RAID users themselves:
if (must_embed && !able_to_embed)
grub_util_error ("Can't embed the core image, but this is required when\n"
"the root device is on a RAID array or LVM volume.");
> As a (blonde) user,
Uhm how is the color of your hear related to this? :-)
> I would think that you'd want to use *as much*
> rather than as little space you can. Why not (from a sizing pov,
> stability could be another issue), after core.img contains
> all necessary modules, fill up any `remaining' space (if that is how it
> works) with extra non-essential modules? Little harm in the ability
> to read more devices, I would say?
No, the goal in core.img is not to provide useful features, just access
/boot/grub. It has to be as small as possible. The smaller, the more
chances it'll work.
--
Robert Millan
<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
