Journal #18: Installing Haiku from an existing Linux

What’s Haiku in the first place?

It is an operating system, period. What might cause a small surprise is that it is not based either on Linux or on BSD — and yet it is (probably) runnable in your modern computer/laptop!

What I most like on it is that the system is integrated with the GUI, so the end user gets a nice experience. This is not so common as it sounds: most Linux distributions are simply a collection of programs and utilities put together in one place, but they are not necessarily integrated — however, you can integrate them. This makes all the difference between user-friendly and user-centered paradigms [1].

Anyway, Haiku is simple, so for me this post is more a hobby than something useful that I will use in the future; however, I find that knowing about more and more about different operating systems has its own advantages.

For more, see https://www.haiku-os.org/about.

Installing Haiku

Note: most of those instructions come from here. Also, thanks David Couzelis for kindly giving me some advice and pointing me to them.

  1. Get Haiku. You can do it either from here, or get nightly releases from here. I personally recommend the nightly releases; I first installed the latest non-nightly one, but later on I discovered that is was very old (circa 2012): it didn’t even have a package manager.
  2. Which image should you download? In this post, I am assuming we’ll install Haiku directly to a (real) disk, so I’m downloading the raw image. Actually, the anyboot image can also be downloaded — and this is the one you will get if you opted for a non-nightly version; however, the anyboot image will be converted to a raw one in step 3 before we proceed. So, skip the next step if you downloaded the raw image.
  3. Got your anyboot image? Now, convert it to raw (run this from a bash compatible shell):
    1. # conversion
      dd if=haiku-anyboot.image of=haiku.raw bs=1M skip=$(expr $(od -j 454 -N4 -i -A n haiku-anyboot.image) / 2048)
    2. # padding
      dd if=/dev/zero of=haiku.raw bs=1 seek=506 count=4 conv=notrunc
      
  4. Now that we got a raw image, we are writing it directly to a disk partition. First things first: find 3GB or more of free space in your disk. Then create room for a partition in there (for example, with fdisk or gparted). Got it? Now create a partition in there. I’ll assume the partition is /dev/sda42. Please change 42 for the appropriate number in your case.
  5. Copy the raw image to the partition (this should be done as ROOT); WARNING: double check the partition and the disk number, otherwise you might lose data.
    1. dd if=haiku.raw of=/dev/sda42 bs=1M conv=notrunc
  6. Make the installation bootable: you’ll need to compile and run the makebootabletiny program, which can be downloaded from here. It is a simple C program, so:
    1. gcc makebootabletiny.c -o makebootabletiny
      ./makebootabletiny /dev/sda42 # this one: as ROOT
  7. Make your bootloader know about Haiku. If you’re using grub2, you can add something such as the following lines to /etc/grub.d/40_custom:
    1. menuentry "Haiku OS" {
          set root(hd0,42)
          chainloader +1
      }
    2. Then run as root: grub-mkconfig -o /boot/grub/grub.cfg

Done! Now you should be able to boot into Haiku.

Now what?

This post is not a review of Haiku, so I’m stopping here. However, if I write a review about Haiku, I’ll do that from Haiku 🙂

I’m just leaving this here.

Footnotes

[1]: By the way, Arch Linux is user-centered, which means that you’re supposed to integrate the system as you wish. If you don’t wish that then you’re screwed anyway, so go away 🙂

Journal #18: Installing Haiku from an existing Linux

Here be dragons! FreeBSD Overview (part I)

Overview

I’m done with Linux distros, and you probably already know that; I have a list of them for servers and desktop use cases, and they cover almost everything I’ll ever need. So I don’t bother testing new distros anymore, specially when possessing Arch Linux, Vagrant, Docker and VirtualBox. Oh, together they are all nice swiss army knives.

So, what about other components of the *nix world? There are the Apple World and the *BSD World. I plan to explore both of them in the future, beginning with FreeBSD. I know there are a couple of BSDs out there, from the top of my head I can list OpenBSD (security oriented thing I believe), DragonFlyBSD, NetBSD and PC-BSD (desktop use). I have no clue what is the difference between them, but I believe testing only one of them is sufficient.

Let’s get it. Heading to http://www.freebsd.org/where.html, I choose the amd64 row of the tenth release. Next comes a FTP listing where I can choose a download file. There are: bootonly (1), disc (2), dvd (3) and (4) memstick.

(4) is for using with dd to write to a USB stick. This is nice, I don’t usually find this thing explicitly on Linux Distros download pages (however IIRC, dd is the official method of writing Arch to a USB stick, and dd’ing the openSUSE ISO image usually works flawlessly too).

