Jump to content
limetech

unRAID Server release 4.5-beta6 available

315 posts in this topic Last Reply

Recommended Posts

Direct download | Torrent (thanks to WeeboTech)

 

 

Bug fixes.

 

unRAID Server 4.5-beta6 Release Notes
=====================================

Changes from 4.5-beta5 to 4.5-beta6
-----------------------------------

Bug fixes:
- Fix ntp startup problem.
- Fix bogus temperature values being displayed when disks are spun down (bug introduced in -beta5).

Other changes:
- Permit spaces in Active Directory account login username.  Any valid AD character should now be possible EXCEPT for the percent '%' symbol.  This is because the '%' symbol is used by linux 'net' command as a separator between username and password, as in:
net ads join -U username%password


Changes from 4.5-beta4 to 4.5-beta5
-----------------------------------

New features:
- Added new share allocation method called "Fill-up".
- Added "Min free space" setting for each share.
- Special handling of split level explictly set to "0".
- The 'mover' will now delete empty directories on the cache disk.
- After looking in the 'config' directory on the Flash for the license key file (for backward compatibility), if not found, unRAID Server OS will look in the root of the Flash.  This allows easier backup/restore of the 'config' directory contents.

Bug fixes:
- Fix wrong 'memtest' in zip file - oops.
- Fix powerdown script.
- Fixed problem where drives would sometimes spin down immediately following spin up.

Other changes:
- Don't store AD adminstrator password, and don't display personal information in the system log.
- Can now use any printable characters in password strings.
- When disabling NCQ don't try to set queue_depth to 1 if it's already set to 0.
- Upgrade ntp from version to 4.2.4p0 to 4.2.4p6.  Also save/restore ntp drift file to/from Flash.
- Upgrade linux kernel to 2.6.29.1
- Support Marvell SAS driver.


Changes from 4.5-beta3 to 4.5-beta4
-----------------------------------

New features:
- Increased maximum number of array devices from 16 to 20 (Pro only).
- Pressing Power button gracefully shuts down the server.
- Disable NCQ on all disk devices that support NCQ.  This typically results in much better write throughput.  A setting called "Force NCQ disabled [yes/no]" is also available in the Disk section of the Settings page of the System Management Utility to override this new behavior.  That is, if this setting is 'yes', then we force NCQ off; if setting is 'no', we leave NCQ queue_depth as-is, ie, whatever linux driver sets it to.

Bug fixes:
- Fixed syslog rotation problem - syslog was rotated, but then syslogd was not restarted.

Other changes:
- Support SAS (Serially-Attached SCSI).
- Support Initio 162x SATA chipset.
- Support the motherboard speaker (beeping).
- Added 'lm_sensors' package.
- Upgrade Samba to version 3.3.3.
- Upgrade memtest to version 2.11 in release zip file.


Changes from 4.5-beta2 to 4.5-beta3
-----------------------------------

Known issues:
- The 'reiserfs' file system is built with kernel-option to enable extended attribute support.  This is necessary for Active Directory.  Even if file system is not mounted with extended attributes, reiserfs still seems to create a hidden file called '.reiserfs_priv' in the volume root. This file is harmless and does not appear in any share.

Bug fixes:
- Fixed problem where all Flash files appeared to have Hidden/System/Archive all set.
- Fixed upgrade problem where 'simple security' was not being initialized properly.
- After formatting a new disk, the 'File system type' was not being updated.
- If cache disk present, should allow 'use cache disk' option in creating new share.
- Fixed problem with mover not moving.

Other changes:
- Changed name of samba include file introduced in -beta2 from 'boot/config/smb.extra' to 'boot/config/smb-extra.conf'.
- Upgrade Samba to (patched) version 3.3.2.  The patch is a bug fix that prevented windows client from removing Read-only attribute (previous versions of samba 3.3.x fail with 'Access denied').
- If security model is not Active Directory don't mount the data disks with acl & extended attributes enabled.
- Prevent recording (ie, writing) 'last access time' when directories and files are read on the Flash.
- Added 'lsof' command.
- Include 'Hardware Monitoring' in the linux kernel build along with this device support:
  AMD Athlon64/FX or Opteron temperature sensor
  Intel Core (2) Duo/Solo temperature sensor
  ITE IT87xx and compatibles
  Winbond W83627HF, W83627THF, W83637HF, W83687THF, W83697HF
  Winbond W83627EHF/DHG


