From owner-freebsd-arm@freebsd.org Wed Jul 13 19:45:31 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04BB8B98B9F for ; Wed, 13 Jul 2016 19:45:31 +0000 (UTC) (envelope-from karl@denninger.net) Received: from mail.denninger.net (denninger.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A22251F2F for ; Wed, 13 Jul 2016 19:45:30 +0000 (UTC) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (Karl-Desktop.Denninger.net [192.168.1.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.denninger.net (Postfix) with ESMTPSA id 5B8B0220F06 for ; Wed, 13 Jul 2016 14:45:22 -0500 (CDT) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> Date: Wed, 13 Jul 2016 14:45:21 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060708050807010708030600" X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 19:45:31 -0000 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 /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--