I couldnt find the file pidesktop.deb. The webpage is really complicated.
I couldnt find the file pidesktop.deb. The webpage is really complicated.
Enrico Miglino wrote:
Christopher,
I am sorry but you are wrong in what you assert. Let me explain:
Formatting the SSD to Fat32 first isn't necessary though this can be a simpler way of allocating a drive letter to the device, and getting some software to acknowledge the device.
This is almost true but most of the GUI procedures want a flat pre formatted microSD or SSD or anything else to proceed with best reliability.
To be able to write system partitions to any device, the software needs its hardware identification handler, you could call this a pointer (though it may be more accurate to call it a file descriptor).
In Linux, this is /dev/sd<x> typically, and in Windows it is \Device\Harddisk#\DR#
Since Fat32 is a partition type, this is not a hardware identification handler, and software writing to the device shouldn't really care. I'm going to assume you're referring to Microsoft Windows here, and what is necessary by some software that isn't coded so well, is a drive letter (E:\ , F:\, etc.), so that the software can enumerate the device as it uses this as the handler, as opposed to the device name (\Device\Harddisk..etc). A device does not have to be formatted with a partition on it for it to have a drive letter.
Having a partition formatted to fat32, like on the Raspbian SDCard can confuse some software.
For example Win32DiskImager. If you have an SDCard with Raspbian installed onto it, Raspbian has two partitions, one with be an ext<x> based partition, and the other will be Fat32. With Win32DiskImager, if you try to over-write the SDCard with a new Raspbian image, it will complain that there's not enough storage space.
Win32DiskImager, being primitive, enumerates the drive letter allocated to the Fat32 partition and calculates the capacity of the partition, then saying "there's not enough space on this partition, I'm going to quit!" and yet, you could be working with a 16gByte SDCard.
The only solution in this case, is to delete the Fat32 partition and then mount the SDCard as a 'simple volume' using Disk Management, from the management console (mmc) and assign a drive letter. You can then use Win32DiskImager to write a full SDCard image to the device. At this stage, re-creating a Fat32 partition to the full size of the SDCard is superfluous because Win32DiskImager will calculate the capacity of the SDCard correctly.
This is where Linux tends to happily trump over Microsoft Windows as an OS, because it has such low level commands and it's a little harder to get this wrong, 'dd' doesn't care what's on the drive, it treats it as a device that you can throw data at, in fact, you can throw that data at any point in the sectors of the drive, though not always a great idea to do so.
I am not saying you're wrong. I'm saying that I'm not wrong either, and we're both correct.
Enrico Miglino wrote:
Also, https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/usb.md alludes that the ability to set the required 'bit' for the Raspberry Pi to boot from USB is not limited to the Pi 3 and is capable on every model of Raspberry Pi.
With a more detailed investigation it is not difficult to discover what the same firmware guys of the Raspberry Pi org says:
That's a good find, and to me it reads in a contradictory manner to what I saw 
I may be tempted to test it anyway, thanks! It's worth noting that the Raspberry Pi 2 v1.2 now runs the same processor as the Pi 3, so it will also be able to USB boot without an SDCard.
The point I ave cited you is that the "common" user, or newbie, not super experienced, does not know nothing more than follow the instructions. So as reported in the "official" (?) documentation using Etcher it can do it in the almost secure way.
By the way, it is interesting to ask "what is exactly the "Etcher" application? It is just a GUI multiplatform wrapper that depending on the operating system it uses dd or similar calls to do just the low level job in a more structured way to make life easier to the users 
About the fact that Pi2 and 1 will work, I am not 100% sure that the processor is the same. But what I am almost sure is that also the other processors should include a sort of boot selector. The deduction came form the field where these are also applied: the mobile devices. If you have time you can try. I suppose that they have not provided this as the boot eeprom firmware on the processor. I am curious to see it.
Enrico
Thank you for the clarification Christopher!
As a matter of fact the difference in processor was anyway a fact as I have at home all the three (four including the first PI prototype part of my personal museum 
). Then all the raspberry pi.org blogs point on the PI B3 the possibility to seriously manage the boot mode bit. There is also a good article on how the on-chip firmware has been upgraded to support this nice feature.
I have used Etcher for the first time when I have flashed the SSD for booting with the Raspbian jessie pixel version. In addition to DiskImager there is also PiBaker, very good for SD card flashing. The problem is that all these imager software only support SD cards or some kind of USB memory stick. Etcher instead has a "unsafe mode" that permit to flash any image on any device. Including your boot storage of the pc so it should be used with a lot of caution. But it is good for SSD and external HDD flashing.
Enrico
