Date: Thu, 14 Jul 2016 11:44:53 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-arm@freebsd.org Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> In-Reply-To: <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <d2eb4035-e494-1a7b-98e5-2aa87efe0763@denninger.net> <EDE65B12-4961-4CEF-8AE9-BFDA4FD508A5@gromit.dlib.vt.edu> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms040705070201000600060102 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/13/2016 21:44, Karl Denninger wrote: > > On 7/13/2016 19:13, Paul Mather wrote: >>> On Jul 13, 2016, at 3:54 PM, Karl Denninger <karl@denninger.net> wrot= e: >>> >>> 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 >> Shouldn't this be /dev/mmcsd0s2a? You're referencing the entire BSD s= lice in the above command, not the UFS partition upon which the rootfs li= ves. > 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@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.) > Ok, so what's broken here folks? This is likely to blow up soon enough on the build systems that the people who are building snapshot releases are using (once they update); I assume this is a function of some sort of change that was made somewhere upstream in the system. The format of the card has to be: 1. MBR 2. First partition is MSDOS (Type "!12") with the various boot code on it (ubldr, etc.) This is fine. 3. The second partition has to be a "BSD" format partition (old-style) 4. Inside the second partition is a "traditional" BSD labeled (bsdlabel style) partititon table. Up to #2 all goes fine on an attached SD card: # gpart show da0 =3D> 63 62552001 da0 MBR (30G) 63 102400 1 !12 (50M) 102463 62449601 - free - (30G) Now we try to create the BSD labeled piece -- I got this from the crochet disk blob creator, incidentally, along with the FreeBSD Wiki (at https://wiki.freebsd.org/FreeBSD/arm/Raspberry Pi 2 image) # gpart add -t freebsd -a 4m /dev/da0 da0s2 added # gpart create -s BSD /dev/da0s2 *gpart: geom 'da0s2': File exists* *Heh, what was that? :)* What's in here? # gpart show 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) Hmmmm... what do we think exists for device nodes? # ls -al /dev/da0* crw-r----- 1 root operator 0x61 Jul 13 20:28 /dev/da0 crw-r----- 1 root operator 0x64 Jul 14 15:23 /dev/da0s1 crw-r----- 1 root operator 0x66 Jul 14 15:23 /dev/da0s2 crw-r----- 1 root operator 0x67 Jul 14 15:23 /dev/da0s2a Wait a minute, I didn't create any BSD slices! WTF? # bsdlabel /dev/da0s2 # /dev/da0s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 62439424 0 4.2BSD 0 0 0 c: 62439424 0 unused 0 0 # "raw" part, don't edit_ _ Oh really? How'd that get in there? And by the way, that's probably why the "add" fails (no space left and the first partition already exists= ) Further, this is *also* why I can "tunefs" the base (/dev/da0s2) because there's no offset (that is, /dev/da0s2 and /dev/da0s2a both point to the same first block) and that may be why the system refuses to boot when I'm done, as it's "tasted" the first entry, found a label and thus it's "open". In fact, that gap is *exactly* what I see when I run bsdlabel on the running card: # bsdlabel /dev/mmcsd0s2 # /dev/mmcsd0s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 62443392 90 4.2BSD 0 0 0 c: 62443482 0 unused 0 0 # "raw" part, don't edit It looks like the issue is that the "gpart create -t freebsd" command stuck a partition table in there which causes the "create -s BSD" to fail= =2E Strategically dding /dev/zero to the card's first 100MB or so (beyond the DOS partition and into the label) and then *again* on the freebsd partition *but before calling gpart to put the slice table on* results in the add working properly. # gpart show 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) # gpart show da0s2 =3D> 0 62439424 da0s2 BSD (30G) 0 128 - free - (64K) 128 62439168 1 freebsd-ufs (30G) 62439296 128 - free - (64K) # tunefs -p /dev/da0s2 tunefs: /dev/da0s2: could not read superblock to fill out disk # tunefs -p /dev/da0s2a tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) enabled 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 That looks valid and now matches the other card... but..... the new (duplicated) card still hangs in the same place..... It boots, the kernel loads, the root filesystem mounts and then the system hangs right after the ue0 MAC address displays on the console. How do you get the "why" on that since I have no way to break out of whatever it is hanging on (it ignores a ^C from a USB keyboard, although it *does* know it's there and the kernel displays attach/detach messages if you plug one in or out while it's hung) and there's no error message displayed that would otherwise help? --=20 Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms040705070201000600060102 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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTQxNjQ0NTNaME8GCSqGSIb3DQEJBDFCBEB/ Dd0o4tEbjNvNd2s6ZXkos4E0OlTn/GDa+ktn2pmNeRw3t2AULRsVnbbnSaJPyh75utw66RNj qmbAvJuTfk8NMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAlu44PfXZ 1zGjJFXo8K+GQ8/pHLsv5GqzTGXX/SK2JOCqgHMESzjEnGJCFIEKPlNpSUDMJPoOOZ6dqiyI NjyiNPkkRsmTTMpYlAVCn84zXfyYkD51RBQDL5yHm84dcb984fQz4V3ShhOOvanlk7U/Mqny 3esnphXsgCzwFCESE2UA90IP/xojFsqDk63ntjtZTfzruXwDf4SZyoWDgl6WvPEtNyuL4/Wz N1qlWfCXkhdKSvu7O+ulaa0HORYgUKkYOS8xU310vtrU0JhO12O/+ENwhSyn8chUNRGgEMaP YZrcLTt4KS+WSVvE8ZlCiqffG8X1Lob3hjrZJHtV3RxKmyXPWTc7G30Vn2taJp7P8KV+TA5K 4n8xYGx/7K8TDm0pZUnrUMrFg+BZE/txCpIhqFHvU9x/MnU+fZ5T28lTHdDerm7xU7qAjZt8 LTX6U9tIhQOIz5PMp6OC7pqmOG4P7BAirgfWSC62x/fGd3Ce5+wp/wDkgzziW1iJ7SSNI6n/ xmKDumPb+oj588PwIeM0Gtq7c473lABei048H/F2ebqhqKB1IsvDU4GiNO9hKn8zj17Rl6Ng 4CB2N7LaEPHVoQ8bgAZX9TslkBqdcTu/Icl3fvtRN8GSIPzy2MYoI+xFFmkBd0feGkaW9Xl6 9ufcAg2t5boE8kwloZ8A/8eU1SIAAAAAAAA= --------------ms040705070201000600060102--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?398ae56c-8893-f188-c210-cf7f19ccf433>