Blog - dyncall and more

9front support

I got around testing dyncall on 9front, yesterday, and it works pretty much out of the box. 9front will be another OS supported by our automated test framework dynOS, from now on. If you like Plan 9, you'll love 9front, give it a try!

Support for Raspberry Pi in dyncall (and dynOS)

Daniel ported dyncall to the Raspberry Pi a few weeks ago. This means we support armhf, now, and this will be part of the 0.8 release. I was able to get it under fully automated tests, as well, running Raspbian as a new OS supported by our test framework, dynOS:

Booting from USB or network (PXE) without BIOS support

Recently, I needed to setup a FreeBSD embedded box - the board had a single SATA interface, only. Having a hard drive hooked up to it, and no access to a CD-drive, I was left with booting the install medium from either USB or PXE (or somehow getting the system on the hard drive, directly). Unfortunately, the rather old BIOS didn't allow me to select neither USB nor PXE as boot options.
Since the hard drive didn't have anything on it, I obviously wasn't able to boot from it, so hooking it up to a different machine and getting FreeBSD somehow on it seemed to be the only option. Interestingly, I didn't even have to go that far. :)

As it turns out, all I needed was a valid MBR on the drive that would allow me to boot from either PXE or USB, and boot0 did exactly that. I honestly don't understand exactly how boot0 detects those devices, but using the following (within a FreeBSD environment, where <device> is the device name of the hard drive we want to put in the embedded machine, later) does the trick:

boot0cfg -B <device>

Putting the drive back into the embedded box, and firing it up, displayed boot0's spartan boot menu and allowed me to boot from an attached USB drive (which had FreeBSD's "memstick" image on it) and even PXE! I guess this works with other boot managers, as well, don't know... So, in the end I was able to boot off the hard drive with boot0 which in turn allowed me to pass the boot process on to my USB device, to then install FreeBSD to the former.
If not having access to a FreeBSD machine with boot0cfg, one could even use fdisk to write the boot0 template (download FreeBSD and get /boot/boot0, then write it using fdisk), e.g. within OpenBSD (didn't check other fdisk versions):

fdisk -f <boot0_template_file> -u <device>

How to autologin on different operating systems

When I started putting together the first OS images for dynOS, our automated dyncall testing environment, the goal was to get some privileged user to login automatically (in our case the superuser), then to trigger the build process and finally the tests, etc.. Unfortunately, it is not as straightforward as it sounds - and maybe it shouldn't be, as autologins are obviously bad in terms of security. Sometimes it's pretty useful and safe to make use of them, though, as in exactly this case: virtual machines used for testing.
Below is a simple list of some operating systems and how to set them up to log in automatically - I'm pretty sure there are better ways for some of them, the list just reflects what worked well enough for me:

Plan9

Replace <mountpoint> below with whatever directory name you feel like; same goes for using the correct device (<drive> - was sdC0 in my case).
I only tested this on x86, don't know about other architectures.

• mount 9fat partition using:
  term% dossrv
  term% mount -c /srv/dos /mnt/<mountpoint> /dev/<drive>/9fat
• add to /mnt/<mountpoint>/plan9.ini:
  user=glenda
  nobootprompt=local!#S/<drive>/fossil

NetBSD

• edit /etc/gettytab and modify the options under 'default:\' to contain
  al=root
  For example:
  default:\
    :ce:al=root:ck:np:im=\r\n%s/%m (%h) (%t)\r\n\r\n:
• the above autologin method applies to all enabled terminals (which would result in running our scripts in parallel), make sure that all console terminals other than the ones you want to login are turned off in /etc/ttys (on -> off)

OpenBSD

• force login at end of /etc/rc.local by appending
  login -f root

DragonFly

• edit /etc/gettytab and modify the options under 'default:\' to contain
  al=root
  For example:
  default:\
   :cb:ce:al=root:ck:lc:fd#1000:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200:\
   :if=/etc/issue:
• since dragonfly seems to login into all enabled terminals at once, which would result in running all login scripts in parallel, simply turn ttyv1-ttyv7 off, in /etc/ttys (on -> off)

Haiku

• current versions don't have multi-user support and seem to always login automatically by default

GNU (most Linux distributions, Debian kFreeBSD, ...)

• make sure either mingetty or agetty is installed, and modify /etc/inittab, so that the c1-line points to mingetty or agetty with the following extra options:
  for agetty: "-n -l /usr/bin/autologin.sh"
  for mingetty: "--autologin root --noclear"
• When using agetty, create /usr/bin/autologin.sh with execute permission and the following contents:
  #!/bin/sh
  exec /bin/login -f root
• If it still asks for a password after reboot, edit /etc/login.defs to add:
  NO_PASSWORD_CONSOLE tty1

Windows

• Windows XP with a single user logs in automatically
• didn't setup other Windows version for dynOS, yet

Minix

• a fresh install of Minix 3 logs in automatically

Finally, a blog

Well, what should I say? Getting to know many different operating systems and processor architectures over the last few years while working on dyncall was quite an experience. Starting and running a blog about all of that was way overdue. This will be about sharing some of the interesting tidbits we came across, putting ideas out, posting upcoming things, etc..
Excited! ;)