Hi gdenicolas ,

You don't need the debian file to boot from the SSD. In the user manual is a step by step guide and explanation on how to set this up:

Pi Desktop User Manual_EN_Rev3.2-FINAL.pdf

I've asked internally about the debian file, and I've read through the manual where there's some typing errors that need to be fixed (eg. capitalization of linux commands).

Feel free to ask me any questions on this as I've been working with this add-on board (and have one sat on my desk).

Several questions:

1 gparted says my ssd card is not partitioned.  Should I partition it first or clone uCD card to SSD and then enlarge the partition?

2. I did find and download pidesktop.deb. Is this the better way?

3. Must the mCD card be removed to boot from the SSD?  Or can the 32 Gb mCD  be used for data?

4. My current Debian desktop allows resetting the BIOS boot order so can have the boot sector on several hard drives and choose which to boot from. Is this possible? 

Hi Thomas,

gparted says my ssd card is not partitioned.  Should I partition it first or clone uCD card to SSD and then enlarge the partition?

None at all. Just format your ssd as Fat32 then when you create the image over it it is properly partitioned

If you download and install the last Raspbian pixel image (I strongly suggest) at the first boot you see a screen saying that it is resizing the partition automatically. So no problem to enlarge the partition after.

Anyway if the partition is not automatically resized it is one of the options of the command raspi-config

I did find and download pidesktop.deb. Is this the better way?

As the .deb extension of the file says, it is just a sort of program that I don't know but I can say for sure that it is not essential to the entire procedure. For now you can start ignoring it.

Must the mCD card be removed to boot from the SSD?  Or can the 32 Gb mCD  be used for data?

None at all You should flash the SSD directly as it is a common micro SD card. No matter of the size (mine is 120 Giga). you should flash it with Etcher that is specific for this role, running on any platform (Linux, OSX and Windows). With this program you can flash any image on any external device. If Etcher refuses to flash your SSD as it is recognised as a HD instead of a external (removable) device, from the Etcher settings set the unsafe mode. Warning: in unsafe mode you can flash any img file also on your main pc hard disk so double check that you are selecting the correct device.

My current Debian desktop allows resetting the BIOS boot order so can have the boot sector on several hard drives and choose which to boot from. Is this possible?

As far as I know the process is specific for the Raspberry PI B3 that has a command supporting the boot device bit set changed from the microSD to a USB device (the SSD USB connected disk).

For details and links take a look to my previous posts in this discussion.

Enrico

Enrico Miglino wrote:

 

Hi Thomas,

 

gparted says my ssd card is not partitioned. Should I partition it first or clone uCD card to SSD and then enlarge the partition?

None at all. Just format your ssd as Fat32 then when you create the image over it it is properly partitioned

 

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.

If you're using Linux you can use the command 'dd' to write to the SSD with an image file, or from a microSD card. If you're using Windows then you can allocate a drive letter to the SSD and then do the same with software such as Win32DiskImager, or you don't need to assign a drive letter if you're using drive cloning software such as Norton Ghost.

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.

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 this we should add the fact that USB memory stick, microSD and SSD most of them are Fat32 pre-formatted for maximum compatibility with all the platforms (I guess they don't include Linux Raspberry PI!). So first I have mentioned - deliberately - only the most reliable today available for free Flashing GUI. It is true (I say) that dd on Linux and Mac will work but this is not the default method not high skilled users approach to flash an image. Second, just because most of the USB storage devices are sold formatted Fat32 I had to keep away the doubt if the storage device should be formatted before in some strange way.

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:

In Raspberry PI Bootmodes documentation page on GitHub you can read that an alternative boot for PI 1, 2 and zero is available (under download) as a workaround for some non-booting devices from SD card. In particularly they say:

For the original Raspberry Pi and the Raspberry Pi 2 (based on the BCM2835 and BCM2836 devices), and in situations where the Pi 3 fails to boot, there is a new method of booting from one of the new boot modes (MSD or ethernet).

that is not a normal, regular available procedure.

The Raspberry pi org blog post you mention is just a non-technical information (more attention should be paid to what they write, the PI3 reference is missed!) and it is non-relevant to find a good procedure.

Instead if you read a more technical reference documentation about the PI Booting modes in the specific tutorial, always on the same site

PI 3 BOOTING PART I: USB MASS STORAGE BOOT BEThttps://www.raspberrypi.org/blog/pi-3-booting-part-i-usb-mass-storage-boot/

you can read:

Will it be possible to boot a Pi 1 or Pi 2 using MSD?

Unfortunately not. The boot code is stored in the BCM2837 device only, so the Pi 1, Pi 2, and Pi Zero will all require SD cards.

So as I stated before IMHO it is just a question of hardware to which we can't workaround in any way.

Enrico

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 this we should add the fact that USB memory stick, microSD and SSD most of them are Fat32 pre-formatted for maximum compatibility with all the platforms (I guess they don't include Linux Raspberry PI!). So first I have mentioned - deliberately - only the most reliable today available for free Flashing GUI. It is true (I say) that dd on Linux and Mac will work but this is not the default method not high skilled users approach to flash an image. Second, just because most of the USB storage devices are sold formatted Fat32 I had to keep away the doubt if the storage device should be formatted before in some strange way.

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:

In Raspberry PI Bootmodes documentation page on GitHub you can read that an alternative boot for PI 1, 2 and zero is available (under download) as a workaround for some non-booting devices from SD card. In particularly they say:

For the original Raspberry Pi and the Raspberry Pi 2 (based on the BCM2835 and BCM2836 devices), and in situations where the Pi 3 fails to boot, there is a new method of booting from one of the new boot modes (MSD or ethernet).

that is not a normal, regular available procedure.

The Raspberry pi org blog post you mention is just a non-technical information (more attention should be paid to what they write, the PI3 reference is missed!) and it is non-relevant to find a good procedure.

Instead if you read a more technical reference documentation about the PI Booting modes in the specific tutorial, always on the same site

PI 3 BOOTING PART I: USB MASS STORAGE BOOT BEThttps://www.raspberrypi.org/blog/pi-3-booting-part-i-usb-mass-storage-boot/

you can read:

Will it be possible to boot a Pi 1 or Pi 2 using MSD?

Unfortunately not. The boot code is stored in the BCM2837 device only, so the Pi 1, Pi 2, and Pi Zero will all require SD cards.

So as I stated before IMHO it is just a question of hardware to which we can't workaround in any way.

Enrico

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

Enrico Miglino wrote:

 

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

The Pi 1 uses the BCM2835 and the Pi 2 v1.1 uses BCM2836. The Pi 2 v1.2 uses BCM2837 which is the same as the Pi 3.

I'll check out Etcher, looks like it was mentioned as part of MagPi https://www.raspberrypi.org/magpi/pi-sd-etcher/  , thanks! There's also DiskImager which I happened upon: https://github.com/DynamicDevices/DiskImager

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