Re: Why doesn't 13_4 img (1.3G) write to a 4 G memstick?

From: Michael Schuster <michaelsprivate_at_gmail.com>
Date: Thu, 23 Jan 2025 20:10:14 UTC
I'd do

xz --decompress <
/hd2/Downloads/FreeBSD/13_4/FreeBSD-13.4-RELEASE-amd64-memstick.img.xz >
tmp.img

 and then look at the size of that file.

HTH
Michael



On Thu, Jan 23, 2025, 20:58 Gary Aitken <freebsd@dreamchaser.org> wrote:

> I'm trying to create a bootable backup memory stick on a 4G stick.
>
>  From https://download.freebsd.org/releases/amd64/amd64/ISO-IMAGES/13.4/
> File Name  ↓    File Size  ↓    Date  ↓
> FreeBSD-13.4-RELEASE-amd64-memstick.img 1342689792      2024-Sep-13 10:15
>
> That looks like 1.3 G to me.
>
> $ xz --decompress <
> /hd2/Downloads/FreeBSD/13_4/FreeBSD-13.4-RELEASE-amd64-memstick.img.xz | dd
> of=/dev/da0 bs=1M conv=sync
> dd: /dev/da0: short write on character device
> dd: /dev/da0: end of device
> 3824+0 records in
> 3823+1 records out
> 4009745920 bytes transferred in 1526.615472 secs (2626559 bytes/sec)
> Prior to writing, the memstick looked like this:
>
> $ gpart show -l da0
> =>     63  7831472  da0  MBR  (3.7G)
>         63  7831472    1  (null)  (3.7G)
>
> $ gpart list da0
> Geom name: da0
> modified: false
> state: OK
> fwheads: 255
> fwsectors: 63
> last: 7831534
> first: 63
> entries: 4
> scheme: MBR
> Providers:
> 1. Name: da0s1
>     Mediasize: 4009713664 (3.7G)
>     Sectorsize: 512
>     Stripesize: 0
>     Stripeoffset: 32256
>     Mode: r0w0e0
>     efimedia: HD(1,MBR,00000000,0x3f,0x777fb0)
>     rawtype: 11
>     length: 4009713664
>     offset: 32256
>     type: fat32
>     index: 1
>     end: 7831534
>     start: 63
> Consumers:
> 1. Name: da0
>     Mediasize: 4009745920 (3.7G)
>     Sectorsize: 512
>     Mode: r0w0e0
>
> After writing:
>
> $ gpart show -l da0
> =>      1  7831534  da0  MBR  (3.7G)
>          1    66584    1  (null)  (33M)
>      66585  2555856    2  (null)  [active]  (1.2G)
>    2622441  5209094       - free -  (2.5G)
>
> $ gpart list da0
> Geom name: da0
> modified: false
> state: OK
> fwheads: 255
> fwsectors: 63
> last: 7831534
> first: 1
> entries: 4
> scheme: MBR
> Providers:
> 1. Name: da0s1
>     Mediasize: 34091008 (33M)
>     Sectorsize: 512
>     Stripesize: 0
>     Stripeoffset: 512
>     Mode: r0w0e0
>     efimedia: HD(1,MBR,0x90909090,0x1,0x10418)
>     rawtype: 239
>     length: 34091008
>     offset: 512
>     type: efi
>     index: 1
>     end: 66584
>     start: 1
> 2. Name: da0s2
>     Mediasize: 1308598272 (1.2G)
>     Sectorsize: 512
>     Stripesize: 0
>     Stripeoffset: 34091520
>     Mode: r0w0e0
>     efimedia: HD(2,MBR,0x90909090,0x10419,0x26ffd0)
>     attrib: active
>     rawtype: 165
>     length: 1308598272
>     offset: 34091520
>     type: freebsd
>     index: 2
>     end: 2622440
>     start: 66585
> Consumers:
> 1. Name: da0
>     Mediasize: 4009745920 (3.7G)
>     Sectorsize: 512
>     Mode: r0w0e0
>
> Despite the website claim of 1.3G size,
> it looks like the uncompressed file is larger than 4G; dd said it
> transferred
> 4G+ bytes.  But da0s2 says it's only 1.2G after the failed write.
> Piped into wc -c it says 1342689792 (1.3G)
>
> Is there some magic I need to invoke?
>
>
>