# Which drive is the boot drive?



## priyadarshan (Mar 17, 2018)

On one server I have two identical Samsung 960 SSDs, with identical FreeBSD 11.1-Release install, showing up as `/dev/nvd0` and `/dev/nvd1`.

Beside somehow altering a drive's content, how does one know which is the boot drive?

I read The FreeBSD Booting Process, but I could not find a clue there.


----------



## ShelLuser (Mar 17, 2018)

That is probably impossible to tell. You can try checking the output of `gpart show` to verify the existence of a freebsd-boot type slice but if that is located on both drives then your only option is to check the system's BIOS settings. For that you could look into sysutils/dmidecode.


----------



## priyadarshan (Mar 17, 2018)

Thank you, I thought of checking with `gpart show`, but the output is identical


```
=>        40  1000215136  nvd0  GPT  (477G)
          40      409600     1  efi  (200M)
      409640        1024     2  freebsd-boot  (512K)
      410664         984        - free -  (492K)
      411648   136314880     3  freebsd-swap  (65G)
   136726528   863488000     4  freebsd-zfs  (412G)
  1000214528         648        - free -  (324K)

=>        40  1000215136  nvd1  GPT  (477G)
          40      409600     1  efi  (200M)
      409640        1024     2  freebsd-boot  (512K)
      410664         984        - free -  (492K)
      411648   136314880     3  freebsd-swap  (65G)
   136726528   863488000     4  freebsd-zfs  (412G)
  1000214528         648        - free -  (324K)
```

`dmidecode` does not seem to return useful information (not adding here as Forum software says it is too long):
https://gist.github.com/anonymous/8ac0df7bbda299b5bd46433211557d1a


----------



## k.jacker (Mar 17, 2018)

If you havn't changed any boot defaults in the UEFI/BIOS then the most probable is the first device in a series of ports of the same type, that's also the numbering FreeBSD applies to the drives (nvd0 in your case will be the M.2 drive in port 0). It's the only way to tell with ZFS to my knowledge. You can point the UEFI/BIOS to whatever drive in a pool (as long as all of them have bootcode installed) and it will read bootcode from that single drive, though FreeBSD will run on all drives in the pool after the booting stage of course.
As a side question.... why do you have EFI and legacy bootcode on your drives?


----------



## priyadarshan (Mar 17, 2018)

Thank you. Yes, I would know which drive is used if I manually boot from a specific one.

But what if the machine is already booted, and one needs to know which is the boot disk, being both disks identical, as hardware and content?

For example, right now, the server is booted from /dev/ndv1. But I cannot find any sysctl flag or other readable setting that reveals that.

Regarding EFI and legacy bootcode, I was actually wondering the same. At install time, the installer ZFS (auto) option presented that option (GPT+Legacy). A likely reason could be this, found here:



> Creating a freebsd-boot partition is not necessary, only the efi partition is needed to boot on a UEFI system. But the freebsd-boot partition does not take much space, and makes it possible to also boot the disk on a BIOS-based computer.


----------



## priyadarshan (Mar 19, 2018)

Today I tried booting with verbose flag on, but I could still not find a clue. As ShelLuser said, it seems it is impossible to tell.


----------



## mrclksr (Mar 20, 2018)

What about the gptids?
`# glabel status`


----------



## priyadarshan (Mar 21, 2018)

Thanks for the pointer.

I do not see a distinguishing flag in that output, though. The list is the same, no matter where I boot from:


```
root@fido:~ # glabel status
        Name  Status  Components
gpt/efiboot0     N/A  nvd0p1
msdosfs/EFI     N/A  nvd0p1
gpt/efiboot0     N/A  nvd1p1
msdosfs/EFI     N/A  nvd1p1
    gpt/boot     N/A  da0p1
  gpt/rootfs     N/A  da0p2
```


----------



## mrclksr (Mar 21, 2018)

Does `# gpart list` show rawtype or rawuuid?


----------



## ShelLuser (Mar 21, 2018)

mrclksr said:


> Does `# gpart list` show rawtype or rawuuid?


See his paste above, gpart won't be able to help here because both drives are pretty much identical. Labels also won't help (note: it might be better to use `gpart show -l` instead of glabel), for the simple reason that those usually get set up by the user (or process) who/which set up the slices after which they usually don't change anymore.

