Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Jul 2016 14:54:12 -0500
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-arm@freebsd.org
Subject:   Re: Bizarre clone attempt failures on Raspberry Pi2...
Message-ID:  <d2eb4035-e494-1a7b-98e5-2aa87efe0763@denninger.net>
In-Reply-To: <548783e1-9047-68f7-5f50-449db684d602@denninger.net>
References:  <548783e1-9047-68f7-5f50-449db684d602@denninger.net>

next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format.

--------------ms090105020105080907090509
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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

Huh?


On 7/13/2016 14:45, Karl Denninger wrote:
> The latest conundrum.....
>
> I am attempting to "clone" a running SD card for the Pi2.
>
> I have re-created the SD filestructure using gpart using the following
> sequence, starting with a blank card (e.g. "da0") and aligning the Unix=

> filestructure on a 4MB boundary (which is my usual practice for any sor=
t
> of solid-state device)
>
> #!/bin/sh
>
> gpart create -s MBR $1
> gpart add -t '!12' -s 50m $1
> gpart set -a active -i 1 $1
> gpart add -t freebsd -a 4m $1
> newfs_msdos $1s1
> gpart create -s bsd $1s2
> gpart add -t freebsd-ufs $1s2
> newfs -U -L rootfs $1s2a
>
> then mounted the two "working" partitions this generates (da0s1 and
> da0s2a) and successfully transferred the root and msdos filesystems
> using rsync.  The result appears to be fine when examined side-by-side
> with the original, other than the fact that it looks like there were
> sparse files that have been expanded, but when you try to boot the
> result it starts, appears to mount the root filesystem, says it's not
> clean (which is odd since it certainly was dismounted cleanly with
> umount!), and the system hangs after displaying the UE (ethernet)
> hardware MAC address on an HDMI console.  There is no response from a
> USB connected keyboard if you try to ^C out of wherever it is (although=

> it DOES know it's there and displays the "found" message when you plug
> the keyboard in.)
>
> If you wait long enough it will tell you it has unblocked the random
> device.  Unfortunately I have no idea where it's hanging in the startup=

> beyond this and have no way to find out since I can get out of wherever=

> it is, even with a physical keyboard plugged into it.
>
> Putting the original card back in and sticking the one that failed to
> boot in an SD card reader produces the following.
>
> Base partition structure of the working sd card:
>
> # gpart show /dev/mmcsd0
> =3D>      63  62552001  mmcsd0  MBR  (30G)
>         63    102375       1  !12  [active]  (50M)
>     102438  62443482       2  freebsd  (30G)
>   62545920      6144          - free -  (3.0M)
>
> Of the other card:
> # gpart show /dev/da0
> =3D>      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)
>
>
> # ls -al /dev/mm*
> crw-r-----  1 root  operator  0x4e Jul 10 19:24 /dev/mmcsd0
> crw-r-----  1 root  operator  0x4f Jul 10 19:24 /dev/mmcsd0s1
> crw-r-----  1 root  operator  0x50 Jul 10 19:24 /dev/mmcsd0s2
> crw-r-----  1 root  operator  0x53 Jul 10 19:24 /dev/mmcsd0s2a
>
> And of the one that will not come up but does boot, in a SD card reader=
:
>
> # ls -al /dev/da0*
> crw-r-----  1 root  operator  0x56 Jul 13 19:27 /dev/da0
> crw-r-----  1 root  operator  0x58 Jul 13 19:27 /dev/da0s1
> crw-r-----  1 root  operator  0x5d Jul 13 19:27 /dev/da0s2
> crw-r-----  1 root  operator  0x60 Jul 13 19:27 /dev/da0s2a
>
> # mount -t msdosfs /dev/da0s1 /mnt
> # df
> Filesystem             1K-blocks   Used    Avail Capacity  Mounted on
> /dev/ufs/rootfs         30229724 824548 26986800     3%    /
> devfs                          1      1        0   100%    /dev
> /dev/msdosfs/MSDOSBOOT     51128   7560    43568    15%    /boot/msdos
> tmpfs                      51200      4    51196     0%    /tmp
> /dev/da0s1                 51128   7560    43568    15%    /mnt
>
> # ls /mnt
> BOOTCODE.BIN                    START_CD.ELF
> CONFIG.TXT                      START_X.ELF
> FIXUP.DAT                       System Volume Information
> FIXUP_CD.DAT                    U-BOOT.BIN
> FIXUP_X.DAT                     UBLDR
> RPI2.DTB                        UBLDR.BIN
> START.ELF
>
> Now here's the thing -- the unix-side filesystem has to be good too,
> because the kernel is not in the MSDOS partition, it's in /boot/kernel
> on the Unix side and it both loads and starts!  But just for good
> measure, here's what we got in there:
>
> # mount -o ro /dev/da0s2a /mnt
> # df
> Filesystem             1K-blocks    Used    Avail Capacity  Mounted on
> /dev/ufs/rootfs         30229724  824548 26986800     3%    /
> devfs                          1       1        0   100%    /dev
> /dev/msdosfs/MSDOSBOOT     51128    7560    43568    15%    /boot/msdos=

