Re: aliasing (or renaming) kern.geom.debugflags

From: Warren Block <wblock_at_wonkity.com>
Date: Fri, 7 Oct 2011 14:27:05 -0600 (MDT)
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