I would like to use my OrangePi zero as a g_masstorage(USB gadget). Successfully make OPI as a g_massstorage device based on [enter link description here][1]
[1]: https://android.googlesource.com/kernel/common/+/bcmdhd-3.10/Documentation/usb/mass-storage.txt.OPI successfully mounted in Ubuntu also Ubuntu PC detect the device as a storage device. But the issue is with Windows PC. The device detected and shows to format the storage device.. How to use the g_massstorage device in Windows? How to mount USB gadget for windows PC? Used to mount the OPI as
sudo modprobe g_mass_storage file=/dev/sda1 stall=0 removable=1 idVendor= idProduct= iManufacturer="MXTronics" iProduct="MXT USB Device" iSerialNumber=
I think, wrong FS type. If your /dev/sda1 is ext2\ext4 or something else linux fs type, your pc with windows will try to format it. Try to use ntfs file format, any other fs format that can be recognized by windows. There are good instruction https://linux-sunxi.org/USB_Gadget/Mass_storage
Related
I fully built fuchsia - and want to flash an usb device with it.
The correct command should be
fx mkzedboot /dev/sdb
fx mkzedboot /dev/sdb
/dev/sdb - DataTraveler 3.0
Changing ownership of /dev/sdb to erhard
[sudo] password for erhard:
Opening device...
Create new GPT partition table...
00000000-0000-0000-0000-000000000000
done
Create new partitions...
done
Writing zedboot for EFI
43049+0 records in
43049+0 records out
22041088 bytes (22 MB, 21 MiB) copied, 2.09618 s, 10.5 MB/s
done
Closing device.
It seems there are only 22MB copied - is that right?
What could be the problem?
If you want a "live usb stick" then fx make-fuchsia-vol is likely what you want
According to the documentation at Prepare a USB flash drive to be a bootable disk, fx mkzedboot only enables the flash drive to netboot for pave, so you must follow the instructions for pave.
I've installed Fuchsia into my USB flash drive without paving, using fx mkinstaller:
First, configure with everything
fx set workstation.x64 \
--with //bundles:tools,//bundles:tests,//bundles:kitchen_sink \
--ccache
Then, build
fx build
Run fx mkinstaller /dev/<usb_drive> in order to write the installer into an physical (or emulated) USB drive (usnig fx mkinstaller on a block device not connected through USB will fail)
Copy the USB flash drive into a disk image using dd. This is the "installer" disk image.
Create an image disk with the exact size of the USB drive. This is the target disk image.
Boot the installer using qemu-kvm, with the two disks images exposed as NVME. No network is needed for this step. EFI must be available; install ovmf following the instructions for your distro, or download the image directly.
sudo /usr/bin/qemu-system-x86_64 \
-monitor stdio \
-vga std \
-machine accel=kvm \
-m 4096\
-device nvme,drive=nvme0,serial=deadbeaf1,num_queues=8 \
-drive file=,if=none,id=nvme0 \
-device nvme,drive=nvme1,serial=deadbeaf1,num_queues=8 \
-drive file=,if=none,id=nvme1 \
-boot once=c,menu=on \
-net nic,macaddr=00:e0:4c:c2:85:01,model=rtl8139 \
-net user \
-rtc base=localtime \
-name "Fuchsia" \
-bios /usr/share/qemu/OVMF.fd
Inside the running Fuchsia, run installer and choose the right target device. Then, shutdown the VM. (unplug the USB flash drive if connected)
Once installed, boot the VM again (connect the USB if you installed there), removing the installer drive from the command line, and check what happens; try with other display drivers and framebuffer resolutions; try in a real machine.
However, once installed, the following happened to me, depending the machine settings:
On qemu with standard VGA display, the system boots, but the screen goes black.
On qemu with other display drivers (QLX, Vmware, etc) and in a real machine (my laptop), the screen freezes on the bootloader screen, and no debug information displayed.
In both cases, I'm able to access the shell through the serial port.
I am using Ubuntu 18.04, woeUsb, 15 GB usb3 Stick, windows 10 64Bit ISO to create bootable device. I found few tutorials how to do it, but I still get error.
Installation failed!
Exit code: 256
Log:
WoeUSB v##WOEUSB_VERSION##
============================== Mounting source filesystem... Wiping all existing partition table and filesystem signatures in /dev/sda...
wipefs: error: /dev/sda: probing initialization failed: No medium
found The command "wipefs --all "${target_device}"" failed with exit
status "1", program is prematurely aborted Unmounting and removing
"/media/woeusb_source_1532252869_8362"... You may now safely detach
the target device
I tried to format my USB several times but nothing worked. I used FAT32 format. Should I first convert it to NTFS?
I have the same issue and found the solution by unmounting USB drive in this way,
Go to the Disks and select your USB drive from the left side menu, and click on the icon shown in the below image to unmount USB.
The command line version of the tool works better in my experience:
woeusb --device Win10_1909_English_x64.iso /dev/sdX --target-filesystem NTFS
/dev/sdX might be different on your system such as sda sdb ..., make sure to check the device path using gparted or fdisk.
Make sure to set the filesystem to NTFS with --target-filesystem NTFS as FAT32 doesn't support large files.
I found that you have to run the software with sudo because it requires the use of gparted. If you don't do this it won't succeed and exit. I suspect this is your problem. I had a similar problem.
I had the same problem but after surfing internet I found something like this: **
sudo woeusb --device image.iso /dev/sdb --tgt-fs NTFS --verbose
**. So in the command image.iso is the OS you downloaded(or the path to it), while the /dev... is the USB device and type of format(NTFS). Just copy the command, change image.iso to the path of your image.iso and change the /dev/sdb to the name of your USB device and make sure you are connected to internet because when I ran the command it seems it communicated with GitHub. Good luck I hope this will help if you haven't found any answer.
There is no need to use any third party tool in the Windows operating system to create a bootable USB. Follow the below commands:
1. Plug your USB drive
2. Open Command Prompt
3. Type: diskpart .
4. Type list volume (this will show your drives)
5. Type sel vol h (h can be replaced with ur usb volume, can be anything g, h, i)
6. Type active
7. It will make your USB active, copy and paste windows files inside it.
I have a device that saves screenshots when you put a flash drive with exFAT/FAT32 and a specific directory tree in its USB socket. I want to livestream these screenshots to other devices as fast as possible via ethernet:
device -> flash drive -> ethernet
So I tried an ARM device (Orange Pi Zero) with OTG support and g_mass_storage kernel module which emulates an USB flash drive via USB OTG:
g_mass_storage - To have your Pi Zero appear as a mass storage device
(flash drive), first create a mini filesystem in a file on your Pi
with sudo dd if=/dev/zero of=/piusb.bin bs=512 count=2880 and set it
up as a fat32 filesystem with sudo mkdosfs /piusb.bin. Then, when
enabling it, add file=/piusb.bin stall=0 onto the end, for example
sudo modprobe g_mass_storage file=/piusb.bin stall=0.
(from https://gist.github.com/gbaman/50b6cca61dd1c3f88f41)
Next I mounted the emulated flash drive for testing purpose on a Laptop (Linux Mint 18) and the flash drive file via sudo mount /piusb.bin /mnt/ on the ARM device. But when I add new files/directories in one system it doesn't appear on the other. I have to remount the device/file first to refresh the files.
So is it even possible to read (and stream) the written data at the same time on my ARM device with g_mass_storage? Or is there a better way to solve my problem?
You should try to remount it.
sudo umount /mnt/
sudo mount /piusb.bin /mnt/
I'm trying to run a Docker container with access to a serial port on the host.
Here is what I did:
I used a Mac
Installed drivers on the host
(http://www.prolific.com.tw/US/ShowProduct.aspx?p_id=229&pcid=41)
Plugged in the device
Ran ls /dev/t* that returned
/dev/tty.usbserial - so it worked
Ran the container, docker run -it --privileged -v /dev:/dev
node:4.4.0 /bin/bash, and then ls /dev/t* inside the container which didn't return the /dev/tty.usbserial device...
I played a lot with different variations of parameters, but I haven't found the working one :)
Also the --device flag is not suitable for me since the device might be reconnected and the name could differ from /dev/tty.usbserial.
You can check if the script described in "Notification of new USB devices in docker container" (from Guido Diepen -- gdiepen) can help.
He too runs his container with the --privileged argument to allow it to access the devices. And he mounts the host directory /dev/bus/usb to the /dev/bus/usb directory within the container with the argument -v /dev/bus/usb:/dev/bus/usb when starting said container.
The script uses both inotifywait and lsusb to wait for devices to be (un)plugged and check if it was the device we are interested in.
The inotifywait will keep on listening to inodes create/delete events under the dev/bus/usb directory and will execute commands whenever an inode corresponding to a relevant device has been just created.
See also, once you have detected an plugged USB device, How to get Bus and Device relationship for a /dev/ttyUSB (not related to Docker, but still relevant).
As pointed by #pgayvallet on GitHub:
As the daemon runs inside a VM in Docker Desktop, it is not possible to actually share a mac host device with the container inside the VM, and this will most definitely never be possible.
I have an Amazon EC2 instance. I booted up a volume and attached it to /dev/sdj. I edited my fstab file to have the line
/dev/sdj /home/ec2-user/mydirectory xfs noatime 0 0
Then I mounted it (sudo mount /home/ec2-user/mydirectory)
However, running the "mount" command says the following:
/dev/xvdj on /home/ec2-user/mydirectory type xfs (rw,noatime)
What? Why is it /dev/xvdj instead of /dev/sdj?
The devices are named /dev/xvdX rather than sdX in 11.04. This was a kernel change. The kernel name for xen block devices is 'xvd'. Previously Ubuntu carried a patch to rename those devices as sdX. That patch became problematic.
https://askubuntu.com/a/47909