Navigation

    Netgate Discussion Forum
    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search

    Pfsense 2.0 NanoBSD on USB Thumbdrive workaround - Quick dirty fix

    2.0-RC Snapshot Feedback and Problems - RETIRED
    2
    7
    6051
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      dreamslacker last edited by

      I've been taking a look at making pfsense 2.0 work off a thumbdrive install and managed to find some useful information on making FreeBSD 8.0 work.  A write to a thumbdrive will normally result in the GEOM not finding the bootable device.
      This is a quick dirty fix that works remarkably well and just what I needed - I was previously using the full install on a Western Digital Raptor 10K RPM drive (only reliable spare drive I had) that was toasting the mini-itx setup and needed to reduce the heat output and power consumption.

      Setup

      • Intel D201GLY2 motherboard

      • 1GB Kingston ValueRam DDR2-667

      • Toshiba 4GB thumbdrive

      • pfsense 2.0 Beta 4 i386 built on Mon Sep 27 05:13:14

      The main problem it seems, is that FreeBSD 8.x doesn't wait for the USB device to mount properly before attempting to boot.
      This is solved by entering the command prompt on the first boot by pressing any key and entering: set kern.cam.boot_delay=10000 (I used 15000 because 10000 fails once in a few boots)
      Then enter: boot
      In short, look at the screenshot:

      After this is done, the system waits long enough for the USB thumbdrive to mount and it will work just fine.  The problem comes back on reboots though.  So I edited /boot/loader.conf (through Diagnostics -> Edit File so that there is no need to muck around with read/ write permissions):

      Caveats:  This setting will not survive a firmware update and the steps above need to be repeated after a firmware update.  Also, if the config is restored (as I did) immediately after the initial config, the first step of entering the command prompt needs to be done one more time when pfsense automatically reboots.

      Hopefully, this will help anyone who wants to use a thumbdrive for pf2.0.  They are cheaper than the CF cards and adaptors in some parts of the world (a CF->SATA adaptor costs more than a 4GB SLC flash over on my side of the pond).  The Toshiba drive is a cheap unit that is slow and I eventually intend to swap it out for a Sandisk Ultra Backup (basically a Sandisk Contour in a plastic shell) which is one of the fastest available and it is cheap.

      1 Reply Last reply Reply Quote 0
      • jimp
        jimp Rebel Alliance Developer Netgate last edited by

        Already a known issue… :-)

        http://redmine.pfsense.org/issues/495

        That setting may have to be used in loader.conf on the CD and elsewhere, or IIRC we can also set that in the kernel config.

        It would cause a longer boot time for everyone though.

        1 Reply Last reply Reply Quote 0
        • D
          dreamslacker last edited by

          Yep.  Didn't see it in a quick search through the forums though.  Took me jumping through a few hoops to find the solution through google and some FreeBSD boards.  Of course, it would increase the boot time but that beats not having a functional router.  ;D
          Would be nice enough if there's a way to just retain the loader.conf/ loader.conf.local upon upgrades.

          1 Reply Last reply Reply Quote 0
          • jimp
            jimp Rebel Alliance Developer Netgate last edited by

            loader.conf.local should be left alone on 2.0 full installs, but not for NanoBSD since that would require extra action post-upgrade. (See here: http://redmine.pfsense.org/issues/892 )

            1 Reply Last reply Reply Quote 0
            • D
              dreamslacker last edited by

              Yeah.  I saw that too when searching for a way to 'retain' the loader.conf file.

              Out of curiosity, is there a way to not reboot automatically after a full restore of a config file?

              1 Reply Last reply Reply Quote 0
              • jimp
                jimp Rebel Alliance Developer Netgate last edited by

                Not that I'm aware of without manually hacking the file to remove the reboot call.

                1 Reply Last reply Reply Quote 0
                • D
                  dreamslacker last edited by

                  Ok. Thanks a lot.

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post

                  Products

                  • Platform Overview
                  • TNSR
                  • pfSense
                  • Appliances

                  Services

                  • Training
                  • Professional Services

                  Support

                  • Subscription Plans
                  • Contact Support
                  • Product Lifecycle
                  • Documentation

                  News

                  • Media Coverage
                  • Press
                  • Events

                  Resources

                  • Blog
                  • FAQ
                  • Find a Partner
                  • Resource Library
                  • Security Information

                  Company

                  • About Us
                  • Careers
                  • Partners
                  • Contact Us
                  • Legal
                  Our Mission

                  We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                  Subscribe to our Newsletter

                  Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                  © 2021 Rubicon Communications, LLC | Privacy Policy