unRAID Server Release 5.0-beta6a Available

[limetech]

Download

 

No one likes reading instructions, but please read this...

 

When you first boot this release, the array will not be automatically Started.  Instead, it will appear as if it were just Stopped.  In addition, the MBR type of each disk is displayed in the Identification column on Disk Status page.  There are 6 possible MBR types:

 

1. MBR: unaligned

2. MBR: 4K-aligned

3. MBR: unaligned (factory-erased)

4. MBR: 4K-aligned (factory-erased)

5. MBR: unknown

6. MBR: error

 

If you see case 5 MBR: unknown for any disk which has previously been used just fine in prior unRaid release, DO NOT START the array; instead, post your finding in this thread so that I can work with you to figure out why this is happening.  The attached image shows how the MBR information is displayed, with the "MBR: unknown" case highlighted.

 

Also included with this release is command-line utility called "mkmbr".  Here is the documentation:

 

/* mkmbr <device> [<offset> [<type>]]
*
* This program may be used to write an "unRAID style MBR". This is simply a normal MBR
* with a single partition 1 starting in either sector 63 or sector 64 and spanning the
* entire remaining size of the disk.  For normal operation, partition 1 "type" is set
* to 0x83 (Linux).  A special case is this: if "type" is set to 0, this is recognized
* by the unRAID management utility as a "factory erased" disk, that is, the entire
* contents of partition 1 are presumed set to zeros.  This lets us add the disk immediately
* to an existing array without disturbing parity.  If you use this program to set "type"
* to 0, but partition 1 is not all-zeros, you will not be able to reconstruct a failed
* drive - you have been warned!
*
* This program only handles hard drives less than 2TB in size; however, an attempt to
* write the MBR on a hard drive larger than 2TB should be recognized and cause the program
* to exit without writing anything. (Should output an "inconsistent size" message.)
*
* The four useful combinations for unRAID are (using /dev/sdc for example):
*  mkmbr /dev/sdc 63 0x83  => normal MBR, partition 1 starts in sector 63
*  mkmbr /dev/sdc 64 0x83  => normal MBR, partition 1 starts in sector 64
*  mkmbr /dev/sdc 63 0     => factory erased, partition 1 starts in sector 63
*  mkmbr /dev/sdc 64 0     => factory erased, partition 1 starts in sector 64
*
* Since offset and type default to 63 and 0x83 respectively, one could use instead:
*  mkmbr /dev/sdc          => normal MBR, partition 1 starts in sector 63
*  mkmbr /dev/sdc 64       => normal MBR, partition 1 starts in sector 64
*
* You could also use this program to create an MBR of any "type" with partition 1 starting
* at any "offset" (and spanning remaining space on disk).  The unRAID management utility
* will deem the MBR "unknown" however.
*/

 

This utility may be used to repair a MBR which has been written incorrectly.  Please note: this utility, like most MBR utilities, only writes sector 0 of the disk.  It does not destroy any file data, and does not render a disk useless (though it might be temporarily useless until MBR is corrected).  There is a lot of lore surrounding MBR's and partitioning which has created great confusion over the years.  In reality, the data structure of a MBR is extremely simple, and much of the complication surrounding them has to do with getting a simple data structure to represent something more complex than it was originally designed for.  With unRaid however, use of the MBR is extremely simple - no funny business with extended partitions, hidden partitions, etc.

 

If you have issues with MBR's please post here and we will sort out what's happening.

 

Please read the Release Notes located on the unRAID wiki.

 

In particular, uninstall or disable any 3rd party add-ons until the add-on author has verified correct operation with this release.

[Zeron]

There seems to a bit of an issue with the new Autostart option:

 

Upgrade from 5.0b6 to 5.0b6a

  all my disks come up with a valid MBR type.

  Start Array.

  Check the Autostart option; It was set to Yes automatically.

  Reboot

  Array does not start,

  Check the Autostart option; It is now set to No.

  Start Array.

  Auto Start is now Yes.

  Stop Array

  Auto Start is now No.

  Set Auto Start to Yes.

  Reboot.

  Array actually Autostarts.

 

 

 

 

[smoldersonline]

As with the previous beta (5.0-beta6), I have a "wrong disk" issue. I have attached a screen from this beta and a screen that I took from 5.0-beta2. I was on beta4 and that works OK, except for the fact that (after a boot) I sometimes have to assign disks 7 through 14.

 

I would like to go back to beta4, but can wait with downgrading if I can help.

[smoldersonline]

Sorry, 2nd screen (5.0-beta6a) attached here.

[prostuff1]

