From owner-freebsd-arm@freebsd.org Wed Jul 13 19:54:15 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 76F3EB98DFE for ; Wed, 13 Jul 2016 19:54:15 +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 236871612 for ; Wed, 13 Jul 2016 19:54:14 +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 9DCE6220FA3 for ; Wed, 13 Jul 2016 14:54:13 -0500 (CDT) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... To: freebsd-arm@freebsd.org References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> From: Karl Denninger Message-ID: Date: Wed, 13 Jul 2016 14:54:12 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090105020105080907090509" 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:54:15 -0000 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 /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--