sata

flashrom 0.9.2 released -- Open-Source, crossplatform BIOS / EEPROM / flash chip programmer

The long-pending 0.9.2 version of the open-source, cross-platform, commandline flashrom utility has been released.

From the announce:

New major user-visible features:
* Dozens of newly supported mainboards, chipsets and flash chips.
* Support for Dr. Kaiser PC-Waechter PCI devices (FPGA variant).
* Support for flashing SPI chips with the Bus Pirate.
* Support for the Dediprog SF100 external programmer.
* Selective blockwise erase for all flash chips.
* Automatic chip unlocking.
* Support for each programmer can be selected at compile time.
* Generic detection for unknown flash chips.
* Common mainboard features are now detected automatically.
* Mainboard matching via DMI strings.
* Laptop detection which triggers safety measures.
* Test flags for all part of flashrom operation.
* Windows support for USB-based and serial-based programmers.
* NetBSD support.
* DOS support.
* Slightly changed command line invocation. Please see the man page for details.

Experimental new features:
* Support for some NVIDIA graphics cards.
* Chip test pattern generation.
* Bit-banging SPI infrastructure.
* Nvidia MCP6*/MCP7* chipset detection.
* Support for Highpoint ATA/RAID controllers.

Infrastructural improvements and fixes:
* Lots of cleanups.
* Various bugfixes and workarounds for broken third-party software.
* Better error messages.
* Reliability fixes.
* Adjustable severity level for messages.
* Programmer-specific chip size limitation warnings.
* Multiple builtin frontends for flashrom are now possible.
* Increased strictness in board matching.
* Extensive selfchecks on startup to protect against miscompilation.
* Better timing precision for touchy flash chips.
* Do not rely on Linux kernel bugs for mapping memory.
* Improved documentation.
* Split frontend and backend functionality.
* Print runtime and build environment information.

The list of supported OSes and architectures is slowly getting longer, e.g. these have been tested: Linux, FreeBSD, NetBSD, DragonFly BSD, Nexenta, Solaris and Mac OS X. There's partial support for DOS (no USB/serial flashers) and Windows (no PCI flashers). Initial (partial) PowerPC and MIPS support has been merged, ARM support and other upcoming.

Also, the list of external (non-mainboard) programmers increases, e.g. there is support for NICs (3COM, Realtek, SMC, others upcoming), SATA/IDE cards from Silicon Image and Highpoint, some NVIDIA cards, and various USB- or parallelport- or serialport- programmers such as the Busirate, Dediprog SF100, FT2232-based SPI programmers and more.

More details at flashrom.org and in the list of supported chips, chipsets, baords, and programmers.

I uploaded an svn version slightly more recent than 0.9.2 to Debian unstable, which should reach Debian testing (and Ubuntu I guess) soonish.

How to setup an encrypted USB-disk software-RAID-1 on Debian GNU/Linux using mdadm and cryptsetup

This is what I set up for backups recently using a cheap USB-enclosure which can house 2 SATA disks and shows them as 2 USB mass-storage devices to my system (using only one USB cable). Without any further introduction, here goes the HOWTO:

First, create one big partition on each of the two disks (/dev/sdc and /dev/sdd in my case) of the exact same size. The cfdisk details are omitted here.

  $ cfdisk /dev/sdc
  $ cfdisk /dev/sdd

Then, create a new RAID array using the mdadm utility:

  $ mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1

The array is named md0, consists of the two devices (--raid-devices=2) /dev/sdc1 and /dev/sdd1, and it's a RAID-1 array, i.e. data is simply mirrored on both disks so if one of them fails you don't lose data (--level=1). After this has been done the array will be synchronized so that both disks contain the same data (this process will take a long time). You can watch the current status via:

  $ cat /proc/mdstat
  Personalities : [raid1]
  md0 : active raid1 sdd1[1] sdc1[0]
        1465135869 blocks super 1.1 [2/2] [UU]
        [>....................]  resync =  0.0% (70016/1465135869) finish=2440.6min speed=10002K/sec
  unused devices: 

