Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
"gpart add" falsely claiming "No space left on device"
251 views
Skip to first unread message
Perry Hutchison
Sep 6, 2016, 3:43:54 AM9/6/16
to
I copied the 10.3-RELEASE memstick.img to a 4GB flash drive, then used
"gpart recover" to resize the partition table to the media. After that
"gpart show" reports:
# gpart show da2
=> 3 7811067 da2 GPT (3.7G)
3 32 1 freebsd-boot (16K)
35 1348832 2 freebsd-ufs (659M)
1348867 2048 3 freebsd-swap (1.0M)
1350915 6460155 - free - (3.1G)
but "gpart add" refuses to add a second freebsd-ufs partition in that
supposedly-free space:
# gpart add -t freebsd-ufs -l pkgs -f x da2
gpart: index '4': No space left on device
# gpart add -t freebsd-ufs -l pkgs -f x -b 1350915 -s 6460155 da2
gpart: index '4': No space left on device
All of these partitions are unmounted.
What am I doing wrong?
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
"gpart recover" to resize the partition table to the media. After that
"gpart show" reports:
# gpart show da2
=> 3 7811067 da2 GPT (3.7G)
3 32 1 freebsd-boot (16K)
35 1348832 2 freebsd-ufs (659M)
1348867 2048 3 freebsd-swap (1.0M)
1350915 6460155 - free - (3.1G)
but "gpart add" refuses to add a second freebsd-ufs partition in that
supposedly-free space:
# gpart add -t freebsd-ufs -l pkgs -f x da2
gpart: index '4': No space left on device
# gpart add -t freebsd-ufs -l pkgs -f x -b 1350915 -s 6460155 da2
gpart: index '4': No space left on device
All of these partitions are unmounted.
What am I doing wrong?
_______________________________________________
freebsd-...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
Warren Block
Sep 6, 2016, 10:18:14 AM9/6/16
to
On Tue, 6 Sep 2016, Perry Hutchison wrote:
> I copied the 10.3-RELEASE memstick.img to a 4GB flash drive, then used
> "gpart recover" to resize the partition table to the media. After that
> "gpart show" reports:
>
> # gpart show da2
> => 3 7811067 da2 GPT (3.7G)
> 3 32 1 freebsd-boot (16K)
> 35 1348832 2 freebsd-ufs (659M)
> 1348867 2048 3 freebsd-swap (1.0M)
> 1350915 6460155 - free - (3.1G)
>
> but "gpart add" refuses to add a second freebsd-ufs partition in that
> supposedly-free space:
>
> # gpart add -t freebsd-ufs -l pkgs -f x da2
> gpart: index '4': No space left on device
>
> # gpart add -t freebsd-ufs -l pkgs -f x -b 1350915 -s 6460155 da2
> gpart: index '4': No space left on device
The second one makes more sense, as the first '-f x' would/should have
> I copied the 10.3-RELEASE memstick.img to a 4GB flash drive, then used
> "gpart recover" to resize the partition table to the media. After that
> "gpart show" reports:
>
> # gpart show da2
> => 3 7811067 da2 GPT (3.7G)
> 3 32 1 freebsd-boot (16K)
> 35 1348832 2 freebsd-ufs (659M)
> 1348867 2048 3 freebsd-swap (1.0M)
> 1350915 6460155 - free - (3.1G)
>
> but "gpart add" refuses to add a second freebsd-ufs partition in that
> supposedly-free space:
>
> # gpart add -t freebsd-ufs -l pkgs -f x da2
> gpart: index '4': No space left on device
>
> # gpart add -t freebsd-ufs -l pkgs -f x -b 1350915 -s 6460155 da2
> gpart: index '4': No space left on device
allocated that space (in an uncommitted operation). Don't know about
the first one, unless you have tried it before.
Why bother with '-f x'? Why not just do the operation immediately?
Ian Smith
Sep 6, 2016, 10:59:48 AM9/6/16
to
In freebsd-questions Digest, Vol 640, Issue 2, Message: 5
How did you 'copy' the memstick.img to the flash drive?
root@x200:~ # ll /dev/da*
crw-rw---- 1 root operator 0x8c Sep 6 19:12 /dev/da0
crw-rw---- 1 root operator 0x8d Sep 6 19:12 /dev/da0a
root@x200:~ #
gpart show da0
=> 0 1974272 da0 BSD (964M)
0 1523248 1 freebsd-ufs (743M)
1523248 451024 - free - (220M)
That's a 10.3 memstick.img dd'd to a 1G stick. For some bizarre reason,
maybe 10? years on, these are still being made as pseudo-floppy images,
here as da0a, rather than something sane like da0s1a, where you could
merrily add more (MBR) partitions and use boot0cfg to choose between
them - as PC-BSD has been doing for years - or with GPT, at least extra
data partition/s as you want here, useful in itself.
It's actually a bodgy image; here's what fdisk makes of that 1G stick:
root@x200:~ # fdisk /dev/da0
******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=973 heads=255 sectors/track=63 (16065 blks/cyl)
parameters to be used for BIOS calculations are:
cylinders=973 heads=255 sectors/track=63 (16065 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:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 0, size 50000 (24 Meg), flag 80 (active)
beg: cyl 0/ head 0/ sector 1;
end: cyl 1023/ head 254/ sector 63
Most of which is nonsense, except that it does start at sector 0, while
imcorporating an MBR and a BSD disklabel, and of course size is bogus.
Sadly, nobody has yet duplicated something like boot0cfg for GPT, so
multibooting from GPT seems to require GPL stuff like GRUB, or maybe
the more complicated (for me, anyway) Boot Environments and such.
Trying to solve this, I've used Darren Pilgrim's dvd1_to_memstick.sh
successfully to make bootable memsticks from dvd1 images, though never
solved the 'bsdinstall / bsdconfig can't find the packages' issue, for
which the release notes for 10.3 at least, and 11, have a workaround.
I've run out of puff to try incorporating that this time around.
FWIW, here's my (excessivey paranoid) adaptation of Darren's script; but
it still uses MBR layout and winds up as /dev/daXa when mounted|booted.
Perhaps you or Warren or someone could adapt it for GPT, though myself
I'd still prefer it as MBR sliced, so you could boot, say, 10.3 or 11.0,
i386 or amd63, with the DVD packages, from say one 8- or 16GB stick. It
should be clear that after the tar poipeline, there's scope to play.
cheers, Ian (please cc me, I take the digest)
=======
#!/bin/sh
#% originally by Darren Pilgrim 17/12/13 from http://pastebin.com/fzgVaCgW
#% smi...@nimnet.asn.au 22/2/14 for FreeBSD 8.2-R (no makefs label option)
#% compaction & extra paranoia 23/6/14; rm 8.2 hack, quit() tidyup 11/9/14
PATH=/bin:/usr/bin:/sbin:/usr/sbin
export PATH
if [ -z "$*" ]; then
echo `basename $0 [dvd1 img] [dvd1 dir] [memstick img] [memstick dir]`
echo ' [dvd1 img] is the dvd1 image to convert'
echo ' [dvd1 dir] is the mountpoint for the dvd1 image'
echo ' [memstick img] is name of the memstick image file to create'
echo ' [memstick dir] is temporary work directory for memstick contents'
exit 1
fi
quit() { echo "$1" ; exit 1 ; }
[ `id -u` -ne 0 ] && quit "This script must be run as root"
[ ! -f $1 ] && quit "Source dvd1 image $1 does not exist"
[ ! -d $2 ] && quit "dvd1 dir mountpoint $2 must be a directory"
[ -e $3 ] && quit "Memstick img file $3 already exists"
[ ! -d $4 ] && quit "Memstick dir $4 not an existing directory"
[ `du -sm $4 | awk '{print $1}'` -gt 2 ] && quit "Memstick dir $4 not empty"
unit=`mdconfig -f $1` || quit "dvd1 img mdconfig fail"
mount_cd9660 /dev/$unit $2 || quit "mount_cd9660 fail"
tar cf - -C $2 . | tar xpf - -C $4 || quit "tar pipeline fail"
umount $2 && mdconfig -d -u $unit || quit "Could not umount dvd1"
echo '/dev/ufs/FreeBSD_Install / ufs ro,noatime 1 1' > $4/etc/fstab
makefs -B little -o label=FreeBSD_Install $3 $4 || quit "makefs fail"
unit=`mdconfig -f $3` || quit "memstick img mdconfig fail"
gpart create -s BSD $unit || quit "gpart create -s BSD fail"
gpart bootcode -b $4/boot/boot $unit || quit "gpart bootcode fail"
gpart add -t freebsd-ufs $unit || quit "gpart add -t freebsd-ufs fail"
mdconfig -d -u $unit
echo "Memstick image $3 created:" ; ls -l $3
=======
On Tue, 06 Sep 2016 00:21:08 -0700 per...@pluto.rain.com (Perry Hutchison) wrote:
> I copied the 10.3-RELEASE memstick.img to a 4GB flash drive, then used
> "gpart recover" to resize the partition table to the media. After that
> "gpart show" reports:
>
> # gpart show da2
> => 3 7811067 da2 GPT (3.7G)
> 3 32 1 freebsd-boot (16K)
> 35 1348832 2 freebsd-ufs (659M)
> 1348867 2048 3 freebsd-swap (1.0M)
> 1350915 6460155 - free - (3.1G)
>
> but "gpart add" refuses to add a second freebsd-ufs partition in that
> supposedly-free space:
>
> # gpart add -t freebsd-ufs -l pkgs -f x da2
> gpart: index '4': No space left on device
>
> # gpart add -t freebsd-ufs -l pkgs -f x -b 1350915 -s 6460155 da2
> gpart: index '4': No space left on device
>
> I copied the 10.3-RELEASE memstick.img to a 4GB flash drive, then used
> "gpart recover" to resize the partition table to the media. After that
> "gpart show" reports:
>
> # gpart show da2
> => 3 7811067 da2 GPT (3.7G)
> 3 32 1 freebsd-boot (16K)
> 35 1348832 2 freebsd-ufs (659M)
> 1348867 2048 3 freebsd-swap (1.0M)
> 1350915 6460155 - free - (3.1G)
>
> but "gpart add" refuses to add a second freebsd-ufs partition in that
> supposedly-free space:
>
> # gpart add -t freebsd-ufs -l pkgs -f x da2
> gpart: index '4': No space left on device
>
> # gpart add -t freebsd-ufs -l pkgs -f x -b 1350915 -s 6460155 da2
> gpart: index '4': No space left on device
>
> All of these partitions are unmounted.
>
> What am I doing wrong?
Hi Perry,
>
> What am I doing wrong?
How did you 'copy' the memstick.img to the flash drive?
root@x200:~ # ll /dev/da*
crw-rw---- 1 root operator 0x8c Sep 6 19:12 /dev/da0
crw-rw---- 1 root operator 0x8d Sep 6 19:12 /dev/da0a
root@x200:~ #
gpart show da0
=> 0 1974272 da0 BSD (964M)
0 1523248 1 freebsd-ufs (743M)
1523248 451024 - free - (220M)
That's a 10.3 memstick.img dd'd to a 1G stick. For some bizarre reason,
maybe 10? years on, these are still being made as pseudo-floppy images,
here as da0a, rather than something sane like da0s1a, where you could
merrily add more (MBR) partitions and use boot0cfg to choose between
them - as PC-BSD has been doing for years - or with GPT, at least extra
data partition/s as you want here, useful in itself.
It's actually a bodgy image; here's what fdisk makes of that 1G stick:
root@x200:~ # fdisk /dev/da0
******* Working on device /dev/da0 *******
parameters extracted from in-core disklabel are:
cylinders=973 heads=255 sectors/track=63 (16065 blks/cyl)
parameters to be used for BIOS calculations are:
cylinders=973 heads=255 sectors/track=63 (16065 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:
<UNUSED>
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 0, size 50000 (24 Meg), flag 80 (active)
beg: cyl 0/ head 0/ sector 1;
end: cyl 1023/ head 254/ sector 63
Most of which is nonsense, except that it does start at sector 0, while
imcorporating an MBR and a BSD disklabel, and of course size is bogus.
Sadly, nobody has yet duplicated something like boot0cfg for GPT, so
multibooting from GPT seems to require GPL stuff like GRUB, or maybe
the more complicated (for me, anyway) Boot Environments and such.
Trying to solve this, I've used Darren Pilgrim's dvd1_to_memstick.sh
successfully to make bootable memsticks from dvd1 images, though never
solved the 'bsdinstall / bsdconfig can't find the packages' issue, for
which the release notes for 10.3 at least, and 11, have a workaround.
I've run out of puff to try incorporating that this time around.
FWIW, here's my (excessivey paranoid) adaptation of Darren's script; but
it still uses MBR layout and winds up as /dev/daXa when mounted|booted.
Perhaps you or Warren or someone could adapt it for GPT, though myself
I'd still prefer it as MBR sliced, so you could boot, say, 10.3 or 11.0,
i386 or amd63, with the DVD packages, from say one 8- or 16GB stick. It
should be clear that after the tar poipeline, there's scope to play.
cheers, Ian (please cc me, I take the digest)
=======
#!/bin/sh
#% originally by Darren Pilgrim 17/12/13 from http://pastebin.com/fzgVaCgW
#% smi...@nimnet.asn.au 22/2/14 for FreeBSD 8.2-R (no makefs label option)
#% compaction & extra paranoia 23/6/14; rm 8.2 hack, quit() tidyup 11/9/14
PATH=/bin:/usr/bin:/sbin:/usr/sbin
export PATH
if [ -z "$*" ]; then
echo `basename $0 [dvd1 img] [dvd1 dir] [memstick img] [memstick dir]`
echo ' [dvd1 img] is the dvd1 image to convert'
echo ' [dvd1 dir] is the mountpoint for the dvd1 image'
echo ' [memstick img] is name of the memstick image file to create'
echo ' [memstick dir] is temporary work directory for memstick contents'
exit 1
fi
quit() { echo "$1" ; exit 1 ; }
[ `id -u` -ne 0 ] && quit "This script must be run as root"
[ ! -f $1 ] && quit "Source dvd1 image $1 does not exist"
[ ! -d $2 ] && quit "dvd1 dir mountpoint $2 must be a directory"
[ -e $3 ] && quit "Memstick img file $3 already exists"
[ ! -d $4 ] && quit "Memstick dir $4 not an existing directory"
[ `du -sm $4 | awk '{print $1}'` -gt 2 ] && quit "Memstick dir $4 not empty"
unit=`mdconfig -f $1` || quit "dvd1 img mdconfig fail"
mount_cd9660 /dev/$unit $2 || quit "mount_cd9660 fail"
tar cf - -C $2 . | tar xpf - -C $4 || quit "tar pipeline fail"
umount $2 && mdconfig -d -u $unit || quit "Could not umount dvd1"
echo '/dev/ufs/FreeBSD_Install / ufs ro,noatime 1 1' > $4/etc/fstab
makefs -B little -o label=FreeBSD_Install $3 $4 || quit "makefs fail"
unit=`mdconfig -f $3` || quit "memstick img mdconfig fail"
gpart create -s BSD $unit || quit "gpart create -s BSD fail"
gpart bootcode -b $4/boot/boot $unit || quit "gpart bootcode fail"
gpart add -t freebsd-ufs $unit || quit "gpart add -t freebsd-ufs fail"
mdconfig -d -u $unit
echo "Memstick image $3 created:" ; ls -l $3
=======
Perry Hutchison
Sep 7, 2016, 2:12:32 AM9/7/16
to
Warren Block <wbl...@wonkity.com> wrote:
> On Tue, 6 Sep 2016, Perry Hutchison wrote:
> > I copied the 10.3-RELEASE memstick.img to a 4GB flash drive, then
> > used "gpart recover" to resize the partition table to the media.
> > After that "gpart show" reports:
> >
> > # gpart show da2
> > => 3 7811067 da2 GPT (3.7G)
> > 3 32 1 freebsd-boot (16K)
> > 35 1348832 2 freebsd-ufs (659M)
> > 1348867 2048 3 freebsd-swap (1.0M)
> > 1350915 6460155 - free - (3.1G)
> >
> > but "gpart add" refuses to add a second freebsd-ufs partition in
> > that supposedly-free space:
> >
> > # gpart add -t freebsd-ufs -l pkgs -f x da2
> > gpart: index '4': No space left on device
> >
> > # gpart add -t freebsd-ufs -l pkgs -f x -b 1350915 -s 6460155 da2
> > gpart: index '4': No space left on device
>
> The second one makes more sense, as the first '-f x' would/should
> have allocated that space (in an uncommitted operation). Don't know
> about the first one, unless you have tried it before.
It gave that result the very first time, and a subsequent "gpart show"
> On Tue, 6 Sep 2016, Perry Hutchison wrote:
> > I copied the 10.3-RELEASE memstick.img to a 4GB flash drive, then
> > used "gpart recover" to resize the partition table to the media.
> > After that "gpart show" reports:
> >
> > # gpart show da2
> > => 3 7811067 da2 GPT (3.7G)
> > 3 32 1 freebsd-boot (16K)
> > 35 1348832 2 freebsd-ufs (659M)
> > 1348867 2048 3 freebsd-swap (1.0M)
> > 1350915 6460155 - free - (3.1G)
> >
> > but "gpart add" refuses to add a second freebsd-ufs partition in
> > that supposedly-free space:
> >
> > # gpart add -t freebsd-ufs -l pkgs -f x da2
> > gpart: index '4': No space left on device
> >
> > # gpart add -t freebsd-ufs -l pkgs -f x -b 1350915 -s 6460155 da2
> > gpart: index '4': No space left on device
>
> The second one makes more sense, as the first '-f x' would/should
> have allocated that space (in an uncommitted operation). Don't know
> about the first one, unless you have tried it before.
produced the same output as before. I tried the second in case the
reason for the first failing was that (absent -b and -s) it defaulted
to trying to define a partition covering the whole device, failing
because the device was not empty.
> Why bother with '-f x'? Why not just do the operation immediately?
except surviving a reboot, in particular a subsequent "gpart show",
but without writing anything to the stick in the (likely) event that
I did something wrong that would corrupt the stick if committed.
(I do not pretend to understand gpart, and I've been finding its
manpage horribly terse.)
Perry Hutchison
Sep 7, 2016, 2:12:44 AM9/7/16
to
Ian Smith <smi...@nimnet.asn.au> wrote:
> In freebsd-questions Digest, Vol 640, Issue 2, Message: 5
> On Tue, 06 Sep 2016 00:21:08 -0700 per...@pluto.rain.com (Perry Hutchison)
> wrote:
> > I copied the 10.3-RELEASE memstick.img to a 4GB flash drive, then
> > used "gpart recover" to resize the partition table to the media.
> > After that "gpart show" reports:
> >
> > # gpart show da2
> > => 3 7811067 da2 GPT (3.7G)
> > 3 32 1 freebsd-boot (16K)
> > 35 1348832 2 freebsd-ufs (659M)
> > 1348867 2048 3 freebsd-swap (1.0M)
> > 1350915 6460155 - free - (3.1G)
> >
> > but "gpart add" refuses to add a second freebsd-ufs partition in
> > that supposedly-free space:
> >
> > # gpart add -t freebsd-ufs -l pkgs -f x da2
> > gpart: index '4': No space left on device
> >
> > # gpart add -t freebsd-ufs -l pkgs -f x -b 1350915 -s 6460155 da2
> > gpart: index '4': No space left on device
> >
> > All of these partitions are unmounted.
> >
> > What am I doing wrong?
>
> Hi Perry,
>
> How did you 'copy' the memstick.img to the flash drive?
# dd if=FreeBSD-10.3-RELEASE-i386-memstick.img of=/dev/da2 bs=71b
> In freebsd-questions Digest, Vol 640, Issue 2, Message: 5
> On Tue, 06 Sep 2016 00:21:08 -0700 per...@pluto.rain.com (Perry Hutchison)
> wrote:
> > I copied the 10.3-RELEASE memstick.img to a 4GB flash drive, then
> > used "gpart recover" to resize the partition table to the media.
> > After that "gpart show" reports:
> >
> > # gpart show da2
> > => 3 7811067 da2 GPT (3.7G)
> > 3 32 1 freebsd-boot (16K)
> > 35 1348832 2 freebsd-ufs (659M)
> > 1348867 2048 3 freebsd-swap (1.0M)
> > 1350915 6460155 - free - (3.1G)
> >
> > but "gpart add" refuses to add a second freebsd-ufs partition in
> > that supposedly-free space:
> >
> > # gpart add -t freebsd-ufs -l pkgs -f x da2
> > gpart: index '4': No space left on device
> >
> > # gpart add -t freebsd-ufs -l pkgs -f x -b 1350915 -s 6460155 da2
> > gpart: index '4': No space left on device
> >
> > All of these partitions are unmounted.
> >
> > What am I doing wrong?
>
> Hi Perry,
>
> How did you 'copy' the memstick.img to the flash drive?
Why bs=71b? 71*512 is the largest factor of the image size that
is a multiple of 512 and less than 126*512, so this way there is
no partial dd block at the end. (Old-timers will remember why
some of us don't like to exceed bs=126b with dd :)
BTW it did boot (I only tried single-user mode) and worked well
enough to resize itself with "gpart recover".
> root@x200:~ # ll /dev/da*
> crw-rw---- 1 root operator 0x8c Sep 6 19:12 /dev/da0
> crw-rw---- 1 root operator 0x8d Sep 6 19:12 /dev/da0a
>
> root@x200:~ #
> gpart show da0
> => 0 1974272 da0 BSD (964M)
> 0 1523248 1 freebsd-ufs (743M)
> 1523248 451024 - free - (220M)
crw-r----- 1 root operator 0, 116 Aug 31 20:05 /dev/da0
crw-r----- 1 root operator 0, 117 Aug 31 20:05 /dev/da0s1
crw-r----- 1 root operator 0, 118 Aug 31 20:05 /dev/da0s2
crw-r----- 1 root operator 0, 119 Aug 31 20:05 /dev/da0s3
crw-r----- 1 root operator 0, 87 Sep 5 18:03 /dev/da1
crw-r----- 1 root operator 0, 88 Sep 5 18:03 /dev/da1a
crw-r----- 1 root operator 0, 112 Sep 5 18:21 /dev/da2
crw-r----- 1 root operator 0, 114 Sep 5 18:21 /dev/da2p1
crw-r----- 1 root operator 0, 115 Sep 5 18:21 /dev/da2p2
crw-r----- 1 root operator 0, 120 Sep 5 18:21 /dev/da2p3
da0 is an actual SCSI disk, partitioned the old way (MBR), and
containing a different OS.
da1 is an 8.1 memstick, "partitioned" the way 8.x memsticks were done.
da2 is the 10.3 memstick, which appears to be GPT.
> That's a 10.3 memstick.img dd'd to a 1G stick. For some bizarre reason,
> maybe 10? years on, these are still being made as pseudo-floppy images,
> here as da0a, rather than something sane like da0s1a, where you could
> merrily add more (MBR) partitions and use boot0cfg to choose between
> them - as PC-BSD has been doing for years - or with GPT, at least extra
> data partition/s as you want here, useful in itself.
Mine is FreeBSD-10.3-RELEASE-i386-memstick.img.xz of
3/24/2016, downloaded from ftp14.us.freebsd.org on 5/1/2016
(and decompressed before being dd'd to the stick , of course).
> It's actually a bodgy image; here's what fdisk makes of that 1G stick:
>
> root@x200:~ # fdisk /dev/da0
> ******* Working on device /dev/da0 *******
> parameters extracted from in-core disklabel are:
> cylinders=973 heads=255 sectors/track=63 (16065 blks/cyl)
>
> parameters to be used for BIOS calculations are:
> cylinders=973 heads=255 sectors/track=63 (16065 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:
> <UNUSED>
> The data for partition 2 is:
> <UNUSED>
> The data for partition 3 is:
> <UNUSED>
> The data for partition 4 is:
> sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
> start 0, size 50000 (24 Meg), flag 80 (active)
> beg: cyl 0/ head 0/ sector 1;
> end: cyl 1023/ head 254/ sector 63
>
> Most of which is nonsense, except that it does start at sector 0, while
> imcorporating an MBR and a BSD disklabel, and of course size is bogus.
******* Working on device /dev/da2 *******
parameters extracted from in-core disklabel are:
cylinders=486 heads=255 sectors/track=63 (16065 blks/cyl)
parameters to be used for BIOS calculations are:
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
start 1, size 7811071 (3813 Meg), flag 0
beg: cyl 0/ head 0/ sector 2;
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>
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
which I take to be the protective MBR of the GPT scheme.
Warren Block
Sep 7, 2016, 8:46:42 AM9/7/16
to
to fdisk and other older tools. What does the man page need? More
examples?
http://www.wonkity.com/~wblock/docs/html/disksetup.html
Perry Hutchison
Sep 8, 2016, 1:41:05 AM9/8/16
to
For starters, default values for -b, -s, -t, and -i in "gpart add".
(I guess -i defaults to "lowest not currently in use", but what about
the others?) List of what-all "attributes" can be set and what they
do. Explanation of when one would use -b vs. -p in "gpart bootcode"
since they are apparently different ways of specifying where the
bootcode comes from (but then your example uses both?) Description
of how to show the current state of the provider vs what it would look
like if pending changes were committed.
> More examples?
>
> http://www.wonkity.com/~wblock/docs/html/disksetup.html
That could do with some explanations of where the "magic numbers"
came from, e.g. the "-b 40" in the gpboot partition and the "-b 1M"
in gprootfs. I suppose there must be some reason for leaving those
3.0k and 492k free spaces around gpboot, but it isn't obvious.
(I guess -i defaults to "lowest not currently in use", but what about
the others?) List of what-all "attributes" can be set and what they
do. Explanation of when one would use -b vs. -p in "gpart bootcode"
since they are apparently different ways of specifying where the
bootcode comes from (but then your example uses both?) Description
of how to show the current state of the provider vs what it would look
like if pending changes were committed.
> More examples?
>
> http://www.wonkity.com/~wblock/docs/html/disksetup.html
That could do with some explanations of where the "magic numbers"
came from, e.g. the "-b 40" in the gpboot partition and the "-b 1M"
in gprootfs. I suppose there must be some reason for leaving those
3.0k and 492k free spaces around gpboot, but it isn't obvious.
Brandon J. Wandersee
Sep 8, 2016, 5:18:59 PM9/8/16
to
Perry Hutchison writes:
> Warren Block <wbl...@wonkity.com> wrote:
>
>> What does the man page need?
>
> For starters, default values for -b, -s, -t, and -i in "gpart add".
> (I guess -i defaults to "lowest not currently in use", but what about
> the others?)
the start of the disk. '-i' defaults to the lowest available
integer. '-s' defaults to everything available. '-t' default to nothing,
because it would be senseless to assume the type of a partition;
gpart(8) will exit with an error if you don't provide it.
> List of what-all "attributes" can be set and what they
> do.
> Explanation of when one would use -b vs. -p in "gpart bootcode"
> since they are apparently different ways of specifying where the
> bootcode comes from (but then your example uses both?)
'-p' specifies how and where. How they're used depends on your partition
scheme and motherboard. See "BOOTSTRAPPING."
> Description of how to show the current state of the provider vs what
> it would look like if pending changes were committed.
user/administrator has---or at least *should* have---a good idea of what
state the disk is in before they start messing with the existing
(presumably good) partition table.
> I suppose there must be some reason for leaving those
> 3.0k and 492k free spaces around gpboot, but it isn't obvious.
--
:: Brandon J. Wandersee
:: brandon....@gmail.com
:: --------------------------------------------------
:: 'The best design is as little design as possible.'
:: --- Dieter Rams ----------------------------------
Perry Hutchison
Sep 9, 2016, 5:15:12 AM9/9/16
to
"Brandon J. Wandersee" <brandon....@gmail.com> wrote:
> Perry Hutchison writes:
> > Warren Block <wbl...@wonkity.com> wrote:
> >> What does the man page need?
> >
> > For starters, default values for -b, -s, -t, and -i in "gpart add".
> > (I guess -i defaults to "lowest not currently in use", but what about
> > the others?)
>
> The defaults are exactly what you'd expect them to be. '-b' defaults
> to the start of the disk.
That would explain why my first attempt failed, since that default
> Perry Hutchison writes:
> > Warren Block <wbl...@wonkity.com> wrote:
> >> What does the man page need?
> >
> > For starters, default values for -b, -s, -t, and -i in "gpart add".
> > (I guess -i defaults to "lowest not currently in use", but what about
> > the others?)
>
> The defaults are exactly what you'd expect them to be. '-b' defaults
> to the start of the disk.
is useful only if no partitions are already defined.
Other reasonable defaults would be the start of the first (lowest
addressed), last (highest addressed), or largest free area. In any
event, the man page ought to say what the default is.
> '-i' defaults to the lowest available integer.
> '-s' defaults to everything available.
the first free block, or the largest free block? (One hopes, not
the sum of all free blocks :) Again, the man page should say!
> '-t' default to nothing,
> because it would be senseless to assume the type of a partition;
> gpart(8) will exit with an error if you don't provide it.
section, if not for the fact that -b and -s (which apparently do
have defaults, even though the man page does not say what they are)
are not bracketed either.
> > List of what-all "attributes" can be set and what they do.
>
> See "ATTRIBUTES."
FreeBSD 8.1).
> > Explanation of when one would use -b vs. -p in "gpart bootcode"
> > since they are apparently different ways of specifying where the
> > bootcode comes from (but then your example uses both?)
>
> '-b' and '-p' specify different values. '-b' specifies what is written;
> '-p' specifies how and where. How they're used depends on your partition
> scheme and motherboard. See "BOOTSTRAPPING."
> > Description of how to show the current state of the provider vs what
> > it would look like if pending changes were committed.
>
> I don't know if this is possible. I believe it's assumed that the
> user/administrator has---or at least *should* have---a good idea
> of what state the disk is in before they start messing with the
> existing (presumably good) partition table.
I can't say "show me what would change if I committed this set" --
the same general idea as doing
:w !diff % -
in vi before saving the file.
> > I suppose there must be some reason for leaving those
> > 3.0k and 492k free spaces around gpboot, but it isn't obvious.
>
> Partition alignment.
is often the case with newer disk drives) -- but 1M? Seems a bit
much, which is why it would be useful for that page to include a
more detailed explanation.
Getting back to the original inquiry, I'm still mystified as to
why gpart won't create a partition in the space that it reports
as being free. Does anyone have a clue what is going on, or how
to find out?
Brandon J. Wandersee
Sep 9, 2016, 9:50:04 AM9/9/16
to
> "Brandon J. Wandersee" <brandon....@gmail.com> wrote:
>
>> '-s' defaults to everything available.
>
> "available" on the entire disk (as if no partitions were defined),
> the first free block, or the largest free block? (One hopes, not
> the sum of all free blocks :) Again, the man page should say!
partitions are present on the disk, you get one partition starting at
the first sector and ending at the last, less any space needed for
scheme-specific metadata and buffer space resulting from '-a' or '-b.'
If partitions exist, you'll get a partition starting at the first free
sector and extending until you hit another partition or the end of the
disk, assuming the partition can be created in that space while
abiding by traits set with '-a' or '-b'.
Obviously partitions can only consist of contiguous space, and the
command will not automatically destroy an existing partition
layout. `gpart add` *adds a partition.* Deleting and resizing
partitions, and destroying tables, are handled by separate commands.
> [The need to specify partition type] _could_ be implied by its not
> being bracketed in the usage section, if not for the fact that -b and
> -s (which apparently do have defaults, even though the man page does
> not say what they are) are not bracketed either.
> There's no [ATTRIBUTES] section in the gpart(8) man page I'm looking at (on
> -s (which apparently do have defaults, even though the man page does
> not say what they are) are not bracketed either.
> FreeBSD 8.1) ... There's no BOOTSTRAPPING section in this gpart(8)
> man page, either.
All of this---including the bracketed '-s' and '-b'---are present in
the latest version of the man page.[1] 8.1 hasn't been supported for four
years, so it's documentation won't be updated.
> Alignment to 4k makes sense if the physical sector size is 4k (as
> is often the case with newer disk drives) -- but 1M? Seems a bit
> much, which is why it would be useful for that page to include a
> more detailed explanation.
sector boundaries regardless a disk's actual or reported sector
size. Newer HDD firmwares often report having 512k sectors for
backwards compatibility, even when they have 4k sectors, while SSDs
don't really have an industry-standard sector size and report whatever
the manufacturer feels like. But in all cases, they're factors of
1Mb. The point is that you either spend some time and effort
researching each disk model in the system and doing some math, or you
just sacrifice a megabyte or two for guaranteed alignment and be done
with it.
[1]: https://www.freebsd.org/cgi/man.cgi?query=gpart&apropos=0&sektion=8&manpath=FreeBSD+10.3-RELEASE+and+Ports&arch=default&format=html
--
:: Brandon J. Wandersee
:: brandon....@gmail.com
:: --------------------------------------------------
:: 'The best design is as little design as possible.'
:: --- Dieter Rams ----------------------------------
Brandon J. Wandersee
Sep 9, 2016, 10:46:29 AM9/9/16
to
manually, either from source (explained in the "Handbook") or with the
misc/freebsd-doc-* port/package. Replace '*' with your native
language. But since it looks like you're working on upgrading to 10.3,
just use the online docs.
Ian Smith
Sep 9, 2016, 1:58:03 PM9/9/16
to
On Tue, 6 Sep 2016 22:54:24 -0700, Perry Hutchison wrote:
> Ian Smith <smi...@nimnet.asn.au> wrote:
> > In freebsd-questions Digest, Vol 640, Issue 2, Message: 5
> > On Tue, 06 Sep 2016 00:21:08 -0700 per...@pluto.rain.com (Perry Hutchison)
> > wrote:
> > > I copied the 10.3-RELEASE memstick.img to a 4GB flash drive, then
> > > used "gpart recover" to resize the partition table to the media.
> > > After that "gpart show" reports:
> > >
> > > # gpart show da2
> > > => 3 7811067 da2 GPT (3.7G)
> > > 3 32 1 freebsd-boot (16K)
> > > 35 1348832 2 freebsd-ufs (659M)
> > > 1348867 2048 3 freebsd-swap (1.0M)
> > > 1350915 6460155 - free - (3.1G)
[..]
> Ian Smith <smi...@nimnet.asn.au> wrote:
> > In freebsd-questions Digest, Vol 640, Issue 2, Message: 5
> > On Tue, 06 Sep 2016 00:21:08 -0700 per...@pluto.rain.com (Perry Hutchison)
> > wrote:
> > > I copied the 10.3-RELEASE memstick.img to a 4GB flash drive, then
> > > used "gpart recover" to resize the partition table to the media.
> > > After that "gpart show" reports:
> > >
> > > # gpart show da2
> > > => 3 7811067 da2 GPT (3.7G)
> > > 3 32 1 freebsd-boot (16K)
> > > 35 1348832 2 freebsd-ufs (659M)
> > > 1348867 2048 3 freebsd-swap (1.0M)
> > > 1350915 6460155 - free - (3.1G)
> > How did you 'copy' the memstick.img to the flash drive?
>
> # dd if=FreeBSD-10.3-RELEASE-i386-memstick.img of=/dev/da2 bs=71b
>
> Why bs=71b? 71*512 is the largest factor of the image size that
> is a multiple of 512 and less than 126*512, so this way there is
> no partial dd block at the end. (Old-timers will remember why
> some of us don't like to exceed bs=126b with dd :)
curiosity. I used to use bs=10240 as earlier recommended, now just:
# dd if=FreeBSD-10.3-RELEASE-amd64-memstick.img \
of=/dev/da0 bs=1m conv=sync
> BTW it did boot (I only tried single-user mode) and worked well
> enough to resize itself with "gpart recover".
> > root@x200:~ # ll /dev/da*
> > crw-rw---- 1 root operator 0x8c Sep 6 19:12 /dev/da0
> > crw-rw---- 1 root operator 0x8d Sep 6 19:12 /dev/da0a
> >
> > root@x200:~ # gpart show da0
> > => 0 1974272 da0 BSD (964M)
> > 0 1523248 1 freebsd-ufs (743M)
> > 1523248 451024 - free - (220M)
>
> # ll /dev/da*
> crw-r----- 1 root operator 0, 116 Aug 31 20:05 /dev/da0
> crw-r----- 1 root operator 0, 117 Aug 31 20:05 /dev/da0s1
> crw-r----- 1 root operator 0, 118 Aug 31 20:05 /dev/da0s2
> crw-r----- 1 root operator 0, 119 Aug 31 20:05 /dev/da0s3
> crw-r----- 1 root operator 0, 87 Sep 5 18:03 /dev/da1
> crw-r----- 1 root operator 0, 88 Sep 5 18:03 /dev/da1a
> crw-r----- 1 root operator 0, 112 Sep 5 18:21 /dev/da2
> crw-r----- 1 root operator 0, 114 Sep 5 18:21 /dev/da2p1
> crw-r----- 1 root operator 0, 115 Sep 5 18:21 /dev/da2p2
> crw-r----- 1 root operator 0, 120 Sep 5 18:21 /dev/da2p3
>
> da0 is an actual SCSI disk, partitioned the old way (MBR), and
> containing a different OS.
> da1 is an 8.1 memstick, "partitioned" the way 8.x memsticks were done.
> da2 is the 10.3 memstick, which appears to be GPT.
>
> > That's a 10.3 memstick.img dd'd to a 1G stick. For some bizarre reason,
> > maybe 10? years on, these are still being made as pseudo-floppy images,
> Seems my 10.3 memstick.img is different than yours :(
> Mine is FreeBSD-10.3-RELEASE-i386-memstick.img.xz of
> 3/24/2016, downloaded from ftp14.us.freebsd.org on 5/1/2016
> (and decompressed before being dd'd to the stick , of course).
first wondered if your 'gpart recover' had somehow mangled it to turn it
into GPT .. but I'd tried gpart recover on the da0 above and it just
said 'da0 recovering is not needed' - which was reassuring :)
So I checked the sha256 of the memstick.img.xz, unxz'd <cough> it then
checked the sha256 of the memstick.img, all good, mdconfig'd it to see:
t23# gpart show md0
=> 3 1350912 md0 GPT (660M)
3 32 1 freebsd-boot (16K)
35 1348832 2 freebsd-ufs (659M)
1348867 2048 3 freebsd-swap (1.0M)
Sure enough, the 10.3 i386 memstick.img is GPT, while the amd64 one is
35 1348832 2 freebsd-ufs (659M)
1348867 2048 3 freebsd-swap (1.0M)
BSD as ever. gpart recover on that said 'md0 recovering is not needed'.
But according to ..
[big cut]
> # fdisk /dev/da2
> ******* Working on device /dev/da2 *******
> parameters extracted from in-core disklabel are:
> cylinders=486 heads=255 sectors/track=63 (16065 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 238 (0xee),(EFI GPT)
> start 1, size 7811071 (3813 Meg), flag 0
> beg: cyl 0/ head 0/ sector 2;
> end: cyl 1023/ head 255/ sector 63
>
> Warning: BIOS sector numbering starts with sector 1
> Information from DOS bootblock is:
> The data for partition 1 is:
> sysid 238 (0xee),(EFI GPT)
> start 1, size 7811071 (3813 Meg), flag 0
> beg: cyl 0/ head 0/ sector 2;
> end: cyl 1023/ head 255/ sector 63
>
> which I take to be the protective MBR of the GPT scheme.
Not only that, but I notice 'EFI GPT', also from fdisk md0 here:
sysid 238 (0xee),(EFI GPT)
start 1, size 1350917 (659 Meg), flag 0
Whereas with the amd64 release there's a whole extra set of images
labelled -uefi- such as: FreeBSD-10.3-RELEASE-amd64-uefi-memstick.img
I'm entirely [U]EFI ignorant, but it seems strange that the i386 images
appear to incorporate that, while amd64 uefi images are kept separate?
Can anyone explain why any of this is so? (looking at you, Warren :)
cheers, Ian
PS there are very significant differences in gpart(8) from (I diff'd)
8.2, 9.3 and 10.3, so best base discussion on the 10.3 version I guess:
https://www.freebsd.org/cgi/man.cgi?query=gpart&apropos=0&sektion=0&manpath=FreeBSD+10.3-RELEASE
Warren Block
Sep 9, 2016, 3:21:05 PM9/9/16
to
On Fri, 9 Sep 2016, Perry Hutchison wrote:
>>> List of what-all "attributes" can be set and what they do.
>>
>> See "ATTRIBUTES."
>
> There's no such section in the gpart(8) man page I'm looking at (on
> FreeBSD 8.1).
Support for 8.1 ended over four years ago. Improvements to man pages
>>> List of what-all "attributes" can be set and what they do.
>>
>> See "ATTRIBUTES."
>
> There's no such section in the gpart(8) man page I'm looking at (on
> FreeBSD 8.1).
are not MFCed back to unsupported releases.
>>> I suppose there must be some reason for leaving those
>>> 3.0k and 492k free spaces around gpboot, but it isn't obvious.
>>
>> Partition alignment.
>
> Alignment to 4k makes sense if the physical sector size is 4k (as
> is often the case with newer disk drives) -- but 1M? Seems a bit
> much, which is why it would be useful for that page to include a
> more detailed explanation.
is aligned with all the smaller values. It also better fits with the
larger internal block sizes used by SSDs and other flash devices.
Starting the first data partition at 1M is a de facto standard and
provides a little additional insurance that some rock-stupid
partitioning tool will see the partition and not destroy it.
At most, aligning to 1M wastes less than one meg of space. Not one gig,
one meg. On UEFI systems, you can even use that small amount of space
for an EFI partition.
> Getting back to the original inquiry, I'm still mystified as to
> why gpart won't create a partition in the space that it reports
> as being free. Does anyone have a clue what is going on, or how
> to find out?
quite a bit over the last few years.
Warren Block
Sep 9, 2016, 5:15:30 PM9/9/16
to
tried in long enough to know what the device will do with that.
Obviously it will ruin transfer bandwidth. Does the device actually
only write the bytes received, or does it write a full block?
Actually, I don't see any reason to use less than 64K or even 1M buffer
size. Smaller sizes add huge amounts of overhead with no benefit.
Maybe worse than nothing if the flash device is particularly dimwitted
about buffering writes.
> > BTW it did boot (I only tried single-user mode) and worked well
> > enough to resize itself with "gpart recover".
>
> Um, do you mean you ran gpart recover on the stick you'd booted off?
the install stick. It will (mostly) boot when the backup GPT table is
in the wrong spot.
> Sure enough, the 10.3 i386 memstick.img is GPT, while the amd64 one is
> BSD as ever. gpart recover on that said 'md0 recovering is not needed'.
>
> But according to ..
> [big cut]
>
> > # fdisk /dev/da2
> > ******* Working on device /dev/da2 *******
> > parameters extracted from in-core disklabel are:
> > cylinders=486 heads=255 sectors/track=63 (16065 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 238 (0xee),(EFI GPT)
> > start 1, size 7811071 (3813 Meg), flag 0
> > beg: cyl 0/ head 0/ sector 2;
> > end: cyl 1023/ head 255/ sector 63
> >
> > which I take to be the protective MBR of the GPT scheme.
> Not only that, but I notice 'EFI GPT', also from fdisk md0 here:
> sysid 238 (0xee),(EFI GPT)
> start 1, size 1350917 (659 Meg), flag 0
> Whereas with the amd64 release there's a whole extra set of images
> labelled -uefi- such as: FreeBSD-10.3-RELEASE-amd64-uefi-memstick.img
>
> I'm entirely [U]EFI ignorant, but it seems strange that the i386 images
> appear to incorporate that, while amd64 uefi images are kept separate?
>
> Can anyone explain why any of this is so? (looking at you, Warren :)
BIOS booting, but the bootcode has been updated to handle both. So we
will soon be back to just one style. "Soon" being relative, I don't
have any specific information on when.
Perry Hutchison
Sep 10, 2016, 11:11:08 PM9/10/16
to
Warren Block <wbl...@wonkity.com> wrote:
> On Fri, 9 Sep 2016, Perry Hutchison wrote:
> > Getting back to the original inquiry, I'm still mystified as to
> > why gpart won't create a partition in the space that it reports
> > as being free. Does anyone have a clue what is going on, or how
> > to find out?
>
> It could be an actual bug. gpart and the man page have been revised
> quite a bit over the last few years.
Indeed. 10.3 behaves differently. (Not better, but differently.)
> On Fri, 9 Sep 2016, Perry Hutchison wrote:
> > Getting back to the original inquiry, I'm still mystified as to
> > why gpart won't create a partition in the space that it reports
> > as being free. Does anyone have a clue what is going on, or how
> > to find out?
>
> It could be an actual bug. gpart and the man page have been revised
> quite a bit over the last few years.
I tried booting the stick and using its own gpart to create the new
partition, and it failed silently: it claimed to have created the
partition, and "gpart show" showed it, but it was gone after rebooting.
I tried several times, sometimes allowing the "gpart add" to do the
operation immediately and other times specifying "-f x" followed by
"gpart commit", and the new partition never survived a reboot.
It is not a matter of the GPT somehow being silently read-only:
I also applied labels to the original partitions, at least once
each before and after creating the new partition, and the label
operations always survived the reboot but the partition creation
never did.
To reproduce (from the top):
dd FreeBSD-10.3-RELEASE-i386-memstick.img to a flash drive.
(I'm using a 4GB flash drive, but the size probably doesn't much
matter.) Note that this is the i386 memstick.img; I have no idea
whether anything similar would happen with other architectures.
Boot it into single-user mode. It will be da0 unless there are
other "da" drives attached.
# gpart recover da0 # resizes the GPT to the stick
I rebooted here for other reasons; dunno if it matters.
# gpart show da0 # shows 3 partitions and some free space
# gpart add -t freebsd-ufs da0 # reports "da0p4 added" (or similar)
# gpart show da0 # shows 4 partitions including the new one
# shutdown -r now
after reboot:
# gpart show da0 # shows 3 partitions and some free space
BTW I also discovered in the course of this that "gpart commit" with
no pending operations misleadingly says "Operation not permitted"
rather than "Nothing to commit" or "No pending operations".
Perry Hutchison
Sep 10, 2016, 11:41:11 PM9/10/16
to
Warren Block <wbl...@wonkity.com> wrote:
> Support for 8.1 ended over four years ago. Improvements to man
> pages are not MFCed back to unsupported releases.
Nor would it matter (in this case) if they were, since I'm running
> Support for 8.1 ended over four years ago. Improvements to man
> pages are not MFCed back to unsupported releases.
8.1 (not following 8-STABLE).
> > Alignment to 4k makes sense if the physical sector size is 4k (as
> > is often the case with newer disk drives) -- but 1M? Seems a bit
> > much, which is why it would be useful for that page to include a
> > more detailed explanation.
>
> 1M is a useful value for several reasons. A partition aligned with 1M
> is aligned with all the smaller values. It also better fits with the
> larger internal block sizes used by SSDs and other flash devices.
>
> Starting the first data partition at 1M is a de facto standard and
> provides a little additional insurance that some rock-stupid
> partitioning tool will see the partition and not destroy it.
>
> At most, aligning to 1M wastes less than one meg of space. Not one gig,
> one meg. On UEFI systems, you can even use that small amount of space
> for an EFI partition.
disksetup.html page :)
Perry Hutchison
Sep 11, 2016, 12:11:19 AM9/11/16
to
Warren Block <wbl...@wonkity.com> wrote:
> On Sat, 10 Sep 2016, Ian Smith wrote:
> > On Tue, 6 Sep 2016 22:54:24 -0700, Perry Hutchison wrote:
> > > (Old-timers will remember why some of us
> > > don't like to exceed bs=126b with dd :)
> > I only go back to '98 on FreeBSD; never heard of that ...
> On Sat, 10 Sep 2016, Ian Smith wrote:
> > On Tue, 6 Sep 2016 22:54:24 -0700, Perry Hutchison wrote:
> > > (Old-timers will remember why some of us
> > > don't like to exceed bs=126b with dd :)
> I don't see any reason to use less than block sizes ...
> Actually, I don't see any reason to use less than 64K or even 1M buffer
> size. Smaller sizes add huge amounts of overhead with no benefit.
This goes back farther than FreeBSD, to SunOS 4.1 or earlier.
> size. Smaller sizes add huge amounts of overhead with no benefit.
The old-timers I mentioned remember DMA hardware that could not handle
a buffer spanning a 64KB physical boundary. It's difficult for a
driver to comply with such a limitation if the blocksize is larger :)
bs=128b is exactly 64KB, and some of those drivers would throw an
error on that, so 126b became the largest considered advisable
absent knowledge that the particular hardware in use could handle
larger.
> > > BTW it did boot (I only tried single-user mode) and worked
> > > well enough to resize itself with "gpart recover".
> >
> > Um, do you mean you ran gpart recover on the stick you'd
> > booted off?
although 8.1 geom does complain about the missing backup GPT table
and say something like "recovery recommended".
> This works but is unnecessary. Unless you want to store more stuff
Precisely. Why else would I be trying to create another partition
on it?
> > [big cut]
> >
> > > # fdisk /dev/da2
> > > ******* Working on device /dev/da2 *******
> > > parameters extracted from in-core disklabel are:
> > > cylinders=486 heads=255 sectors/track=63 (16065 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 238 (0xee),(EFI GPT)
> > > start 1, size 7811071 (3813 Meg), flag 0
> > > beg: cyl 0/ head 0/ sector 2;
> > > end: cyl 1023/ head 255/ sector 63
> > >
> > > which I take to be the protective MBR of the GPT scheme.
>
> Of course, fdisk knows nothing but MBR. Please stop using fdisk.
protective MBR? AFAIK "gpart show" shows only the GPT itself.
Warren Block
Sep 11, 2016, 8:54:13 AM9/11/16
to
On Sat, 10 Sep 2016, Perry Hutchison wrote:
> Warren Block <wbl...@wonkity.com> wrote:
>> On Sat, 10 Sep 2016, Ian Smith wrote:
>>> On Tue, 6 Sep 2016 22:54:24 -0700, Perry Hutchison wrote:
>>>> (Old-timers will remember why some of us
>>>> don't like to exceed bs=126b with dd :)
>>> I only go back to '98 on FreeBSD; never heard of that ...
>> I don't see any reason to use less than block sizes ...
>> Actually, I don't see any reason to use less than 64K or even 1M buffer
>> size. Smaller sizes add huge amounts of overhead with no benefit.
>
> This goes back farther than FreeBSD, to SunOS 4.1 or earlier.
>
> The old-timers I mentioned remember DMA hardware that could not handle
> a buffer spanning a 64KB physical boundary. It's difficult for a
> driver to comply with such a limitation if the blocksize is larger :)
>
> bs=128b is exactly 64KB, and some of those drivers would throw an
> error on that, so 126b became the largest considered advisable
> absent knowledge that the particular hardware in use could handle
> larger.
Ah, "b" for blocks, not bytes. I guarantee I have never used that on
> Warren Block <wbl...@wonkity.com> wrote:
>> On Sat, 10 Sep 2016, Ian Smith wrote:
>>> On Tue, 6 Sep 2016 22:54:24 -0700, Perry Hutchison wrote:
>>>> (Old-timers will remember why some of us
>>>> don't like to exceed bs=126b with dd :)
>>> I only go back to '98 on FreeBSD; never heard of that ...
>> I don't see any reason to use less than block sizes ...
>> Actually, I don't see any reason to use less than 64K or even 1M buffer
>> size. Smaller sizes add huge amounts of overhead with no benefit.
>
> This goes back farther than FreeBSD, to SunOS 4.1 or earlier.
>
> The old-timers I mentioned remember DMA hardware that could not handle
> a buffer spanning a 64KB physical boundary. It's difficult for a
> driver to comply with such a limitation if the blocksize is larger :)
>
> bs=128b is exactly 64KB, and some of those drivers would throw an
> error on that, so 126b became the largest considered advisable
> absent knowledge that the particular hardware in use could handle
> larger.
FreeBSD, and never experienced a problem. On disks, I routinely use
bs=64K, and 1M for flash can help transfer rates.
>>>> BTW it did boot (I only tried single-user mode) and worked
>>>> well enough to resize itself with "gpart recover".
>>>
>>> Um, do you mean you ran gpart recover on the stick you'd
>>> booted off?
>
> Yep. No other choice. 8.1 gpart does not understand "recover" --
> although 8.1 geom does complain about the missing backup GPT table
> and say something like "recovery recommended".
>
>> This works but is unnecessary. Unless you want to store more stuff
>> on the install stick ...
>
> Precisely. Why else would I be trying to create another partition
> on it?
At this point, it's still confusing how you did a recover if the old
version of gpart being used did not support that.
>>>> which I take to be the protective MBR of the GPT scheme.
>>
>> Of course, fdisk knows nothing but MBR. Please stop using fdisk.
>
> Is there another program that will display the details of the
> protective MBR? AFAIK "gpart show" shows only the GPT itself.
static structure, an MBR with a single partition, type 0xEE, sized to
fill the entire disk or 2TB, whichever is smaller.
0 new messages