0

Since the filesystem and kernel are separate components for an embedded system, I am wondering if the filesystem can be replaced without modifying the kernel image? Of course, I would like nothing more than to also upgrade the kernel, but unfortunately do not have the kernel source and it would be much simpler if I could just flash the device with a new filesystem. I have a 14.04 filesystem that I can flash the device with and boot but a few files need to be modified for our use case and every time I try to change something in the filesystem, I get a kernel panic. I suspect this could be a problem introduced with the un-tarring and tarring of the filesystem (permissions or ownership are getting changed) and I have tried doing this as root and also with the preserve permissions flag (-p) as suggested on several other posts. I am wondering if what I am trying to do is even a feasible path to continue? Is the 3.10.3 kernel compatible with the 14.04.5_LTS OS?

2 Answers 2

1

The filesystem will contain libraries and configs required to make a device work. In an embedded system this is often very tightly bound because of limited resources and performance requirements. This means they typically have limited tools and expect very specific device and storage layouts with no autodetection.

Sometimes the embedded system will contain non-free drivers and code that are only built for a specific kernels as they are distributed binary only or otherwise restrictively licenced.

Part of my work involves testing embedded linux devices and i've not found one yet that would handle switching kernels without access to the development environment that made it and some serious head scratching.

This is of course a major problem for security and a lot of manufacturers duck their responsibility to keep updating, for that reason try to find devices with open development toolchains and you will find this is done for you.

2
  • Yeah, this whole change came about due to security concerns with the device. I realized from the beginning that trying to produce an updated kernel without the source was going to be a huge undertaking with many obstacles, if even possible. With that being said, do you think it's possible to just update the OS/ filesystem and leave the kernel alone?
    – Kristina
    Jan 18, 2017 at 18:12
  • beware of hidden checksums , lots of embedded systems store filesystem checksums in unsual places , if you change the fs you will need to ensure all of these are updated. You also risk bricking the device if you edit the filesystem such that it can't load the kernel.
    – Amias
    Jan 19, 2017 at 9:24
0

This is not the recommended way to handle upgrading the OS, but we are sometimes bound by certain restrictions that require us to do so. Upgrading the file system without upgrading the kernel does work in this instance. Later Ubuntu releases may not always be compatible with older versions of the kernel, however. To verify compatibility of kernel and OS versions, check out the Ubuntu Support Schedule.

Since I do not have the original file system used and our hardware is custom, creating a file system from scratch was surely not the path of least resistance. Instead, I performed an apt-get update upgrade of the device in-place and made the custom file changes there as well (a few security related patches). This method preserved all of the custom drivers specific to our board and components.

The functional file system was then tarred and used on the flashing server. As @Amias mentioned, there are some device specific configurations that can get you into a mess when doing things this way, so you will have to be cognizant of this. In my case, there was a network related file generated after the upgrade, which stored some hardware specific addresses for the network interfaces. This file was /etc/udev/rules.d/70-persistent-net . The result of flashing a device with this file present in the file system was that the network interfaces would not come up due to a "device not found" error. The hardware addresses were incorrect in the config file. I was able to remove this file completely and resolve that issue.

I also found that preserving permissions and ownership of the original files throughout the whole tar and file transfer process was crucial. Be sure to run the tar command as sudo to preserve ownership and use the -p flag to preserve permissions. Furthermore, if you are manipulating the file system on a host computer, the host must also have the same users as the target machine in order to preserve ownership of the files.

The solution is a little hacky, but it does work.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .