GEOM/bsdlabel regression in 8.x?

[Daniel O'Connor-3]

I was helping a friend as he wanted to add a partition to a new install, ie he did (effectively) this..

truncate -s 10m /tmp/test
mdconfig -a -t vnode -f /tmp/test
fdisk -BI /dev/md0
bsdlabel -w /dev/md0s1
bsdlabel -e /dev/md0s1
<change a: to>
  a:     2048       16    4.2BSD        0     0     0
newfs /dev/md0s1a
mkdir /mnt/test
mount /dev/md0s1a /mnt/test
bsdlabel -e /dev/md0s1

Then you get..
"bsdlabel: Class not found"

Note that just touching the file bsdlabel is using is enough to cause it to generate that error.

I tried the same steps on a 7.x system and it worked fine.

ktrace shows
...
 90200 bsdlabel CALL  ioctl(0x4,DIOCGMEDIASIZE,0x7fffffffe430)
 90200 bsdlabel RET   ioctl 0
 90200 bsdlabel CALL  ioctl(0x4,DIOCGSECTORSIZE,0x7fffffffe434)
 90200 bsdlabel RET   ioctl 0
 90200 bsdlabel CALL  ioctl(0x4,DIOCGFWSECTORS,0x7fffffffe454)
 90200 bsdlabel RET   ioctl 0
 90200 bsdlabel CALL  ioctl(0x4,DIOCGFWHEADS,0x7fffffffe454)
 90200 bsdlabel RET   ioctl 0 90200 bsdlabel CALL  close(0x4) 90200 bsdlabel RET   close 0
 90200 bsdlabel CALL  close(0x3)
 90200 bsdlabel RET   close 0
 90200 bsdlabel CALL  open(0x800c04040,O_RDWR,<unused>0x26ec)
 90200 bsdlabel NAMI  "/dev/md0s1"
 90200 bsdlabel RET   open -1 errno 1 Operation not permitted
 90200 bsdlabel CALL  open(0x800651b5f,O_RDONLY,<unused>0)
 90200 bsdlabel NAMI  "/dev/geom.ctl"
 90200 bsdlabel RET   open 3
 90200 bsdlabel CALL  ioctl(0x3,GEOM_CTL,0x800c06040) 90200 bsdlabel RET   ioctl 0 90200 bsdlabel CALL  close(0x3)


Note that my friend tried it on real hardware and said that after he rebooted it appeared(!)

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C






_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"

[Dimitry Andric]

On 2010-07-04 14:24, Daniel O'Connor wrote:
...
> mkdir /mnt/test
> mount /dev/md0s1a /mnt/test
> bsdlabel -e /dev/md0s1
>
> Then you get..
> "bsdlabel: Class not found"

First unmount /dev/md0s1a, or the device /dev/md0s1 will be in use, and
opening it for read/write (as bsdlabel probably does) will fail.

Alternatively, you can turn on the "footshooting" debug flag in geom:

     Protection mechanisms in the geom(4) subsystem might prevent boot0cfg
     from being able to update the MBR on a mounted disk.  Instructions for
     temporarily disabling these protection mechanisms can be found in the
     geom(4) manpage. Specifically, do a

           sysctl kern.geom.debugflags=0x10

     to allow writing to the MBR, and restore it to 0 afterwards.

and try again.  This may not work as expected though. :)
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"

[Daniel O'Connor-3]

On 04/07/2010, at 23:27, Dimitry Andric wrote:

>> Then you get..
>> "bsdlabel: Class not found"
>
> First unmount /dev/md0s1a, or the device /dev/md0s1 will be in use, and
> opening it for read/write (as bsdlabel probably does) will fail.
>
> Alternatively, you can turn on the "footshooting" debug flag in geom:
>
>     Protection mechanisms in the geom(4) subsystem might prevent boot0cfg
>     from being able to update the MBR on a mounted disk.  Instructions for
>     temporarily disabling these protection mechanisms can be found in the
>     geom(4) manpage. Specifically, do a
>
>           sysctl kern.geom.debugflags=0x10
>
>     to allow writing to the MBR, and restore it to 0 afterwards.
>
> and try again.  This may not work as expected though. :)

It doesn't make a difference if you set that flag or not.

(The fact you need to set debugflags to modify the MBR is a separate bug anyway IMO)

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C






_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"

[Jaakko Heinonen]

On 2010-07-04, Daniel O'Connor wrote:
> "bsdlabel: Class not found"

