unRAID Server Release 4.7 "final" Available


Recommended Posts



This is exactly the same as 4.7-beta1 except for the version string changed to simply "4.7".


unRAID Server 4.7 Release Notes

Installation on a New Flash Device

To make a bootable USB Flash device using Windows (XP/Vista/Win7), follow these steps:
1. Plug your USB Flash device into your Windows PC.
2. Open 'My Computer' (XP) or 'Computer' (Vista/Win7) and right-click your Flash device. Click 'Format...', set the volume label to UNRAID and then click 'Start'. Important: the volume label must be set to UNRAID (all caps).
3. Click on your Flash device (to open it) and drag then entire contents of the unRAID Server zip file to the Flash.
4. For Windows XP, click on the file 'make_bootable'.  A DOS window will open and run the 'syslinux' utility on the Flash.  For Windows Vista or Windows 7, right-click on the file 'make_bootable' and select 'Run as administrator'.
5. Once again, right-click your Flash device in 'My Computer' or 'Computer' and then click 'Eject'.  Your Flash device is now ready to boot into unRAID Server OS.

Upgrading an existing Flash Device

Note: after upgrading, some changes may require additional user intervention, please refer to the Change Log below.

If you are currently running unRAID Server 4.6 or higher, please copy the following files from the new release to the root of your Flash device:

If you are currently running unRAID Server 4.5.x, 4.4.x, 4.3.x or 4.2.x, please copy the following files from the new release to the root of your Flash device:

If you are currently running unRAID server 4.1 or 4.0, please copy the following files from the new release to the root of your Flash device:

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 any version of unRAID Server before 4.0, please contact support@lime-technology.com for upgrade instructions.

Change Log

Changes from 4.7-beta1 to 4.7

No changes (except version string).

Changes from 4.6 to 4.7-beta1

Feature: Advanced Format drive support - partition 1 may now be aligned on 4K boundry (sector 64)

This release now provides support for so-called Advanced Format (AF) drives.  AF drives are hard drives which
have native 4KB sector size instead of traditional 512-Byte sector size (though these drives typically still report
a sector size of 512-Bytes to the operating system).  Drives larger than 2TB are still not supported in this release

Traditionally, when the Master Boot Record (MBR) is created on a hard drive, partition 1 is positioned to start
on sector 63.  This is due to legacy support for old drives that use cylinder/head/sector addressing instead of
Logical Block addressing.  AF drive support involves nothing more than positioning the start of Partition 1 on
sector 64 instead of sector 63, thus "aligning" it on a 4KB boundary (since 64 sectors = 32KB which is a multiple
of 4KB).

Whether to create Partition 1 starting with sector 63 or sector 64 is configurable using a new setting in the Disk
settings section of the Settings page called "Default partition format".  The default value of this setting is
"MBR: unaligned", which specifies an MBR-style partition table with partition 1 starting in sector 63.  If you
intend to install a new AF drive, you should first change this setting to "MBR: 4K-aligned", which specifies an
MBR-style partition table with partition 1 starting in sector 64.  [Note a future version may include a third
option called "GPT", or "GUID Partition Table".  This will be necessary to support drives larger than 2TB.]

For most AF drives, you will want to set "Default partition format" to "MBR: 4K-aligned" for maximum performance
(but see note about the Western Digital EARS drives below).  Also, there is no performance or storage loss in
starting Partition 1 in sector 64 for ALL drives, not just AF drives.

IMPORTANT: any drive formatted with "MBR: 4K-aligned" using this version of unRAID OS will NOT BE RECOGNIZED as
formatted in any previous version of unRAID OS.

As for WD EARS - these drives include a physical jumper which, if installed, remaps the sectors internally
so that if Partition 1 is created to start in sector 63, it gets remapped to a starting sector that is on a 4K
boundary (a hack to support Windows XP).  If you have formatted an EARS drive with a previous version of unRAID or
Windows with the jumper in place, we recommend you leave the jumper in place and do not re-format the drive; just
treat it as a non-AF drive.  There is NO performance penalty for doing this!

Finally, the MBR of any drive that already has a valid "unRAID" MBR will not be re-written, regardless of the
setting of "Default partition format".  This includes unRAID MBR with "factory-erased" signature.  Therefore, if
you use Joe L.'s excellant "preclear_disk" script, you must expclitly use the -A option to position partition 1 in
sector 64 if this is what you desire.

Other: added Cancel button when Clearing is in process.

Bug fix: fix problem causing Win7 to report "too many open files"

Bug fix: disable login on certain non-user accounts.

