Middleware Error when running the Wizard for first time drive setup

[MattInMinneapolis]

Hello, I'm not sure where to post this question. I have the latest FreeNAS version installed on a custom built machine and it appears to be running fine as I can access the console via the IP. However, when I try and setup my three storage drives, I get a "Middleware Error". So then, I go to the "Wipe" button and try and wipe 1 of the drives and I get the same error. The drives were in my old Windows 10 machine as a File Server in RAID 5 and they worked just fine for my music and such. Also, I recently completely wiped them on a different machine due to the aforementioned error when I tried use the "Wipe" button in FreeNAS. Any insight would be greatly appreciated. Please see my machine specs in my Signature. Here is one of the errors when I use the Wizard:

Code:

Request Method:	POST
Request URL:	http://123.456.7.89/system/wizard/
Software Version:	FreeNAS-11.0-U2 (e417d8aa5)
Exception Type:	MiddlewareError
Exception Value:	
[MiddlewareError: b'Unable to GPT format the disk "ada0": gpart: geom \'ada0\': Operation not permitted\n']
Exception Location:	./freenasUI/middleware/notifier.py in __gpt_labeldisk, line 409
Server time:	Wed, 2 Aug 2017 06:31:15 -0500
Traceback


Environment:

Software Version: FreeNAS-11.0-U2 (e417d8aa5)
Request Method: POST
Request URL: http://123.456.7.89/system/wizard/


Traceback:
File "/usr/local/lib/python3.6/site-packages/django/core/handlers/exception.py" in inner
  39.			 response = get_response(request)
File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py" in _legacy_get_response
  249.			 response = self._get_response(request)
File "/usr/local/lib/python3.6/site-packages/django/core/handlers/base.py" in _get_response
  178.			 response = middleware_method(request, callback, callback_args, callback_kwargs)
File "./freenasUI/freeadmin/middleware.py" in process_view
  162.		 return login_required(view_func)(request, *view_args, **view_kwargs)
File "/usr/local/lib/python3.6/site-packages/django/contrib/auth/decorators.py" in _wrapped_view
  23.				 return view_func(request, *args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/django/views/generic/base.py" in view
  68.			 return self.dispatch(request, *args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/formtools/wizard/views.py" in dispatch
  237.		 response = super(WizardView, self).dispatch(request, *args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/django/views/generic/base.py" in dispatch
  88.		 return handler(request, *args, **kwargs)
File "/usr/local/lib/python3.6/site-packages/formtools/wizard/views.py" in post
  300.				 return self.render_done(form, **kwargs)
File "/usr/local/lib/python3.6/site-packages/formtools/wizard/views.py" in render_done
  357.								   **kwargs)
File "./freenasUI/system/forms.py" in done
  468.						 init_rand=False,
File "./freenasUI/middleware/notifier.py" in init
  238.			 f(objectid, *args, **kwargs)
File "./freenasUI/middleware/notifier.py" in _init_volume
  1057.		 self.__create_zfs_volume(volume, swapsize, kwargs.pop('groups', False), kwargs.pop('path', None), init_rand=kwargs.pop('init_rand', False))
File "./freenasUI/middleware/notifier.py" in __create_zfs_volume
  802.			 vdevs = self.__prepare_zfs_vdev(vgrp['disks'], vdev_swapsize, encrypt, volume)
File "./freenasUI/middleware/notifier.py" in __prepare_zfs_vdev
  738.								  swapsize=swapsize)
File "./freenasUI/middleware/notifier.py" in __gpt_labeldisk
  409.				 raise MiddlewareError(f'Unable to GPT format the disk "{devname}": {error}')

Exception Type: MiddlewareError at /system/wizard/
Exception Value: [MiddlewareError: b'Unable to GPT format the disk "ada0": gpart: geom \'ada0\': Operation not permitted\n']



Request information

GET

No GET data
POST

Variable	Value
initial_wizard-current_step	'confirm'
__form_id	'dijit_form_Form_5'
FILES

No FILES data
COOKIES

Variable	Value
fntreeSaveStateCookie	'root%2Croot%2F38%2Croot%2F53%2Croot%2F53%2F54'
csrftoken	'eLqQZih8PKdMh5rvOpOuzDqHEfGM5E3r7AMK2Y1i0exhjM4KYRM1uAuR9hWsY8uW'
sessionid	'id8up5ry6swpux6cg9f86si7yabh37rr'
META

Variable	Value

 

[Redcoat]

Welcome to the forum.
This post has some detailed help from a couple of the moderators here on this issue.
Search is your friend here (and on Google ...) - look for Unable to GPT format the disk "ada0": gpart: geom \'ada0\': Operation not permitted.
Good luck - @Spearfoot and @wblock are here very often so surely will be able to help with followup.

 

[wblock]

My first guess is that the old drives were using motherboard RAID. Is that correct?

 

[MattInMinneapolis]

Correct. I set up the RAID 5 via my old AMD motherboard.

 

[wblock]

If you still have the old motherboard, reconnect the drives and use the BIOS to destroy the RAID array. The problem is that RAID metadata is left on the disks. FreeNAS sees this, even when not using the original motherboard.

There several ways to delete that metadata. Most are a hassle.

 

[Evertb1]

If you still have the old motherboard, reconnect the drives and use the BIOS to destroy the RAID array. The problem is that RAID metadata is left on the disks. FreeNAS sees this, even when not using the original motherboard.

There several ways to delete that metadata. Most are a hassle.

I always use some bootable tools disk/usb (like Gandalfs Windows 10PE) to clean up drives. I use tools like Active@ Partion Manager or AOMEI partition assistant professional. I always assumed that removing al the partitions and resetting the MBR or GPT would clean up the disk sufficiently. I take it hat is not the case? I never used a hardware raid so I have not experienced this troubles yet.

 

[wblock]

Motherboard RAID ("fakeRAID") uses a small part of each disk to hold metadata. This data is not accessible to anything but the disk controller, and does not even appear. The disk appears to have a bit less space. Normal disk partitioning tools can't do anything about this, or even see that the space is in use. The controller hides it from them. So tools that are aware of how to deal with it are required. The BIOS menus are one way, but that only works if done on the original motherboard or a compatible one. FreeBSD and FreeNAS have a "graid" module that can deal with that metadata. It's somewhat unusual in that it recognizes that metadata even when the disks are not on a motherboard with that type of motherboard RAID.

Note that motherboard RAID is not "hardware" RAID. There is no separate controller hardware, it's just normal disk ports. The difference is that the motherboard is capable of recognizing and booting from a defined array of disks.

Connecting the disk to something that does not have a compatible motherboard RAID and wiping the whole thing, or at least the first and last megabyte, should erase that problem metadata. Then take the oath to never, ever use motherboard RAID ever again. Ever.

 

[Evertb1]

Then take the oath to never, ever use motherboard RAID ever again. Ever.

That one I decided long ago. I did not fancy to have my motherboard die on me and then not being able to buy one with the same raid "controller" with as result a lost raid array. Warnings like that were published in computer magazines as long as I can remember. But those warnings were always about loosing the raid (and thus the data) and not about making it hard to utilize the disks for normal use again. I never spent a thought about it but it's kind of brutal that you can "ruin" a couple of disks this way. I mean, motherboard raid is kind of consumer level but you can hardly expect that every consumer can handle that problem. I call it hardware raid but I realize that is not correct. I do know the difference.