[illumos-Discuss] multiboot-fu needed

Mike Riley lvskiprof at cox.net
Wed Sep 15 22:36:52 PDT 2010


On 09/15/10 17:10, Andrew Gabriel wrote:
> Mike Riley wrote:
>> On 09/15/10 07:53, Garrett D'Amore wrote:
>>> If you plan ahead for this and use slices (which are kind of like
>>> 'partitions in a partition') intelligently, you can have many different
>>> installs of Solaris. I think on x86 hardware up to 16 slices are
>>> supported on a given partition. (On SPARC its only 8.)
>>
>> Correct about the slices. An RFE I filed way back when proposed a way
>> to let SPARC also get 16 slices. The only reason it still has 8 is for
>> backwards compatibility with SunOS.
>
> The VToC format is quite different.
> Sparc obviously has to maintain compatibility with OBP.
> x86 uses the SVR4 VToC format which is why it gets 16 slices (and if you
> patched the FDISK partition type, its disks were just about
> interchangeable with other SVR4's unixes, back when there were some
> other SVR4's).

Yes, the proposal in the RFE was not for the boot disk, but for removable drives.

>> The idea of the RFE was so that removable disks from an X86 system
>> could be read and written on a SPARC system for data interchange.
>
> Well, ZFS on GPT/EFI has done that now (except for the boot disk).

Very true, but those didn't exist back then.  You still don't see GPT flash drives though, at 
least I have not.  But as I recall (back from 2007 or 2008) the GPT code for SPARC and X86 was 
not compatible, has that been addressed yet?

>> Unless format has been updated you can only view and set the slices
>> past 7 using prtvtoc/fmthard.
>
> I also fell over live upgrade grub boot support breaks with slice
> numbers > 9 (i.e. more than a single digit).

Should be fixable though.  In the menu it is just a letter (a for s0, etc.).  Probably the code 
was not written by someone that knew we had 16 slices available.

>> As you should be able to tell from my posts on this thread, I have
>> been inside this code for years, and have wanted to fix it forever...
>
> I always wanted the *p0 device on sparc (whole disk, regardless of any
> slicing/partitioning). It was difficult to use disks on sparc which had
> some alien OS's partitioning scheme, but it works fine on x86, using the
> *p0 device and decoding the alien OS's partitioning in your own software.

That had been part of the original design concept to eliminate the disk geometry as Larry Lee 
proposed it.  Didn't that get put in?

Mike



More information about the Discuss mailing list