OT? Formatting SD cards under Linux

Yes, I have a number of suggestions.

First, please post the _actual_ dd command; it may matter. Are you using partitions, and are you trying to write a whole card image to a partition or vice versa ? Some of my suggestions below assume you are using partitions; adjust as required if you are not. :-)

Second, are you flushing buffers before ejecting the card ? Issue a sync command using your favourite shell before ejecting the card if you are not sure.

Third, use the "p" command in the fdisk utility (if your Linux version has it; on my Redhat based systems it's in /sbin) to display the partition information on the card before writing to it. Do the same after writing to it and post the results.

Use the base device name, ie: /dev/sdc, and not a partition, ie: /dev/sdc1, with the fdisk command. I note your comments above about not been able to access the card after writing to it, but you don't say if the base device is no longer showing up or if it's showing up, but a partition isn't.

NOTE: be careful when using fdisk; it doesn't do any of the handholding that the GUI partition tools do so you need to know what you are doing and you can damage things easily if you start exploring. On the plus side, you can see exactly what is going on, without a GUI getting in the way, which is why it's my tool of choice.

Fourth, try mounting the image, in read-only mode, on a loopback device and make sure that you can access the contents of the image in this way.

Fifth, what filesystem is on the card and what are sizes of the source device (ie: the one you created the dd image from) and target device ? If they are different, are you encountering filesystem geometry issues ?

Finally, check /var/log/messages to see if there are any clues there when you reinsert the card.

Simon.

As well as posting the dd command you are using to write to the new SD card, can you also post the dd command you used to create the image in the first place ?

Simon.

Sorry, that bit was unclear. I meant what is the filesystem used on the source device for the dd image, and hence is embedded within the dd image you created. I didn't mean the filesystem on the destination card (which will get destroyed when overwritten by the dd image.)

Simon.

Just a thought: I once had a reader that couldn't reliably tell the computer what was going on when a card was pulled, a card of a different type put in, then that card pulled and swapped for the first one.

Put pulling the plug on the card reader, putting a card in, and plugging the reader in _did_ work.

It's total voodoo, but you may want to try that if Simon's more rational suggestions don't work.

You can also use these options to dd: oflag=direct or oflag=dsync

to ensure that the writes aren't cached. I'm not completely clear on the difference (which I think maps to O_DIRECT and O_DSYNC in the I/O calls, but nothing seems to explain what they mean for raw block devices).

I'd also recommend pulling out the card/card reader (ideally the card reader) and plugging it back in, so that any cached partition information is cleared.

Theo

"Simon Clubley" wrote in message news:jl7hru$v2e$ snipped-for-privacy@dont-email.me...

Hi Simon, Here's the command for the dd write to SD card, it's straight from the vendor documentation, obviously the paths I've used differ, but as I mentioned the write seems to work fine. I suspect strongly that the lack of closing the write as you and others have mentioned could be the problem, once I get another SD card that the reader will recognise, that'll be the first thing I try.

The source image has been downloaded from the vendor website, straight into the host filesystem.

dd if=/path/to/2gbsd-noeclipse-latest.dd conv=sync bs=512 of=/dev/sda I'd prefer not to mention the supplier involved, because I am having problems, and that may lead to perceptions by others that are unwarranted. They have been very helpful in other aspects, and their hardware is excellent.

Thanks to all for the input.

Before you spend money on another card, I am not yet convinced your existing card is actually damaged. It's possible that it's filesystem may simply be unreadable which may be causing it to not be visible to the GUI level, but it should still be visible to fdisk in that case. As such, you may wish to consider the following suggestions. All these suggestions require executing with root level access.

First, do you get any I/O errors if you repeat this command on the same card a second time ? If you do, then yes, the card may have been damaged somehow, but it would still surprise me. (BTW, make sure there is a /dev/sda device node first before repeating the command, as this dd command will likely create a normal file in /dev/ called sda if there isn't).

Second, after unplugging and plugging back in the card reader with the suspected faulty card inserted, look at the resulting messages in /var/log/messages as there may be some clues there. If you post the full set of messages which occur as a result of this, one of us here may spot something.

Third, what happens when you run "/sbin/fdisk /dev/sda" and display the partition information ? This is my actual test for if /dev/sda has really been recreated (and is physically accessible) after the card was reinserted regardless of whatever any GUI might say.

If you get as far as fdisk displaying a partition layout, even if it's junk, the card is still physically accessible.

Finally, you need to make sure that the source image is ok before trying to write it to another card. I recommend you mount it using a loopback device (in readonly mode to avoid accidental changes) and make sure that you can view the filesystem embedded within this vendor supplied image.

I understand. I have had this dilemma in the past as well.

Simon.