andrew.cagney%gmail.com@localhost (Andrew Cagney) writes:
>Here's the output from several further runs with -w:
># mbrlabel /dev/rsd0
>Found MSDOS partition; size 1073741824 (524288 MB), offset 2048
> skipping existing MSDOS partition at slot a.
>Found 4.2BSD partition; size 524288000 (256000 MB), offset 1073743872
> adding 4.2BSD partition to slot e.
>5 partitions:
># size offset fstype [fsize bsize cpg/sgs]
> a: 1073741824 2048 MSDOS # (Cyl. 1 -
>524288)
> b: 16384 1073743872 4.2BSD 1024 8192 16 # (Cyl. 524289 -
>524296)
> c: 1952151552 0 unused 0 0 # (Cyl. 0 -
>953198)
> d: 16384 1073743872 4.2BSD 1024 8192 16 # (Cyl. 524289 -
>524296)
> e: 16384 1073743872 4.2BSD 1024 8192 16 # (Cyl. 524289 -
>524296)
>notice how it is breeding partitions ...
That looks like a non-i386 system (c seems to be the raw partition)
and a bug.
Yes, it is a Pi. (arm). 1tb usb disk so C is the full disk. It the disk is meant to have two partitions and some free space:
From dmesg:
sd0 at scsibus0 target 0 lun 0: <WD, My Passport 070A, 1030> disk fixed
sd0: fabricating a geometry
sd0: 930 GB, 953199 cyl, 64 head, 32 sec, 512 bytes/sect x 1952151552 sectors
and from fdisk:
fdisk: Cannot determine the number of heads
Disk: /dev/rsd0c
NetBSD disklabel disk geometry:
cylinders: 953199, heads: 64, sectors/track: 32 (2048 sectors/cylinder)
total sectors: 1952151552
BIOS disk geometry:
cylinders: 1023, heads: 255, sectors/track: 63 (16065 sectors/cylinder)
total sectors: 1952151552
Partitions aligned to 2048 sector boundaries, offset 2048
Partition table:
0: Primary DOS with 32 bit FAT - LBA (sysid 12)
start 2048, size 1073741824 (524288 MB, Cyls 0-66837/118/33)
1: NetBSD (sysid 169)
start 1073743872, size 524288000 (256000 MB, Cyls 66837/118/34-99472/225/17)
PBR is not bootable: All bytes are identical (0xff)
2: <UNUSED>
3: <UNUSED>
Hmm, the man page has "The raw partition (typically partition c, but d on i386 and some other platforms) is left alone during this process.". Why? Shouldn't it try to always try to make C the NetBSD partition, and D the disk?
And to get off topic, instead of starting A up, would it be better to pack the other partitions at the end of the table, keep A (root) and B (swap) free? The first thing I'm going to do with disklabel is that shuffle.
For some reason mbrlabel forces the size of a BSD partition to 16384,
which also defeats the duplicate detection. BSD partitions are those
with an MBR type of
165 MBR_PTYPE_386BSD
166 MBR_PTYPE_OPENBSD
168 MBR_PTYPE_APPLE_UFS
169 MBR_PTYPE_NETBSD
That's probably done because BSD partitions also use the other
parameters (fsize,bsize,cpg/sgs) that can only be guessed without
further analyzing the disk contents.
Fdisk seems to know. This behavior seems to make mbrlabel less useful. I was hoping it could predictably pre-populate and write a disklabel.
The bug doesn't usually show up on i386 systems because the only
BSD type MBR partition found is usually the raw partition which
is ignored anyway.
>A reboot, however, seems to have flushed what ever was going wrong:
That's because 'w' alone doesn't write to the disk but only updates the
in-core version of the disklabel.
Ah. I should be specifying -w -r.