Some more info is also available from mdadm:

  $ mdadm --detail --scan
  ARRAY /dev/md0 metadata=1.01 name=foobar:0 UUID=1234578:1234578:1234578:1234578

  $ mdadm --detail /dev/md0
  /dev/md0:
          Version : 1.01
    Creation Time : Sat Feb  6 23:58:51 2010
       Raid Level : raid1
       Array Size : 1465135869 (1397.26 GiB 1500.30 GB)
    Used Dev Size : 1465135869 (1397.26 GiB 1500.30 GB)
     Raid Devices : 2
    Total Devices : 2
      Persistence : Superblock is persistent
      Update Time : Sun Feb  7 00:03:21 2010
            State : active, resyncing
   Active Devices : 2
  Working Devices : 2
   Failed Devices : 0
    Spare Devices : 0
   Rebuild Status : 0% complete
             Name : foobar:0  (local to host foobar)
             UUID : 1234578:1234578:1234578:1234578
           Events : 1
      Number   Major   Minor   RaidDevice State
         0       8       33        0      active sync   /dev/sdc1
         1       8       49        1      active sync   /dev/sdd1

Next, you'll want to create a big partition on the RAID device (cfdisk details omitted)...

  $ cfdisk /dev/md0

...and then encrypt all the (future) data on the device using dm-crypt+LUKS and cryptsetup:

  $ cryptsetup --verbose --verify-passphrase luksFormat /dev/md0p1
  Enter your desired pasphrase here (twice)
  $ cryptsetup luksOpen /dev/md0p1 myraid

After opening the encrypted container with cryptsetup luksOpen you can create a filesystem on it (ext3 in my case):

  $ mkfs.ext3 -j -m 0 /dev/mapper/myraid

That's about it. In future you can access the RAID data by using the steps below.

Starting the RAID and mouting the drive:

  $ mdadm --assemble /dev/md0 /dev/sdc1 /dev/sdd1
  $ cryptsetup luksOpen /dev/md0p1 myraid
  $ mount -t ext3 /dev/mapper/myraid /mnt

Shutting down the RAID:

  $ umount /mnt
  $ cryptsetup luksClose myraid
  $ mdadm --stop /dev/md0

That's all. Performance is shitty due to all the data being shoved out over one USB cable (and USB itself being too slow for these amounts of data), but I don't care too much about that as this setup is meant for backups, not performance-critical stuff.

Update 04/2011: Thanks to Bohdan Zograf there's a Belorussian translation of this article now!

Using Debian GNU/Linux on the Lenovo IdeaPad S9e netbook

TuxMobil - Linux on Laptops, Notebooks, PDAs and Mobile Phones Linux On Laptops

Lenovo Ideapad S9e netbook

