pendrive clone impossible ?

Sat Nov 30 23:29:30 UTC 2019

On Sat, Nov 30, 2019 at 11:49 PM Polytropon wrote:
>
> On Sat, 30 Nov 2019 23:28:04 +0100, Tomasz CEDRO wrote:
> > It looks like either GEOM is hiding something from application/me, or
> > pendrive itself is preventing MBR to be modified, or some sort of
> > mix..?
>
> That is possible (but unlikely), and there's another (equally
> unlikely) possibility that your computer has some "boot sector
> virus protection" activated in the BIOS which prevents writes
> to block 0 of a device...

Nope, I also though about that, buy would have noticed that, and the
problem did not show up with any other device, while I am really
cloning lots of drives for servicing/backup purposes :-)

> > I guess the first is more probable because DD'ing from /dev/md0,
> > /dev/zero, /dev/random devices always works, while DD'ing from da0.mbr
> > file never works. If pendrive was defending itself none of them would
> > be possible, right?
>
> Yes, that's at least my impression. Can you provide an error
> message of dd, or does it say "blocks copied", but no MBR data
> actually arrived on the USB stick?

no error at all. just blah bytes transferred in blah seconds (blah
bytes / second).

> > The Source pendrive was MBR. This is why I did /dev/zero -> /dev/da1
> > just to make sure there is no GPT of any sort on the Target pendrive,
> > nor MBR, also I could see where write was skipped.
>
> Okay, so you can _confirm_ that there is MBR (partition table
> with "DOS primary partitions") in it - good. In that case,
> using gpart or fdisk to read the MBR should work definitely
> for the source stick - and should also work for the target stick
> after the MBR has been written correctly.

Yes. Source pendrive works and worked fine for several months on
dozens of machines connected with no problem. Target pendrive was
advertised to be faster so I just wanted to clone the data to a faster
device ;-)

> If you use something like
>         # dd if=/dev/da0 of=/dev/da1 bs=1M
> i. e., a block size typical for such media, does it make any
> difference? Not copying 512 bytes is one thing, but not copying
> a much larger block - 1 MB - with the 512 bytes at its beginning,
> that would be _really_ strange.

I usually use "bs=1000m" or "bs=500m" with "status=progress" for a
large drives because that allows optimal performance and progress
tracking.. so I guess the bigger block size has already been tested
:-)

> If you dd the 1st 512 bytes out of the source and the target and
> compare them, are they identical? They _should_, according to what
> dd reports.
>
>         # dd if=/dev/da0 of=/dev/da1 bs=512 count=1

That did not copy the DA0 MBR to DA1.

>         # dd if=/dev/da0 of=da0.mbr bs=512 count=1

That did copy DA0 MBR to a file.

>         # dd if=/dev/da1 of=da1.mbr bs=512 count=1

That did copy DA1 MBR to a file.

>         # diff da0.mbr da1.mbr

Looking with `less -f` when the copy was done the contents was the
same, when copy was not done I could see the difference because of
writing zeros prior.

> You can then repeat this test with a bigger block:

I did a copy whole disk data from one to another using much more
bigger blocks like 100M 500M and 1000M.. no change.

> In any case, there should be _no_ difference (no matter if the
> partitions themselves are incomplete and unreadable on the target
> stick).

Yes, I think so too.

> > Because I need to finish quickly, I have used GPART to create and add
> > partitions by hand and I am DD'ing partition by partition. So far so
> > good.
>
> In case they are UFS partitions, you could newfs the target
> partition, and then use dump | restore - I don't know if this
> is faster, but it would work as well.

I just have one big FAT32 storage partition for files, one bootable
FreeBSD LiveCD/Installed copied from a memstick image, and one Kali
Linux bootable image just in case ;-)

> Next idea is for them to put some "AI/ML anti virus malware" into
> the firmware of the USB stick that accepts data, returns "written"
> to the writer, but doesn't actually write anything to its storage,
> because... we need to protect the users! :-)

Well, I need to stop at assumption that this particular Kingston line
of pendrives are messy and should be avoided, maybe some quirk could
do the job, but I have no more time to play, so I leave a trace if
someone meets similar issues in future :-)

> Rule:
> If it stops you to do stupid things, it also stops you to do clever
> things, and most things we do in UNIX world are usually not invented
> elsewhere. :-)

This is why I do not respect these modern UX "researchers" that
removed menu from a GIMP toolbar "because no other program works that
way". This most beautiful Rule in the universe reveals such ignorance
instantly! On the other side of the force we have "according to
microsoft development is about enforcing changes" and so we do live
now in this kind of the "enforced" world..

Thank you Poly for your time, lets stop here! :-) :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info