Re: Guidance on conflicts between GNU GRUB and proprietary software

[Phillip Susi]

On 9/28/2010 4:04 AM, Colin Watson wrote:
>   * The BIOS can often only read from relatively near the start of the
>     disk, and core.img must be readable by the BIOS.  If some other
>     operating system is already installed - the common dual-boot case,
>     and the case where this problem is overwhelmingly most likely to
>     matter - it's likely to occupy a large stretch of partitioned space
>     right after the boot track.

If int13 can't access the whole disk then it does not really matter
where the grub core image is since it still has to use int13 to load the
kernel.  If the bios is broken, then grub might load, but can't load
your kernel.  Worse yet, it might all work fine when you install, then
you later upgrade something that rebuilds your initrd, and it happens to
get allocated further down the disk and suddenly you can't boot.  The
only sane way to deal with such a broken bios is to put all of /boot
near the start of the disk.

>   * The MBR format has so many irritating restrictions on primary
>     partitions that the more partitions an operating system needs to
>     create by default, the more stress we put on partitioning
>     algorithms.  (Most people don't notice any of this until they try to
>     install on a machine whose OEM helpfully created three or four
>     primary partitions already.)

With 3 partitions you should be fine since you only need one for the
extended partition.  What does the installer do now when all 4 are used?
 Doesn't it just bail out?  As long as you are creating an extended
partition to hold the root and swap logical partitions anyhow, you may
as well make one more for grub.