Bug #495
closed
USB drive fails to mount during boot
0%
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
<empty line> Abort manual inputmountroot> ?
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
<empty line> Abort manual inputmountroot> 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.
Updated by Chris Buechler about 14 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.
Updated by Jeppe Oland about 14 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.
Updated by Chris Buechler about 14 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).
Updated by Jeppe Oland about 14 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
Updated by Chris Buechler over 13 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
Updated by Jeppe Oland over 13 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.
Updated by Tim Nelson over 13 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.
Updated by Anonymous over 13 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.
Updated by Ermal Luçi over 13 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.
Updated by Chris Buechler over 13 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.
Updated by Sondre Slathia almost 13 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?
Updated by Jim Pingle almost 13 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.
Updated by Florent THOMAS over 8 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
Updated by Florent THOMAS over 8 years ago
Well,
I finally foun the issue, I was using Unetbootin and it was a bad choice.
Working with DD is magic!
Regards