hi, all
I hope tx2 to support sctp. Then I downloaded source from website, built kernel and reboot. when booting, there are errors flashing on the black screen. I can not enter Ubuntu 18.04 on TX2 now.
Is there anybody knowing how to solve it?
Any help will be appreciated.
hi, JetPack 4.4 is used on TX2. I hope TX2 to support SCTP. Then I have to build kernel for SCTP.
When I reboot , I got the errors flashing on the black screen. Now I stop here and can not enter the Ubuntu 18.04. Could anyone help with this??
What I did is as follows. Is it correct??
1\ downloads source code from website, public_sources.tzb2.
2\ unzip the source:
tar -xvf public_sources.tzb2 split the first directory
tar -xvf kernel_sources.tzb2
3\ copy the original .config to /usr/src/kernel/kernel-4.9/ and edit it ( set all parameters related to SCTP yes, there are three that are set)
4\ make and install
sudo make -j5 Image
sudo make modules
sudo make modules_install
5\ backup the /boot/Image to Image-original
copy the new Image to /boot
6\ reboot
Can I enter the old version without flashing TX2. Because I have lots of projects on it. I am afraid them to disappear if flashing TX2 with a new Ubuntu 18.04. Could anybody help with this?
When I plug the keyboard and mouse in USB port. The boot error is:
- Please share the full dmesg.
- Please share the result of “lsmod”
Can I enter the old version without flashing TX2. Because I have lots of projects on it. I am afraid them to disappear if flashing TX2 with a new Ubuntu 18.04. Could anybody help with this?
I guess your board is still working fine but just no desktop. Connect the serial console log may help prove it.
I tried to use ctrl+alt+f1~f6 when booting. There is two screen flashing in turn. Anyway it means the keyboard is ok. I can not enter anything because of the flashing. Here is the output :TX2 build kernel - Google Drive
Could anybody help? Thank you so much
Questions:
- Did you set CONFIG_LOCALVERSION to “
-tegra”? - Did you set the SCTP support via an editor, e.g., “
make menuconfig”, or did you set this via editing (editors understand dependencies)?
The questions from @WayneWWW will be needed to know what went wrong and how you can about repair, whereas my questions are mostly to determine why the kernel failed i the first place (I am assuming you will still want this functionality after repairs, but will want to know how to do so without running into this issue again).
Your question is exactly confusing me too . I have no idea about the failed building kernel.
I copied .config file to the build directory (usr/src/kernel/kernel-4.9) and gedit it. Then I set parameters about SCTP are m.( There are three parameters related to SCTP are not set in the original .config file. I set CONFIG_NETFILTER_XT_MATCH_SCTP=m, CONFIG_IP_VS_PROTO_SCTP=m, CONFIG_IP_SCTP=m)
Then I did make and install. I used commands “sudo make -j5 Image, sudo make modules, sudo make modules_install”. The way means that I did not set CONFIG_LOCALVERSION to “-tegra”, does it?
Thank you for your help!
You built and installed a new kernel, that kernel failed boot.
Not all features can be built integrated (“=y”), and not all features can be built as a module (“=m”). Some features require enabling other features when enabled (config editors know to complete other requirements if you enable such a feature…gedit does not do this).
The modules_install you mention is correct. However, if a module was provided by a third party, and not directly from that kernel build, then the new location would be missing that module. This isn’t likely, but it has to be considered if you change CONFIG_LOCALVERSION. A boot message about one or more missing modules would be related to this (I did not see any such message for your case, but other people do find this issue at times).
The command “uname -r” has CONFIG_LOCALVERSION as its suffix. On an NVIDIA kernel you would typically see “4.9.140-tegra”. Modules are searched for at:
/lib/modules/$(uname -r)/kernel/"
…and after a modules_install you might consider checking which modules are present in the old and new uname -r, looking at what may have disappeared in the new uname -r.
What I am getting at is that you might get a valid configuration for your kernel the way you did it. Probably you did. But what if you did procedurally correct, but some dependency was missed through use of gedit instead of a config editor? Or what if there was some third party module in the old uname -r, but this is now missing in the new uname -r path? I’m looking for combinations of corner cases.