This is because GEOM_BSD -> GEOM_PART_BSD change. bsdlabel(8) needs
read-write access to the device. If it can't get that, it tries an
alternative GEOM based method only supported by GEOM_BSD. The error
message "Class not found" is printed because the "BSD" GEOM class
doesn't exist.

You might be able to do the changes with gpart(8).

--
Jaakko
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"

[Dimitry Andric]

On 2010-07-04 16:26, Daniel O'Connor wrote:
>> First unmount /dev/md0s1a, or the device /dev/md0s1 will be in use, and
>> opening it for read/write (as bsdlabel probably does) will fail.
>>
>> Alternatively, you can turn on the "footshooting" debug flag in geom:
...
> It doesn't make a difference if you set that flag or not.
>
> (The fact you need to set debugflags to modify the MBR is a separate bug anyway IMO)

On my 8-stable box, I have tried this sequence of commands:

  truncate -s 10m /tmp/test
  mdconfig -a -t vnode -f /tmp/test
  mdconfig -a -t vnode -f /tmp/test
  fdisk -BI /dev/md0
  bsdlabel -w /dev/md0s1
  bsdlabel -e /dev/md0s1
  newfs /dev/md0s1a
  mkdir /mnt/test
  mount /dev/md0s1a /mnt/test
  bsdlabel -e /dev/md0s1

The last one indeed fails, because the device is in use.  This is
expected, but the error message is very misleading, and should be
improved.

The real 'bug' (although there will probably be loads of bikesheds about
it) is probably that if you *do* unmount the filesystem, bsdlabel still
fails:

  umount /mnt/test
  bsdlabel -e /dev/md0s1
  [class not found yada yada]

Apparently, unmounting does not properly 'release' whatever underlying
geom device is preventing read/write access.  However, if you then set
the footshooting flag:

  sysctl -w kern.geom.debugflags=0x10
  bsdlabel -e /dev/md0s1

bsdlabel can write without problems, at least on my box.  Stranger
even, if you subsequently turn off the footshooting flag, it *still*
can write to the label.  That is, unless you mount and unmount the
filesystem, after which is again, sort of 'locked' against writing.

All highly confusing. :)
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"

[Garrett Cooper-6]

On Sun, Jul 4, 2010 at 8:37 AM, Dimitry Andric <[hidden email]> wrote:

> On 2010-07-04 16:26, Daniel O'Connor wrote:
>>> First unmount /dev/md0s1a, or the device /dev/md0s1 will be in use, and
>>> opening it for read/write (as bsdlabel probably does) will fail.
>>>
>>> Alternatively, you can turn on the "footshooting" debug flag in geom:
> ...
>> It doesn't make a difference if you set that flag or not.
>>
>> (The fact you need to set debugflags to modify the MBR is a separate bug anyway IMO)
>
> On my 8-stable box, I have tried this sequence of commands:
>
>  truncate -s 10m /tmp/test
>  mdconfig -a -t vnode -f /tmp/test
>  mdconfig -a -t vnode -f /tmp/test
>  fdisk -BI /dev/md0
>  bsdlabel -w /dev/md0s1
>  bsdlabel -e /dev/md0s1
>  newfs /dev/md0s1a
>  mkdir /mnt/test
>  mount /dev/md0s1a /mnt/test
>  bsdlabel -e /dev/md0s1
>
> The last one indeed fails, because the device is in use.  This is
> expected, but the error message is very misleading, and should be
> improved.
>
> The real 'bug' (although there will probably be loads of bikesheds about
> it) is probably that if you *do* unmount the filesystem, bsdlabel still
> fails:
>
>  umount /mnt/test
>  bsdlabel -e /dev/md0s1
>  [class not found yada yada]
>
> Apparently, unmounting does not properly 'release' whatever underlying
> geom device is preventing read/write access.  However, if you then set
> the footshooting flag:
>
>  sysctl -w kern.geom.debugflags=0x10
>  bsdlabel -e /dev/md0s1
>
> bsdlabel can write without problems, at least on my box.  Stranger
> even, if you subsequently turn off the footshooting flag, it *still*
> can write to the label.  That is, unless you mount and unmount the
> filesystem, after which is again, sort of 'locked' against writing.
>
> All highly confusing. :)

<offtopic>

There's a weird ass feature in geom too under 7.x+ that if you have
where if you have a dangerously dedicated disk partitioned like so
that gets mounted, it automatically hides the slicing:

$ dd if=/dev/zero of=afile bs=10m count=5
$ mdconfig -a -t vnode -f afile
md1
$ ls /dev/md1*
/dev/md1
$ sudo fdisk -BIq /dev/md1
$ bsdlabel -w /dev/md1s1
$ bsdlabel -e /dev/md1s1
# /dev/md1s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:    96311       16    unused        0     0
  c:    96327        0    unused        0     0         # "raw" part, don't edit