(3) probably contains a lot of unnecessary stuff and (1) is probably excessively lightweight. So I chose (2), the disc option.

After downloading it, I chose to test it with VirtualBox. Current release on my Arch system is 4.3.14. I create a new virtual machine optimized for BSD from the wizard page, then choose the ISO I just download and boot it.

The installation process proved to be relatively straightforward. It is ncurses-based, and the options you are prompted to enter are exactly what you would expect from a pretty traditional unix system.

One remarkable option is that I could choose to have a ZFS filesystem. Linux systems usually don’t allow that easily due to license reasons.

A confusing thing was about the keyboard/locale config. It isn’t traditional. I would expect to have options such as pt_BR, en_US, en_CA, fr_FR, and so on, but there are not. In the testing area of the keyboard, I couldn’t enter the ‘á’ character, with any of the Brazilian/Portuguese keyboard options.

Another downside: the shell. Default options were sh, csh and tcsh. REALLY? Where are the ‘traditional’ shells, such as bash, zsh, dash (debian), fish…(?) The shell will be the first program I’m going to install.

After the installation, I wasn’t able to identify the bootloader. It didn’t look like GRUB or syslinux, so I believe it is something specific to *BSDs.

I’m a Linux guy, so the first things I tried after logging into the system (as root, of course) was to inspect which commands were available. Most of what I’m used to were. This is one advantage of using a Unix systems: there is much in common between Linux and BSDs. Of course, I’m not being 100% precisely here, since Linux is only the kernel (what I’m referring to as Linux is actually GNU/Linux).

I entered ‘vi’. Shame on me. I took a while to find the ‘:’ key to quit from it. I’ve just discovered my keyboard wasn’t properly set up, despite of my Brazilian choice at the installation. ‘loadkeys’ wasn’t available either. But I can live with that, for now.

Important links: (also added to my open-bookmarks)

You see, once with the system up and running, it is necessary to do a lot of reading to understand what is going on behind the scenes. Those links might help you as they helped me.

I’m stopping here for now. Part II should cover package management and more criticism about this system (maybe I might find something useful and/or good there too, I’m not that biased (for now)). There are several questions which still need an answer.

Before leaving, I’ve done pkg install bash then pkg info to check if everything went fine. Default bash binary was put into /usr/local/bin. I really dislike to have several binary folders (/bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin), this is so non-intuitive (do I have to say that Arch unified almost all of those, and Gentoo deals with them in an elegant way?). Also, did you believe that I had to mount something to /dev/fd in order to use bash? And I had to add an entry in /etc/fstab to make it permanent too. What the hell?! (You see…hell, BSD logo…can’t believe I made this joke. OK, till next time!)

(There is also an album availble on Flickr with some screenshots of the installation process. It might be deleted or cluttered with other screenshots later on.)

Second part of this series is here.

Here be dragons! FreeBSD Overview (part I)

Instalando o Gentoo a partir do Arch

TL;DR: pequena TODO list sobre como instalar o Gentoo. Você vai passar 90% do seu tempo olhando para texto dando scroll na tela (processo demorado…).

Esse é o método mais tradicional possível (e que me interessa) que pude constatar. Adapte-o para as suas próprias necessidades:

  1. Boote em um ambiente com o Arch (na verdade, você pode fazer isso a partir de qualquer distro decente).
  2. Crie uma partição /, do tipo ext4, para acomodar a instalação do Gentoo. De preferência, coloque um label decente lá. Sugestões de ferramentas para isso: cfdisk ou gparted.
  3. Monte essa partição em /mnt/gentoo.
  4. Continue a partir do handbook oficial do Gentoo – nesse caso, para a arquitetura amd64.
  5. No entanto, atenção. Use esse guia para perceber quais etapas de instalação e configuração são diferentes (em relação a se estivéssemos instalando pelo método oficial, a partir do live environment do gentoo), mais especificamente da parte 4 à parte 6.
  6. Baixe o PKGBUILD gentoo-mirrorselect do AUR.
  7. Use mirrorselect -i -o e então selecione interativamente os mirrors mais próximos da sua localização atual. Copie o valor da variável GENTOO_MIRRORS para o final do seu /mnt/gentoo/etc/portage/make.conf.
  8. Copie o seu /etc/resolv.conf para /mnt/gentoo/etc/resolv.conf. Isso é importante para ter conectividade dentro do ambiente de chroot.
  9. CFLAGS que recomendo para o /etc/portake/make.conf: “-march=native -O2 -pipe” (helper)
  10. A partir daqui, nada especial, apenas continue seguindo o handbook do gentoo, até a parte do bootloader.
  11. Chegando na parte do bootloader, optei por deixar o Arch gerenciá-lo. Nesse caso, basta rodar um típico grub-mkconfig -o /boot/grub/grb.cfg que o Gentoo deverá ser automaticamente detectado (supondo que o pacote ‘os-prober’ esteja instalado).
  12. Configure a rede no Gentoo. Isso é bastante específico, mas o procedimento é bem parecido com a configuração da rede no Arch. A única questão é que, ao dar emerge no wpa_supplicant (no caso de você utilizar Wi-fi), vai demorar bastante até todas as dependências serem instaladas (esse é o ponto principal que me afastou do Gentoo até hoje. Sem pacotes binários, ter que compilar tudo localmente…ao menos, se no final a otimização do sistema for maior, pode ter valido mais a pena.)
  13. Teste o Gentoo durante uma semana e diga o que você achou dele 😉
  14. Decida se você gosta mais do Gentoo ou do Arch. Isso vale tanto para o sistema, tanto para a comunidade. Não tenho ideia de como seja a comunidade do Gentoo (a do Arch eu já tinha uma boa noção de como era mesmo antes de ter o sistema instalado).

