Project

General

Profile

Actions

Bug #671

closed

disklabel in raw and kernel mode disagree

Added by corecode almost 17 years ago. Updated almost 17 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

on a usb stick:

disklabel -r -e yields one c: partition starting at offset 63. using this disklabel unmodified produces complaints from disklabel itself:

partition c: partition extends past end of unit
Warning, partition c doesn't start at 0!

doing the same without -r produces the right offset (0).

cheers
simon

Actions #1

Updated by dillon almost 17 years ago

:on a usb stick:
:
:disklabel -r -e yields one c: partition starting at offset 63. using thi=
:s disklabel unmodified produces complaints from disklabel itself:
:
:partition c: partition extends past end of unit
:Warning, partition c doesn't start at 0!
:
:doing the same without -r produces the right offset (0).
:
:cheers
: simon

On what device?  If you do it on the raw device (e.g. /dev/da0) there
won't be any label snooping. Labels only get snooped on slice devices,
which is why we really only support labeling slice devices. You might
be able to get away with specifying e.g. /dev/da0s0 though.
The on-disk version of the disklabel is different from the in-memory
version. This is historical, inherited from FreeBSD (and even before
that I think)... and I wish now that I had removed it years ago but
too late now... all the offsets in the on-disk label are absolute,
i.e. adjusted to add in the slice offset.
When the kernel read-snoops the on-disk label it adjusts the offsets
back to 0. When the kernel write-snoops it adjusts the offsets back
to absolute.
What I would like to do is just read and write the label straight,
without snoop-adjusting it. The kernel NEVER uses the absolute offsets,
it always uses the slice-relative offsets (i.e. starting at 0).
-Matt
Actions #2

Updated by corecode almost 17 years ago

