Created attachment 168654 [details]
dmesg output from a successful boot noting differences from hung boot.
I am using FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20160308-r296485.img and experiencing a problem with USB flash drives and the built-in RPi Ethernet. In summary, as soon as I add my USB flash drive to /etc/fstab, the system will never complete the boot process and ue0 never change the link state. Once this happens, disconnecting the flash drive from the RPi and rebooting does not help. Only if the flash drive is never added to /etc/fstab, will the system boot normally.
I don't recall experiencing this problem when using FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20160127-r294912.img and wonder if the new problem may have been introduced by changes made for "Bug 199446 - arm Raspberry Pi panic without ethernet connected on boot"
Here is how to reproduce it:
1) Install FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20160308-r296485.img
2) Insert a USB flash drive
3) Create a UFS filesystem on da0p1
4) Add /dev/da0p1 to /etc/fstab
5) Restart the Raspberry Pi
Troubleshooting steps I've taken:
Erased (dd if=/dev/zero of=/dev/da0) the flash drive and set up partition again)
Used different brand of flash drive.
Added the option 'noauto' to fstab.
Used another, known good RPi2.
Used another, known good power supply.
Used another, known good SD card.
None of the above makes a difference and still results in the hung boot.
I swapped components (flash drive, power supply, SD card and RPi itself) with a Linux-based media center. I cannot reproduce the problem on the media center.
Do not add flash drive to fstab, but mount manually after booting.
I am attaching the dmesg output from a successful boot when the flash drive is not in fstab. Unfortunately I cannot include dmesg output from the hung boot, but I do notice that the 'ue0: link state changed to DOWN' and 'ue0: link state changed to UP' lines never appear on the screen.
Did you try pressing CTRL+T to see what the current process is doing?
This might be a rc.d script problem and not directly USB related.
I had similar issue and fixed it by adding the 'late' mount option to the USB drive in /etc/fstab.
I have not tried CTRL+T since I've set this up as a headless server and do not have a keyboard for it. Normally I just wait for the IP to show up in my router's DHCP list and connect via SSH. When it did not show up, I attached the Pi to my television and that's when I noticed it getting hung up. It could very well be an rc.d script problem since the hung boot persists even if I remove the flash drive and power cycle the Pi.
I found where the error is occurring, though I'm not sure why. I've got my RPi2 attached to one of those Adafruit console cables and this is what I am seeing:
Starting file system checks:
/dev/ufs/rootfs: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ufs/rootfs: clean, 7098588 free (244 frags, 887293 blocks, 0.0% fragmentation)
Can't stat /dev/da0p1: No such file or directory
THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY:
ufs: /dev/da0p1 (/home)
Unknown error; help!
ERROR: ABORTING BOOT (sending SIGTERM to parent)!
Apr 15 21:47:52 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode
Enter full pathname of shell or RETURN for /bin/sh: uhub1: 5 ports with 4 removable, self powered
So the hanging I experienced before was the system waiting for me to press a key to go to the shell.
The funny thing is that when I go into the shell and list the files in /dev, /dev/da0p1 does indeed exist. Furthermore, I can manually run 'fsck /dev/da0p1' without any problems. Once I do that, /dev/da0p1 is marked clean and when I exit the shell, the boot process continues. (See attachment for details.)
So it seems like a timing issue, that da0p1 is not there when fsck runs. I even tried Sylvain's suggestion of using the 'late' option in fstab, but nothing changed. It still complains about not finding /dev/da0p1 and waits on manual intervention.
I am attaching a log of the boot output. Line 214 shows where the trouble begins. Please let me know if you'd like me to try anything else to help narrow this down.
Created attachment 169357 [details]
Console output from boot requiring manual intervention