pendrive clone impossible ?

[Dr. Nikolaus Klepp]

Anno domini 2019 Sun, 1 Dec 17:45:17 +0100
 Tomasz CEDRO scripsit:
> 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
> 

IMO your pendrive is broken. Please try the same operation on a live-linux and check again.

Nik


-- 
Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ...