On 2012/03/07 11:22 (GMT-0500) Dennis Gallien composed:
Where are we locating core.img, the disk's extended area just past the MBR or in a filesystem? IIRC the manual recommends the former over the latter. Both locations have vulnerabilities. I seem to recall that the master's extended area is sometimes used by MS e.g. for BitLocker, and perhaps other vendors use this space too for proprietary purposes, although these are quite unusual.
Depends on your definition of "unusual". OS/2 & eCS have long used the last sector on the first track for IBM Boot Manager data. Now eCS is shipping with a replacement boot manager called AiR-Boot, which has been using sectors following the MBR sector for its whole existence. http://air-boot.sourceforge.net/ What AiR-Boot is that Grub2 is not is user-friendly.
But a filesystem is vulnerable to moving blocks which can render the address hard-coded into boot.img invalid.
Besides this issue, there is another vulnerability with using a filesystem - getting the address to embed into boot.img wrong in the first place. Here again grub2 has an advantage over grub1 when using the MBR extended area for core.img. The grub installer program checks several data to determine the disk address of core.img, including making a bios query. Sometime the address is just plain wrong. In my tests with grub1 and for a reason I cannot explain, this happened more often when stage1 was looking for grub on a logical partition. If core.img is placed in the MBR extended area, it is always in exactly the same location on disk and so the address hard-coded into boot.img will always be correct.
But MBR is not "compatible" with multibooting Windows, which seemingly at every opportunity will replace the MBR code with generic boot code, putting Grub in need of repair.
Given the above, it seems that it would always be best to install boot.img to the MBR and core.img to the area immediately following, unless that space is already used
Only thrice has Grub been installed on any MBR of mine. The first was Corel Linux, which shipped with WordPerfect, which I eventually learned how to install without overwriting the MBR. The second was Xandros, which apparently at the time could not be installed without overwriting the MBR. The third was 12.2M1, where at one point during boot loader configuration I wasn't paying close enough attention after doing a goback from entering an unwanted step, which resulted in changing what I had changed to get the bootloader off the extended and MBR and onto /. IOW, they've all amounted to accidents. Grub is unlikely ever to be installed to any MBR of mine on purpose, because there's _always_ some way to make a system bootable via generic MBR code, and thus no need to replace standard code with non-standard code that depends on configuration on some partition and/or boot track sectors to work at all.
For users who already have Windows installed, this means writing over the DOS code in the MBR (as already is frequently done in installation now).
This amounts to a huge percentage of installs, almost a general rule, and most difficult as to first time would-be converts from Window to Linux.
It would be good to have a simple recovery mechanism whereby /usr/lib/master-boot-code could be written back to the MBR, or at least instructions somewhere on how to do this with live-media, in the event the grub installation fails; the machine would then at least be bootable again.
But of course the problem is easily avoided by Air-Boot, .... or by
The alternative to this is to not use the MBR at all for grub, which means using the generic code in the MBR with the active flag set + a primary PBR for boot.img + a filesystem for core.img, and with that back to the problems above.
Such problems I don't have. But then, I generally try RTFM first instead of waiting to see what damage needs repair. And I know how to avoid these issues: http://fm.no-ip.com/PC/install-doz-after.html -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org