unRAID OS Version: 6.0-beta6 (has always existed)

 

Description: In some cases, a drive will fail to mount. unRAID makes the assumption that a non-mounting disk means that it is unformatted, and will identify the disk as unformatted to the user, and enable the "format" button. If pressed, the format button will reformat the disk.

 

How to reproduce: Steps to reproduce are unclear. Although code has been added to unRAID to try and prevent this situation, it does continue to occur at times.

 

Other information:

 

A possible solution is that the "unformatted" prompt be changed to "unable to mount or unformatted" or similar.  A disk specific format button could be present, and clicking it would display an "are you sure" message along with partition information for any Linux or non-Linux partitions on the disk. The "are you sure" could possibly be skipped if unRAID determines the disk has no possible data partitions. The prompt could also give the user the option to select the target file system.

 

(UPDATE: Just noticed that a 6.0 feature addresses this bug. Will leave here until it is fixed, though, so that users reading about bugs will see it. The proposed enhancement seems to adequately address this issue.)

Very belatedly, I'm here to elaborate on this issue.  There are actually 3 separate issues with 3 different fixes, but they are very closely related, and I don't know if Tom wants them separated or not.

 

Issue #1 (critical):  basically stated by Brian above, as the general case of a drive failing to mount for ANY reason, and therefore being marked as 'Unformatted'.  Further discussion is in this thread.  Reasons for mount failures could be missing mount points, hardware issue with drive, modified start sector on drive, corrupted MBR or partition table, corrupted Reiser file system (especially corrupted superblock), bad or marginal sector in MBR or Reiser file system, etc.

 

Issue #2 (important):  missing /mnt, causing all mount points to be missing, and all subsequent mounts to fail, both disks and shares (/mnt/user and /mnt/user0).  This post details how a package upgrade removed /mnt.  The Deluge package author may have thought that the Cache drive was always mounted, so placed files/folders on it (eg. /mnt/cache/.apps/deluge/), then fixed/upgraded the package and relocated those elsewhere.  The user had the original Deluge package installed, then added the upgraded package.  On booting, the first package was installed, then the upgradepkg tool was called to install the newer package.  It first backs out the previous installation, then installs the upgrade.  That sounds fine, until you examine the syslog and determine that upgradepkg is too aggressive in its cleanup of the previous.  It removes the unwanted files and folders, then checks to see if the containing folder is empty, and if so, removes it too.  It then checks the parent and each ancestor, and removes them too if empty, which in this case results in the loss of /mnt.  Here is a sample of its work -

Apr 18 16:18:10 Tower logger:  --> Deleting empty directory /usr/lib/python2.6/site-packages/deluge/

Apr 18 16:18:10 Tower logger:  --> Deleting empty directory /usr/lib/python2.6/site-packages/deluge-1.3.5-py2.6.egg-info/

Apr 18 16:18:10 Tower logger:  --> Deleting empty directory /usr/doc/deluge-1.3.5/

Apr 18 16:18:10 Tower logger:  --> Deleting empty directory /mnt/cache/.apps/deluge/

Apr 18 16:18:10 Tower logger:  --> Deleting empty directory /mnt/cache/.apps/

Apr 18 16:18:10 Tower logger:  --> Deleting empty directory /mnt/cache/

Apr 18 16:18:10 Tower logger:  --> Deleting empty directory /mnt/

Apr 18 16:18:10 Tower logger:  --> Deleting empty directory /lib/systemd/system/

Apr 18 16:18:10 Tower logger:  --> Deleting empty directory /lib/systemd/

You may say this is just a problem specific to Deluge, but there's nothing unique about it.  Any plugin or package author can place files and folders in /mnt OR ANY SUBFOLDER of it, and later change their mind about the location.  A side note, this installation also had placed files in a subfolder of /etc, then in the later package removed them, and the same pruning occurred.  The only thing that saved /etc from suffering the same fate as /mnt was the fact there were other files in /etc, so it's never empty.

 

