Blogs

Alpha release coordination / plan

Blog post by stpere on Mon, 2009-04-06 19:03

Greetings,

I'm proposing myself as a release coordinator for the upcoming Alpha Release, and here are the highlights of the plan.

First, this plan shouldn't be applied before those conditions are met :

  • the LiveCD works quite good (with no major issues left). My understanding of that topic is that we still need the FS overlay (that allows attributes over iso9660) to support live queries. If there is anything more to add to this point, please comment. Plus, the ioscheduler should be tweaked to enhance the user experience using that media.
  • all the criticals (blockers) issues already identified are fixed. I see that a lot of them have already been taken care of; that's good! :)

So basically, my plan tries to moderate the pressure on the developper workforce while at the same time optimize the benefits from the release (attention from the community at large, etc..)

What I propose is to set a condition list, that when all met, will trigger the countdown. So here is the basic timeline I propose :

RELEASE -4 weeks : Trigger

All conditions are met according to the release comitee. Feature freeze is announced to start after this week.

RELEASE -3 weeks : Feature freeze is effective

Bugfixes only. Medium tolerance to regressions.
First release of a preview livecd at the end of the week.
QA team gets the livecd to play with. Basically, we try to boot it from everywhere :) But at this step, it shouldn't be the firsts steps of the livecd, so should be somewhat useable already.

We tag/branch/(whatever it is called under svn) the repository.. all work that might "break" things temporarely are done on the new "unstable" branch. Fixes to what will become the release goes to the "stable" branch.

We put a countdown on the website, with a hot-linkable banner so that fans can blog about it and displays the countdown on their site.

RELEASE -2 weeks :

Bugfixes only. Low tolerance to regressions.
Call to test the livecd newest release.

Backport the main fixes that have been tested in unstable.

RELEASE -1 week :

Bugfixes only!! No tolerance for regressions.

Major Fixes regarding LiveCD are still accepted.

At this point, there should only be trivial bug fixes on other components. Of course the software is still alpha, but we have to get ready for the R-Day..

Special attention is paid to documentation and website..

RELEASE -3 days :

Past this point, the alpha tree is frozen.. the final images are in production

RELEASE -2 days :

Images are uploaded, seeded, ... we get the md5sum of the images..

RELEASE -1 day :

QA team test a final time the images. There is not much to be done at that time.

RELEASE!

Press releases are sent! Website is switched in release mode! The webserver braces itself!! :)

Okay, comments welcome..

Keep in mind that it's a draft ;-) On future posts, I will start the discussion regarding the formats we will distribute in (LiveCD, UsbStick, VMWare Images, etc...)

A Jocund Eulogy

Blog post by nielx on Sat, 2009-04-04 21:12

According to my resume, I've been contributing to Haiku since 2002. I don't remember how I determined that start date, and GMail is only five years old so searching that does not provide me with an answer either. What I do know is that I feel a strong connection with this project. Which really makes it all that harder to part.

I remember I started by writing a naive proposal about internationalization back when this was still OpenBeOS. You should know that at the time I was sixteen years old, so I never really knew BeOS, and I just came from the translation team from KDE. I left that project in search of something bigger, more integrated, more ... I think we have all been there. BeOS seemed like a materialization of that dream. Only, Be Inc. already turned into ashes when I started my quest. A bunch of silly coders with a vision were determined to continue that dream. Little did they know that seven years later their code would boot on many machines - even though mine right now seems to be left out of the fun. My proposal on internationalization, however, never came to materialize.

And yet another deadline wooshed by...

Blog post by meianoite on Fri, 2009-03-06 09:46

Rule #1: never set deadlines when you're moving houses.
Rule #2: no, they won't reconnect the Internet on a timely fashion, so don't count on it. Telcos make no distinction between "worst case scenario" and "average turnaround time".
Rule #3: by Murphy's law, don't plan on spending some minutes of your lunch time at work writing the blog entry you promised. Your boss will ask you favours if s/he has the slightest suspicion that you're idling.
Rule #4: smartphones aren't made for writing texts of any real length. Don't be tempted to use one for this purpose, else prepare yourself for a lot of grief.

This is bothering me to no end. I'll spend some time at my dad's this weekend, and I'll set aside some quality hours to write. Stay tuned.

Haiku at SCaLE 2009: the Report

Blog post by koki on Tue, 2009-03-03 20:13
Haiku booth at SCaLE 2009Haiku booth at SCaLE 2009