Sorry, 2nd screen (5.0-beta6a) attached here.

 

Did you read the Release Notes link given at the end of the thread that says you have to delete the super.dat file in the config folder?

 

You will have to delete that and then reassign all your drives.

[BRiT]

Uhm, yeah, what prostuff1 said while I was busy typing the exact same thing.

 

Copy from the release notes:

    * Version 5.0-beta3, 5.0-beta4, 5.0-beta5, 5.0-beta5a, 5.0-beta5b

 

  1. Prepare the flash: either shutdown your server and plug the flash into your PC or Stop the array and perform the following actions referencing the flash share on your network:

          * Copy the files bzimage and bzroot from the zip file to the root of your flash device, overwriting the same-named files already there.

          * Delete the file config/super.dat. You will need to re-assign all your hard drives.

 

  2. Reboot your server. Once boot-up has completed, you should see "Stopped. Configuration valid." array status with all disks assigned correctly except for the Cache disk. If you previously had a Cache disk assigned, you will need to re-assign it manually and re-apply any unique configuration settings for it.

 

  3. Carefully examine the Identification strings for each disk. If you see "MBR: error", or "MBR: unknown" for any disk, do not Start the array; instead post your finding in the Forum announcement thread for this release. If everything looks ok, click Start to bring the array on-line. Note: there is a new configuration setting on the Disk Settings page called "Enable auto start". If you set this to "Yes", then upon next server boot, if the array is valid, then it will be automatically Started (this is the old behavior).

[BRiT]

Unfortunately my situation is as expected -- everything reports as it should, so I can not help troubleshoot the original issue seen on my system. 

 

Parity: MBR: 4K-aligned

Drive 1: MBR: unaligned

Drive 2: MBR: unaligned

Drive 3: MBR: unaligned

Drive 4: MBR: 4K-aligned

Drive 5: MBR: 4K-aligned

 

However, I will be having some server repairs going on tomorrow involving more reboots, so should anything change in my situation I will be sure to dump the original MBR before proceeding. I want to verify this command will work to accomplish that:

 

dd if=/dev/sd# of=original_sd#.mbr count=1

[smoldersonline]

That is what I did: delete super.dat and then reboot. The screen I attached is after I tried to assign the disks.

[prostuff1]

I never ran into the original issue but I have a test machine that has 2 IDE drive and 2 SATA drive ready to go and that can have pretty much anything done to them.  I can set some up to be 4K aligned and some to not be 4K aligned.

 

The parity drive would be a 200GB drive and every other drive is smaller than that.

 

Let me know Tom if you want me to format any of them specifically in a certain config.

[prostuff1]

That is what I did: delete super.dat and then reboot. The screen I attached is after I tried to assign the disks.

 

replace the disk.cfg file from the distribution with the one in your config folder.  You will have to probably reset some specific disk settings but try that.

[johnodon]

Upgraded from v5b6 to v5b6a.

 

All drives came back as MBR unaligned or MBR 4K aligend.  No errors or unknowns as expected since I was able to upgarde from v5b4 to v5b6 without issue.  Configuration was valid...started array...parity valid.

 

In short, no issues here.

 

John

[smoldersonline]

I must be loosing my mind... Again deleted super.dat and (again) rebooted, all seems fine now. Very sorry for this 

[bubbaQ]

FWIW, this one clobbered my cache drive that had a valid partition table, with multiple partitions, and replaced it with a single 64-aligned partition.

 

I tried to add a drive that was from 5.0beta4 and contained data, and it reported it as unformatted.  Booted back to 5.0Beta4 and that data drive was fine.

[dark_avenger]

Just upgraded from beta6, all drives came back MBR: unaligned no issues here.

[bubbaQ]

I get an "MBR: unknown" on my bench machine.  Partition table is as follows:

 

 

root@dev:~# sfdisk -luS /dev/sdb

Disk /dev/sdb: 48641 cylinders, 255 heads, 63 sectors/track
Warning: The partition table looks like it was made
  for C/H/S=*/1/0 (instead of 48641/255/63).
For this listing I'll assume that geometry.
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
/dev/sdb1            64 781422767  781422704  83  Linux
/dev/sdb2             0         -          0   0  Empty
/dev/sdb3             0         -          0   0  Empty
/dev/sdb4             0         -          0   0  Empty
root@dev:~#

[bubbaQ]

Seems that no matter how I try, I can not get unRAID to accept a cache disk with a partition table already on it.  I have the cache partition first, and another partition second.  But no matter what I do, unRAID nukes the partition table and replaces it.

 

Is this broken in 5.0-beta6a ... or is it gone?

