DragonFly users List (threaded) for 2008-03
DragonFly BSD
DragonFly users List (threaded) for 2008-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Installation on Macbook Pro

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Wed, 19 Mar 2008 01:57:56 +0000

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 :)


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'.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]