Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have read through and undertaken Linux From Scratch (and BLFS) and I was wondering, can I follow this guide to create a Darwin Distro by substituting the xnu kernel? Would the process be vastly different to that outlined in LFS?

My current understanding is that all that would be required to make the system "Darwin" rather than "Linux" would be the kernel substitution. Is this correct?


EDIT:

In response to killermist's comment, I shall refine this question. While I am looking for information about this topic generally, what I am specifically looking for is something like a "Darwin Distro Creation Guide" much like the LFS is a "Linux Distro Creation Guide".

I appreciate that such information will probably only come from the folks from Puredarwin, OpenDarwin or GNU/Darwin so this is something of a callout to them for help. A "How-We-Made-PureDarwin-Nano-Start-To-Finish" guide like LFS would be perfect, but I know that is asking a lot.

share|improve this question
3  
Its probably worth looking at puredarwin to see what goes into building a darwin based distro (and the problems they and opendarwin faced in this) –  Journeyman Geek Feb 4 '13 at 0:45
1  
To regular userland both kernels look very similar, but the software used to manage the kernel and the software intimately involved with it (including libc) are quite different. The LFS documentation won't be of much help in this critical first steps. Perhaps starting from (or at least studying) the kFreeBSD branch of Debian is more relevant. –  vonbrand Feb 19 '13 at 23:00
1  
Hint: If you actually make a question of what you're trying to do, you both increase your chances of finding a hit in already existing questions, but also increase the likelihood that it will attract more people with ideas for how to answer the question. As opposed to being confused what the question really is. Just a thought. –  killermist Mar 4 '13 at 2:50
1  
Darwin is somewhat based on BSD, which is different from Linux. The BSD way of doing things is different in more things than just the kernel (filesystem preferences, directory structures, upgrade policy, etc). –  Vesperto Mar 23 '13 at 18:59
2  
Being binary compatible with is not the same thing, I'm afraid. @Vesperto is right, Darwin is more closely related to the BSD family than to Linux; albeit with a decidedly different kernel than other BSDs. I think you would have better luck looking for a BFS type guide than for a LFS based one. The BSD Handbook would be another good reference source. You would still need to use your Darwin references for it's relevant information. –  Jerry W Jackson Apr 9 '13 at 4:21

2 Answers 2

Short answers to this question:

Technically: Yes

Practically: No*

With Binary Cheats: Probably, but also not legal (untested)

With Binary Cheats for generic hardware: As above (untested)

*unless you work at Apple (*clears throat in general direction of California*)


Longer answer:

This is going to be rather long. I suggest coffee. If you don't have the time/inclination to read it all you can skip to "Concluding Remarks".

Practically Possible (No):

Sadly, Apple has withdrawn the source code for too many of Darwin's necessary KEXTs and binaries to make the compilation of a Darwin OS purely from source possible. It still is technically possible (you could write the source yourself to patch it up properly) but I simply don't have the time, skills or inclination to do this (and I doubt the crowd funding community would be very interested).

Unsurprisingly the key tipping point was the release of Darwin 10 which brought xnu into x86_64-land. Most of the necessary sources were around before then, but were x86 only. As time has gone on, the meaning of Apple's "Open Source" appears to have shifted to "Open Source on Apple's hardware only" as Apple's KEXTs are now by-and-large hardware-specific, so even if you could get everything up and running (see below) you'd still be confined to Apple hardware.

Technically Possible (Yes):

However, all is not lost. The LFS guide did come in handy and certainly all of the necessary setup can be conducted without actually building the Darwin OS. Furthermore the steps presented give you an almost-exact roadmap of the path ahead, minus the kernel, KEXTs and bootloader. I did manage to solve the bootloader problem though (at least for Apple hardware).

If you're interested, here's a full overview of what you will have to do:

  • Erase a partition (8GB or larger preferably) on a drive (internal or external doesn't matter) and format it as Mac OS Extended (Journaled) (HFS+).
  • Ensure it has a GUID Partition Table (GPT) and that when you do it has an EFI partition. The easiest way to to this is through Apple's Disk Utility but you can do it on the command line if you want (there are tutorials elsewhere on how to do this). The important point is that when you run distil list diskNsM the following information should be correct:

Partition Type: Apple_HFS

OS Can Be Installed: Yes

Read-Only Media: No

Read-Only Volume: No

  • Now to follow the LFS guide (with adaptations).

  • Insert 'DFS=/Volumes/DarwinOS' (no quotes and with the actual mount point obviously) into .bashrc and .bash_profile

  • Make the user directory (chown it to 0:0 at the very end):

    sudo mkdir -v $DFS/usr

  • Enter root:

    sudo su -

  • Make the sources directory and set the sticky bit:

    mkdir -v $DFS/sources # Make sure you still have $DFS defined, if not, redefine it.

    chmod -v a+wt $DFS/sources

  • Make the tools directory and make a symlink to it so we can add it easily to $PATH later (still in root by the way):

    mkdir -v $DFS/tools

    ln -sv $DFS/tools /

    logout # Leave root

  • Download the source of all the packages you want. This is, of course, where you get stuck. All the necessary ones aren't there. (Incidentally I prefer GNU's binutils anyway.)

