Thanks to forum member kingwavy in the following form thread for highlighting th…is bug. On initial inspection of the reported data, drive names of the form sdab, sdac, when the same system has a system drive of the more common sda# type name, are being incorrectly identified as system drives. This is currently thought to be the trigger for an incompatible serial=none response from scan_disks() that is then surfaced by scan_disks() caller _update_disk_state():
```
File “/opt/rockstor/src/rockstor/storageadmin/views/disk.py”, line 342, in _update_disk_state
if (re.match(‘fake-serial-’, do.serial) is not None) or (
File “/usr/lib64/python2.7/re.py”, line 137, in match
return _compile(pattern, flags).match(string)
TypeError: expected string or buffer
```
With kingwavy's assistance the incorrect labelling of root was identified via debug logging thus:
```
m = Disk(name='sdaf', model='PERC H710', serial='fake-serial-0b606a7b-c7fa-4cf0-9e7a-c8dcc70d4034', size=976748544, transport=None, vendor='DELL', hctl='0:2:0:0', type='disk', fstype='btrfs', label='SCRATCH', uuid='a90e6787-1c45-46d6-a2ba-41017a17c1d5', parted=False, root=True, partitions={})
[14/May/2018 13:21:21] DEBUG [system.osi:478] disks item = Disk(name='sdag', model=None, serial='fake-serial-2a01338a-d494-40ef-80d9-ba2888bfde5f', size=976748544, transport=None, vendor=None, hctl=None, type='disk', fstype='btrfs', label='SCRATCH', uuid='a90e6787-1c45-46d6-a2ba-41017a17c1d5', parted=False, root=True, partitions={})
[14/May/2018 13:21:21] DEBUG [system.osi:478] disks item = Disk(name='sdae', model=None, serial='fake-serial-288f98c5-e108-4ca4-b1e0-fd4a791e7ea5', size=234461593, transport=None, vendor=None, hctl=None, type='disk', fstype='btrfs', label='INTEL_SSD', uuid='a504bf03-0299-4648-8a95-c91aba291de8', parted=False, root=True, partitions={})
```
ie multiple additional "root=True" attributions and a suspected consequent erroneous 'fake-serial-...' attribution: ie relevant lsblk:
NAME="sdae" MODEL="INTEL SSDSC2KW24" SERIAL="CVLT6153072G240CGN" SIZE="223.6G" TRAN="sas" VENDOR="ATA " HCTL="1:0:17:0" TYPE="disk" FSTYPE="btrfs" LABEL="INTEL_SSD" UUID="a504bf03-0299-4648-8a95-c91aba291de8"
However the system drive in this trigger system is still identified correctly:
```
[14/May/2018 13:21:21] DEBUG [system.osi:478] disks item = Disk(name='sda3', model='PERC H710', serial='6848f690e936450018b7c3a11330997b', size=277558067, transport=None, vendor='DELL', hctl='0:2:0:0', type='part', fstype='btrfs', label='rockstor_rockstor', uuid='7f7acdd7-493e-4bb5-b801-b7b7dc289535', parted=True, root=True, partitions={})
```
It is noteworthy that the 'sdab' drive (presumably list order related) is the victim of _update_disk_state() bug with "serial=none":
```
[14/May/2018 13:21:21] DEBUG [system.osi:478] disks item = Disk(name='sdab', model=None, serial=None, size=976748544, transport=None, vendor=None, hctl=None, type='disk', fstype='btrfs', label='SCRATCH', uuid='a90e6787-1c45-46d6-a2ba-41017a17c1d5', parted=False, root=True, partitions={})
```
when the serial is again plainly available (via default and initial lsblk call):
```
NAME="sdab" MODEL="ST91000640SS " SERIAL="5000c50063041947" SIZE="931.5G" TRAN="sas" VENDOR="SEAGATE " HCTL="1:0:14:0" TYPE="disk" FSTYPE="btrfs" LABEL="SCRATCH" UUID="a90e6787-1c45-46d6-a2ba-41017a17c1d5"
```
Also tangentially relevant is root_disk()'s inflexibility re matching only sda and not sdab type drive names, though this is not currently thought to be a trigger in this issue.
Please reference / update the following forum thread with this issues progress / resolution:
https://forum.rockstor.com/t/disk-scan-errors-expected-string-or-buffer/4783
.