DragonFly users List (threaded) for 2008-03
Re: Installation on Macbook Pro
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
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
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