After a long week of chronic procrastination, here is finally my report from the recent SCaLE conference. The 7th Southern California Linux  Expo, familiarly known as SCaLE 7x, was held at the Westin Hotel Los Angeles Airport Hotel on February 20th through the 22nd, and Haiku had its booth for the third year in a row. SCaLE is a bit special for me, as it was the first show that I did for Haiku (back in 2007) and because that's where Haiku made its debut at a big open source conference; I personally view this first appearance combined with the now renowned Haiku Tech Talk that we gave at the Google Mountain View offices soon after (Google video available here) as a sort of turning point for a project coming out of obscurity and starting to make it in front of the eyes of the world. Melancholic aspects aside, SCaLE is a popular open source event that combines abundant and rich speaker tracks with an exhibit floor that has a healthy mix of open source projects and businesses, so it is a great place to raise awareness and promote the project among a small but well qualified audience of mainly geeks and business people both involved in open source.

Remember the "Young Offender"

Blog post by meianoite on Wed, 2009-02-25 16:46

"We're busy running out of time", said the lyrics.

Actually, the whole lyrics to that song just ring so true to me. Never really liked the song itself, though.

I expect to post the promised (on the mailing list) blog entry by tomorrow.

FOSDEM 2009 report

Blog post by mmu_man on Mon, 2009-02-09 15:01

Here is my own report about what happened at FOSDEM. Actually so many things went on I probably missed some.

Getting there

For this second time at FOSDEM, I tried to get a shared devroom with other projects, but there were so many requests we only had a booth. We probably wouldn't have had enough material alone for two days anyway. Besides, manning a booth itself is already quite demanding.

makebootable - What and why and how to do it manually

Blog post by mmlr on Sun, 2009-02-08 16:12

Usual question: "I've dd'ed the image to somewhere and now it doesn't boot". Usual advice: "You have to make it bootable by using makebootable". Usual reaction: "Ehm, ok how do I do that?". Since this type of question comes up quite frequently, let me try to explain a bit of background on that pseudo-mystical tool "makebootable", how you can get it and how you can manually make a partition bootable without even needing makebootable.

The Stage 1 Bootloader

Ok, what we are really talking about here is the stage 1 bootloader. It is a tiny bit of software that is written to the start of a partition or disk. It is where either the BIOS or the boot manager will jump to to get the OS booted. In the case of Haiku this stage 1 bootloader loads a bit of the BFS partition the installation is on and locates /beos/system/zbeos. zbeos is the stage 2 bootloader, which provides the boot menu and loads the kernel. In the case of a missing makebootable we never get to that stage 2 bootloader.

If you want to look at it from the code side you should check out "src/system/boot/platform/bios_ia32/stage1.S". It's nicely commented and pretty straight forward to follow. But let me just explain the rough outline:

  • 1. Set up a few basics, clear registers and store the drive id
  • 2. Check if we have disk extension provided by the BIOS
  • 3. Load the rest of the stage 1 bootloader
  • 4. Validate the BFS superblock
  • 5. Search the stage 2 bootloader on disk
  • 6. Load the stage 2 bootloader into memory
  • 7. Run the stage 2 bootloader

When we enter the stage 1 bootloader we have the following available: the first block of the stage 1 bootloader, so the first 512 bytes. What we do from there is execute steps 1-3. Even though the stage 1 bootloader is only a tiny bit of software, it's not tiny enough to fit completely into one 512 byte block. That's why it is split across the first and second block of a partition (with the BFS superblock sandwiched between the two parts at the start of the second block).

Where we fail with a missing makebootable is step 3. This is the first time we need to load something from disk. To do that we use the BIOS disk services that provide us with a simple interface to load stuff from disk into memory. We are always accessing the disk here, and not the partition. This means, when we want to load the second part of the stage 1 bootloader, we need to instruct the BIOS to load the block "where we are" + 1. And that's exactly the important part here "where we are", i.e. where the first part of the stage 1 bootloader is. The thing is, we do not know where the first part of the stage 1 bootloader is on disk. We don't know the needed offset to get from the start of the disk to the partition we are booting from. Therefore we can't calculate the location of the second block and subsequently the location of the BFS structures.

So how do we get to know that offset? Simple: it is written into the stage 1 bootloader using makebootable. The only thing makebootable does is to find exactly that partition offset and write it into the bootloader at a specific place (bytes 506-510 to be exact), so that the first part of the stage 1 bootloader is able to calculate the correct offsets into the disk.

