CONFIG_EXT4_ENCRYPTION change in .config not persisting after building the kernel

Hi community/dev team,

I’m trying to enable encryption config in the kernel, by using menuconfig and rebuilding the kernel. But the specific change is not persisting and is overridden each time while the kernel is build. Other changes to config (like USB firmware, zswap) works.

This is what I am doing inside the downloaded kernel sources(32.2) directory,

copying the running .config,

zcat /proc/config.gz > .config

Editing it with make menuconfig to enable,

File systems -> Ext4 Encryption

After saving, I verify the modified .config file and see the following encryption related flags enabled.


Building the kernel,

make -j5
sudo make modules_install

copy the new kernel image,

sudo cp arch/arm64/boot/Image /boot

Reboot successfully and verify the running config

cat running.config | grep ENCRYPTION

I’m not sure why only the flags w.r.t Encryption are not persisting, is it disabled by any rule for a reason?

It sounds like the procedure to install the new kernel isn’t using the kernel you expect. An integrated feature can’t be removed without rebuilding the kernel. I’m not familiar with “running.config”, I’d suggest building with a new “CONFIG_LOCALVERSION” to get a new “uname -r”, and then verifying “uname -r” actually changed. If it did, then find if the feature exists via:

zcat /proc/config.gz | grep ENCRYPTION


I should have mentioned that running.config is just the current config from /proc/config.gz, I confirm that I’m running rebuilt modified kernel and there was no issue in replacing the kernel as I have done it several times and verified. I’m running root in USB, so related flags changed for that is working as expected.

Only CONFIG_EXT4_ENCRYPTION is not persisting, even though .config shows as changed before building it.

uname -r
zcat /proc/config.gz | grep ENCRYPTION


Are you able enable CONFIG_EXT4_ENCRYPTION ?

hello indiandragon,

JetPack kernel release should be shown as below

nvidia@nvidia-desktop:~$ uname -r

could you please have another try by adding below configurations to your building steps.
for example,

export LOCALVERSION=-tegra
make ARCH=arm64 O=$TEGRA_KERNEL_OUT tegra_defconfig


The uname -r I quoted is for the rebuilt kernel with config changed to show that I’m indeed running new modified kernel; that’s why it doesn’t show Tegra.

uname -r

I will try the flags you’ve mentioned. But can you confirm that there’s nothing in the code explicitly overriding ENCRYPTION config?

Can you verify the “.config” still has this set in the “O=$TEGRA_KERNEL_OUT” location after the build completes? If so, then it should stick. I would think anything causing this option to be invalid would also break kernel build. If it is in the “.config” you used, then it shouldn’t ever self-remove.


Just to clarify, the current modified kernel I’m running was built using the steps mentioned in my first comment as it is; i.e without any environmental variables for Tegra builds as mentioned by @JerryChang and you. It built without errors and was patched for USB boot with Zswap. Only issue is that EXT4 encryption config doesn’t stick.

But when I build using the environmental variables suggested you and jerry, it doesn’t compile and exits with an error in the ‘SUB Module’. No matter how many times I clean and start fresh. I think, the USB boot module or Zswap patch is doesn’t compile when using the Tegra environmental variables.

I will post the exact error when I build next time, kindly keep this post open as EXT4 Encryption issue is still not resolved.

Is it correct to assume the build was done natively on the Nano without cross compile? This is mandatory if no environment was set.

Can you verify your modules exist at:

/lib/modules/$(uname -r)/

(there should be an entire tree of modules within that)

Can you try changing, within your build’s “.config”, the “CONFIG_LOCALVERSION” (which is the suffix of “uname -r”) and seeing if booting to that kernel also changes the “uname -r”? As an example, “4.9.140” says you did not have a CONFIG_LOCALVERSION. This is what that kernel was compiled with:


If you were to change this to “-test”, like what follows, then “uname -r” would be “4.9.140-test”, and module install would go there: