[OpenBIOS] [commit] r832 - in trunk/openbios-devel: arch/sparc32 drivers

Mark Cave-Ayland mark.cave-ayland at siriusit.co.uk
Mon Aug 9 10:50:55 CEST 2010

Tarl Neustaedter wrote:

>> The problem is that some images don't have a bootable partition in
>> 'd', but 'a', any of these fail because only the first device is
>> attempted in boot-device list. The automagic partition change hack may
>> mask this.
>> [...]
>> In the NetBSD case, 'a' is not bootable but 'd' is. Aurora 1.0, Zoot
>> (Red Hat Linux 4.0) and SuSE 7.3 only boot from 'a'. In some images
>> (for example Debian 4.0R5) 'a' and 'd' are equivalent
> Some history behind the boot partitions - if you look at the man page 
> for mkisofs, under the -sparc-boot switch, you'll see the various 
> partitions which were reserved for particular architectures. My 
> recollection is that partition ":d" was for the "dragon" architecture, 
> from about 15-20 years ago. The current generation of SPARCs use 
> partition ":f" (and have for at least a decade), although we may be 
> changing that to ":a" fairly soon.
> Current Sun/Oracle release DVDs are created such that all eight 
> partitions point to the same physical blocks. You can boot from any of 
> ":a" through ":h", and Openboot will be equally happy.
> Solaris itself isn't quite as flexible. The common label parsing code 
> does a bunch of geometry checks on the partitions, and unless it 
> identifies the disk as a read-only removable media, will completely 
> discard the label and return a "default" VTOC where only partitions 0 
> and 2 (:a and :c) exist, and they occupy the entire disk. This will 
> matter to you only if you get pretty far into booting Solaris.

Wow, I think I start to understand this now. As I mentioned in my 
previous email, the Forth is very simple for parsing boot-device - it 
simple opens each device in turn and returns the first one that returns 
a valid ihandle (as per the spec).

My guess is that the bug Blue is seeing is that actually 
packages/sun-parts.c is somehow returning a valid ihandle for a slice 
when it shouldn't (as Blue suggests it is perhaps related to the 
automagic partition hack).



Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

More information about the OpenBIOS mailing list