Unable to access web ui, and shares not mounted to file system after reboot

@djevo1 asking other infos, can you provide this? :

psql -U rocky -d storageadmin -c "SELECT * FROM storageadmin_disk;" (pass always rocky)

Let me explain : shares require pools, pools require disks.
You can force a share delete (bot /home and /root although you don’t have them), you can delete a pool, but not rockstor default rockstor_rockstor pool…but you don’t have it!

My idea : probably we’re missing a check raising those WebUI errors, but being this related to a missing rockstor_rockstor pool I think you had a “freaky update” (ex. blocked/partially blocked during yum update over Rockstor package and others)

M.

 id | pool_id | name | size | offline | parted | btrfs_uuid | model | serial | transport | vendor | s
mart_available | smart_enabled | smart_options | role 
----+---------+------+------+---------+--------+------------+-------+--------+-----------+--------+--
---------------+---------------+---------------+------
(0 rows)

Hi @djevo1, your last post confirms my idea about a “broken system” :
you don’t have shares, you don’t have pools and you don’t have disks too

@suman & @phillxnet any idea about this? I don’t think this can not be because of a Rockstor update

Mirko

These problems have happened over and over even after a complete resintall.

@djevo1 Could you give some info about the nature of your install, ie did you select “Encrypt my data” during install (which can lead to no pools or shares) or do you have any ‘custom’ config that might be at the root cause of your apparently perpetual problems:

It might also be useful to know what the hardware arrangement is, ie do you use a flash drive for you system install and if so what is the model and size, and has the system disk hardware changed over time? Also have your tested your memory integrity etc? See our Pre-Install Best Practice (PBP).

Do you have a uefi install?

Just trying to get more context as the symptoms you described are indicative of multiple simultaneous issues but the known db update one is not known to actually stop the UI, which you also report. Hence investigating corruption causes (@Flyer’s “broken system”) with your report of repeated instances even after re-install leads me to seek other causes.

What is the output of for example:

btrfs fi show

and

btrfs fi usage /mnt2/rockstor_rockstor

and

ls -la /dev/disk/by-id/

Apologies if I’ve misread this thread but just trying to chip in.

Also note that we now have a 3.9.0.iso which circumvents the know intermittent update issues we saw half way through the 3.8 testing channel releases so do use this version if you end up reinstalling.

No UEFI install.
No encrypt my data
Standard install
Boot disk made from ISO, installed on a recommended sony flashdrive

BTRFS fi output

Label: 'rockstor_rockstor'  uuid: 713f423e-ed9d-4cfd-b8b1-fd76528e870e
    Total devices 1 FS bytes used 2.90GiB
    devid    1 size 6.04GiB used 5.51GiB path /dev/sdg3

Label: 'PrimaryR5'  uuid: 52ff3397-57dc-4dc0-b282-61d530fd515e
    Total devices 6 FS bytes used 2.39TiB
    devid    1 size 1.82TiB used 616.02GiB path /dev/sdb
    devid    2 size 1.82TiB used 616.02GiB path /dev/sdd
    devid    3 size 1.82TiB used 616.02GiB path /dev/sda
    devid    4 size 1.82TiB used 616.02GiB path /dev/sdf
    devid    5 size 1.82TiB used 616.02GiB path /dev/sde
    devid    6 size 1.82TiB used 616.02GiB path /dev/sdc

btrfs fi usage

Overall:
    Device size:           6.04GiB
    Device allocated:           5.51GiB
    Device unallocated:         534.00MiB
    Device missing:             0.00B
    Used:               2.97GiB
    Free (estimated):           2.56GiB    (min: 2.30GiB)
    Data ratio:                  1.00
    Metadata ratio:              1.97
    Global reserve:          16.00MiB    (used: 0.00B)

Data,single: Size:4.88GiB, Used:2.84GiB
   /dev/sdg3       4.88GiB

Metadata,single: Size:8.00MiB, Used:0.00B
   /dev/sdg3       8.00MiB

Metadata,DUP: Size:309.00MiB, Used:63.47MiB
   /dev/sdg3     618.00MiB

System,single: Size:4.00MiB, Used:0.00B
   /dev/sdg3       4.00MiB

System,DUP: Size:8.00MiB, Used:16.00KiB
   /dev/sdg3      16.00MiB

