Upgrading ESOS in-place ?

[Bill Lambert]

I'm just about ready to deploy my first pair of ESOS servers for some real-world testing, and there is just one lingering concern: I'd want to upgrade it over the network, without physically removing the USB key.  Reasons being:

- I like working remotely at random hours
- mounting the USB key inside the chassis reduces the likelihood of removal by an absent-minded tech (i.e. me)
- scripted upgrades, which then opens up logging / tracking opportunities

So my thinking is:

1. mount /boot
2. replace bzImage-esos.* and initramfs.cpio.gz
3. mount /mnt/root
4. rsync the new root
5. reboot (cross fingers)
6. happy dance!

Did I miss anything ?

On a related note, I'm curious as to why there is a separate root partition, instead of one big fat initramfs for everything ?  The latter is how I like to build my appliances, I figure it's easier on the NAND to update two files, rather than to pound it with a thousand metadata updates.  I suppose a real root partition makes it easier to debug / make persistent changes ?

Cheers
-Bill

[Marc Smith]

On Sun, Nov 17, 2013 at 8:38 AM, Bill Lambert <vri...@gmail.com> wrote:

I'm just about ready to deploy my first pair of ESOS servers for some real-world testing, and there is just one lingering concern: I'd want to upgrade it over the network, without physically removing the USB key.  Reasons being:

- I like working remotely at random hours
- mounting the USB key inside the chassis reduces the likelihood of removal by an absent-minded tech (i.e. me)
- scripted upgrades, which then opens up logging / tracking opportunities

So my thinking is:

1. mount /boot
2. replace bzImage-esos.* and initramfs.cpio.gz
3. mount /mnt/root
4. rsync the new root
5. reboot (cross fingers)
6. happy dance!

I have not personally done this myself, but I believe Marcin has... I'll let him chime in, but I believe he does it like this:

1. Copy the new tar ball ESOS image package up to your live ESOS server into /tmp (assuming you have enough physical RAM to un-pack it) or to a real local storage (not USB flash drive) mounted file system (eg in /mnt/vdisks/blah).

2. Extract the tar ball.

3. Use dd to write the .img file to your USB flash drive block device node.

4. Run conf_sync.sh and reboot.

I'd be extra sure you have a good backup of your configuration files off the machine before doing this though. =)

This is something we'd like to add into the documentation as a supported method for upgrading ESOS in-place, so expect better documentation/support to come. Instead of doing it manually, we'd like to modify install.sh to support it (and it might already work, but its early, and I haven't looked yet, so if you're adventurous you can try install.sh above). Also doing the above method you would need to manually integrate the proprietary CLI tools if you're using any... in which using install.sh would facilitate that as well.

Did I miss anything ?

On a related note, I'm curious as to why there is a separate root partition, instead of one big fat initramfs for everything ?  The latter is how I like to build my appliances, I figure it's easier on the NAND to update two files, rather than to pound it with a thousand metadata updates.  I suppose a real root partition makes it easier to debug / make persistent changes ?

Honestly, its been so long now, I don't remember exactly why I chose this method... I did experiment in the early days with everything in initramfs, but ended up with the real root partition and copying everything over to a tmpfs file system on boot. Whatever the reason, I will say as you mentioned above, it has turned out to be a nice feature, especially for development... being able to modify things in /mnt/root and then reboot and having them stick is priceless for testing/developing, but I could also see it as a benefit for end-users that might want to customize their ESOS without the extra steps need to generate an initramfs image. They simply mount /mnt/root and make changes.

Let us know how it goes.

--Marc

Cheers
-Bill

--
You received this message because you are subscribed to the Google Groups "esos-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to esos-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Bill Lambert]

I will most certainly do an unhealthy amount of tinkering over the next few weeks/months, and report back with any useful findings.

One of the perks of a "fat" initramfs is being able to push the whole system out via PXE, which I find immensely useful in both the lab and production.  I've been doing that a lot lately, as it eliminates the need for boot media and lets me update or repurpose hosts very quickly.  Plus there's just something cool about a server on the opposite coast pulling a test build over HTTP.  I have a funny feeling I might repackage  ESOS as a single image in the near future ;)

[Marc Smith]

Sounds good, let us know.

--Marc

On Sun, Nov 17, 2013 at 12:33 PM, Bill Lambert <vri...@gmail.com> wrote:

I will most certainly do an unhealthy amount of tinkering over the next few weeks/months, and report back with any useful findings.

One of the perks of a "fat" initramfs is being able to push the whole system out via PXE, which I find immensely useful in both the lab and production.  I've been doing that a lot lately, as it eliminates the need for boot media and lets me update or repurpose hosts very quickly.  Plus there's just something cool about a server on the opposite coast pulling a test build over HTTP.  I have a funny feeling I might repackage  ESOS as a single image in the near future ;)