obsolete

Installing Haiku to a partition from Linux

Article contributed by ekdahl on Thu, 2007-09-06 16:36
2010-January: This document is now obsolete. We are in the process of consolidating and re-organizing the website documentation. For now please refer to the in-progress website documentation.

This is a guide for you who have already been able to build an image of Haiku under Linux and running that with an emulator such as QEMU or VMWare and want to try Haiku natively with your real hardware.

Disclaimer: Do this on your own risk. I don't take any resposibility for any data loss caused by using this guide.

The following procedure have been tested with Kubuntu 7.04

I assume the following:

  • You are using Linux
  • You have a build system up and running
  • You are using GRUB as boot loader
  • You have a spare partition on which you want to install Haiku

The first thing you need to find out is the Linux name of your partition. A simple way of finding that is to run a partition editor. If you're using Gnome or Xfce, then use the application GParted, and if you are using KDE, the app to use is QTParted. In those applications you get a graphical view of your harddrives and partition layout.
The name of the partition can for example be
/dev/hdb3 - which means the third primary partition on the second PATA hard drive
or
/dev/sda6 - which means the second logical partition on the extended partition on the first SATA hard drive

Short simplified explanation of naming:
First letter: 'h' means PATA, 's' means SATA or USB drives
Third letter: 'a' means first drive, 'b' means second drive, and so on...
Digit: Partition number, 1-4 is primary partitions, one of these can be an extended partition which in turn contains logical partitions. The numbering of logical partitions start with 5.

Next step is to tell the build system that the "image" used for installing haiku on should be your partition instead of the file haiku.image which you have used previously. That can be done by overriding the variables HAIKU_IMAGE_NAME and HAIKU_IMAGE_DIR. The recommended way of doing that is to create a file called UserBuildConfig under trunk/build/jam. All your customizations to the image can be done here, like if you want to include extra drivers or applications which are not part of the standard image.
If your partition was at location /dev/sda6 the contents of UserBuildConfiq should read:

HAIKU_IMAGE_NAME	= sda6 ;
HAIKU_IMAGE_DIR		= /dev ;

Make sure that you wrote the right partition, because the partition will be overwritten.

Now you're set to build Haiku. Issue this command in a terminal (under the trunk directory):

jam -q

If no errors occured you will be flooded with messages like
Error: Failed to open connection to FS shell: No such file or directory
But that's to expect, since you dont have write access to the partition you're trying to install haiku on.

To complete the installation simply run

sudo jam -q

And the actual installation to the partition will be performed. The reason for not running with sudo the first time is that you want the ownership of the compiled files to be your user account.

Now it's time to add a boot entry for Haiku in GRUB.
To edit GRUB's entries run

sudo kate /boot/grub/menu.lst

or

sudo gedit /boot/grub/menu.lst

depending on what editor you use.

GRUB uses a different naming strategy for harddrives than Linux. It uses a scheme like this:

(hdN,n)

Where N is the hard disk number, starting on 0. And all hard disks' name start with hd.
And n is the partition number, also starting on 0. The first logical partition always have the number 4, regardless of the number of primary partitions.
If you're still unsure, check out
http://www.gnu.org/software/grub/manual/grub.html#Naming-convention

As an example
/dev/sda6 would be (hd0,5) in GRUB (if there are no PATA drives installed).

The entry would finally be

# Haiku on /dev/sda6
title		Haiku
rootnoverify	(hd0,5)
chainloader	+1

This should be somewhere in your /boot/grub/menu.lst file.

That's it! Reboot to test. Good luck, you'll need it.

If you have updated the source and want to reinstall Haiku, just run

jam -q

from trunk and subsequently

sudo jam -q

And your partition once again is populated by a fresh install.

Building Haiku on Ubuntu Linux, Step by Step

Article contributed by leavengood on Sat, 2007-07-21 04:11
2010-January: This document is now obsolete. We are in the process of consolidating and re-organizing the website documentation. For now please refer to the in-progress website documentation.

Another article on this site already describes the basics of building Haiku on Linux. Since my distribution of choice is Ubuntu, I decided to get Haiku building on it and then provide a detailed step-by-step guide for others to follow.

