Hello,

I am having an issue trying to get it to boot on both my Pi Zero and Pi Zero W.

I used a centos box with docker to build the sdcard.img then used win32diskimage to copy it to the SD card.

Can you confirm if this needs to be build on the PI or not?

Also would be nice if you just provided a blank image for us noobs out there.

Kind Regards,
Jason

This will probably be a 'long press', so we'll need to implement that.

Debugging some issues with mounting drives would be much easier if we could get a debug log even when no explicit error has occurred. This can probably just go under the 'Options' menu.

I really wish we could name each drive - even if it's limited to like 8 characters. Something to better remember which drive is which.

This is currently exfat

Some applications will only work with a usb drive that is not 'removable'. This is easily configurable via the configfs module, but we would need some way for the user to specify that a particular drive should not be shown as 'removable'.

Hi,
How about supporting HFS+ via the default menu when creating a new drive ?
CU Assetburned ;-)

It would be nice to be able to change VID/PID arbitrarily using a configuration somewhere convenient. Then you could spoof a Sandisk USB drive for example or something like that or some other specific device that was "supported/allowed"

Might have to add a 10K resistor on the RST line between the uC/PI and the Display. This will depend on the time the uC goes to a shutdown state, and the PI starts up. When the uC goes to shutdown state it pulls the line low causing the display to go off.

This could be useful for distinguishing between the drives. The trouble with putting the format there is that we won't know that it hasn't changed, so maybe just the size for now.

MacOS creates some files in the ISOs directory which clutters the pISO menu a bit. It would be best to just ignore things starting with a period.

Currently we select the new drive size in 10% increments, this should probably be more flexible

I've created the ISOS folder and copied over a Windows 8 iso, Ubuntu Desktop iso and Ubuntu Server ISO. I've followed the guide and activated the iso and when plugged into a running windows 10 OS I see the CD rom mount and the files come up. But if I try to boot from PISO, the computer doesn't see the image as a boot up option. I've tried two different computers and several different BIOS settings. I don't have a PISO error dump since there was no error. It just won't recognize as a bootable device. I set the drive up as fat when I first provisioned it. Shouldn't the PISO support this?

Only done cursory tests so far but not been able to use a pISO to boot an USB boot enabled Raspberry Pi. Only tried with a drive with IchigoJam BASIC4Rpi so far as it should have been the thing that would cause the least amount of problems as it's just files in a FAT32 partition.

Has anyone had any success booting a pi using pISO?

I copied the ISO from a ripped BluRay and a ripped DVD to the ISOS folder, but after mounting either ISO the computer where I plug in the pISO does not recognize the image as a DVD or a BluRay respectively.
I can however mount the standard disc, and with a virtual DVD/BluRay SW mount the ISOs from the ISOS folder, and then play them.
The pISO mounted BluRay ISO is not recognized at all and the pISO mounted DVD is reported a 'corrupt'

I'd like to see the format of each virtual drive listed on the right side of the drive listing in the main menu.

I.E.

Drive0 (NTFS)
Drive1 (EFS2)
Drive2 (EXFAT)

There is no way currently to remember which format I assigned to which virtual drive.

This is only possible if we can have multiple gadgets per UDC

Some users are reporting issues with windows isos only shows a single text file when mounted with the pISO. I need test this out.

Currently, as the users creates and deletes files on virtual drives, the 'Free' space on the side will always decrease. In order to determine how much free space is actually available, we need to fstrim the vdrives. This should be an option (an maybe should be done automatically from time to time).

We may be able to expose a usb ethernet interface to the host. Then they will (probably) dhcp lease. If we have a dhcp server, we can give a lease with our ip as the DNS server. Then they should be able to (on windows at least) go to something like 'piso' and it would hit the smb server on the pISO. I'd have to explore how this may work on linux/macos

Users should be able to see the version number of the pISO OS they are running somewhere.

Currently, I think the best approach is to just allow the pi to act as an FTP server for vdrives that have been internally mounted. Wifi connect should take the following approach:

1. Attempt to connect to a pre-configured network for some time interval (say, 20 seconds)
2. After a timeout, create a wireless AP to allow the user to connect to (or maybe just have a button to let the user choose when this should be active)

We could potentially use bluetooth to get keying info for do encrypted drives, but this would probably require creating an Android and IOS app which is probably not feasible prior to launch.

I don't see a good way to 'sync' drives with different filesystems, but we should be able to 'clone' a drive to a different fs by just copying everything we can. Obviously this will take a while if the volume is full, but could be an easy way to transfer a few files from one fs to another.

Let's say I have Drive1 mounted. As soon as I enable Drive2, Drive1 gets disconnected (with all the warnings on OS that do that) and afterwards both Drive1 and Drive2 are remounted. Is that really necessary? Would it be possible to just connect Drive2 additionally?

Some interest has been expressed in having an optional verification step for isos. This probably wouldn't be that hard to implement, if we just say for each iso, you can have a 'iso.hash' file. If the hash is present, then long-pressing the select button on mount the iso after checking the hash.

Title says it all, the pISO currently advertises itself as "buildroot" in the network. Why not change this to something more friendly like "pISO" or even have a setting for it in piso.config?

