I have a number of DroboFS drives, and these are no longer supported by Drobo.

As they still have quite a bit of life in them, and it's getting harder and harder to find information on Drobo's site front-and-center, I thought I'd log some useful information for later.

At the time of this writing (2017-01-09), the Drobo Dashboard is up to version 3.1.5, and it works on El Capitan, Sierra, and High Sierra.

If it's not discovering drives, do this; though I've never had to.

According to Drobo, the largest size approved drive is 4TB for the DroboFS. See this resource, and look at the Legacy Products section. And, it only handles SATA.

With newer models, it seems one can put 10-12TB drives in them.

Choosing a drive can be tricky, but it seems that the Enterprise SATA is all purpose, as well as it works in all models except the Drobo Mini, making a viable upgrade path possible without ditching the drives.

The drive models list a number of contenders, but suggests that the Seagate Constellation and the Western Digital Black series are the winners.

Upon reasearching on Amazon, it seems there's actually a WD Black and a WD Gold to pick from. The WD Gold has a larger cache, has faster internal data rates, and seems to use less power — making it the choice of data centers and NAS systems, opposed to the WD Black, which seems to be more for desktops.

I really wish drive manufactures would merely label in plain English what the drive did and how it was optimized, rather than hiding behind a color code.

Attempting to format a new Seagate Expansion 4TB USB3.0 drive under Apple's macOS (Sierra or High Sierra) fails when the new drive is pre-formatted as NTFS for your PC.

Here is what the drive looks like when you look at it from the command line:

$ diskutil list

1
2
3
4
5

/dev/disk5 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *4.0 TB     disk5
   1:         Microsoft Reserved                         134.2 MB   disk5s1
   2:       Microsoft Basic Data Seagate Expansion Drive 4.0 TB     disk5s2

IMPORTANT NOTE: In these examples we're showing the disk at /dev/disk5, your drive may vary -- and this is not something you want to get wrong.

If you look at the GUID Partition Table (GPT), it's full of stuff.

$ sudo gpt show -l /dev/disk5

1
2
3
4
5
6
7
8
9
10

     start        size  index  contents
         0           1         PMBR
         1           1         Pri GPT header
         2          32         Pri GPT table
        34      262144      1  GPT part - "Microsoft reserved partition"
    262178        2014         
    264192  7813771264      2  GPT part - "Basic data partition"
7814035456        1678         
7814037134          32         Sec GPT table
7814037166           1         Sec GPT header

$ sudo gpt destroy /dev/disk5 # YOUR DRIVE MAY BE DIFFERENT

If you look at the GPT immediately after destroying it, it will look like this:

$ sudo gpt show -l /dev/disk5

1
2

start        size  index  contents
    0  7814037167

At this point you can use Disk Utility or any other tool of your choosing to format it.

Finally, if the disk just won't eject, do this:

$ diskutil eject /dev/disk5

In the past, I've run php and allowed it within user subdirectories, thus content in public_html can use .php files.

All was going well until I upgraded the system, then all kinds of things broke relating to home pages.

Turns out there's a new policy with PHP that disables PHP by default in user home directories. This is actually a really good idea for security reasons.

However, if a system doesn't have untrusted users, it can be okay to re-enable.

This requires going into the /etc/apache2/mods-available/php*.conf file that contains the text public_html, and commenting out the IfModule statements.

1
2
3
4
5

#<IfModule mod_userdir.c>
#    <Directory /home/*/public_html>
#        php_admin_flag engine Off
#    </Directory>
#</IfModule>

Do NOT set the content within them to On, as it may be so tempting to do; for doing so will prevent .htaccess from being able to override the setting.

This one tripped me up until I saw the obvious.

Hexo posts have a tags attribute in their "frontmatter" (the meta-data at the top of a post).

Initally, I incorrectly tried putting a comma separated word list in that field.

1

tags: hexo, markdown, solved

This led to Hexo generating a single tag called "hexo, markdown, solved", which wasn't what I wanted.

Scouring the documentation didn't seem to flaunt any obvious answers, and even the primary example pages that Google returns don't use tags that much.

But, I did stumble across one, and the light went on. Dummy, it's YAML. That means the "frontmatter" is an array.

1
2
3
4

tags:
  - hexo
  - markdown
  - solved

I recently started playing with Hexo and nearly gave up completely due to the markdown system provided with it.

I found strange behaviors, such as multiple adjacent lines were being treated a linebreaks instead of a paragraph, as markdown normally does.

There was a workaround, which involved changing a setting in the _config.yaml file, but that didn't fix things completely.

If a line started with a link, then there were situtations where it wouldn't wrap it in a paragraph and weird things happened. If a link came at the end of the line, it'd usually work fine, but if there was a period immediately after the tag, then it'd absorb the next paragraph.

I found with all kinds of permutations just trying to build a simple example.

Then, I read about hexo-renderer-markdown-it which was described as "Markdown down right."

I uninstalled the default version:

1

npm un hexo-renderer-marked --save

Installed the new one:

1

npm i hexo-renderer-markdown-it --save

And without changing any of my valid markdown, the page rendered perfectly.

This plugin should be the default version that ships with hexo.

While exploring hexo, I ran into a problem installing it.

yarn was aborting the install claiming that there was no <code>--production</code> switch.

A quick check of yarn's version number showed that I was somehow way out of date.

According to yarn's installation directions this was merely a matter of performing a self-update, which yarn also claimed it wasn't able to do, or to install an updated pubkey.gpg and install/update with apt.

These solutions didn't work either.

The problem was that another package, cmdtest, had it's own obsolete copy of yarn.

The solution was simply to uninstall it, then install yarn with apt:

1
2
3
4
5

sudo apt remove cmdtest

curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add -
echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list
sudo apt-get update && sudo apt-get install yarn