Date: Thu, 14 Jul 2016 13:27:35 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-arm@freebsd.org Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> In-Reply-To: <1468518953.72182.219.camel@freebsd.org> 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> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms080000060206080005050305 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 7/14/2016 12:55, Ian Lepore wrote: > On Thu, 2016-07-14 at 11:44 -0500, Karl Denninger wrote: >> 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 >>>>>> wrote: >>>>> 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 slice in the above command, not the UFS partition upon which >>>> the rootfs lives. >>> 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) =20 >>>>> disabled >>>>> tunefs: NFSv4 ACLs: (-N) =20 >>>>> disabled >>>>> tunefs: MAC multilabel: (-l) =20 >>>>> disabled >>>>> tunefs: soft updates: (-n) =20 >>>>> enabled >>>>> tunefs: soft update journaling: (-j) =20 >>>>> disabled >>>>> tunefs: gjournal: (-J) =20 >>>>> disabled >>>>> tunefs: trim: (-t) =20 >>>>> disabled >>>>> tunefs: maximum blocks per file in a cylinder group: (-e) 4096 >>>>> tunefs: average file size: (-f) =20 >>>>> 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) =20 >>>>> 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? :)* >> > There's nothing new or different-on-rpi about this. There was > previously a BSD geom there.=20 No there wasn't. It was a blank (brand new) card the first time around; it had a MSDOS filesystem on it (as do all new cards) but *no* BSD-specific geom anything on it. > To reliably create a new layout regardless of what may be present > already on the media, you have two choices: > > 1 - dd zeroes to the entire device > 2 - use the "no commit" feature of gpart Actually in the case at hand #1 isn't impractical since I really only care about the first 100MB or so being zeroed. The reason is that my boot block (the MSDOS fs) is ~50Mb and the label is obviously next, so if we zero the first 100MB we're fine. And in fact that does work. > When you pass no '-f <flags>' to a gpart command, it automatically adds= > the "-f C" (commit) flag behind your back. There is no "don't commit" > flag, so (this is surrealistically crazy...) what you're supposed to do= > is pass an invalid flag, which it won't complain about, in order to > prevent it from automatically adding that 'C' flag you didn't even > realize existed. (This is where *I* curse whoever coded this mess.) > > When you don't commit, the changes take place in a sort of 'virtual > workspace' and nothing on the physical disk changes until you do a > "gpart commit" (or "gpart undo" to discard the changes). Making all > this much-less-cool that it's sounding right now, there is no automatic= > recursion for commit and undo... if you create a bunch of nested stuff > (a slice, a geom within that slice, parititions within that geom), then= > you have to commit all the pending new geoms *in reverse order of how > they were created*. > > So, using da0 (since it's shorter to type), the sequence goes like: > > gpart destroy -f x -F da0 > gpart create -f x -s MBR da0 > gpart add -f x -t \!12 -s 64M -a 4M da0 > gpart add -f x -t freebsd -a 4M da0 > gpart destroy -f x -F da0s2 > gpart create -f x -s BSD da0s2 > gpart add -f x -t freebsd-ufs da0s2 > gpart commit da0s2 > gpart commit da0 > newfs_msdos /dev/da0s1 > newfs -U /dev/da0s2a > > And that reliably creates a fresh rpi-style layout regardless of what > was on the media before you started. Ok, I will try this, BUT I suspect it's still screwed (blind) because when I zeroed the front of the disk I got a "correct" partition layout but after populating it what I get still hangs after it mounts root in the same place. The way to prevent the alignment issue from coming up is to specify a "-b" switch on the "add", giving you a block offset.=20 "-b 64" is sufficient; now if the system tries to "taste" da0s2 it will fail (as it does for the card that is running) but "tasting" da0s2a succeeds. > Now, to address the question of the filesystem existing at da0s2 versus= > da0s2a, the difference is alignment. Making things even more > confusing, alignment (if you don't specify it) sometimes changes based > on the type and brand of usb sdcard reader you're using and the fake > geometry values it reports to the system. (A USB reader almost always > reports different fake geometry than a native sd slot would on a > machine with non-USB based sd support.) Yes, I understand that; if the alignment matches thus the "a" partition starts at offset zero then you can actually reference that (although length might be wrong) with the base device. After all, what it really does is look at the blocks to see if the magic number is good, and if so it tries to read and process it. But this doesn't explain why, after getting a layout that's correct (by writing zeros to the front of the card first, so anything that "might" be there isn't) and copying all the file structure over (which facially not only appears to be correct but the loader finds and loads the kernel, AND the root filesystem mounts!) the system hangs, apparently just before init gets started. If init can't be found you should get a complaint (been there, done that) on the console but there is no complaint of any sort. I've gotten through the bad structure issue on the SD card, and am now left with "why does it hang on boot -- with no error or other indication of what the problem is" after the kernel loads *and* the root filesystem mounts? --=20 Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080000060206080005050305 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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTQxODI3MzVaME8GCSqGSIb3DQEJBDFCBECr KgludZbd+i5FfLayqTbe0byi+Fqvq2LhwPwuQ0k1ngJNSS9ITfbiJaaneB7KAc6Ge7aIGJBZ CA2hTgkgCfygMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAah29Ii30 Au6YvejxiUocOMZrtDgx4LA7dy17YKMWggI131TXWC9OQWvcaiX4GmvW7HlSsfKx7GShiaaN B/kaNNxYI1gAcJnZvHEilIV/QYo3YmCaGior1+Ew5i2k8DnIn/KkdVKs8geYiL4UU/nvcdnV ya3O/BIw9LfIc3014Fln6RowCkjkhMoarnY3hIbLzVcJrLw549jR1xlcnLAMhYPMYTpK9bYI gO32MCSEyQYyRJzBg9cZ1Z4cFr76Xcx2sGtfqg3YmtvI6/PreLkZJxHb3ND0WFMhcMt/2WrI CGTjz9dg2F2MS498ertLfLHRagIcOiz6vlNcRDVuZXa9fuA45YENJinrL+bB56uII7r/3xAa 51ORqqpGa12BEZQFMoY8XYhPr1RNWPUFowsls/w5vh9u0hxxi8iAjjxYObkw5ho4liyBxP6O Z3zN8zvSN+jVlZa28Yrcv1H71GSxqny6wk2MTxEmSfeiHDnI0RNHqY7lz58Wq43g7Zps4VB4 5YlWyijl5QyUHBZw3/ZP3NNgqCNl5NH60vQ281tOHP/ijzDB82v9ZXdRTGG45LHq9CesZ9lT Pf+j1uMnM/c4bSryXhuy1vdBGl94RDe/xAN7kp/d0WTPq8TbvkRoYTVoR26KKbOo0+IEVYzL 8wiQFRHG7gket4UOtfBQEXw3y8AAAAAAAAA= --------------ms080000060206080005050305--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7a91fc79-1c85-fac8-aa3f-db90592f3f44>