Creating image of CF card produces inconsistent results
A friend is trying to clone a CF card using the following linux command:
sudo dd if=/dev/sdb of=card3.img bs=4M status=progress
but each time, it is producing a different image.
The first two cards they have imaged have produced inconsistent results.
What could be the cause of this?
linux clone dd compact-flash
asked Dec 7 at 9:24
Hiccup
1458
|
show 2 more comments
A friend is trying to clone a CF card using the following linux command:
sudo dd if=/dev/sdb of=card3.img bs=4M status=progress
but each time, it is producing a different image.
The first two cards they have imaged have produced inconsistent results.
What could be the cause of this?
linux clone dd compact-flash
asked Dec 7 at 9:24
Hiccup
1458
2
Is the card currently mounted, maybe things are changing on it
– Xen2050
Dec 7 at 9:28
@Xen2050 He has been unmounting it before each dump. But just mounting a device shouldn't write to it, should it?
– Hiccup
Dec 7 at 9:37
Mounting itself shouldn't modify device's content, but it enables processes to do so. And there's plenty of stuff running in the background in modern OSes.
– gronostaj
Dec 7 at 9:47
Indeed, but I think it would be considered a bug if an OS wrote to external storage without the users permission.
– Hiccup
Dec 7 at 9:50
2
Mounting may modify the device's content: it may update the last-mount timestamp on some filesystems, or the root directory's last-access timestamp, or even the journal in some cases.
– grawity
Dec 7 at 9:51
|
show 2 more comments
A friend is trying to clone a CF card using the following linux command:
sudo dd if=/dev/sdb of=card3.img bs=4M status=progress
but each time, it is producing a different image.
The first two cards they have imaged have produced inconsistent results.
What could be the cause of this?
linux clone dd compact-flash
asked Dec 7 at 9:24
Hiccup
1458
A friend is trying to clone a CF card using the following linux command:
sudo dd if=/dev/sdb of=card3.img bs=4M status=progress
but each time, it is producing a different image.
The first two cards they have imaged have produced inconsistent results.
What could be the cause of this?
linux clone dd compact-flash
linux clone dd compact-flash
asked Dec 7 at 9:24
Hiccup
1458
asked Dec 7 at 9:24
Hiccup
1458
edited Dec 7 at 9:46
asked Dec 7 at 9:24
Hiccup
1458
asked Dec 7 at 9:24
Hiccup
1458
asked Dec 7 at 9:24
Hiccup
1458
1458
2
Is the card currently mounted, maybe things are changing on it
– Xen2050
Dec 7 at 9:28
@Xen2050 He has been unmounting it before each dump. But just mounting a device shouldn't write to it, should it?
– Hiccup
Dec 7 at 9:37
Mounting itself shouldn't modify device's content, but it enables processes to do so. And there's plenty of stuff running in the background in modern OSes.
– gronostaj
Dec 7 at 9:47
Indeed, but I think it would be considered a bug if an OS wrote to external storage without the users permission.
– Hiccup
Dec 7 at 9:50
2
Mounting may modify the device's content: it may update the last-mount timestamp on some filesystems, or the root directory's last-access timestamp, or even the journal in some cases.
– grawity
Dec 7 at 9:51
|
show 2 more comments
2
Is the card currently mounted, maybe things are changing on it
– Xen2050
Dec 7 at 9:28
@Xen2050 He has been unmounting it before each dump. But just mounting a device shouldn't write to it, should it?
– Hiccup
Dec 7 at 9:37
Mounting itself shouldn't modify device's content, but it enables processes to do so. And there's plenty of stuff running in the background in modern OSes.
– gronostaj
Dec 7 at 9:47
Indeed, but I think it would be considered a bug if an OS wrote to external storage without the users permission.
– Hiccup
Dec 7 at 9:50
2
Mounting may modify the device's content: it may update the last-mount timestamp on some filesystems, or the root directory's last-access timestamp, or even the journal in some cases.
– grawity
Dec 7 at 9:51
2
2
Is the card currently mounted, maybe things are changing on it
– Xen2050
Dec 7 at 9:28
Is the card currently mounted, maybe things are changing on it
– Xen2050
Dec 7 at 9:28
@Xen2050 He has been unmounting it before each dump. But just mounting a device shouldn't write to it, should it?
– Hiccup
Dec 7 at 9:37
@Xen2050 He has been unmounting it before each dump. But just mounting a device shouldn't write to it, should it?
– Hiccup
Dec 7 at 9:37
Mounting itself shouldn't modify device's content, but it enables processes to do so. And there's plenty of stuff running in the background in modern OSes.
– gronostaj
Dec 7 at 9:47
Mounting itself shouldn't modify device's content, but it enables processes to do so. And there's plenty of stuff running in the background in modern OSes.
– gronostaj
Dec 7 at 9:47
Indeed, but I think it would be considered a bug if an OS wrote to external storage without the users permission.
– Hiccup
Dec 7 at 9:50
Indeed, but I think it would be considered a bug if an OS wrote to external storage without the users permission.
– Hiccup
Dec 7 at 9:50
2
2
Mounting may modify the device's content: it may update the last-mount timestamp on some filesystems, or the root directory's last-access timestamp, or even the journal in some cases.
– grawity
Dec 7 at 9:51
Mounting may modify the device's content: it may update the last-mount timestamp on some filesystems, or the root directory's last-access timestamp, or even the journal in some cases.
– grawity
Dec 7 at 9:51
|
show 2 more comments
1 Answer
1
active
oldest
votes
Just mounting with write access (rw) could be writing things, on ext filesystems there's at least the following attributes that are updated:
- Last mounted on
- Mount count
- Last mount time
- And possible files access times that are updated when if files are just read (mount's
noatimeshould stop those). - And a "Last write time" attribute if writing occurs)
Actually, mounting without write access (using mount's
-r/-o ro) might still write to the device, see man mount:
-r, --read-only
Mount the filesystem read-only. A synonym is -o ro.
Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, ext3 and ext4 will replay the journal
if the filesystem is dirty. To prevent this kind of write access, you may want to
mount an ext3 or ext4 filesystem with the ro,noload mount options or set the block
device itself to read-only mode, see theblockdev(8) command.
And
blockdevhas the--setrocommand, to set a block device as read-only
You could compare the images and see which bytes are different, with cmp or something like vbindiff. Only a few bytes could be a date or count somewhere (I'm not sure if the attributes are stored as plain text, or encoded somehow).
Or read-only mount two (or more) of the images and compare just the files. Plain diff can compare directory trees, but I prefer a gui like kdiff3. If the only difference is in the mount count or last mount time it won't show up in the files (different file access times probably won't either).
Or maybe the device or your ram or something else is going bad & reading different bytes here & there.
You could also keep the device unmounted, make an image, then unplug & reconnect the device (still unmounted) and make another image & then compare, they should be the same.
answered Dec 7 at 10:48
Xen2050
9,95431536
@KamilMaciorowski How would you "deny write access to it before mounting?
– Hiccup
Dec 7 at 19:36
@KamilMaciorowski Very interesting, I didn't know chmod was all that's needed to ro a device, didn't even know it was possible actually. Have any links to more info? I tried searching & found an inconclusive Q on U&L, andblockdev --setro& mount's noload, but mostly drowned in hits for mount ro & "my USB went ro".
– Xen2050
Dec 8 at 13:10
@Xen2050 I was wrong, my tests were not good enough. Now I seechmoddoesn't prevent access in general. I guess this is the reason. I will delete my comments in few hours.
– Kamil Maciorowski
Dec 8 at 18:48
@Hiccup See my comment just above. Now I think I mislead you withchmod. I'm sorry and I apologize.
– Kamil Maciorowski
Dec 8 at 18:50
@KamilMaciorowski Ah well, it did seem almost "too good to be true," at least I learned a little more about mount's sneaky writes & noload & blockdev
– Xen2050
Dec 10 at 3:23
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1381582%2fcreating-image-of-cf-card-produces-inconsistent-results%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Just mounting with write access (rw) could be writing things, on ext filesystems there's at least the following attributes that are updated:
- Last mounted on
- Mount count
- Last mount time
- And possible files access times that are updated when if files are just read (mount's
noatimeshould stop those). - And a "Last write time" attribute if writing occurs)
Actually, mounting without write access (using mount's
-r/-o ro) might still write to the device, see man mount:
-r, --read-only
Mount the filesystem read-only. A synonym is -o ro.
Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, ext3 and ext4 will replay the journal
if the filesystem is dirty. To prevent this kind of write access, you may want to
mount an ext3 or ext4 filesystem with the ro,noload mount options or set the block
device itself to read-only mode, see theblockdev(8) command.
And
blockdevhas the--setrocommand, to set a block device as read-only
You could compare the images and see which bytes are different, with cmp or something like vbindiff. Only a few bytes could be a date or count somewhere (I'm not sure if the attributes are stored as plain text, or encoded somehow).
Or read-only mount two (or more) of the images and compare just the files. Plain diff can compare directory trees, but I prefer a gui like kdiff3. If the only difference is in the mount count or last mount time it won't show up in the files (different file access times probably won't either).
Or maybe the device or your ram or something else is going bad & reading different bytes here & there.
You could also keep the device unmounted, make an image, then unplug & reconnect the device (still unmounted) and make another image & then compare, they should be the same.
answered Dec 7 at 10:48
Xen2050
9,95431536
@KamilMaciorowski How would you "deny write access to it before mounting?
– Hiccup
Dec 7 at 19:36
@KamilMaciorowski Very interesting, I didn't know chmod was all that's needed to ro a device, didn't even know it was possible actually. Have any links to more info? I tried searching & found an inconclusive Q on U&L, andblockdev --setro& mount's noload, but mostly drowned in hits for mount ro & "my USB went ro".
– Xen2050
Dec 8 at 13:10
@Xen2050 I was wrong, my tests were not good enough. Now I seechmoddoesn't prevent access in general. I guess this is the reason. I will delete my comments in few hours.
– Kamil Maciorowski
Dec 8 at 18:48
@Hiccup See my comment just above. Now I think I mislead you withchmod. I'm sorry and I apologize.
– Kamil Maciorowski
Dec 8 at 18:50
@KamilMaciorowski Ah well, it did seem almost "too good to be true," at least I learned a little more about mount's sneaky writes & noload & blockdev
– Xen2050
Dec 10 at 3:23
add a comment |
Just mounting with write access (rw) could be writing things, on ext filesystems there's at least the following attributes that are updated:
- Last mounted on
- Mount count
- Last mount time
- And possible files access times that are updated when if files are just read (mount's
noatimeshould stop those). - And a "Last write time" attribute if writing occurs)
Actually, mounting without write access (using mount's
-r/-o ro) might still write to the device, see man mount:
-r, --read-only
Mount the filesystem read-only. A synonym is -o ro.
Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, ext3 and ext4 will replay the journal
if the filesystem is dirty. To prevent this kind of write access, you may want to
mount an ext3 or ext4 filesystem with the ro,noload mount options or set the block
device itself to read-only mode, see theblockdev(8) command.
And
blockdevhas the--setrocommand, to set a block device as read-only
You could compare the images and see which bytes are different, with cmp or something like vbindiff. Only a few bytes could be a date or count somewhere (I'm not sure if the attributes are stored as plain text, or encoded somehow).
Or read-only mount two (or more) of the images and compare just the files. Plain diff can compare directory trees, but I prefer a gui like kdiff3. If the only difference is in the mount count or last mount time it won't show up in the files (different file access times probably won't either).
Or maybe the device or your ram or something else is going bad & reading different bytes here & there.
You could also keep the device unmounted, make an image, then unplug & reconnect the device (still unmounted) and make another image & then compare, they should be the same.
answered Dec 7 at 10:48
Xen2050
9,95431536
@KamilMaciorowski How would you "deny write access to it before mounting?
– Hiccup
Dec 7 at 19:36
@KamilMaciorowski Very interesting, I didn't know chmod was all that's needed to ro a device, didn't even know it was possible actually. Have any links to more info? I tried searching & found an inconclusive Q on U&L, andblockdev --setro& mount's noload, but mostly drowned in hits for mount ro & "my USB went ro".
– Xen2050
Dec 8 at 13:10
@Xen2050 I was wrong, my tests were not good enough. Now I seechmoddoesn't prevent access in general. I guess this is the reason. I will delete my comments in few hours.
– Kamil Maciorowski
Dec 8 at 18:48
@Hiccup See my comment just above. Now I think I mislead you withchmod. I'm sorry and I apologize.
– Kamil Maciorowski
Dec 8 at 18:50
@KamilMaciorowski Ah well, it did seem almost "too good to be true," at least I learned a little more about mount's sneaky writes & noload & blockdev
– Xen2050
Dec 10 at 3:23
add a comment |
Just mounting with write access (rw) could be writing things, on ext filesystems there's at least the following attributes that are updated:
- Last mounted on
- Mount count
- Last mount time
- And possible files access times that are updated when if files are just read (mount's
noatimeshould stop those). - And a "Last write time" attribute if writing occurs)
Actually, mounting without write access (using mount's
-r/-o ro) might still write to the device, see man mount:
-r, --read-only
Mount the filesystem read-only. A synonym is -o ro.
Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, ext3 and ext4 will replay the journal
if the filesystem is dirty. To prevent this kind of write access, you may want to
mount an ext3 or ext4 filesystem with the ro,noload mount options or set the block
device itself to read-only mode, see theblockdev(8) command.
And
blockdevhas the--setrocommand, to set a block device as read-only
You could compare the images and see which bytes are different, with cmp or something like vbindiff. Only a few bytes could be a date or count somewhere (I'm not sure if the attributes are stored as plain text, or encoded somehow).
Or read-only mount two (or more) of the images and compare just the files. Plain diff can compare directory trees, but I prefer a gui like kdiff3. If the only difference is in the mount count or last mount time it won't show up in the files (different file access times probably won't either).
Or maybe the device or your ram or something else is going bad & reading different bytes here & there.
You could also keep the device unmounted, make an image, then unplug & reconnect the device (still unmounted) and make another image & then compare, they should be the same.
answered Dec 7 at 10:48
Xen2050
9,95431536
Just mounting with write access (rw) could be writing things, on ext filesystems there's at least the following attributes that are updated:
- Last mounted on
- Mount count
- Last mount time
- And possible files access times that are updated when if files are just read (mount's
noatimeshould stop those). - And a "Last write time" attribute if writing occurs)
Actually, mounting without write access (using mount's
-r/-o ro) might still write to the device, see man mount:
-r, --read-only
Mount the filesystem read-only. A synonym is -o ro.
Note that, depending on the filesystem type, state and kernel behavior, the system may still write to the device. For example, ext3 and ext4 will replay the journal
if the filesystem is dirty. To prevent this kind of write access, you may want to
mount an ext3 or ext4 filesystem with the ro,noload mount options or set the block
device itself to read-only mode, see theblockdev(8) command.
And
blockdevhas the--setrocommand, to set a block device as read-only
You could compare the images and see which bytes are different, with cmp or something like vbindiff. Only a few bytes could be a date or count somewhere (I'm not sure if the attributes are stored as plain text, or encoded somehow).
Or read-only mount two (or more) of the images and compare just the files. Plain diff can compare directory trees, but I prefer a gui like kdiff3. If the only difference is in the mount count or last mount time it won't show up in the files (different file access times probably won't either).
Or maybe the device or your ram or something else is going bad & reading different bytes here & there.
You could also keep the device unmounted, make an image, then unplug & reconnect the device (still unmounted) and make another image & then compare, they should be the same.
answered Dec 7 at 10:48
Xen2050
9,95431536
edited Dec 8 at 13:21
answered Dec 7 at 10:48
Xen2050
9,95431536
answered Dec 7 at 10:48
Xen2050
9,95431536
answered Dec 7 at 10:48
Xen2050
9,95431536
9,95431536
@KamilMaciorowski How would you "deny write access to it before mounting?
– Hiccup
Dec 7 at 19:36
@KamilMaciorowski Very interesting, I didn't know chmod was all that's needed to ro a device, didn't even know it was possible actually. Have any links to more info? I tried searching & found an inconclusive Q on U&L, andblockdev --setro& mount's noload, but mostly drowned in hits for mount ro & "my USB went ro".
– Xen2050
Dec 8 at 13:10
@Xen2050 I was wrong, my tests were not good enough. Now I seechmoddoesn't prevent access in general. I guess this is the reason. I will delete my comments in few hours.
– Kamil Maciorowski
Dec 8 at 18:48
@Hiccup See my comment just above. Now I think I mislead you withchmod. I'm sorry and I apologize.
– Kamil Maciorowski
Dec 8 at 18:50
@KamilMaciorowski Ah well, it did seem almost "too good to be true," at least I learned a little more about mount's sneaky writes & noload & blockdev
– Xen2050
Dec 10 at 3:23
add a comment |
@KamilMaciorowski How would you "deny write access to it before mounting?
– Hiccup
Dec 7 at 19:36
@KamilMaciorowski Very interesting, I didn't know chmod was all that's needed to ro a device, didn't even know it was possible actually. Have any links to more info? I tried searching & found an inconclusive Q on U&L, andblockdev --setro& mount's noload, but mostly drowned in hits for mount ro & "my USB went ro".
– Xen2050
Dec 8 at 13:10
@Xen2050 I was wrong, my tests were not good enough. Now I seechmoddoesn't prevent access in general. I guess this is the reason. I will delete my comments in few hours.
– Kamil Maciorowski
Dec 8 at 18:48
@Hiccup See my comment just above. Now I think I mislead you withchmod. I'm sorry and I apologize.
– Kamil Maciorowski
Dec 8 at 18:50
@KamilMaciorowski Ah well, it did seem almost "too good to be true," at least I learned a little more about mount's sneaky writes & noload & blockdev
– Xen2050
Dec 10 at 3:23
@KamilMaciorowski How would you "deny write access to it before mounting?
– Hiccup
Dec 7 at 19:36
@KamilMaciorowski How would you "deny write access to it before mounting?
– Hiccup
Dec 7 at 19:36
@KamilMaciorowski Very interesting, I didn't know chmod was all that's needed to ro a device, didn't even know it was possible actually. Have any links to more info? I tried searching & found an inconclusive Q on U&L, and
blockdev --setro & mount's noload, but mostly drowned in hits for mount ro & "my USB went ro".– Xen2050
Dec 8 at 13:10
@KamilMaciorowski Very interesting, I didn't know chmod was all that's needed to ro a device, didn't even know it was possible actually. Have any links to more info? I tried searching & found an inconclusive Q on U&L, and
blockdev --setro & mount's noload, but mostly drowned in hits for mount ro & "my USB went ro".– Xen2050
Dec 8 at 13:10
@Xen2050 I was wrong, my tests were not good enough. Now I see
chmod doesn't prevent access in general. I guess this is the reason. I will delete my comments in few hours.– Kamil Maciorowski
Dec 8 at 18:48
@Xen2050 I was wrong, my tests were not good enough. Now I see
chmod doesn't prevent access in general. I guess this is the reason. I will delete my comments in few hours.– Kamil Maciorowski
Dec 8 at 18:48
@Hiccup See my comment just above. Now I think I mislead you with
chmod. I'm sorry and I apologize.– Kamil Maciorowski
Dec 8 at 18:50
@Hiccup See my comment just above. Now I think I mislead you with
chmod. I'm sorry and I apologize.– Kamil Maciorowski
Dec 8 at 18:50
@KamilMaciorowski Ah well, it did seem almost "too good to be true," at least I learned a little more about mount's sneaky writes & noload & blockdev
– Xen2050
Dec 10 at 3:23
@KamilMaciorowski Ah well, it did seem almost "too good to be true," at least I learned a little more about mount's sneaky writes & noload & blockdev
– Xen2050
Dec 10 at 3:23
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1381582%2fcreating-image-of-cf-card-produces-inconsistent-results%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Is the card currently mounted, maybe things are changing on it
– Xen2050
Dec 7 at 9:28
@Xen2050 He has been unmounting it before each dump. But just mounting a device shouldn't write to it, should it?
– Hiccup
Dec 7 at 9:37
Mounting itself shouldn't modify device's content, but it enables processes to do so. And there's plenty of stuff running in the background in modern OSes.
– gronostaj
Dec 7 at 9:47
Indeed, but I think it would be considered a bug if an OS wrote to external storage without the users permission.
– Hiccup
Dec 7 at 9:50
2
Mounting may modify the device's content: it may update the last-mount timestamp on some filesystems, or the root directory's last-access timestamp, or even the journal in some cases.
– grawity
Dec 7 at 9:51