Date: Sun, 01 Dec 2019 16:45:34 -0000 From: Tomasz CEDRO <tomek@cedro.info> To: Scott Bennett <bennett@sdf.org> Cc: FreeBSD Questions Mailing List <freebsd-questions@freebsd.org>, Polytropon <freebsd@edvax.de>, Anatoly <anatoly@kazanfieldhockey.ru>, gljennjohn@gmail.com, "freebsd-usb@FreeBSD.org" <freebsd-usb@freebsd.org> Subject: Re: pendrive clone impossible ? Message-ID: <CAFYkXj=imTgDWWkttkgtPpwTFJ4zZ10mjGcQwZ99DLTVnJGROQ@mail.gmail.com> In-Reply-To: <201912010728.xB17SQkC019214@sdf.org> References: <201912010728.xB17SQkC019214@sdf.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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: 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFYkXj=imTgDWWkttkgtPpwTFJ4zZ10mjGcQwZ99DLTVnJGROQ>