Install FreeBSD bootcode from Linux rescue system

I have a system like this:
gpart show
=> 40 7501476448 nvd0 GPT (3.5T)
40 1024 1 freebsd-boot (512K)
1064 984 - free - (492K)
2048 33554432 2 freebsd-swap (16G)
33556480 7467919360 3 freebsd-zfs (3.5T)
7501475840 648 - free - (324K)
If after a FreeBSD upgrade I forget to update the bootloader then is it possible to install it using a Linux rescue system and command dd?

In the Linux rescue system I can mount the zfs pool:


zpool import -N -R /mnt zroot
zfs mount zroot/ROOT/default


And /mnt/boot/pmbr and /mnt/boot/gptzfsboot are accessible.

And in Linux rescue system the disk is found as: /dev/nvme0n1
 
Do you think these commands are correct?


dd if=/mnt/boot/pmbr of=/dev/nvme0n1 bs=512 count=1
dd if=/mnt/boot/gptzfsboot of=/dev/nvme0n1 bs=512 seek=40
 
Do you think these commands are correct?


dd if=/mnt/boot/pmbr of=/dev/nvme0n1 bs=512 count=1
Nooo! Not 512. You will destroy the partition table. Ok, it's a fake one but... The number of bytes to write is precisely 446. I don't know with linux, but the FreeBSD dd can't write less than 512 bytes IIRC, so this command is a bad idea. I will let the current bootcode. The update of this piece of code brings nothing interesting.

Do you think these commands are correct?


dd if=/mnt/boot/gptzfsboot of=/dev/nvme0n1 bs=512 seek=40
Should work if you remove "seek" and if the linux nvme0n1 is well the FreeBSD nvd0p1.

That said, ataxa1a is right. It would be simpler and less dangerous to use a FreeBSD booting key and use the suited commands.
 
Linux nvme0n1 = FreeBSD nvd0 (not nvd0p1). So I believe seek=40 is needed in this case to skip the first 40 sectors (MBR and unused space) and write into the freebsd-boot partition starting at sector 40. Am I right?
 
Linux nvme0n1 = FreeBSD nvd0 (not nvd0p1). So I believe seek=40 is needed in this case to skip the first 40 sectors (MBR and unused space) and write into the freebsd-boot partition starting at sector 40. Am I right?
Ah ok. Can't you use the partition directly: nvme0n1p1? This is less prone to error.
 
Back
Top