2

Is there a method of self-upgrading the Linux kernel on a Raspberry Pi which is safe against power outages and filesystem corruption.

When running a Raspberry Pi remotely, it's important to be able to upgrade both the filesystem and kernel in a reliable way. Usually, this is achieved by having two partitions or copies of the kernel and a bootloader capable of switching back to a recovery image.

But, as I understand it, the Raspberry Pi bootloader is proprietary code running on the GPU which doesn't support this.

Toby Jaffey
  • 121
  • 3
  • 4
    I'm surprised you know of any system whose kernel may be upgraded and is safe against power outages, filesystem corruption and other gotchas. I've never heard of one. – joan Dec 11 '14 at 14:49
  • This is a common requirement in inacessible deployed systems https://archive.fosdem.org/2012/schedule/event/699/130_Presentation_Safe-Upgrade.pdf (PDF link) – Toby Jaffey Dec 11 '14 at 14:54
  • Berryboot should allow for this, albeit in a way that's not so conducive to your context. So it is not impossible... – goldilocks Dec 11 '14 at 16:35
  • Another solution would be the bootloader diff-patching the partition and writing from time to time the index, in case of reboot the bootloader can continue updating the partition. This removes the need of two partitions or a failsafe firmware. I suppose the raspberry-pi bootloader doesn't support it, but I know some folks managed to implement that with u-boot. – Julien Vermillard Dec 11 '14 at 17:24
  • My reaction was mainly to the open ended gotchas which can not by definition be foreseen or be allowed for. However remotely upgrading the kernel of a deployed system seems like a pretty massive gotcha in its own right. I'd rank it with attaching a secure system to the internet and then acting surprised when it's compromised. – joan Dec 11 '14 at 18:02

1 Answers1

1

Please have a look at my project Nard SDK
http://www.arbetsmyra.dyndns.org/nard/
which is quite robust against failed system upgrades. It is designed specifically for embedded projects and has precautionary measures to minimize failures in the event of a power cut in the middle of system upgrade.

Ronny Nilsson
  • 898
  • 5
  • 13