Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm intending to replace a NAS's Custom Linux with Arch Linux (details at the bottom), of course wishing to preserve all user data and (due to the SSH-only headless access) attempting to be fool-proof since a mistake may require firmware reinstallation (or even brick the device). So instead of running the installation (downloading the appropriate Arch Linux ARM release and probably using the chroot into LiveCD approach) without appropriate preparations, what must I keep in mind? (Please feel free to answer without restriction to Arch Linux) More precisely:

  • Do I somehow have to bother with figuring out how a specific device's boot process works (e.g. which parts of the bootloader reside on the flash memory and which ones are on the harddisk) or can I rely on the distribution's installer to handle this correctly?
  • How can I determine whether some (possibly proprietary) drivers are used and how can I migrate them into the new setup?
  • Is the RAID configuration safe from accidental deletion?
  • Is there a way to fake the booting process so I can check for correct installation while the original system remains accessible by simply rebooting? E.g. using chroot and kexec somehow?
  • What else should I be aware of?

The specific case is that I want to replace the custom Linux from a Buffalo LinkStation Pro Duo (armv5tel architecture, the nas-central description is a bit more helpful here and also provides instructions on how to gain SSH root access) with Arch Linux ARM. But a more general answer may be more helpful for others as well.

share|improve this question
up vote 9 down vote accepted

with the required skill and especially knowledge about the installed linux it is not worth while anymore to replace it. and whatever you do, you probably never want to replace the already installed kernel. however, you can have your arch linux relatively easy and fool proof!

the concept: you install arch linux into some directory on your NAS and chroot (man chroot) into it. that way you don't need to replace the nas linux. you install and configure your arch linux and replace the native linux's services by arch linux services step by step. the more complete and powerful your arch linux installation gets you auotomate the chrooting procedure, turn off the services provided by the native linux one by one while automating the starting of services within the chrooted arch linux. when you're done the boot procedure of your NAS works like this: load the kernel and mount the hdds, chroot into arch linux, exec /sbin/init in your chrooted environment.

you need to work out the precise doibg yourself, b/c i know neither arch linux nor your NAS and its OS. you need to create the target directory into which you want to install arch linux; it needs to be on a device with sufificient available writable space (mkdir /suitable/path/archlinux), then you need to bootstrap your arch linux

cd /suitable/path/archlinux
wget http://tokland.googlecode.com/svn/trunk/archlinux/arch-bootstrap.sh
bash arch-bootstrap.sh yournassarchitecture

Now you have a basic arch linux in that path. You can chroot into it along the lines of

cp /etc/resolv.conf etc/resolv.conf
cp -a /lib/modules/$(uname -r) lib/modules
mount -t proc archproc proc
mount -t sysfs archsys sys
mount -o bind /dev dev
mount -t devpts archdevpts dev/pts
chroot . bin/bash

Then you should source /etc/profile. Now your currnt shell is in your arch linux and you can use it as if you had replaced your native linux ... which you have for the scope of your current process. Obviously you want to install stuff and configure your arch linux. When you use your current shell to execute /etc/init.d/ssh start you are actually starting the ssh daemon of your arch linux installation.

When you're done and you really want to entirely replace your native linux (services) with arch linux, your NAS's native linux doesn't start any services anymore but executes the chroot procedure above with the difference that the last line is exec chroot . sbin/init.

This is not as complete as a real replacement, but as fool proof as it gets. and as stated initially, with the knowledge and skill required for this, IMHO (!), a complete replacement is not necessary and worth while.

share|improve this answer
p.s.: yes,this does read a lot like the gentoo installation howto. – Bananguin Jan 7 '13 at 22:28
The main reason for replacing that Linux is that even though there is a way to install the ipkg package manager, the compiled packages are mostly outdated. While for simple things a manual compilation was no trouble, getting something with more complex dependencies compiled without something like yaourt or emerge is a real mess. And at some point I may realize that a Kernel module is missing... – Tobias Kienzler Jan 8 '13 at 5:48
Thanks for your suggestions, that's my approach so far, though ultimately I think replacement will be adequate... Maybe it is helpful that used GPL packages and their sources are made available by Buffalo.jp, though I don't expect you to dig through that :-7 I guess you refer to the Install Gentoo from an existing Linux document? I'll check that and the ARM installation guide for some pointers – Tobias Kienzler Jan 8 '13 at 6:01
if all the native linux does is the chroot into your arch linux and run init you will have replaced the native linux without the need to delete remove or overwrite anything. hence without the risk of breaking or bricking anything. chrooting into running init is exactly what initrds do. the best thing to do is have the native linux start an ssh daemon on some odd port before chrooting so that you can ssh into the native linux for debuging purposes if you broke your arch installation. and of course you can load additional kernel modules from inside a chroot. – Bananguin Jan 8 '13 at 8:31
But this will still run the native kernel, correct? Running an "external" sshd alongside an "internal" one sounds like a good idea though. – Tobias Kienzler Jan 8 '13 at 10:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.