[OpenIndiana-discuss] OI 2020.10 install disk FAIL #2 !!!

[Reginald Beardsley]

 Toomas,

Thank you. That was quite helpful. "format -e" does indeed work in the live desktop environment once one does a sudo /bin/su. At the time I got the SEGV on 2017.10 I was primarily focused on recovering my Solaris 10 u8 instance. As I had successfully scrubbed the 3 pools in single user mode I wanted to back them up before repairing grub. In the end with your confirmation of the installgrub operation I simply did it and all is well. That system has a 3 TB 2 disk mirror scratch pool in addition to the 3 disk s0/s1 root and export pools.

I have run a 3 or 4 way mirror on s0 and a RAIDZ1 (2x 3 disk systems) or RAIDZ2 (1x 4 disk system) pool for /export for around 8 years. The systems currently run Solaris 10 u8, oi151_a7 and Hipster 2017.10. The oi151_a7 is the RAIDZ2 system, but heat limitations in the small space I have them in has resulted in it not being used in practice.

Some systems have identical disks for the pools and some do not. By sizing the slices properly I have had no issues at all. And the fact that I was able to completely recover my u8 instance when all the pools were corrupted is strong testimony that it is very robust even if grub is not installed on the one drive in the mirror that doesn't show errors. I think I have now corrected that but have no desire to test it. Concurrent with the u8 fault I had a router running DD-WRT fail so I was hopping.

I agree that configurations such as mine do require expertise and care, but I don't think it can be called "bad practice". The 4 way rpool mirror in the s0 slice of my NL40 is certainly far more robust than having rpool on a single flash drive as was suggested generally when I built the RAIDZ2 on the NL40. I tested that when it was built by pulling 2 disks and it recovered perfectly, albeit slowly. I should note that I have only used 2 TB disks for the s0/s1 arrangement. The EFI label might not support that even though it should. I shall test that in the process of upgrading from Hipster 2017.10.

On the 2020.10 live desktop gparted dumps core in jack's home directory. Unfortunately dbx running on 2017.10 doesn't see it as an ELF file though file(1) does. Thus far I have not been able to get a working copy of gdb to determine where it fails.

My attempt to install gdb via pkg on 2017.10 resulted in this:

rhb at Hipster:/app/pkgs# pkg install gdb
Creating Plan (Solver setup): /
pkg install: No matching version of developer/debug/gdb can be installed:
 Reject: pkg://openindiana.org/developer/debug/gdb@7.10.1-2020.0.1.6
 Reason: This version is excluded by installed incorporation consolidation/userland/userland-incorporation at 0.5.11-2017.0.0.9657
rhb at Hipster:/app/pkgs# find /usr -name gdb
/usr/share/glib-2.0/gdb
/usr/share/gdb
rhb at Hipster:/app/pkgs# 

FWIW The /app/pkgs tree is where I build 3rd party software from source. Unfortunately, gdb 10.1 failed to build as did 9.2. It's a fairly elaborate system that allows me to toggle links in /app/{bin,lib} to select particular versions each of which is in /app/pkgs/<name>/<version>/{bin,lib,man,src} etc. I have found the ability to seamlessly fallback to a different version invaluable. Shell scripts create or remove symlinks as needed and allows complete control over what software versions are selected in PATH. 

With an EFI label on the 5 TB disk, I shall see if the text install will allow me to create the mirror and RAIDZ configuration.

Best regards,
Reg