I finally went out and bought an external micro SD card reader, and the result is the same. The files are all present, but nothing shows up on the screen when I try to boot the Raspberry Pi. The screen remains blue, with a message stating that there's no HDMI signal. Also, the expected wireless network never shows up on the list of available networks, on any device.
So, I have a brand new, popular-brand, quality, micro SD card, along with a new micro SD card reader. Using this new hardware hasn't resulted in a working micro SD card.
I, also, followed swampdog's suggestion of attempting to build the micro SD card contents, from the .img file, using a series of command line tools, that he provided. That has, also, resulted in a non-working micro SD card (one that doesn't seem to boot).
In addition to this, I've used RonR's extraordinarily helpful "image-check" program. Based on the results, there appears to be nothing wrong with this image file.
All of this continues to cause me to have lots of questions about the "dd" command. It's a command that's very simple to use, and, based on all that I know, it's very powerful and thorough. It makes an exact copy of a drive, or micro SD card, by writing data, bit-by-bit, between mediums, and placing that data in the same locations as the original drive (or, in this case, micro SD card). Again, this seems to be as thorough as you can get. All partition data, and partition structure, is duplicated, as well as files, directories, etc. It's a program that performs exact replication. Could any other archiving/duplication process be more thorough? This is what makes all of this so puzzling. If this process fails, what other process could ever work? Is it even possible to have a more thorough process?
It's because of this thorough, bit-by-bit, replication process, that I've chosen to use the "dd" command to archive all of my micro SD cards. However, the process is clearly failing, and I'm very interested in knowing why.
At this point, all I can think is to have an expert look at the .img file, along with the resulting, unbootable, micro SD card, and attempt to see what's going on. The files and partitions are in place, and the Raspberry Pi LEDs seem to indicate that it's booting. However, I'm certainly no expert. I don't have a thorough understanding of the entire Raspberry Pi booting process. For this reason, I think it may be time to have an expert analyze this file, duplicate a resulting, non-bootable, micro SD card, and figure out why nothing's showing up on the screen, and why it doesn't produce a Wi-fi network. I'm very curious to know where things are breaking down, and why this process isn't working.
Unless anyone is able to think of anything else that I've missed, I think this may be my next step.
I greatly appreciate the extraordinary input that everyone's provided. If anyone has more suggestions, I'd love to continue to hear them.
So, I have a brand new, popular-brand, quality, micro SD card, along with a new micro SD card reader. Using this new hardware hasn't resulted in a working micro SD card.
I, also, followed swampdog's suggestion of attempting to build the micro SD card contents, from the .img file, using a series of command line tools, that he provided. That has, also, resulted in a non-working micro SD card (one that doesn't seem to boot).
In addition to this, I've used RonR's extraordinarily helpful "image-check" program. Based on the results, there appears to be nothing wrong with this image file.
All of this continues to cause me to have lots of questions about the "dd" command. It's a command that's very simple to use, and, based on all that I know, it's very powerful and thorough. It makes an exact copy of a drive, or micro SD card, by writing data, bit-by-bit, between mediums, and placing that data in the same locations as the original drive (or, in this case, micro SD card). Again, this seems to be as thorough as you can get. All partition data, and partition structure, is duplicated, as well as files, directories, etc. It's a program that performs exact replication. Could any other archiving/duplication process be more thorough? This is what makes all of this so puzzling. If this process fails, what other process could ever work? Is it even possible to have a more thorough process?
It's because of this thorough, bit-by-bit, replication process, that I've chosen to use the "dd" command to archive all of my micro SD cards. However, the process is clearly failing, and I'm very interested in knowing why.
At this point, all I can think is to have an expert look at the .img file, along with the resulting, unbootable, micro SD card, and attempt to see what's going on. The files and partitions are in place, and the Raspberry Pi LEDs seem to indicate that it's booting. However, I'm certainly no expert. I don't have a thorough understanding of the entire Raspberry Pi booting process. For this reason, I think it may be time to have an expert analyze this file, duplicate a resulting, non-bootable, micro SD card, and figure out why nothing's showing up on the screen, and why it doesn't produce a Wi-fi network. I'm very curious to know where things are breaking down, and why this process isn't working.
Unless anyone is able to think of anything else that I've missed, I think this may be my next step.
I greatly appreciate the extraordinary input that everyone's provided. If anyone has more suggestions, I'd love to continue to hear them.
Statistics: Posted by evansste — Wed Jul 24, 2024 8:32 am