Once the system is booted then a Unix-like OS doesn't distinguish between drives anymore, only the main (root) directory is all which counts. And that can originate from pretty much everywhere if need be.


----------



## priyadarshan (Mar 21, 2018)

mrclksr said:


> Does `# gpart list` show rawtype or rawuuid?



Right now I am booting from nvd0. 

Please note that nvd1 is not exactly the same as nvd0 anymore, as I was experimenting with it.

Still, I do not see how to tell I am booting from nvd0:


```
root@fido:~ # gpart list
Geom name: nvd0
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 1000215175
first: 40
entries: 152
scheme: GPT
Providers:
1. Name: nvd0p1
   Mediasize: 209715200 (200M)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 20480
   Mode: r0w0e0
   rawuuid: b08af524-2b59-11e8-a1a8-107b4493e73f
   rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
   label: efiboot0
   length: 209715200
   offset: 20480
   type: efi
   index: 1
   end: 409639
   start: 40
2. Name: nvd0p2
   Mediasize: 2147483648 (2.0G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 210763776
   Mode: r1w1e0
   rawuuid: b090f3fb-2b59-11e8-a1a8-107b4493e73f
   rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
   label: swap0
   length: 2147483648
   offset: 210763776
   type: freebsd-swap
   index: 2
   end: 4605951
   start: 411648
3. Name: nvd0p3
   Mediasize: 509751590912 (475G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 2358247424
   Mode: r1w1e1
   rawuuid: b094da38-2b59-11e8-a1a8-107b4493e73f
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: zfs0
   length: 509751590912
   offset: 2358247424
   type: freebsd-zfs
   index: 3
   end: 1000214527
   start: 4605952
Consumers:
1. Name: nvd0
   Mediasize: 512110190592 (477G)
   Sectorsize: 512
   Mode: r2w2e3

Geom name: nvd1
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 1000215175
first: 40
entries: 152
scheme: GPT
Providers:
1. Name: nvd1p1
   Mediasize: 819200 (800K)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 20480
   Mode: r0w0e0
   rawuuid: 44f09781-072f-11e7-a6d0-24be05245205
   rawtype: c12a7328-f81f-11d2-ba4b-00a0c93ec93b
   label: efiboot0
   length: 819200
   offset: 20480
   type: efi
   index: 1
   end: 1639
   start: 40
2. Name: nvd1p2
   Mediasize: 524288 (512K)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 839680
   Mode: r0w0e0
   rawuuid: 44fa542b-072f-11e7-a6d0-24be05245205
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   label: gptboot0
   length: 524288
   offset: 839680
   type: freebsd-boot
   index: 2
   end: 2663
   start: 1640
3. Name: nvd1p3
   Mediasize: 17179869184 (16G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 2097152
   Mode: r0w0e0
   rawuuid: 4502ddcc-072f-11e7-a6d0-24be05245205
   rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
   label: swap0
   length: 17179869184
   offset: 2097152
   type: freebsd-swap
   index: 3
   end: 33558527
   start: 4096
4. Name: nvd1p4
   Mediasize: 494927872000 (461G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 2097152
   Mode: r0w0e0
   rawuuid: 45081070-072f-11e7-a6d0-24be05245205
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: zfs0
   length: 494927872000
   offset: 17181966336
   type: freebsd-zfs
   index: 4
   end: 1000214527
   start: 33558528
Consumers:
1. Name: nvd1
   Mediasize: 512110190592 (477G)
   Sectorsize: 512
   Mode: r0w0e0
```


----------



## priyadarshan (Mar 21, 2018)

ShelLuser said:


> Once the system is booted then a Unix-like OS doesn't distinguish between drives anymore, only the main (root) directory is all which counts. And that can originate from pretty much everywhere if need be.



Thanks ShelLuser. I wonder if at least it would be possible to tell _programmatically_.

I can imagine such a feature to be useful to programmers. If that would be the case, then I could write a script or c program to reveal the boot disk.


----------



## mrclksr (Mar 21, 2018)

ShelLuser said:


