Date: Tue, 03 Mar 2009 08:58:32 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: Jaakko Heinonen <jh@saunalahti.fi> Cc: freebsd-geom@FreeBSD.org Subject: Re: gpart probing problem Message-ID: <6E283F9A-30B1-431E-B6F1-142E17647FB2@mac.com> In-Reply-To: <20090302195126.GA6974@a91-153-125-115.elisa-laajakaista.fi> References: <20090302195126.GA6974@a91-153-125-115.elisa-laajakaista.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 2, 2009, at 11:51 AM, Jaakko Heinonen wrote: > I noticed a regression after gpart (GEOM_PART_*) was made default. > > I have a disk which has remnants of an old GPT table but which has a > valid MBR table. Previously I got following messages to the log but > the > MBR partition was da0s1 was properly detected. > > GEOM: da0: corrupt or invalid GPT detected. > GEOM: da0: GPT rejected -- may not be recoverable. > GEOM_LABEL: Label for provider da0s1 is msdosfs/FOO. > > Now with gpart as default the MBR table is not detected and I can't > access the da0s1 partition. These messages appear to the log: > > GEOM: da0: corrupt or invalid GPT detected. > GEOM: da0: GPT rejected -- may not be recoverable. > > g_part_gpt_probe() only does a check for GPT header signature > existence > but it doesn't check if the table is actually valid. gpart doesn't try > other schemes after it has decided to use GPT. It's actually not a regression. There's always a MBR in front of a GPT and a corrupted GPT should not be tossed aside and ignored. The behaviour of gpart is correct in that the operator/user needs to remove the ambiguity. Either by fixing the GPT or otherwise by removing it altogether. Under no circumstance should the kernel use the MBR and pretend nothing is wrong. FYI, -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6E283F9A-30B1-431E-B6F1-142E17647FB2>