Assuming you could in fact download all the ones you needed, let's press on.

  • Make an underprivileged user specifically for DFS (suggested by LFS):

    sudo dscl . -create /Users/lfs

    sudo dscl . -create /Users/lfs UserShell /bin/bash

    sudo dscl . -create /Users/lfs RealName "LFS DFS"

    sudo dscl . -create /Users/lfs UniqueID "2070" # whatever you like

    sudo dscl . -create /Users/lfs PrimaryGroupID 20 # Default 'staff'

    sudo dscl . -create /Users/lfs NFSHomeDirectory /Users/lfs

    sudo dscl . -passwd /Users/lfs dfs # Again to taste.

  • Note you have to make the new user's homedir manually on a Mac:

    sudo mkdir /Users/lfs

    sudo chown -R lfs:staff /Users/lfs/

  • Now grant the new user access to the sources and tools

    sudo chown -v lfs $DFS/tools

    sudo chown -v lfs $DFS/sources

  • Log in:

    su - lfs

    Password: dfs

  • Run the following command to clean the environment (from LFS):

    cat > ~/.bash_profile << "EOF"

    echo "Entering clean environment…"

    exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash

    EOF

  • Now run the following command (see LFS for what it does if you aren't sure):

    cat > ~/.bashrc << "EOF"

    set +h

    umask 022

    DFS=/Volumes/DarwinOS # As previously

    LC_ALL=POSIX

    LFS_TGT=$(uname -m)-dfs-darwin1242 # Look inside gcc/configure for possibilities!

    PATH=/tools/bin:/bin:/usr/bin # Note symlink from before

    export LFS LC_ALL LFS_TGT PATH

    echo ".bashrc script complete. Environment is ready."

    EOF

  • GCC's /configure is quite flexible. Try grepping the *- pattern, or just run gcc -v to see how your host machine was configured and copy that.

  • Now logout of the lfs user and log back in. You should now have a clean environment.
  • Everything from now takes place inside the lfs user. You'll noticed I was slightly lazy in only converting half the 'LFS' symbols to 'DFS' symbols. Sorry about that but you get the idea.

Okay now to the hypothetical section.

From here out it's pretty well going to be standard LFS procedure: Extract sources, build, install, test, delete sources. Note the 2 passes of binutils, GCC and Glibc are still necessary BUT you ALSO have to have a working copy of libc++.1.dylib - and you'll need to do that in 2 passes as well. You can see the LLVM project's libcxx page for a few more details. Once compiled, you can put it in /usr/lib. You'll need to compile and install the xnu kernel (there are a few tutorials around the web for how to do that) and then install the KEXTs. Even if all the required KEXTs were available, you'd still need to put them into the .kext package by hand. Again there are tutorials for how to hand-craft a KEXT on the command line.

The final bit is making the system bootable. To do that, you would run the following command:

"$DFS/usr/sbin/bless" --folder "$MOUNT/System/Library/CoreServices" --bootefi --verbose

Actually the location to bless doesn't really make a difference. That folder is just Apple-standard.

In any case, assuming the kernel and KEXTs were in the right places, you had proper copies of dyld, launchd, etc in place and boot.efi was working correctly, the system should be working and bootable!

Note if you really wanted to you could run a faux-launchd that is just a script to run a bash prompt - that's what PureDarwin Nano does.

Again, by all means, write the KEXTs and binaries yourself if you like - it is technically possible. Just call me when you're done.


With Binary Cheats: Probably, but also not legal (untested)

So, why can't you just rip the binaries, KEXTs and required files out of Mountain Lion, bless the volume and go? Well, you probably can. But you also need a license to do this. Also, if you do this, you've just basically made a copy of Mountain Lion. Isn't that sort of beside the point?

With Binary Cheats for generic hardware: As above (untested)

This pretty much is the OSx86 project. Again you pretty much run into legal issues straight away. There's no question that these last two methods are definitely possible - the fact that you can run Mountain Lion on generic hardware is proof of that - but the whole point of this was to be able to legitimately compile your own Darwin OS from source.


Side Note

You may have noticed I've deliberately avoided anything 32-bit. In a world where every major OS is available in 64-bit there's not much point in compiling a 32-bit one. Apple did actually provide disk images of Darwin (up until Darwin 9) here. They worked perfectly on my Windows box.

Concluding Remarks

I guess at the end of the day, people don't by Mac for Darwin, they buy Mac for Aqua. As a result, support for Darwin as a standalone, open-source product has gradually declined to the point where it is really just a token gesture to the open-source community. The other slightly ironic fact is that in order to learn about a lot of this, you have to jump right into the OSx86 project, which isn't exactly sanctioned (to put it blandly). Even then, there's not a great deal of information around. PureDarwin is an excellent place to start, and Jonathan Levin's book is an invaluable reference for all things xnu.

This has been an extremely educational year of work, and I'm almost as happy knowing how to do it as I would be actually doing it. I'm going to have to stop work on it at some stage though and now is that time. As a final futile shout out to Apple, would it be too much to ask to have just one more build of Darwin when you release Mavericks?

share|improve this answer

Obviously, you have recognized that the LFS is for Linux and Darwin is very much differ from the Linux LFS applied, so it is simple beyond your single person efforts to applied the LFS to the Darwin systems.

There are many community attempt to replace / improve the Darwin systems. while the OpenDarwin project doesn't have much succeed, guess the code by Apple is too hard, while there is still one project PureDarwin remaining:
PureDarwin SourceForge
PureDarwin HomePage

Get a Developer Account first, Grab their build tools, then you could get the steps on making your own custom Kernel.

Darwin Kernel are not having same architecture with Linux Kernel, so, it cannot be replaced with Linux Kernel, so you need to compile it.

Actually all you need to do is to stick 100% with the PureDarwin project, then call the following script: Google Code - Pure Darwin Switch Kernel with the custom Kernel Images you have made will be fine.

But regarding how to build a good working Darwin Kernel, that would be a new question.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.