plaes.org | Be free!

Pic by Timmu

After some fiddling, it works

Although, it doesn’t look as good as Ross’s due to the missing image. Google Maps doesn’t have one yet..

Few days ago I was setting up a machine which was supposed to have two hard disks running in RAID1 (mirror mode). As I do not have much experience with RAIDx stuff I encountered few problems during the setup
My first approach was to create a kernel with embedded initramfs image which worked until it had to mount the filesystems from RAID device, failing with following error:

The filesystem size (according to the superblock) is
212144483 blocks. The physical size of the device is 212144384 blocks.
Either the superblock or the partition table is likely to be corrupt.

Quite quickly we discovered (as I was installing remotely, relying on Taavi feeding me the error messages) when using ext2/ext3 filesystem one has to fix and resize the filesystems before using them in RAID system. This is because the RAID superblock will be written near the end of the partitions thus reducing the physical size of the filesystem. So here it goes:

mdadm --create /dev/mdx --raid-devices=2 /dev/sdax /dev/sdbx
e2fsck -f /dev/mdx
resize2fs /dev/mdx

Before I even tested it I wanted first to try out another trick - I tried the partition type for all raid components to 0xFD. I then quickly made another kernel image without initramfs and booted it.. Voila.. everything worked even without initramfs

So to sum it up:

1. First set the partition type to 0xFD which stands for “Linux RAID autodetect” for all the partitions taking part in the RAID setup.
2. After assigning partitions to RAID, run a forced filesystem check (forced because otherwise utility refuses to check clean filesystem)
3. Resize the partition because added RAID superblock has shrinked the filesystem area…

“64-bit capable” translates as a mode where a 64-bit application/OS can access 64-bit instructions and registers and is also known as “Long mode“.

On Linux machine just check the contents of /proc/cpuinfo. If processor flags contain lm, then your CPU is 64-bit capable.

Also, a little excerpt from Linux Kernel Sources:

#include/asm/cpufeature_32.h
[snip]
#define X86_FEATURE_LM          (1*32+29) /* Long Mode (x86-64) */
[/snip]

As I needed a bit more recent kernel on one machine due to some exotic hardware, I didn’t want to use regular kernel provided by portage. Instead I opted to track latest Linus’s snapshot using git. Although there are snapshot kernel packages in the portage their usage is a bit cumbersome because every time new release is made and you update it, kernel sources will land into different directory… Managing these will become quite cumbersome…
There was also another gotcha: removing all the kernels provided by portage made it unhappy as it wants to have at least one installed kernel. First I though I can just use the ‘–inject’ option to insert the package by not installing it, but unfortunately this feature has been removed ages ago
Fortunately the feature itself hadn’t been removed as it is possible to use either /etc/portage/package.mask or /etc/portage/profile/package.provided. package.mask isn’t suitable to use because there are some packages I use that depend on kernel package, so I had to use second option. But it took a while to figure out how to ignore all the versions because the package atom has to be provided with version number. So, in order to “inject” a package into system one has to use similar form:
sys-kernel/gentoo-sources-9999