Date: Tue, 22 Nov 2016 07:35:11 -0700 (MST) From: Warren Block <wblock@wonkity.com> To: Mark Moellering <markmoellering@psyberation.com> Cc: freebsd-questions@freebsd.org, info@classcreator.com Subject: Re: replacing bootloader wipes disk? Message-ID: <alpine.BSF.2.20.1611220727370.80487@wonkity.com> In-Reply-To: <CAA0uU3UNzc89tGKQs658=y1N_hb1705rWYHBP1gGt8udUD_K0Q@mail.gmail.com> References: <CAA0uU3UNzc89tGKQs658=y1N_hb1705rWYHBP1gGt8udUD_K0Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1611220727370.80487>