Date: Wed, 13 Jul 2016 14:45:21 -0500 From: Karl Denninger <karl@denninger.net> To: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <548783e1-9047-68f7-5f50-449db684d602@denninger.net>
next in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format.
--------------ms060708050807010708030600
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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 sort
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 structure
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]/
--------------ms060708050807010708030600
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
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTMxOTQ1MjFaME8GCSqGSIb3DQEJBDFCBEAA
vsRL/odPvGZMGSY1jwP6gPynou1A/l0V11PGziDuxqv/oRsSJe6zjrDqft+M2+UxqD6l+2f7
lI+BZutDfH1YMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV
BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z
IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk
YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT
AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1
ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG
9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIANCyqPSjm
wXa4ca2DcWA4tz4zPpBpge7ZlQZ4aMMqqQL+oAH5T7Xoc8bS56ogAxNw20lU6iKR9/s/ysn+
r5p1VMhvabrjkG3kQJu6pFMC/hDyAVDyIVGuclKJGlyY6by5lm1CLvK1PDt9bWn0TDkwVo+I
HMiMxprF5ADJXt1D5WASqp3X9y1lJKQE3AkSRbErg+RWiIdZ5RJd/yTMafDh9AbZeR0b+rsh
R5ywkwg3BpgmE1r6H0vTS4mC2G+Us+5iaSnCLKGRHqSD1IUDj4utGKllcp+fyKj4/PZUpC0u
2MGvkmTm1YLEDwQJmN2i8QzqqQAjG4GHjaEUyUiHVMlaDiXfsLKHnak3OWUxIhlfm8HaOA3Q
wqXigHPMWBY408bBB/QYYq9Vp9EG4Q18v1ghg9hjQv49aX0v6CMRmyKoHnhdY6LS3l9XquSo
TjkFBL3b8XyqKnVNxbVajcSAQni4QCYm8jgl+eHVlmRRsKZLgEjwX32IYrKhK/lrHrb8KTfV
F3lWI1UIPaPjVmrYZbmJQyJQY/7C392TizMvPAWgKFIdRAfLO96OP8dNaLWe8+l8VZxrohrm
HPL5/RDQwKLLosEHUERSmgJ1b5vwTIb7tLxUwqtyPbFGANuABM8CTouRLqH0wh9HDwdz6Ukm
nOkNUmY4NLBDPsDq5/9eqtZfIZ0AAAAAAAA=
--------------ms060708050807010708030600--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?548783e1-9047-68f7-5f50-449db684d602>