> See his paste above, gpart won't be able to help here because both drives are pretty much identical. Labels also won't help (note: it might be better to use `gpart show -l` instead of glabel), for the simple reason that those usually get set up by the user (or process) who/which set up the slices after which they usually don't change anymore.



I was interested in the gptid/rawuuid, not labels.



priyadarshan said:


> Still, I do not see how to tell I am booting from nvd0:


I was assuming:
If the system boots from nvdX, nvdXpY is mounted as root filesystem on /. So if partition no. Y of disk0 has the UUID uuid0, and partition no. Y of disk1 has the UUID uuid1, I can tell from which disk device the system was booted. Maybe I was assuming too much, or didn't understand the problem. Sorry for the noise.


----------



## priyadarshan (Mar 21, 2018)

mrclksr Thank _you_ for the constructive ideas.


----------



## phoenix (Mar 21, 2018)

mrclksr said:


> I was interested in the gptid/rawuuid, not labels.
> 
> I was assuming:
> 
> If the system boots from nvdX, nvdXpY is mounted as root filesystem on /. So if partition no. Y of disk0 has the UUID uuid0, and partition no. Y of disk1 has the UUID uuid1, I can tell from which disk device the system was booted. Maybe I was assuming too much, or didn't understand the problem. Sorry for the noise.



That assumes that you have two separate disks with separate filesystems on them, and only / from one of them was mounted.  Then you'll see which device it's being mounted from.  Of course, the disk you mount the root filesystem from doesn't always correspond to the disk you booted from (think GELI-encrypted ZFS with unencrypted /boot.  If you have a RAID array across the two disks, or a ZFS pool across the two disks, then / refers to data on *both* disks simultaneously; even though you only booted off one.

Once the BIOS has read the boot loader off a disk, and the loader has passed control over to the kernel, there's no way to know where the original boot blocks came from.  (AFAIK, anyway.)  The kernel doesn't care where it was loaded from, so it doesn't track it; it just tracks where the / filesystem is mounted from.  Which is why you need to make sure you install the boot blocks / loader onto *every* disk that you might boot from.  Especially when using some kind of RAID (whether hardware, software, or ZFS).

There's nothing worse than have a 2-disk array where disk 0 dies, and there's no boot blocks/loader on disk 1.    Yeah, been there, done that, didn't get a t-shirt.    Required some fancy typing from the loader prompt of an mfsBSD USB stick.  

If you're feeling masochistic, with fancy boot loaders like GRUB you can boot off disk 0, load a kernel off disk 1, and mount the root filesystem off disk 3.  Good luck figuring that out from just looking at the output of the mount command.    Or boot off a floppy, to load a kernel off an MMC disk, to mount the root filesystem off a ZFS pool.  Or load GRUB off the local disk, get a kernel off the network, and do even crazier things with filesystems from local and remote locations.  (Yes, these are all things we've done at work at one time or another.)


----------



## priyadarshan (Mar 22, 2018)

Thank you phoenix for the panorama of potential boot-issues. I hope I'll be able to grow at least a small part of your experience.


----------



## priyadarshan (Mar 23, 2018)

After much testing and based on phoenix's clarifications, I am ready to throw the towel on this.

I am left with a burning question though: how would it be possible to _programmatically_ know which is the boot drive?

Wouldn't be possible for a script to be executed at boot-time to `touch` a file in /tmp or elsewhere, so that, later, the mere existence of such file would reveal which is the boot disk?


----------



## ShelLuser (Mar 23, 2018)

priyadarshan said:


> I am left with a burning question though: how would it be possible to _programmatically_ know which is the boot drive?


It wouldn't. In some cases even the order in which the drives get detected can change.

The moment that you transfer control to the kernel is also the moment the system will forget all about this. The only thing the kernel would know is what device to access to mount the root system.

Basically only the boot manager / menu would be able to tell which was the actual boot drive.


----------



## priyadarshan (Mar 23, 2018)

Wow, I see. Even a small kernel-level patch would not be enough. This is illumining. Thank you.


----------



## priyadarshan (Jun 20, 2018)

Based on this, it seems same is true on Linux. On the other hand, macOS and Solaris/illumos seems to offer such introspection.


----------

