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]" |
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]" |
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]" |
In reply to this post by Daniel O'Connor-3
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]" |
In reply to this post by Daniel O'Connor-3
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]" |
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]" |
In reply to this post by Dimitry Andric
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]" |
In reply to this post by Jaakko Heinonen
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]" |
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]" |
Free forum by Nabble | Edit this page |