I recently got my hands on a Lenovo IdeaPad S9e netbook for a short amount of time (I don't own it), so I did a few tests with Debian unstable (more or less Lenny right now) and a Linux 2.6.28 kernel on it, see results below.

The machine type is 4187-42G, and it features an Intel Atom N270 CPU (with HyperThreading) at 1.6 GHz, 1 GB of DDR2 RAM, an 80 GB SATA drive, an 8.9" WSVGA 1024x600 (glossy) screen, VGA port, LAN, wifi, bluetooth, 2xUSB, SD card slot, PCI ExpressCard slot, built-in microphone, and a webcam.

BIOS

You can enter the BIOS by pressing F2, the boot menu by pressing F12 during boot. Booting from USB works fine on this netbook. There's a Splashtop installation on the netbook (called "Lenovo Quickstart" here) which you can disable in the BIOS.

Installation

There's no CD-ROM drive, so the simplest way is to use a USB thumb drive for installation. Here's how you can prepare one containing a Lenny installer (assuming your USB thumb drive is /dev/sda):

  $ wget http://cdimage.debian.org/debian-cd/5.0.1/i386/iso-cd/debian-501-i386-netinst.iso
  $ wget http://ftp.nl.debian.org/debian/dists/lenny/main/installer-i386/current/images/hd-media/boot.img.gz
  $ gunzip boot.img.gz
  $ dd if=boot.img of=/dev/sda1
  $ mount -t vfat /dev/sda1 /mnt
  $ cp debian-500-i386-netinst.iso /mnt
  $ umount /mnt

If the above USB thumb drive doesn't boot correctly (which it did not in my case: GRUB error 17) it's probably because of a messed-up MBR. This is how you can fix it:

  $ apt-get install mbr
  $ install-mbr /dev/sda

 Lenovo Ideapad S9e Debian installation

Then insert the USB thumb drive in the Lenovo IdeaPad S9e, choose USB boot in the BIOS, and start the installer. Most of the process works as usual, the only small difference is that you might want to load the "parted" installer module in order to resize the Windows-partition on the disk (if you want to keep it) to make space for Linux. The second (fat32) partition seems to keep a restore image and/or the Splashtop stuff, not sure.

Audio

Works out of the box using the snd_hda_intel driver. The hardware is onboard audio in the southbridge (82801G / ICH7) and uses the Realtek ALC269 codec. If some programs don't have working audio, try modprobe snd-pcm-oss.

Built-in microphone

Untested so far.

Bluetooth

Works out of the box using the bluetooth and btusb driver. The laptop's Bluetooth device is USB-attached internally and shows up in lsusb as:

  $ lsusb
  Bus 003 Device 002: ID 0a5c:2150 Broadcom Corp.
  $ dmesg
  usb 3-2: Product: BCM2046 Bluetooth Device

After modprobe btusb you can use hcitool / hciconfig etc. as usual, and/or enable more related stuff with /etc/init.d/bluetooth start.

Sensors

The lm-sensors script detects the lm75, eeprom, i2c-dev, and i2c_i801 modules. The following is the 'sensors' output:

  $ sensors
  acpitz-virtual-0
  Adapter: Virtual device
  temp1:       +36.0 °C  (crit = +95.0 °C)    

The hard drive temperature can be viewed with:

  $ hddtemp /dev/sda
  /dev/sda: FUJITSU MHZ2080BH G1: 44 °C

HPET

The Intel ICH7 southbridge in this laptop supports High Performance Event Timers (HPET) which allows for more power savings and thus improved battery life.

  $ dmesg | grep -i hpet
  ACPI: HPET 3F6E1E41, 0038 (r1 INTEL  CALISTGA  6040000 LOHR       5A)
  ACPI: HPET id: 0x8086a201 base: 0xfed00000
  hpet clockevent registered
  HPET: 3 timers in total, 0 timers will be used for per-cpu timer
  hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
  hpet0: 3 comparators, 64-bit 14.318180 MHz counter

You can check the wakeups-per-second with powertop.

SD card slot

Works out of the box. It seems to be attached via USB internally (usb-storage driver).

  $ lsusb
  Bus 001 Device 004: ID 0bda:0158 Realtek Semiconductor Corp. Mass Stroage Device

PCI ExpressCard slot

Untested so far.

ACPI

Works fine, see comments for "acpitool" output.

Network card

Works out of the box using the tg3 driver.

  $ modprobe tg3
  tg3.c:v3.94 (August 14, 2008)
  tg3 0000:02:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
  tg3 0000:02:00.0: setting latency timer to 64
  eth0: Tigon3 [partno(BCM95906) rev c002 PHY(5906)] (PCI Express) 10/100Base-TX Ethernet 00:11:22:33:44:55
  eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[0] TSOcap[0]
  eth0: dma_rwctrl[76180000] dma_mask[64-bit]

Touchpad

Works out of the box, both in X as well as in the console using gpm.

  $ dmesg
  Synaptics Touchpad, model: 1, fw: 7.2, id: 0x1c0b1, caps: 0xd04731/0xa40000

Suspend-to-disk and suspend-to-RAM

I'm using the hibernate Debian package. You can explicitly force the usage of either method in /etc/hibernate/hibernate.conf by uncommenting the respective lines.

  TryMethod disk.conf
  # TryMethod ram.conf

Suspend does not yet work out of the box, however, as the machine is unknown:

  $ s2ram -n
  Machine unknown
  This machine can be identified by:
      sys_vendor   = "LENOVO                          "
      sys_product  = "418742G         "
      sys_version  = "Lenovo                  "
      bios_version = "14CN51WW  "
  See http://suspend.sf.net/s2ram-support.html for details.

After a few test I found that s2ram -f -a 3 works fine (tested from console only so far). Now this needs to be integrated upstream and in the Debian package (I'll file a bug report). Update: Submitted bug #520848, and an email to the upstream mailing list.

Wireless

There doesn't seem to be a mainline driver for the Broadcom BCM4312 wifi card in the laptop, yet:

  $ lspci -nn
  05:00.0 Network controller [0280]: Broadcom Corporation BCM4312 802.11b/g [14e4:4315] (rev 01)

Neither the b43 nor the b43legacy drivers work as of 2.6.28. For now, one of two possible options is to build a (partly non-free) driver provided by Broadcom from source (option 2 would be to use ndiswrapper, I guess, but that's untested):

  $ wget http://people.debian.org/~adamm/kernel/linux-kbuild-2.6.28_2.6.28-0.1_i386.deb
  $ dpkg -i linux-kbuild-2.6.28_2.6.28-0.1_i386.deb (currently needed in unstable due to bug #518115)
  $ apt-get install build-essential linux-headers-2.6.28-1-686
  $ mkdir temp; cd temp
  $ wget http://www.broadcom.com/docs/linux_sta/hybrid-portsrc-x86_32-v5_10_79_10.tar.gz
  $ tar xfvz hybrid-portsrc-x86_32-v5_10_79_10.tar.gz
  $ make -C /lib/modules/`uname -r`/build M=`pwd` clean
  $ make -C /lib/modules/`uname -r`/build M=`pwd` modules

If that worked, you can load the driver via:

  $ rmmod bcm43xx; rmmod b43; rmmod b43legacy (you could also permanently blacklist these modules)
  $ modprobe ieee80211_crypt_tkip
  $ insmod ./wl.ko
  $ dmesg
  wl: module license '' taints kernel.
  wl 0000:05:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
  wl 0000:05:00.0: setting latency timer to 64
  eth1: Broadcom BCM4315 802.11 Wireless Controller 5.10.79.10

You can now run iwconfig, iwlist, etc. from the command line, or use some GUIs such as kwifimanager.

In order to disable wireless, run:

  $ rmmod wl

So far, I only tested WEP (but not WPA).

CPU frequency scaling

Works out of the box using the acpi_cpufreq driver. Use cpufreq-set -c 0 -g performance if you need full CPU power, cpufreq-set -c 0 -g powersave otherwise. Use -c 1 to do the same with the other CPU/core.

PC speaker

Works fine out of the box using the pcspkr module, tested with beep.

Graphics card

Works out of the box using the intel X.org driver.

  $ xrandr
  Screen 0: minimum 320 x 200, current 1024 x 600, maximum 1024 x 1024
  VGA disconnected (normal left inverted right x axis y axis)
  LVDS connected 1024x600+0+0 (normal left inverted right x axis y axis) 195mm x 113mm
     1024x600      60.0*+
     800x600        60.3  
     640x480        59.9  
  TV disconnected (normal left inverted right x axis y axis)

DRI works out of the box with the (mainline, open-source) driver:

  $ glxinfo | grep direct
  direct rendering: Yes

If you attach an external monitor or projector, you can enable it using xrandr as usual:

  $ xrandr --output VGA --auto

You can also use a dual-head setup by adding this to your "Screen" section in /etc/X11/xorg.conf:

  SubSection "Display"
    Virtual 2048 2048
  EndSubSection

After restarting the X server, you can play with xrandr and move the external screen (VGA) "below" the laptop's LCD screen (LVDS) for a simple dual-head setup. The GUI tools arandr or grandr are probably a bit simpler to use than plain command line xrandr.

USB

Works fine, of course. The only small problem is that there are only two USB ports, more would have been better.

Disk drive

Works fine, it's an 80 GB SATA drive.

Webcam

Works out of the box using the uvcvideo driver.

  $ lsusb
  Bus 001 Device 005: ID 5986:0141 Acer, Inc
  $ modprobe uvcvideo
  uvcvideo: Found UVC 1.00 device Lenovo EasyCamera (5986:0141)
  input: Lenovo EasyCamera as /devices/pci0000:00/0000:00:1d.7/usb1/1-3/1-3:1.0/input/input9
  usb 1-3: New USB device found, idVendor=5986, idProduct=0141
  usb 1-3: New USB device strings: Mfr=3, Product=1, SerialNumber=0
  usb 1-3: Product: Lenovo EasyCamera
  usb 1-3: Manufacturer: BISON Corporation

You can use luvcvideo for webcam viewing.

Battery

Lasts for ca. 3.5 hours, probably less if the system is under high load.

Special keys

Fn+CursorUp / Fn+CursorDown (brightness), Fn+ESC (enable/disable webcam), Fn+F1 (sleep mode), Fn+F2 (enable/disable TFT backlight), Fn+F6 (enable/disable thouchpad), Fn+F7 (Num lock), Fn+F8 (scroll lock), and Fn+F11 (F12 key) all work fine.

Fn+F3, Fn+F5, Fn+F9, Fn+F10, and all other special keys are untested.

LEDs

The power, disk activity, CAPS lock, Num lock, and battery charging LEDs all work fine out of the box.

lspci -tvnn

  -[0000:00]-+-00.0  Intel Corporation Mobile 945GME Express Memory Controller Hub [8086:27ac]
           +-02.0  Intel Corporation Mobile 945GME Express Integrated Graphics Controller [8086:27ae]
           +-02.1  Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller [8086:27a6]
           +-1b.0  Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller [8086:27d8]
           +-1c.0-[0000:02]----00.0  Broadcom Corporation NetLink BCM5906M Fast Ethernet PCI Express [14e4:1713]
           +-1c.1-[0000:03-04]--
           +-1c.2-[0000:05]----00.0  Broadcom Corporation BCM4312 802.11b/g [14e4:4315]
           +-1d.0  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 [8086:27c8]
           +-1d.1  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 [8086:27c9]
           +-1d.2  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 [8086:27ca]
           +-1d.3  Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 [8086:27cb]
           +-1d.7  Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller [8086:27cc]
           +-1e.0-[0000:06]--
           +-1f.0  Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge [8086:27b9]
           +-1f.1  Intel Corporation 82801G (ICH7 Family) IDE Controller [8086:27df]
           +-1f.2  Intel Corporation 82801GBM/GHM (ICH7 Family) SATA IDE Controller [8086:27c4]
           \-1f.3  Intel Corporation 82801G (ICH7 Family) SMBus Controller [8086:27da]

cat /proc/cpuinfo

See comments.

Resources

All in all it's a really nice hardware, and it works (more or less) flawlessly without much hassle with recent distros/kernels.

Update 2009-03-22: Updated various sections, added more info. Added resources section.

Recovering from a dead disk in a Linux software-RAID5 system using mdadm

RAID5 failure

As I wrote quite a while ago, I set up a RAID5 with three
IDE disks at home, which I'm using as backup (yes, I know that
RAID != backup) and storage space.

A few days ago, the RAID was put to a real-life test for the first time, as one of the disks died. Here's what that looks like in dmesg:

raid5: raid level 5 set md1 active with 3 out of 3 devices, algorithm 2
RAID5 conf printout:
 --- rd:3 wd:3
 disk 0, o:1, dev:hda2
 disk 1, o:1, dev:hdg2
 disk 2, o:1, dev:hde2
[...]
hdg: dma_timer_expiry: dma status == 0x21
hdg: DMA timeout error
hdg: 4 bytes in FIFO
hdg: dma timeout error: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hdg: dma_timer_expiry: dma status == 0x21
hdg: DMA timeout error
hdg: 252 bytes in FIFO
hdg: dma timeout error: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hdg: dma_timer_expiry: dma status == 0x21
hdg: DMA timeout error
hdg: 252 bytes in FIFO
hdg: dma timeout error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hdg: DMA disabled
ide3: reset: success
hdg: dma_timer_expiry: dma status == 0x21
hdg: DMA timeout error
hdg: 252 bytes in FIFO
hdg: dma timeout error: status=0x58 { DriveReady SeekComplete DataRequest }
ide: failed opcode was: unknown
hdg: DMA disabled
ide3: reset: success
hdg: status timeout: status=0x80 { Busy }
ide: failed opcode was: 0xea
hdg: drive not ready for command
hdg: lost interrupt
hdg: task_out_intr: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown
hdg: lost interrupt
hdg: task_out_intr: status=0x50 { DriveReady SeekComplete }
ide: failed opcode was: unknown

That's when I realized that something was horribly wrong.

Not long after that, these messages appeared in dmesg. As you can see the software-RAID automatically realized that a drive died and removed the faulty disk from the array. I did not lose any data, and the system did not freeze up; I could continue working as if nothing happened (as it should be).

 md: super_written gets error=-5, uptodate=0
 raid5: Disk failure on hdg2, disabling device.
 raid5: Operation continuing on 2 devices.
 RAID5 conf printout:
  --- rd:3 wd:2
  disk 0, o:1, dev:hda2
  disk 1, o:0, dev:hdg2
  disk 2, o:1, dev:hde2
 RAID5 conf printout:
  --- rd:3 wd:2
  disk 0, o:1, dev:hda2
  disk 2, o:1, dev:hde2

This is how you can check the current RAID status:

 $ cat /proc/mdstat
 Personalities : [raid6] [raid5] [raid4] 
 md1 : active raid5 hda2[0] hde2[2] hdg2[3](F)
       584107136 blocks level 5, 64k chunk, algorithm 2 [3/2] [U_U]

The "U_U" means two of the disks are OK, and one is faulty/removed. The desired state is "UUU", which means all three disks are OK.

The next steps are to replace the dead drive with a new one, but first you should know exactly which disk you need to remove (in my case: hda, hde, or hdg). If you remove the wrong one, you're screwed. The RAID will be dead and all your data will be lost (RAID5 can survive only one dead disk at a time).

The safest way (IMHO) to know which disk to remove is to write down the serial number of the disk, e.g. using smartctl, and then check the back side of each disk for the matching serial number.

 $ smartctl -i /dev/hda | grep Serial
 $ smartctl -i /dev/hde | grep Serial
 $ smartctl -i /dev/hdg | grep Serial

(ideally you should get the serial numbers before one of the disks dies)

Now power down the PC and remove the correct drive. Get a new drive which is at least as big as the one you removed. As this is software-RAID you have quite a lot of flexibility; the new drive doesn't have to be from the same vendor / series, it doesn't even have to be of the same type (e.g. I got a SATA disk instead of another IDE one).

Insert the drive into some other PC in order to partition it correctly (e.g. using fdisk or cfdisk). In my case I needed a 1 GB /boot partition for GRUB, and the rest of the drive is another partition of the type "Linux RAID auto", which the software-RAID will then recognize.

Then, put the drive into the RAID PC and power it up. After a successful boot (remember, 2 out of 3 disks in RAID5 are sufficient for a working system) you'll have to hook-up the new drive into the RAID:

 $ mdadm --manage /dev/md1 --add /dev/sda2
 mdadm: added /dev/sda2

My new SATA drive ended up being /dev/sda2, which I added using mdadm. The RAID immediately starts restoring/resyncing all data on that drive, which may take a while (2-3 hours, depends on the RAID size and some other factors). You can check the current progress with:

 $ cat /proc/mdstat 
 Personalities : [raid6] [raid5] [raid4] 
 md1 : active raid5 sda2[3] hda2[0] hde2[2]
       584107136 blocks level 5, 64k chunk, algorithm 2 [3/2] [U_U]
       [>....................]  recovery =  0.1% (473692/292053568) finish=92.3min speed=52632K/sec

As soon as this process is finished you'll see this in dmesg:

 md: md1: recovery done.
 RAID5 conf printout:
  --- rd:3 wd:3
  disk 0, o:1, dev:hda2
  disk 1, o:1, dev:sda2
  disk 2, o:1, dev:hde2

In /proc/mdstat you'll see "UUU" again, which means your RAID is fully functional and redundant (with three disks) again. Yay.

 $ cat /proc/mdstat
 Personalities : [raid6] [raid5] [raid4] 
 md1 : active raid5 sda2[1] hda2[0] hde2[2]
       584107136 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]

Btw, another nice utility you might find useful is hddtemp, which can check the temperature of the drives. You should take care that they don't get too hot, especially so if the RAID runs 24/7.

 $ hddtemp /dev/hda
 dev/hda: SAMSUNG HD300LD: 38 °C
 $ hddtemp /dev/hde
 dev/hde: SAMSUNG HD300LD: 44 °C
 $ hddtemp /dev/sda
 dev/sda: SAMSUNG HD322HJ: 32 °C

Once again QEMU saved the day...

Suppose you want to try out Xen for the first time, and you're a bit paranoid careful because, well, you don't want to break your system. No problem, just download the Xen 3.0 Demo CD Image (a live CD). Or so I thought; it took me a loong time to even find a download link for that beast. There seems to be no ISO image for 3.0.4, but only for 3.0.3 (gah!).

Anyways, the live CD seems to try to mount /dev/sda as my CDROM drive, which is... um... stupid, as that's a harddrive. A SATA harddrive to be more specific. A dm-crypt'ed hard drive to be even more specific. So there's no way the live CD can ever mount that. I was dropped into a minimalist shell, but couldn't figure out how to fix anything from there, and a quick look at the docs didn't reveal anything either.

So here's my fix:

  • Boot the normal OS, insert the live CD.
  • Start the live CD in QEMU: qemu -cdrom /dev/cdrom -boot d
  • Done. I had some problems with graphics in QEMU, so I chose the command line boot option of the live CD...

Nice huh? QEMU's hard drive is an IDE drive, it's called /dev/hda (instead of /dev/sda), thus the live CD works fine.

(Yes, I'm sure this could be fixed "the right way" too, but this is a nice way to get quick results, i.e. a working Xen test setup)

Syndicate content