format(1m) is an application, not kernel source. Therefore, finding where it is crashing is trivial.
#dbx /usr/sbin/format >run -e (select large drive) >where The issue is that it crashes from a SEGV instead of doing something sensible. The version on Solaris 10 u8 is *very* old. But if a label has been put on the drive already it will happily handle drives over 2 TB in the u8 single user install media shell. You get a choice of writing an MBR or EFI label. The former won't allow access to the full drive, but the EFI label will. I reported the OI version of format(1m) crashing a *very* long time ago. I found a note I made about this problem in oi151_a7 8 or 9 years ago. I had similar fun with a 3 TB USB drive. I set up my Ultra 20 to build OI and did a build, but when I asked on the dev lists for guidance in making the new build boot I got no response. As easy a fix as the format SEGV is I was quite happy to do that as well as address some of the other large drive related issues. There are a number of complications with regard to sector size, total number of sectors, etc. I've been using a 3 TB SATA on Solaris 10 u8 for 10 years. The first one had 512 byte sectors. When it failed the replacement had 2k sectors. That was its own little adventure, but I got it working and later added a 2nd 3 TB drive to form a mirror. If someone doing support work on OI does not have a >2 TB bare drive with which to test whether the bug in format(1m) is actually fixed in a more recent release, they are not capable of testing a fix. There is nothing magical about 5 TB. It's what I had on hand. With my most important system down, doing an update on my internet access host is a complete non-starter. Especially when my router is not working. I bought a new one and will address the issues I was having with my WRT54GL and DD-WRT at some other time. As it happens, with the confirmation from Toomas about installing grub I decided to skip making a backup before repairing grub. I've been planning to update my Hipster instance, but not without having an alternative means of internet access available. Reg On Sunday, February 21, 2021, 07:37:15 PM CST, Richard L. Hamilton <rlha...@smart.net> wrote: I'm not an OS developer (although I have read a fair bit of Solaris etc source over the years, and have written a kernel module or two for my own amusement). That said, if you have a core file, pstack core_file (whatever the core file's name is) will give a backtrace, which might (although with a SEGV, it might not, too) provide SOME clue what's happening. I don't know where that specific size limit comes in. Typically, the limit for a bootable partition in Solaris is 2TB (1TB on older systems, even lower on ancient ones). EFI labels/partitions will likely support larger disks than VTOC (SPARC) or fdisk (x86/64) label. I don't know whether OpenIndiana has the same limits. People that know this stuff well enough that for any given problem you might have, can say "that's fixed in version such-and-such", or "here's a workaround" are rare enough even for systems that have big commercial support. OpenIndiana/Illumos may have SMALL commercial support, but it's also mostly a SMALL number of volunteers. It's a bit much to expect that any of them would have a 5TB disk on hand to try and re-create your problem (let alone have a saved install of the old version you're running), and finding it by inspecting code wouldn't be quick either. That says nothing about the future of anything, save that support options are obviously limited, particularly if you're not paying someone for priority service. _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
