replacing bootloader wipes disk?

[Warren Block]

On Tue, 22 Nov 2016, Mark Moellering wrote:

> Everyone,
>
> I have an odd situation.  I am helping a small company out, after my
> regular work hours, with their email server, which is on an older
> version FreeBSD (8.X or possibly 9.0)  I got a call a few days ago,
> saying the server wouldn't boot.  The server is at a hosting company
> but I was able to connect over a software KVM.  They had a new 11.0
> live disk to boot from, which I used to run fsck on each partition (it
> is running the old UFS2 partitions) and clean all the drives.
>
> When everything was finished and all drives were marked clean, I tried
> to boot from hard drive, it came up with GRUB and was trying to boot
> into linux , with the error "Can't find EXT3 Superblock". The error
> made sense but I had no idea why it was using GRUB, so I said there
> was something wrong with the bootloader.
>
> The next day (today), I was forwarded an email saying they ran the
> following commands to try and replace the bootloader.
>
> fdisk -B -b /boot/boot0 /dev/ada0
> and boot0cfg -B ada0
>
>
> When I checked the drive this evening, it appeared to be completely
> blank, except for a bootloader.  I am not good enough with fdisk to
> tell but could these commands have erased the drive?  They don't look
> like they would but fdisk is not something I use much...  Any help is
> greatly appreciated

Is it really an MBR disk?  fdisk knows nothing else, and will see a GPT 
disk as MBR.  Those commands should not have destroyed anything 
unrecoverably (I think), but they would put a multi-boot MBR loader on a 
GPT disk, which will then not boot.  The solution to this is to stop 
using fdisk and boot0, or at least make sure the disk is really MBR 
before using them.  gpart handles MBR, GPT, and other types of 
partitioning correctly. If this was a GPT disk, it might be able to 
recover the primary partition table from the second table at the end of 
the disk.  The first step is running 'gpart show' on that disk to find 
out which type of partitioning is really there.

It's definitely worth developing new procedures using gpart instead of 
fdisk.