Unallocated:
   /dev/sdg3     534.00MiB

ls -la /dev/disk/by-id/

drwxr-xr-x 2 root root 360 Mar 23 08:17 .
drwxr-xr-x 6 root root 120 Mar 23 08:17 ..
lrwxrwxrwx 1 root root   9 Mar 23 08:17 ata-HGST_HDS724020ALE640_PK2111P6KR0REV -> ../../sdc
lrwxrwxrwx 1 root root   9 Mar 23 08:17 ata-Hitachi_HDS722020ALA330_JK1101BFH5BA2F -> ../../sde
lrwxrwxrwx 1 root root   9 Mar 23 08:17 ata-Hitachi_HDS722020ALA330_JK1105B8G5YXDX -> ../../sdb
lrwxrwxrwx 1 root root   9 Mar 23 08:17 ata-Hitachi_HDS722020ALA330_JK11A8BFHSVNSF -> ../../sdf
lrwxrwxrwx 1 root root   9 Mar 23 08:17 ata-Hitachi_HDS722020ALA330_JK11B1BFHTZRKF -> ../../sdd
lrwxrwxrwx 1 root root   9 Mar 23 08:17 ata-Hitachi_HDS722020ALA330_JK11B1BFHU3VHF -> ../../sda
lrwxrwxrwx 1 root root   9 Mar 23 08:17 usb-Sony_Storage_Media_7C071058A21AA21D64-0:0 -> ../../sdg
lrwxrwxrwx 1 root root  10 Mar 23 08:17 usb-Sony_Storage_Media_7C071058A21AA21D64-0:0-part1 -> ../../sdg1
lrwxrwxrwx 1 root root  10 Mar 23 08:17 usb-Sony_Storage_Media_7C071058A21AA21D64-0:0-part2 -> ../../sdg2
lrwxrwxrwx 1 root root  10 Mar 23 08:17 usb-Sony_Storage_Media_7C071058A21AA21D64-0:0-part3 -> ../../sdg3
lrwxrwxrwx 1 root root   9 Mar 23 08:17 wwn-0x5000cca222c2b628 -> ../../sdb
lrwxrwxrwx 1 root root   9 Mar 23 08:17 wwn-0x5000cca229d087df -> ../../sde
lrwxrwxrwx 1 root root   9 Mar 23 08:17 wwn-0x5000cca229d8f027 -> ../../sdf
lrwxrwxrwx 1 root root   9 Mar 23 08:17 wwn-0x5000cca229d973c2 -> ../../sdd
lrwxrwxrwx 1 root root   9 Mar 23 08:17 wwn-0x5000cca229d98340 -> ../../sda
lrwxrwxrwx 1 root root   9 Mar 23 08:17 wwn-0x5000cca22df44964 -> ../../sdc

@djevo1 Thanks that’s narrowed things down a tad and

I’m not aware of one actually.

If you could also answer the above questions it might help to narrow down / rule stuff out further?

Also we have had some reports of issues with the newer kernel:

More specificity would help but if this is down to a newer kernel causing instability on your particular hardware that would be another avenue of exploration. Not many reports of such but there have been some. Around this time I think there was a kernel update.

16gb sony flash drive, one recommend by unraid, freenas, centos etc. I haven’t tested memory integrity. I remember everything was running fine on I believe 3.7, after upgrading to 3.8 the issues began and seemed to be consistent.

processor    : 0
vendor_id    : AuthenticAMD
cpu family    : 16
model        : 10
model name    : AMD Phenom(tm) II X6 1100T Processor
stepping    : 0
microcode    : 0x10000dc
cpu MHz        : 800.000
cache size    : 512 KB
physical id    : 0
siblings    : 6
core id        : 0
cpu cores    : 6
apicid        : 0
initial apicid    : 0
fpu        : yes
fpu_exception    : yes
cpuid level    : 6
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter
bugs        : tlb_mmatch fxsave_leak sysret_ss_attrs null_seg
bogomips    : 6612.45
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate cpb

