openSUSE 12.2 on a Gumstix Overo Fire

I’m having a late Hackweek (or hackish week, or at least a few hackdays), which seems like the ideal time to try running openSUSE on the Gumstix Overo Fire board that’s been sitting in my hackdrawer for the last year or so.  Thanks to the people working on the openSUSE ARM port, there are already suitable rootfs images and a kernel that’s close enough, so mostly this has been an exercise in getting the right bits onto a MicroSD card and learning how to interact with u-boot.

Current status: It boots and I can log in on the console.  The kernel seems to panic during shutdown. I haven’t tried networking, video, sound or anything else yet.

If anyone else wants to replicate my setup, you will need:

To prepare the MicroSD card (based on these docs):

  1. Plug it into your laptop or desktop system somehow (my laptop has an SD card reader).
  2. Figure out what device it is (in my case, it’s /dev/mmcblk0).
  3. Figure out how big it is, then partition it into a 64MB bootable FAT partition, and an ext3 Linux partition.  Apparently this involves some slightly weird geometry. Frankly I’m a bit dubious about this, given a couple of warnings, but it’s what the Gumstix docs said to do…
# fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 7958 MB, 7958691840 bytes
...
# echo 7958691840/255/63/512 | bc
967

Now we know how many cylinders to tell it to use (the -C parameter of sfdisk), so being careful not to break anything, we do this:

# dd if=/dev/zero of=/dev/mmcblk0 bs=1024 count=1024
...
# sfdisk --force -D -uS -H 255 -S 63 -C 967 /dev/mmcblk0
Checking that no-one is using this disk right now ...
OK
...
No partitions found Input in the following format; absent fields get a default value.
<start> <size> <type [E,S,L,X,hex]> <bootable [-,*]> <c,h,s> <c,h,s>
...
/dev/mmcblk0p1 :128,130944,0x0C,*
/dev/mmcblk0p1   *       128    131071     130944   c  W95 FAT32 (LBA)
/dev/mmcblk0p2 :131072,,,-
/dev/mmcblk0p2        131072  15544319   15413248  83  Linux
/dev/mmcblk0p3 :0,0
/dev/mmcblk0p3             0         -          0   0  Empty
/dev/mmcblk0p4 :0,0
/dev/mmcblk0p4             0         -          0   0  Empty
New situation:
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
/dev/mmcblk0p1   *       128    131071     130944   c  W95 FAT32 (LBA)
/dev/mmcblk0p2        131072  15544319   15413248  83  Linux
/dev/mmcblk0p3             0         -          0   0  Empty
/dev/mmcblk0p4             0         -          0   0  Empty
Warning: partition 1 does not end at a cylinder boundary
Warning: partition 2 does not start at a cylinder boundary
Warning: partition 2 does not end at a cylinder boundary
end of partition 2 has impossible value for cylinders: 967 (should be in 0-966)
Do you want to write this to disk? [ynq] y
Successfully wrote the new partition table
...
  1. Format and mount both partitions:
# mkfs.vfat -F 32 /dev/mmcblk0p1 -n boot
mkfs.vfat 3.0.10 (12 Sep 2010)
# mke2fs -j -L rootfs /dev/mmcblk0p2
mke2fs 1.41.14 (22-Dec-2010)
...
# mkdir /media/{boot,rootfs}
# mount /dev/mmcblk0p1 /media/boot
# mount /dev/mmcblk0p2 /media/rootfs
  1. Extract the JeOS image and the kernel RPM into the rootfs partition (this may take a while):
# tar -xjvf openSUSE-12.2-ARM-JeOS.armv7l-1.12.1-Build1.15.3.tbz -C /media/rootfs
...
# cd /media/rootfs
# rpm2cpio kernel-omap2plus-3.4.6-2.10.1.armv7hl.rpm | cpio -idmv
...
# cd
  1. Put MLO, u-boot.bin and the kernel uImage on the boot partition (MLO needs to go on first, and make sure you get the omap2plus uImage, not the default one, which won’t work):
# cp MLO /media/boot/
# cp u-boot.bin /media/boot/
# cp /media/rootfs/boot/uImage-3.4.6-2.10-omap2plus /media/boot/uImage
  1. Sync, unmount both partitions and remove the card:
# sync ; umount /media/boot ; umount /media/rootfs

To boot the Gumstix board:

  1. Insert the MicroSD card
  2. Plug the USB console in to your desktop/laptop and use screen (or kermit, or whatever) to connect to it:
# screen /dev/ttyUSB0 115200
  1. Apply power. You’ll almost certainly want to stop the autoboot and reset the envrionment:
Texas Instruments X-Loader 1.5.0 (Aug 29 2011 - 12:52:49)
OMAP3530-GP ES3.1
Board revision: 0
Reading boot sector
Loading u-boot.bin from mmc

U-Boot 2010.12 (Aug 22 2011 - 09:49:35)

OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz
Gumstix Overo board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0
In:    serial
Out:   serial
Err:   serial
Board revision: 0
Tranceiver detected on mmc2
No EEPROM on expansion board
Die ID #529e0004000000000403a1f303025013
Net:   smc911x-0
Hit any key to stop autoboot:  0 [ENTER]
Overo # nand erase 240000 20000
...
Overo # saveenv
...
Overo # reset
  1. If all has gone well, the system will boot, a few services will fail to start, and you’ll be able to log in as root (password “linux”)
Welcome to openSUSE 12.2 "Mantis" - Kernel 3.4.6-2.10-omap2plus (ttyO2).

linux login: root
Password: *****
This is the Lime-JeOS 12.2 SuSE Linux System.
To upgrade your system call:

    zypper refresh
    zypper install -t product openSUSE-12.2

Have a lot of fun...
linux:~ # uname -a
Linux linux 3.4.6-2.10-omap2plus #2 SMP Sat Sep 8 06:38:16 UTC 2012 armv7l armv7l armv7l GNU/Linux

Here’s some (remarkably poor quality) video proof:

Now I just need to figure out if the blinking red LED next to the ethernet port is blinking in merry happiness, or trying to warn me of impending doom.

Shameless High Availability Googlebait

I’m sure newcomers to high availability on Linux are still being bewildered by reams of readily googlable semi-ancient information floating out there in the ether.  So I’m going to try to help remedy this by saying:

This has been a public service announcement.  Thank you for reading.

That UEFI Secure Boot Thing

Yesterday Matthew Garret posted Implementing Secure Boot in Fedora, which was subsequently covered by Cory Doctorow in Lockdown: free/open OS maker pays Microsoft ransom for the right to boot on users’ computers.  I find myself somewhat torn by the whole affair.  I understand how the choice by Fedora to cough up $99 to have their shim bootloader signed by Microsoft can be seen as a sellout.  But at the same time, if your goal is to ensure your distro is bootable without forcing the user to screw around with their firmware settings, I think Fedora has probably made the least-worst choice, and I think other distros should also consider evaluating this approach.

Immediately, speaking purely practically, a single $99 payment by a distro to cover a (presumably) infrequently updated shim bootloader, and thus have Linux work with UEFI secure boot, is not terribly onerous.  Even if many distros did this, I’m not seeing it amounting to much of a revenue stream for Microsoft.  And it meets the stated goal (make Linux run on new hardware with minimum user effort or even awareness).  So that’s fine as far as it goes.

I’m far less happy about it from a political perspective, where this amounts to supporting another instance of what I’d call The Certificate Cartel, a term I used to apply to SSL CAs.

So, like I said, I find myself somewhat torn by the whole affair.