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

    Which install media for SG-2440?

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    14 Posts 5 Posters 3.4k Views
    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.
    • S
      signal7
      last edited by

      Ok - thanks for the note, I'll give that a shot and post my results.  I couldn't find any documentation on the appliance itself other than the product specs.  Links to download pfSense don't indicate which download fits this hardware.

      The 'appliance' nature of this device doesn't make it clear that it would be so fragile in a power outage.  Either the root fs should be read only as necessary or the filesystem should be journaled.  This problem has been fixed for years, so it surprises me that I would need to buy a ups when one shouldn't have been required.  Just my opinion - I bought this for it's reliability.  Having to reload after only two months is not a good sign.  Please don't take this as negative criticism - it's a suggestion for improvement, if anything.

      Also - it's curious that the /etc directory gets hit frequently enough that I found a 3 page discussion of it in the forum with the same error message.  If anything, the groups file should be static and unchanging.  I know I was sleeping at the time and not even logged into the system.

      1 Reply Last reply Reply Quote 0
      • A
        almabes
        last edited by

        NanoBSD is more resilient, but at the cost of limited support of packages.
        There's a thread about installing on a ZFS partition instead of UFS, which I am going to look in to.

        1 Reply Last reply Reply Quote 0
        • C
          cmb
          last edited by

          The root issue causing that problem is worked around setting sync on /, which we'll be doing by default in 2.2.3 and newer. You can apply it manually if you'd like, by changing the rw part of /etc/fstab to rw,sync so it looks something like this:

          # Device                Mountpoint      FStype  Options         Dump    Pass#
          /dev/da0s1a             /               ufs     rw,sync              1       1
          
          

          I'm at upwards of 1000 power cycles on a SG with that set with no problems.

          1 Reply Last reply Reply Quote 0
          • A
            almabes
            last edited by

            Just for completeness, this works on other platforms as well, such as the VK-40TE (which I have a few)…correct?

            1 Reply Last reply Reply Quote 0
            • C
              cmb
              last edited by

              It works for everything running a full install. nanobsd versions already set sync and so aren't affected.

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

                Would you say that change is a reasonable retrofit for all non-nano installs 2.x and up or just 2.2.x?

                I'm all for improved resilience to power failures…..

                -jfp

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  Only for 2.2+. Earlier versions built on FreeBSD 8.3 are unaffected.

                  Steve

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

                    Thanks for that Steve.

                    I see the underlying cause is discussed in more depth: https://redmine.pfsense.org/issues/4523.

                    -jfp

                    1 Reply Last reply Reply Quote 0
                    • S
                      signal7
                      last edited by

                      After futzing with it for a bit, I found what I thought was a much easier way to recover.  The last time I did an upgrade, I checked the box for the unit to do a full backup.  Ok, so then how do you do a full restore if the web interface doesn't come up?  Well, it turns out in my case that if I recovered the groups file from a different system (or from the tgz file in root's home directory) and then disconnected the WAN interface, the GUI would work just fine (very odd, that behavior).

                      I recovered back to 2.2.1 and then re-upgraded.  The system rebooted and was once again unresponsive.  Hmmm.  It worked fine on 2.2.1 and in theory, the full restore should have overwritten any corrupt files.

                      I again disconnected the WAN interface and rebooted.  The system came up and was responsive on the local interface.  I plugged the WAN interface back in.  It works fine.

                      For some reason, if the WAN interface is connected during boot up the system is non functional.  I've looked over the boot messages and there are no warnings to speak of.

                      I may yet do a full reload as suggested, but thought the added data might be interesting to the community - especially if it might resolve some of these problems.

                      1 Reply Last reply Reply Quote 0
                      • A
                        almabes
                        last edited by

                        I had one crap out at a customer location about a month ago.  Ended up backing up the config.xml to my laptop, reloading the ADI engineering platform pfSense 2.2.2 and uploading the config.  I was done in half an hour.  No futzing.

                        Did the fstab modification last night, and rebooted.  All is good.

                        1 Reply Last reply Reply Quote 0
                        • S
                          signal7
                          last edited by

                          At this point I've reloaded it twice.  The first time around, I got through getting the config back on there and then added sync to the root fs in the fstab.  I rebooted and it went braindead - hung at 'booting from hard disk…'  I tried a power cycle and it did the same thing.

                          Ok - reload it again.  This time make the change to fstab, verify it reboots, then do the config.  Seems functional at the moment.  If I have to reload this again, it's going back to an older release as I'm not really feeling this release is ready.

                          I try various things and 'futz with it' as a means of learning.  Sometimes it really pays off - maybe not today, but the info will come in handy later at some point.  You've got to admit, restoring a backup should have done it and should have been much less painless than a complete reload.

                          1 Reply Last reply Reply Quote 0
                          • A
                            almabes
                            last edited by

                            @signal7:

                            I try various things and 'futz with it' as a means of learning.  Sometimes it really pays off - maybe not today, but the info will come in handy later at some point.  You've got to admit, restoring a backup should have done it and should have been much less painless than a complete reload.

                            Me, too. 
                            I was relating a similar tale of woe.  Same device.  Same problem.  I, however, DIDN'T have the luxury of futz time.  I had 25 people trying to sell motorcycles, that couldn't because the firewall was down.

                            I think, when the backup was restored in both our cases, it set the com port configuration back to com1.  If you can get to the webConfigurator you can add the tweaks to /boot/loader.conf and get the console back.

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.