processor    : 1
vendor_id    : AuthenticAMD
cpu family    : 16
model        : 10
model name    : AMD Phenom(tm) II X6 1100T Processor
stepping    : 0
microcode    : 0x10000dc
cpu MHz        : 800.000
cache size    : 512 KB
physical id    : 0
siblings    : 6
core id        : 1
cpu cores    : 6
apicid        : 1
initial apicid    : 1
fpu        : yes
fpu_exception    : yes
cpuid level    : 6
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter
bugs        : tlb_mmatch fxsave_leak sysret_ss_attrs null_seg
bogomips    : 6613.05
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate cpb

processor    : 2
vendor_id    : AuthenticAMD
cpu family    : 16
model        : 10
model name    : AMD Phenom(tm) II X6 1100T Processor
stepping    : 0
microcode    : 0x10000dc
cpu MHz        : 800.000
cache size    : 512 KB
physical id    : 0
siblings    : 6
core id        : 2
cpu cores    : 6
apicid        : 2
initial apicid    : 2
fpu        : yes
fpu_exception    : yes
cpuid level    : 6
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter
bugs        : tlb_mmatch fxsave_leak sysret_ss_attrs null_seg
bogomips    : 6613.04
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate cpb

processor    : 3
vendor_id    : AuthenticAMD
cpu family    : 16
model        : 10
model name    : AMD Phenom(tm) II X6 1100T Processor
stepping    : 0
microcode    : 0x10000dc
cpu MHz        : 800.000
cache size    : 512 KB
physical id    : 0
siblings    : 6
core id        : 3
cpu cores    : 6
apicid        : 3
initial apicid    : 3
fpu        : yes
fpu_exception    : yes
cpuid level    : 6
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter
bugs        : tlb_mmatch fxsave_leak sysret_ss_attrs null_seg
bogomips    : 6613.06
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate cpb

processor    : 4
vendor_id    : AuthenticAMD
cpu family    : 16
model        : 10
model name    : AMD Phenom(tm) II X6 1100T Processor
stepping    : 0
microcode    : 0x10000dc
cpu MHz        : 800.000
cache size    : 512 KB
physical id    : 0
siblings    : 6
core id        : 4
cpu cores    : 6
apicid        : 4
initial apicid    : 4
fpu        : yes
fpu_exception    : yes
cpuid level    : 6
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter
bugs        : tlb_mmatch fxsave_leak sysret_ss_attrs null_seg
bogomips    : 6613.05
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate cpb

processor    : 5
vendor_id    : AuthenticAMD
cpu family    : 16
model        : 10
model name    : AMD Phenom(tm) II X6 1100T Processor
stepping    : 0
microcode    : 0x10000dc
cpu MHz        : 800.000
cache size    : 512 KB
physical id    : 0
siblings    : 6
core id        : 5
cpu cores    : 6
apicid        : 5
initial apicid    : 5
fpu        : yes
fpu_exception    : yes
cpuid level    : 6
wp        : yes
flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt cpb hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter
bugs        : tlb_mmatch fxsave_leak sysret_ss_attrs null_seg
bogomips    : 6613.04
TLB size    : 1024 4K pages
clflush size    : 64
cache_alignment    : 64
address sizes    : 48 bits physical, 48 bits virtual
power management: ts ttp tm stc 100mhzsteps hwpstate cpb

Let me know if you need anything else.

Any more ideas on how to resolve this issue.

@djevo1 Hello again. I was awaiting the answer to the following question:

I’ll assuming it hasn’t changed.

Given your repeated issues I’m guessing the problem may well lay there. Only a select few USB flash drives are up to hosting a non read only root file system such as all but FreeNAS (nanobsd) have in your quoted list (not sure of unRAID though):

Although the nature of btrfs does mitigate this some.

I suspect the recommendation you refer to is for use as the install media, not for use as the actual system disk (certainly in the case of CentOS). Anyway if it’s a common factor it is definitely worth a look as although Rockstor has made improvements to cut down on system disk writes it is not generally a good idea to use flash drives that don’t have proper wear levelling (unable to check as no model given) and reasonable performance. And, as there are some timing checks with Rockstor’s build in watchdog system, if the disk you are using is particularly slow you run the risk of timeouts and their consequent system failure. One artefact of this is a dead UI incidentally due to required initialisation code failing to complete in what is considered enough time for there not to have been a problem. Oh and an install won’t take hours but minutes which is nice.

