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

    Flash Wrap without removing CF card?

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    26 Posts 10 Posters 11.9k 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.
    • E
      Eaterofpies
      last edited by

      Heh i found that out the hard way . . .

      I nearly got it to boot monowall by remounting / as RW then copying the kernel and ram disk image out of the monowall image and reconfiguring the boot loader.

      Only problem was that i forgot the config xml so it just shut down when it booted.

      The plan was to then reinstall monowall over the top so it wasnt such a mess :D.

      You could then reflash it using the latest version as described in my previous post

      This could probably be made to work but its a lot more hassle than just pulling the CF card out.

      1 Reply Last reply Reply Quote 0
      • N
        Numbski
        last edited by

        I'm just brainstorming here, so feel free to smack me down if you must….

        Mount an external nfs share so we have access to the image we want to flash (I know, network flash bad bad bad)....

        Become root, force root filesystem into rw.  Begin dd.

        The system will return, then hang, right?  Upon reboot you should have a fresh pfSense install sans your config, however if you backed up your config.xml ahead of time, then you just need to set the lan IP, go in, and reload the config.

        I have a couple of embedded systems back at the office I can try this on for grins.  As the guys have said - UNSUPPORTED. :P  If this works, I'm happy for you, but you still won't be able to do an unattended upgrade, you'll have to be present, it would only save you from having the rip the system open.

        That said, if it did work, what I could say is prior to flashing, mount the flash image as an md volume, and copy your config file over first, THEN flash.  Upon reboot it would be the closest to an inline upgrade one could hope for currently.

        1 Reply Last reply Reply Quote 0
        • N
          Numbski
          last edited by

          Sadly, I still have not had a chance to give this a try, but I did have a second thought on the matter.

          Most of my CF cards are either 128 or 512, yet the embedded image is only 64MB.  The thought comes to mind that one could partition the card.  ie, go ahead and flash as per normal, then run mkfs and create another partition that uses the remainder of the card's space.  Edit /etc/fstab so that it gets mounted as additional space.

          When you want to update, copy the file over to this new rw partition, and then follow the directions I have above.  When the dd command returns you should fully expect the system to hang.  Reboot and you should be all set.

          1 Reply Last reply Reply Quote 0
          • P
            pcatiprodotnet
            last edited by

            I mount my WRAP.2C Motherboards upside down (outdoor case).  Since I use only one mini-pci wireless, I have both CF and mini-pci slot on same side facing up.  All too easy… other than making the custom tight-fit/right-angle Serial cable.
            -pc

            1 Reply Last reply Reply Quote 0
            • E
              Eaterofpies
              last edited by

              what would really be ideal is something similar to monitor mode on cisco kit (well PIXs at any rate havent used the rest).

              Basically its a seperate really cut down OS with the sole purpose of recovering the device when something goes wrong / you need to reflash / you screw up..

              the cisco one includes a tftp client and some form of uploading firmware over serial i think (slow but good if you're stuck).
              I have had a quick play but couldnt get anything along these lines working.

              if that was working it would be relatively simple to load any image on we wanted. the only problem would be loading the images on without destroying the recovery mode and booting them.

              1 Reply Last reply Reply Quote 0
              • T
                think0r
                last edited by

                This is obviously an issue of great importance to anyone running on an embedded device.  Taking the unit apart for every firmware update is just not going to cut it for anyone that needs to manage a large number of these units.  I don't see any reason why we can't just create a separate kernel specifically for embedded updating that uses a ram disk and runs tftp or something and add it to the current embedded image or pfsense.  We could use a boot loader to to select "normal pfsense kernel" (default) or "updater kernel".  Make an option in the web gui to allow us to change the boot loader config for the next reboot.

                Does this seem do-able?  Are there currently any plans to add some sort of firmware upgrading functionality to the embedded images that allow for in box or remote firmware updating?

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

                  @think0r:

                  This is obviously an issue of great importance to anyone running on an embedded device.  Taking the unit apart for every firmware update is just not going to cut it for anyone that needs to manage a large number of these units.  I don't see any reason why we can't just create a separate kernel specifically for embedded updating that uses a ram disk and runs tftp or something and add it to the current embedded image or pfsense.  We could use a boot loader to to select "normal pfsense kernel" (default) or "updater kernel".  Make an option in the web gui to allow us to change the boot loader config for the next reboot.

                  You must be new around here.    This has been hashed to death …

                  @think0r:

                  Does this seem do-able?  Are there currently any plans to add some sort of firmware upgrading functionality to the embedded images that allow for in box or remote firmware updating?

                  Not at the present.

                  Maybe in the future.  The problem is stuffng the 32 megabyte image into ram to update.  Couple that lighty wants to hold this in ram and make a copy of it then you end up using 64 megs of ram just to get the update into ram.  Most people will be using more than 64 megs of ram on a running embedded image.

                  If you want to do the work you outlined above, please send patches.

                  1 Reply Last reply Reply Quote 0
                  • T
                    think0r
                    last edited by

                    The updater kernel would be an alternate boot method.  That is to say that pfsense would not be booted.  The updater imagine would be tiny with only the ability to upload the new image into ram disk and flash it back to the CF card and perhaps copy any configs into memory then back to CF after writing.  Why wouldn't this fit into the 128mb's of memory included on more WRAP boards?

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

                      @think0r:

                      The updater kernel would be an alternate boot method.  That is to say that pfsense would not be booted.  The updater imagine would be tiny with only the ability to upload the new image into ram disk and flash it back to the CF card and perhaps copy any configs into memory then back to CF after writing.  Why wouldn't this fit into the 128mb's of memory included on more WRAP boards?

                      It wouldnt fit on a RUNNING SYSTEM.  Going with your idea, how are you going to signal that an update kernel should be loaded?  I am not trying to poopoo your idea but its an unbelievable amount of work what you are proposing.  Not only will the builder scripts need to be updated to be able to boot two different systems a whole new set of boot management code would need to be added.

                      1 Reply Last reply Reply Quote 0
                      • B
                        billm
                        last edited by

                        It's easy…

                        1. download developers edition
                        2. boostrap developers edition
                        3. change build system to make it generate binary diffs
                        4. make changes so binary diffs work
                        5. create a diff with your well commented work
                        6. file a ticket in cvstrac with your diff attached
                        7. if it makes sense we commit

                        When you get to step 7, let me know.

                        --Bill

                        pfSense core developer
                        blog - http://www.ucsecurity.com/
                        twitter - billmarquette

                        1 Reply Last reply Reply Quote 0
                        • T
                          think0r
                          last edited by

                          @sullrich:

                          @think0r:

                          The updater kernel would be an alternate boot method.  That is to say that pfsense would not be booted.  The updater imagine would be tiny with only the ability to upload the new image into ram disk and flash it back to the CF card and perhaps copy any configs into memory then back to CF after writing.  Why wouldn't this fit into the 128mb's of memory included on more WRAP boards?

                          It wouldnt fit on a RUNNING SYSTEM.  Going with your idea, how are you going to signal that an update kernel should be loaded?  I am not trying to poopoo your idea but its an unbelievable amount of work what you are proposing.  Not only will the builder scripts need to be updated to be able to boot two different systems a whole new set of boot management code would need to be added.

                          Fine, I will just add my own bootloader and dual boot between pfsense and something else via the serial console.  If adding a capable bootloader configuration to pfsense requires a massive rewrite of pfsense to work then forget it.  It just seems short sighted to suggest we should all disassemble embedded devices for every update.

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

                            @think0r:

                            Fine, I will just add my own bootloader and dual boot between pfsense and something else via the serial console.  If adding a capable bootloader configuration to pfsense requires a massive rewrite of pfsense to work then forget it.  It just seems short sighted to suggest we should all disassemble embedded devices for every update.

                            pfSense's main focus IS NOT ON EMBEDDED!  If you want a product that focuses on embedded run m0n0wall!

                            1 Reply Last reply Reply Quote 0
                            • B
                              billm
                              last edited by

                              @think0r:

                              @sullrich:

                              @think0r:

                              The updater kernel would be an alternate boot method.  That is to say that pfsense would not be booted.  The updater imagine would be tiny with only the ability to upload the new image into ram disk and flash it back to the CF card and perhaps copy any configs into memory then back to CF after writing.  Why wouldn't this fit into the 128mb's of memory included on more WRAP boards?

                              It wouldnt fit on a RUNNING SYSTEM.  Going with your idea, how are you going to signal that an update kernel should be loaded?  I am not trying to poopoo your idea but its an unbelievable amount of work what you are proposing.  Not only will the builder scripts need to be updated to be able to boot two different systems a whole new set of boot management code would need to be added.

                              Fine, I will just add my own bootloader and dual boot between pfsense and something else via the serial console.  If adding a capable bootloader configuration to pfsense requires a massive rewrite of pfsense to work then forget it.  It just seems short sighted to suggest we should all disassemble embedded devices for every update.

                              What's more short-sighted is threatening to add your own bootloader.  We don't care about threats.  Do it, if it works and you wish to help others (or god forbid, contribute something back to the project), please do.  You think we have nothing better to do but spend hours supporting our slowest platform?  Yes, it's bloody annoying that I have to crack the case on my 4801, but I've got much better shit to work on than making embedded updates easier.  Open source software works because people that have a need solve that need…you have a need, solve it.

                              --Bill

                              pfSense core developer
                              blog - http://www.ucsecurity.com/
                              twitter - billmarquette

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

                                Furthermore, we wanted embeddeds to be updatable but we simply ran out of time in the 1.0 release cycle.

                                So whats more short-sighted, releasing a product that works but lacks updating without reflashing or saying screw the embeddeds since we didnt finish everything we wanted to?

                                As Bill said this is a open source project.  We try really hard to do as much as we can but this simply did not have enough time to flesh out.  I eagerly await your patches since you seem to be so much in the know on these things.

                                1 Reply Last reply Reply Quote 0
                                • T
                                  think0r
                                  last edited by

                                  Ok, got it.  I am solving my own problem.  I asked about this solution for feed back and perhaps some better ideas on the topic.  I also wanted to know if there was anything already in the works. I certainly did not mean to suggest that you should do all this work or that I was some how unable or unwilling to contribute a solution.  When I have something workable I will submit a patch or some documentation which ever the case maybe.  If you have anything "helpful" to add to any possible solution to this problem please do.

                                  1 Reply Last reply Reply Quote 0
                                  • N
                                    Numbski
                                    last edited by

                                    Just my 2 cents here.  Again.
                                    (OOPS!  I didn't see there were 2 pages to this discussion, nor the ensuing flames…I wasn't trying to target sullrich here, just trying to be hlpeful!  :( )

                                    Sullrich, if I recall, /boot/loader.conf (or is it another file in there?) that controls the beastie menu, you can arbitrarily add additional boot options there, right?

                                    So...here's what I'm thinking.  Add a seperate boot process.  This one makes a copy of barebone essentials for operation into a ramdisk.  chroot to that ramdisk so that we're not living on the flash card anymore.  Make a copy of config.xml while we're at it.

                                    Prompt for a tftp server (since that's the standard?), and as the tftp is coming across, but dd'ing it to the flash and not storing it in RAM.  Perhaps tftp isn't the right tool for this, perhaps netcat/dd?  You get what I'm saying though.  When the transfer is complete, mount the flash card, copy config.xml back to the new filesystem, reboot.

                                    Make sense?  It's about as clean as you could get, and I think a relatively simple sh script could cover all of the above.  Note that I totally suck at sh scripting.  perl I can do, but loading perl just to run the flash update is excessive IMHO. ;)  Anyone feel like volunteering to give the above a go?

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

                                      Either way we are too late in the release process for 1.0.  We cannot just rip apart the builder code at this point if we do not want to go back to beta status.

                                      1 Reply Last reply Reply Quote 0
                                      • N
                                        Numbski
                                        last edited by

                                        My apologies.  Edited my post above.  Didn't realize I was butting my head into a flame war.  Wasn't my intention.

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