Problem adding new slices

[Jason Edward Kocol]

Kevin Oberman wrote:
> Sorry. I read that there was no /dev/ad0s3, so there was no reason to
> ask for the bsdlabel output.
> 
> First, the slicing looks good. All of the numbers are reasonable and add
> up correctly.
> 
> I now must suspect it's a GEOM issue. It looks like GEOM is not tasting
> the drive properly, but this gets out of my realm of expertise. I would
> suggest getting the dmesg from a verbose boot and posting it along with
> your kernel config somewhere so that people can examine them. And let us
> know when the sources were updated. 
> 
> I suspect I will not be the one to find anything, though. Everything
> looks fine to me...except that it does not work. :-(

I don't know what I did differently this time, but I finally got it to 
work.  Here are the steps I took.  May not be the best method but it got 
the slice created and mountable.  I didn't like all the reboots but they 
seemed to make a difference.

1) Ran sysinstall.  Created slice ad0s3 in fdisk using the remaining 
portion of the disk (just so I don't have to go through this again). 
Wrote changes here.  Rebooted.
2) Checked /dev.  /dev/ad0s3 and /dev/ad0s3c finally exist, therefore 
off to a better start.
3) Ran sysinstall again.  Created /d partition in label editor.  Wrote 
changes.  Rebooted.
4) Checked /dev.  /dev/ad0s3d is now there.

It was at this point that I tried to mount the partition, which failed 
with an incorrect super block error.  Then it occurred to me that I 
never actually saw newfs run from sysinstall like it usually does during 
a fresh install or adding a new disk.  So I did one more step:

5) newfs /dev/ad0s3d.

The partition was able to be mounted.

Here are some caveats to this whole thing, for those that are interested:

- Needed to run 'sysctl kern.geom.debugflag=16' every time I needed to 
write a change to the disk after a fresh boot, since it was a new 
partition on the disk for the running system.
- sysinstall reported that the geometry was incorrect for this disk, so 
it used a "more likely geometry."  I don't remember the values it chose, 
but when I tried to put in the ones that my BIOS reported it didn't like 
those either.  So your suspicions of a GEOM issue may have been 
well-founded initially.

I would post a verbose dmesg and kernel config as suggested, but since 
everything works now I don't know how useful or necessary it would be to 
anyone else who might encounter this problem.  The whole thing was 
rather mysterious to me from the get-go, quite honestly.

Thanks,
-Jason