Bug 17003

Summary: dscheck() overzealously protects labels on non-BSD partitions
Product: Base System Reporter: eps <eps>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 3.4-RELEASE   
Hardware: Any   
OS: Any   

Description eps 2000-02-26 08:10:01 UTC 
On a drive using DOS partitioning, dscheck() prevents overwriting the
first 1K of a partition that formerly held a UFS filesystem, even if
the partition type is changed to something other than DOSPTYP_386BSD.

Fix: 

Ignore contents of non-BSD partitions.  Don't even call
readdisklabel().

Relevant files: diskslice_machdep.c subr_diskslice.c ufs_disksubr.c
How-To-Repeat: dd if=/dev/zero of=/dev/rwd0s2 bs=512 count=1
Comment 1 Bruce Evans 2000-02-26 10:24:01 UTC 
On Sat, 26 Feb 2000 eps@sirius.com wrote:

> On a drive using DOS partitioning, dscheck() prevents overwriting the
> first 1K of a partition that formerly held a UFS filesystem, even if

It actually prevents overwriting the second sector.  This prevents
overwriting the first nK if the write is for nK at offset 0 and the
sector size is < nK.

> the partition type is changed to something other than DOSPTYP_386BSD.

This is a feature.  All types of partitions can have BSD labels.  This
part of the feature is intentional.  If you don't want your otherOS
partitions labeled, then don't put a label on them, and don't forget
to remove unwanted labels if you change partition types.  Also, be
careful when moving partitions.  An old label will wake up if there
is a valid one in the second sector of a new partition.

Labels can be difficult to remove, because of bugs in the label write
(un)protection ioctl.  The only reliable method that I know of is:
1) Open the whole disk device for the drive, and write suitable garbage
   (normally 0's) over the label sector.  If you use dd, then you will
   need an up to date dd that supports seeking to offsets >= 2GB if the
   label sector offset is >= 2GB.
2) Make sure that all subdevices on the drive are closed.  An in-core
   copy of the old label will be used until the next open after they
   are all closed.

Bruce
Comment 2 iedowse freebsd_committer freebsd_triage 2005-04-17 22:03:38 UTC 
State Changed
From-To: open->closed


Sorry, this is unlikely to be fixed now in 4.x, and the partition 
code in 5.x and -CURRENT is completely different so should not have 
this behaviour.