# Binary upgrade 7.1->8.0 messed up my gmirror



## zapher (Jan 4, 2010)

Hi!

This week I finally upgraded to 8.0 via freebsd-update upgrade -r 8.0-RELEASE. Unfortunately this wasn't as smooth as I would have wished for.

I have a gmirror named /dev/mirror/gm0 with two disks (ad6, ad10) attached to it. Before the upgrade it was working fine and I had /dev/mirror/gm0*s1* mounted at /storage as it's not used as a system disk. Merely as a storage disk.

After the upgrade, I rebooted, and all hell broke loose. As my gm0*s1* was no where to be found, it failed to mount. This forced me into single user mode where I not only lost my $TERM type, but termcap didn't work. As you can imagine, without a $TERM type, it's difficult to edit files. I finally managed to edit _/etc/fstab_ through a livecd to be able to comment out the mount and now I'm back in the system. Worth to note is that both mergemaster, termcap and bash all broke while in single user mode.

I now ponder on why my slice went away? And what is /dev/gm0*a* all about? Any ideas on how to safely get my data back in one piece? _gmirror list_ tells me the mirror is working fine and all synced up.

_fdisk /dev/mirror/gm0_ outputs:

```
******* Working on device /dev/mirror/gm0 *******
parameters extracted from in-core disklabel are:
cylinders=24321 heads=255 sectors/track=63 (16065 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=24321 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 390716802 (190779 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 1023/ head 14/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
```

Thanks!


----------



## zapher (Jan 4, 2010)

I found this on the topic "dangerously dedicated disks" http://www.pubbs.net/freebsd/200912/39499/

Maybe someone could give me some expert advice here? I'm not to keen of just erasing sector #2 just to test their theory.


----------



## DutchDaemon (Jan 4, 2010)

See also http://forums.freebsd.org/showthread.php?t=8729


----------



## zapher (Jan 4, 2010)

Thanks! I just read that, funny enough.

So as I understand it, FBSD 8 doesn't approve that I have both a MBR *AND* a disklabel? That would explain why it shows mirror/gm0a instead of mirror/gm0s1 as it prefers the disklabel partition scheme (which on my part is defunct).

So because that the MBR lies in sector 1, and I don't use the disklabel layout in sector 2 I could just # _dd if=/dev/zero of=/dev/mirror/gm0 oseek=1 count=1_ to have it write over sector (LBA) 2?

Or should I instead do this directly to one of my drives and have gmirror sync it over? 
# _dd if=/dev/zero of=/dev/ad6 oseek=1 count=1_


----------



## DutchDaemon (Jan 4, 2010)

I copied your post over to the other thread to enhance your chances of getting a meaningful reply.


----------



## zapher (Jan 4, 2010)

Awesome! Erasing my messed up disklabel (sector 2) solved it! Didn't even have to reboot.

*Total procedure:*
Make sure you have a backup in case you mess it up. This backs up both LBA (sector) 1 and 2 which holds the MBR and GPT/BSDlabel correspondingly.
`# dd if=/dev/daX of=boot.bak count=2`

Next, you want to skip the first LBA and write 512B of zeroes over the second LBA.
`# dd if=/dev/zero of=/dev/daX oseek=1 count=1`

Make sure daX is the *whole device*, not a slice or label (daXs1 etc).

Also, make sure you type in the dd-commands correct. Failing to do so can *destroy data*!


----------



## phwaap (Mar 30, 2010)

@zapher those were two horrifying commands to run on a 1TB mirror but worked great.


----------



## zapher (Mar 31, 2010)

phwaap said:
			
		

> @zapher those were two horrifying commands to run on a 1TB mirror but worked great.



Haha, I can relate to that. Glad it worked! And as always, don't trust 3rd party commands. Read the manual before and make sure it's doing what it says it's doing.


----------

