Project

General

Profile

Bug #495

USB drive fails to mount during boot

Added by Jeppe Oland over 9 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Operating System
Target version:
Start date:
04/10/2010
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.0
Affected Architecture:

Description

I installed pfSense-2.0-BETA1-20100407-1435 on a new SuperMicro X7SPA-H board.
The drive used was a 512 MB USB stick.
(During installation I removed the SWAP partition since otherwise there was not enough space).

After installing, it correctly boots from the USB stick and passes the initial pfSense option screen.
Then it fails to mount the drive like this:

--------------------- LOG FOLLOWS

If you have invalid mount options, reboot, and first try the following from the loader prompt:
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0

da0: set vfs.root.mountfrom.options=rw
<CBM Flash Disk 5.00> Removable Direct Access SCSI-2 device

da0: 40.000MB/s transferand then remove invalid mount options from
/etc/fstab.
da0: 482MB (987136 512 byte sectors: 64H 32S/T 482C)

Loader variables:
vfs.root.mountfrom=ufs:/dev/da0s1a
vfs.root.mountfrom.options=rw

Manual root filesystem specification:
<fstype>:<device> Mount <device> using filesystem <fstype>
eg: ufs:/dev/da0s1a
eg: cd9660:/dev/acd0
This is equivalent to: mount -t cd9660 /dev/acd0 /

?                  List valid disk boot devices
&lt;empty line&gt; Abort manual input

mountroot> ?

List of GEOM managed disk devices:
ufsid/4bc0604f03725fe0 da0s1a da0s1 da0
Loader variables:
vfs.root.mountfrom=ufs:/dev/da0s1a
vfs.root.mountfrom.options=rw

Manual root filesystem specification:
<fstype>:<device> Mount <device> using filesystem <fstype>
eg: ufs:/dev/da0s1a
eg: cd9660:/dev/acd0
This is equivalent to: mount -t cd9660 /dev/acd0 /

?                  List valid disk boot devices
&lt;empty line&gt; Abort manual input

mountroot> ufs:/dev/da0s1a

--------------------- LOG ENDS

After entering the boot device manually, it continues booting just fine.

pfSense 1.2.3 worked fine on the same hardware.

History

#1 Updated by Chris Buechler over 9 years ago

  • Category set to Operating System
  • Status changed from New to Rejected

This is a FreeBSD problem we can't do anything about. Replicate with a stock RELENG_8 and report to the FreeBSD stable list.

#2 Updated by Jeppe Oland over 9 years ago

This is a FreeBSD problem we can't do anything about.
Replicate with a stock RELENG_8 and report to the FreeBSD stable list.

Will do.

Since the device is actually detected, and entering it manually works, it's probably just a timing issue.

Is there no way to insert a slight delay before the system automatically tries mounting?
Or preferably that it tries, and if it fails it retries every second for a little while before failing.

#3 Updated by Chris Buechler over 9 years ago

Oh, yeah that reminds me of an issue that I think may have been discussed recently on one of the FreeBSD lists related to booting from USB and needing a delay. That might be it (though a change of that nature is beyond what we do, needs to be fixed upstream).

#4 Updated by Jeppe Oland over 9 years ago

I spent some time Googling, and found a few people discussing the problem.

It sounds like this patch might fix it until a good proper fix can be done.
http://www.mail-archive.com/freebsd-bugs@freebsd.org/msg00370.html

#5 Updated by Chris Buechler almost 9 years ago

  • Status changed from Rejected to New
  • Target version set to 2.0

Don't need the patch, just the loader.conf addition:
kern.cam.boot_delay=10000

#6 Updated by Jeppe Oland almost 9 years ago

http://forums.freebsd.org/showpost.php?s=d7af7671c4a56cb50af4c13e2fb7877f&p=91961&postcount=8

It looks like a configuration option was added to work around the problem.
I will try the latest BETA4 build over the weekend and report any success/failure back.

#7 Updated by Tim Nelson almost 9 years ago

This listed configuration option has been tested and confirmed to work. Test board was running 2.0 BETA3 on a Geode LX based system with an onboard Marvell USB<-->SATA controller.

#8 Updated by Sebastian Piecha almost 9 years ago

Had same problem mounting root from USB DVD drive with pfSense-2.0-BETA4-20100925-1629. Worked fine with pfSense 1.2.3.

After adding kern.cam.boot_delay=10000 to loader.conf and recreating iso-image root file system was mounted correctly.

#9 Updated by Ermal Lu├ži over 8 years ago

  • Status changed from New to Feedback

I think this should be documented somewhere and users can deal with it themselves.
It is not a bug in pfSense per se.

#10 Updated by Chris Buechler over 8 years ago

  • Status changed from Feedback to Resolved

Yeah I talked to thompsa a bit about this a couple days ago, our only option is to hard code kern.cam.boot_delay at a higher value for all installs, which always delays boot by 10 seconds. That's unacceptable. It's easy to escape to the loader prompt and set that for those who need to (no need to recreate the iso as others in this ticket have mentioned). I added to the boot troubleshooting page.
http://doc.pfsense.org/index.php/Boot_Troubleshooting

As far as we're concerned and can control, that resolves this.

#11 Updated by Sondre Slathia about 8 years ago

I just came across this issue still present on latest nightly build of embedded 4g pfsense 2. Is this issue resolved for embedded images?

#12 Updated by Jim Pingle about 8 years ago

Sondre Slathia wrote:

I just came across this issue still present on latest nightly build of embedded 4g pfsense 2. Is this issue resolved for embedded images?

It's a problem no matter what when booting from USB media regardless of whether it's a full install or embedded. Just insert the lines mentioned above in your /boot/loader.conf.local file and it will be fine.

#13 Updated by Florent THOMAS almost 4 years ago

Hi,

I've experimented the same problem with :
  • memstick 2.1.5 and 2.2.4
  • with or without the delay
  • with 2 differents usb from old and recent generation

Sadly no more success

#14 Updated by Florent THOMAS almost 4 years ago

Well,

I finally foun the issue, I was using Unetbootin and it was a bad choice.
Working with DD is magic!

Regards

Also available in: Atom PDF