Bizarre clone attempt failures on Raspberry Pi2...
Karl Denninger
karl at denninger.net
Thu Jul 14 16:44:56 UTC 2016
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? :)*
What's in here?
# gpart show da0
=> 63 62552001 da0 MBR (30G)
63 102400 1 !12 [active] (50M)
102463 4033 - free - (2.0M)
106496 62439424 2 freebsd (30G)
62545920 6144 - free - (3.0M)
Hmmmm... what do we think exists for device nodes?
# ls -al /dev/da0*
crw-r----- 1 root operator 0x61 Jul 13 20:28 /dev/da0
crw-r----- 1 root operator 0x64 Jul 14 15:23 /dev/da0s1
crw-r----- 1 root operator 0x66 Jul 14 15:23 /dev/da0s2
crw-r----- 1 root operator 0x67 Jul 14 15:23 /dev/da0s2a
Wait a minute, I didn't create any BSD slices! WTF?
# bsdlabel /dev/da0s2
# /dev/da0s2:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 62439424 0 4.2BSD 0 0 0
c: 62439424 0 unused 0 0 # "raw" part,
don't edit_
_
Oh really? How'd that get in there? And by the way, that's probably
why the "add" fails (no space left and the first partition already exists)
Further, this is *also* why I can "tunefs" the base (/dev/da0s2) because
there's no offset (that is, /dev/da0s2 and /dev/da0s2a both point to the
same first block) and that may be why the system refuses to boot when
I'm done, as it's "tasted" the first entry, found a label and thus it's
"open".
In fact, that gap is *exactly* what I see when I run bsdlabel on the
running card:
# bsdlabel /dev/mmcsd0s2
# /dev/mmcsd0s2:
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
a: 62443392 90 4.2BSD 0 0 0
c: 62443482 0 unused 0 0 # "raw" part,
don't edit
It looks like the issue is that the "gpart create -t freebsd" command
stuck a partition table in there which causes the "create -s BSD" to fail.
Strategically dding /dev/zero to the card's first 100MB or so (beyond
the DOS partition and into the label) and then *again* on the freebsd
partition *but before calling gpart to put the slice table on* results
in the add working properly.
# gpart show da0
=> 63 62552001 da0 MBR (30G)
63 102400 1 !12 [active] (50M)
102463 4033 - free - (2.0M)
106496 62439424 2 freebsd (30G)
62545920 6144 - free - (3.0M)
# gpart show da0s2
=> 0 62439424 da0s2 BSD (30G)
0 128 - free - (64K)
128 62439168 1 freebsd-ufs (30G)
62439296 128 - free - (64K)
# tunefs -p /dev/da0s2
tunefs: /dev/da0s2: could not read superblock to fill out disk
# tunefs -p /dev/da0s2a
tunefs: POSIX.1e ACLs: (-a) disabled
tunefs: NFSv4 ACLs: (-N) enabled
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
That looks valid and now matches the other card... but..... the new
(duplicated) card still hangs in the same place.....
It boots, the kernel loads, the root filesystem mounts and then the
system hangs right after the ue0 MAC address displays on the console.
How do you get the "why" on that since I have no way to break out of
whatever it is hanging on (it ignores a ^C from a USB keyboard, although
it *does* know it's there and the kernel displays attach/detach messages
if you plug one in or out while it's hung) and there's no error message
displayed that would otherwise help?
--
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/39e3adfe/attachment.bin>
More information about the freebsd-arm
mailing list