I performed these steps on a fresh Ubuntu 7.04 (Feisty Fawn) install, but they should be similar for other versions and probably the same for most Debian-based distributions.

  1. Install the needed packages for building:
    sudo apt-get install subversion yasm autoconf automake texinfo flex bison gawk build-essential
  2. Create the Haiku development directories and get the Haiku build tools source:
    mkdir develop
    cd develop
    mkdir haiku
    cd haiku
    For anonymous checkout:
    svn checkout http://svn.berlios.de/svnroot/repos/haiku/buildtools/trunk buildtools
    For an existing Haiku developer:
    svn checkout https://developername@svn.berlios.de/svnroot/repos/haiku/buildtools/trunk buildtools
  3. Build and install the Haiku Jam:
    cd  buildtools/jam
    make
    sudo ./jam0 install
    cd ../..
  4. Get the Haiku source (this will take a while): For anonymous check-out:
    svn checkout http://svn.berlios.de/svnroot/repos/haiku/haiku/trunk trunk
    For an existing Haiku developer:
    svn checkout https://developername@svn.berlios.de/svnroot/repos/haiku/haiku/trunk trunk

    If there are any errors when checking out above, just cd into the trunk directory and type "svn up" to get any missed files. This also applies when updating the code in the future.

  5. Build the cross compiler tools (GCC 2.95):
    cd ~/develop/haiku/trunk
    ./configure --build-cross-tools ../buildtools/
    To build with GCC 4.x the configure line is:
    ./configure  --build-cross-tools-gcc4 x86 ../buildtools/

    But keep in mind this will produce binaries which are not compatible with BeOS.

  6. Build the Haiku image:
    jam haiku-image
    To build for testing in VMWare:
    jam haiku-vmware-image

    A VMWare configuration file for running this image can be found at 3rdparty/vmware/haiku.vmx

That is it! Not too bad. Thanks to Ingo and the various other contributors for making the Linux compiling so easy.

Getting and Building the Haiku Source Code

Article contributed by wkornewald on Sat, 2006-10-28 09:10

Document Obsolete

2010-January: This document is now obsolete. We are in the process of consolidating and re-organizing the website documentation. For now please refer to the in-progress website documentation.

Please note this document mainly pertains to building Haiku under BeOS R5 and later. If you're using a non-BeOS host platform, you might find this guide more useful.

Getting the source

All commands must be executed in the Terminal.

Go to the parent directory for Haiku's repository and enter:

svn checkout http://svn.berlios.de/svnroot/repos/haiku/haiku/trunk haiku

This will checkout the source into a new subdirectory called "haiku". Members of Haiku should login with their BerliOS account to get commit access:

svn checkout https://developername@svn.berlios.de/svnroot/repos/haiku/haiku/trunk haiku

After the initial checkout (also in case not the entire tree was checked out successfully) you can fetch source code updates with the following command in your repository's root folder:

svn update

Installing the cross-compiler

Download the Haiku cross-compiler and extract it to "/boot" (for example by setting the "Destination" in Expander to just "/boot"). Then you need to configure your tree to use this cross compiler. Go to the root folder of your checked out Haiku repository and invoke the configure script with the "cross-tools-prefix" option like this:

configure --cross-tools-prefix /boot/apps/haiku/cross-tools/bin/i586-pc-haiku-

Be careful to include all of the string up to and including the last dash, as all the cross compiler tools have this prefix (they are for example called "i586-pc-haiku-ar"). You need to specify this prefix everytime you run configure.

Building the source

You can now start the build process with:

jam

Note that this will just build any target that is found in the tree. This is usually not that useful, as many parts might not build and are not required. So optionally, a target can be specified by adding a target name. For example, "jam app_server" will only build the app_server target. Normally though you will want to build an image or installation using the commands below. Add the "-a" option to rebuild the whole source or only the specified target in case Jam didn't notice source changes.

Building an image

You can build a Haiku image with:

jam haiku-image

This will place a file named "haiku.image" into the "generated" folder.

To build an image for testing in VMWare:

jam haiku-vmware-image

This will place a file named "haiku.vmdk" into the "generated" folder.

Instead of building an image, you may install Haiku on a mounted partition using:

HAIKU_INSTALL_DIR=/target_folder jam install-haiku

Further reading

Please read "Version Control with Subversion" for a detailed introduction.

FixFi

Getting Linux Developer Tools

Article contributed by johndrinkwater on Tue, 2006-08-15 19:34
2010-January: This document is now obsolete. We are in the process of consolidating and re-organizing the website documentation. For now please refer to the in-progress website documentation.

What you need

You will need svn before starting this process; the other tools (jam, gcc et al) are built from our repository. Before attempting to build Haiku, one must get copies of the development toolchain. Keep in mind that the process will consume around 1 GiB of disk space.

Fetching the tools

To build Haiku on Linux you must first check out and build the cross-compiler. The easiest method for doing so is to check it out in a directory just below that of the Haiku root. Navigate to the parent directory of Haiku and use a command such as:

svn checkout svn://svn.berlios.de/haiku/buildtools/trunk buildtools

