pendrive clone impossible ?

[Tomasz CEDRO]

On Sun, Dec 1, 2019 at 8:28 AM Scott Bennett <bennett at sdf.org> wrote:
> >Does GEOM in any way prevents me from using disk that has corrupt MBR?
>      Yes, most likely.
>
> >Why I cannot write a MBR from a file but I can from a md0?
> >Any hints welcome :-)
>      See the last line of your messages below.
> (..)
> >ugen0.8: <Kingston DataTraveler 3.0> at usbus0
> >umass1 on uhub0
> >umass1: <Kingston DataTraveler 3.0, class 0/0, rev 3.20/1.10, addr 7> on usbus0
> >umass1:  SCSI over Bulk-Only; quirks = 0x8100
> >umass1:3:1: Attached to scbus3
> >da1 at umass-sim1 bus 1 scbus3 target 0 lun 0
> >da1: <Kingston DataTraveler 3.0 PMAP> Removable Direct Access SPC-4 SCSI device
> >da1: Serial Number BLAHBLAH
> >da1: 400.000MB/s transfers
> >da1: 118272MB (242221056 512 byte sectors)
> >da1: quirks=0x2<NO_6_BYTE>
> >GEOM_PART: integrity check failed (da1, MBR)
>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  There is your hint, courtesy of
>  |||||||||  ||||||||||||||||||||||             FreeBSD's GEOM_PART kernel class.

Hello Scott and thank you for your valuable input. If you are sure
that this is NOT a problem of a pendrive or anything USB related with
that particular pendrive (i.e. some quirk required for valid
operations), and you ARE sure that this is a matter of GEOM, then:

1. OS / GEOM is hiding things from operator. It does not write bytes
as instructed to fix the disk, instead, it considers disk invalid and
silently discards _only_some_of_the_data_ with no clear error/warning
indication. Unacceptable!!!

2. OS / GEOM lies to operator. It does return a SUCCESS code while
_some_ data goes to /dev/null. Unacceptale!!!

3. If disk is _considered_ broken then access should be _fully_
blocked. But how am I supposed to fix it when OS silently blocks
essential part of the fix? Who allows writing over a corrupted disk
anyway?

4. OS / GEOM is broken and incoherent in this area and proves system
unreliable / not trustworthy. This needs to be fixed please. Will
report a bug.


That "irrelevant blather" just proves above. OS cannot silently
interfere with operator actions and do whatever it likes. Other people
also noticed this problem. This is not the FreeBSD way, looks more
like Linux way.

Now it looks like the factory pre-format pendrive was considered
invalid by GEOM, this is why the initial `dd if=/dev/da0 of=/dev/da1`
copied _almost_ whole data but without MBR. Then the situation
escalated - MBR dumped to a file could not be written to a target
drive, but it could be written from a md0 device, and all sorts of
black magic. It THIS IS UNACCEPTABLE!!!

When I DD something from IF then it must get untouched into OF, unless
missing privilege or hardware failure error is clearly reported
preventing further actions.

Damn, the DD is the simplest thing in Unix.

Either I get the command executed exactly as instructed, or not
executed at all. The return code is here to say what happened. Error
is here to show me something is wrong. As simple as that.

Now it looks like the disk is okay, just GEOM did some interpretation,
knew better what I want to, and did, without telling me that.

Imagine there were some really sensitive backups on the drive and
system decided only to copy selected parts of them with no error. Not
a problem for you?

Tomek

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