On Thursday, March 08, 2012 11:03 AM Felix Miata wrote:
On 2012/03/08 10:26 (GMT-0500) Dennis Gallien composed:
if Windows is installed I suggest we leave the DOS code in the mbr and boot.img in the pbr of the root partition; if root is on a logical the pbr of the extended primary must be used. Then set the active flag on that primary. Then check the mbr hole; if it is empty, use it for core.img, otherwise use the root filesystem and install boot.img accordingly.
http://tech.groups.yahoo.com/group/dfsee-support/message/13859 explains that *buntu installations usually make eCS unbootable by making a change in the 64 byte MBR partition table itself even when *buntu installation is to existing partition(s). I have no idea whether Grub2 installation is responsible for this, but it is something to watch for in 12.2's support and installation systems for Grub2. I don't recall ever having this happen from an openSUSE installation. It may well be *buntu's partitioning routine does this even when there's no reason to touch the tables, and has nothing to do with Grub2.
That's scary. I've seen programs which re-write table records rather than updating them, e.g., when the partition type is simply being changed. And IMO it's particularly risky if the table has already been created by another OS on the machine, a risk warned about in the partitioning utilities. (Years ago there were occasions where the only way I could get linux installed with grub was to first create a partition table from within Windows with PartitionMagic; wasn't there even once a time when SuSE was distributed with PM?) Anyway, if Ubuntu or grub2 is manipulating the table, be a good idea to know how and why. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org