Problems after boot when building Kernel from Source

Compiling source on a 64-bit Ubuntu 14.04 box.
I am building the Kernel using the Linaro 5.1 tool chain.

So I am following the documentation and I get it to compile successfully, and flash successfully, but when it boots it loads the Ubuntu UI and I can use Firefox to browse the internet but essentially no other programs. No terminal or anything when I search for programs (which I get when flashing the provided kernel). And if the screen locks the default password does not work, and I get locked out.

I copy over the zImage, Image and dtb files. I also built and installed the modules when building and tar’d that up as well. One thing I noticed is that when it builds and installs the modules from source it adds ‘-dirty’ to the end of the kernel folder name. I tried adding the ‘-dirty’ to the directories in kernel_headers.tbz2 tar file, but that did not seem to work when I flashed that so not sure that is neeeded, or if I need to remove the ‘-dirty’ when installing the modules.

I am calling “sudo ./” after changing any files in the Linux_for_tegra_tx1 directory.

Anyone seen something similar when building from source?

To be clear I mean the Dash is empty. I can get a terminal using ctr+alt+T but then I can not change the do anything useful from there as whenever I try and sudo I get the error “sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set”, which indicates my install went wrong, but I am not sure where it went wrong.

The first thing I would suspect is the config used for the kernel build. Closely related to this is where the kernel will look for modules…CONFIG_LOCALVERSION. If non-module features were changed, you probably want a completely new CONFIG_LOCALVERSION, and thus the need to build a completely new module directory. If you didn’t match CONFIG_LOCALVERSION, then likely your kernel is looking for modules in the wrong place and can’t load any of them. FYI, the CONFIG_LOCALVERSION which ships with TX1 is from the suffix of “uname -r”: “-3.10.67-g3a5c467”.

As a side note, the Linaro tool chain is very actively being developed with all kinds of 64-bit ARMv8a support, so it might be worthwhile to try the latest precompiled binary version (it’s hard to keep up with how fast the releases are show up). I’m testing:


So that variable is not being set in the tegra21_defconfig is that where I should add it? Not at the board to play around at the moment. Also the version from the latest driver package is “3.10.67-gcdddc52” and compiling it from source adds ‘-dirty’ for some reason.

Yeah the plan was to get it working with 5.1 first instead of trying to keep up with the latest 5.2.


That variable is always custom. If you look in /proc/config.gz or defconfig it’ll be empty. Regardless of whether you make a defconfig, oldconfig, or menuconfig, you’ll get a .config file. This is where it must go, you wouldn’t want it in the defconfig. Using the /proc/config.gz as the start means no matter how customized the system is it’ll be a known starting point.

Before you do anything, you may wish to “make mrproper” (you can use the options like output source tree “-O” and ARCH with make mrproper or make menuconfig), and only then put the config file in…see if that removes the “-dirty”.

I just enabled swap when I compiled mine but here is how I did it. Follow the instructions in the pdf except for these tweaks. After I export the variables and make the $TEGRA_KERNEL_OUT directory I go into the kernel-source directory and do a make O=$TEGRA_KERNEL_OUT tegra21_defconfig. Once that is done switch over to the $TEGRA_KERNEL_OUT dir. Enter make zImage and let it run for a minute or so. You can let it run to completion but its not necessary. Then do a make menuconfig set up your kernel and continue like the pdf says. It makes a link in your kernel-out dir so you don’t need to be in kernel-src and have to enter the O= stuff every time I also make a MODULES directory in the kernel-out and install the modules into there so they are all together. On my set up that is the only way it will work from a fresh install of the kernel source. I’ve gotten it to work in a chrooted environment but it really doesn’t buy you anything since you have to cross compile there as well. Seems to me you should be able to set up a armhf compiler on the TX1 and do the cross compile on that machine. Just changing the swap config which doesn’t build any modules I simply copied over Image and zImage and rebooted. Once you get through it once its easy. I went to all the trouble of building the toolchains but now I’m on the linaro compilers as well. Haven’t had any weirdness from those.


Has one tested kernel built from source using “make O=$TEGRA_KERNEL_OUT tegra21_defconfig” on TX1?

I built kernel using “tegra21_defconfig”, but it did not work on my Shield TV. I have kernel working with different configuration file from…_nvidia_foster
That configuration file for has more than 4000 lines, but “tegra21_defconfig” has only 558 lines.

CM-Shield configuration file start with:


and other 40 lines before “#CONFIG_SWAP is not set”

But “tegra21_defconfig” is missing “CONFIG_ARM64=y” and other “General setup” lines before “#CONFIG_SWAP is not set”.

I’m wondering if “tegra21_defconfig” is complete to build kernel for TX1.

So I have done a ‘make mrproper’ etc… in the $TEGRA_KERNEL_OUT dir, and I consistently do a ffull sweep with make mrproper, make clean etc… between builds.

I explicitly set the CONFIG_LOCALVERSION and disabled CONFIG_LOCALVERSION_AUTO. Which did not change anything, and exhibited the same behavior. Diving into dmesg, it appears to indicate memory is bad on the on-board flash memory. I need to build a UART cable so I can just try flashing a new kernel without flashing the whole rootfs.

I will try Linaro 5.2 today to see if that changes anything, and after that use the kernel_config file I grabbed from the successfully flashed kernel provide by nvidia, grabbed from /proc/config.gz

griz11@ you are saying that you ran into issues with the kernel building with swap disabled? Hmm may need to look into that.

If there is a CRC error this may actually be the WiFi firmware issue. See:

If the TX1 appears to not work “out of the box without a flash”, it is perhaps just the TX1 trying to drive the monitor at a rate it is not capable of…which means the system is actually working fine (serial console would tell, or what I did was look at my DHCP server log and find out what address the TX1 is at so I could ping it and ssh in).

Perhaps more information on what your goals are would help…did a flashed system work with default kernel? Is the kernel build being attempted as a debug step, or is it to add a feature?

Yes the system works fine with the default kernel when flashed. But I checked the wifi script and I do indeed have bad wifi firmware. So will be getting it RMA’d. As they mention to just disable it to continue working until an RMA comes in.

So while there is a bad wifi firmware, that still doesnt point to why programs do no show on the Dash, as that would likely happen with the default kernel as well.

End goal is to try and get android running on it, which before I even go down that path I need to ensure I have a working reference kernel from source.

Didn’t get a chance to play around much over the holidays. With UART cable I was able to use u-boot to select different kernels at the start, and verify what was loading etc… I was able to manually scp over my newly built kernel and modules, and have them bring up Ubuntu fine. I can also delete the original kernel and modules(to verify nothing was pointing to originals etc…) and my new build still works fine. So Still not sure why DASH has no programs in it when I use ./apply_binaries and ./flash and I get crashes running dmesg, but at least I have a workaround for now that verifies I built it correctly.