Date: Wed, 23 Nov 2016 01:18:44 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Mark Moellering <markmoellering@psyberation.com> Cc: freebsd-questions@freebsd.org, info@classcreator.com Subject: Re: replacing bootloader wipes disk? Message-ID: <20161123002647.F2342@sola.nimnet.asn.au> In-Reply-To: <mailman.113.1479816002.28971.freebsd-questions@freebsd.org> References: <mailman.113.1479816002.28971.freebsd-questions@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In freebsd-questions Digest, Vol 651, Issue 2, Message: 2 On Tue, 22 Nov 2016 00:09:38 -0500 Mark Moellering <markmoellering@psyberation.com> 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. That would have been a great time to (once again) run such as: # dd if=/dev/ada0 of=/safe/place/thisbox.mbr count=1 # fdisk -s ada0 > /safe/place/thisbox.slices # boot0cfg -v ada0 > /safe/place/thisbox.boot0cfg # gpart show -p ada0 > /safe/place/thisbox.gpart_ada0 # gpart show -p adasX >> /safe/place/thisbox.gpart_ada0 # for each slice Anyway, can you show the fdisk, boot0cfg and (first) gpart results now? > 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. Does it usually boot FreeBSD? Did it really have a Linux slice too? If so, did it use GRUB to get to it? If not, where's that come from? > 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 Well .. the boot0cfg alone would have installed /boot/boot0 by default, and initialised it, perhaps to the last-used active slice. The fdisk before would install /boot/boot0 (rather than say /boot/mbr) but would not initialise it, but then the subsequent boot0cfg should have. Ie I think the fdisk likely superfluous, but probably not what damaged it. Neither should have changed the slice table - so perhaps that had been clobbered before these steps? It's a pity if they didn't save the MBR or at least one of the above that could describe it for reconstruction. Do the folk you're helping have a copy of the MBR? So small, so handy! > 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 Well just 'fdisk ada0' (and 'boot0cfg -v ada0') write nothing, but just report, as does 'gpart show ada0' - and all are worth reporting because each can provide (sometimes subtly) different clues as to how the system from the BIOS viewpoint sees the drive's boot status. For instance, seeing where fdisk has the first data sector - perhaps 63 - can indicate where your slice 1 started, and where you should find its bootblocks and embedded disklabel, should recovery be required. > I am hoping they put in a new drive but since I don't work on this > machine until after hours, I am not talking to the tech's working on > it during the day. > > Again, all help is greatly appreciated. I feel your pain :) but don't know if that could help. More data might. cheers, Ian (please cc me, subscribed to -digest)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161123002647.F2342>