It seems easy to fix, always check return code on all mkdir's (so we know mount points do exist), and/or always check and recreate /mnt, or place a _DO_NOT_REMOVE_ file or folder in /mnt so it's never empty, or just 'mkdir /mnt' at array start before any mounting.  Fixing Issue #2 does not fix Issue #1, as it is only a specific case (non-existent mount point) leading to drives being marked 'Unformatted'.  Issue #1 is the general case, that includes all other causes too.

Edit:  Tom has changed 'mkdir' usage to always be 'mkdir -p' instead, thereby fixing this issue.  Issue #2 should be considered fixed.

 

Issue #3 (trivial):  wrong event and syslog statement that the disks were mounted.

Apr 18 16:19:02 Tower emhttp: Mounting disks...

Apr 18 16:19:02 Tower emhttp: shcmd (19): mkdir /mnt/disk1

Apr 18 16:19:02 Tower emhttp: _shcmd: shcmd (19): exit status: 1

Apr 18 16:19:02 Tower emhttp: shcmd (20): set -o pipefail ; mount -t reiserfs -o user_xattr,acl,noatime,nodiratime /dev/md1 /mnt/disk1 |& logger

Apr 18 16:19:02 Tower logger: mount: mount point /mnt/disk1 does not exist

Apr 18 16:19:02 Tower emhttp: _shcmd: shcmd (20): exit status: 32

Apr 18 16:19:02 Tower emhttp: disk1 mount error: 32

Apr 18 16:19:02 Tower emhttp: shcmd (21): rmdir /mnt/disk1

Apr 18 16:19:02 Tower emhttp: _shcmd: shcmd (21): exit status: 1

Apr 18 16:19:02 Tower emhttp: shcmd (22): mkdir /mnt/disk2

Apr 18 16:19:02 Tower emhttp: _shcmd: shcmd (22): exit status: 1

...

Apr 18 16:19:03 Tower emhttp: shcmd (28): mkdir /mnt/user

Apr 18 16:19:03 Tower emhttp: _shcmd: shcmd (28): exit status: 1

Apr 18 16:19:03 Tower emhttp: shcmd (29): /usr/local/sbin/shfs /mnt/user -disks 16777214 -o noatime,big_writes,allow_other -o remember=0  |& logger

Apr 18 16:19:03 Tower shfs/user: fuse_main exit: 1

Apr 18 16:19:03 Tower logger: fuse: bad mount point `/mnt/user': No such file or directory

Apr 18 16:19:03 Tower emhttp: shcmd (30): crontab -c /etc/cron.d -d &> /dev/null

Apr 18 16:19:03 Tower emhttp: shcmd (31): /usr/local/sbin/emhttp_event disks_mounted

Apr 18 16:19:03 Tower emhttp_event: disks_mounted            ummm...  really?!?!

It posts the event/message that disks were mounted, but actually not one disk or share was mounted.  Technically, if Issue #2 were fully resolved and /mnt always guaranteed to be present, then you can justifiably say that Issue #3 doesn't need to be fixed, since it should never happen again.  The purist side of me thinks it should still be listed here though, and adding a simple check for successful mounts would be better (just in case).

Edit:  Tom has changed 'mkdir' usage to always be 'mkdir -p' instead, thereby making Issue #3 a non-issue.  Issue #3 could be considered fixed.

 

 

(UPDATE: Just noticed that a 6.0 feature addresses this bug. Will leave here until it is fixed, though, so that users reading about bugs will see it. The proposed enhancement seems to adequately address this issue.)

I've hunted and hunted, and can't find that feature list for v6.0 any more.  Anyone know where it is?  As I recall, that proposed enhancement did seem to address the most important problem, but I'd like to read it again.

Will look into this more with the team next week.  Thank you for your diligence on this one.  Really appreciate the thorough information.