dd question

[Ian Smith]

Re: freebsd-questions Digest, Vol 590, Issue 7, Message: 7
On Sat, 26 Sep 2015 11:10:40 -0453.75 [a very peculiar timezone]
"William A. Mahaffey III" <wam at hiwaay.net> wrote:

[cutting unmercifully to the chase]

 > >> I am preparing a USB stick for use to install FreeBSD 9.3R on 2 new 
 > >> boxen I am bringing online. I already had the FreeBSD 9.3R img dd'ed 
 > >> to that stick last year when I provisioned this box, but for some 
 > >> reason, when I plugged the stick into my USB port today to copy some 
 > >> additional files to it (scripts to be used during installs to 
 > >> partition & slice up HDD's), I got errors in my syslog file & 
 > >> couldn't mount the drive for the copies.

 > >> -rw-r--r--  1 wam  users  717373440 Jul 26  2014 
 > >> FreeBSD-9.3-RELEASE-amd64-memstick.img

 > Well, I got tired of waiting (again) & moved the process to my last 
 > remaining Linux box & did the dd there. It completed OK & for grins I 
 > inserted it back into this (FreeBSD 9.3R-p24) box. It created 2 devices:
 > 
 > [root at kabini1, /etc, 11:04:30am] 529 % lltr /dev/da0* ; date
 > crw-r-----  1 root  operator  0xd1 Sep 26 11:01 /dev/da0a
 > crw-r-----  1 root  operator  0xd0 Sep 26 11:01 /dev/da0

 > It used to create /dev/da0s1, but no matter, I manually mounted the da0a 
 > partition & I can see stuff there, although it reports a bad FS size:

No, the memstick images have always been setup as an unsliced disk; in 
fact they were done that way in an historical accident (in retrospect) 
that made them appear to sysinstall as floppy disk images, due to it 
already interpreting anything libdisk (prior to modern GEOM framework) 
found as a sliced da device as a 'real' SCSI disk, so interpreting the 
unsliced da devices as installation mensticks to distinguish them.

My FreeBSD-9.3-RELEASE-amd64-memstick.img is just the same, and I still 
find it sad memsticks use nothing better .. PCBSD for example has used 
sliced memsticks for ages, so you can have up to 4 slices with different 
images (eg 9.3 and 10.x, or amd64 and i386), use boot0cfg and the 
booteasy boot manager to choose one, plus a spare slice for writing 
dmesg, boot logs and other interestubg data, so using the whole stick 
rather than turning your 4 to 16GB stick into a oversized floppy.

 > Filesystem            Type         Size    Used   Avail Capacity Mounted on
[..]
 > /dev/da0a             ufs          682M    636M   -8.8M   101% /media/sd

Yes, they're setup overcommitted, rather without the usual 8% reserved, 
using some truly filthy tricks with fdisk, bsdlabel and some instances 
use dd to update _parts_ of the MBR and bsdlabel.  Don't go there.  And 
you likely won't get away with writing anything 'live' to these sticks, 
short of using dd with 'foot-shooting' sysctl kern.geom.debugflags=16

 > [root at kabini1, /etc, 11:07:56am] 531 % ll /media/sd/ ; date
 > total 723
 > -rw-r--r--   2 root  wheel     965 Jul 10  2014 .cshrc
 > -rw-r--r--   2 root  wheel     253 Jul 10  2014 .profile
 > -r--r--r--   1 root  wheel    6197 Jul 10  2014 COPYRIGHT
 > -r--r--r--   1 root  wheel    8553 Jul 10  2014 ERRATA.HTM
[..]

 > The USB drive is a 4 GB Mushkin unit. Did the naming convention for 
 > devices change at some point in the various kernel upgrades since last 
 > summer ? ISTR that it used to create a da0s1 device for that drive, 
 > that's what I have in my fstab file to mount that drive manually w/o the 
 > full mount command naming FS-type & mount point or device. Thanks for 
 > everything so far & TIA for any more clues ....

YSTRW :) Other memsticks formatted for sliced use will have a da0s1 
(etc) but never these installation images.  I'd love to be wrong.

For example, here is a 9.2-RELEASE memstick built instead from the 
dvd1.iso image, but still in the same format, on an 8GB stick:

smithi on t23% ll /dev/da*
crw-r-----  1 root  operator    0, 138 Sep 28 01:41 /dev/da0
crw-r-----  1 root  operator    0, 139 Sep 28 01:41 /dev/da0a

smithi on t23% fdisk 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

50000 sectors?  24 Meg?  Wild, eh, and meaningless.

smithi on t23% bsdlabel da0a
# /dev/da0a:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:  5448528        0    4.2BSD        0     0     0
  c:  5448528        0    unused        0     0         # "raw" part, don't edit

t23# mount /dev/da0a /media
t23# df -h
Filesystem     Size    Used   Avail Capacity  Mounted on
[..]
/dev/da0a      2.6G    2.4G    -30M   101%    /media

gpart makes more sense of it, but I'm not sure whether gpart can be used 
in 'dirty tricks' mode to create these.  And I've no idea whether growfs 
could do anything sensible about growing them; you could try.  Warren?

smithi on t23% gpart show da0
=>       0  15646720  da0  BSD  (7.5G)
         0   5448528    1  freebsd-ufs  (2.6G)
   5448528  10198192       - free -  (4.9G)

cheers, Ian