Date: Fri, 15 Jul 2016 09:44:23 -0500 From: Karl Denninger <karl@denninger.net> To: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <d1aba096-e645-04df-dfda-5a9284250960@denninger.net> In-Reply-To: <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> 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> <bec46aff-a4d5-9c4d-49d0-78534b13f719@denninger.net> <E01579F5-9562-4E51-9CFB-EA510460A4C8@gromit.dlib.vt.edu> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format.
--------------ms050309030404030506070706
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 7/15/2016 09:22, Paul Mather wrote:
> On Jul 15, 2016, at 9:44 AM, Karl Denninger <karl@denninger.net> wrote:=
>
>> On 7/15/2016 08:36, Paul Mather wrote:
>>> On Jul 14, 2016, at 11:36 PM, Karl Denninger <karl@denninger.net> wro=
te:
>>>
>>>> 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 shoul=
dn'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 th=
us
>>>> 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 h=
angs
>>>> without ever proceeding -- and without any sort of error message
>>>> indicating that it is unable to mount something it needs.
>>> You have to do that because the device entry in the stock /etc/fstab =
is /dev/msdosfs/MSDOSBOOT. The /dev/msdosfs part indicates it's using ms=
-dos labels. In other words, this is just the same sort of failure you w=
ere getting when you weren't labelling the UFS partition as "rootfs". La=
belling the file system properly "fixes" the issue, as you would expect.
>>>
>>> It's a misnomer to say the code "requires" labels. It's just that's =
the way the distribution images are currently set up. I have an older Pi=
that predates the current distribution images that just uses /dev/mmcsd0=
=2E.. device names in /etc/fstab. Both approaches work fine. You just n=
eed to make sure the devices you specify in /etc/fstab will actually exis=
t when it comes time to mount the corresponding file system.
>> Except that if the root filesystem doesn't mount you get an error, and=
>> thus you can figure out what's going on. What excuse is there for not=
>> printing an error message if a mount fails, and if something in
>> /etc/fstab fails to mount what's with hanging the machine? I've had
>> disks be unavailable before on Intel architecture machines (it happens=
>> when disks fail) and the result is an error on the failure to mount bu=
t,
>> unless it's the root volume, the system still comes up.
>
> Are you sure you don't get an error? When I forgot to label rootfs rec=
ently when I cloned an SD card I got an error displayed on the serial con=
sole. I didn't get an error on the HDMI screen console.
You get an error if rootfs is not labelled on the HDMI screen (as root
fails to mount.) There is *no* error on an HDMI screen if the msdosfs is
not labeled.
> As I've mentioned before directly, FreeBSD/arm acts like console=3D"com=
console,vidconsole" is in effect. This means that during /etc/rc boot pr=
ocessing, you'll only get output on comconsole (except for kernel message=
s, which seem to go to both). That's been my experience in FreeBSD in ge=
neral.
>
> I dimly recall folks on here saying U-Boot doesn't currently enable/sup=
port USB keyboards, so there's not really much you can do to fix it inter=
actively if you fail to boot the OS and hence enable USB keyboard support=
via FreeBSD. That's not a problem if you use a serial console, which is=
supported by U-Boot.
Well, that's not true if the kernel is loaded. Once the kernel loads a
usb keyboard works.
>
> I'm not sure comparisons with Intel architecture machines is entirely a=
ppropriate as they use a different boot environment/mechanism. Still, I =
stand by the fact that I've always got an error message on the serial con=
sole when disks on my FreeBSD/arm system have failed to mount at boot. (=
It used to happen regularly with an external USB drive I had that took a =
long time to probe, and I ended up having to put a kern.cam.boot_delay in=
/boot/loader.conf to avoid the system dropping into single-user mode whe=
n doing a reboot.)
>
>
>>> If you stop using labels in your /etc/fstab then you won't have probl=
ems when those labels are missing. If the labels are missing, the /dev/{=
msdosfs,ufs} devices will not be present and the system will drop to sing=
le-user mode because none-late, non-noauto file systems can't be accessed=
via their device nodes when attempting to mount them. When that happens=
and you don't have a serial console enabled then you have problems remed=
iating the situation.
>>>
>>> If a file system is not needed to mount as part of booting (as you su=
ggest for /boot/msdos) then you should probably flag it with the "noauto"=
option in /etc/fstab or remove it from /etc/fstab entirely.
>>>
>>> I think the problem you were having is not copying all the required a=
ttributes of the file systems in question when cloning your SD cards, giv=
en your /etc/fstab setup. It sounds like you've fixed that, now.
>> Again, if it dropped to single user mode *and said it was doing so* or=
>> if there was an error message on the console when the filesystem faile=
d
>> to mount I would have found this in a reasonable period of time. It
>> wasn't that rough to do so with the ufs label once I knew the filesyst=
em
>> was failing to mount, which was discernible from the console output.
>>
>> Not printing an error when things error out is rude at best, and when
>> that error is going to prevent the system from coming up this darn wel=
l
>> ought to show up where one with a monitor plugged in can see it, eh?
>>
>> There was literally no indication at all as to what was going on and
>> since gpart does not show filesystem labels for *either* BSD labeled
>> slices OR msdos figuring out what was different between the two proved=
>> to be a bit troublesome. IMHO at least the failure to display an erro=
r
>> message in this circumstance ought to be corrected.
>
> See above re: serial console vs. video console.
>
> As for the labels, these are file system labels and not partition label=
s. The big clue is in the device name in /etc/fstab. (The "-l" option t=
o "gpart show" will only show labels "[f]or partitioning schemes that sup=
port partition labels". That's reasonable, IMHO, as partitions are not t=
he same as file systems and gpart is concerned with partitions.) In my e=
xperience, complaints about not being able to access /dev/ufs/something m=
eans you forgot to label a UFS file system as "something" when you made i=
t. :-)
>
> Cheers,
>
> Paul.
Understood, but the issue here is that there's no indication without a
serial console that you have anything wrong -- the system appears to
have simply hung.
The quick fix is to put "failok" (or noauto) in the default /etc/fstab
entry for the dos filesystem, since it is not necessary for that
filesystem to be mounted at all on a running machine. If there is a
policy reason to leave it accessible (and there's a fairly-clean
argument that there is) then "failok" might be preferable to "noauto",
but either way forcing a filesystem that is not necessary to be
accessible or the system fails to come up and does not give any
indication of same on what many users will have accessible to them is
facially wrong.
These devices are thought of as "appliances" by many and as such the
model of USB keyboard + HDMI (e.g. TV or monitor) is entirely
reasonable, and IMHO FreeBSD ought to, when possible, make that a viable
option. It both is and can be provided the kernel loads, but the
defaults in pre-built configurations right now preclude that.
--=20
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------ms050309030404030506070706
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
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MTUxNDQ0MjNaME8GCSqGSIb3DQEJBDFCBEAU
BWw+e2UIci1jPGY5CcQURgT3a9qt26aoyPnMXmwf083eRtotXqguxULx6bKS473IysQtykVc
RVUJgxs/Qe/aMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV
BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z
IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk
YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT
AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1
ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG
9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAsqk3ZkjH
t5go36OFOsxX5TxkvwAD8Ycr3fPSdpwTaKl/RJWJ8zud6igigO1Lbifij/I0hkyGszWn+3aa
02YOmUAhBmXr2E138r51kHB/FtjznE6WU2Vx5TetUJgSVr8uqIus2xetvIeKHLqNQCojQA/s
dOaWBqPByXco62eHLh/F204XXJate/0GJ2UTgVqFWFriy6Jj3okx7IHj3vARtKtbiMAWWIQG
D6OW8wkc+GYQjlkpOu6SVWjFFsQ6aE4gMIM8c2+wqn1BI/N0ymWhUErrl1221bZkPIC7h1rx
Yj46uQmcn4jrkIh+R8+nNvobdxwXt3/QA+vbO0QhqMMIVvU/FPfWLf7VWc3v+yZlpVxKTLH9
W7siFt9sJ6EnbXdopYufDTiRQOpoOe//7ilrH1wRcsWyv7CBCtGdpQGXCQg+yzoNDmrj8jXe
HDcooHdihOKe5kpqfmbtvBAYjzZmDvADGp8GeIaPfOgFPh8yo4gvcxU833CG4uZHsfBMLiuL
vkgHbu91MWomIdiCdcd7GeySmO5Sa0iRgr4S5oUGsN8Ojdc5G52g8rcv5z5kY3OHTISRfbjH
/3yfYzLZAuDzyV41FqCoMsnRHpIzh45gvZB09gJPEXUESQAawbW5bfkz/JIQ53VnVKxr9qcw
AEZqVcBuCk2wOqNru9NkRwDRqdgAAAAAAAA=
--------------ms050309030404030506070706--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d1aba096-e645-04df-dfda-5a9284250960>