2

On a test server there are two Samsung 960 Pro SSDs, exactly same maker, model and size. On both I've installed a fresh install of exactly the same OS, OmniOS r15026.

By pressing F8 at POST time, I can access the motherboard BOOT manager, and choose one of the two boot drives. Thus, I know which one the system booted from.

But how can one know programmatically, after boot, which is the boot disk?

It seems that is:

Does Solaris/illumos offer some introspective hooks to determine which is the boot disk?

Is it possible to programmatically determine which is the boot disk on Solaris/illumos?

A command line tool would be fine too.

Edit 1: Thanks to @andrew-henle, I have come to know command eeprom.

As expected it is available on illumos, but on test server with OmniOS unfortunately it doesn't return much:

root@omnios:~# eeprom
keyboard-layout=US-English
ata-dma-enabled=1
atapi-cd-dma-enabled=1
ttyd-rts-dtr-off=false
ttyd-ignore-cd=true
ttyc-rts-dtr-off=false
ttyc-ignore-cd=true
ttyb-rts-dtr-off=false
ttyb-ignore-cd=true
ttya-rts-dtr-off=false
ttya-ignore-cd=true
ttyd-mode=9600,8,n,1,-
ttyc-mode=9600,8,n,1,-
ttyb-mode=9600,8,n,1,-
ttya-mode=9600,8,n,1,-
lba-access-ok=1

root@omnios:~# eeprom boot-device
boot-device: data not available.

Solution on OmniOS r15026

Thanks to @abarczyk I was able to determine the correct boot disk.

I had to use a slightly different syntax:

root@omnios:~# /usr/sbin/prtconf -v | ggrep -1  bootpath
          value='unix'
      name='bootpath' type=string items=1
          value='/pci@38,0/pci1022,1453@1,1/pci144d,a801@0/blkdev@w0025385971B16535,0:b

With /usr/sbin/format, I was able to see entry corresponds to

  16. c1t0025385971B16535d0 <Samsung-SSD 960 PRO 512GB-2B6QCXP7-476.94GB>
      /pci@38,0/pci1022,1453@1,1/pci144d,a801@0/blkdev@w0025385971B16535,0

which is correct, as that is the disk I manually selected in BIOS.

Thank you very much to @abarczyk and @andrew-henle to consider this and offer instructive help.

gsl
  • 656
  • 1
  • 13
  • 22

3 Answers3

3

The best way to find the device from which the systems is booted is to check prtconf -vp output:

# /usr/sbin/prtconf -vp | grep bootpath
        bootpath:  '/pci@0,600000/pci@0/scsi@1/disk@0,0:a'
abarczyk
  • 46
  • 4
  • Thank you very much, this worked perfectly. On my test system, illumos/OmniOS r15026, I had to use the syntax `/usr/sbin/prtconf -v | ggrep -1 bootpath`, showing on line next to "bootpath" entry, `value='/pci@38,0/pci1022,1453@1,1/pci144d,a801@0/blkdev@w0025385971B16535,0:b'`. With `format`, I can then see that entry corresponds to `c1t0025385971B16535d0 `, which is correct, as that is the disk I manually selected in BIOS. – gsl Jun 20 '18 at 09:52
2

On my Solaris 11.4 Beta system, there is a very useful command called devprop which helps answer your question:

$ devprop -s bootpath
/pci@0,0/pci1849,8c02@1f,2/disk@1,0:b

then you just have to look through the output of format to see what that translates to. On my system, that is 

       9. c2t1d0 <ATA-ST1000DM003-1CH1-CC47-931.51GB>
      /pci@0,0/pci1849,8c02@1f,2/disk@1,0
James McPherson
  • 1,493
  • 7
  • 14
  • Thank you, it works on OmniOS too, `/sbin/devprop -s bootpath`, or, even better for me, `devprop diskdevid`. This answer is more elegant, as more succint than previous one, although `prtconf -v` is the device tree `devprop` looks at. – gsl Jun 28 '18 at 09:08
1

Use the eeprom command.

Per the eeprom man page:

Description

eeprom displays or changes the values of parameters in the EEPROM. It processes parameters in the order given. When processing a parameter accompanied by a value, eeprom makes the indicated alteration to the EEPROM; otherwise, it displays the parameter's value. When given no parameter specifiers, eeprom displays the values of all EEPROM parameters. A '−' (hyphen) flag specifies that parameters and values are to be read from the standard input (one parameter or parameter=value per line).

Only the super-user may alter the EEPROM contents.

eeprom verifies the EEPROM checksums and complains if they are incorrect.

platform-name is the name of the platform implementation and can be found using the –i option of uname(1).

SPARC

SPARC based systems implement firmware password protection with eeprom, using the security-mode, security-password and security-#badlogins properties.

x86

EEPROM storage is simulated using a file residing in the platform-specific boot area. The /boot/solaris/bootenv.rc file simulates EEPROM storage.

Because x86 based systems typically implement password protection in the system BIOS, there is no support for password protection in the eeprom program. While it is possible to set the security-mode, security-password and security-#badlogins properties on x86 based systems, these properties have no special meaning or behavior on x86 based systems.

Andrew Henle
  • 27,654
  • 3
  • 23
  • 49
  • Thank you for pointing out command `eeprom`. It is [available on illumos](https://illumos.org/man/1M/eeprom), but on my illumos (OmniOS) test server unfortunately does not return much. See edited question. – gsl Jun 14 '18 at 12:43
  • 1
    @gsl I don't have access to a Solaris server right now, so I can't check. But you may find something useful somewhere in `/boot`. You might have to parse the GRUB configuration files on an x86 box. Is it safe to assume that the `/` filesystem is on your boot disk? – Andrew Henle Jun 14 '18 at 13:31
  • Thank you, I am looking now at `/boot` to search for some useful information. Yes, the `/` filesystem is on the boot disk. I have edited question with `zfs list`. – gsl Jun 14 '18 at 13:53
  • I have pasted output of boot/loader.rc [here](https://pastebin.com/H80Q0329). But most of those settings are commented out. – gsl Jun 14 '18 at 14:00
  • 1
    @gsl From what I recall, you may have to to look under `/boot/grub`. There's probably a `menu.???` file in there that you can get the boot disk from, if you can figure out how to parse the entries. The problem becomes with how you define "boot disk". Is that where the bootloader is? Is that where your root filesystem is? The initial GRUB bootloader can be on one disk, which initially loads a Solaris kernel off a second disk, which then loads a root filesystem from a ZFS pool on one or more *other* disks. – Andrew Henle Jun 14 '18 at 14:51
  • Thank you for the directions. I have pasted [/boot/grub/menu.lst](https://pastebin.com/RcdkvHnE). But it does not have much clues. Also, I have further edited question, to add a use-case (2 exact same boot drives, with exact same fresh OS install), to clarify. – gsl Jun 14 '18 at 15:39