Bizarre clone attempt failures on Raspberry Pi2...

Karl Denninger karl at denninger.net
Thu Jul 14 02:44:22 UTC 2016



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.)

-- 
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/20160713/a1f828ee/attachment.bin>


More information about the freebsd-arm mailing list