Solved Partitioning drives

V

VulcanRidr

This is the third (and hopefully final) post about adding an NVMe drive to my two lenovo mini-servers. (see here and here). So I installed the m.2 drives in both machines, and once I turned off the optane stuff in bios, the drives worked.

But now I have run into a sort of strange issue. Both machines are configured identically (i5-7500T CPU @ 2.70GHz, 32GB RAM, a 480GB SSD). Both were built initally on FreeBSD 14.0-RELEASE. But when I added the 500GB m.2 drive, I noticed that the SSD on one of them was partitioned as such:


Code: 
=>       40  937703008  ada0  GPT  (447G)
         40     532480     1  efi  (260M)
     532520       1024     2  freebsd-boot  (512K)
     533544        984        - free -  (492K)
     534528    4194304     3  freebsd-swap  (2.0G)
    4728832  932972544     4  freebsd-zfs  (445G)
  937701376       1672        - free -  (836K)

while the other looks like:

Code: 
=>       40  937703008  ada0  GPT  (447G)
         40     532480     1  efi  (260M)
     532520       2008        - free -  (1.0M)
     534528    4194304     2  freebsd-swap  (2.0G)
    4728832  932972544     3  freebsd-zfs  (445G)
  937701376       1672        - free -  (836K)

As far as I can tell, both are booting via efi, but one server has a freebsd-boot partition on ada0p2, and the other does not.

So my questions are thus:
  • If the system is booting via efi, is the freebsd-boot partition superfluous?
  • Should I make the (larger) m.2 drive match what is on the existing SSD?
  • If I create the m.2 drive with a freebsd-boot partition, since it is larger, will I be unable to delete the SSD and recreate it since it is smaller?
I am guessing that if the second box is booting correctly, then it probably really doesn't matter. I was just trying to figure out why the differences in the drives occurred that way since I built them back-to-back from the same image.

Thanks!
 
UEFI doesn't use the freebsd-boot partition. It only uses the efi partition. The freebsd-boot partition is used by legacy boot for a boot loader when booting off GPT.

I partitioned my rescue disks with an efi partition and a freebsd-boot partition, like your first example, allowing it to boot off my UEFI machines and legacy machines. My UEFI machines are partitioned like your second example. Except for the ability to boot in UEFI and legacy modes, the two schemes on the same disk are a waste of space.
 
Thank you, Cy! It makes me wonder if on one of them when I was setting up the ZFS in the installer I chose EFI+BIOS and on the other I chose EFI only...It's been a year since I built them, and I just don't remember...
 
VulcanRidr said:
Thank you, Cy! It makes me wonder if on one of them when I was setting up the ZFS in the installer I chose EFI+BIOS and on the other I chose EFI only...It's been a year since I built them, and I just don't remember...
Click to expand...

One more series of questions regarding booting...I just upgraded my desktop (today) to a Ryzen board and cpu. It has two on-board m.2 slots, so I bought 2 1tb NVMe drives, in theory to replace the two SATA SSDs that are currently in the boot pool.

So what is the best way to tell if the system is all EFI boot or BIOS boot. I know that it will EFI boot, because that is how I dual boot the system (FreeBSD and linux)...

So if I create the nda[01] with an efi slice, a swap slice, and a zfs slice, then zpool attach nda[01]p3 to the existing pool (one at a time), detach ada[01]p4 (I know I could do a replace on each drive as well), and then update efibootmgr to point to the NVMe drives, will this get me off of the SSDs in the right way?

Is there a way to see how a FreeBSD system in general is able to boot?
 
VulcanRidr said:
Thank you, Cy! It makes me wonder if on one of them when I was setting up the ZFS in the installer I chose EFI+BIOS and on the other I chose EFI only...It's been a year since I built them, and I just don't remember..
Click to expand...
This is precisely that.

To test your possibilities of boot, start by use my utility in show-me mode as root user.
https://github.com/Emrion/uploaders or just pkg install loaders-update if you are on the latest repository.

Post the output here.
 
VulcanRidr said:
So if I create the nda[01] with an efi slice, a swap slice, and a zfs slice, then zpool attach nda[01]p3 to
Click to expand...
Not directly related with your question itself though, you would be confusing the words slice and partition. This could confuse someone who want to answer your disk-related questions (especially when the one is in hurry).

In MBR era, the number of partitions are restricted to only upto 4. So, for example, [PC|MS]-DOS defined extended partition that can be logically partitioned into sub partitions.

Historically, OS'es derived from old Unix required more partitions than 4, so FreeBSD did the same thing with a bit different way, and as historically the word partition was used, the DOS extended partition like partition is called slice.

In contrast with it, GPT can provide (usually) sufficient number of partitions. So FreeBSD no longer has any reason to use slice to hold partitions in it.

But there still exists something like slice. Dummy partition in protective MBR (PMBR) which covers the whole bunch of the drive, to protect GPT pattitions from old (non-GPT-aware) partitioning tools by telling them that the whole disk is already in use.

