Bug #1009

partition oddity

Added by swildner about 6 years ago. Updated over 4 years ago.

Status:ClosedStart date:
Priority:LowDue date:
Assignee:alexh% Done:

0%

Category:-
Target version:-

Description

DragonFly won't let me zero a partition:

zoot# dd if=/dev/zero of=/dev/ad8s2d
dd: /dev/ad8s2d: Read-only file system
1+0 records in
0+0 records out
0 bytes transferred in 0.000135 secs (0 bytes/sec)

Sascha

History

#1 Updated by dillon about 6 years ago

:DragonFly won't let me zero a partition:
:
:zoot# dd if=/dev/zero of=/dev/ad8s2d
:dd: /dev/ad8s2d: Read-only file system
:1+0 records in
:0+0 records out
:0 bytes transferred in 0.000135 secs (0 bytes/sec)
:
:Sascha
:
:--
:http://yoyodyne.ath.cx

That is the error you usually get if the partition in question is
still mounted.

-Matt
Matthew Dillon
<>

#2 Updated by swildner about 6 years ago

Yeah but it isn't.

zoot# mount | grep ad8s2d
zoot# dd if=/dev/zero of=/dev/ad8s2d
dd: /dev/ad8s2d: Read-only file system
1+0 records in
0+0 records out
0 bytes transferred in 0.009650 secs (0 bytes/sec)

Sascha

#3 Updated by dillon about 6 years ago

:...
:>
:> That is the error you usually get if the partition in question is
:> still mounted.
:
:Yeah but it isn't.
:
:zoot# mount | grep ad8s2d
:zoot# dd if=/dev/zero of=/dev/ad8s2d
:dd: /dev/ad8s2d: Read-only file system
:1+0 records in
:0+0 records out
:0 bytes transferred in 0.009650 secs (0 bytes/sec)
:
:Sascha
:
:--
:http://yoyodyne.ath.cx

That's odd. Is /dev or / mounted read-only? What about the modes
on /dev/ad8s2d ? If you do a fresh boot (i.e. never having tried to
mount anything using that device), and then issue the dd, does it
work differently?

Does disklabel recognize the disk?

Also try regenerating the /dev entry for ad8s2.

cd /dev
./MAKEDEV ad8
./MAKEDEV ad8s2
./MAKEDEV ad8s2a

-Matt
Matthew Dillon
<>

#4 Updated by swildner about 6 years ago

Hmm,

I tried most of this, all negative.

However, I _do_ have some partitions of the ad8s1 slice mounted (/,
/usr, etc.). Could it be because of this? I would think this shouldn't
affect partitions on ad8's other slices, right?

I'll try later from a LiveCD.

Sascha

#5 Updated by dillon about 6 years ago

:> on /dev/ad8s2d ? If you do a fresh boot (i.e. never having tried to
:> mount anything using that device), and then issue the dd, does it
:> work differently?
:>
:> Does disklabel recognize the disk?
:>
:> Also try regenerating the /dev entry for ad8s2.
:>
:> cd /dev
:> ./MAKEDEV ad8
:> ./MAKEDEV ad8s2
:> ./MAKEDEV ad8s2a
:
:Hmm,
:
:I tried most of this, all negative.
:
:However, I _do_ have some partitions of the ad8s1 slice mounted (/,
:/usr, etc.). Could it be because of this? I would think this shouldn't
:affect partitions on ad8's other slices, right?
:
:I'll try later from a LiveCD.
:
:Sascha

Is this on 1.12 or HEAD ? I do recall a bug in the partition-open
bitmap in the disk layer that I'm pretty sure I fixed in HEAD, but
may not have fixed in 1.12. It is possible there is an issue there,
it is worth checking out.

-Matt
Matthew Dillon
<>

#6 Updated by swildner about 6 years ago

It's on HEAD. I just booted with last night's snapshot and the problem
is the same, so it doesn't seem to matter whether other partitions on
the same disk are mounted or not.

Sascha

#7 Updated by dillon about 6 years ago

:It's on HEAD. I just booted with last night's snapshot and the problem
:is the same, so it doesn't seem to matter whether other partitions on
:the same disk are mounted or not.
:
:Sascha
:
:--
:http://yoyodyne.ath.cx

Post the disklabel output. If partition 'd' starts at offset 0
you won't be able to dd into it, because it will overlap the disklabel
itself (which is protected).

Matthew Dillon
<>

#8 Updated by swildner about 6 years ago

Hmm,

this seems to be the cause here:

# /dev/ad8s2:
type: unknown
disk: amnesiac
label:
flags:
bytes/sector: 512
sectors/track: 57
tracks/cylinder: 117
sectors/cylinder: 6669
cylinders: 20473
sectors/unit: 136534437
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # milliseconds
track-to-track seek: 0 # milliseconds
drivedata: 0

16 partitions:
# size offset fstype
c: 136534437 0 unused # 66667.206MB
d: 136534437 0 4.2BSD # 66667.206MB

Sascha

#9 Updated by dillon about 6 years ago

:Hmm,
:
:this seems to be the cause here:

Yup, that's the problem. I should have thought of it sooner.
Basically it has to work this way. It is an artifact of the BSD
label's in-band storage of the label. GPT labels store the actual
label out-of-band, so that sort of problem doesn't crop up.

But with BSD disklabels, the disklabel itself is stored in-band, meaning
at sector 0 as displayed by the label. To avoid it is best to start
at sector 16.

You can zero out the disk slice using e.g. ad8s2 (which is access without
going through the label and thus is able to overwrite the label), but
if you access it via a partition in the label and the partition starts
at sector 0, e.g. ad8s2d, then that chunk at the beginning containing
the label itself will be read-only by default.

-Matt

#10 Updated by swildner about 6 years ago

Hmm, unfortunately, using ad8s2 alone gives the same result:

zoot# dd if=/dev/zero of=/dev/ad8s2
dd: /dev/ad8s2: Read-only file system
1+0 records in
0+0 records out
0 bytes transferred in 0.003719 secs (0 bytes/sec)

#11 Updated by thomas.nikolajsen about 6 years ago

disklabel -W ?

Actually I almost removed -W / -N flags from disklabel(8) some time ago,
as I did understand from Matts commit messages that this was removed;
I found out that these flags are still working though.
Must have misread commit messages & and didn't read the code.

On similar lines: it seems like it is neede to reboot DragonFly
when changing between 32-bit and 64-bit disklabels, can this be correct?
After erasing a disklabel (eg 32-bit), using dd, disklabel64 fails,
as kernel still have copy of 32-bit disklabel.

-thomas

#12 Updated by corecode over 5 years ago

can we close this? seems like "we'll, that's how it is"

Also available in: Atom PDF