Tag Archives: Linux

Playing with the Odroid-U2

Picked up one of Hardkernel’s Odroid-U2 dev boxes, figured a quad-core arm box for less than $100 shipped was worth kicking around a bit. After a week-ish of playing with it I thought it worth posting my findings with various OS variants. For reference, I am using Class 10 microSDHC cards (anything less is painfully slow) and a wired connection while I wait on my USB wifi dongle to show up.

I don’t really have a specific use case for the box, but the main categories I’m poking at are media playback (using XBMC, Plex, Netflix), gaming, and general web/app usage. One big downside for general usage across all the Android builds is that the user interface is only moderately okay if you’re not using a touch screen. Swiping through pages is great using fingers, not so much via a normal mouse…

Stock Android
The first thing I tried was the latest official Android build (dated 25th April, 2013). It’s using version 4.1.2_r1 as it’s base with some custom bits as follows:

  • Right mouse click as the back button
  • Power button on the navigation bar
  • No status bar
  • Mounts SD card as internal storage
  • Working(-ish) USB bluetooth support

Overall it’s a very solid build, however trying to use Netflix or Plex to view videos resulted in a black screen with audio. According to the official forums, it’s a known issue with their 4.1 builds and their advice is to revert back to the 4.0.* based builds instead. I didn’t try going that route since I already had my eye on the CM nightlies. Running XBMC was generally okay here but the UI lagged and there were some visual glitches during playback (mostly menu overlays). Although my cheap BT dongle was seen and I was able to pair my phone with the Odroid, I couldn’t ever get my Moga gaming controller to pair properly so I couldn’t do any real game testing. I’m assuming this was more to do with the dongle and not the build since I saw folks on the forums able to use BT controllers without issues.

CyanogenMod
My next try with Android was CyanogenMod nightlies. It’s based on version 4.2.2 and is overall a better option (IMO) than stock. Media playback Just Works, had no issues with Netflix, Plex was able to do playback of some high bitrate 1080p h264 streams without any glitches. XBMC here has been almost flawless with only minor hiccups during playback. This is certainly the faster of the two Android builds, and the kernel allows overclocking to 2Ghz to give it a boost if you’re so inclined (I wasn’t). However, there are a few gotchas involved through the install and usage.

First, the procedures outlined on the CM wiki to install weren’t entirely complete. After installing the initial image as directed I was unable to reboot into recovery mode. Took a bit of digging, but I grabbed the odroidu2-recovery.zip file they list for the windows install instructions and unzip’d to the root of the vfat partition before rebooting. This seems to only be needed for the initial install, subsequent reboot-to-recovery attempts from an installed CM nightly worked just like it should.

The next big gotcha was with the way CM mounts the sd card. It’s fstab file is setup to treat the eMMC card as the internal sd and the micro sd as external which is great if you’re using eMMC, not so much if you aren’t. Fixing it requires editing /system/etc/vold.fstab and swapping the entries, I’ve got a copy here you can just copy over to fix things. You’ll have to do that after each update since the file is replaced during the flash.

The last thing worth mentioning isn’t really a problem but, since the CM build treats this as a tablet and stays close to ASOP, you get the normal tablet interface. So you’ll need to grab your own power widgets (I use secure settings) and deal with the normal status navigation bar. For the latter I just set up a tasker profile to enable the “Expanded Desktop” option (via secure settings) when XBMC is running to get true full screen.

Linux
For this I used the Ubuntu 12.11 Fully Loaded community image from the odroid forums. It’s a great image with several full desktop environments to chose from, very fast and usable. Using it out of the box on a TV screen requires tweaking DPI or font sizes to be able to read anything, but once that’s done it’s pretty straightforward. The only thing really worth mentioning as a downside is viewing YouTube videos in the Chromium browser is painful since there’s no hardware acceleration of the webm codec. Using Firefox with the provided greasemonkey scripts will allow you to chose the h264 versions of the videos which do work at up to 1080p res without issue.

I think you could use this as a desktop replacement as long as you kept your home directory on either a secondary device (USB drive?) or NFS volume, but flashing wipes EVERYTHING so you wouldn’t want to keep a local home directory. The image also includes various emulators and games, but I haven’t had a chance to try those so I can’t speak to how those worked.

In summary, this little beast draws almost no power and has enough horsepower to do quite a bit. I’m looking forward to support maturing in Android and Linux to take full advantage of the hw, but the potential for usage here is huge.

Moar RAID Win

Had to upgrade my storage over the past week and decided to see just how good Linux software raid (mdadm) and SATA hot plugging were these days. The current setup was a five disk array with two 1TB and three 750GB drives attached to an ASUS M3A76-CM motherboard in AHCI mode. My first issue was that all five drives were attached internally so access would require mucking about in the case to replace the three disks so I dug around and ended up purchasing a Supermicro CSE-M35T-1B so I would be able to swap the disks out easily.

After getting the original drives shifted into the new rack, it was as easy as 1-2-3(ish) to replace the drives (with the filesystem live):

  1. mdadm /dev/md1 --fail $PARTITION --remove $PARTITION
  2. Replace disk, create partition
  3. mdadm /dev/md1 --add $PARTITION, resync

