It is possible that if the linker is pointing to a directory on the SD card in which to link against, and if that SD card either (A) is missing that content, or (B) the SD card is not found, then this might cause user space content to block. Your linker path does indicate it is looking in “/usr/local/lib”, so possibly this is the case.
Do you have another SD card you could clone the first to, and then edit the clone so that experimenting is safer? If so, then there are a few things you could try which might be fairly simple. Also, do you have the exact fstab line?
I don’t have the exact line, but it was from this post
I just replaced the UUID with my SD card’s UUID. I have another card lying around. What do I need to do? Also just to be clear, the nano kit didn’t come with a card to begin with. The card was put in by us. We only recieved the kit with OS pre-installed in the 16 Gig internal EMMC with barely any space left.
Can I confirm it had the “nofail” option in it? If so, then the partition failing to mount would not cause boot to hang. This, in turn, adds to the possibility that it is searching for a library path or file which cannot be reached (which can be a side-effect of a failed mount; in this case “/usr/local/lib”).
It is possible that the UUID is wrong. There is an ID for both the partition, and for the SD card as a whole. At least that is my current theory on why mount failed.
This is an eMMC model, and so the o/s is not on the SD card, but the fstab is. With the SD card mounted on the host PC, what do you see for “lsblk -f” (I’m only interested in the SD card part, but the command will list for your whole PC)? Was the earlier screenshot of lsblk -f from the PC and that specific SD card? Or was it from the SD card on the Nano when it did work (probably it was from the Nano, but I’m interested in knowing if any formatting or partitioning took place after that screenshot)?
This screenshot is from today, after I recovered from the boot fail. I did have the nofail flag. I even tried to do /dev/mmcblkp1 instead of the UUID earlier.
That time I had the same black screen issue but restarting without the SD card made the device boot. That didn’t work so I looked up the UUID thing which caused the device to fail booting entirely(with or without the SD card). I have even tried mounting it whilst on system. All I get is Ubuntu 18.04 has experienced an internal error
Now I may have made an error in the UUID part as you are suspecting. I was in a state of panic trying to fix the board, so I just deleted the line without looking. Regardless I still can’t mount the SD properly without getting errors.
If this is what I think the problem is (and perhaps it is not), then the problem is not actually the act of mounting the SD card. The problem is (probably) that something is needed on that SD card. Normally that is not a problem, but if the linker is pointed at certain “problem content” (in this case within “/usr/local/lib”, then it is possible to hang boot before it can get to a login.
Assuming this is correct, then you have to basic workarounds:
Edit the fstab to not mount the external device, while making sure the lib content is valid. Not easy since the fstab in question is on the eMMC, and you can’t get to it to edit it without flashing.
Edit the content on the SD card to put the valid content in place. This is in theory “possibly” easy, but we don’t know exactly what is missing. A current serial console log would go a long way towards that knowledge. Can you get a serial console log?
Towards this latter method of repair, if you have the old content of the “/usr/local/lib”, then you could perhaps add that content from your host PC. If you still have the flash content from your most recent flash of the Jetson (it is an eMMC model, so I’m assuming you have something from the third party vendor), then quite possibly you have a raw flash image. The raw flash image can easily be loopback mounted on a host PC, and then copied to the SD card. This would guarantee that at least that content is valid (it might still be something related to fstab edits, but we’d know the SD card content to “/usr/local/lib” is valid).