A bug was fixed where certain non-users were able to login via telnet. But to get this fix to apply (if you want), you must follow this procedure:
1. After booting this release, go to your flash share and delete the files 'config/passwd' and 'config/smbpassd'
2. Reboot the server
Note: you will need to re-enter any users you had created.

Bug fix: do not save HWADDR to config/network.cfg.

Previously, the ethernet MAC address (HWADDR) was being stored in 'config/network.cfg'.  Normally this causes no problems unless configuration moved to a different motherboard in which case the old MAC address could instated.
To instate this fix, you should click on 'Apply' under the Network section of the Settings page so that 'config/network.cfg' gets re-written.

Link to comment
  • Replies 414
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Good news.  Thanks for the continued effort.  I will install jumpered drives this time around as the preclear is almost complete with Jumper in place.  No sense shutting down to remove jumpers to format again, so I will just run 4.7 and then install non-jumpered "-A" cleared disk next time around...


Great work!

Link to comment



Could someone please clarify this for me :

Can any disk currently installed in the array be converted to 4K or should we need to buy specific drives?

Any drive can be converted but ONLY "ADVANCED FORMAT" drives will benefit from the 4-K alignment.  You can go through the lengthy process of changing all your disks but I highly suggest that you DO NOT do that.

Link to comment



Could someone please clarify this for me :

Can any disk currently installed in the array be converted to 4K or should we need to buy specific drives?

Any disk can be installed and partitioned to start on a 4k aligned boundary.   It will not have any effect on anything on an older disk drive that needed to be aligned to a 512 byte boundary.    (because aligning to a 4K boundary also automatically aligns it to a 512 byte boundary.)


So, you do not need to buy any special drives.  All will work.  


Your existing drives do not need to be changed in any way to use 4.7.  They will work exactly as they do today on 4.6.


If you purchase a new drive and install it you might as well use the new MBR-4k-alignment.   Just be aware... and drive partitioned for 4k-alignment will not be recognized in an older version of unRAID.


Joe L.

Link to comment

Thank you :)


As I already have a couple of "new" 2TB drives, is there a way to know if they will benefit from a realignment?

Do they say "Advanced Format" on them anywhere?  or mention 4k sectors?


If not, they probably won't benefit.  (It won't hurt, other than you cannot expect them to be recognized in older releases of unRAID as valid unRAID drives.)


General advice.  If the drives are already assigned in your array, don't mess with them. 


Joe L.

Link to comment



Did a upgrade from 4.6 , Now a have a issue with one disc, Replacement disk is too small.


I know that is the GIGABYTE issue, but how can I easily fix this ? without loosing my data on that disk?


DISK_WRONG	/dev/md5		/dev/sdf	SAMSUNG_HD103UJ_S13PJ1KQ612827 <-- was old disk in this slot
  SAMSUNG HD103UJ _S13PJ1KQ612827 <-- current disk in this slot


From syslog

Jan 25 17:31:36 Tower kernel: ata8.00: HPA detected: current 1953523055, native 1953525168 (Errors)







Link to comment

Yes, you can do it without losing data.


Try this:

hdparm -N p1953525168 /dev/sdf


Follow it with

hdparm -N /dev/sdf

to see if it took effect.



My results below


root@Tower:~# hdparm -N p1953525168 /dev/sdf



setting max visible sectors to 1953525168 (permanent)

max sectors   = 1953525168/7368112(1953525168?), HPA setting seems invalid (buggy kernel device driver?)




root@Tower:~# hdparm -N /dev/sdf



max sectors   = 1953525168/7368112(1953525168?), HPA setting seems invalid (buggy kernel device driver?)



I did a refresh but still same, but now I rebooting...

Link to comment

Now it saying

Start will bring the array on-line, start Data-Rebuild, and then expand the file system.


Hmm should I do that ?

It sounds as if it now thinks the disk is bigger than it was previously.  That is a good sign.


What do you get now when you type:

hdparm -N /dev/sdf


Is there any mention of the HPA in the syslog?

grep -i hpa /var/log/syslog


also post the output of

grep  sdf  /var/log/syslog


The good news is once uRAID expands the file system, you'll gain back those few meg it used for the HPA for use in the array.


It will basically be re-constructing what is currently there, so the risk is very small.  I say if everything else looks good, start the array.  In about 9 or 10 hours (perhaps less if you have a fast server) you'll be back to normal, but without the HPA.


Joe L.


Link to comment

Here is the results


The first command didn't show anything.


and the other is here


root@Tower:~# grep  sdf  /var/log/syslog
Jan 25 18:26:25 Tower kernel: sd 8:0:0:0: [sdf] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
Jan 25 18:26:25 Tower kernel: sd 8:0:0:0: [sdf] Write Protect is off
Jan 25 18:26:25 Tower kernel: sd 8:0:0:0: [sdf] Mode Sense: 00 3a 00 00
Jan 25 18:26:25 Tower kernel: sd 8:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 25 18:26:25 Tower kernel:  sdf:
Jan 25 18:26:25 Tower kernel:  sdf1
Jan 25 18:26:25 Tower kernel: sd 8:0:0:0: [sdf] Attached SCSI disk
Jan 25 18:26:30 Tower emhttp: pci-0000:00:11.0-scsi-3:0:0:0 host8 (sdf) SAMSUNG_HD103UJ_S13PJ1KQ612827
Jan 25 18:26:31 Tower kernel: md: import disk5: [8,80] (sdf) SAMSUNG HD103UJ  S13PJ1KQ612827       size: 976762552




Thanks for your help, Joe :-)




Link to comment

There is one more important step.  Because you have 'extended' the drive, the parity info for that area assumed the area contained all zeros, but that area actually contains a copy of the BIOS.  Now that the area is included, the parity info is invalid, and could cause corruption (within that very remote area!) to any disk rebuilt subsequently.


You should therefore run a parity check, and I would expect it to report a number of parity errors at the very end of the drive, while fixing the parity info there.  Alternatively, you could possibly zero it out manually, with a dd command, and some careful calculations of the start and end of that area.  Joe would be much better at providing the correct dd command to zero the area out.  I would still run a parity check, to verify that all is now valid.


I don't know for sure, but I think it is also possible that the Reiser file system may use a bit of that space.  I believe for performance reasons, ReiserFS stores some leaves or parts of its file systems evenly throughout the disk space.  It is remotely possible therefore that the Reiser self-expansion due to the apparent disk size change could store something up there.  I would run a reiserfsck afterward, to make sure a zeroing did not overwrite it.


In the past, we recommended that users just ignore this HPA, if they did not plan on using the drive as the parity drive.  The amount of disk space is minuscule, and completely beyond normal usage at the very end of the drive, not worth all of this hassle.  If v4.6 and up require dealing with it, then a number of users have this hassle to look forward to.  I really hope not.  It would probably be better if Tom could find a way to just ignore these HPA's, and accept the declared disk size.


These HPA's are refusing to leave us alone!  Now they may be back, trying to have the last laugh!  Sounds like a horror movie sequel.

Link to comment

I would just do a parity check.  It will fix anything from those upper 4k of space.   I would NOT zero it out, since the file system has been expanded, and I have no idea what it might have put there.

We do know one thing for certain, Gigabyte had some stuff there, and it will not be all zeros.


So yes, do a parity check.  Do not be alarmed if it finds a lot of parity errors when it gets to the end.  They are expected.

A second parity check should come up clean.


Yes, the HPAs are more of a pain in the backside than ever.  Nice it was easy to remove it using hdparm.


Joe L.  

Link to comment

Sure, I just get unRAID 4.7b1 working and the real 4.7 comes out, time to test my first update!!!   ::)


My first "update" seems to be successful.  I get the following warnings and errors (in bold).  Any reason to be alarmed?


Jan 25 04:12:08 Tower kernel: ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0000000000000000/1 (20090903/tbfadt-557) (Minor Issues)

Jan 25 04:12:08 Tower kernel: ACPI Error (psargs-0359): [ECEN] Namespace lookup failure, AE_NOT_FOUND (Minor Issues)

Jan 25 04:12:08 Tower kernel: ACPI Error (psparse-0537): Method parse/execution failed [\] (Node c14760c8), AE_NOT_FOUND (Minor Issues)

Jan 25 04:12:08 Tower kernel: ACPI Warning: Incorrect checksum in table [OEMB] - 91, should be 8C (20090903/tbutils-314) (Minor Issues)

Jan 25 04:12:08 Tower kernel: ACPI: I/O resource it87 [0x295-0x296] conflicts with ACPI region SIOE [0x290-0x2af] (Minor Issues)

Jan 25 04:12:08 Tower kernel: atiixp 0000:00:14.1: simplex device: DMA disabled (Errors)

Jan 25 04:12:08 Tower kernel: ide1: DMA disabled (Errors)

Jan 25 04:12:10 Tower emhttp: shcmd (14): killall -HUP smbd (Minor Issues)



Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.