Reinstall to latest Rockstor fails to import pools

Brief description of the problem

I have created an installer with the latest 15.6/5.0.15-0 ISO. Having used the installer, although Rockstor loadss and I have access to the web interface, an attempt to import the pools fails with the attached log/message.

Detailed step by step instructions to reproduce the problem

Create Installer from 15.6/5.0.15-0 ISO
Run installer to overwrite previous boot disc.
Run new installation
Go through initialisation
Log in to web interface
Create user etc
Get Discs screen
Click on small arrow to import pools etc
Fail

Web-UI screenshot

Error Traceback provided on the Web-UI

        Traceback (most recent call last):

File “/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/backends/utils.py”, line 89, in _execute
return self.cursor.execute(sql, params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/rockstor/.venv/lib/python3.11/site-packages/psycopg/cursor.py”, line 97, in execute
raise ex.with_traceback(None)
psycopg.errors.DeadlockDetected: deadlock detected
DETAIL: Process 16696 waits for ShareLock on transaction 671; blocked by process 16807.
Process 16807 waits for ShareLock on transaction 669; blocked by process 16696.
HINT: See server log for query details.
CONTEXT: while updating tuple (0,24) in relation “storageadmin_disk”

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
File “/opt/rockstor/src/rockstor/storageadmin/views/disk.py”, line 790, in _btrfs_disk_import
do.save()
File “/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/models/base.py”, line 814, in save
self.save_base(
File “/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/models/base.py”, line 877, in save_base
updated = self._save_table(
^^^^^^^^^^^^^^^^^
File “/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/models/base.py”, line 990, in _save_table
updated = self._do_update(
^^^^^^^^^^^^^^^^
File “/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/models/base.py”, line 1054, in _do_update
return filtered._update(values) > 0
^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/models/query.py”, line 1231, in _update
return query.get_compiler(self.db).execute_sql(CURSOR)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/models/sql/compiler.py”, line 1984, in execute_sql
cursor = super().execute_sql(result_type)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/models/sql/compiler.py”, line 1562, in execute_sql
cursor.execute(sql, params)
File “/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/backends/utils.py”, line 67, in execute
return self._execute_with_wrappers(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/backends/utils.py”, line 80, in _execute_with_wrappers
return executor(sql, params, many, context)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/backends/utils.py”, line 84, in _execute
with self.db.wrap_database_errors:
File “/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/utils.py”, line 91, in exit
raise dj_exc_value.with_traceback(traceback) from exc_value
File “/opt/rockstor/.venv/lib/python3.11/site-packages/django/db/backends/utils.py”, line 89, in _execute
return self.cursor.execute(sql, params)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/rockstor/.venv/lib/python3.11/site-packages/psycopg/cursor.py”, line 97, in execute
raise ex.with_traceback(None)
django.db.utils.OperationalError: deadlock detected
DETAIL: Process 16696 waits for ShareLock on transaction 671; blocked by process 16807.
Process 16807 waits for ShareLock on transaction 669; blocked by process 16696.
HINT: See server log for query details.
CONTEXT: while updating tuple (0,24) in relation “storageadmin_disk”

Clicking the small downward arrow on another disc (the smallest and I suspect the lowest numbered one {SDA?}) worked and the pools appeared. After reinstating the config and then exporting the pools the system is now running and I can access the shares.

Perhaps the little arrow should not appear on all drives?

1 Like

Good question. You should be able to import from “any” disk that’s part of a pool (hence the arrows on every disk). But, I think there have been instances similar to yours where it worked only on a specific disk that’s part of the pool… but I do remember I’ve been able to do it in the past using the “highest” (e.g. /dev/sdf) device in the pool as well as the “lowest” (like your above mentioned /dev/sda/)

Here is a list of mount points on the system:

mount | grep /dev/sd
/dev/sde4 on / type btrfs (rw,noatime,space_cache,subvolid=258,subvol=/@/.snapshots/1/snapshot)
/dev/sde4 on /.snapshots type btrfs (rw,noatime,space_cache,subvolid=257,subvol=/@/.snapshots)
/dev/sde4 on /boot/grub2/i386-pc type btrfs (rw,noatime,space_cache,subvolid=266,subvol=/@/boot/grub2/i386-pc)
/dev/sde4 on /boot/grub2/x86_64-efi type btrfs (rw,noatime,space_cache,subvolid=267,subvol=/@/boot/grub2/x86_64-efi)
/dev/sde2 on /boot/efi type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/sde4 on /home type btrfs (rw,noatime,space_cache,subvolid=259,subvol=/@/home)
/dev/sde4 on /opt type btrfs (rw,noatime,space_cache,subvolid=260,subvol=/@/opt)
/dev/sde4 on /root type btrfs (rw,noatime,space_cache,subvolid=261,subvol=/@/root)
/dev/sde4 on /srv type btrfs (rw,noatime,space_cache,subvolid=262,subvol=/@/srv)
/dev/sde4 on /tmp type btrfs (rw,noatime,space_cache,subvolid=263,subvol=/@/tmp)
/dev/sde4 on /usr/local type btrfs (rw,noatime,space_cache,subvolid=265,subvol=/@/usr/local)
/dev/sde4 on /var type btrfs (rw,noatime,space_cache,subvolid=264,subvol=/@/var)
/dev/sda on /mnt2/fullPool type btrfs (rw,relatime,space_cache,subvolid=5,subvol=/)
/dev/sda on /mnt2/Music type btrfs (rw,relatime,space_cache,subvolid=258,subvol=/Music)
/dev/sda on /mnt2/Photos type btrfs (rw,relatime,space_cache,subvolid=331,subvol=/Photos)
/dev/sda on /mnt2/Videos type btrfs (rw,relatime,space_cache,subvolid=1290,subvol=/Videos)
/dev/sda on /mnt2/Backups type btrfs (rw,relatime,space_cache,subvolid=30425,subvol=/Backups)

As you can see only sda appears. Here is a list of block devices:

sblk -e 7,11                                                                                
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS                                                                    
sda      8:0    0 232.9G  0 disk /mnt2/Backups                                                                  
                                 /mnt2/Videos                                                                   
                                 /mnt2/Photos                                                                   
                                 /mnt2/Music                                                                    
                                 /mnt2/fullPool                                                                 
sdb      8:16   0   1.8T  0 disk                                                                                
sdc      8:32   0   1.8T  0 disk                                                                                
sdd      8:48   0   4.5T  0 disk                                                                                
sde      8:64   1  29.2G  0 disk                                                                                
├─sde1   8:65   1     2M  0 part                                                                                
├─sde2   8:66   1    64M  0 part /boot/efi                                                                      
├─sde3   8:67   1     2G  0 part [SWAP]                                                                         
└─sde4   8:68   1  27.2G  0 part /var                                                                           
                                 /usr/local                                                                     
                                 /tmp                                                                           
                                 /srv                                                                           
                                 /root                                                                          
                                 /opt                                                                           
                                 /home                                                                          
                                 /boot/grub2/x86_64-efi                                                         
                                 /boot/grub2/i386-pc                                                            
                                 /.snapshots                                                                    
                                 /                                                                              

The pool is made up from sda, sdb, sdc & sdd (sde is the boot disc). So it looks like sda is different. Is that because that is the device that the ‘restore pool’ worked on? Or because it’s the first disc in the list?

Yes, in this view all the shares show up on one of the devices.
In my case, all shares will look up on /dev/sdc (and my import after a rebuild was likely /dev/sdf) so I think that view is more related to how the pool was initially created.
But, yes, the pool should be successfully imported.

If you do:

lsblk -P -p -o NAME,LABEL,HCTL,FSTYPE

you will also see the “members” of your pool (the LABEL column)

with btrfs fi show will show you the various pool member devices

2 Likes