Is there a power-safe way to upgrade the Linux kernel?

[tobyjaffey]

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.
(Also, it seems that the u-boot port does not support USB mass storage, so would have to modify the SD card, which is potentially dangerous?).

Thanks.

Crossposted from http://raspberrypi.stackexchange.com/qu ... nux-kernel

[davidcoton]

Why do you want to upgrade the kernel on a remote Pi?

If it ain't bust, don't fix it.

[tobyjaffey]

I want to deploy Raspberry Pis into remote locations where to get physical access will be difficult and expensive.

The Pis will be securely connected to a network. I need to know that if a critical kernel patch is needed that it can be applied safely.

I know this can be done, at risk, by modifying the kernel.img or config.txt to overwrite or switch kernels. But, this leaves a potential window of danger against power failure or SD card corruption. I want to remove these risks.

[DougieLawson]

You can define the kernel name in /boot/config.txt it doesn't have to be called kernel.img

Code: Select all

#
kernel=3.12.33+.kernel.img
#kernel=3.18.0+.kernel.img
#kernel=3.18.0A.kernel.img
#device_tree=bcm2708-rpi-b-plus.dtb
#device_tree_overlay=dt-blob.i2c

is what I've got on my A+ where I've been testing the 3.18 kernel with the device tree.

[tobyjaffey]

[quote="DougieLawson"]You can define the kernel name in /boot/config.txt it doesn't have to be called kernel.img

Code: Select all

#

Thanks. That's a piece of the puzzle.
It will allow writing a second kernel under a new filename, then doing a switchover a bit quicker.

But, writing the new kernel will need the SD card FAT partition to be mounted R/W as will changing config.txt.
Potentially, SD card corruption could happen during either write.

Once the new kernel name is in config.txt, if it fails to boot, the system will also be dead.

[pluggy]

If I were running a system that needed upgrade reliability and remote were more difficult than across (a small) town, I wouldn't use a Pi as a starting point.

Great fun, but no basis for difficult, dangerous or mission critical work.

Just my opinion.

[Richard-TX]

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


Crossposted from http://raspberrypi.stackexchange.com/qu ... nux-kernel

In a word, no.

Where I work, we have computer spread all across the globe. When an upgrade goes wrong we have to send someone to the physical location to fix it. It isn't just power loss that can occur that will cause an upgrade to fail. Hardware issues can also cause a upgrade to fail. In short, It is just part of the cost of doing business.

Having said that, there are some systems that are so far out of date that it is almost an embarrassment. Yet they have no issues, no outages, no failures and they haven't been rebooted in over 3 years. They just keep on running and doing exactly what we need for them to do. The OS and the application hasn't been "supported" by the vendors (if the vendor even exists anymore) in over 7 years. We have never needed "support". Everything just runs and runs reliably.

The point in all this is "why fix what isn't broken?" If it is running and running well, why upgrade? You run a much higher risk of breaking things with a new release. The only exception is security patches. If one looks at the patch closely, most of the time those can be applied without even needing to reboot the system.

[septantrionalis]

I like the "why fix what isn't broken?" mantra. I wish I would have followed this over the weekend. I ended up attempting to upgrade the kernel of my remote Raspberry Pi Friday night thinking it would be safe (I've never had problems before). I rebooted the system only to find that I couldn't connect anymore. I ended up having to bring the Pi back home and re-imaged the whole thing. blah. That was a good day wasted and there was no real reason for me to upgrade the kernel.