Date: Thu, 14 Jul 2016 22:36:35 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-arm@freebsd.org Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <bec46aff-a4d5-9c4d-49d0-78534b13f719@denninger.net> In-Reply-To: <7a91fc79-1c85-fac8-aa3f-db90592f3f44@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> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format.
--------------ms060700030308030407000306
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 7/14/2016 13:27, Karl Denninger wrote:
> On 7/14/2016 12:55, Ian Lepore wrote:
> 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 add=
s
>> 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 d=
o
>> 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 automati=
c
>> recursion for commit and undo... if you create a bunch of nested stuff=
>> (a slice, a geom within that slice, parititions within that geom), the=
n
>> 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 versu=
s
>> 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 s=
o
> 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 indicatio=
n
> of what the problem is" after the kernel loads *and* the root filesyste=
m
> mounts?
>
Found it.
Apparently the current code *requires* the label be set on the msdos
partition. If it's not then not only does it not mount (which shouldn't
matter post-boot as the loader is supposed to pass the dtb file, it is
specified in the config file without any sort of path prefix, and thus
once the kernel has loaded it should not matter if the dos partition if
actually mounted or not) *but* the boot process hangs without any
indication of why!
So, you must do newfs_msdos -L MSDOSBOOT -F 16 {device}
If the "-L" is missing you're hosed; the system facially appears to be
just fine but while the loader comes up and so does the kernel, it hangs
without ever proceeding -- and without any sort of error message
indicating that it is unable to mount something it needs.
I can clone cards now.
--=20
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------ms060700030308030407000306
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
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTUwMzM2MzVaME8GCSqGSIb3DQEJBDFCBED3
2eXUs69rN4wP6UaYrq6gFMKzRf6x+1dmM50d/eEiILacJsG26+oXuCZLOWjwdYBsDaPyHSMb
F6xO6kl2bWFMMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV
BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z
IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk
YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT
AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1
ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG
9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAO2aRDFU3
mF+JTZ0qbiST1rRPgApWL8onamBZvPnkcpuVikKZuMMA63AZ4WPk1t+nF35/cLu0dURNVmmO
G6YJ8L8m7iGrz7szgD6QSNKkK2VNR2jtUnXBw7uK+5lgh3FHyOpWgh4JTKGji75HE3QP4kS6
FE0g0CQ3LIDl97bRrxdihMixqdZ/zEyxwTeapy27Uwx3Jr/cwD9hubEznjGgxqR5pTcOx4lF
qvfjelSxXazp4SONxQDJy7tW2Exzdh3Tz/VMep2YlMncH9wjaaaw+nezIWiNmVYGlg8wVvRO
vf3t21PQK4MnHCjE914xhezRmnjHcZyi6b6mAYJOntc/u8qH9E/f3TbhZjUfjKQT7jvmPMlr
xTT7hMbdvXYaAOQwWvcK6ZSnsQOSGXMIagozLW+U2uabcUqHaXtoxolfw65Jz1ltMPiGioJj
W0sTenAqpfT/tEympSDeaJqCfJcYg7OFaN3GVdFbACp7k0OstKfio2OlBA4xWLkOyJgpeedT
KW6k4VJaB2EC+FDeONkkNE49tj2WghixHFH9APFSa6pWMGFFClVwKV+V6qZIghjzRnIRx6Xs
LJeQ2s3we4yRrxu8RjDlRT3zcrHKMgiZ2RNUAOmcBbx5L6iRPGI4xD4lNCBRirCpvWxYXhKg
JG82pU9iNyT5RtydKcGiPoCk/ssAAAAAAAA=
--------------ms060700030308030407000306--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bec46aff-a4d5-9c4d-49d0-78534b13f719>