Flash Wrap without removing CF card?

sullrich

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.

billm

It's easy…

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

When you get to step 7, let me know.

--Bill

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.

sullrich

@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!

billm

@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

sullrich

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.

think0r

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.

Numbski

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?

sullrich

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.

Numbski

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