Re: Installation on Macbook Pro

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Christopher Rawnsley wrote:
> Here is a little update for my problem...
>
> On 12 Mar 2008, at 02:48, YONETANI Tomokazu wrote:
> > IIRC, you need to fiddle with ad5*.  A better alternative I can think of
> > is to partition (or maybe even disklabel it and newfs -O1) using FreeBSD
> > installer first, then boot with DragonFly LiveCD, and continue the rest
> > of procedure explained in /README .
>
> Formatting with FreeBSD worked fine. FreeBSD appeared to have formatted 
> the disk differently by switching the slice order. So the 165 ID 
> (DragonFly/Free BSD) slice came before my 175 ID (HFS+) slice even 
> though the physical disk layout was the other way round (Significant at 
> all?). I now had a properly sliced drive so I rebooted with DF which 
> could now write to the disk :). Thank you for that, Yonetani.
>
> So I rebooted and this time booted from the hard drive. Boot loader came 
> up! Unfortunately, it couldn't boot the DF slice. So I went back to the 
> CD and (this is where I got a bit stupid...) fired up fdisk to check 
> everything out. Nothing to odd. Had a look at gpt's output too. Which I 
> found to be a little odd. The DF slice shared the same index (of 1) with 
> my EFI slice with Mac OS X at index 2.
>
> Let me first explain that, from what I read, in order for a computer to 
> comply with EFI they have to have an extra slice set aside for EFI. On 
> my laptop that means that I have this in the form of a 200MB slice with 
> the rest for whatever.
>
> Now I remember seeing when Mac OS X and Windows
> was installed, I booted into the DF live CD and ran gpt. The output that 
> time around was EFI slice at 1, Mac OS X at 2 and Windows at 3. Even 
> though I don't think boot0 can boot from the GPT, I wonder whether the 
> FreeBSD installer changed something in a similar way to the MBR. Very 
> speculative, I know but I can't check out anymore 'cause...

Side Note:  Recall my saying Apple marched to the beat of a different 
orchestra?

If memory serves, this is where some of that shows.

There isn't just one such 'hidden' slice - there is one preceding *every 
other* slice/partition. I.E. my 6 UFS slices, having been set up with OS 
X have 6 100 MB slices in between them.

There is information about this online in OS X-specific articles, and it 
is why I suggest using a separate HDD entirely, as I do with *BSD/PPc 
(FW800 is *fast*, and even USB 2.) is decent)

> Going on my hunch that something in the MBR was wrong and was causing 
> boot0 to not read it properly I decided to open up fdisk and see if I 
> could find anything that might be a cause. I checked each slice through 
> using the -u option (IIRC) and when I got the the Mac OS X slice it 
> complained about the head boundaries being all wrong. I rather stupidly 
> thought that I'd let it automatically update this. This caused nothing 
> to boot etc. Long story short I ended wiping everything in favour of it 
> being quicker for me (I had deadlines to meet...). It was all backed up 
> so hopefully that won't keep anyone awake at night!

Just for 'education' as to how different things really are - creadm, but 
do not alter, with both fdisk and disklabel from FreeBSD/PPc AND OpenBSD 
PPc as well as DFLY.

> I think I will come back to DF in the not so distant future but I'm just 
> going to let myself go on other things for now. Thanks a lot to all you 
> guys who tried to help me. I really appreciate it :)
>
> --
> Chris
>
> P.S. Would it be possible to by pass the MBR all together in favour of 
> GPT by simply using another boot loader other than boot0 

Yes - though that isn't entirely 'bypassing' the MBR in all cases, it 
can be made so.

See the various 'boot floppy' methods, including grub (compex for 
complexity's own sake, but flexible) and 'GAG' (simple, but effective) 
or even Warp LVM if you can get your hands on a copy - then think USB 
stick instead of floppy.

It is also fairly easy to alter and re-assemble boot0 to build a custom 
loader. Even if asm language is not your long suit, the code is in 
'symbolic' assembler, and there is very littel of it, so is easy to 
grok. (Mine drops never-used-here FAT/NTFS/DOS recognition in favor of 
grokking Minix, Solaris, Syllable, fs types for example)

> or would this 
> also require changes in the kernel or elsewhere?

Not required - yet.

Potential gains *could* be had where multiple controllers and drives 
exist - my 'normal' environment.

What is wanted is that the next two stages are as BFBI simple as boot0.

Ex: If changing drive order (cartridges, externals) or controller 
channel-order, the visible part is an fstab that 'follows suit'.

In FreeBSD or DFLY, this can be accomplished by creative disklabeling 
and such, e.g. :

- set up a RAID1 array with (n)atacontrol, even if you never add the 
second drive.  fstab will have entries such as /dev/ar(x)s(n) - which 
will be 'found' even if the devices of the set that had been /dev/ad0 
moves to /dev/ad6 or ad10. Similar with GEOM / GMIRROR in FreeBSD.

- in FreeBSD (haven't tested with DFLY), use /dev/ufs/<label> instead of 
/dev/ad(x)s(n). Likewise, these will be 'found' regardless of channel 
re-ordering.

One of the 'opportunities' ("There are no 'problems'...") w/r trying to 
use info from the disklabel, however, is that nearly all of the ffs/ufs 
'players' have drifted apart w/r their use and interpretation of fdisk 
(slightly) and their disklabel (very significantly). For FreeBSD / DFLY 
the differences do not always show. OpenBSD OTOH makes you think you 
have accidentally booted DRDOS...

I don't see that changing - nor 'all other' os & fs vanishing.

So IF one is to be able to mix and match - one either needs - grub or 
OS/2-LVM-style - a boot manager that stands above the fray - essentially 
a mini-OS - ELSE to move to a 'none of the above' universal-donor fs 
type - at least for booting.

After that - the full weight of the OS is in-hand, and there are tools 
to mount <whatever> from <wherever>.

'Short term' the answer may be to make use of increasingly universal 
large RAM, load a lean toolset into RAM as a live cd does, then go off 
and *inspect* the available media, report  findings, and await 
instructions or time-out to last used boot device.

Not hard - we did it in asm on dual-FDD-controller CP/M machines that 
could haul 16 8" and 16 5 1/4" drives from a dozen different makers, ID 
them by probing their indexing schemes (soft, songle-hole, multi-hole, 
inner track, outer track) and disk layout.

But bloody *tedious*....

We again live in 'interesting times' w/r flexible, but not fully mature 
'standards'.

Bill