You should now have a 'buildtools' folder that contains folders named 'binutils' and 'gcc' amongst others.

Building jam

Change to the buildtools folder and we will start to build 'jam' which is a requirement for building Haiku. Run the following commands to generate and install the tool:

cd  buildtools/jam  
make
sudo ./jam0 install

Keep in mind that the above will overwrite any previous installation of 'jam', as Haiku requires a slightly modified version. You can ensure that jam is installed correctly by comparing the result of the following:

$ jam -v
Jam 2.5-haiku-20060813. OS=LINUX. Copyright 1993-2002 Christopher Seiwald.

 

Building binutils

The binutils used by Haiku will be automatically generated according to the initial configuration of the Haiku source and placed in the 'generated/cross-tools' directory of Haiku. Before generating the tools you must consider the version required, there are essentially two choices:

  • 2.95: Creates BeOS compatible binaries
  • 4.x: Incompatible with BeOS, but theoretically more efficient binaries

Unless there is a pressing need, choose 2.95 as the latter option can cause frequent build issues. The commands for configuration are,

2.95:

cd haiku 
./configure --build-cross-tools ../buildtools/

4.x

cd haiku
./configure --build-cross-tools-gcc4 x86 ../buildtools/

The process can take quite some time, but when it finishes you are ready to compile your first haiku image.

Using Subversion with the Haiku Source Repository

Article contributed by axeld on Mon, 2005-03-07 05:00
2011-November: This document is now obsolete. Subversion is no longer in use. We are in the process of consolidating and re-organizing the website documentation. For now please refer to the in-progress website documentation.

As we've already announced earlier, we're planning to switch our version control system from CVS to Subversion. While CVS is working nice basically, it's much too limited to serve as a good foundation for a project of a size like ours.

The following document should give you an introduction on how to use Subversion with our repository - it will not provide you with many details, but with some pointers in case you want to know more about Subversion. The current version of Subversion is 1.1.3.

It will also not cover the installation of Subversion on BeOS - alongside this document, we've published a package that will take care of this for your convenience. To successfully use Subversion on BeOS with our provider of choice, BerliOS, you'll need an updated ssh client, a new pipe file system (developed by François Revol), the flock_server (that provides a file locking service needed by several applications), and of course, a recent Subversion client. You have to thank Ingo Weinhold and David Reid for the availability of these ports for BeOS.

Setting up the local repository

The most important difference for you is that you don't want to check out the entire repository anymore: unlike CVS, Subversion would leave you with all tags and branches as separate files on your hard drive - which totals in about 1.4 GB of files at the moment. Instead, you will specifically ask for the "trunk" only - that's what you already know as the CVS root now. And in there, you may also not need to check out the build tools, as these are available separately, and ready to be installed, anyway.

Checking out the sources

If you want to do an anonymous checkout, you don't need SSH - this should already work with the Subversion release as published on BeBits. To get a copy of the current Haiku tree (and Haiku only), you would write something like this:

	svn checkout http://svn.haiku-os.org/haiku/haiku/trunk [directory-name]

This will create the directory "trunk" in the current working directory and put everything from the repository under haiku/trunk into it. If you don't like the name "trunk" on your disk, you can specify the optional directory-name parameter.

You'll probably notice that "current" is gone - it's now called "haiku". Anyway, this should take a while, but give you a recent copy of our current sources. Note, before the actual switch, we'll be freezing CVS commits and then update the Subversion repository from the most recent one; what you currently get from BerliOS is quite outdated.

For a developer checkout, it's quite similar:

	svn checkout svn+ssh://svn.haiku-os.org/srv/svn/repos/haiku/haiku/trunk

Don't be confused by the double password retrieval: that's obviously how it's meant to be (at least it's not a bug we claim credit for). It will only do that with the checkout command; update and all other commands needing access to the repository work as expected. But you may want to store your public SSH key at BerliOS's so that you don't ever have to type it in again.

Note, if your local user account is different from your login name at BerliOS, the SVN_SSH variable must be set a bit differently for things to work:

	export SVN_SSH="ssh -l developername"

You can pass other options to ssh this way as well if you wish. Unlike CVS, if your local user name is identical to your developer name at BerliOS, you don't have to set the variable at all, though.

Keeping the sources up to date

This is an easy task, and is very similar to what you're used to from CVS:

	svn update

Of course, this will also work in sub directories, in case you only want to update a certain piece of the tree. And just like with CVS, you don't have to specify the URL of the tree when you are issuing a command from inside a checked out tree.