The only USB device I use here as a Rockstor systsem disk is a Sandisk Extreme USB 3.0 although it is often on USB 2.0 ports.

What for example is the output of the following hdparm command on your system flash drive?

In the following we see a Rockstor system disk tested live on a usb 2.0 port (core 2 duo):

hdparm -tT /dev/disk/by-id/usb-SanDisk_Extreme_AA011217150507460372-0\:0

/dev/disk/by-id/usb-SanDisk_Extreme_AA011217150507460372-0:0:
 Timing cached reads:   3612 MB in  2.00 seconds = 1806.73 MB/sec
 Timing buffered disk reads: 104 MB in  3.04 seconds =  34.25 MB/sec

and on an Asus N3700-ITX board via USB 3.0 port and not as a system disk we have:

/dev/disk/by-id/usb-SanDisk_Extreme_AA011217150507460372-0:0:
 Timing cached reads:   2872 MB in  2.00 seconds = 1436.34 MB/sec
 Timing buffered disk reads: 566 MB in  3.00 seconds = 188.55 MB/sec

And in a much faster machine using a USB 3.0 port on an i5 Haswell (and not as a live root fs) we have:

/dev/disk/by-id/usb-SanDisk_Extreme_AA011217150507460372-0:0:
 Timing cached reads:   29856 MB in  2.00 seconds = 14944.18 MB/sec
 Timing buffered disk reads: 658 MB in  3.00 seconds = 219.17 MB/sec

So from your above by-id listing the command would be:

hdparm -tT /dev/disk/by-id/usb-Sony_Storage_Media_7C071058A21AA21D64-0:0

See how that test goes and definitely consider using something other than a generic usb flash drive as the system disk. The performance and stability will be heaps better.

Hope that helps.

Here is the output of HDparm
/dev/disk/by-id/usb-Sony_Storage_Media_7C071058A21AA21D64-0:0:
Timing cached reads: 4862 MB in 2.00 seconds = 2431.85 MB/sec
Timing buffered disk reads: 30 MB in 3.02 seconds = 9.92 MB/sec

I wanted to provide an update on this. I got an ssd, made an install drive from the latest iso, installed sucessfully. When I reboot the machine the system starts no problem, however the web ui is not available. I first see that initrock is empty so I follow another forum post to run /opt/rockstor/bin/initrock I then get this. There appears to be something wrong.

2017-04-07 23:30:58,240: Supported kernel(/boot/vmlinuz-4.8.7-1.el7.elrepo.x86_64) is already the default
2017-04-07 23:30:58,330: /etc/rc.d/rc.local looks correct. Not updating.
2017-04-07 23:30:58,331: Checking for flash and Running flash optimizations if appropriate.
2017-04-07 23:30:59,241: Updating the timezone from the system
2017-04-07 23:30:59,242: system timezone = America/New_York
2017-04-07 23:30:59,244: Updating sshd_config
2017-04-07 23:30:59,247: sshd_config already has the updates. Leaving it unchanged.
2017-04-07 23:30:59,247: Please be patient. This script could take a few minutes
2017-04-07 23:30:59,391: initializing Postgresql...
2017-04-07 23:31:01,255: Done.
2017-04-07 23:31:02,500: Creating app databases...
2017-04-07 23:31:04,465: Done
2017-04-07 23:31:04,465: Initializing app databases...
Traceback (most recent call last):
  File "/opt/rockstor/bin/initrock", line 45, in <module>
    sys.exit(scripts.initrock.main())
  File "/opt/rockstor/src/rockstor/scripts/initrock.py", line 383, in main
    run_command(['su', '-', 'postgres', '-c', "psql storageadmin -f %s/conf/storageadmin.sql.in" % BASE_DIR])  # noqa E501
  File "/opt/rockstor/src/rockstor/system/osi.py", line 110, in run_command
    raise CommandException(cmd, out, err, rc)
