Re: pendrive clone impossible ?
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, ... ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: pendrive clone impossible ?
On Sat, 30 Nov 2019 22:08:21 +0100, Tomasz CEDRO wrote: > I have to clone a pendrive, the same one to another almost the same > (number of sectors differs a bit). The problem is that DD does not > seem to do the job. It always worked for me. > > Also I am not really able to clone the MBR: > 1. dd if=/dev/da0 of=/dev/da1 bs=512 count=1 does not copy anything. What is the error message that dd provides? > 2. dd if=/dev/zero of=/dev/da1 bs=512 count=1 zeroes the mbr. > 3. dd if=/dev/random of=/dev/da1 bs=512 count=1 randoms the mbr. > 4. dd if=/dev/da0 of=da0.mbt bs=512 count1; dd if=da0.mbr bc=512 > count=1 does NOT copy the mbr. The last command seems to be a bit "damaged", I think it should read (separated into two commands for better readability): dd if=/dev/da0 of=da0.mbr bs=512 count=1 dd if=da0.mbr of=/dev/da0 bs=512 count=1 Again, what is the error message of the 2nd dd command? > 5. mdconfig -a -tvnode da0.mbr; dd if=/dev/md0 of=/dev/da1 bc=512 > count=1 does put the data into mbr, but still da1 seems to have no > partitions!!! Have you tried copying more than just the first 512 bytes, let's say, the first whole MB? Of course the rest of the partitions would be "incomplete" and therefore not readable, but you should at least get the partition information when you use gpart or ye olde fdisk to read it. > While size of the drives differs a bit, the last partition contains > FreeBSD LiveCD image and is much smaller than the partition so it can > be truncated with no problem because there are zeros after. That should be no problem. Partitions can always be smaller than But... you're mentioning a FreeBSD Live CD image. Maybe that one is dedicated, i. e., doesn't actually have any partitions with the meaning of "DOS primary partitions" (which is what gpart or fdisk would list, as mentioned above). However, at least gpart should show at least _some_ information, or you use "disklabel /dev/da" and compare source and target data. In case of a dedicated partitioning (with partition meaning an _actual_ partition in the context of a BSD label, "the thing with the letters"), you should at least find one partition (the "a" partition, bootable). So it's no entirely clear if you try to deal with a MBR disk, something dedicated, or GPT? Everything is possible. :-) > Does GEOM in any way prevents me from using disk that has corrupt MBR? That is possible. Try "sysctl kern.geom.debugflags=0x16" which was, at least in the past, often a way to make things work again. :-) > Why I cannot write a MBR from a file but I can from a md0? To dd, a virtual node shouldn't be needed to operate on MBRs. The if= and of= parameters will (should!) accept plain files just like real devices. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB-C smartphone does not detect correctly as UMS
On Sun, 14 Oct 2018 18:57:48 +0200, Tomasz CEDRO wrote:
> I have problems detecting a smartphone over USB-C - at first it only
> changes over the USB, then I switch it to be a USB Mass Storage, but I
> see no disk.. the same with different modes (i.e. Media Transfer,
> Picture Transfer, etc)..
In "mass storage" mode, a normal USB-backed da device should
appear (this is not the default for smartphones). Until all
involved stages of the device connection have been secured,
no da device will be accessible for tasks like mounting.
> DMESG shows only device connected and disconnected in a loop..
This seems to point to the core problem - a connection
problem.
> What is the problem here? VID/PID is unknown to the system or it does
> not present itself correctly as known USB endpoint?
This should not matter. Especially for PTP ("media transfer" modes)
a normal ugen device usually is sufficient.
> Any hints appreciated :-)
Check both the cable and the USB port on the computer.
Judging from your description, a connect/disconnect loop
suggests a connection problem. Also make sure your cable
is compatible (!) with both your device and your computer.
Backwards Compatability. The physical USB-C connector
isn't backwards compatible, but the underlying USB
standard is. You can't plug older USB devices into
a modern, tiny USB-C port, nor can you connect a
USB-C connector into an older, larger USB port. But
that doesn't mean you have to discard all your old
peripherals.
Source:
https://www.howtogeek.com/211843/usb-type-c-explained-what-it-is-and-why-youll-want-it/
I'm not sure I'll it... ;-)
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB Device self-umount
On Tue, 26 Sep 2017 22:52:28 +0200, Tomasz CEDRO wrote: > I will have to see how Windoze handles ATAPI EJECT, maybe that could > bring some insight on how to umount ejectable media triggered by the > device-eject-button-press.. Hmmm... I don't think this is what happens. ATAPI EJECT is issued by the OS (ATAPI device driver) and the device simply ejects. If this action is "prefixed" with an unmount() call and a certain delay, everything is well. This is how a typical GUI file manager on Linux or FreeBSD works. But pressing the device's eject button will simply eject the media. Subsequent TUR inquiries by the OS will result in "device not ready", and that may cause the umount() call, but _after_ the device has been removed. > As for now the device reports CHECK-CONDITION to mark media missing, > then reboots and re-appeares, but that causes "device not cleanly > unmounted" warnings on macOS for instance.. Of course it does. :-) With filesystems mounted read-only, this typically isn't a problem, but those with read-write access might be left in an inconsistent state, and depending on the OS, cannot be mounted again (or require a run of fsck, or in case of "Windows", a kind of "repair" that often leads to data loss and corrupted files). Examining the USB traffic and checking for the CAM packets exchanged between the device and the OS could help you find a way to implement the impossible. ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
Re: USB Device self-umount
On Tue, 26 Sep 2017 16:30:48 +0200, Tomasz CEDRO wrote: > The question is how to gracefully self-umount from a device point of > view in a way not to confuse automounter and/or usb / mass storage > drivers? Is there any way of doing that in SCSI+USB? Something like > CD-ROM eject, then device removal.. This is a _very_ good question of high relevance which hasn't been solved across many operating systems. :-) Basically, a normal (clean) unmount can only be initiated by the OS. You can program the controller (on the USB device) to disconnect on its own, but that doesn't cause the OS to call unmount(), it just makes the device disappear. One thing I could imagine is the use of SCSI status messages and a modified (!) storage access driver in the OS which could act upon a specific status code with a call to unmount(), but that is, as far as I know, not implemented yet anywhere. The primary problem with disconnecting is that it happens _before_ the unmount() call, and keep in mind that unmounting also requires some time. The OS can issue a certain direct access action, but it's up to the device to perform that action. Until it has successfully been performed, the device may not be deconnected. Timing is hard. :-) For CD-ROM, or optical media in general, it's not a problem because it's read-only. The CAM EJECT command - again issued by the OS, not by the device -, when performed _before_ unmount, leaves the OS in a problematic state: Something is still mounted, but it doesn't exist anymore. Okay, umount -f, no damage done. But with read-write media such as USB direct access storage... well... that looks much more complicated. That's why you alway unmount first, then wait, then disconnect. Sorry I couldn't provide more helpful suggestions... ;-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-usb@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