Changes from 4.4.2 to 4.5-beta2
-------------------------------

New features:
- Support Active Directory Service (ADS).  This lets an unRAID server join an Active Directory (AD) domain.
- System Management Utility will now use a CSS style sheet file on the Flash (config/style.css) if present.
- May now read syslog directly via browser by referencing 'http://tower/log/syslog' (substitute 'tower' with your server name).  Actually any 'file' in the /var/log directory can be read via 'http://tower/log/file'.
- May now read arbitrary files on disk and user shares via http protocol by referencing URL 'http://tower/share/<diskN>/...' or 'http://tower/share/user/<sharename>/...' (substitute 'tower' with your server name).
- Samba configuration now 'includes' the file on the Flash 'config/smb.extra' if present.  This is included at the end of the 'global' section just before the share definitions.  This may be used to customize the Samba configuration.
- Added control to enable/disable 'mover' logging.

Bug fixes:
- With user mode security enabled, would not accept 'root' share login until password was set at least once.
- Fixed problem in 'mover' script where mover would attempt to move objects in a top-level directory staring with a '.' character.  These would all fail and cause excessive syslog messages.
- Fixed bug in 'logrotate' which would prevent syslog from rotating.

Other changes:
- Part of adding AD support: Removed "User security [enabled/disabled]" control from Shares page, and added "Share security [simple/User Level/Active Directory]" control to Settings page:
  unRAID 'Basic' (free version) supports only 'Simple' share security model;
  unRAID 'Plus' supports 'Simple' and 'User Level' share security models only;
  unRAID 'Pro' supports all share security models ('Simple', 'User Level', and 'Active Directory').
- Removed System Management Utility control for setting SMB ports; this can be done via 'config/smb.extra' if desired.
- Change spin-down logic to account for external programs spinning drives up/down.
- Per user request, added '/usr/lib/libstdc++.so.6.0.9'
- Upgraded to linux kernel 2.6.28.4.
- Upgraded to samba 3.3.0.


Upgrade Instructions (Please Read Carefully)
============================================

If you are currently running unRAID Server 4.2-beta1 or higher (including 4.2.x 'final'), please copy the following files from the new release to the root of your Flash device:
    bzimage
    bzroot

If you are currently running unRAID server 4.0 or 4.1, please copy the following files from the new release to the root of your Flash device:
    bzimage
    bzroot
    syslinux.cfg
    menu.c32
    memtest

This can be done either by plugging the Flash into your PC or, by copying the files to the 'flash' share on your running server.  The server must then be rebooted.

If you are currently running unRAID Server 3.0-beta1 or higher, please follow these steps to upgrade:

1. Referring to the System Management Utility 'Main' page, make a note of each disks's model/serial number; you will need this information later.

2. Shut down your server, remove the Flash and plug it into your PC.

3. Right-click your Flash device listed under My Computer and select Properties.  Make sure the volume label is set to "UNRAID" (without the quotes) and click OK.  You do NOT need to format the Flash.

4. Copy the files from the new release to the root of your Flash device.

5. Right-click your Flash device listed under My Computer and select Eject.  Remove the Flash, install in your server and power-up.

6. After your server has booted up, the System Management Utility 'Main' page will probably show no devices; this is OK, navigate to the 'Devices' page. Using the model/serial number information gathered in step 1, assign each of your hard drives to the correct disk slot.

7. Go back to the 'Main' page and your devices should appear correctly.  You may now Start the array.


If you are installing this release to a new Flash, please refer to instructions on our website at:

http://www.lime-technology.com/wordpress/?page_id=19

Share this post


Link to post

Here is the linuxtracker torrent

 

Comes up 'bad ID'

Share this post


Link to post

It looks like the 2.6.29.1 Linux kernel still cannot do HDIO_GET_IDENTITY on a SATA drive on my SuperMicro LSISAS1068E SAS controller.

 

Not an unraid problem, but to my simple understanding this might not bode well for using SuperMicro SAS controllers with unraid.

 

parity: pci-0000:00:12.0-scsi-1:0:0:0 (sdd) ata-WDC_WD10EACS-00ZJB0_WD-WCASJ1908386

disk1: pci-0000:02:00.0-sas-0x5003048000610e80:1:0-0x1221000004000000:4 (sdb) scsi-SATA_WDC_WD10EACS-00_WD-WCASJ0766868

disk2: pci-0000:03:00.0-scsi-1:0:0:0 (sdc) ata-WDC_WD10EACS-00D6B0_WD-WCAU40627966

 

