Nanobsd usbus0 still not fixed?
-
For whatever reason starting on pfsense 2.1 (2.0.3 is not affected), when on nanobsd it lists the ethernet ports as usbus0 during setup. This causes them obviously to not work. It also starts to boot on the wrong option. It boots to 1 then kernel panics from fstab. I remember fixing this changing the default boot option to 3. I am surprised this still isn't fixed. When I have to set the interfaces for the first time I literally have to guess the correct interface name… (and sometimes even then it does not work at all)
This affects two different computers I've tried. They have hardware that is completely different.
https://forum.pfsense.org/index.php?topic=63996.0
Same error seems to be here.
-
The error in the linked thread looks completely different to me. They have a rootmount error where the box failed to detect their CF card. You have an error where your network interfaces are incorrectly detected so you can't configure them.
Please give more details of the hardware you're using.
I have 2.1 NanoBSD installs on several different types of hardware and have not had any problems so it's not something inherent in Nano.
Steve
-
It's just an asus p45 deluxe board with two ethernet ports (p45 pqe)
The same thing happened on another computer with an e6300 and some g41/g31 motherboard with two intel nics for pci.
What I meant by the same issue was I have that as well. If I have my boot option as 1, it gives me a fstab error.
I have to change the default boot option to 3.
The normal version of pfsense 2.1 works.I am also having another weird issue where the wan connections gets dropped and I have to reboot. This happens randomly. (This is in the system log)
kernel: arpresolve: can't allocate llinfo for 10.10.10.1
I can can access pfsense via lan still from my computer (10.10.10.160 when this happens)Setup is:
Openwrt router(10.10.10.1) -> pfsense(10.10.10.100 as wan ipv4 gateway) and then it makes a lan for 192.168.1.1(dhcp disabled) No computers connect to the pfsense router, I just have it for openvpn. -
Ah, Ok. So when you select option 3 'Boot from USB' what your actually doing is telling the kernel to wait a short time in order for USB devices to power up/initialise themselves so they can be detected.
You can make that change permanently by adding the line:kern.cam.boot_delay=10000
to the file:
/boot/loader.conf.local
You will have to create that file if you haven't had to already.See:
https://doc.pfsense.org/index.php/Boot_Troubleshooting#Booting_from_USBSteve
-
I hit the thanks button too for taking the time out ;p
I was already using that fix and it works well. I also put in a hp dual nic pci express connector card and I haven't had openvpn or the wan interface disconnect yet randomly.
http://h18000.www1.hp.com/products/servers/networking/nc360t/I think that's what I am using, I got something like that on ebay for $20 and it works good.
I assume the onboard Marvell controllers do not play well with pfsense. https://www.asus.com/Motherboards/P5QE/#support Is the board
"Marvell 88E8056&88E8001 beta driver version 10.68.3.3 for Windows 7." Is listed under the drivers so I guess it's one of those.I also get better speedtest results by 20 megabits on the HP nics which shouldn't happen since they're both gigabit behind a strong q6600.
-
The Marvell NICs should be supported by the msk (8056) or sk (8001) drivers. The msk driver has a bug that shows up as a watchdog timeout in the logs with some hardware. There's a simple work around though:
https://doc.pfsense.org/index.php/PfSense_on_Watchguard_Firebox#Known_Issues_2Steve
-
Ah, Ok. So when you select option 3 'Boot from USB' what your actually doing is telling the kernel to wait a short time in order for USB devices to power up/initialise themselves so they can be detected.
You can make that change permanently by adding the line:kern.cam.boot_delay=10000
to the file:
/boot/loader.conf.local
You will have to create that file if you haven't had to already.See:
https://doc.pfsense.org/index.php/Boot_Troubleshooting#Booting_from_USBSteve
I can't edit my old post, but incase anyone else sees this thread. It should be:
kern.cam.boot_delay="10000"
I just put a new box and I remember I made this thread. Just updating it since someone else may run into this issue.