Date: Tue, 10 Aug 2010 16:52:08 -0600 From: Dale Scott <dalescott@shaw.ca> To: Michael Powell <nightrecon@hotmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: RE: ZFS woes Message-ID: <cdb7e80c52f85.4c6183b8@shaw.ca> In-Reply-To: <i3sfru$tlt$1@dough.gmane.org> References: <4C61B215.9030603@nagual.nl> <01FB8F39BAD0BD49A6D0DA8F7897392904F7BD@Mercury.galaxy.lan.lcl> <i3sfru$tlt$1@dough.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
=3E=3E wiped out the firt mb=3B i used sysinstall to create a fbsd=A0sli= ce=3B wiped =3E=3E it out again=3B booted knoppix to create an EFI / GPT=3B booted i= nto =3E=3E opensolaris and created a zpool (v14)=2C but nothing=2C nothing=A0= =3E=3E did the=A0trick=2E I was doing a vanilla fbsd install recently using a couple re-claimed 25= 0GB IDE drives=2E The install completed without errors=2C but after rebo= ot GEOM complained bitterly about the secondary GPT table on the boot dr= ive being corrupted or invalid=2C and unrecoverable corrupted or invalid= GPT tables on the 2nd drive=2E By trying something like above=2C I was = able to get the system drive to rebuild the secondary GPT table=2C but n= othing worked on the second drive=2E Google told me a targeted approach = was technically possible (by calculating exactly where a specific drive = stores its GPT metadata and zeroing just that bit)=2C but also that the = broader solution of zeroing out the entire drive would be faster for me = than figuring out the calculation (about 18 hrs to zero the entire drive= =2C at least it was mostly while sleeping)=3A =22dd if=3D/dev/zero of=3D= /dev/ad3 bs=3D64K=22 (no idea if the block size is optimal or even=A0rel= evant)=2E Dale Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cdb7e80c52f85.4c6183b8>