I can add the device on the "Devices" page, but when you go back to "Main":

 

parity: pci-0000:00:12.0-scsi-1:0:0:0 (sdd) ata-WDC_WD10EACS-00ZJB0_WD-WCASJ1908386

disk1: not installed

disk2: pci-0000:03:00.0-scsi-1:0:0:0 (sdc) ata-WDC_WD10EACS-00D6B0_WD-WCAU40627966

 

# uname -a

Linux Tower5 2.6.29.1-unRAID #2 SMP Thu Apr 23 14:17:18 MDT 2009 i686 AMD Athlon X2 Dual Core Processor BE-2400 AuthenticAMD GNU/Linux

 

# dmesg

Fusion MPT base driver 3.04.07

Copyright © 1999-2008 LSI Corporation

Fusion MPT SAS Host driver 3.04.07

mptsas 0000:02:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18

mptbase: ioc0: Initiating bringup

ioc0: LSISAS1068E B3: Capabilities={Initiator}

mptsas 0000:02:00.0: setting latency timer to 64

scsi1 : ioc0: LSISAS1068E B3, FwRev=011a0000h, Ports=1, MaxQ=266, IRQ=18

scsi 1:0:0:0: Direct-Access    ATA      WDC WD10EACS-00Z 1B01 PQ: 0 ANSI: 5

sd 1:0:0:0: [sdb] 1953525168 512-byte hardware sectors: (1.00 TB/931 GiB)

sd 1:0:0:0: [sdb] Write Protect is off

sd 1:0:0:0: [sdb] Mode Sense: 73 00 00 08

sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

sd 1:0:0:0: [sdb] 1953525168 512-byte hardware sectors: (1.00 TB/931 GiB)

sd 1:0:0:0: [sdb] Write Protect is off

sd 1:0:0:0: [sdb] Mode Sense: 73 00 00 08

sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

sdb: sdb1

sd 1:0:0:0: [sdb] Attached SCSI disk

libata version 3.00 loaded.

md: initializing superblock

md: import disk0: HDIO_GET_IDENTITY ioctl error: -22

md: import disk0: HDIO_GET_IDENTITY ioctl error: -22

md: unRAID driver removed

md: unRAID driver 0.95.2 installed

md: xor using function: p5_mmx (7898.800 MB/sec)

md: import disk0: [8,48] (sdd) WDC WD10EACS-00ZJB0                          WD-WCASJ1908386 offset: 63 size: 976762552

md: import disk1: HDIO_GET_IDENTITY ioctl error: -22

md: import disk2: [8,32] (sdc) WDC WD10EACS-00D6B0                          WD-WCAU40627966 offset: 63 size: 976762552

md: import disk0: [8,48] (sdd) WDC WD10EACS-00ZJB0                          WD-WCASJ1908386 offset: 63 size: 976762552

md: import disk1: HDIO_GET_IDENTITY ioctl error: -22

md: import disk2: [8,32] (sdc) WDC WD10EACS-00D6B0                          WD-WCAU40627966 offset: 63 size: 976762552

mdcmd (3): start

md: import disk0: [8,48] (sdd) WDC WD10EACS-00ZJB0                          WD-WCASJ1908386 offset: 63 size: 976762552

md: import disk1: HDIO_GET_IDENTITY ioctl error: -22

md: import disk2: [8,32] (sdc) WDC WD10EACS-00D6B0                          WD-WCAU40627966 offset: 63 size: 976762552

unraid: allocated 7288kB

md2: running, size: 976762552 blocks

mdcmd (5): check

md: recovery thread woken up ...

md: recovery thread syncing parity disk ...

 

# mkdir -p /mnt/foo

# mount /dev/sdb1 /mnt/foo

# df -H /mnt/foo

Filesystem            Size  Used  Avail Use% Mounted on

/dev/sdb1              1.1T  646G  355G  65% /mnt/foo

# ls -l /mnt/foo/media/recordings/TheSimpsons-*

-rwx------ 2 root root 3492790148 Feb  3 21:00 TheSimpsons-IMarriedMarge-4536516-0.ts

-rwx------ 2 root root 3513946112 Nov 22 21:00 TheSimpsons-JazzyandthePussycats-3128200-0.mpg

-rwx------ 2 root root 3508084736 Nov 20 01:30 TheSimpsons-LifeontheFastLane-3083514-0.mpg