Not technically correct, but if you'll now easily imagine the protective dummy partition as the only slice of the drive and all partitions are inside it.
 
VulcanRidr said:
So if I create the nda[01] with an efi slice, a swap slice, and a zfs slice, then zpool attach nda[01]p3 to the existing pool (one at a time), detach ada[01]p4 (I know I could do a replace on each drive as well), and then update efibootmgr to point to the NVMe drives, will this get me off of the SSDs in the right way?
Click to expand...
I can see that the thread has been solved already.

Just wanted to add my few cents here. EFI loader needs not to be on the drive you are booting from. Personally, I do put the EFI partition with loader on all the drives in the system, including the cache-only drive. These extra loaders can be considered as backups. BIOS finds the first loader and starts it. Loader then looks for bootable ZFS pool and boots it. In case where there is no drives with EFI partitions or loaders in it, one can even launch the loader from external USB stick and still boot the system.

So, the EFI boot is really flexible.
 
Argentum said:
I can see that the thread has been solved already.

Just wanted to add my few cents here. EFI loader needs not to be on the drive you are booting from. Personally, I do put the EFI partition with loader on all the drives in the system, including the cache-only drive. These extra loaders can be considered as backups. BIOS finds the first loader and starts it. Loader then looks for bootable ZFS pool and boots it. In case where there is no drives with EFI partitions or loaders in it, one can even launch the loader from external USB stick and still boot the system.

So, the EFI boot is really flexible.
Click to expand...
Just a FYI.
I myself am using patched boot1.efi to choose which pool/partition to boot from.
The patch is at PR 207940 and whichever the latest 2 patches (need to choose one, as the 2 variants differs just how the partitions/pools are shown).

The original author's (Naomichi Nonaka's) version shows them with raw UUID of them, and my variant shows them with interface-based.
You can see details on Comment 35 and Comment 46 there.

Note that these patch can boot FreeBSD only, as these looks for /boot/loader.efi in all pools/partitions available to choose candidates to boot from and kicks the one chosen (default: first found candidate from the drive the boot1.efi is loaded from, ZFS is preferred over UFS).
 
Emrion said:
This is precisely that.

To test your possibilities of boot, start by use my utility in show-me mode as root user.
https://github.com/Emrion/uploaders or just pkg install loaders-update if you are on the latest repository.

Post the output here.
Click to expand...
This is the output I got:

Code: 
sudo loaders-update show-me
loaders-update v1.0.1
show-me mode: it tells what it would do but changes nothing.

One or more efi partition(s) have been found.

mount -t msdosfs /dev/ada1p1 /mnt
Would run: cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi
Would run: cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi.orig
umount /mnt
mount -t msdosfs /dev/ada0p1 /mnt
Would run: cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi
Would run: cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi.orig
umount /mnt
mount -t msdosfs /dev/nda1p1 /mnt
mount_msdosfs: /dev/nda1p1: Invalid argument
Cannot mount nda1p1, so cannot looking for its loader(s).
Is this partition formatted?
mount -t msdosfs /dev/nda0p1 /mnt
mount_msdosfs: /dev/nda0p1: Invalid argument
Cannot mount nda0p1, so cannot looking for its loader(s).
Is this partition formatted?

One or more freebsd-boot partition(s) have been found.
The root file system is zfs.

Examining ada1...
There is a mismatch between the root fs and the current loader.
Root fs: zfs / Partition has: ufs.
--> No loader update on /dev/ada1p2.
Examining ada0...
There is a mismatch between the root fs and the current loader.
Root fs: zfs / Partition has: ufs.
--> No loader update on /dev/ada0p2.

-------------------------------
Your current boot method is UEFI.
Boot device: ada0p1 File(\EFI\BOOT\BOOTX64.EFI)
Updatable EFI loader: 4
4 serious error(s) occured. See texts above.
-------------------------------
The 2 ada errors occurred because p2 are for bios boot, which apparently the system is not doing, and the two for nda are because I just created the partitions in gpart, so have not yet created the filesystems.
 
Your system is efi booting on ada0p1 file /efi/boot/bootx64.efi.
ada1p1 contains a valid loader too, but both ada0p1 and ada1p1 should be updated.

I think that ada0p2 and ada1p2 have never been filled with gptzfsboot.
Use: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0 (same for ada1).

nda0p1 and nda1p1 must be msdos formatted, the path /efi/boot/ created and /boot/loader.efi copied as efi/boot/bootx64.efi.
Code: 
newfs_msdos /dev/nda0p1
mount -t msdosfs /dev/nda0p1 /mnt
mkdir -p /mnt/efi/boot
cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
umount /mnt

After that, run again loaders-update to be sure all is ok.

Next tests: commute in CSM/BIOS mode to try at least ada0. Back to efi mode, you can use efibootmgr to select one by one all your efi loaders.
 
Emrion said:
Your system is efi booting on ada0p1 file /efi/boot/bootx64.efi.
ada1p1 contains a valid loader too, but both ada0p1 and ada1p1 should be updated.