Valeu pessoal. Como sou 100% newbie no Gentoo, apreciarei quaisquer dicas! (Enquanto as dicas não aparecem, Wiki Pages e Forums Threads me esperam). Sabe, é bom, de vez em quando, ser newbie em alguma coisa. Claro que ser expert / muito bom / hacker em algumas aplicações é ótimo, mas eu acredito na importância de possuir uma boa base de conhecimento em geral (não necessariamente apenas para fins acadêmicos ou financeiros, mas também para satisfazer a mente: desafios são importantes!).

Ah, mais dois comentários:

  1. Terminando de escrever esse post e de editá-lo, a compilação dos (130) pacotes que o wpa_supplicant puxou não chegou nem na metade…(eu teria instalado uns três ou quatro Archs automatizados nesse tempo – tá bom, não vale comparar pacotes binários com código-fonte, eu sei)
  2. Esse é o meu terceiro ou quarto post utilizando o org2blog (do emacs). Já ficou bastante claro para mim que vou passar a usá-lo de maneira fixa. O único problema é que eu ainda não sei a sintaxe de formatação dele direito, é muita informação. Não é nem que não seja intuitiva, mas já tem LaTeX, BBCode, Markdown, aí eu tenho que aprender mais uma markup language. Mas, provavelmente vou me submeter a isso, o orgmode é sensacional para management em geral.
Instalando o Gentoo a partir do Arch

Server Challenge – Instance #1: Installation of Distros

Today I’m covering the installation process of the following distros: Arch, Ubuntu Server, CentOS and openSUSE (as promised); together with the VirtualBox set up.

Let’s begin with the virtualization decisions. We are not creating any real applications, we just want a testing area. So, a virtual machine is the perfect place to poke around. The two obvious options for Linux (my Host/base system is Arch Linux, no surprise) are VirtualBox and VMWare (the free option). Actually, there’s QEMU also, but it is a little advanced (more advanced than I need now).

I opted for VirtualBox. Personally I have familiarity with both VBox and VMWare, but the last one is commercial and closed-source, and I want FOSS as much as possible.

Okay, and what about the decisions?

  • 16 GB for each virtual drive. That’s more than sufficient. 10-12 GB would probably be enough (we are not creating full-featured or storage servers).
  • 512 MB of RAM for each virtual machine. Just one exception: I chose 768 MB for openSUSE, because I knew it would start X by default (sounds like a bad thing for a server…maybe SLES doesn’t behave this way?)

Now, second things second: about downloading the ISOs. There was a good design about them: for every distro, the download was just two clicks away from their home pages.

We need to define a comparison framework to rank the distros. I’ll keep it simple: the best ones will be colored with blue (or green, that depends on my humor), the poor ones with red. If I do not have anything to say about them, I’ll just leave them away, with their default color.

  • Ubuntu: pretty straightforward. You quickly find the download page, either with Google or heading to www.ubuntu.com.
  • Arch:  no trouble, right? www.archlinux.org. There is only one ISO, but if you are considering Arch, you should probably knew that it defaults to a minimal installation environment.
  • CentOS: okay too. www.centos.org. A little hard to find the minimal ISO.
  • openSUSE: http://www.opensuse.org/ you might get confused at first. Which version would you download, the live or the one about network? ‘Network’ sounds like a server, right? I thought that too. But the problem is the description (see below): it does not mention anything related to servers; instead, it sounds more like a minimal ISO, better suited for upgrades.
Downloads the installation system and all packages from online repositories.Suitable for installation or upgrade.

