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. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