-rwx------ 2 root root 3489337344 Nov 19 21:00 TheSimpsons-That90sShow-3083515-0.mpg

#

 

Share this post


Link to post

Note for Safari users:  it appears you need to add a dummy style.css file in the config folder of your unRAID flash drive.  Please see this post.  This applies to unRAID versions 4.5-beta2 or later.

Share this post


Link to post

It looks like the 2.6.29.1 Linux kernel still cannot do HDIO_GET_IDENTITY on a SATA drive on my SuperMicro LSISAS1068E SAS controller.

 

Thank you for the detailed info.  The patch I thought would fix this is definitely in the 2.6.29.1 kernel  :(

Share this post


Link to post

Note for Safari users:  it appears you need to add a dummy style.css file in the config folder of your unRAID flash drive.  Please see this post.  This applies to unRAID versions 4.5-beta2 or later.

 

Fixed in next beta.

Share this post


Link to post

I have found a small issue (should be pretty rare).

 

Today I was having some internet explorer issues (I could get the web gui by using an ip address but not the servername).  I had just rebooted unraid.

 

To try and rule out unraid as the culprit I went into the "settings" page and clicked "apply" (under "Identification" section, first one on the page) to attempt to re-apply the servername (thinking that maybe the setting did not get set properly on boot).  When I did that, the cron jobs I had set previously (on boot) were erased. ( I use one for automatic parity checking on the first of the month.  The other is for spin control of the drives)

 

from syslog:

 

crontab initially being set-up during boot:

May  7 14:45:36 server emhttp: shcmd (17): rm /etc/samba/smb-shares.conf >/dev/null 2>&1
May  7 14:45:36 server emhttp: shcmd (18): cp /etc/exports- /etc/exports
May  7 14:45:36 server emhttp: shcmd (19): mkdir /mnt/user
May  7 14:45:36 server emhttp: shcmd (20): /usr/local/sbin/shfs  /mnt/user -o allow_other,attr_timeout=0,entry_timeout=0,negative_timeout=0
May  7 14:45:36 server emhttp: shcmd (21): cp /var/spool/cron/crontabs/root- /var/spool/cron/crontabs/root
May  7 14:45:36 server emhttp: shcmd (22): echo '# Generated mover schedule:' >>/var/spool/cron/crontabs/root
May  7 14:45:36 server emhttp: shcmd (23): echo '40 3 * * * /usr/local/sbin/mover 2>&1 | logger' >>/var/spool/cron/crontabs/root
May  7 14:45:36 server emhttp: shcmd (24): crontab /var/spool/cron/crontabs/root
May  7 14:45:37 server emhttp: shcmd (25): killall -HUP smbd
May  7 14:45:37 server emhttp: shcmd (26): /etc/rc.d/rc.nfsd restart | logger

 

crontab being reset after pressing the first "apply" button on the webgui "settings" page

May  7 14:59:24 server emhttp: shcmd (27): /etc/rc.d/rc.samba stop | logger
May  7 14:59:24 server emhttp: shcmd (28): /etc/rc.d/rc.nfsd stop | logger
May  7 14:59:25 server emhttp: shcmd (29): hostname server
May  7 14:59:25 server emhttp: shcmd (30): echo '# Generated' >/etc/hosts
May  7 14:59:25 server emhttp: shcmd (31): echo '127.0.0.1 server localhost' >>/etc/hosts
May  7 14:59:25 server emhttp: shcmd (32): cp /var/spool/cron/crontabs/root- /var/spool/cron/crontabs/root
May  7 14:59:25 server emhttp: shcmd (33): echo '# Generated mover schedule:' >>/var/spool/cron/crontabs/root
May  7 14:59:25 server emhttp: shcmd (34): echo '40 3 * * * /usr/local/sbin/mover 2>&1 | logger' >>/var/spool/cron/crontabs/root
May  7 14:59:25 server emhttp: shcmd (35): crontab /var/spool/cron/crontabs/root
May  7 14:59:25 server emhttp: shcmd (36): rm /etc/samba/smb-shares.conf >/dev/null 2>&1
May  7 14:59:25 server emhttp: shcmd (37): cp /etc/exports- /etc/exports
May  7 14:59:25 server emhttp: shcmd (38): /etc/rc.d/rc.samba start | logger
May  7 14:59:25 server logger: Starting Samba:  /usr/sbin/nmbd -D
May  7 14:59:25 server logger:                  /usr/sbin/smbd -D
May  7 14:59:25 server emhttp: shcmd (39): /etc/rc.d/rc.nfsd start | logger

 

It appears that when I applied the changes, that the cron jobs were reset like they are when the system is booted.  Namely, it takes the stock version from "/var/spool/cron/crontabs/root", adds the mover script job and then resets cron (processes 32-35 in syslog snippit).

 

Tom, is there any way to prevent unraid from killing user added cron jobs when settings are changed in the webgui?

 

Also, thank you kindly for including the driver for the on-board nic on the ASUS P5KPL-CM.  It is working perfectly now.

 

Driver Details:

NIC driver info (from ethtool -i)

driver: ATL1E

version: 1.0.0.7-NAPI

 

Cheers,

Matt

Share this post


Link to post

How do you set up your cron jobs?  If you are modifying the file '/var/spool/cron/crontabs/root' via the 'go' file, then just modify '/var/spool/cron/crontabs/root-' instead.

 

That's one of the purposes of the file with the '-' character appended.  You can make custom edits to this file that will be retained when webGui makes changes.  The '/etc/exports' is similar, there is a '/etc/exports-' file.

Share this post


Link to post

I've just had *major* problems after having updated to 4.5-beta6. I'm coming from 4.3.3, where all worked ok for me. Dated up to 4.5-beta6. After boot was complete, one of my data disks was shown as "unformatted", the others were shown correctly. Afraid as I was, I tried to stop the array at once. Well, it didn't work, it kept running. But the page refreshed itself. Now the cache disk and all data disks but one were listed as "unformatted" and the array was still not stoppable (tried several times). I began to sweat quite a lot. unRAID 4.5-beta6 was still reading from the one data disk it accepted. So I waited two minutes and then I could finally stop the array, go back to 4.3.3 and fortunately all is well again now with 4.3.3.

 

As you may be able to imagine I'm quite afraid of ever upgrading to a newer version again now. I've invested thousands of hours into my data. Losing it would be a catastrophe...

 

(8x Western Digital 1TB, 2x Samsung 1 TB, cache drive Samsung 500GB)

 

Edit: What I can say is that even those harddisks which were first detected and displayed correctly, and which were shown as unformatted only after I first try to stop the array, have got that reiserfs directory added to their root. So how can unRAID claim they are unformatted when it's able to create a directory on them?

Share this post


Link to post

Maybe it would make sense to change the array start logic? IMHO after a fresh boot the array should *never* start automatically, if the array is not in 100% perfect state (all harddisks being detected as formatted and in 100% perfect state). A manual start should be necessary in any other case. I think that would be the best way to make sure that a software bug/problem like I experienced could never destroy any data. If the array had been in stopped state with unRAID never having done *any* write access to any of the harddisks after the 4.5-beta6 boot, I wouldn't have had to sweat at all and could now provide you with logs or whatever info you needed. But I won't go back to 4.5-beta6 as long as it tries to start the array and write to the disks. (The statistics showed that write accesses did happen.)

Share this post


Link to post

As long as you don't click 'Format' button you can't lose any data.  The write statistics you see are the result of the 'mount' process & the fact that writes are taking place at all means that the unRAID driver is started & operating correctly with the correct configuration.

 

The 'unformatted' status appears following array Start when a disk does not 'mount' correctly - that is, linux did not find a valid reiserfs file system on the disk.  This should never happen, especially if array parity is valid (because read errors should be corrected on-the-fly and write errors should cause the disk to get disabled, but still mount).

 

When Stopping the array, if a disk does not un-mount correctly, all the ones that did un-mount will have 'unformatted' status.  This is a longstanding issue which has been fixed in next beta (4.5-beta7).

 

But it's important for me to see why one of your disks wouldn't mount when moving from 4.3.3 to 4.5-beta6.  So I'd like to ask you to upgrade once more, boot up the server, and then capture the system log.  An easy way to capture the log, once the server is up, is enter this in the address bar of your browser:

 

  //tower/log/syslog

 

(of course substitute the actual name of your server for 'tower' if you changed it).  Then click inside the browser window, hit Ctrl-A then Ctrl-C, and then paste the text into an email to me tomm@lime-technology.com or paste into a post here.

Share this post


Link to post

Out of curiosity, are you using the ls-R trick? I have the same problem as you with regards to stopping the array and not being able to unmount all the drives because of read activity. However this only occurs if I want to stop the array within five minutes from booting it. I found that by not running ls-R I don't get the problem any more so I reckon it is just the ls-R process caching the drive.

 

 

Santan

Share this post


Link to post

As long as you don't click 'Format' button you can't lose any data.

Ok, I'm afraid, but I guess I'll have to trust you on this one...   :-\

 

The 'unformatted' status appears following array Start when a disk does not 'mount' correctly - that is, linux did not find a valid reiserfs file system on the disk.  This should never happen, especially if array parity is valid (because read errors should be corrected on-the-fly and write errors should cause the disk to get disabled, but still mount).

I have a suspicion why the problem may have occurred:

 

unRAID 4.3.3 did not write any system folders to the drives. But unRAID 4.5-beta6 tried to create one system folder on every disk named "reiserfs" something. Now before I updated to 4.5-beta6 I had cleaned up the cache disk. However, I didn't have enough free space on the data disks. So 2 of the data disks were shown with 0 bytes free on the statistics page (with 4.3.3). Now my guess is that the latest reiserfs file system driver for whatever funny reason has to create those system folders and if it can't, mounting fails. And I guess that creating that folder failed on one of the 0 byte free disks because, well, there was no space left to create even an empty folder.

 

Does that sound reasonable?

 

I've now cleaned up those 0 byte free harddisks and will try to install 4.5-beta6 again. If my guess was right, it might work this time. BTW, there were two 0 byte free disks, but only one failed to mount. I guess that despite the 0 byte free the other drive managed to squeeze that new system folder in somehow while the other disk couldn't...

 

EDIT: Yes, 4.5-beta6 works now. So I think my guesses posted above are probably good.

 

Out of curiosity, are you using the ls-R trick? I have the same problem as you with regards to stopping the array and not being able to unmount all the drives because of read activity. However this only occurs if I want to stop the array within five minutes from booting it. I found that by not running ls-R I don't get the problem any more so I reckon it is just the ls-R process caching the drive.

I don't even know what Is-R is, so it's most probably not the reason why I couldn't stop the array at first...

Share this post


Link to post

I've just had *major* problems after having updated to 4.5-beta6. I'm coming from 4.3.3, where all worked ok for me. Dated up to 4.5-beta6. After boot was complete, one of my data disks was shown as "unformatted", the others were shown correctly. Afraid as I was, I tried to stop the array at once. Well, it didn't work, it kept running. But the page refreshed itself. Now the cache disk and all data disks but one were listed as "unformatted" and the array was still not stoppable (tried several times). I began to sweat quite a lot. unRAID 4.5-beta6 was still reading from the one data disk it accepted. So I waited two minutes and then I could finally stop the array, go back to 4.3.3 and fortunately all is well again now with 4.3.3.

 

As you may be able to imagine I'm quite afraid of ever upgrading to a newer version again now. I've invested thousands of hours into my data. Losing it would be a catastrophe...

 

(8x Western Digital 1TB, 2x Samsung 1 TB, cache drive Samsung 500GB)

 

Edit: What I can say is that even those harddisks which were first detected and displayed correctly, and which were shown as unformatted only after I first try to stop the array, have got that reiserfs directory added to their root. So how can unRAID claim they are unformatted when it's able to create a directory on them?

In this case, unRAID is mis-reporting what actually happened...  Your drives were not "unformatted" but instead, "not mounted."  The data on them was safe from any access.  As Tom already said, as long as you do not press the "Format" button, you did no harm. 

 

It is interesting this happened to you when in the middle of an upgrade and your symptoms are slightly different than we are used to hearing about.  When you first rebooted you said one drive was "unformatted"  Perhaps it had not yet spun up... or had some issue that caused it to not mount properly... That is why the copy of the syslog would be so helpful...

 

When you tried to stop the array, you said all but one drive showed as "unformatted"  That is usually a symptom of that one drive being busy and unable to be un-mounted.  (Were you logged onto the server via telnet or the system console doing this?  I ask because if you had changed directory to one of the disks to do the clean-up, it would be "busy" since it was your current directory, and unable to be un-mounted)

 

We've been working with Tom towards a solution to that same symptom of "unformatted" that occurs when attempting to stop the array, and the unRAID software is unable to un-mount the drives prior to stopping the array.  This can occur when a process is keeping the drive from being un-mounted, usually because a program is still accessing a file on the disk.  unRAID's managemenmt web-page in-accurately shows "unformatted" on all the drives it was able to un-mount, and shows proper data on those it was unable to un-mount because they were busy.  It is equally unsettling when you first see it.

 

Are you running any add-on programs or packages at all.  Were you doing the reboot at the same time the "mover" script was trying to empty your cache drive?  It might have been the process keeping the disk busy.  The more clues you can provide, the better we can figure out what happened.

 

Reading your last post more closely, I think your suspicions are correct.... I'll bet you are right on track that the initial error had something to do with the disks being full.. I doubt many people have had that exact situation when rebooting during this upgrade. I can imagine if it was unable to create the .reiserfs_priv file when mounting , the mount might fail, and you wold see "unformatted" as unRAID interperted the inability to mount as not containing a mountable reiser file system... thus showing you "unformatted."

 

I'm sure Tom will also have some ideas.  If you can post a syslog, please do so... It will help.

 

Joe L.

Share this post


Link to post

How do you set up your cron jobs?  If you are modifying the file '/var/spool/cron/crontabs/root' via the 'go' file, then just modify '/var/spool/cron/crontabs/root-' instead.

 

That's one of the purposes of the file with the '-' character appended.  You can make custom edits to this file that will be retained when webGui makes changes.  The '/etc/exports' is similar, there is a '/etc/exports-' file.

 

Tom,

 

When I originally wrote the script, I used some example I found in the forum.  The basic process (in the script) I use to add cron jobs is as follows:

 

1. crontab -l > /tmp/crontab

2. "grep -q" to see if the command already exists in /tmp/crontab

3. If so, delete them so we don't have more than one (using grep -v)... then add the job to /tmp/crontab

4. reset cron with the newly modified /tmp/crontab file

 

this seems to be the most popular way of adding cron jobs from all the scripts I found, including what many people use to schedule parity checks. (in fact I can't think of another way I saw it done in all the user scripts I looked over)

 

Attached is the script I wrote, it can be used anytime to change/show status/add/remove scheduled parity checks. (included for sake of full disclosure, I also copy it to /usr/bin on boot for easy access).  I added a txt extension to the file for forum uploading reasons.

 

I run it with the command:

paritycheck -f Monthly -H 4 (to schedule a monthly parity check at 4 am on the first day of the month)

 

Usage: $progname [Now/Stop] [-f Freq] [-H Hour] [-m Minute] [-M Day of Month] 
             [-d Weekday] [-s] [-h] [-r]

       Now = Start parity check immediately.  Argument must be used alone.
       
       Stop = Stop a parity check in progress.
       
       -f Freq = Frequency of the parity check.  Possible values: Quarterly, 
            Bi-Monthly, Monthly, Weekly, Daily.
            
            If Quarterly, Bi-Monthly or Monthly is selected, the day of month, 
            hour and minute argument are needed and if not specified will 
            default to the value specified below.  The weekday argument is 
            ignored if supplied.
            
            If Weekly is selected, the weekday, hour and minute arguments are 
            needed and if not specified will default to the value specified 
            below.  The month and day of month arguments are ignored.
            
            If Daily is selected, only the hour and minutes arguments are 
            needed and if not specified will default to the value specified 
            below.  All others are ignored.
            
       -H Hour = The hour of the day (24 hour clock) to perform the parity 
            check.  Single value or expression compliant with the hour column 
            in cron.  
                   
       -m Minute = The minute of the day to perform the parity check.  Single 
            value or expression compliant with the minute column in cron.  
                   
       -M Day of Month = The date of the month to perform the parity check.  
            These are values 1-31. (note: some months don't have 31 days)
                  
       -d Weekday =  The day of the week to perform the parity check.  Single 
            value or expression compliant with the hour column in cron. 
            Including: 0-6 or sun-sat.
                   
       -s = status - Gives current status of parity check.  Cannot be used 
            with other options.
       
       -r = Remove - Remove scheduled parity check, if exists.  Cannot be used
            with other options.
       
       -h = help - Provides usage screen.  Cannot be used with other options.
       
       -? = help - Provides usage screen.  Cannot be used with other options.

 

 

 

How should I be adding jobs to cron?  Are you suggesting that I change the file I am modifying from '/tmp/crontab' to '/var/spool/cron/crontabs/root-'?  If not, maybe you could provide a small example of how you envisioned they would be added?

 

Cheers,

Matt

Share this post


Link to post

Just upgraded from 4.3.3 to 4.5-beta6. Running solid for a day with no issues. For whatever reason 4.4 never worked on my system, the server would become unresponsive after several hours. Happy that 4.5 has solved whatever issues I was having before!

Share this post


Link to post

How should I be adding jobs to cron?  Are you suggesting that I change the file I am modifying from '/tmp/crontab' to '/var/spool/cron/crontabs/root-'?  If not, maybe you could provide a small example of how you envisioned they would be added?

 

Yes you should update '/var/spool/cron/crontabs/root-' for your custom crontab changes.  Every time you apply changes to a share configuration setting, the crontab 'root' file is regenerated by starting with the 'root-' file and then appending any changes required by the setting change (at present only thing put in the 'root' crontab file is the mover schedule).

 

In the particular case you cite here though, there is an easier way to accomplish what you want.  Just create a script that executes the 'mdcmd check' operation and place this script into the /etc/cron.monthly directory.  Any scripts in this directory are executed at 4:20AM on the first day of a month.

Share this post


Link to post

I have a suspicion why the problem may have occurred:

 

unRAID 4.3.3 did not write any system folders to the drives. But unRAID 4.5-beta6 tried to create one system folder on every disk named "reiserfs" something. Now before I updated to 4.5-beta6 I had cleaned up the cache disk. However, I didn't have enough free space on the data disks. So 2 of the data disks were shown with 0 bytes free on the statistics page (with 4.3.3). Now my guess is that the latest reiserfs file system driver for whatever funny reason has to create those system folders and if it can't, mounting fails. And I guess that creating that folder failed on one of the 0 byte free disks because, well, there was no space left to create even an empty folder.

 

Does that sound reasonable?

 

Actually, no.  The files you are referring to are called '.reiserfs_priv' and they exist only in the root directory of a file system.  They are used to store "extended attributes" which are necessary to support Active Directory correctly.  All releases prior to 4.5-beta2 should never create these files.  All releases starting with 4.5-beta3 will only possibly create these files if you select 'Active Directory' as the security mode.  So if you went directly from 4.3.3 to 4.5-beta6 (and are not using Active Directory) I don't see how you could see these files.

 

Also, I don't see how a file system with 0 free blocks would not mount - never have seen that.

 

Again, need to see a system log.

Share this post


Link to post

Just upgraded from 4.3.3 to 4.5-beta6. Running solid for a day with no issues. For whatever reason 4.4 never worked on my system, the server would become unresponsive after several hours. Happy that 4.5 has solved whatever issues I was having before!

Thanks for the feedback!  Good to hear of success once in a while  ;D

Share this post


Link to post

How should I be adding jobs to cron?  Are you suggesting that I change the file I am modifying from '/tmp/crontab' to '/var/spool/cron/crontabs/root-'?  If not, maybe you could provide a small example of how you envisioned they would be added?

 

Yes you should update '/var/spool/cron/crontabs/root-' for your custom crontab changes.  Every time you apply changes to a share configuration setting, the crontab 'root' file is regenerated by starting with the 'root-' file and then appending any changes required by the setting change (at present only thing put in the 'root' crontab file is the mover schedule).

 

In the particular case you cite here though, there is an easier way to accomplish what you want.  Just create a script that executes the 'mdcmd check' operation and place this script into the /etc/cron.monthly directory.  Any scripts in this directory are executed at 4:20AM on the first day of a month.

 

Thank you for the prompt replies.  I will update my cron scripts to modify the suggested file in addition to the current cron file.  Originally the script was placing the "mdcmd check" script in the etc.cron.* directories, as it evolved, I wanted more control over time and date and more frequency options (for future use and so others could benefit from the same script).

 

I also recently updated (yesterday) to 4.5beta6 from 4.3.3 and am extremely happy I did.  The added features and settings have come in helpful and I have not had any issues realted tot he release (just the cron stuff, which is mostly my fault... user ignorance).

 

Keep up the great work!  looking forward to seeing what the future holds.

 

Cheers,

Matt

Share this post


Link to post

Just upgraded from 4.4.2.

 

Seems to have issues with cache drive speed:

 

- using 4.4.2 write to cache drive via user share was ~30MB/sec (still too low for my full satisfaction)

- using 4.5-beta6 write to cache drive via user share is between 9-14MB/sec

  However, if I try to write to cache drive directly (not via user share) I can reach the level I had with 4.4.2 at ~30MB/sec

 

Is it a bug or the problem is on my side?

 

Thank you for your support in advance!

Share this post


Link to post
Guest
This topic is now closed to further replies.