On Mon, Aug 9, 2010 at 8:50 AM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
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.
'd' was for sun4m (ss-5, -10, -20 etc.). 'Dragon' was a codename for sc-2000, which was sun4d.
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).
Yes, that was the problem, partition check never failed. I'll commit a fix.
BTW, it looks like Sparc64 boot has been broken at some point.