Bizarre clone attempt failures on Raspberry Pi2...

[Karl Denninger]

On 7/15/2016 08:36, Paul Mather wrote:
> On Jul 14, 2016, at 11:36 PM, Karl Denninger <karl at denninger.net> wrote:
>
>> 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.
>
> 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.
>
> 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.

> 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.
>
> 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.
>
> 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.

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?

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.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20160715/89fedd77/attachment.bin>