Date: Mon, 27 Aug 2012 12:42:07 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Matt Smith <matt@xtaz.co.uk> Cc: Erich Dollansky <erichfreebsdlist@ovitrap.com>, freebsd-stable@freebsd.org, Stefan Bethke <stb@lassitu.de> Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown Message-ID: <alpine.BSF.2.00.1208271230360.48366@wonkity.com> In-Reply-To: <78f8335e54e04f158609f0382afb8d4d@xtaz.co.uk> References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> <b98001dbe576eafcf4f4500e975680ec@xtaz.co.uk> <20120827172650.7e6a7685@AMD620.ovitrap.com> <c5c51c674a29c136f0d10a3fe936a6a0@xtaz.co.uk> <alpine.BSF.2.00.1208270750130.46223@wonkity.com> <78f8335e54e04f158609f0382afb8d4d@xtaz.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 27 Aug 2012, Matt Smith wrote: > On 2012-08-27 14:56, Warren Block wrote: >> >> Stefan called it. The newfs is done on /dev/gpt/gptroot, no problem >> there. But when glabel writes to /dev/ada0p2--which is >> /dev/gpt/gptroot, same thing, it overwrites the last block. And then >> the filesystem is mounted with the glabel device, which is actually >> one block smaller than the filesystem expects. >> >> Could be either the filesystem or GEOM that's causing the failure at >> shutdown. >> >> Happily, those glabels aren't accomplishing anything useful and can >> be skipped. Removing the glabels and changing the devices in fstab >> might be enough. A more cautious approach would be to back up, newfs, >> skip the glabel step, and then change the devices in fstab. > > As I said on a previous mail I did boot it with a USB stick and cleared the > glabel metadata and altered the fstab to point to both the GPT labels and the > raw UFS device and I still get the issue. So am I right in thinking then that > this has caused irreparable damage To the filesystem? Probably (weasel word) not. The old instructions for gmirror used the last block out of a filesystem and there have been no notable reports of data loss. One thing to mention is that SU+J might change what the filesystem does with that last block. I'm avoiding SU+J until the dump problem is fixed, so have not experimented with that. > and the only way I can fix this now is to newfs the filesystem again, > this time just using GPT labels and not using glabel at all? I'll commit to it and say yes, that will work. > This is the first time I've ever done a manually partitioned installation > with GPT and alignment, previously I've only ever used sysinstall with > non-aligned MBR installations, so it was a bit of a learning curve. If I do > have to newfs it again then I want to be sure that I'm doing the correct > things so that I don't find myself with any other issues. So does the rest of > what I did look fine? No obvious problems jumped out at me. Here are my notes: http://www.wonkity.com/~wblock/docs/html/disksetup.html The gpart version is halfway down. I really need to switch that around.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1208271230360.48366>