7

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.

Tobias Kienzler
  • 9,374

1 Answers1

9

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 -nd https://raw.githubusercontent.com/tokland/arch-bootstrap/master/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.

Ned64
  • 8,726
Bananguin
  • 7,984
  • 3
    p.s.: yes,this does read a lot like the gentoo installation howto. – Bananguin Jan 07 '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 08 '13 at 05: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 08 '13 at 06:01
  • 1
    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 08 '13 at 08: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 08 '13 at 10:40
  • Yes it will and those sources should be available to you so you can build additional modules if you need them. Keeping the native kernel has the best chances of ending up with a fully working device and never bricking your device :-) – Bananguin Jan 08 '13 at 22:53
  • I did spend some more time on this now, and unfortunately things aren't as easy as I hoped: arch uses systemd with its very own logging system and a "Cannot be run in a chroot() environment", so I currently even fail to obtain a /var/log/messages to figure out why sshd silently fails... – Tobias Kienzler Oct 28 '13 at 15:14
  • Oh thou brave new world ... You could try configuring SSH to use its own logging instead of syslog or you could use a more sensible Linux distro or you go right ahead with what i wrote in the second last paragraph. Oh and I think systemd is not started as /sbin/init, so you need to adopt the chroot statement to load systemd correctly. – Bananguin Oct 28 '13 at 21:51
  • Indeed, and it get's even "better": systemd is started via /bin/init --system, but refuses to do so in a chroot environment (and a user instance requires the system being booted with systemd...). Well, I figured out sshd simply uses the mother-system's syslog, so basically I could just mount -o bind /var/log var/log (or even just bind messages, though IIRC binding files instead of directories is error-prone). Anyway, sounds like I should give gentoo a shot instead... Maybe emerge can be native-fied somehow... – Tobias Kienzler Oct 29 '13 at 08:24
  • I'm fairly certain, that systemd can/will work with initrds, and therefore with some form of chroot. Check out pivot_root and then try something along the lines of cd /newroot; pivot_root . oldroot; exec bin/init --system >dev/console 2>dev/console <dev/console ;. It would seem systemd makes it difficult to "safely replace" Linuxes ... – Bananguin Oct 29 '13 at 08:37
  • pivot_root . oldroot yields Invalid argument (after mkdir oldroot), which seems to be connected to rootfs being mounted on /... – Tobias Kienzler Oct 29 '13 at 09:02
  • I fear using ArchLinux is overcomplicating things a lot - I'll try either Gentoo or maybe (Rootless) GoboLinux - the latter actually sounds predestined for such a purpose – Tobias Kienzler Oct 29 '13 at 09:14