Mailinglist Archive: opensuse-factory (715 mails)

[Dennis Gallien <dwgallien@xxxxxxxxx>]

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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx