Odroid HC2 NAS with "extras"

[Donovan Ready]

(ignore, notes to Doug)

I've done this for myself, but I created a subforum with very specific permissions. That way we don't have to ignore each other.

Being mods, we can delete these, you know - feel free now that I'm done if you've read this edit yo YOUR post. Heh.

[Doug Coulter]

This really belongs up-thread somewhat, but you can do this anytime. It was one of those things that was too easy for me to remember to put it in, but in fact, it's not easy unless you have some years of linux under your belt...there's a few curveballs here.

The HC2, or for that matter, a Raspberry Pi pressed into the same service, will have an SD card you boot from (or if an XU4, maybe emmc, but same issues), and a big spinner or SSD (if you're rich) as the shared space. The thing with linux is that it likes to write files in normal operation - access logs, you name it...and this ruins flash memory at some point - SSD's are better than USB sticks which are better than SD, but...it's better to avoid that issue.

So, what I do with any SD-based platform (except the latest pi that will just plain not need and SD at all, making this simple again) - is partition the big disk with one big partition - it'll be sda1 in almost all cases, for the share, and another which will be sda2 (if you want to use my examples verbatim) to use for the part of the directory tree that linux is going to write on. This part also holds the MySQL database, the apt logs, you name it. It doesn't have to be big, but since I might want to use big databases or slave to such - I made mine second partition fairly large.

I had some nominal 4 TB drives, so I made the second partition 77 gigabytes (a number I pulled out of my nether regions) and the rest the main share as the first one, both as ext4, using gparted as the tool to do that - before I ever booted the thing up for the first time (because this isn't my first time and this is the easy way if you know what you're going to want). I did the big spinner work on another machine, using an external drive caddy - analagous to the way I also burned the linux distro on the SD card using an SD adapter. While a brave friend who is a very experienced sysadmin sometimes does this on a live system, it's a lot safer to do this on some other machine.

So we have an SD card that will boot and run linux, and this big spinner that isn't really any use - yet.

However we do it, we make two directories on the SD card root tree - one I called /share (which is duh, the share) and another called /spin, as I have no imagination and the thing spins. We will copy the entire contents of the SD card's /var to the sda2 "spin" partition, the one I made 77gb, which is "tiny" in this context, but huge compared to the SD card.

I used sudo cp -rp sdxa/var sdyb/var, with xa and yb being what the SD card and spinner were named on the host system I did this on.
The result was a /var directory on the spinner on its second partition, with all the same stuff, including subdirs and their contents, that was on the SD card, with the same permissions; that's the -rp option to cp.

Now when you hook it all up and boot - linux from the SD card doesn't know about any of this yet - it's still using just the SD card, maybe mounting the spinner partitions on /media, but that's it. While making minimal other changes - because the copy of /var we put on spinner won't get any that would affect it, we need
to tell linux to mount it up as we want on the next boot, so it covers up the SD cards version (which will be ignored and not updated thereafter! This matters depending on how you might do backups, a topic for another post).

Also, we want this linux to have the big spinner partition mounted someplace we can share it easily via Samba or better, NFS.

It turns out, things like MySQL and AppArmor don't like having the database stuff moved once set up, so the way I'm doing this uses an extra layer of indirection via a "bind" type mount so they basically can't tell we moved the earth under their feet - this will work even after full setup on the SD card, in other words.

We accomplish this via an edit to /etc/fstab, which you have to be root to do - something like sudo gedit /etc/fstab if you've put in gedit, or whatever the normal simple text editor in your distro if not (you could use nano...).

/etc/fstab winds up looking like this in my setup:

Code: Select all

UUID=e139ce78-9841-40fe-8823-96a304a09859   /   ext4   errors=remount-ro,noatime,discard   0   1
UUID=96C3-9298                /boot    vfat   noatime,discard          0    2
/dev/sda1   /share   ext4   defaults   0   0
/dev/sda2   /spin   ext4   defaults   0   0
/spin/var   /var   none   defaults,bind   0   0


The big drive gets an sda name in /dev, and the SD is the default by-uuid syntax I didn't bother to change (Even though it seemed like a good idea at the time to some intern modifying linux, it's a disaster if you need to backup/restore with different media that won't have the same UUID...and confuse you as to why why nothing works now).

For this to work, you have to create directories /share and /spin on the SD card first. I made them permissive and owned by the odroid user, but "anyone can do anything" to them - security freaks might do this a little differently, but this at least works easily.

So, the big share gets mounted over.../share, which is kinda easy to remember, and the other partition we're going to use for /var - all the databases, logs and so on - gets mounted over /spin and then aliased to /var with a bind mount. This turns out to be the way you keep various things from complaining they moved if it wasn't already this way when you installed them.

And in my case, now I have 77 gigs in /var for databases and logs, and I don't write on the SD card all the time anymore - only when there are things like software updates.

There is probably a way to build the SD card in the first place so that the whole non /boot linux is on the spinner somewhere. My couple of tries didn't work, so...this works. I'm all ears if someone got it to work a better way.