It has been a good year…
Monday, December 31st, 2007![]()
Pic by Timmu
![]()
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:
“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