# /dev/gpt/efibootX on mirrored zfs root



## Geezer (May 17, 2022)

On two broadly similar machines, both with mirrored zfs root, one machine has been upgraded and the other I am holding off:

On the machine that I am happy with:
`freebsd-update -r 13.1-RELEASE upgrade`
`freebsd-update install` reboot `freebsd-update install`
`mount -t msdosfs /dev/gpt/efiboot0 /mnt`
`cp /boot/loader.efi /mnt/efi/boot/BOOTx64.efi`
`umount /mnt`
`mount -t msdosfs /dev/gpt/efiboot1 /mnt`
`cp /boot/loader.efi /mnt/efi/boot/BOOTx64.efi`
`umount /mnt`

All well, all up and running.


On the machine that I am holding off:
`ls -l /dev/gpt/`

```
crw-r-----  1 root  operator  0x7c May 17 14:38 efiboot1
```
But no efiboot0.

When I try to mount efiboot1
`mount -t msdosfs /dev/gpt/efiboot1 /mnt`

```
mount_msdosfs: /dev/gpt/efiboot1: Invalid argument
```

`gpart show`

```
=>       40  781422688  nvd0  GPT  (373G)
         40     532480     1  efi  (260M)
     532520       2008        - free -  (1.0M)
     534528  134217728     2  freebsd-swap  (64G)
  134752256  646670336     3  freebsd-zfs  (308G)
  781422592        136        - free -  (68K)

=>       40  781422688  nvd1  GPT  (373G)
         40     532480     1  efi  (260M)
     532520       2008        - free -  (1.0M)
     534528  134217728     2  freebsd-swap  (64G)
  134752256  646670336     3  freebsd-zfs  (308G)
  781422592        136        - free -  (68K)
```

`zpool status zoroot`

```
pool: zoroot
 state: ONLINE
  scan: scrub repaired 0B in 00:00:14 with 0 errors on Sat May  7 16:39:37 2022
config:

    NAME        STATE     READ WRITE CKSUM
    zoroot      ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        nvd0p3  ONLINE       0     0     0
        nvd1p3  ONLINE       0     0     0

errors: No known data errors
```

So I am holding off on upgrading, till I can find out what has happened to my [EXPLETIVE]effing[/EXPLETIVE] efi.

Any ideas?


----------



## SirDice (May 17, 2022)

Geezer said:


> But no efiboot0.


Forgot to label the partitions? Have you tried mounting the partition by it's name instead of a label?


----------



## Geezer (May 17, 2022)

SirDice said:


> Forgot to label the partitions?


Should that not have got done when I installed it?



SirDice said:


> Have you tried mounting the partition by it's name instead of a label?


`mount -t msdosfs /dev/nvd0p1 /mnt`
`mount_msdosfs: /dev/nvd0p1: Device busy`
`mount -t msdosfs /dev/nvd1p1 /mnt`
`mount_msdosfs: /dev/nvd1p1: Invalid argument`


----------



## SirDice (May 17, 2022)

Device busy usually means it's already mounted.


----------



## Geezer (May 17, 2022)

SirDice said:


> Device busy usually means it's already mounted.


`mount`
`/dev/nvd0p1 on /boot/efi (msdosfs, local)`

How right you are?

That sorts out efiboot0.  Why might efiboot1 not work?


----------



## SirDice (May 17, 2022)

Maybe it was never set up properly. If I recall correctly the installer only installed the EFI loader on the first disk and ignored the second. That should be fixed now but it means that second efi partition may not have been correctly set up.


----------



## Geezer (May 17, 2022)

Yes.


----------



## grahamperrin@ (May 24, 2022)

SirDice said:


> … If I recall correctly the installer only installed the EFI loader on the first disk and ignored the second. That should be fixed …



Thanks, I'm aware of what's pictured (below the line) for EFI boot entries, however (sorry) I can't figure out whether there's _also_ a fix for e.g.
bootx64.efi on multiple ESPs. 

<https://cgit.freebsd.org/src/log/?h=releng/13.1&qt=grep&q=loader> etc.













						bsdinstall: bootconfig: Try to clean old efi boot entries · freebsd/freebsd-src@477fbe6
					

If one install FreeBSD on the same machine multiple times in a row or on different harddrive they have a lot of 'FreeBSD' efi boot entries added. With this patch we now do : - If there is n...




					github.com


----------

