Linux on AIRIS Kira N7000

Yesterday I installed Linux (a distribution called Kirbian, excellent job by these guys: http://kirbian.wordpress.com, thanks!!! ) on a AIRIS Kira N7000, an arm based netbook.

Just to help anyone who wants to do the same, I managed to make Wikidpad work on this device. The original wxPython library did not work in this hardware, it threw an “illegal instruction” exception, but after compiling the library on the device, it worked perfectly. Even with 256MB of RAM, it is perfectly suitable for my purposes.

I would like to have Dropbox in the device, but there is still no dropbox for arm. If you are a dropbox user, you can vote for this development in: https://www.dropbox.com/votebox/358/linux-arm-support, as I mentioned in my previous post.

So I installed btsync in both my laptop and kira, and will synchronize Dropbox between them, until there is some arm support from dropbox…

Image

Advertisements

OpenSuSE not booting after upgrading from 12.1 to 12.2

Hi all, this post has nothing to do with Raspberri Pi, but following its advices will be very valuable in any Linux system.

The problem.

I upgraded my PC with OpenSuSE 12.1 to 12.2 following this guide: http://en.opensuse.org/SDB:System_upgrade

Nothing new, I have been upgrading this system from 11.2 following more or less the same procedure.

After upgrading, the system does not boot. Well, it did boot, but got stuck at some point and did not show neither XWindow nor shell.
I tried booting in single mode (in OpenSuSE, just write “single” when the grub menu shows up), and the same symthoms.
This system, since 12.1 upgrade, is booting with systemd instead of sysvinit, so I tried to go back to old sysvinit (press F5 in grub menu or add init=/sbin/init to boot command line). It said that I did not have any /etc/inittab, maybe I lost it during the upgrade. So let’s try the shell boot.

On boot menu, write “init=/bin/sh” or press F5 and choose “Shell”. That drives you to a system with no network, no graphical interface, a very limited system with no services at all, but with a PROPMT!
On this shell, you can see, as I saw, that the special device files for a mirror disk had changed from /dev/md1 to /dev/md127. Linux, did not find my mirror. Also, I found that special device files for raw disks had also changed, but fortunately I had them mounted using either LVM or /dev/disks/by-id device files.

The solution
Well, using this shell boot you can edit fstab and make the system boot again. Once you have booted (or before, but you don’t have copy paste features 🙂 ), use udevadm to find information about mounted disks, this way:
# udevadm info -q all -n /dev/sda1 | grep DEVLINKS

You get something like:
E: DEVLINKS=/dev/disk/by-id/ata-ST9320423AS_5VH3W3P8-part1 /dev/disk/by-id/scsi-SATA_ST9320423AS_5VH3W3P8-part1 /dev/disk/by-id/wwn-0x5000c50029cb080f-part1 /dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0-part1

Use one of the by-id special device files instead of /dev/sdXP because the latter can change due to upgrades, race conditions or simply hardware relocation of disks. Using /dev/disk/by-path device files can yield the same problems, because it depends on the hardware path of the disk, and it can change if you have a screwdriver at home.

I also got rid of md mirroring and migrated the disk to LVM, for one thing, I didn’t have a mirror at all, just a “one disk mirror”… historical reasons… LVM could have mounted this disk, because lvols device files do not depend on disk location or udev discovering. For instance, /dev/vg01/lvol1 will always be /dev/vg01/lvol1 as long as the vg metadata is not corrupted, so you can trust LVM and use lvol device files in fstab.

You can also write udev rules in order to call your disks anything you want, depending on serial number, size of the disk, etc. and use that name in fstab.

Trusting any kind of raw special device files is not a good practice at all. This is the same that trusting /dev/dsk/cXtYdZ device files in HP-UX, they depend on the path to the disk. On the other hand, /dev/disk/diskX special device depend on the disk itself. As long as you do not change WWID of disk, this device file does not change even if you change the hardware path of the disk (in HP-UX 11.31 at least). However, it is a good practice to use LVM in HP-UX because it isolate you from hardware details, you can even migrate disks physically and keep the same fstab, because the LVM device files depend on the metadata, not the hardware paths.