freebsd stable - Mar 2005 - "ioctl DIOCSMBR: Operation not permitted" from "boot0cfg -s 1"

On a couple of machines here (my laptop and an SMP "build machine"), I
track each of RELENG_4 and RELENG_5 on a daily basis.  I do this by
using separate bootable slices.

As a consequence of doing things this way, I have become accustomed to
using boot0cfg to switch the default boot slice when I need to do this
(which is usually twice daily per machine).

I know of no problems doing this with RELENG_4 in the past, nor with
RELENG_5 (since that tag was laid down, of course -- there had been an
issue with 5.x when it was -CURRENT back in the earlier days of GEOM,
but that was un-broken withiin a few days -- up through Sunday (27 Feb).

This morning, I got through building & booting 5.4-PRERELEASE OK, so I
tried switching back to slice 1 (where I have RELENG_4 living).  This is
what I saw:

freebeast(5.4-P)[1] sudo boot0cfg -s 1 -v ad0
Password:
boot0cfg: /dev/ad0: ioctl DIOCSMBR: Operation not permitted
freebeast(5.4-P)[2] 

I also tried in single-user mode (after "fsck -p" and mounting the
usual
file systems, since boot0cfg is in /usr/sbin); same result.

I can't help but think that this is a symptom of a mistake -- especially
for -STABLE.  (-CURRENT/HEAD, I could believe, though a "heads up"
would
be welcome if such a change were contemplated.)

Now, on my laptop, it's easy enough to just press the appropriate Fx key
at boot; for that build machine -- which runs headless, keyboardless,
but with a serial console -- I found that I needed to interrupt the boot
sequence early -- just after the boot blocks have been loaded; I was
prompted:
>> FreeBSD/i386 BOOT
Default: 0:ad(0,a)/boot/loader
boot:

and responded "0:ad(0,1,a)/boot/loader", which booted from slice 1
(which was running 4.11-STABLE); I then used "boot0cfg" to switch the
default boot slice to "1".

I should be in a position to be able to test potential fixes.

Thanks,
david
-- 
David H. Wolfskill				david@catwhisker.org
There is a place in software engineering for an appreciation of history.

See http://www.catwhisker.org/~david/publickey.gpg for public key.

On Tue, 1 Mar 2005, David Wolfskill wrote:
> On a couple of machines here (my laptop and an SMP "build
machine"), I
> track each of RELENG_4 and RELENG_5 on a daily basis.  I do this by
> using separate bootable slices.
>
> As a consequence of doing things this way, I have become accustomed to
> using boot0cfg to switch the default boot slice when I need to do this
> (which is usually twice daily per machine).
>
> I know of no problems doing this with RELENG_4 in the past, nor with
> RELENG_5 (since that tag was laid down, of course -- there had been an
> issue with 5.x when it was -CURRENT back in the earlier days of GEOM,
> but that was un-broken withiin a few days -- up through Sunday (27 Feb).
>
> This morning, I got through building & booting 5.4-PRERELEASE OK, so I
> tried switching back to slice 1 (where I have RELENG_4 living).  This is
> what I saw:
>
> freebeast(5.4-P)[1] sudo boot0cfg -s 1 -v ad0
> Password:
> boot0cfg: /dev/ad0: ioctl DIOCSMBR: Operation not permitted
> freebeast(5.4-P)[2]
This is a GEOM safety feature.  Set sysctl kern.geom.debugflags=16 to
disable the safety, but you can very easily spam any mounted volumes this
way. Use at your own risk :)

-- 
Doug White                    |  FreeBSD: The Power to Serve
dwhite@gumbysoft.com          |  www.FreeBSD.org

David Wolfskill writes:
| freebeast(5.4-P)[1] sudo boot0cfg -s 1 -v ad0
| Password:
| boot0cfg: /dev/ad0: ioctl DIOCSMBR: Operation not permitted
| freebeast(5.4-P)[2] 

You might try:
	sysctl kern.geom.debugflags=16

Doug A.