Apple court, Apple rules. Try diskutil:
$ diskutil list
# if mounted somewhere
$ sudo diskutil unmount $device
# all the partitions (there's also a "force" option, see the manual)
$ sudo diskutil unmountDisk $device
# remember zip drives? this would launch them. good times!
$ sudo diskutil eject $device
(In the case of a disk image, the hdiutil ...
If you have a recent enough version of util-linux, it contains the tool blkdiscard which is able to TRIM entire devices, or ranges within a device using --offset and --length options.
Please note: blkdiscard is dangerous, if you let it TRIM the wrong regions, your data is gone!
So you can figure out the unpartitioned (free) regions of your partition table ...
dd: error writing „/dev/mmcblk0“: I/O error
“I/O error” (short for “input/output error”) means that there was a problem accessing a hardware. When you get this on a storage medium, it means that your storage medium is dead or dying, or you have a loose wire or underpowered peripheral or some other hardware problem.
I/O error from an SD card means that it's ...
I figure there is a cache somewhere that is holding up the final 5MB but I thought fsync should make sure that doesn't happen
conv=fsync means to write back any caches by calling fsync - after dd has written all the data. Hanging at the end is exactly what it will do.
When the output file is slower than the input file, the data written by dd can pile up ...
The ext4 feature (400) is the new metadata_csum feature. If this feature is enabled and old tools are used to mount the filesystem they will only be able to mount read-only.
To create a ext4 filesystem without this feature:
sudo mke2fs /dev/sdb1 -O ^metadata_csum
Or turn it off on an already ...
I think stress testing an SD card is in general problematic given 2 things:
There are no guarantees that one write to the next is actually exercising the same physical locations on the SD. Remember that most of the SD systems in place are actively taking a block as we know it and moving the physical location that backs it around based on the ...
LVM is not overkill if you have 17 partitions. (IMHO)
As for the partition limit, it just happens to be the default. Probably no one expected that many partitions on a device that used to have only a few megs.
179 block MMC block devices
0 = /dev/mmcblk0 First SD/MMC card
I just ran into this same problem. After debugging the issue with the e2fsck maintainer, we realised that the SD card was broken. It was accepting writes without error, but it wasn't actually writing the data to the card. The SD card was effectively read only.
It seems the card had gone into some sort of failsafe mode, where the data could still be read, ...
(Old question, but useful info for those searching)
If you want to fully test an SD card (destructively) you can check the entire data space with the F3 tools which have been ported to Linux
They let you write a variety of patterns to the disk and then check to see if there are any failures.
You could also use badblocks, but badblocks uses repeating ...
While they are quite reliable (no moving parts), SD cards/USB flash drives can be slower (you probably do not want to run disk-intensive operations from there) and have limited write cycles. From this Super User question:
Flash memory indeed has limited write cycles. However, by now it is unlikely that you'll encounter this within the normal lifetime of ...
hdparm --trim-sector-ranges can trim a range. The man page warns to use it, so you better be sure you got the right range and syntax.
I think sending a trim for all data outside a partition would be dangerous, as there is some hidden data there sometimes like bootloader code or second partition tables. You'd need to know exaclty, which areas outside of ...
Figure out that I should enable the following kernel configurtion:
After added these three configuration based to my old config, everything is working as expected.
If you're just looking to copy an SD card exactly from one to another then you can do so with dd on the command line.
You should NOT do this from your raspberry pi from it's own OS. This is because the OS may write to the SD card while copying and corrupt the copy.
To copy an sd card, plug both into your two readers (it doesn't matter whether or not they ...
I've ran an entire system from an SD card before (over USB 1.0!) It was extremely slow. I was running OpenBSD. It has softdep which increased performance by a large amount, though that doesn't transfer to Linux.
I'd say the biggest thing to make sure of is that you mount it with noatime, this way, you don't get penalized by every read you do. Also, you ...
I do this and it works just fine for me. But I only use it on one computer; the biggest problem I see with using the same card for two means you can only use one at a time. Just something to watch out for: I ran into a bit of trouble because the system was trying to mount the /home directory before the SD card was detected, aborting the boot process. I had ...
There are a number of issues with your test, some fuzzy, some not. It also depends on your goal. Two subtle, sort of fuzzy issues are:
You are not reading from the same area you are writing to, your read test effectively, then, does nothing (unless the controller has read disturb correction, in which case it may occasionally move the page being read to ...
I assume you (your unix user) owns the device or at least has sufficient permissions on it (for example if you are root).
If the command lsblk -o NAME,FSTYPE,MOUNTPOINT,PARTLABEL,SIZE,RO shows your device as read only (RO=1), you can try to execute hdparm -r 0 /dev/sdb5. This disables the read only flag in the kernel (according to man hdparm).
The error "EXT4-fs : couldn't mount RDWR because of unsupported optional features (400)" is due to different versions between the partition formatter (mkfs.ext4) and the mounter.
You have two options:
a) Either you have to upgrade the mounter program using a newer distro inside the SD-card.
b) or you have to backup the files, reformat the SD-card with the ...
I know this is an old thread, but, I figured I'd offer some insight.
This seems to be the way sd cards die a natural death. The number of read/write cycles sd cards can endure is substantially lower than most other mediums considered 'read/write'. When that has been exhausted, the card will go into read only mode, but won't inform you of such. Lots of ...
The answer to this depends heavily on your use case.
I no longer own a Raspberry Pi,
but the one I used to have came with 512 MB of RAM.
Conveniently, my NFS server has the same amount.
In addition to NFS, this server (like all my others)
has an m68k cross-compiler that sees regular use via distcc.
It also has an always-on GNU screen session
attached to the ...
This seems more an hardware/use case problem than something else. I bet common sense might be more important than Linux skills here. Are you doing heavy I/O in the cards, MySQL/Apache/compiling stuff...syslog/frequent system updates? -- comment by Rui F Ribeiro
I can expand on the above. But I agree with the first point, and I agree this was the first ...
As mentioned by 0andriy, you can use bind/unbind. I am doing something similar but this will be different as it depends on the hardware. To unbind my sdio wifi module I use:
echo -n "2190000.usdhc" > /sys/devices/soc0/soc/2100000.aips-bus/2190000.usdhc/driver/unbind
This will give you something like mmc1: card 0001 removed in dmesg.
I then toggle a ...
Well, the way you can fix this is to fix the "power can be cut at any time" problem. Is it impossible to add even a minute of battery power?
Alternatively, maybe you could use two SD cards. Write the data to one card, sync, write to the other. Each block of your data would need a checksum and block number, but then even with some pretty unlucky power ...
Without looking at the kernel source, that would depend on the specific SD chip and its kernel driver. You should look at datasheets and the kernel source. For example, on my laptop:
$ lspci | grep SD
15:00.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 21)
Presumably, the chip implements the SD state machine in hardware, ...
You must tell apart the resizing of a block device (here: /dev/sdb4) from the resizing of a file system. A file system can be smaller but not bigger than the underlying block device.
You should make a backup of the partition table:
sfdisk -d /dev/sdb > ~/sfdisk_sdb.txt
Then you make a copy of that file and adapt the line that looks similar to this:
Just adding some points to slm's answer - note these are more in place for SSDs than for "dumb" SD cards, since SSDs play much dirtier tricks with your data (e.g. de-duplication):
you are writing 64KB to the beginning of the device - this itself has two problems:
flash cells usually have erase blocks of size from 16KB up (more likely in the 128-512KB range,...
Btrfs uses crc32c checksums to check the integrity of blocks.
If the checksum doesn't match the block when it's read then an alternative block is read. This is assuming there is an alternative (RAID1). If that block also fails or if there is no alternative an EIO (error input/output) is returned.
I do not know of any way to automatically detecting errors, ...
The card is password-protected. (@derobert's guess is right.) And kernel modules do not provide useful pointers to this.
I was suspecting this but I did not know that it's a SD-specific hardware feature; I thought that the Nokia simply encrypts the partition which I would be able to solve by action like mkdosfs /dev/sdb or such.