Other Can't erase microSD after burning FreeBSD on it.

Hello guys!

Recently I have tried to set up FreeBSD on my Raspberry Pi. So I burnt my microSD on macOS with "dd if=/path/to/img_file of=/dev/disk1 bs=1 conv=sync" and used for its intended purpose without any problems. But after some time I have noticed, that files have been erased after reboot. As the card have been needed for other purposes, I decided to delete FreeBSD. But it did not work. Nothing can delete neither partitions(slices) nor files in them. MacOS, Windows even Linux can't handle it. Console/gui utilities are useless. After rewriting with other images they report about success, but in reality it is still. Any computer able to mount card, but not erase or write.
Also there is no any permission problems, just like normal storage.

Is that microSD "died"? Is there any possibility to return to normal operation?

On the screenshot: /dev/disk1s1 - boot, /dev/disk1s2 - root
Снимок экрана 2016-12-11 в 1.39.04.png
 
No, it's not possible to permanently destroy an SD card by writing an image on it. The FreeBSD image just has a non-standard partitioning and filesystem that MS Windows and OS X fail to recognize. That's why they can't handle it, at least not directly. I'm pretty sure you can still wipe it clean in the OS X disk utility, select the disk (not the partition) on the list and choose "Erase".
 
Have you tried to zero it with dd if=/dev/zero ?

Also some adapters have a lock on the side to make it read only.

Yes dd if=/dev/zero with bs=512. Spent a lot of time, but no result.
I have tried with unlocked adapter and with card reader, result is the same.
 
No, it's not possible to permanently destroy an SD card by writing an image on it. The FreeBSD image just has a non-standard partitioning and filesystem that MS Windows and OS X fail to recognize. That's why they can't handle it, at least not directly. I'm pretty sure you can still wipe it clean in the OS X disk utility, select the disk (not the partition) on the list and choose "Erase".

Nope
Unfortunately neither disk utility nor diskutil can't do this. Disk utility says that the disk have to be disabled. Although I unmounted it manually.
I should try connect my microSD to the FreeBSD virtual machine and erase it there
Снимок экрана 2016-12-11 в 13.21.36.png
Снимок экрана 2016-12-11 в 13.19.46.png
 
When writing FreeBSD installation images to media those become partitioned "dangerously dedicated".
This can be reverted by gpart destroy -F <device: i.e. da0> making USB sticks etc. reusable.

Avoid operations like dd if=/dev/zero to memory based media. You might not get what you intend to do because of the self-management of those devices. Even worse such operations can deteriorate remaining lifespan of the (cheap) memory used in most of those devices.
 
When writing FreeBSD installation images to media those become partitioned "dangerously dedicated".
This can be reverted by gpart destroy -F <device: i.e. da0> making USB sticks etc. reusable.

Avoid operations like dd if=/dev/zero to memory based media. You might not get what you intend to do because of the self-management of those devices. Even worse such operations can deteriorate remaining lifespan of the (cheap) memory used in most of those devices.

In FreeBSD everything looks good. But after I have unpluged card from virtual machine, gparted and fdisk show me old results
upload_2016-12-11_14-11-31.png

upload_2016-12-11_14-20-7.png

upload_2016-12-11_14-17-59.png
 
Hm. Is it possible to write/dd some other image (e.g. Linux) on this SDcard? If that works, you may create an (empty) image with standard(c) file system with size of the card and "burn" this. Just an idea.

Ciao,

Photor
 
dd if=/dev/zero with bs=512
No kidding. That is a tremendous waste of time. Always use at least a bs of 64k. 1M is fine. However, this should not be done on flash media unless necessary.

When writing FreeBSD installation images to media those become partitioned "dangerously dedicated".
This has changed recently. FreeBSD 11, for instance, is a UEFI or BIOS/MBR boot image.

The difficulty sounds like it came from using old utilities that only understand MBR. They happily changed the PMBR, but anything modern knows that's just a fake and it's really the GPT tables that are important. People often blow away the primary GPT but leave the secondary one at the end of the disk in place. Then things get confusing. The way to fix that is to destroy whatever partitioning is on the disk, then create a GPT layout, then destroy that also.

Overwriting the disk with dd should also do that, although it will take a long time and isn't particularly good for flash media. But depending on the platform, something might have protected those tables.

So, guidelines:
Don't use dd until all other options have been tried.
Don't use old utilities like fdisk.
Don't use anything that does not understand both MBR and GPT.
I don't know how good the Linux disk utilities are. I do know that gpart(8) on FreeBSD is very good at this.

So use gpart(8) to destroy any confused partitioning, then create a GPT partitioning scheme, then destroy that.
 
Hm. Is it possible to write/dd some other image (e.g. Linux) on this SDcard? If that works, you may create an (empty) image with standard(c) file system with size of the card and "burn" this. Just an idea.

Ciao,

Photor

Nope, any write operations (include dd images) do not work with card any more :c
 
There's one possibility but it's quite unlikely, the card may have a firmware with programmable write protection switch and erasing the original partition and filesystem layout might have turned on the protection.
 
In the ports collection is sysutils/disktype, it is a useful tool to detect as much info about partitions / filesystems as possible. It can be run on regular files as well as block devices. I wonder what it would tell us about OP's microSD card.
 
There's one possibility but it's quite unlikely, the card may have a firmware with programmable write protection switch and erasing the original partition and filesystem layout might have turned on the protection.

I have looked through the card initialization process (linux dmesg). There was no such thing. Line like "Write protection" had "no" status.
 
I have little experience with GParted. It has worked for me some times, failed at other times. gpart(8) has a more narrow scope and is better at it.

The screenshots I saw showed gpart working. And now I see "virtual machine" in the messages above, which changes the whole game.

I would use FreeBSD on real hardware to do this. It would not have to be installed, a "live" disk like mfsBSD would work, as would the Shell mode of the FreeBSD installer. Of course, there is the difficulty of identifying the right disk and not erasing the wrong one.
 
I have little experience with GParted. It has worked for me some times, failed at other times. gpart(8) has a more narrow scope and is better at it.

The screenshots I saw showed gpart working. And now I see "virtual machine" in the messages above, which changes the whole game.

I would use FreeBSD on real hardware to do this. It would not have to be installed, a "live" disk like mfsBSD would work, as would the Shell mode of the FreeBSD installer. Of course, there is the difficulty of identifying the right disk and not erasing the wrong one.

In the ports collection is sysutils/disktype, it is a useful tool to detect as much info about partitions / filesystems as possible. It can be run on regular files as well as block devices. I wonder what it would tell us about OP's microSD card.

Yes, advices with BSD tools I'm trying on vm.
But what is the difference? Why vm change everything?
I've got some free space on laptop's hdd. Allocated the disk space exactly for FreeBSD. I would like to make dualboot, but forgot about it :D
Will try on fresh dual boot or live and show results.

And yes, Gparted weak a bit. But there is gparted live, which make this tool very helpful.
 
The thing with a VM is that the hardware isn't real. There can be bugs in the emulation. Or you might have the emulated disk set to accept writes and write them in memory, but never actually commit them to disk. So the state of the disk reverts when the VM restarts. Or there might be a snapshot of the VM.

Please do not experiment on the laptop drive. At least not without a full, verified backup first.
 
The thing with a VM is that the hardware isn't real. There can be bugs in the emulation. Or you might have the emulated disk set to accept writes and write them in memory, but never actually commit them to disk. So the state of the disk reverts when the VM restarts. Or there might be a snapshot of the VM.

Please do not experiment on the laptop drive. At least not without a full, verified backup first.

Oh, I agree. Work with real hardware would make more sense!
Yes, of course I have 1 or 2 verified backups. I've already got some bad experience with the installation modifications of the operating systems :D

There were some issues with configure wlan interface, so I was not able to install. Will try handle it a bit later. Just FreeBSD live boot for now.
Unfortunately there was no result.
And sorry for image quality...
 

Attachments

  • upload_2016-12-15_10-52-26.png
    upload_2016-12-15_10-52-26.png
    719.6 KB · Views: 493
  • upload_2016-12-15_10-52-54.png
    upload_2016-12-15_10-52-54.png
    565.3 KB · Views: 487
  • upload_2016-12-15_10-53-9.png
    upload_2016-12-15_10-53-9.png
    698.1 KB · Views: 493
  • Screenshot from 2016-12-15 10-43-00.png
    Screenshot from 2016-12-15 10-43-00.png
    49.7 KB · Views: 528
In the ports collection is sysutils/disktype, it is a useful tool to detect as much info about partitions / filesystems as possible. It can be run on regular files as well as block devices. I wonder what it would tell us about OP's microSD card.

Sorry for the long delay. I wanted to dualboot install FreeBSD on my laptop, but it is not possible so far. Here is what disktype says.
 

Attachments

  • upload_2016-12-15_11-32-9.png
    upload_2016-12-15_11-32-9.png
    19 KB · Views: 491
Back
Top