Next: size of the ISOs.

  • Arch: ~500MB. Pretty good. Downside: if you want your favorite software already bundled with the ISO, you’ll be disappointed. Only the core components are included.
  • Ubuntu: ~650MB, nice, nice!
  • CentOS: ~4GB. Damn…unless you spot the minimal ISO: ~400MB.
  • ~950MB (KDE Live). Unless you notice the version you want is the ‘network’ one (it is not). ~300MB.

Now you just noticed I have committed one error. I simply downloaded the wrong (=full-featured) version of CentOS. More errors are to come! Just wait (Great…).

[I ended up with the DVD version of CentOS (because I only discovered the minimal version after the DVD one was installed; and with the KDE Live version of openSUSE — I got trouble with the network ISO. I say it wouldn’t be hard to get it right, but I’m managing 4 distros, besides my own system and my own life, so I do not want to waste my time with a virtual machine I know I’ll dispose a few days from here]

Then…what? Let’s install these beasts! Do not expect me to include screenshots. First, my design decisions:

  • There will be / and swap partitions. Swap will occupy the same as memory (512 MB; 768 MB for openSUSE). The rest will be owned by /. No /home.
  • Ext4 filesystem.
  • LVM! It would be too boring to setup only the classic MBR partition scheme.

Now, here is a brief overview of the installations:

  • Ubuntu: pretty standard ncurses-based setup. I liked it. There is only a little inconvenience: you have to get your options right since the beginning. If you change your mind later, after the installation, about a setup idea, you’ll have trouble figuring out what to do. I’ll repeat: the installer is good, but be sure of what you want. Want an example? Suppose you have set up the wrong timezone, or the wrong keyboard. How do you correct it after the installation? You’ll have to search how to do it, sure. Problem is: now you’ll use the command line. There will be no ncurses-based let-me-undo-my-previous-choice(s)-please. Using the command line is not a problem; the problem is the inconsistency of the pre- and pos-installation. If at least you could know what command the installer issued while you opted for a option with ncurses, it would be fine. But you don’t know. I’m saying hiding commands from the future sysadmin is not a good idea. It might be less scary for the inexperient/newbie learning about servers, but it is not for the I-know-how-to-handle-my-system guy.
  • CentOS: hated. Period. But it at least is intuitive. Problem: chose LVM by default. What if I didn’t want it?
  • openSUSE: I used the KDE Live version, but booted straight to the installation (not to the live environment). The openSUSE installer is amazing. Period. The best installer ever. You can customize (with an intuitive user interface) almost everything you want. For example, it would be ridiculously easy to choose btrfs for my server: the installer would take care of all trouble. So you should expect I had no trouble setting up LVM here. But it has the same flaw as Ubuntu: you don’t know what is happening behind the scenes.  Furthermore, this installer used X (with a mouse interface and everything). Also, after you reboot your VM, openSUSE begins its post-installation. It is the only one (at least, of my 4 distros) which does that.
  • Arch: no installer. I won’t color it red because this is part of the Arch design. The benefits are clear: you have full control over what your system will be. You are the master who controls (almost) every aspect, tweaking and customization of it. And you know exactly what commands you have entered. Now, this might be a problem too. But the problem is between the computer and the chair. If you lack the knowledge of some aspect of the installation (for example, I didn’t know how to setup LVM manually), the installation will take some time, because you’ll have to learn how to do it. But the ArchWiki is amazingly and vastly well documented, therefore you have no excuses. Bottom line: if you are able to set up an Arch server just by yourself, I expect you know what you were doing (GLaDos would be proud. Now, back to testing). Believe me: this is a rare skill. Of course you don’t need to set up Arch to be a skilled person, you can prove yourself an expert with (for example) Ubuntu too. What I’m saying is: using automatic installers is good to save time, but bad to acquire knowledge.

What’s next?

I still have to set up LVM on my Arch VM. I’ll make the following decision: there will be no Arch VM. I’ll use my own system (/ desktop) to play with an Arch server. Why? No need to duplicate effort. Buuuuuuuut I’ll create a VM just to learn (and correctly set up!) about LVM. At least I should to that.

Then, for the next post, there are two possibilities: a) how to set up LVM on Arch (maybe, with a description about LVM in general) or b) I have to think about this. What about LAMP? It looks like the next thing I should to. LAMP stands for Linux-Apache-MySQL-<insert_your_favorite_scripting_language_here>. P could be PHP, Python or Perl. Or Ruby, then we will have LAMR :). So, for b), I think Apache is the best continuation.

Until the next post, people. Comments about your own experiences with these distros are welcome.

Server Challenge – Instance #1: Installation of Distros