Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 01 Dec 2019 15:09:26 -0600
From:      Scott Bennett <bennett@sdf.org>
To:        tomek@cedro.info
Cc:        gljennjohn@gmail.com, freebsd@edvax.de, freebsd-questions@freebsd.org, anatoly@kazanfieldhockey.ru
Subject:   Re: pendrive clone impossible ?
Message-ID:  <201912012109.xB1L9Q7d014429@sdf.org>
In-Reply-To: <CAFYkXj=imTgDWWkttkgtPpwTFJ4zZ10mjGcQwZ99DLTVnJGROQ@mail.gmail.com>
References:  <201912010728.xB17SQkC019214@sdf.org> <CAFYkXj=imTgDWWkttkgtPpwTFJ4zZ10mjGcQwZ99DLTVnJGROQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Tomasz CEDRO <tomek@cedro.info> wrote:

  [freebsd-usb@ trimmed from addresses *again* --SB]
> On Sun, Dec 1, 2019 at 8:28 AM Scott Bennett <bennett@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:

     Please review wording above.  For anyone to make the claim that
you ask here without his having physical access to the hardware, or even
with access, would be absurd.  Having said that, I would just comment that
small flash drives are the most frequently fallible/defective devices I
have yet encountered.  I have used them with no problem, then unplugged
them, and the next time I've plugged them in, they caused a stream of
error messages on the console until the kernel eventually shut them down
and refused to reuse the device name for any purpose at all until after
a reboot.  Usually, though, they fail mostly silently and become totally
unresponsive.  Would a flash drive that failed in some way I hadn't seen
before be surprising?  Not in the least.
>
> 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!!!

     Well, let's see here.  You ignored the error message the system did
give you, but now you want more and different messages?
     The status of the device after the kernel has rejected its MBR is
not something I could say with certainty.
>
> 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.
>
     I would suggest that you at least try what I suggested in my previous
message.  Do also take a moment to read the descriptions of both sysctl
variables, and think about what they imply.  That took care of such
problems for me.
>
> 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.

     I've already shown you that it was not silent in rejecting the MBR
on the device.
>
> 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

     Your description does look peculiar, I agree.  However, you might
also try recording all command input and stderr output using a tool like
script(1), so you could show us exactly what happened.
     Hm.  Before rebooting, here is something else to try.  After
attaching the flash drive, if you get the error message again, try

ls -lgFG /dev/da*
gpart show da0 da1
gpart show -l da0 da1

and post the output from them in your next report here.  I am curious to
see which device names for slices and partitions, if any, the system
may create after it rejects a MBR, as well as what gpart(8) gets from it.
If you try setting the two sysctl variables as suggested, these commands'
output would also be interesting to see in that 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!!!

     Again, another post hoc description of events, rather than evidence
we can look at.
>
> 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?
>
     Please use script(1) to document what happens with the sysctl
variables set as suggested by the man page, and then post the results
to the list.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:   bennett at sdf.org   *xor*   bennett at freeshell.org  *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201912012109.xB1L9Q7d014429>