I have downloaded nv-jetson-nano-sd-card-image-r32.3.1.zip sd-blob-b01.img multiple times. I’ve done the unzip, and I’ve done the dd to the SD card multiple times as well. Ah, FWIW, I’m preparing the SD card on CentOS. When I first got the machine I downloaded an earlier image (.zip) and burned it, all went well. I decided to get the latest and greatest, and now I’m wedged. I’ve tried making the SD card on two different CentOS machines.
The closest I get is during boot I will get the Nvidia flash screen and then the thing goes dark. AFAICT nothing more happens.
I did an fdisk on the SD card, it shows 14 partitions. Initially fdisk complained that it needed me to do a write to finish making a duplicate. I’ve tried the boot with and without doing that write. Same results. Is there a known issue?
Well if the card is truly filling then that’s your issue.
If the input file is only 5.1GB then you’re using a different .img than I.
Mine is
-rw-r--r-- 1 root root 12884901888 Dec 16 13:28 sd-blob-b01.img
ls -lh
-rw-r--r-- 1 root root 12G Dec 16 13:28 sd-blob-b01.img
Mine does not end gracefully, I admit. It copies all of the .img but then hangs there, as though it couldn’t finalize. I pull the card out, and then dd replies that it copied all the bytes. As I said, I run fdisk and that complains that the duplicate partition table hasn’t been written, and I need to do a write. And, like I said, I do the write. Does not help.
gparted says that it recognizes only the ext4 partition; the other 13 are unknown. And they’re tiny, maybe a 1/2 MB or so. What’s that about?
The SD card is mounted automatically when I insert it in any of my other machines; /dev/sda1 shows up just fine. I haven’t looked inside it, but I’m guessing it’s fine.
Anybody know whether there is a way to get an old SD card image?
You might try flashing with gnome-disks or etcher. One of those is usally what I use. Etcher is probably the better option since it does a verification pass to ensure the image was written sucessfully. If that fails, you’ll proabably want to try another reader and/or card. I tend to feel dd is asking to overwrite something important accidentally.
Re: partition count, it’s normal for there to be many partitions due to the way Tegra systems boot. Android is similarly configured. There are good reasons to isolate things like that. It’s also normal that the partitions aren’t expanded to fit the whole disk after the initial flash. On first boot you’re presented with an option to resize / to as big as you choose, defaulting to the maximum available size. Lastly, if you try to edit the partition table before first boot there is a good chance you’ll break things.
At this point I am convinced that there’s a problem with the nano.
I’ve made SD cards on 3 different machines, CentOS 7 and 8, using dd
with multiple bs values, the 32.2.1, 32.2, 32.1 images, and the image I used
from the first time the machine worked, the behavior is always the same.
Is there a hardware forum around here? Are there any diagnostics I can
do to prove it’s bad hardware? I don’t want to replace the hardware and
find out the new hardware behaves the same way. (I admit I could be wrong
about it being hardware, I just don’t think I am. I’d like to prove it’s
the hardware, or not.)
gnome-disks seems to be a way to monkey around with partitions. I don’t
need to monkey with the partitions. I need to make an SD card that works.
No, my input image is also 12884901888 bytes, it just stops the copy at the 5.1 GB point, since it believes the disk is full. I’ve tried with 2 SD cards, on two computers, with dd and start-up disk creater - same result.
Anybody know whether there is a way to get an old SD card image?
I found an older image (r32.2.1) but I cannot relocate the site atm. I’ve tried it as well, but with no success. I can share the image if you want.
The hamburger / menu in the top right has an option to backup and restore disk images. You can modify partitons, but the utility is closer to Apple’s general purpose disk utility program.
Anyway, please give Etcher a shot since it will do a verification pass, which neither gnome-disks or dd do. If it fails the verification pass, then you know it’s a reader or card problem. I’ve run into issues with both, so verification that all of the data was written is certainly a good thing.
it WAS a switch between the nano and the power supply. (sheesh!)
this switch had the wacky property that when the nano was powered up, with anything reasonably close to 5V, the current would grow up to about .4A and then crash. this made it look like a power supply problem and an SD card problem. for a time, the switch worked slightly better and the nano would run, but with the machine throttled. the reason for the throttling seemed to be temperature, but it was not. it was an (ahem!) power supply problem – but the problem was really the power switch. with the power switch banished to the infernal regions both the original and replacement nanos are behaving as they should.