[jamesbaker]

Did you use linux versions of fdisk or cfdisk?

I used cfdisk and am running beta6 without an issue.

 

Got a swap partiton on the cache drive and it mounts instantly

 

You also have to use mkreiserfs to format the first partiton on the cache drive, otherwise UNraid will blow it away.

 

Be sure to label the disks to make mounting easier.

mkreiserfs -l yourdisk /dev/hda1

mkswap -L yourdisk /dev/hda2

[bubbaQ]

Yup... tried with fdisk and cfdisk.... with a proper reiserfs.  No matter how I make it, the partition is "MBR: unknown"

 

[nxtiak]

Went from 5.0beta6 to 5.0beta6a.

Started the Array and it tells me my CACHE drive is unformatted. (it's empty, so I wasn't worried). The thing is, before when I did click on the disk, it said the Partition Type was unknown or some weird thing, so guess this will solve that.

 

Format on the Cache finished (500gig WD), it now says 4K-Aligned.

[limetech]

I get an "MBR: unknown" on my bench machine.  Partition table is as follows:

 

 

root@dev:~# sfdisk -luS /dev/sdb

Disk /dev/sdb: 48641 cylinders, 255 heads, 63 sectors/track
Warning: The partition table looks like it was made
  for C/H/S=*/1/0 (instead of 48641/255/63).
For this listing I'll assume that geometry.
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
/dev/sdb1            64 781422767  781422704  83  Linux
/dev/sdb2             0         -          0   0  Empty
/dev/sdb3             0         -          0   0  Empty
/dev/sdb4             0         -          0   0  Empty
root@dev:~#

 

This is what I'm looking for.  Please post output of these two command:

 

cat /sys/block/sdb/size

 

dd status=noxfer count=1 if=/dev/sdb | od -Ad -t x1

[limetech]

Seems that no matter how I try, I can not get unRAID to accept a cache disk with a partition table already on it.  I have the cache partition first, and another partition second.  But no matter what I do, unRAID nukes the partition table and replaces it.

 

Is this broken in 5.0-beta6a ... or is it gone?

 

Broken - I got a bit exuberant in reworking the MBR logic, sorry.

[limetech]

Went from 5.0beta6 to 5.0beta6a.

Started the Array and it tells me my CACHE drive is unformatted. (it's empty, so I wasn't worried). The thing is, before when I did click on the disk, it said the Partition Type was unknown or some weird thing, so guess this will solve that.

 

Format on the Cache finished (500gig WD), it now says 4K-Aligned.

 

From the announcement post:

 

"If you see case 5 MBR: unknown for any disk which has previously been used just fine in prior unRaid release, DO NOT START the array; instead, post your finding in this thread so that I can work with you to figure out why this is happening."

 

Since you formatted your Cache disk I have no way of knowing what's causing this problem in the first place.

 

Come on people - the idea of this beta series to get these dumb problems solved so I can move on to releasing new features.

[bubbaQ]

This is what I'm looking for.  Please post output of these two command:

 

cat /sys/block/sdb/size

 

dd status=noxfer count=1 if=/dev/sdb | od -Ad -t x1

 

As requested....

 

root@dev:~# sfdisk -luS /dev/sdb

Disk /dev/sdb: 48641 cylinders, 255 heads, 63 sectors/track
Warning: The partition table looks like it was made
  for C/H/S=*/1/63 (instead of 48641/255/63).
For this listing I'll assume that geometry.
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
/dev/sdb1            64 781422767  781422704  83  Linux
/dev/sdb2             0         -          0   0  Empty
/dev/sdb3             0         -          0   0  Empty
/dev/sdb4             0         -          0   0  Empty
root@dev:~# cat /sys/block/sdb/size
781422768
root@dev:~# dd status=noxfer count=1 if=/dev/sdb | od -Ad -t x1
1+0 records in
1+0 records out
0000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0000448 02 01 83 00 ff ff 40 00 00 00 70 90 93 2e 00 00
0000464 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
0000496 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa
0000512
root@dev:~#

 

The difference in the partition table is the 02 01 and ff ff starting at offset 448.

[bubbaQ]

If the MBR is unknown, perhaps change the background color of the pullown on the drive identification, to reinforce that the drive is not OK, and further alert the user to not start the array.

[prostuff1]

If the MBR is unknown, perhaps change the background color of the pullown on the drive identification, to reinforce that the drive is not OK, and further alert the user to not start the array.

 

And maybe taking it one step further would be to not allow them to start the array at all should a disk come up as MBR unknown.

 

That would at least force them to come back here and request help.