2

How to load an image to the pie remotely while SD card is inside of the device? I don't think I can do this using dd command while connected via SSH / VNC. A new image should be probably loaded from the cloud. Is this possible to do in general?

radek19
  • 41
  • 6

2 Answers2

3

You would have to boot a minimal system that can run with the root fs entirely in memory -- which is possible.

Are there any good Raspberry Pi distributions that load completely into RAM?

In addition to the suggestions there, apparently Tiny Core can run in RAM on the Pi:

http://www.tinycorelinux.net/

The trick with this is you will have to write to the SD card while streaming the image from the net, since it is unlikely you will have enough memory to download it entirely first.

If you need to have a normal system on the SD card, you have a few choices, some of which require a spontaneous reboot:

  • Include a small third partition with the RAM based OS in it, edit /boot/cmdline.txt to use that as the root fs, reboot. The gotcha with this is you may have to keep /lib/modules in sync with /boot/kernel.img -- unless you swap a different kernel in first. OTOH, standard Pi kernels can run with no modules since they are custom built for the hardware; this limits functionality but it may be enough for what you want to do.

  • Create a kernel that uses an initramfs which does what you want. Normal non-pi kernels do this in order to select modules from it in order to mount the root fs, since they are intended to run on a range of hardware. I'm not sure what limitations there are, but I don't see why this couldn't be done. This requires more technical expertise than the first option.

  • If you really don't want to reboot first (which seems silly, since you are going to have to reboot after you install the image anyway), you could use a chroot based system in RAM. This is probably the slickest option, reboot or no, but again it requires some technical expertise.

That said...

the problem is that I need to load my own Raspbian image (circa 7gb) with lots of existing customizations in it. I have tens of pies in production and goal is to make them compliant to a company standards. Everytime I find a new bug fix I need to clone the image and send it out to all other pies.

This to me is an XY problem where your Y is not a very good idea. I think you should contemplate a more normative method of automating updates. Re-writing the whole OS is very clumsy and very fragile; since you cannot download the new image and must write it to the card streaming from an online source, if anything goes wrong with the network in that interval or your RAM based OS, you are totally screwed.

goldilocks
  • 58,859
  • 17
  • 112
  • 227
  • Thanks, but the problem is that I need to load my own Raspbian image (circa 7gb) with lots of existing customizations in it. I have tens of pies in production and goal is to make them compliant to a company standards. Everytime I find a new bug fix I need to clone the image and send it out to all other pies. – radek19 Apr 06 '18 at 13:32
  • Added some stuff about this. – goldilocks Apr 06 '18 at 14:00
0

I stumbled across this question, and while I share goldilocks reservations; it is possible - albeit with some constraints.

Telephone networks face similar issues; it is generally considered unacceptable to shut an exchange down to upgrade software. Telecommunications solves this by a number of techniques - often dual processors in a hot/standby pair.

I have done something similar on the Pi; basically with one boot partition and duplicate root partitions. You boot to one root partition, and you can mount the spare, update software etc (although I would use rsync), then modify the cmdline.txt to boot to the alternate root partition and reboot.

The root partitions need to have unique PARTUUID, and both should run off the same kernel, although you could even use the technique used by raspberrypi-bootloader raspberrypi-kernel to upgrade kernel/firmware on a live system.

Obviously the SD Card needs to be larger to accommodate the 2 root partitions.

Milliways
  • 59,890
  • 31
  • 101
  • 209