I started writing down the steps I took to set things up. It got pretty long, so I decided to write a setup shell script to do all the work. It'll come in handy when a new version of Raspbian or Pixel_x86 comes out and I need to make a new SD card. And of course it'll make it easier for my dear readers to do this themselves. The setup script should be well-documented (doesn't everyone say that?), so have a look at what I did.
I learned a lot about scripting partitioning software. Did you know you can call parted with parameters to do simple tasks such as add or delete a partition? Not documented is the fact that you can't do negative sizes, such as -4000, which means "4000 meg from the end of the disk". Which I of course needed to do. Parted thinks it's a parameter since it starts with a dash. So I had to pipe the command into parted using echo. Kind of makes the scripting ability useless.
This workaround was necessary because I decided to use a partition instead of an image file as a backing store for the mass storage gadget. Why? it should be a bit faster. Or so I imagine.
I also had to do some funny things to try and find the drive designation of the SD card. I didn't want to have the user enter this if at all possible, since it takes a fair bit of Linux experience to find this out reliably. I personally have no problem using dmesg for this, but then I've been doing this for quite a while.
I also ran into a bit of a weird problem - Pixel on a laptop behaves quite differently than a Pi when it comes to disk mounting and copying. First, when you eject a disk on the Pi using the desktop control, the disk can still be manually mounted. But on the laptop, when you eject, the disk disappears. The kernel no longer sees it. You have to unplug and re-plug it to get it back.
But there's a more vexing problem - if I make a new partition and then copy the Pixel_x86 iso to it I can only copy part of it. It seems as soon as I copy the first few sectors. which contains the partition table, the kernel recognises it as a kind of extended disk. And since this disk is marked read-only (because it's a DVD image), the kernel suddenly halts copying. I tried copying from the beginning of the disk with an offset, but couldn't get this to work either.
A Raspberry Pi doesn't exhibit this behavior. So you'll need an operating Pi to set things up instead of just using the laptop running Pixel_x86 from a DVD or flash drive. I was trying to avoid this since folks might not have one available. I don't feel too bad though, a second Pi is a handy thing to have when working with Pi Zeros.