I think that ada0p2 and ada1p2 have never been filled with gptzfsboot.
Use: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 2 ada0 (same for ada1).

nda0p1 and nda1p1 must be msdos formatted, the path /efi/boot/ created and /boot/loader.efi copied as efi/boot/bootx64.efi.
Click to expand...

Yes, I know. I generally do it while/after the p3 (or p4) resilvers.

Emrion said:
Code: 
newfs_msdos /dev/nda0p1
mount -t msdosfs /dev/nda0p1 /mnt
mkdir -p /mnt/efi/boot
cp /boot/loader.efi /mnt/efi/boot/bootx64.efi
umount /mnt

After that, run again loaders-update to be sure all is ok.
Click to expand...

Looks good to me:

Code: 
sudo loaders-update show-me
loaders-update v1.0.1
show-me mode: it tells what it would do but changes nothing.

One or more efi partition(s) have been found.

mount -t msdosfs /dev/ada1p1 /mnt
Would run: cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi
Would run: cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi.orig
umount /mnt
mount -t msdosfs /dev/ada0p1 /mnt
Would run: cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi
Would run: cp /boot/loader.efi /mnt/EFI/BOOT/BOOTX64.efi.orig
umount /mnt
mount -t msdosfs /dev/nda1p1 /mnt
EFI loader /mnt/EFI/boot/bootx64.efi is up-to-date.
umount /mnt
mount -t msdosfs /dev/nda0p1 /mnt
EFI loader /mnt/EFI/boot/bootx64.efi is up-to-date.
umount /mnt

One or more freebsd-boot partition(s) have been found.
The root file system is zfs.

Examining ada1...
There is a mismatch between the root fs and the current loader.
Root fs: zfs / Partition has: ufs.
--> No loader update on /dev/ada1p2.
Examining ada0...
There is a mismatch between the root fs and the current loader.
Root fs: zfs / Partition has: ufs.
--> No loader update on /dev/ada0p2.

-------------------------------
Your current boot method is UEFI.
Boot device: ada0p1 File(\EFI\BOOT\BOOTX64.EFI)
Updatable EFI loader: 4
2 serious error(s) occured. See texts above.
-------------------------------
Emrion said:
Next tests: commute in CSM/BIOS mode to try at least ada0. Back to efi mode, you can use efibootmgr to select one by one all your efi loaders.
Click to expand...
Bootcode is stamped in ada0p2 and ada1p2, as I recall, I had to restamp it for the upgrade to 14.0-RELEASE, but I don't think I need it, especially since I read somehere (FreeBSD wiki?) that you can't BIOS boot off of NVMe drives anyway. I just want to make sure that the system is not going to try to boot from BIOS.

Something I also noticed is that before the mobo/cpu/ram upgrade, both ada0 and ada1 were listed in efibootmgr. Now it shows only one drive:

Code: 
sudo efibootmgr
Boot to FW : false
BootCurrent: 0001
Timeout    : 1 seconds
BootOrder  : 0001, 0002, 0003, 0004, 0005
+Boot0001* UEFI OS
 Boot0002* debian
 Boot0003* UEFI:CD/DVD Drive
 Boot0004* UEFI:Removable Device
 Boot0005* UEFI:Network Device

I just want to make sure the NVMe drives show up/are available/are bootable there before I go detaching the SSDs from the pool.
 
VulcanRidr said:
Bootcode is stamped in ada0p2 and ada1p2, as I recall, I had to restamp it for the upgrade to 14.0-RELEASE, but I don't think I need it, especially since I read somehere (FreeBSD wiki?) that you can't BIOS boot off of NVMe drives anyway. I just want to make sure that the system is not going to try to boot from BIOS.
Click to expand...
Ok. I didn't understand your point since nvme drives are ndaX. You eventually want to get rid of ada0 and ada1.

VulcanRidr said:
Something I also noticed is that before the mobo/cpu/ram upgrade, both ada0 and ada1 were listed in efibootmgr. Now it shows only one drive:
Click to expand...
You can create new efi entries (called efi vars) with efibootmgr.
Read well the manual page. This command is very powerful but not obvious on some points.
 
Emrion said:
Ok. I didn't understand your point since nvme drives are ndaX. You eventually want to get rid of ada0 and ada1.
Click to expand...

Correct. I just didn't want to end up in a situation where my system got into a state where it is trying to BIOS boot, can't seen ndaX, and I have removed adaX from the pool...

Emrion said:
You can create new efi entries (called efi vars) with efibootmgr.
Read well the manual page. This command is very powerful but not obvious on some points.
Click to expand...
Yeah, I looked at the man page, but I need to do a deep dive into it before removing the SATA drives. :)
 
Thanks everyone that helped...I was able to get the NVMes added to the pool and to efibootmgr, the SSDs removed from the pool and from efi, and taken out of the system. Can once again dual boot FreeBSD and Devuan via efi... I even took a minute and cleaned up the efibootmgr on my laptop as well.

Thanks for all the support and advice.
 
You must log in or register to reply here.
Back
Top