Background
Unfortunately, I need to use very very old ARM OABI Linux environment to salvage data from XFS used by broken NAS. XFS is designed to be compatible between platforms, but for some reasons, it was incompatible only with ARM OABI environment. As you may know, OABI used a curious middle endian and struct layout. It's a very old story around Linux kernel 2.6.1x, or so. But, it affects my HDL-GT1.0 actually. Linux box can not show any file entries even if the disk can be mounted, and xfs_repair has no power to solve the problem.FYI, the first KURO BOX that was sold in Japan also used ARM OABI, but later versions used ARM EABI, AFAIK.
Basic Strategy
Install debian 4.0 (etch) onto QEMU. Etch was already out of maintenance, but this is the best choice since HDL-GT1.0 looks using the Linux that was based on it. Also there is enough information to install it onto QEMU, e.g. this site (*1). Debian 5.0 (lenny) provided two versions, OABI and EABI for ARM, but the next 6.0 (squeeze) had only EABI. Anyway these all were out of maintenance. There were no benefit to choose others.How to Install
I used Ubuntu 14.04.1 with QEMU that is installed by "apt-get install qemu". Basically, I just followed the way described at (*1). But some tricks were needed since the information was already out of date, and meanwhile, etch was removed from the official place.Boot files
Two mandatory files distributed at (*1) were also removed. I found them from web.archive.org. I can download them, but it seems that the server sometimes return 404 against them. Anyway, if you were lucky enough, you will be able to get them.Also, etch's initrd.gz was fetched from archive.debian.org/. The first initrd.img-2.6.18-6-versatile was used after installation, and the second initrd.gz was used on installation.
Use a manually chosen mirror site
Since etch was removed from the original place, I should specify an archive site manually. Mirror site name was archive.debian.org, and the path was default, /debian/. Here are some screen shots.
Other Notices
In the page (*1), that picture for the question "Continue without installing a kernel?" looks like the answer should be "<No>". But "<Yes>" is the right answer here.Also, there is a critical issue to me. The provided kernel did not enable xfs support. So, even I install xfsprogs package and so on, xfs can not be mounted. According to the article, I can build kernel by myself. So, I'll try it next.
FYI, xfs_repair seems not working fine, but anyway it does not crash. Here, QEMU is launched with additional flags "-hdb HDL-GT-md13.img" here.
# apt-get install xfsdump # it will install dependent xfs related packages including xfsprogs
# xfs_repair /dev/sdb # it works somehow?
Kernel build
Let's build a kernel to support XFS. The system contains minimum set of packages. So, we need following packages to build the kernel at least. There are two choices, 2.6.18 and 2.6.24, but choose 2.6.18 that the original installation bases on.# apt-get install make gcc linux-source-2.6.18 kernel-package build-essential libncurses5-dev initrd-toolsThen, prepare source files.
# cd /usr/srcKernel 2.6.18 has a config template file for versatile. Here, we use it as a baseline, then enable XFS support in addition.
# tar jxf linux-source-2.6.18.tar.bz2
# cd linux-source-2.6.18
# make versatile_defconfigIn the menu, enable a following items. I'm not sure if this is the exactly necessary and sufficient condition. But at least, it is sufficient:)
# make menuconfig
- Bus support ---> PCI support [built-in]
- Device drivers ---> SCSI device support ---> SCSI device support [module]
- Device drivers ---> SCSI device support ---> SCSI disk support [module]
- Device drivers ---> SCSI device support ---> SCSI tape support [module]
- Device drivers ---> SCSI device support ---> SCSI generic support [module]
- Device drivers ---> SCSI device support ---> SCSI low-level drivers ---> SYM53C8XX Version 2 SCSI support [module]
- File systems ---> Ext3 journalling file system support [module]
- File systems ---> XFS filesystem support [module]
- File systems ---> XFS Quota support [built-in]
- File systems ---> XFS Security Level support [built-in]
- File systems ---> XFS POSIX ACL support [built-in]
- File systems ---> XFS Realtime subvolume support [built-in]
- File systems ---> Filesystems in Userspace support [module]
- File systems ---> Pseudo filesystems ---> Virtual memory file system support (former shm fs) [built-in]
- File systems ---> Pseudo filesystems ---> Tmpfs POSIX Access Control Lists [built-in]
- File systems ---> Pseudo filesystems ---> Userspace-driven configuration filesystem (EXPERIMENTAL) [module]
- File systems ---> Native language support --> Japanese charsets (Shift-JIS, EUC-JP) [module]
- File systems ---> Native language support ---> NLS UTF-8 [module]
# make dep
# make modules && make zImage && make modules_install && make install
# mkinitrd -o /boot/initrd-2.6.18.img 2.6.18
Now dependent modules should be installed into the internal file system, and kernel and initrd images that can be specified on launching QEMU are created. The kernel image should be placed at arch/arm/boot/zImage, and initrd image is /boot/initrd-2.6.18.img as you specified at the last command. I copied them to the host machine via scp. After shutting down the emulated ARM system, launch the system again with these new images, as
# qemu-system-arm -M versatilepb -kernel zImage -initrd initrd-2.6.18.img -hda hda.img -hdb want-to-read-fs-in-xfs.img -append "root=/dev/sda1"The resolution of the boot console is finer than the original, and linux logo is not used. But anyway, it boots. Once you login the system, it will support XFS correctly, and it is exactly the XFS that is not compatible with current XFS. In my case, I launched QEMU with "-hdb HDL-GT-md13.img", then it can mount the image correctly.
# mount /dev/sdb /mnt
# ls -l /mnt
drwxr-xr-x 6 root root 88 May 16 2012 share
drwxr-xr-x 6 root root 88 May 16 2012 spool
Yep!
