Date: Fri, 15 Jul 2016 10:22:26 -0400 From: Paul Mather <paul@gromit.dlib.vt.edu> To: Karl Denninger <karl@denninger.net> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> In-Reply-To: <60b6e156-981e-9fbd-b68c-0daae1961286@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> <bec46aff-a4d5-9c4d-49d0-78534b13f719@denninger.net> <E01579F5-9562-4E51-9CFB-EA510460A4C8@gromit.dlib.vt.edu> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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> =
wrote:
>>=20
>>> Found it.
>>>=20
>>> 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!
>>>=20
>>> So, you must do newfs_msdos -L MSDOSBOOT -F 16 {device}
>>>=20
>>> 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.
>>=20
>> 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 were getting when you weren't labelling the UFS partition as =
"rootfs". Labelling the file system properly "fixes" the issue, as you =
would expect.
>>=20
>> 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... device names in /etc/fstab. Both approaches work fine. =
You just need to make sure the devices you specify in /etc/fstab will =
actually exist 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 =
but,
> 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 =
recently when I cloned an SD card I got an error displayed on the serial =
console. I didn't get an error on the HDMI screen console.
As I've mentioned before directly, FreeBSD/arm acts like =
console=3D"comconsole,vidconsole" is in effect. This means that during =
/etc/rc boot processing, you'll only get output on comconsole (except =
for kernel messages, which seem to go to both). That's been my =
experience in FreeBSD in general.
I dimly recall folks on here saying U-Boot doesn't currently =
enable/support USB keyboards, so there's not really much you can do to =
fix it interactively 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.
I'm not sure comparisons with Intel architecture machines is entirely =
appropriate 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 =
console 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 when doing a reboot.)
>=20
>> If you stop using labels in your /etc/fstab then you won't have =
problems 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 single-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 remediating the situation.
>>=20
>> If a file system is not needed to mount as part of booting (as you =
suggest for /boot/msdos) then you should probably flag it with the =
"noauto" option in /etc/fstab or remove it from /etc/fstab entirely.
>>=20
>> I think the problem you were having is not copying all the required =
attributes of the file systems in question when cloning your SD cards, =
given 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 =
failed
> 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 =
filesystem
> was failing to mount, which was discernible from the console output.
>=20
> 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 =
well
> ought to show up where one with a monitor plugged in can see it, eh?
>=20
> 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 =
error
> 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 =
labels. The big clue is in the device name in /etc/fstab. (The "-l" =
option to "gpart show" will only show labels "[f]or partitioning schemes =
that support partition labels". That's reasonable, IMHO, as partitions =
are not the same as file systems and gpart is concerned with =
partitions.) In my experience, complaints about not being able to =
access /dev/ufs/something means you forgot to label a UFS file system as =
"something" when you made it. :-)
Cheers,
Paul.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?04391154-A38E-46CD-B570-B2BECFD19022>