Critical issues with 2.3CE nanobsd amd64 4g on SD card
-
What CF cards are those specifically (make and model), and what hardware are you using?
-
@cmb:
What CF cards are those specifically (make and model), and what hardware are you using?
Was a prebuild pfsense from a german official reseller (on your list)
AMD APU1D4 [3x 1Gbit Realtek; 1GhZ Dualcore; 4GB DDR3]
came with 8GB Transcend SDHC Class 10 (TS8GSDHC10)The other CF I tried was a PNY 32GB SDHC Class 10 (SD32GBHC6-EF)
-
Ah, APU so SD rather than CF. Thanks for the info.
All our release testing on APUs is with Sandisk SD cards, which do fine with the mount speed. I have some other cards that are slow to re-mount though, will give one of those a shot.
-
I usually call them CF somehow I'm used to, but yeah, I should correct it to SD I think.
Sorry for the misleading.Do you test with a specific type of SanDisk? I might consider getting one of those to have better compatibility with your upcoming releases then. (And I'd need an other backup card anyway in case an update went terribly wrong so the guy at the branch office could switch cards in a worst case scenario)
-
For those who are seeing "Device busy" or similar and unable to force the disk read-write, try the following (preferably from the console):
umount -f /cf; fsck -t ufs -y /cf; mount -f -o rw /cf
Not something we'd normally recommend but somehow it seems that just the /cf slice is getting wedged for some people at the OS level.
Once that is done, set the permanent RW flag on Diagnostics > NanoBSD.
If you're running on an APU+SD card, I'd seriously consider reinstalling from a memstick-serial image as a full install. Activating the option to keep /tmp and /var in RAM will keep writes low, and the sizes can be tweaked so you have decent space there. Your overall experience is likely to be much better that way on APU than with NanoBSD. Short of using an mSATA anyhow.
-
If you're running on an APU+SD card, I'd seriously consider reinstalling from a memstick-serial image as a full install.
Any recommendations for a good memstick, maybe a type you test with?
Oh, and - that would only increase the performance for the one who administrates it, right? Not the firewall performance itself.
-
If you're running on an APU+SD card, I'd seriously consider reinstalling from a memstick-serial image as a full install.
Any recommendations for a good memstick, maybe a type you test with?
The specific memstick doesn't matter much for what I meant – that's only used for the installer. I test using a wide variety of USB thumb drives for installing pfSense, but at the moment my favorites are this PNY 16GB drive and these Sandisk Cruzer 16GB drives.
Oh, and - that would only increase the performance for the one who administrates it, right? Not the firewall performance itself.
It depends on the specific features used. It wouldn't affect packet processing, though it might affect daemons on the firewall that might touch the disk for one reason or another. If you're primarily using basic firewall/routing/NAT functions it wouldn't likely be any difference in speed.
-
I'm using it for firewalling (dual wan), snort (one wan gateway only) and openvpn client.
Would it still be ok to keep running the SD (tbh I had no idea when I purchased this model, I just didn't want to spend too much money for a 1-2PC branch office being connected to our main office ^^) -
You just use the memstick image to boot the appliance into the installer, just as you would do with a CD-ROM, if you had a drive in it. You do a full install on the SD card.
-
Oh, I see, then I misread it at first. Will try this when I get the SDHC-Card 16GB, SanDisk Extreme Pro 95MB/s, maybe 2.3 will run on it like it should (the firewall goes live next week, so there's still time to mess with it ^^)
-
Note that when installing "Full" on flash-based media (CF or SD or DOM, etc), my advice would be to avoid creating a Swap partition.
If there's a swap partition present pfSense will mount it - and using flash media as swap space can be really hard on flash wear. Of course, if swap space is really used - but to be on the safe side, I'd suggest not to use swap at all - on NanoBSD it didn't exist anyway - on embedded platform swap was not present…I guess there should be an extra option during setup - Automatic install on flash-based media, to avoid automatic creation of swap space.
-
For those who are seeing "Device busy" or similar and unable to force the disk read-write, try the following (preferably from the console):
umount -f /cf; fsck -t ufs -y /cf; mount -f -o rw /cf
Not something we'd normally recommend but somehow it seems that just the /cf slice is getting wedged for some people at the OS level.
Once that is done, set the permanent RW flag on Diagnostics > NanoBSD.
Jimp, is this safe to do over SSH from a LAN computer that I am RDP'd into? (I am not onsite)
-
umount -f /cf; fsck -t ufs -y /cf; mount -f -o rw /cf
Jimp, is this safe to do over SSH from a LAN computer that I am RDP'd into? (I am not onsite)
We have done that exact thing remotely several times with no ill effects, but there is always a chance it could go sideways so I can't say it's completely safe.
