Author: markus

KVM too fast for plymouth-upstart-bridge

Kind of a hilarious bug, really… I recently installed another Ubuntu 14.04 server running inside a KVM with a rather fast storage backend, therefore the system apparently boots just a tiny bit faster than my other images have in the past. Problem is, apparently that slows down the boot process as init thinks something must be crashing and decides to respawn it for good measure…

[ 2.311174] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
[ 2.811553] init: plymouth-upstart-bridge main process (191) terminated with status 1
[ 2.812789] init: plymouth-upstart-bridge main process ended, respawning
[ 2.874117] init: plymouth-upstart-bridge main process (210) terminated with status 1
[ 2.875167] init: plymouth-upstart-bridge main process ended, respawning
[ 2.904155] init: plymouth-upstart-bridge main process (217) terminated with status 1
[ 2.905289] init: plymouth-upstart-bridge main process ended, respawning
[ 2.928618] init: plymouth-upstart-bridge main process (221) terminated with status 1
[ 2.929713] init: plymouth-upstart-bridge main process ended, respawning
[ 49.975826] Adding 2093052k swap on /dev/mapper/[...]

Yep, that’s right – 47 seconds waiting and idling, doing nothing when the image could have booted in a fraction of that time.

To fix it, simply add a sleep 2 to your /etc/init/plymouth-upstart-bridge.conf

[...]
stop on (stopping plymouth
         or stopping plymouth-shutdown)     

console output

exec plymouth-upstart-bridge
sleep 2

Init won’t freak out anymore and starts the image as it’s supposed to:

[    1.225045] random: lvm urandom read with 16 bits of entropy available
[    1.281118] bio: create slab <bio-1> at 1
[    1.370262] EXT4-fs (dm-0): mounted filesystem with ordered data mode. Opts: (null)
[    1.684687] tsc: Refined TSC clocksource calibration: 2500.001 MHz
[    2.153550] Adding 2093052k swap on /dev/mapper/[....]-swap_1.  Priority:-1 extents:1 across:2093052k FS
[    2.169332] EXT4-fs (dm-0): re-mounted. Opts: errors=remount-ro
[    2.190451] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
[    2.408937] EXT4-fs (vda1): mounting ext2 file system using the ext4 subsystem
[    2.417990] EXT4-fs (vda1): mounted filesystem without journal. Opts: (null)
[    3.316769] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    3.316778] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[    3.495345] FS-Cache: Loaded

Way better….

Updating SmartArray controllers on 64-bit Ubuntu 14.04

Want to install a firmware update on one of your HP SmartArray controllers while running a 64-bit OS? Turns out, the binaries distributed by HP seem to be 32-bit only – running for example Ubuntu 14.04, here’s what you gotta do…

root@host:~#./CP021971.scexe 
./CP021971.scexe: 153: ./CP021971.scexe: pushd: not found
./CP021971.scexe: 158: ./CP021971.scexe: popd: not found
./ccissflash: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

 

But libstdtc++6 seems already installed, hmpf… 32-bit maybe?

root@host:~# dpkg --add-architecture i386
root@host:~# apt-get update
root@host:~# apt-get install libstdc++6:i386
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  gcc-4.8-base:i386 gcc-4.9-base:i386 libc6:i386 libgcc1:i386
[...]

 

Let’s try that again…

root@host:~#./CP021971.scexe                                                                                                                                               
./CP021971.scexe: 153: ./CP021971.scexe: ./CP021971.scexe: 158: ./CP021971.scexe: popd: not found
pushd: not found

        This program consists of two phases: device discovery and device update.
        No device will be updated until you answer.

Do you want to run device discovery?
(yes/no) yes
Finding hardware. This may take a few minutes.
Found 1 devices.

Do you want to upgrade the device that has older ROM?
(yes/no) yes
1 devices will be updated.
Updating: P410i Slot: 0 from [5.70] to [6.40]
Updating: P410i Slot: 0 from [5.70] to [6.40]

As part of the reboot process, you must power cycle the server and any external array storage devices.

Well, that was rather easy…

Fix for bad write performance with LUKS + RAID5

After setting up a new fileserver with an LUKS encrypted dataset on top of Linux software RAID5 I did some benchmarks and reliability testing before filling it up with “real” data… but it turns out write performance was quite horrible. Only a fraction of what the “raw” RAID5 could do, all while having the CPU mostly idle. So what’s going on?

Apparently only small blocks of data get written to the disks when using LUKS encrypted volumes (mostly default settings) therefore dramatically reducing write performance (figured it out thanks to this) on my RAID 5 volume. Setting the stripe_cache_size from 256 to 8192 increased throughput from roughly 50-70 MB/sec to well above 200 MB/sec.

echo 8192 > /sys/block/md0/md/stripe_cache_size

To permanently set it, so you don’t have to manually adjust it after every reboot, consider setting up a udev rule like this:

/etc/udev/rules.d/md-stripe-cache.rules


SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="8192"