UFS gpart bootcode

B

balanga

I'm trying to figure out how gpart bootcode works.

My understanding is that it installs the mbr in the first block on a device and this block contains space for the partition table. So if you first run gpart add and subsequently run gpart bootcode, don't you overwrite the partition table?

According to


you first run CMD]gpart add[/CMD] and then run gpart bootcode.

This obviously works, but I don't see how.
 
For understanding, comments in /usr/src/stand/i386/boot0/boot0.S would be very helpful to understand. It's assembly codes, but comments are in English. If you don't have src tree on your installation, you can read it via cgit repo.
As shown in the comments, the position and size of primary partition table is fixed on all supported variants. See manpage of gpart(8) for supported partition schemes.
Also see related Wikipedia page to understand various MBRs (not all variants would be supported by FreeBSD, though).
Not actually read source codes how gpart handles it, but basically, read new bootcode from specified file (usually, /boot/boot0), read current MBR to be updated, copy primary partition table in read current MBR to the primary partition table area in read new bootcode, then, overwrite MBR with updated one should assure current partition table to be kept.
 
That's not exactly clear to me, but are you saying that gpart bootcode saves a copy of your partition table and reapplies it after installing the mbr -b BOOTCODE ?
 
balanga said:
That's not exactly clear to me, but are you saying that gpart bootcode saves a copy of your partition table and reapplies it after installing the mbr -b BOOTCODE ?
Click to expand...
MBR, including primary partition table, is only 1 sector (512bytes).
Disk (block device) I/O is done with per sector at minimum.
So updating bootcodes in MBR (gpart bootcode -b) must be copy-on-write.
Otherwise partition table is assured to be wiped out (broken).
As I haven't encountered such a situation when I was using MBR scheme (before switching to GPT scheme), writing more detailed,

  1. Read new bootcode into memory.
  2. Read current MBR at the top of disk (Cylinder 0, Head 0, Sector 0) into memory, different address with 1.
  3. Copy primary partition table area of 2. into the same position (in the sector) of 1. The area of 1. was all zero'ed before the copy.
  4. Write updated 512 bytes of memory 1. into the top of disk mentioned on 2.
or
  1. Read current MBR at the top of disk (Cylinder 0, Head 0, Sector 0) into memory.
  2. Read new bootcode into memory, different address with 1.
  3. Copy primary partition table area of 1. into the same position (in the sector) of 2. The area of 2. was all zero'ed before the copy.
  4. Write updated 512 bytes of memory 2. into the top of disk mentioned on 1.
 
balanga said:
That's not exactly clear to me, but are you saying that gpart bootcode saves a copy of your partition table and reapplies it after installing the mbr -b BOOTCODE ?
Click to expand...
see /usr/src/sys/geom/part/g_part_mbr.c
static int g_part_mbr_bootcode(struct g_part_table *basetable, struct g_part_parms *gpp)
static int g_part_mbr_write(struct g_part_table *basetable, struct g_consumer *cp)

Edit: if boot0cfg /usr/src/usr.sbin/boot0cfg/boot0cfg.c
#define OFF_PTBL 0x1be /* offset: partition table */ bpath = "/boot/boot0"; mbr_size = read_mbr(disk, &mbr, !B_flag); if (B_flag) { boot0_size = read_mbr(bpath, &boot0, 1); memcpy(boot0 + OFF_PTBL, mbr + OFF_PTBL, sizeof(struct dos_partition) * NDOSPART);
 
Read FreeBSD Handbook first, this case, Chapter 2.6 would be helpful.

As the Warren's page you linked introduced GPT first, cannot understand why you've chosen MBR, but assuming you have buggy BIOS in hand and cannot handle GPT (usually, even if on pre-UEFI BIOS'es, pmbr would help booting from GPT-partitioned disk), thus answered as above.

At least, Warren's page is outdated at least for UEFI.
It seems to be avoiding risk for UEFI cannot boot FreeBSD. I've used something alike when I first tried UEFI boot (actually it was problematic at the moment and I've discussed on freebsd-current ML with Steven Hartland, assisting him fixing the issue by testing his patches. Linked from above is the first post.).
Now, usually freebsd-boot partition is no longer needed for UEFI boot on sane UEFI firmwares and default boot code for UEFI switches from boot1.efi to loader.efi.
 
You must log in or register to reply here.
Back
Top