From owner-freebsd-bugs@freebsd.org Sun Dec 1 17:17:04 2019 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2341B1B19FF for ; Sun, 1 Dec 2019 17:17:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 47Qw0J0D8vz4261 for ; Sun, 1 Dec 2019 17:17:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 05D701B19FD; Sun, 1 Dec 2019 17:17:04 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0597A1B19FC for ; Sun, 1 Dec 2019 17:17:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47Qw0H6Q5pz425y for ; Sun, 1 Dec 2019 17:17:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id BBE8119F2A for ; Sun, 1 Dec 2019 17:17:03 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xB1HH3ag079274 for ; Sun, 1 Dec 2019 17:17:03 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xB1HH3ZT079272 for bugs@FreeBSD.org; Sun, 1 Dec 2019 17:17:03 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 242341] GEOM / GEOM_PART: silent discard MBR modification Date: Sun, 01 Dec 2019 17:17:03 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: tomek@cedro.info X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2019 17:17:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D242341 Bug ID: 242341 Summary: GEOM / GEOM_PART: silent discard MBR modification Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: tomek@cedro.info Hello world, I am unable to clone a pendrive with `dd if=3D/dev/da0 of=3D/dev/da1` becau= se GEOM_PART considers disk broken and silently prevents writing _all_ data (it discards MBR), thus: 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? This looks typical Linux way, and we don't really like Linux for th= at, right? 4. OS / GEOM is broken and incoherent in this area and proves system unreliable / not trustworthy. This needs to be fixed please. Solution proposal: 1. Do not hide actions / never lie to the user. Do what superuser wants. 2. When disk is _considered_ broken then access should be blocked returning= I/O Error with DMESG message and instructions how to use sysctl that will allow writing to a _whole_ disk in order to fix it. 3. Use clear _warnings_ but perform actions, or use _errors_ and prevent actions. Thank you :-) Tomek ugen0.8: at usbus0 umass1 on uhub0 umass1: on us= bus0 umass1: SCSI over Bulk-Only; quirks =3D 0x8100 umass1:3:1: Attached to scbus3 da1 at umass-sim1 bus 1 scbus3 target 0 lun 0 da1: Removable Direct Access SPC-4 SCSI de= vice da1: Serial Number BLAHBLAH da1: 400.000MB/s transfers da1: 118272MB (242221056 512 byte sectors) da1: quirks=3D0x2 GEOM_PART: integrity check failed (da1, MBR) <--- here is the only problem indication --=20 You are receiving this mail because: You are the assignee for the bug.=