Date: Fri, 28 Jan 2011 04:20:03 -0600 (CST) From: Scott Bennett <bennett@cs.niu.edu> To: freebsd-questions@freebsd.org Subject: [SOLVED] REPOST: Re: help requested in fixing disk label mistake Message-ID: <201101281020.p0SAK33X003843@mp.cs.niu.edu>
next in thread | raw e-mail | index | archive | help
I wrote:
> A few days ago, I posted here regarding damage resulting from a typing
>error and, a few minutes later, posted a followup to correct an error in my
>description of the problem. Thus far I've gotten no responses. In case the
>lack of response is simply due to the message having gotten lost in the flow,
>I'm reposting it below. I hope that someone who is more familiar with the
>details of bsdlabels and glabels can help me understand how to correct the
>problem because I'm loath at this point to embark upon an ill-informed trial-
>and-error experimentation program to recover label and file system(s).
>
> Scott
> ............................repost follows.........................
> I just wrote:
>> A couple of days ago, I reorganized the internal hard drive of my machine
>>to reclaim space that used to be occupied by another operating system for use
>>with my now exclusively FreeBSD system. I used a stand-alone partition manager
>>to edit the slices down to just two slices. I then attempted to bsdlabel the
>>first slice, but made a bit of a slip. When I should have typed
>>
>> bsdlabel -w ad0s1
>>
>>I actually typed
>>
>> bsdlabel -w da0s1
>>
>>Oops.
>> I went ahead with the work on the internal drive (ad0), and the system
>>is up and running fine. Now I'd like to try to fix the damage done to the
>>external drive that I relabeled by mistake. That drive's layout before the
>>damage was done was a single slice, divided into two partitions (da0s1 and
> ^^^^^
>>da0s2), each of which was then glabel'ed. The moment I rewrote the bsdlabel
> ^^^^^
> Yet another pair of mistakes on my part. Those should have said da0s1d
>and da0s1e. Sorry for any confusion.
>
>>for the first slice by mistake, the two partitions' entries in /dev/label
>>vanished, of course. I checked and discovered that the only external drive
>>for which I had not kept backup copies of the bsdlabel information was that
>>drive. :-( Fortunately, the full backups of the file systems that I needed
>>to reload onto the internal drive were in the first partition of the external
>>drive in question (used to be s1d, now s1a for the time being), so by mounting
>>/dev/da0s1a I still had full access to the file system containing the backups.
>> My hypothesis is if I can somehow rewrite a correct bsdlabel for the
>>affected slice, that the system will then recognize the glabel metadata for
>>the two partitions immediately, and the /dev/label entries will appear right
>>away like magic. Unfortunately, without a backup file of the bsdlabel
>>information, I'm unsure how to accomplish that. Is there some way that I can
>>discover the exact size in sectors of the first partition, so that I could
>>edit the bsdlabel information and redefine it as two partitions of the correct
>>sizes and offsets? Is there some field in dumpfs(8) output that would give me
>>what I need (allowing, of course, for the fact that the first partition
>>is actually one sector longer than anything dumpfs(8) would know about due to
>>the glabel metadata in the final sector of the partition)? Or is my hypothesis
>>stated above actually incorrect, and if so, why/how?
>> PLEASE send any replies to ME DIRECTLY (or at least Cc: me directly)
>>because I receive this list in digest form and am at least a week and a half
>>behind on my reading. :-} Thanks much in advance for any helpful ideas.
Well, I didn't get any responses, so I ended up testing what I had
surmised. First, I edited the bsdlabel for the s1 slice to replace the s1a
partition with s1d and s1e partitions. I used "dumpfs -m" to see the sector
count that had been used by newfs(8) in creating the file system in the s1d
partition and used that value as the size of the s1d partition and that value
plus the offset of the s1d partition as the offset of the s1e partition. I
took the size of the s1c partition (i.e., the whole slice) minus the offset
of the s1e partition as the size of the s1e partition. I rewrote the label
and then checked /dev/label for the missing entries. No dice. So I added
1 sector to the size of s1d and the offset of s1e and subtracted 1 sector from
the size of s1e, rewrote the label, and checked again. Still nothing.
Guessing that there might well have been some leftover sectors in s1d
when newfs(8) had created the file system there, I began repeating the process
just described. Eventually, on the fifteenth or sixteenth iteration, voila!
The missing device files in /dev/label had suddenly reappeared. :-) I then
immediately saved a copy of the corrected bsdlabel where I keep copies of the
other bsdlabels on my system.
So all is now well. I'm posting this result, so that if someone else
runs into the same trouble someday, perhaps they will find this method in the
list archives and be able to apply it successfully to recover from it, too.
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at cs.niu.edu *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201101281020.p0SAK33X003843>