Looks like the newer attachments are not coming through yet. Meanwhile, it looks like the original log basically starts failure messages at a time when the login manager and dbus session is starting (multi-user.target for text mode likely does not have a problem, it is at the very start of the login software for GUI that the problem starts at…Ubuntu seems to do WiFi setup here as well, so this might explain why the RF Kill message shows up while firmware is validated as correct).
Although I’m going to end up suggesting it is easiest to just test by reflash using non-JetPack for purely driver plus sample rootfs, here is something to test for further debugging if you want to look closer at what is going on (and in case the issue remains even after a careful command-line-only flash). You may want to skip to just flashing as mentioned at the end of this if you do not want to explore more about the issue.
Since you have a serial console you will be able to select from multiple boot entries at startup. Even so, file edits under serial console can be difficult due to line wrap being more primitive under serial console…are you able to use ssh to log in and edit files, or does the crash prevent this? What I’d like to do is add this to the end of the “APPEND” key/value pair of “/boot/extlinux/extlinux.conf” (and this is one very long line which must remain a single very long line):
Or, as an alternative to editing the original boot entry, you could create a second boot entry in extlinux.conf which differs only from the original by labels and addition of that same APPEND edit, then boot to the alternate entry. What that does is tell the system to boot to purely text mode and never load anything related to GUI. If booting to text mode without ever touching GUI results in no error, then the source of the error has been narrowed down on. You can enter or leave GUI mode by telling systemd to switch to “multi-user.target” (text mode) or “graphical.target” (GUI). Kernel command line “systemd.unit=” is one way to do this, but a slight modification lets you do the same thing in an interactive shell (which doesn’t do much good if you can’t get to a shell…thus the reason for extlinux.conf edits):
sudo systemctl isolate graphical.target
sudo systemctl isolate multi-user.target
If you are interested in doing a minimal flash to get as close as possible to validating hardware without use of JetPack, here are the instructions…
Download the driver package and sample rootfs. R24.2 is here:
Make sure you have about 25GB of spare space after download completes (it may actually be a bit less space required, but a bit of safety for temporary files is good). Make sure the partition is ext4 (“df -H -T .” while in the relevant directory will confirm).
Unpack the driver package without sudo. cd into the Linux_for_Tegra subdirectory, then into rootfs. Unpack sample rootfs here using sudo. cd back one directory to Linux_for_Tegra, and run “sudo ./apply_binaries.sh”. This is now set up for flash once the Jetson is in recovery mode.
Attach the micro-B USB cable, put the Jetson in recovery mode. Verify the host sees this via “lsusb -d 0955:7721” (it should show something).
Start the flash:
sudo ./flash.sh -S 14580MiB jetson-tk1 mmcblk0p1
This will take some time. At some point “bootloader/system.img.raw” will appear, and its exact byte size should be 1458010241024 bytes, or 15288238080 bytes.
The Jetson should be rebooted when done, and network address should be from DHCP query…ping should work. Serial console should work. Hopefully the GUI stage startup will not be an issue. If the issue remains (an actual crash versus simple video setup problems), then it might be time to RMA, but it would be unusual for this kind of problem to be hardware related when text mode works correctly (which is why a careful reflash is an important test should multi-user.target work correctly…even if multi-user.target fails you’d want to do this reflash before RMA as a final test).