Bizarre clone attempt failures on Raspberry Pi2...
Karl Denninger
karl at denninger.net
Thu Jul 14 18:27:38 UTC 2016
On 7/14/2016 12:55, Ian Lepore wrote:
> 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 at 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 at 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 at 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.
No there wasn't. It was a blank (brand new) card the first time around;
it had a MSDOS filesystem on it (as do all new cards) but *no*
BSD-specific geom anything on it.
> 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
Actually in the case at hand #1 isn't impractical since I really only
care about the first 100MB or so being zeroed. The reason is that my
boot block (the MSDOS fs) is ~50Mb and the label is obviously next, so
if we zero the first 100MB we're fine.
And in fact that does work.
> 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.
Ok, I will try this, BUT I suspect it's still screwed (blind) because
when I zeroed the front of the disk I got a "correct" partition layout
but after populating it what I get still hangs after it mounts root in
the same place. The way to prevent the alignment issue from coming up
is to specify a "-b" switch on the "add", giving you a block offset.
"-b 64" is sufficient; now if the system tries to "taste" da0s2 it will
fail (as it does for the card that is running) but "tasting" da0s2a
succeeds.
> 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.)
Yes, I understand that; if the alignment matches thus the "a" partition
starts at offset zero then you can actually reference that (although
length might be wrong) with the base device. After all, what it really
does is look at the blocks to see if the magic number is good, and if so
it tries to read and process it.
But this doesn't explain why, after getting a layout that's correct (by
writing zeros to the front of the card first, so anything that "might"
be there isn't) and copying all the file structure over (which facially
not only appears to be correct but the loader finds and loads the
kernel, AND the root filesystem mounts!) the system hangs, apparently
just before init gets started.
If init can't be found you should get a complaint (been there, done
that) on the console but there is no complaint of any sort.
I've gotten through the bad structure issue on the SD card, and am now
left with "why does it hang on boot -- with no error or other indication
of what the problem is" after the kernel loads *and* the root filesystem
mounts?
--
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20160714/11230bed/attachment.bin>
More information about the freebsd-arm
mailing list