also happens with vn(4):

  1. truncate -s 4G disk.img
  2. vnconfig -c -s labels vn0 disk.img
  3. fdisk -I /dev/vn0
    • Working on device /dev/vn0 *
      fdisk: invalid fdisk partition table found
      Warning: ending cylinder wraps, using all 1's
  4. fdisk /dev/vn0
    • Working on device /dev/vn0 *
      parameters extracted from device are:
      cylinders=4096 heads=64 sectors/track=32 (2048 blks/cyl)

Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=4096 heads=64 sectors/track=32 (2048 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165,(DragonFly/FreeBSD/NetBSD/386BSD)
start 32, size 8388576 (4095 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 255/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
  1. disklabel -r -w vn0s1 auto
  2. disklabel -r vn0s1
  3. /dev/vn0s1:
    type: unknown
    disk: amnesiac
    label: fictitious
    flags:
    bytes/sector: 512
    sectors/track: 63
    tracks/cylinder: 256
    sectors/cylinder: 16128
    cylinders: 520
    sectors/unit: 8388576
    rpm: 3600
    interleave: 1
    trackskew: 0
    cylinderskew: 0
    headswitch: 0 # milliseconds
    track-to-track seek: 0 # milliseconds
    drivedata: 0
16 partitions:
  1. size offset fstype
    c: 8388576 32 unused # 4095.984M
    partition c: partition extends past end of unit
    Warning, partition c doesn't start at 0!
    Warning, An incorrect partition c may cause problems for standard system utilities
  2. disklabel vn0s1
  3. /dev/vn0s1:
    type: unknown
    disk: amnesiac
    label: fictitious
    flags:
    bytes/sector: 512
    sectors/track: 63
    tracks/cylinder: 256
    sectors/cylinder: 16128
    cylinders: 520
    sectors/unit: 8388576
    rpm: 3600
    interleave: 1
    trackskew: 0
    cylinderskew: 0
    headswitch: 0 # milliseconds
    track-to-track seek: 0 # milliseconds
    drivedata: 0
16 partitions:
  1. size offset fstype
    c: 8388576 0 unused # 4095.984M

As you can see, -r shows the offset from beginning of the disk, without -r it
shows the offset from the start of the slice.

Actions #3

Updated by dillon almost 17 years ago

:Simon 'corecode' Schubert <> added the comment:
:
:also happens with vn(4):
:
:# truncate -s 4G disk.img
:# vnconfig -c -s labels vn0 disk.img
:# fdisk -I /dev/vn0
:...
:# disklabel -r vn0s1

I tried that exact sequence and it worked ok.  The disklabel -r vn0s1
returned the translated disklabel (partition c starting at offset 0)
instead of the on-disk disklabel. Which means that vn0s1 properly
snooped the raw read.
test28# cd /home
test28# rm disk.img
test28# truncate -s 4G disk.img
test28# vnconfig -c -s labels vn0 disk.img
test28# fdisk -I /dev/vn0
  • Working on device /dev/vn0 *
    fdisk: invalid fdisk partition table found
    Warning: ending cylinder wraps, using all 1's
    test28#
    test28# fdisk vn0
  • Working on device /dev/vn0 *
    parameters extracted from device are:
    cylinders=4096 heads=64 sectors/track=32 (2048 blks/cyl)
Figures below won't work with BIOS for partitions not in cyl 1
parameters to be used for BIOS calculations are:
cylinders=4096 heads=64 sectors/track=32 (2048 blks/cyl)
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165,(DragonFly/FreeBSD/NetBSD/386BSD)
start 32, size 8388576 (4095 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 255/ sector 63
The data for partition 2 is:
&lt;UNUSED&gt;
The data for partition 3 is:
&lt;UNUSED&gt;
The data for partition 4 is:
&lt;UNUSED&gt;
test28#
test28# disklabel -r -w vn0s1 auto
test28# disklabel -r vn0s1
...
16 partitions:
  1. size offset fstype
    c: 8388576 0 unused # 4095.984M
-Matt
Matthew Dillon
&lt;&gt;
Actions #4

Updated by dillon almost 17 years ago

It occurs to me that you may have forgotten to do a 'make upgrade'.
Or, if you have, that it is not properly regenerating the 'vn'
devices. Make sure the /dev/vn* devices are correct. e.g.:

crw-r----- 1 root operator 43, 0x1e110007 Jul 22 11:50 /dev/vn0
crw-r----- 1 root operator 43, 0x1e100007 Jul 13 16:00 /dev/vn0s0
crw-r----- 1 root operator 43, 0x00000000 Jul 13 16:00 /dev/vn0s0a
crw-r----- 1 root operator 43, 0x00000001 Jul 13 16:00 /dev/vn0s0b
crw-r----- 1 root operator 43, 0x00000002 Jul 13 16:00 /dev/vn0s0c
crw-r----- 1 root operator 43, 0x00000003 Jul 13 16:00 /dev/vn0s0d
crw-r----- 1 root operator 43, 0x00000004 Jul 13 16:00 /dev/vn0s0e
crw-r----- 1 root operator 43, 0x00000005 Jul 13 16:00 /dev/vn0s0f
crw-r----- 1 root operator 43, 0x00000006 Jul 13 16:00 /dev/vn0s0g
crw-r----- 1 root operator 43, 0x00000007 Jul 13 16:00 /dev/vn0s0h
crw-r----- 1 root operator 43, 0x00100000 Jul 13 16:00 /dev/vn0s0i
crw-r----- 1 root operator 43, 0x00100001 Jul 13 16:00 /dev/vn0s0j
crw-r----- 1 root operator 43, 0x00100002 Jul 13 16:00 /dev/vn0s0k
crw-r----- 1 root operator 43, 0x00100003 Jul 13 16:00 /dev/vn0s0l
crw-r----- 1 root operator 43, 0x00100004 Jul 13 16:00 /dev/vn0s0m
crw-r----- 1 root operator 43, 0x00100005 Jul 13 16:00 /dev/vn0s0n
crw-r----- 1 root operator 43, 0x00100006 Jul 13 16:00 /dev/vn0s0o
crw-r----- 1 root operator 43, 0x00100007 Jul 13 16:00 /dev/vn0s0p

-Matt
Actions #5

Updated by corecode almost 17 years ago

new kernel fixed the problem. closing.

Actions

Also available in: Atom PDF