Date: Thu, 23 Jan 2025 16:26:07 -0700 From: Gary Aitken <freebsd@dreamchaser.org> To: questions@freebsd.org Subject: Re: Why doesn't 13_4 img (1.3G) write to a 4 G memstick? Message-ID: <7b491ec9-4678-497f-ae9a-cfdbbb10f6eb@dreamchaser.org> In-Reply-To: <52bad083-f814-4570-80b9-e11338fb4cdb@dreamchaser.org> References: <80444fa1-51a8-469e-a15d-55b255196d6a@dreamchaser.org> <52bad083-f814-4570-80b9-e11338fb4cdb@dreamchaser.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>> On Thu, Jan 23, 2025, 20:58 Gary Aitken <freebsd@dreamchaser.org <mailto: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/ <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. It appears the sectorsize of the disk is a problem. If the copy is done using bs=512K to match the sector size of the device, it fits. Is there a way to read only the boot block and the first two partitions to compute a checksum?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7b491ec9-4678-497f-ae9a-cfdbbb10f6eb>