Some Subversion specials

  • Unlike CVS, Subversion does not need a network connection to show you the changes you made to your working copy - this will reduce the network usage to a minimum (the svn status and svn diff commands). This has a couple of other advantages as well, like the svn revert command which you can use to undo local changes.
  • Subversion has a real rename feature - now you can move files (and directories) around without losing the file's history.
  • If a conflict occurs during an update, Subversion doesn't let you commit files marked as conflicting. After you've resolved the conflict, you need to tell Subversion that the conflict is no longer an issue by calling svn resolved . You will also notice that Subversion helps you resolving the conflict by creating some files in your working copy that contain the originally checked out revision as well as the verbatim new revision of that file.

Tags and branches

In CVS, tags are just common names for a set of files with specified revisions; branches add some hidden dimension to concerned files. That makes it not so easy to see which files are actually tagged, respectively are contained by a branch (unless you just check the tag/branch out).

In Subversion, a tag is just a copy of the directories and files to be tagged, placed in a designated part of the repository. Branches are just the same, with the difference that while you usually leave tags alone once you have created them, in branches you still do editing. If you tag or branch from a branch, you guessed it, you just make a copy of the branch. All this copying sounds like a huge waste of storage, but in fact Subversion copies lazily; that is, no actual copy of a file's data is made until you start editing it.

Regarding the special place for tags and branches in the repository I mentioned, best have a look at the layout of our directory structure:

  buildtools/
...
haiku/
branches/
tags/
trunk/
vendor/
jam/
current/
2.4/
2.5rc3/
...

As we had in CVS we have two main modules, buildtools and haiku. Here only the structure of the latter is shown. Little surprise, the subdirectories branches and tags are the places for branches and tags respectively. vendor is the place for vendor branches. It has subdirectories for the components whose contents are managed as described in the Subversion Book. trunk has already been mentioned above; it is the main trunk of development.

The directories branches and tags deserve a closer look. Both are structured exactly the same, so only branches will be described more in detail; everything applies analogously for tags.

  haiku/
branches/
components/
ShowImage/
1.0-fixes/
...
developer/
axeld/
...
haiku/
old/
team/
kernel/
...

The subdirectory components is intended for branches that concern only one component of Haiku which could be distributed independently of the OS itself, too. As an (imaginary) example say ShowImage: Version 1.0 is out and development for 2.0 with new features is in full progress, but it has been decided to release a bug fix version. For this purpose the 1.0-fixes branch has been created. By the way, it would most certainly not be a copy of the whole Haiku tree, but only of the respective subdirectory (src/apps/showimage). If your component has headers and sources, which are stored in separate subtrees in the Haiku source tree (headers and src respectively), you don't need to copy the whole Haiku source tree either. You can create the branch directory by hand and copy only the concerned parts of the tree into it.

developer is the place for developer branches. Any developer who desires so can have a subdirectory. If you're paranoid and want to always commit your day's work even if it doesn't compile/work, this is the place. Or you have different computers you use for Haiku development and need a means to keep them in sync. Or you want to do experimental development. Just use this directory. Its inner structure is completely up to you.

A similar place, just for whole teams, is the team subdirectory. It shall mainly be used for experimental development in which more than one team member is participating. For the inner directory structure the team is responsible.

Into haiku go all branches of the complete OS once we start releasing versions.

Finally there is the directory old which contains all branches that had been created with CVS and were converted to Subversion branches. To save the work of understanding what each one was for and sorting them into the respective directories above, we just put them here. When you need one of them, just move it into the directory it belongs to. Each branch starts at the directory current, but contains only the files that were actually branched. You usually want to move only the innermost directory containing all files. For example:

$ svn mkdir -m "Directory for jam branches." 
svn+ssh://svn.haiku-os.org/srv/svn/repos/haiku/branches/components/jam
$ svn mv -m "Moved JAM2_4_VANILLA_FIXES branch to proper place."
svn+ssh://svn.haiku-os.org/srv/svn/repos/haiku/branches/old/JAM2_4_VANILLA_FIXES/current/src/tools/jam
svn+ssh://svn.haiku-os.org/srv/svn/repos/haiku/branches/components/jam/2.4-vanilla-fixes
$ svn rm -m "No longer needed."
svn+ssh://svn.haiku-os.org/srv/svn/repos/haiku/branches/old/JAM2_4_VANILLA_FIXES

This moves the branch JAM2_4_VANILLA_FIXES branch to its proper place, extracting only the relevant subdirectory. As you see we do this directly in the repository (only URLs are used), which is (despite the long command lines) the most convenient way for copying and moving directories (this includes creating tags and branches).

Useful links:

If you're a developer, you probably need to know a little more about how to use Subversion. Here are some links that you might want to have a look at:

Syndicate content