[herrold@centos-7 pISO]$ git clone [email protected]:herrold/pISO.git
Cloning into 'pISO'...
remote: Counting objects: 939, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 939 (delta 7), reused 14 (delta 5), pack-reused 923
Receiving objects: 100% (939/939), 3.28 MiB | 150.00 KiB/s, done.
Resolving deltas: 100% (611/611), done.
[herrold@centos-7 pISO]$ ls
pISO
[herrold@centos-7 pISO]$ cd pISO/
[herrold@centos-7 pISO]$ man sdimage
No manual entry for sdimage
[herrold@centos-7 pISO]$ make sdimage
/bin/sh: ./utils/should-rebuild: No such file or directory
cd "/home/herrold/vcs/git/foss-upstreams/pISO/pISO/buildroot" && cp "configs/raspberrypi0_defconfig" ".config"
cp: cannot stat ‘configs/raspberrypi0_defconfig’: No such file or directory
make: *** [update-config] Error 1
[herrold@centos-7 pISO]$ pwd
/home/herrold/vcs/git/foss-upstreams/pISO/pISO
[herrold@centos-7 pISO]$

The virtual volumes should show up with the same name as is shown on the screen.

http://pid.codes/howto/

There is virtually no documentation for pISO at the moment. Things that should be documented:

• How to physically attach the pISO to a Pi Zero
• Installing and updating the pISO operating system
• Creating/Deleting new virtual drives
• How to store disk images in virtual drives and how to mount them
• WiFi Setup and Usage
• How to take snapshots (and the performance implications)
• pISO config file and options

Currently, the error screen does not tell users how to actually report the issue. It should link to something like 'https://piso.support/issue' which would redirect to the wiki page on reporting issues.

Is it possible to password protect the volumes on the pSIO? I’m browsing the documents but could not find anything. Also would it support an external hard drive attached to the piZero?

on plug in of piso to Windows 10 Device, error in device manager states: A request for the USB device descriptor failed.

For performance reasons, we don't write the log file to the sd card. This is typically fine because when an error occurs, we will copy the log file in to the debug tar file. However, if pISO just hangs for some reason, there will be no way for us to debug the issue.

We should probably have a way to configure debugging to the sd card. That way we should be able to track down the issue if it is reproducible.

A user has reported difficulty copying larger files (>200MB) via SMB.

When storing .iso files in the ISOS folder on a drive from macOS it will create ._xxxxxx.iso files (macOS specific stuff). Would it be possible to hide those files from the menu? E.g:

renzosimac:~ renzo$ ll /Volumes/Drive1/ISOS
total 635072
drwxrwxrwx 1 renzo staff 32K Oct 5 16:36 .
drwxrwxrwx 1 renzo staff 32K Dec 31 1979 ..
-rwxrwxrwx 1 renzo staff 4.0K Oct 5 16:37 ._gparted-live-0.32.0-1-amd64.iso
-rwxrwxrwx@ 1 renzo staff 310M Aug 26 11:37 gparted-live-0.32.0-1-amd64.iso

Both of these show up in the pISO menu. Of course only the 310M version is bootable.

The fact that these will naturally corrupt if the drive reaches 100% capacity seems like it may make it impractical, but there may be a workaround

My piso is delivered. But I have two broken pins on the board (power pins)

When we connect to an existing wifi network, we show a screen with the IP address we were leased, but we should also just show the address in parentheses after the network name.

I'm able to create and use drives just fine, however when trying to mount ISO's I get the error:

The disk you inserted was not readable by this computer.

Working on OSX Mojave. Have tried mounting ISOs on EXFAT and FAT32 drives. Believe I'm working with pISO v1.0.1.

Some users have more specific samba configuration requirements. The easiest way to work with this would be to just allow users to copy the smb.conf file to the root of the SD card. Then, before we start the server, we can copy that file to use as the config. This will give users essentially arbitrary control of samba configuration.

Some interest has been expressed in allowing a user to 'import' the contents of an existing flash drive to a virtual drive.

It would be nice to be able to toggle a volume as read-only

When I add a total of three wifi.client entries in piso.config, all three show up in the wifi menu. However only the first entry works. Selecting the second or third client entry results in a connection using the first entry. If the first entry is for an AP that is out of range, the connection fails with a error indicating it was unable to get an IP address. So selecting other wifi.client entries seems to do nothing, it only attempts connections with the first entry.

piso v1.0.2

I received both the pISO’s I had ordered, but only one is working.
Tha bad one boots up ok, but the ‘down’ button does not work, and then randomly it will flip the screen upside down.
After the flip the new ‘down’ button works, but then of course the ‘up’ button now does not work.
I have tried to swap the pISO to my other Raspberry Pi zero, but the issue moves with the pISO.
Please advise.

For safety, we should probably enable thin_check and try to have it auto-repair any corrupt metadata.

Currently, input feels a bit laggy, and we sometimes drop inputs. This can almost certainly be fixed by changing things around a bit in controller.rs.

Testsystem: macOS 10.13.6, latest pISO OS compiled from master.
Let Drive2 be single partition ExFAT.

The documentation says:
Note however, that a given virtual drive cannot be in use in two places at once (as this would cause corruption). So you must 'unplug' the virtual drive (by selecting it from the main screen) before it is visible in the FTP or SMB servers.

Drive2 was visible via SMB while plugged in. However, as the documentation correctly states: data copied via WiFi in this state ends up in limbo - presumably the folder where the drive would be mounted on the pISO to serve it via SMB.

Could pISO check if a drive is plugged in and not serve it via SMB when that's true? Would be more user friendly.

Currently, the flash procedure can cause strange things to happen if a drive has already been flashed once. We should probably prevent that.