[solved] Bug 6.4.0-rc7a - New array won't format disks

Hello,

I got some new disks, and decided to start a new array, with the latest version of unraid. The new array consists of a brand new drive, and the parity disk of the old array.

The unraid USB consists of a copy of the files of the RC7a-installation zip with two changes. First, network.cfg was changed IP-address changed to a static IP address so the server can be accessed without dhcp, and the second is that an alternate network card was excluded in the syslinux.cfg by using an pci-stubs.ids option.

I proceeded to start up, logged in to unraid and added the new disk as partiy, and the old parity as first data disk, then started the array. It went to fill the parity while leaving the data disk as unmountable. I selecfed the option in unraid which said format disks, but it wouldn't do that. Then I waited untill the parity-writing was done, and after that selected the option to format the data disks and that I was sure. Again it failed, even though it should go on formatting.

I took a look at the logfiles, and noticed it said:

Aug 24 12:21:43 Tower emhttpd: mount error: No file system (32)

Aug 24 12:27:03 Tower root: mount: /mnt/disk1: wrong fs type, bad option, bad superblock on /dev/md1, missing codepage or helper program, or other error.
Aug 24 12:27:03 Tower emhttpd: mount error: No file system (32)

syslog

Update: My old array has an older file system, and since I'm building a new array, I decided to take advantage of the latest one. My array consists at this point of a parity drive, and a blank formatted drive that finally formatted after selecting a filesystem specifically for it in its options, instead of leaving it at default.

So, I took one of the old drives, and copied over all the files, then stopped the array and added the drive to it. The time: 8:29:03

I started the array, and it detected the new drive, and went on a parity-sync. Then it informed me the new drive wasn't formatted, and so, I selected 'yes I want to do this', and clicked format. This time, I got a lot of interesting error-messages.

After this, I waited a bit, selected 'yes I want to do this' and clicked format again. I am not insane (insanity is doing the same thing over and over and expecting different results) and as expected got pretty much the same results. After that, I stopped the array, went into the disk-options, and selected xfs as filesystem, which is also set as the default in the disk settings of the system settings in the settings.

Then, finally started the array again, selected 'yes, I want to do this' and clicked format. And, as expected, this time it did actually went to format the drive.

I've also done some digging through the logs, and it seems if you leave all disk-settings to default, it'll execute:

mkfs.xfs -m crc=1,finobt=1 -f /dev/

and if you do select a filesystem in the drive-options, it'll execute

mkfs.xfs -m crc=1,finobt=1 -f /dev/md2

So, this means it does read the settings correctly, it just does something funny after that.

Thanks for reading, and I hope this can get fixed!

tower-syslog-20170825-0852.zip

Update2:

It took me a while to copy files over from the 3rd disk, since somehow I don't understand split-levels entirely, and the documentation is completely unclear wether or not the root-directory is counted or not (the 0th level). Examples of which level a split happens would be really helpful but are nowhere to be found in the documentation.

Anyway, I decided to change something in my procedure. Normally, I add a drive to the server, mount it temporarily in the file-structure (for example at /tmp/drive) copy everything over to the array, then use wipefs to wife the filesysteminformation, use fdisk to remove the partition previous filesysem was one, then add it to the array.

Then unraid would read the parity-drive and rebuild the drive to empty status, and with the latest version, not format the drive automatically.

So, today I thought what would happen if I use wipefs on the entire drive, and first cleaned out the partition, and used wipefs on the drive. It made unraid behave differently, because there was less magic numbers on it, so unraid went clearing it instead of rebuilding it. The end-result was the same, a bit less wear on the parity-drive, but it still would not format the drive, and have the same mkfs behaviour where it would try to format /dev when filesystem set as default(xfs) and only after setting xfs would format /dev/md3. For the next drive, I inted to repeat the wipefs behaviour, add drive to array, clear it, and immediatly set xfs and see if it goes format immediatly without trying to format /dev first. Stay tuned...

Update3: As expected, stopping the array setting the drive to xfs, starting the array and selecting format did not try to format /dev but did format the proper device, today it was /dev/md4. Next I'll try setting the next drive to xfs and then back to default. My guess is that it'll again try to format /dev instead of then /dev/md5

Update4: Shocking news! My guess was wrong! It seems that if you add a drive to the array, clear it, and have the setting for filesystem as default, and then format it, it'll try to format the whole of /dev which fortunatly doesn't work, but if you stop the array before or after clearing, and set the filesystem to another setting and then back to default, it will format the proper device properly, and change the filesystem-setting for the drive from 'default' to whatever you set as default setting.

Now it'll be interesting to see what it does on a completely new array with blank drives, but that'll take a while because of having to move data and completely clear before adding, instead of after.

Update5: There is a newer unraid version available, but because of consistency, I first wanted to see what would happen with blank disks. So, I got a different computer, with two blank disks, and my other USB-device. Used the USB-creator to put the same version on it, and put my pro-key on it. Started the computer, logged in through my network to it, and added both 1TB drives to the array. Then started the array, and while unraid was doing the parity-thing, I told it to also format the data drive, which was set as filesystem to 'auto'. As expected, it tried to format /dev/ instead of /dev/sdb, so it has nothing to do with hardware or settings.

Lets see if the bug is fixed with the last unraid (rc8q as of writing).

Update6: I've made a new config in rc7a and updated unraid through the update OS function, and rebooted. Then I added the drives again and it went to do the parity-thing and made it format.  It worked! So, it seems to have been fixed. Yay!

Edited September 5, 20178 yr by Wody