From owner-freebsd-questions@freebsd.org Sat Nov 30 23:29:30 2019 Return-Path: Delivered-To: freebsd-questions@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 C9C481BC0C4 for ; Sat, 30 Nov 2019 23:29:30 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47QSJT551Zz4fpK for ; Sat, 30 Nov 2019 23:29:29 +0000 (UTC) (envelope-from tomek@cedro.info) Received: by mail-ot1-x32f.google.com with SMTP id a15so343062otf.1 for ; Sat, 30 Nov 2019 15:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CF/2rqOsr72OFtAUXmyOf0E4a9gvHksldCVmEP63/V8=; b=fAXHMqRN/IL9vy53QNoox5HPmSxz8o/0ryCHTF3njAa3JVL/AVljPUIGcQEI+YRn/l wzZWr7dg9NRtoN+ahkbERNHzYRxdgkVBPdXqBrCjfTSZX0E58NPAqghdFoNd7GH5Dp9I ZM+tIicaGKH+yuba8iwWgbec3+nbi7VkEo/q15n5Nc/sMWnB3QXbESrxLx1jOJSrBVHs VfIsWsBcQhGkkOUm8MZd8/DvWhstHIMmg9BQ4eR4AoL0183FKQRkTSz186QGxmFv4HbJ 5X1yxxpGWRmIqy/GiLTAxIkK/vON8nxjYFeZNFOzqPvlCVwMBSiHVucC/kQtQ62YJCdg HBLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CF/2rqOsr72OFtAUXmyOf0E4a9gvHksldCVmEP63/V8=; b=IGmpJ+eeQ/W2WsxiokpWRI8J6ybabxjiglgsMuZ2xBhBhwbfKfbStZeBh0Ehr38qVN mlTj9Ww6IKLV16/jopaH11NLfcpyoa/sv4L8AlU2UeVNVfMEi5UKhSyvjZsGCh/pvn6P azLxGIHBtIrOkM8tR8b3GCy8Kkkp8oE/MNFl4wjIf2uUen3AejwjNGGHPSYo6gJ/BvWm eWeBJd9se6zzBe5TIKzmyZ8KukVQNPsLoSCNubj1P4tDLXobKYgJUV/TlayTMq66SKdv TK2i9rss9LHaX7Cy44GFk0IfvgGtUNVlqlAtkqV2xRHBDRxMiUflTcYo6yObA23D2x6f fS8Q== X-Gm-Message-State: APjAAAVTp6dy0shIf787Wz0Sliu1DxnqzdtiV66KelMZJGP8N4fzp+3b LAl1S1diOWK8+sQ2XyJGokPKfc6iQEU= X-Google-Smtp-Source: APXvYqwPYQ0K2hdoLLt/EEZKJymtTQE9FGGxLK9j88FXp87gGq8WBPAlfJtgFfgrIt7paT7nu43Icg== X-Received: by 2002:a9d:5cca:: with SMTP id r10mr15117704oti.57.1575156568323; Sat, 30 Nov 2019 15:29:28 -0800 (PST) Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com. [209.85.167.174]) by smtp.gmail.com with ESMTPSA id j26sm2066588otq.18.2019.11.30.15.29.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 Nov 2019 15:29:27 -0800 (PST) Received: by mail-oi1-f174.google.com with SMTP id k196so12781261oib.2; Sat, 30 Nov 2019 15:29:27 -0800 (PST) X-Received: by 2002:aca:5785:: with SMTP id l127mr6227330oib.168.1575156566754; Sat, 30 Nov 2019 15:29:26 -0800 (PST) MIME-Version: 1.0 References: <20191130223322.1028feab.freebsd@edvax.de> <20191130234900.81464b43.freebsd@edvax.de> In-Reply-To: <20191130234900.81464b43.freebsd@edvax.de> From: Tomasz CEDRO Date: Sun, 1 Dec 2019 00:29:13 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: pendrive clone impossible ? To: Polytropon Cc: FreeBSD Questions Mailing List , "freebsd-usb@FreeBSD.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 47QSJT551Zz4fpK X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=cedro.info header.s=google header.b=fAXHMqRN; dmarc=none; spf=none (mx1.freebsd.org: domain of tomek@cedro.info has no SPF policy when checking 2607:f8b0:4864:20::32f) smtp.mailfrom=tomek@cedro.info X-Spamd-Result: default: False [-3.69 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[cedro.info:s=google]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; DMARC_NA(0.00)[cedro.info]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[cedro.info:+]; RCVD_IN_DNSWL_NONE(0.00)[f.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; IP_SCORE(-2.39)[ip: (-7.70), ipnet: 2607:f8b0::/32(-2.25), asn: 15169(-1.94), country: US(-0.05)] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2019 23:29:30 -0000 On Sat, Nov 30, 2019 at 11:49 PM Polytropon wrote: > > On Sat, 30 Nov 2019 23:28:04 +0100, Tomasz CEDRO wrote: > > It looks like either GEOM is hiding something from application/me, or > > pendrive itself is preventing MBR to be modified, or some sort of > > mix..? > > That is possible (but unlikely), and there's another (equally > unlikely) possibility that your computer has some "boot sector > virus protection" activated in the BIOS which prevents writes > to block 0 of a device... Nope, I also though about that, buy would have noticed that, and the problem did not show up with any other device, while I am really cloning lots of drives for servicing/backup purposes :-) > > I guess the first is more probable because DD'ing from /dev/md0, > > /dev/zero, /dev/random devices always works, while DD'ing from da0.mbr > > file never works. If pendrive was defending itself none of them would > > be possible, right? > > Yes, that's at least my impression. Can you provide an error > message of dd, or does it say "blocks copied", but no MBR data > actually arrived on the USB stick? no error at all. just blah bytes transferred in blah seconds (blah bytes / second). > > The Source pendrive was MBR. This is why I did /dev/zero -> /dev/da1 > > just to make sure there is no GPT of any sort on the Target pendrive, > > nor MBR, also I could see where write was skipped. > > Okay, so you can _confirm_ that there is MBR (partition table > with "DOS primary partitions") in it - good. In that case, > using gpart or fdisk to read the MBR should work definitely > for the source stick - and should also work for the target stick > after the MBR has been written correctly. Yes. Source pendrive works and worked fine for several months on dozens of machines connected with no problem. Target pendrive was advertised to be faster so I just wanted to clone the data to a faster device ;-) > If you use something like > # dd if=/dev/da0 of=/dev/da1 bs=1M > i. e., a block size typical for such media, does it make any > difference? Not copying 512 bytes is one thing, but not copying > a much larger block - 1 MB - with the 512 bytes at its beginning, > that would be _really_ strange. I usually use "bs=1000m" or "bs=500m" with "status=progress" for a large drives because that allows optimal performance and progress tracking.. so I guess the bigger block size has already been tested :-) > If you dd the 1st 512 bytes out of the source and the target and > compare them, are they identical? They _should_, according to what > dd reports. > > # dd if=/dev/da0 of=/dev/da1 bs=512 count=1 That did not copy the DA0 MBR to DA1. > # dd if=/dev/da0 of=da0.mbr bs=512 count=1 That did copy DA0 MBR to a file. > # dd if=/dev/da1 of=da1.mbr bs=512 count=1 That did copy DA1 MBR to a file. > # diff da0.mbr da1.mbr Looking with `less -f` when the copy was done the contents was the same, when copy was not done I could see the difference because of writing zeros prior. > You can then repeat this test with a bigger block: I did a copy whole disk data from one to another using much more bigger blocks like 100M 500M and 1000M.. no change. > In any case, there should be _no_ difference (no matter if the > partitions themselves are incomplete and unreadable on the target > stick). Yes, I think so too. > > Because I need to finish quickly, I have used GPART to create and add > > partitions by hand and I am DD'ing partition by partition. So far so > > good. > > In case they are UFS partitions, you could newfs the target > partition, and then use dump | restore - I don't know if this > is faster, but it would work as well. I just have one big FAT32 storage partition for files, one bootable FreeBSD LiveCD/Installed copied from a memstick image, and one Kali Linux bootable image just in case ;-) > Next idea is for them to put some "AI/ML anti virus malware" into > the firmware of the USB stick that accepts data, returns "written" > to the writer, but doesn't actually write anything to its storage, > because... we need to protect the users! :-) Well, I need to stop at assumption that this particular Kingston line of pendrives are messy and should be avoided, maybe some quirk could do the job, but I have no more time to play, so I leave a trace if someone meets similar issues in future :-) > Rule: > If it stops you to do stupid things, it also stops you to do clever > things, and most things we do in UNIX world are usually not invented > elsewhere. :-) This is why I do not respect these modern UX "researchers" that removed menu from a GIMP toolbar "because no other program works that way". This most beautiful Rule in the universe reveals such ignorance instantly! On the other side of the force we have "according to microsoft development is about enforcing changes" and so we do live now in this kind of the "enforced" world.. Thank you Poly for your time, lets stop here! :-) :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info