Wondering...

[jb_fvwm2]

I had a large backup disk which I had rsync'd to, but for some reason it would not boot on its own. Writing bootcode to it, and the data disappeared when one of the write-bootcode commands or methods (I tried several) succeeded without error. I followed the often-linked method of resinstalling a MBR scheme on it (slightly at odds with one of the threads here) which ostensibly failed (at a point where it was not supposed to), but I found it had indeed written filesystems and labels in /dev. I used those, on mountpoints, and over many hours finally rsync'd all the data back. It would not boot on its own. The first write-bootcode resulted in a F4 pxe menu which did nothing. I wrote
another bootcode command to that disk. All the data disappeared, the labels are gone.
....
Wondering if anyone has any way to recover the lost labels (I suppose if I could revert the mbr command ( gpart refuses ) they might. Or other advice; I know the next step is to
use GPT not MBR but I had preferred the latter. Or some other suggestion (what someone, say, does
routinely several times a year and never fails... in similar circumstances, to set up a new disk,
that never has trouble booting...)
Apologies if it is in some thread somwhere. I figured this post might be quicker than rereading
and rereading...)

 

[jb_fvwm2]

Sixty seconds of CLI saves twenty-odd hours of Rsync...

I thought the data was all gone (it was...)
Might as well start over.

fdisk /dev/ada0  #  (be sure to be using the /dev/ad10 == /dev/ada0 )
gpart destroy -F /dev/ada0
gpart create -s mbr ada0  # /dev omitted
gpart bootcode -b /boot/mbr ada0 # /dev omitted
# THAT line is what I suspect may fail later on, be incomplete ^^
gpart add -t freebsd ada0
cd /dev/ufs
ls
# the labels are BACK!

So the data is back. I've the disk mounted, ready for the
next backup. GOOD.... But suspect that
trying to write bootcode to it is Risky-Again.. All I need is some copy-this-file-there (or dd ) to make it bootable
that won't destroy (undo) the changes wrought by the above gpart commands.

 

[wblock@]

The labels come back because the bsdlabel(8) portion of the disk is still present. When you create the FreeBSD slice, GEOM sees the existing bsdlabel(8) information in it. To fully wipe the disk and start over, you need to destroy ada0s1 first, then ada0.

This comes from having to use BSD disk labels to split up a partition because MBR can't have more than four slices.

Rather than have two different kinds of partitioning on a disk, you can just switch to GPT. GPT can have more than four partitions, so there is no need for additional partitioning schemes.

 

[jb_fvwm2]

The bootcode cli above failed to install anything bootable. Unsure of which (gpart, boot0cfg, sysinstall, nothing, ...) to try next. [ Unless the "set active" of gpart is due instead, in which case I apologize for the extra post. ].
later...
gpart set active removed the labels and the data. I've undone it...

 

[wblock@]

With MBR, boot code has to be installed in both the MBR and the bsdlabel locations. The updated Handbook mirroring section shows examples.

But please, don't use MBR unless required.

 

[jb_fvwm2]

Probably very good advice...
I've saved another thread which showed a complete GPT install which worked. In the meantime, sysinstall was able to mark it active, but failed to install the boot manager, and the result was a blinking cursor. I'll read your link next...