When you start out with a normal Haiku disk image, the offset is simply initialized to 0. With that background you should now be able to understand why it works to dd a raw image to a raw device and get it booted. It works because if you write the image at offset 0, this is the same offset that is present in the image. If you write it to somewhere else, i.e. you write the image to a partition instead, meaning the disk offset is not 0, the stage 1 bootloader will still try to read from offset 0 + 1, because that's what is written into the bootloader. So this won't boot.

The makebootable Tool

As mentioned the purpose of makebootable is to write a stage 1 bootloader to a partition and supply it with the correct partition offset. The problem makebootable has to solve is to be available on different platforms and be compatible with the different ways of finding the partition offset. Each OS has its own API for that, that's why makebootable has to be explicitly ported to make writing directly to a partition work. So far it's been ported to linux, FreeBSD, Darwin and of course BeOS and Haiku. On unsupported platforms (like on Windows or Solaris for example) you therefore can't use makebootable to do it automatically for you.

On supported platforms however you can build makebootable using the command "jam run :\<build\>makebootable /dev/sdc4". This will build and run makebootable for your host platform, giving it the partition you want to make bootable ("/dev/sdc4" for example). This will output the partition offset that is written to the stage 1 bootloader.

Note that if you have a BeOS or Haiku installation you can use makebootable from there. The BeOS stage 1 bootloader is a bit different, but it's compatible with the Haiku stage 1 bootloader, as it loads the stage 2 from /beos/system/zbeos as well. So on these platforms just run "makebootable /dev/disk/...". You can run makebootable with a path of a mounted volume as well, so if you mounted the target partition at "/HaikuStick" you can as well do "makebootable /HaikuStick".

If You Can't Use makebootable

If you can't use, or don't want to use makebootable, you can of course do the partition offset thing manually. For example if you are on Windows and want to make the second partition of your USB drive where you dd'ed the image to bootable. What you need for that is a hex editor. If you can get one where you can access the raw disk directly that's the best situation, otherwise you have a few steps more.

The first step is to find out what the partition offset in blocks is. If you have some tool to get that information from, get it from there. You either need the offset in 512 byte blocks or the offset in bytes and then divide that by 512. If you don't have a tool that can display the offset, you should be able to read it from the partition table in the master boot record (MBR). If you have a hex editor allowing you to access the raw device at offset 0 (where the MBR is located) point it there. If not, use dd to read the MBR into a file (something along "dd if=/dev/sdc of=mymbr.bin bs=512 count=1" in case of Windows take the "Partition0" thing, they really mean raw device by partition 0) and open that in the hex editor. Now when you're looking at that MBR you gather the partition offset from the partition table. The layout is documented for example at Wikipedia, but since that is a lot of info for a small task, let me explain that the partition table starts at offset 446 (0x1be) and has 4 entries of 16 bytes. Each entry being:

  • 1. Active flag (1 byte, 0x80 = active 0x00 = not active)
  • 2. Start offset in cylinder/heads/sectors (CHS) format (3 bytes)
  • 3. Partition type (1 byte, 0xeb for BFS, but it doesn't really matter)
  • 4. End offset in CHS format (3 bytes)
  • 5. Start offset in logical block address (LBA) format (4 bytes)
  • 6. Partition length in blocks (4 bytes)

What we need from that is the partition start offset in blocks. This is exactly what field 5 holds for us. Note that this is a little endian 32 bit integer, but as the format is the same in the stage 1 bootloader it doesn't matter at all. Just note down that number for the partition you want to make bootable. The direct offsets to those numbers are 454, 470, 486 and 502 for primary partitions 1, 2, 3 and 4 respectively. If you're doing logical partitions here, you'll have to figure out how to get that offset yourself, sorry.

When you finally have that offset, you can either patch it directly on the partition if you have a hex editor that allows that or you simply patch it in the haiku image you started with and afterwards dd it to your partition again. In any case you point the hex editor to the first block of the stage 1 bootloader (the first block in the image file or on the partition) and write down the partition offset number at offset 506, just so that you don't touch the 0x55 0xaa at the very end of that block. If you have the partition offset as a number read from a tool, convert it to hex and write it there as a 32 bit little endian integer (i.e. reversed so an offset of 0x01020304 would result in the bytes 0x04 0x03 0x02 0x01 at offset 506). Just to explain it a bit more graphically here's a screenshot of DiskProbe under Haiku with the two relevant parts selected. On the left the MBR and on the right the partition with the same offset.
manual makebootablemanual makebootable

Syndicate content