Date: Thu, 14 Jul 2016 11:55:53 -0600 From: Ian Lepore <ian@freebsd.org> To: Karl Denninger <karl@denninger.net>, freebsd-arm@freebsd.org Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <1468518953.72182.219.camel@freebsd.org> In-Reply-To: <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <d2eb4035-e494-1a7b-98e5-2aa87efe0763@denninger.net> <EDE65B12-4961-4CEF-8AE9-BFDA4FD508A5@gromit.dlib.vt.edu> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2016-07-14 at 11:44 -0500, Karl Denninger wrote: > On 7/13/2016 21:44, Karl Denninger wrote: > > > > On 7/13/2016 19:13, Paul Mather wrote: > > > > On Jul 13, 2016, at 3:54 PM, Karl Denninger <karl@denninger.net > > > > > wrote: > > > > > > > > Oh, there is one difference: > > > > > > > > tunefs -p on the new device *works* (no idea why however since > > > > there's > > > > no slice there) where it FAILS on the original: > > > > > > > > root@Test-MCP:/home/karl # tunefs -p /dev/mmcsd0s2 > > > Shouldn't this be /dev/mmcsd0s2a? You're referencing the entire > > > BSD slice in the above command, not the UFS partition upon which > > > the rootfs lives. > > Right. Here's the issue; it doesn't work on the original disk (as > > it > > shouldn't) on the entire BSD slice but... > > > > tunefs: /dev/mmcsd0s2: could not read superblock to fill out > > > > disk > > > > > > > > root@Test-MCP:/home/karl # tunefs -p /dev/da0s2 > > > > tunefs: POSIX.1e ACLs: (-a) > > > > disabled > > > > tunefs: NFSv4 ACLs: (-N) > > > > disabled > > > > tunefs: MAC multilabel: (-l) > > > > disabled > > > > tunefs: soft updates: (-n) > > > > enabled > > > > tunefs: soft update journaling: (-j) > > > > disabled > > > > tunefs: gjournal: (-J) > > > > disabled > > > > tunefs: trim: (-t) > > > > disabled > > > > tunefs: maximum blocks per file in a cylinder group: (-e) 4096 > > > > tunefs: average file size: (-f) > > > > 16384 > > > > tunefs: average number of files in a directory: (-s) 64 > > > > tunefs: minimum percentage of free space: (-m) 8% > > > > tunefs: space to hold for metadata blocks: (-k) 6408 > > > > tunefs: optimization preference: (-o) time > > > > tunefs: volume label: (-L) > > > > rootfs > > > Cheers, > > > > > > Paul. > > It DOES on the "clone"! > > > > It ALSO does on the "a" partition of the clone. > > > > This implies that gpart screwed up the partitioning, but THAT > > leaves > > open how and why the original partitioning (which is defined here > > https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi%202%20image) > > works > > at all, since that's what I'm doing -- and yet it gives the results > > as > > above (and no boot when I'm done.) > > > > Ok, so what's broken here folks? This is likely to blow up soon > enough > on the build systems that the people who are building snapshot > releases > are using (once they update); I assume this is a function of some > sort > of change that was made somewhere upstream in the system. > > The format of the card has to be: > > 1. MBR > 2. First partition is MSDOS (Type "!12") with the various boot code > on > it (ubldr, etc.) This is fine. > 3. The second partition has to be a "BSD" format partition (old > -style) > 4. Inside the second partition is a "traditional" BSD labeled > (bsdlabel > style) partititon table. > > Up to #2 all goes fine on an attached SD card: > # gpart show da0 > => 63 62552001 da0 MBR (30G) > 63 102400 1 !12 (50M) > 102463 62449601 - free - (30G) > > Now we try to create the BSD labeled piece -- I got this from the > crochet disk blob creator, incidentally, along with the FreeBSD Wiki > (at > https://wiki.freebsd.org/FreeBSD/arm/Raspberry Pi 2 image) > > # gpart add -t freebsd -a 4m /dev/da0 > da0s2 added > # gpart create -s BSD /dev/da0s2 > *gpart: geom 'da0s2': File exists* > > *Heh, what was that? :)* > There's nothing new or different-on-rpi about this. There was previously a BSD geom there. Nothing you've done with gpart up to this point changed that. As soon as you make a slice entry that once again points to where the old BSD geom is, the automatic "taste" procedure that happens after creating a new geom (the slice) finds it there and creates new geoms for it as well. When you're trying to reliably create a layout on a device regardless of what has been there in the past, this is frustrating and your inclination is to curse whoever coded such a mess. When your MBR got overwritten by accident and you restore it, and all the other data on the disk turns out to be just as intact as it ever was, your inclination is to praise whoever coded such robustness. I've been meaning to write up a wiki page or something on this for six months, but I never get around to it. So I'll just dump it out all stream-of-conciousness style here... To reliably create a new layout regardless of what may be present already on the media, you have two choices: 1 - dd zeroes to the entire device 2 - use the "no commit" feature of gpart Since #1 is impractical, here's the story with #2... When you pass no '-f <flags>' to a gpart command, it automatically adds the "-f C" (commit) flag behind your back. There is no "don't commit" flag, so (this is surrealistically crazy...) what you're supposed to do is pass an invalid flag, which it won't complain about, in order to prevent it from automatically adding that 'C' flag you didn't even realize existed. (This is where *I* curse whoever coded this mess.) When you don't commit, the changes take place in a sort of 'virtual workspace' and nothing on the physical disk changes until you do a "gpart commit" (or "gpart undo" to discard the changes). Making all this much-less-cool that it's sounding right now, there is no automatic recursion for commit and undo... if you create a bunch of nested stuff (a slice, a geom within that slice, parititions within that geom), then you have to commit all the pending new geoms *in reverse order of how they were created*. So, using da0 (since it's shorter to type), the sequence goes like: gpart destroy -f x -F da0 gpart create -f x -s MBR da0 gpart add -f x -t \!12 -s 64M -a 4M da0 gpart add -f x -t freebsd -a 4M da0 gpart destroy -f x -F da0s2 gpart create -f x -s BSD da0s2 gpart add -f x -t freebsd-ufs da0s2 gpart commit da0s2 gpart commit da0 newfs_msdos /dev/da0s1 newfs -U /dev/da0s2a And that reliably creates a fresh rpi-style layout regardless of what was on the media before you started. Beware that if you do some gpart stuff with -f x you MUST either commit or undo, and you'd better remember which geoms need to be committed, because nothing about a gpart show will tell you what's pending. If you don't either commit or undo the pending stuff, further attempts to work with that device will just give confusing "operation not permitted" errors with no clue about why. > [snip stuff about tunefs] Now, to address the question of the filesystem existing at da0s2 versus da0s2a, the difference is alignment. Making things even more confusing, alignment (if you don't specify it) sometimes changes based on the type and brand of usb sdcard reader you're using and the fake geometry values it reports to the system. (A USB reader almost always reports different fake geometry than a native sd slot would on a machine with non-USB based sd support.) By design, dating back as long as I can remember, it has been possible for a bsdlabel and a ufs filesystem to begin at the same block on disk. The first 16K (iirc) of a ufs filesystem is never touched by ufs, specifically so that the bsdlabel can live in those blocks. My understanding of this is vague at best; I think it may have been a thing that made more sense with the tiny disks back in the 80s and 90s. So, in the command sequence above, consider these two variations of creating the ufs partition inside the bsd slice. If you do it as shown above, without aligning the partition, you get: # gpart add -f x -t freebsd-ufs da0s2 [commit, format, ...] # gpart show da0s2 => 0 31145940 da0s2 BSD (15G) 0 31145940 1 freebsd-ufs (15G) # file -s /dev/da0s2 /dev/da0s2: Unix Fast File system [v2] (little-endian) [snip] # file -s /dev/da0s2a /dev/da0s2a: Unix Fast File system [v2] (little-endian) [snip] Now if you do it with the partition aligned you get: # gpart add -f x -t freebsd-ufs -a 4M da0s2 [commit, format, ...] # gpart show da0s2 => 0 31145940 da0s2 BSD (15G) 0 8163 - free - (4.0M) 8163 31129600 1 freebsd-ufs (15G) 31137763 8177 - free - (4.0M) # file -s /dev/da0s2 /dev/da0s2: data # file -s /dev/da0s2a /dev/da0s2a: Unix Fast File system [v2] (little-endian) [snip] It's interesting that file(1) doesn't recognize a bsd label. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1468518953.72182.219.camel>