Each resync after the replacement took 3-4 hrs and the fan in the rack kept the disks no warmer than 32C. After the final disk was done and synced, I expanded the array to include the new space:
mdadm --grow /dev/md1 --size=max
Then let lvm know the new space was usable:
pvresize /dev/md1
And ran vgdisplay to see my extra ~940GB.

Gawd it’s nice when stuff Just Works.

Xen and vlans

During a big lab move at work a few months ago, we decided that our utility virt server needed VLAN support. The dhcp vm needed interfaces on three different networks and it seemed rather silly to add extra physical interface for the minimal traffic generated.

The first issue we encountered was the rather interesting bridging script installed by default. It does wonders for being able to bridge the primary interface and can be used to bridge multiple interface, but it fails entirely for VLAN interfaces. Best bet is just to disable any network scripts in /etc/xen/xend-config.sxp and let the os handle it. We’re using RHEL5, so we created the VLAN interface along with the bridge using the normal configs in /etc/sysconfig/network-scripts. Our naming scheme for the devices was ${DEVICE_TYPE}{$VLAN_NUMBER}.conf.

Example vlan123.conf:

DEVICE=vlan123
VLAN=yes
VLAN_NAME_TYPE=VLAN_PLUS_VID_NO_PAD
PHYSDEV=eth1
BOOTPROTO=static
ONBOOT=yes
BRIDGE=xenbr123

As you can see, eth1 is the physical interface connected to the switch port tagged with the vlans. We added the ‘VLAN_PLUS_VID_NO_PAD’ param to use the vlan${NUMBER} scheme. We aren’t bringing the interface up with an ip as it’s gonna be part of a bridge.

xenbr123.conf:

DEVICE=xenbr123
TYPE=Bridge
BOOTPROTO=static
ONBOOT=yes

This brings up our bridge without an ip address. The dom0 doesn’t need an ip on this VLAN, so no point in enabling it. To use the bridge in your domu’s, just specify the interface in the config file (or at creation time).

Example domu def file with multiple interfaces:

name = "example"
uuid = "62e4f71f-a46c-25f7-e947-f161aaad6f00"
maxmem = 512
memory = 512
vcpus = 1
bootloader = "/usr/bin/pygrub"
on_poweroff = "destroy"
on_reboot = "restart"
on_crash = "restart"
vfb = [ ]
disk = [ "phy:/dev/vm/example,xvda,w" ]
vif = [ "mac=00:16:3e:4b:a5:46,bridge=xenbr123", "mac=00:16:3e:4b:a5:4a,bridge=xenbr456", mac=00:16:3e:4b:a5:47,bridge=xenbr789"]

The above was pretty straightforward, but after putting it in place we ran into a very odd issue. The vm’s couldn’t actually communicate via the vlan’d interfaces. After a bit of tcpdumping we discovered the default firewall was allowing outbound traffic on the bridge, but incoming was getting rejected. Easy fix was to add the following lines to /etc/sysconfig/iptables:


-A RH-Firewall-1-INPUT -i xenbr+ -j ACCEPT
-A RH-Firewall-1-INPUT -o xenbr+ -j ACCEPT

Note that this allows all traffic to pass on all xenbr devices. Since the dom0 doesn’t have an ip bound it’s not an issue in our configuration since the only traffic on the bridges are for the domu’s. If you do use the devices in your dom0, you’ll need to adjust the firewall accordingly or you’ll end up with a gaping hole in your security scheme.

Sammich

Gimmie a sandwich!

Fedora n Mythtv n Hellanzb oh my!

I’ve been running Gentoo on it for forever, but lately I’ve grown tired of dealing with the weekly tree breakage and hassles. I also wanted to attempt a 64 bit OS in the hopes it would gain me enough to play h264-encoded files w/o glitches.

My first attempt was using Ubuntu, but performance wasn’t much better and I was seeing some video tearing. My second attempt was Fedora Core 6. Performance was amazing. MythTV was more responsive and video files played glitch-free. However, ndiswrapper was causing the machine to lockup randomly. This seems to be an issue with the rt73 driver as I saw it on both my installations. My next step was to do a 32 bit install of FC6 and I was shocked to see the same MythTV performance as before. I dunno what magic is being done there, but I likes a whole lot. H264 file seem to be playing a bit better, tho not as smoothly as I’d like.

Getting the rest of my required stack (Hellanzb, Hellahella, etc.) was a snap. There’s no packages for the Hella* stuff, but most of the deps are in extras so installing was a snap. I ended up getting MythWeb installed as part of the ‘Mythtv-Suite’ metapackage so I attempted to run Hellahella behind an apache proxy. Failure was complete there due to hardcoded paths. A bit of Googling later and I found some very helpful instructions on setting it up via mod_python. Those instructions assume you are running apache for Hellahella exclusively (or as a NameVirtualHost). I’m not, so here’s my config:

<location /hella>
SetHandler mod_python
PythonHandler mod_python.wsgi
PythonPath "['/var/www/hellahella/'] + sys.path"
PythonOption wsgi.application startup::app
PythonOption SCRIPT_NAME /hella
</Location>
Alias /stylesheets/ "/var/www/hellahellaMedia/stylesheets/"
Alias /javascripts/ "/var/www/hellahellaMedia/javascripts/"
Alias /images/ "/var/www/hellahellaMedia/images/"

Switch to our mobile site