Summary: | Adding USB flash drive to fstab hangs boot on Raspberry Pi 2 | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Dave <dhorton668> | ||||||
Component: | arm | Assignee: | freebsd-arm (Nobody) <freebsd-arm> | ||||||
Status: | New --- | ||||||||
Severity: | Affects Only Me | CC: | dhorton668, hselasky, sylvain | ||||||
Priority: | --- | ||||||||
Version: | CURRENT | ||||||||
Hardware: | arm | ||||||||
OS: | Any | ||||||||
Attachments: |
|
Description
Dave
2016-03-26 15:48:09 UTC
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. --HPS I had similar issue and fixed it by adding the 'late' mount option to the USB drive in /etc/fstab. HPS, 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. Dave 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
|