The Xorg.0.log looks normal until near the end. Assuming you use a USB keyboard (or other keyboard), there should be one or more config/udev lines like:
(II) config/udev: Adding input device USB Keyboard (/dev/input/event3)
What kind of keyboard do you use? Is there a USB keyboard?
alternatives.log shows some differences with my system, although I don’t know if it is significant. I’ve done a lot of updates and perhaps have not installed things which you have. However, it’s worth noting this one line from my system which differs from your…it MIGHT matter:
run with --force --install /etc/ld.so.conf.d/arm-linux-gnueabihf_EGL.conf arm-linux-gnueabihf_egl_conf /usr/lib/arm-linux-gnueabihf/mesa-egl/ld.so.conf 500
Mine links with a mesa directory, yours links with a tegra-egl directory. It is possible for these libraries to be linked incorrectly and bring down graphics or perhaps even produce an OOPS. This could be an issue if your rootfs was modified to do this prior to flash, it could also occur by changes to support EGL after install. Since I don’t have ubuntu for my host (I use fedora) I can’t say what JetPack does or does not do correctly. Regardless, you could go to your L4T R21.4 directory and recreate the rootfs directory (along with apply_binaries.sh) as if using just the flash app and ignoring the JetPack GUI. I would be more specific, but I just don’t know how JetPack works on this and especially JetPack from a VM.
My auth.log differs from yours, but there are a lot of reasons why this may happen. In particular, I don’t see errors.
boot.log does not show any obvious errors. pm-powersave.log probably is not useful unless looking for a specific setting.
FYI, the serial cable is not used during flash. You could view it during flash and perhaps get some information if the failure is from a bad flash…but a bad flash usually leaves Jetson unbootable until reflashed (an impossible size for system.img would result in an error during flash). The part from flash which can consistently cause failure without a flash error is if the rootfs is incorrect. For example, only root authority (including sudo) can unpack and place device special files as needed; if a loopback device needs to be created, only root authority can do this as well. A file system unpacked as non-root cannot set permissions to root, and flash copies permissions as-is…modified rootfs implies modified Jetson from flash, and no error during flash.
Serial cable is often necessary to debug problems such as this, and it would make a huge difference in how easy or difficult it is to figure out the problem. Serial cable console does not depend on the video card and continues to function in many cases when the rest of the system is in a terrible and extreme state of failure. This would certainly be the best way to see what is going on. If you don’t have a convenient DB-9 serial port on your host, you could get a serial UART which is a USB cable with a DB-9 on one end. Here’s one that works well:
…this would use something /dev/ttyUSB1 for the serial port name. 115200 8N1 would be the setting.
The closest thing to a “smoking gun” on the problem is the EGL graphics linking differences, but again this might be because I have updated packages and installed different things. Without serial console, I’d suggest manually downloading and installing non-JetPack L4T R21.4 on your flash host and running the flash in a console, paying particular attention to making sure rootfs unpack and sudo apply_binaries.sh are correct.