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.
CONFIG_EXT4_ENCRYPTION=y
CONFIG_EXT4_FS_ENCRYPTION=y
CONFIG_FS_ENCRYPTION=y
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
# CONFIG_EXT4_ENCRYPTION is not set
# CONFIG_FS_ENCRYPTION is not set
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
@linuxdev
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
4.9.140
zcat /proc/config.gz | grep ENCRYPTION
# CONFIG_EXT4_ENCRYPTION is not set
# CONFIG_FS_ENCRYPTION is not set
Are you able enable CONFIG_EXT4_ENCRYPTION ?
hello indiandragon,
JetPack kernel release should be shown as below
nvidia@nvidia-desktop:~$ uname -r
4.9.140-tegra
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
make ARCH=arm64 O=$TEGRA_KERNEL_OUT
@JerryChang
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
4.9.140
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.
@linuxdev
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:
CONFIG_LOCALVERSION=""
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:
CONFIG_LOCALVERSION="-test"