Date: Fri, 9 Sep 2016 15:15:08 -0600 (MDT) From: Warren Block <wblock@wonkity.com> To: Ian Smith <smithi@nimnet.asn.au> Cc: Perry Hutchison <perryh@pluto.rain.com>, freebsd-questions@freebsd.org Subject: Re: "gpart add" falsely claiming "No space left on device" Message-ID: <alpine.BSF.2.20.1609091441170.50899@wonkity.com> In-Reply-To: <20160910022609.E91459@sola.nimnet.asn.au> References: <mailman.109.1473163202.26682.freebsd-questions@freebsd.org> <20160907000551.F91459@sola.nimnet.asn.au> <57cfab90.qRHpzKSiF/A9Stt1%perryh@pluto.rain.com> <20160910022609.E91459@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 10 Sep 2016, Ian Smith wrote: > On Tue, 6 Sep 2016 22:54:24 -0700, Perry Hutchison wrote: > > Ian Smith <smithi@nimnet.asn.au> wrote: > > > In freebsd-questions Digest, Vol 640, Issue 2, Message: 5 > > > On Tue, 06 Sep 2016 00:21:08 -0700 perryh@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 :) > > I only go back to '98 on FreeBSD; never heard of that .. I'll resist my > 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 I don't see any reason to use less than block sizes. Can't say I've 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? This works but is unnecessary. Unless you want to store more stuff on 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. Of course, fdisk knows nothing but MBR. Please stop using fdisk. > 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 Yes. Please, please stop using fdisk. > 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 :) We are in a time of transition. There were separate images for UEFI and 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1609091441170.50899>