From owner-freebsd-questions@freebsd.org Sat Nov 30 22:49:11 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 0CA7C1BAF43; Sat, 30 Nov 2019 22:49:11 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47QRPx65nbz4cjC; Sat, 30 Nov 2019 22:49:09 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([94.222.2.248]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPA (Nemesis) id 1MauFB-1i3mfU1Q4p-00cRu3; Sat, 30 Nov 2019 23:49:03 +0100 Date: Sat, 30 Nov 2019 23:49:00 +0100 From: Polytropon To: Tomasz CEDRO Cc: FreeBSD Questions Mailing List , "freebsd-usb@FreeBSD.org" Subject: Re: pendrive clone impossible ? Message-Id: <20191130234900.81464b43.freebsd@edvax.de> In-Reply-To: References: <20191130223322.1028feab.freebsd@edvax.de> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:zGXvU+J6bSMGH5TqUhmPcv5uyVs34HmFHSNbo8tn2iXxbcqVPGR iS/AORYWO95hYFqDwY1mwPyogKZSUS4gAhN1ubCvB0wT7k/jMV2MvUc4cgrQAz8aw+XGk0Q 7kLTQqWn1KNYJidkgeFS8Yt8Hlgsr0Nv7aP36CEvTDED/8y0QEhs2bguB5eXkJtYOFdaXVV DGRwa7z5ojAOipq6/ggdw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:f+ZOKn8saXE=:lAz+jre+JgRuAwKPqO7gvD NJiFmY3MlLSZd1Rrnx4wOaQ0xI2/YlooprMQmq5UiNyJS3FJx6xuhbswxRXLj+WJ77rpjMmLX eze+c9GvD68iuViZqhMrz/sVsZ5izAmjTQoSc90FC5KldHEnhAi4GnFgFIQ1915AKM6Gidh/y q8W9uQw2HaoO2BDuCIqbL/FI0c2iI9vJJPF5VKcFMWtIoZg1ncEf5ag77jiDnGYk7Z+7a+3gh VhSaYQg7AYb5E3ZQgrAklogu6rXo7I5Kfyd/I6z6aecIdvUAqv+CAuVzZzxUPgODBMawNv2dp eD9MgB8cJCbnv+2EGKAaRQkbmhN/x5Snd4TamrhIwUTIBQ/50AGePIbPRZJfHku3Mk+SGP66O kw3sL3okD8rdedRsAYBRYBzWqxP28BqP1kv0KJo9XkUkQH43msNK9860GaqE5d8bK/ZhL8ncx oudFpVdv+VVfT3tnJDuDKhdVn3qyG8pdh/9scztyrOk2vIY6K/XthPy9nE/qHzLksNf6uO4gT HWdRBiJUR71c6xC6TpVey/kbBOfKK3u1TxL2fzGWRuASG5tr4LWX0xbkKRxYazVD4P9rxjRZv GQc+8qVDKaZgMCLZqjN/TqUXklnxmHx9J+VyPimZl6KreVJc5XilGT7COXe/lvcip+3wl3fUh XP9zfbg3RcC+9ZqLHCJjWTTOFsT8DiI6iIlCcl5JT5Xegr2fWLlg0o8TNCqRMOhuAOivmhtCR MuwJdefd8D1/KywyYl6m4hPQ/vq+uWc2d888yZjO8Lay6s98JIyAWTwn1QkXPYaTh9hw8569c DgdKzT2SerBlYzqAlkF1GMm/KRXFJiUAz4eI2+wzZnH4vLF2YXSoh1XrWWNHyzA1GdN4qpZah AWw68w2bdTK9RK97srwA== X-Rspamd-Queue-Id: 47QRPx65nbz4cjC X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 212.227.17.13) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [4.84 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[248.2.222.94.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.38)[0.385,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.96)[0.956,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[13.17.227.212.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.10)[ip: (-0.59), ipnet: 212.227.0.0/16(-1.18), asn: 8560(2.29), country: DE(-0.01)] 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 22:49:11 -0000 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... > 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? > 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. > This is the first time ever dd if=/dev/da0 of=/dev/da1 did NOT copy > the entire drive (the da1 attached GEOM noted inegrity checked MBR was > left blank the rest seems to be there). 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. Maybe - even though I cannot imagine why - the target stick does not accept being written smaller amounts of data, which of course is nonsense, as you said that 512 bytes of zeroes or random data _will_ be written. > DD reported NO ERROR.. in fact > I got a standard summary on transferred bytes as operation was > completed successfully. I did not count all bytes transferred because > I never had to before. Is the OS hiding something from me? And from > DD? Is Penrdive messing with the GEOM / OS? 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 # dd if=/dev/da0 of=da0.mbr bs=512 count=1 # dd if=/dev/da1 of=da1.mbr bs=512 count=1 # diff da0.mbr da1.mbr You can then repeat this test with a bigger block: # dd if=/dev/da0 of=/dev/da1 bs=1m count=1 # dd if=/dev/da0 of=da0.1mb bs=1m count=1 # dd if=/dev/da1 of=da1.1mb bs=1m count=1 # diff da0.1mb da1.1mb In any case, there should be _no_ difference (no matter if the partitions themselves are incomplete and unreadable on the target stick). > 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. > The Target pendrive is Kingston 128GB DTSE9 G2 USB3.0. Be careful with > that fellow! > > Below is a Kingston's response cut-and-paste found on a forum where > another folk tried to install bootable system on a 32GB DTSE9 G2 ;-) > > " > The first thing to point out is that a USB drive needs to be set as a > fixed drive which requires a tweak in the firmware, commonly refereed > to as "flipping the RMB". Not every firmware is suitable for such an > operation and since we use different flash controller providers to > meet the supply and demand for our products, we cannot check the > suitability of every firmware to be altered to accomodate booting from > USB. > > Furthermore a standard USB drive is designed for sequential read and > writes, rather than random read and write speeds. > > Booting from the USB will be very slow and will be a detriment to the > product, affectively its longevity. > > Therefore we cannot guarantee the longevity and reliability of the > drive within the warranty period, and could offer no further support > in case of a drive failure. > > This is the reason why we at Kingston do not support the bootability > of our commodity USB products. > > If you purchased the DTSE9G2/32GB to be used specifically for this > purpose, we can only recommend that you return it to your supplier for > a refund and we apologise for any inconvenience this may cause. > " > > WELL, KINGSTON LOOKS LIKE A LOTTERY AND I FEEL LIKE A WINNER! ;-) 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! :-) 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. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...