> tmpfs                      51200       4    51196     0%    /tmp
> /dev/da0s2a             30233340 2299932 25514744     8%    /mnt
>
> I can mount it, and everything is there.  Specifically, if I look
> through /etc/rc.d and the /etc/rc file itself, both are present, as is
> /sbin/init and the checksums match too.
>
> With both filesystems mounted (the sd card cloned to on /mnt) tunefs
> says they both have the label set correctly and all the flags are the
> same -- the only difference is the space to hold for metadata blocks,
> which is likely because the original load was done with an image and
> then growfs resized it.
>
> # tunefs -p /mnt
> 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
>
> # tunefs -p /
> 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)            2488
> tunefs: optimization preference: (-o)                      time
> tunefs: volume label: (-L)                                 rootfs
>
> I've never had trouble cloning a disk like this in the Intel world and
> quite-clearly the system CAN find the cloned card's filesystem structur=
e
> or the kernel would not come up -- but it does....
>
> What the hell am I doing wrong?
>

--=20
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

--------------ms090105020105080907090509
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G
A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl
bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND
dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL
MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM
TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD
ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg
XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp
3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f
IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO
aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ
Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5
vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq
yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/
o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l
eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI
KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw
CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB
DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX
RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw
FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6
eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf
G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO
sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb
An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+
JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ
3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat
HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0
FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG
1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT
n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH
RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD
MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5
c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTMxOTU0MTJaME8GCSqGSIb3DQEJBDFCBED1
owVoZRaEDhENLJHrgxuw71er/79/QX8cypBTvfSYyug7u7eF4LMLCfnpLVJsF2lYIk1ytzUh
h6C+zPTXvU0LMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV
BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z
IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk
YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT
AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1
ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG
9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAqBIsmIJJ
HwcLjeisxqV7O5FJEzvQy/8WEgQcCJnl8sUeAZCGK1nLEUrk1lL3yxqbhRY8/o3+oCGFyFNi
fxuVi1fYuOwjFe/KuZZaq6U9wlMYfnCZAru/+pThiogyekdHMtrXJp/MNspdOxdCvKwUMlTN
yhV4viMX4GIO3K7uvXeWE99UX4KL4VrajNrHtizlERqexkSLwmjB8lSTa4nhCMoGf4r2Ugal
ZFMkRKEZXVcSFsQw3+8AhroqIQvj8Wo712A5rXBUbo5Tjw2uSgX/j9yDUjCg3epbqDR9bcnw
tD6VXwC+YH75fgBdmAZnGvx4/mgc+Q/U9JePm5mwqAingmeD7ocioEt9M+EDK3e0WoEDJPkp
ozBuzShkqeKgjTq1Dx8fphvlgPIKoj4UMDO8dulC2sQkDrNePviQUkLX4iIgov3hdsTqe/hd
R5hAlhFoix6opH3KxTtk95n+aUKVoKleYLfEAG+F+J22e9zE8rMgXrcFmGNf0mVur4zh2dVJ
tf4QY3KFA14d4Qr3591F9xiIzTxWR9WPK0wuKC7tpyPU1P2pYq2TCsiQ3ftuGc/Bom5sTE2c
PjsIk10+/4ocsaMNY8xsh/t/FgkS1V3dm36BI5s5+FnnTktUYaOR3XJ0VZj5G93Rgap+FI9c
Gjd2MsLT74rvrO1LgQMh7/kKqAcAAAAAAAA=
--------------ms090105020105080907090509--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d2eb4035-e494-1a7b-98e5-2aa87efe0763>