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@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@0.5.11-2017.0.0.9657
rhb@Hipster:/app/pkgs# find /usr -name gdb
/usr/share/glib-2.0/gdb
/usr/share/gdb
rhb@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
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
