louiscar wrote:alyf80 wrote:
Having said that, the QNAP GPL tarball at
http://sourceforge.net/projects/qosgpl/ contains all the relevant sources, so I was able to build a working recovery environment by compiling and installing QNAP's kernel and LVM tools on a standard system.
would love to have a bootable image of that recovery if possible for the more unix challenged amongst us or perhaps you could do a step by step tut for creating same?
What I cobbled together was more of a horrible hack than a real recovery environment; building something that can be used without a fair level of linux-fu would take a considerable amount of time, which I really don't have right now.
I can outlne the process, but you will probably have to adapt things based on your environment and any problems you might encounter.
Start with a clean linux install (you need persistent storage, so a live distro is probably not the best idea). I cloned a gentoo system I happened to have at hand, but any distribution should do.
You need a working development environment, so make sure you install the relevant packages (C compiler, binutils, glibc and kernel headers,...). I don't have a complete list, you will have to sort out the missing dependencies from any errors you get.
The first step is to install thin-provisioning-tools; these are just needed for a configure check so don't bother with the sources in the QNAP tarball: just installing your distribution's package should be fine.
From the tarball extract src/LVM2.2.02.96, configure it with --with-thin=internal, compile and install. If you get errors during the configuration or complilation, check your dependencies.
Now comes the fun part, i.e. the kernel.
Extract src/linux-3.12.6; for configuration I picked a default from the kernel_cfg folder in the tarball (I used TS870/linux-3.12.6-x86_64-hal.cfg, which is for an x86 NAS with specs reasonably similar to a recent PC) and adjusted it to include drivers for the hardware in my rescue system.
Everything you need (console, input, storage, network, ...) should be compiled in rather than built as a module: this is a rather ancient kernel and the userspace tools from your distribution might not play nice with it (in my case module loading did not work at all).
Compiling the kernel is a bit of a hassle, as QNAP seems to have sprinkled the sources with calls to code in a module of their own (picd) which is disabled in the configuration and cannot be enabled as it fails to compile.
I was not interested in debugging kernel build issues, so as a quick hack I left picd disabled and added
Code: Select all
#define send_message_to_app(...) do {} while(0)
at the end of include/qnap/pic.h, just before the final #endif; this effectively converts the offending calls to no-ops.
Then you need to reboot using the kernel image you just compiled; it might take some trials to get everything right, so be sure to keep the orginal kernel around so you can always go back and make changes.
At this point you should have a working system running a patched kernel and with a patched LVM installed; if all RAID volumes are connected and running, the usual
should not give any errors, and a subsequent
should output a list of all your volumes in "available" state, which you can then mount.
Now, the usual disclaimers apply: this is what I did, and it worked for me. If you try to do the same and it kills your cat (or destroys your data), well, tough luck.
I did not write a detailed HOWTO for a good reason: if what I wrote above looks like gibberish to you, you should definitely not attempt to follow it.
Also, the method above is only intended as an emergency measure to gain read-only access to your volumes so that you can copy data off them. Do not mount the volumes read-write, and do not attempt any provisioning operations on the pools!
Hope this helps,
Andrea