# newfs /dev/md1s1
/dev/md1s1: 47.0MB (96324 sectors) block size 16384, fragment size 2048
        using 4 cylinder groups of 11.77MB, 753 blks, 1536 inodes.
super-block backups (for fsck -b #) at:
 160, 24256, 48352, 72448
$ ls /dev/md1*
/dev/md1 /dev/md1s1
$ ls /dev/md1*
/dev/md1 /dev/md1s1 /dev/md1s1a
$ mount /dev/md1s1 /mnt/mem
$ ls /dev/md1*
/dev/md1 /dev/md1s1
$ umount /mnt/mem
$ ls /dev/md1*
/dev/md1 /dev/md1s1 /dev/md1s1a

It's something that someone noticed at my work.

</offtopic>

Thanks,
-Garrett
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"

[Daniel O'Connor-3]

On 05/07/2010, at 1:07, Dimitry Andric wrote:
>  bsdlabel -e /dev/md0s1
>
> The last one indeed fails, because the device is in use.  This is
> expected, but the error message is very misleading, and should be
> improved.

Maybe, I wouldn't call it expected because it used to work :)

I agree about the error message though!

> The real 'bug' (although there will probably be loads of bikesheds about
> it) is probably that if you *do* unmount the filesystem, bsdlabel still
> fails:
>
>  umount /mnt/test
>  bsdlabel -e /dev/md0s1
>  [class not found yada yada]
>
> Apparently, unmounting does not properly 'release' whatever underlying
> geom device is preventing read/write access.  However, if you then set
> the footshooting flag:
>
>  sysctl -w kern.geom.debugflags=0x10
>  bsdlabel -e /dev/md0s1
>
> bsdlabel can write without problems, at least on my box.  Stranger
> even, if you subsequently turn off the footshooting flag, it *still*
> can write to the label.  That is, unless you mount and unmount the
> filesystem, after which is again, sort of 'locked' against writing.
>
> All highly confusing. :)

Hmm odd, the sysctl had no effect here..

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C






_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"

[Daniel O'Connor-3]

On 05/07/2010, at 24:52, Jaakko Heinonen wrote:

> On 2010-07-04, Daniel O'Connor wrote:
>> "bsdlabel: Class not found"
>
> This is because GEOM_BSD -> GEOM_PART_BSD change. bsdlabel(8) needs
> read-write access to the device. If it can't get that, it tries an
> alternative GEOM based method only supported by GEOM_BSD. The error
> message "Class not found" is printed because the "BSD" GEOM class
> doesn't exist.
>
> You might be able to do the changes with gpart(8).

Ahh that does work..

midget# gpart add -t freebsd-ufs -i 4 md0s1
md0s1d added
midget# newfs /dev/md0s1d
/dev/md0s1d: 2.8MB (5744 sectors) block size 16384, fragment size 2048
        using 4 cylinder groups of 0.70MB, 45 blks, 128 inodes.
super-block backups (for fsck -b #) at:
 160, 1600, 3040, 4480
mmidget# mount /dev/md0s1d /mnt/test2
midget# mount
..
/dev/md0s1a on /mnt/test (ufs, local)
/dev/md0s1d on /mnt/test2 (ufs, local)

IMO it's still a regression because bsdlabel used to work, although I can appreciate it might be a rather in depth change to have it work with the New World Order (tm).

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C






_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"

[Daniel O'Connor-3]

On 05/07/2010, at 9:06, Daniel O'Connor wrote:

>
> On 05/07/2010, at 24:52, Jaakko Heinonen wrote:
>
>> On 2010-07-04, Daniel O'Connor wrote:
>>> "bsdlabel: Class not found"
>>
>> This is because GEOM_BSD -> GEOM_PART_BSD change. bsdlabel(8) needs
>> read-write access to the device. If it can't get that, it tries an
>> alternative GEOM based method only supported by GEOM_BSD. The error
>> message "Class not found" is printed because the "BSD" GEOM class
>> doesn't exist.
>>
>> You might be able to do the changes with gpart(8).
>
> Ahh that does work..
>
> midget# gpart add -t freebsd-ufs -i 4 md0s1

<snip>
> IMO it's still a regression because bsdlabel used to work, although I can appreciate it might be a rather in depth change to have it work with the New World Order (tm).

So, why didn't it? Shouldn't it DTRT? This is a stock kernel.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C






_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[hidden email]"