system.exceptions.CommandException: Error running a command. cmd = su - postgres -c psql storageadmin -f /opt/rockstor//conf/storageadmin.sql.in. rc = 2. stdout = ['SET', 'SET', 'SET', 'SET', 'SET', 'CREATE EXTENSION', 'COMMENT', 'SET', 'SET', 'SET', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', 'CREATE TABLE', 'ALTER TABLE', 'CREATE SEQUENCE', 'ALTER TABLE', 'ALTER SEQUENCE', '']. stderr = ['psql:/opt/rockstor/conf/storageadmin.sql.in:1134: WARNING:  terminating connection because of crash of another server process', 'DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.', 'HINT:  In a moment you should be able to reconnect to the database and repeat your command.', 'psql:/opt/rockstor/conf/storageadmin.sql.in:1134: server closed the connection unexpectedly', '\tThis probably means the server terminated abnormally', '\tbefore or while processing the request.', 'psql:/opt/rockstor/conf/storageadmin.sql.in:1134: connection to server was lost', '']

Take a look below from a fresh install on an ssd

@djevo1 Well done for persevering and thanks for the update.

Note that directly after install, where you then reboot, the first Rockstor boot may take a couple of minutes after the console reaches the login point before the whole system is then ready to work. In other words the WebUI will not be available for a couple of minute after the boot appears to have finished. If you then interfere with this process by enacting the initrock trick you may end up with 2 processes attempting to do the initialization (time consuming) setup of the db. You quoted error would seem to indicate that is what happened.

... 'terminating connection because of crash of another server process', 'DETAIL:  The postmaster has commanded 
this server process to roll back the current transaction and exit, because another server process exited abnormally 
and possibly corrupted shared memory.

This is a guess mind you. So do be patient expecially on the first boot. Interferring with the initrock process while it’s in the process of starting will have undetermined consequences. To me it seems like that is what happened here.

Let us know if this timing info is relevant in your case?

The times between the console message changing from no ip to containing the message with the IP in, has varied on my test hardware here from < 1 min to 3m 50 seconds (on an ancient Dell Dimension 3100C Celeron 2.8GHz single core). In these test I repeatedly pressed the enter key to invoke a console message update to time when the console message was updated with the IP. At that point or very soon there after the Web-UI should be accessible.

Hope that helps.

Also make sure you don’t inadvertently have selinux enabled (I suspect this can happen by default on uefi installs).

You last post:

Has nothing below it !

Please be assured that we do test install the iso images. Just not on all possible hardware or configurations.:slight_smile:

Hope you enjoyed the much faster install on the ssd by the way. Must have taken ages to install on that slow USB key.

I am also assuming this machine meets the min spec ram (2G free), seems likely given the CPU?

The install was actually about the same time. A few things I have noticed though. The initrock was done about 30 minutes after initial boot. I rebooted this morning and the system had the web ui running with no issues. I did noticed however that it is saying version 3.8.8 in the corner even though I downloaded the 3.9 ISO. I will probably do a reinstall again to ensure the process wasn’t interuppted.

@djevo1 Be aware that you may have inadvertently downgraded if you don’t first pick an update channel via the WebUI. Tricky I know if it doesn’t work straight off (but it does in our tests). Many command line admins will do immediate yum update etc, but the repos may not yet be appropriate for that if you have not first selected the update channel you fancy. Also if done directly upon first boot you may again interfere with the initialisation process.

I know we need better docs on this initial fragility. But it comes as a side effect of trying to be at least in part an independent package and upon first boot there is a tone of stuff that needs doing before things are properly installed (db mainly).

Agree you need to see a clean install and be advised that we are appliance based so anything done via the command line is obviously untested / unaccounted for. @Flyer is doing some great stuff on the package update system however so we should be much more transparent / user friendly on that front soon.

Do take note of whatever you do on your subsequent installs as that will help to pin down the problem. Essentially a default everything install (usually using DHCP) is your best bet as that is the most tested. You will not need to do the initrock trick as that will simply complicate things and is not necessary except in very specific circumstances.

Best to identify the problem before attempting fixes.

Install speed for me has varied massively depending on the medium holding the iso and of course the system disk speed. Cores also speed things up as does memory of course.

3.8.8 in top right after install is definitely a sign you have downgraded or don’t have the 3.9.0 iso.
also 3.8.8 is ages old.

Try doing nothing in the console on your next install and see how things go?

It is actually 3.8.16. I have it reinstalled now, and am attempting to add update channel, but need to wait until my activation code is reset.

When i installed the 3.9.0 iso it was also showing version 3.8.16 after first log in. Then updated via testing channel