On Fri, 7 Oct 2011, Glen Barber wrote: > Hi, > > On 10/7/11 3:18 PM, Poul-Henning Kamp wrote: >>> My guess is that GEOM isn't letting go of the GPT table and you have >>> multiple partitions in the GPT table and you're not destroying them >>> hierarchically in a proper manner.. but again, that's just a guess >>> based on hazy recollection. >> >> If none of the GPT partitions are open, you should be able to >> open /dev/da0. If not, the GPT geom class is buggy. >> > > In my experience, without kern.geom.debugflags=16, the MBR will not be > written to the memstick, leaving you with what would effectively be a > coaster in the not-so-distant past. Tried it just now with the 9.0-BETA3 memstick image. # dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k 10463+1 records in 10463+1 records out 685731840 bytes transferred in 52.614157 secs (13033219 bytes/sec) # mount /dev/da0p2 /mnt # dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k dd: /dev/da0: Operation not permitted # sysctl kern.geom.debugflags=16 kern.geom.debugflags: 0 -> 16 # dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k 10463+1 records in 10463+1 records out 685731840 bytes transferred in 52.915362 secs (12959031 bytes/sec) Followed by removing the memory stick without unmounting it to avoid overwriting part of the image. No obvious problems, but no, it's not polite. (I'm thinking "automounter" here.) We could make the normal procedure just the dd, followed by a note: If this gives an 'Operation not permitted' error, make sure that the target device is not in use or being automounted by some helpful utility program. And maybe If the error still appears and no other options are available, sysctl kern.geomflags.debug=16 will override the system safety and allow writes to the device.Received on Fri Oct 07 2011 - 18:27:07 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:18 UTC