so much so, that I tried the beta version of the Boot From MSD (mass storage device) changes the Pi folk blogged about recently.
TL;DR version: It didn't work for me because I messed up, but I found another solution that is pretty darn compelling in the process of trying it out.
First, I found the Pi blog post here <link>, and read it over about three hundred times because it was the kind of thing I've been fighting for years now. Then, in typical form I got on Amazon and ordered a solid state disk and a little box to hold it and adapt it to USB.
Wait, before you go off and do the same thing I did, check out the link above and read the rest of this post. Also, the reason I said to use my link is because it points to the 'official' post about the boot from MSD, there are a lot of copies out there on the web and some of them are wrong. Go to the real source and start from there. I won't go into the details of what to do since I would only be copying someone else's hard work and I might make a mistake that would screw you up.
Here's the hardware I'm using:
![]()
These things cost me about $35, and I'm sure I could have gotten them cheaper if I was willing to wait for a boat from Taiwan, but I wanted to try this out right the heck now.
I went into Raspberry Pi's github repository <link> for the instructions and followed them exactly on my Pi 3B, and of course, it didn't work. Not because the instructions were bad, but because, in exuberance, I ordered a USB 3.0 device. They specifically say they don't support USB 3 and I just ignored that when I looked for the stuff I needed. However, it impressed on me something that I had overlooked way back when I tried a USB stick to overcome the problems with SD cards.
You ONLY NEED TO BOOT FROM THE SD CARD !! You don't need to run with it. That means, you put the boot stuff on the card, boot from it, and then ... get ready for this ... you mount it READ ONLY so a power failure won't corrupt the card because of files left open when the little guy dies. If you don't write to the card, it won't get messed up.
Sure, there will be a thing or two to consider doing this, for example when I do an update-upgrade (shudder), it will probably fail if there are changes to the boot code. Fine, I'll just make a note to myself to remember to remount the boot file system RW before I do that; or more likely, I'll fix it after the upgrade fails with some obscure error message. I'm actually running one of my little machines this way right now and it seems to be doing fine, and it boots awesomely fast compared to the SD card.
I've pulled the power plug a few times to see what happens, and YES darn it, I managed to corrupt the file system on the SSD. But, and this is a really big thing to me, fsck fixed it and it just kept on keeping on. I hardly noticed the problem.
Let's think about this a bit more. I don't have to even think about the long tedious process of backing up the SD card any more. I just make a couple of copies of Raspbian lite on cheap little SD cards just big enough to hold it and stick them to the wall taped to a 3x5 index card with a clear label I'll remember later. The SD card dies because of some random act, I grab another card, plug it in, and away the Pi goes because all the stuff that really matters is on the SSD. I can also use this technique on any of the Pi's I have, even the oldest. You just need to be able to read the SSD to finish the boot process; I don't need a whole system on the SD card. An unexpected benefit of this is that you have a fully boot-able system on the SD card that you can use to repair something if you need to.
Here's the cmdline.txt from the /boot on my Pi3B:
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/sda2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
And the entry I have in fstab to set the boot to read only:
/dev/mmcblk0p1 /boot vfat ro,auto,user,exec,async 0 2
I'm not sure that this fstab entry is totally correct, but it gets the job done; root can't write to the boot partition. I keep two cmdline.txt files for backup in the /root directory: cmdline.txt.ssd for ssd boots, cmdline.txt.sd for sd card boots. I just copy whichever I need to cmdline.txt so I don't have to look up the weird name mmcblk0p1 each time I test something in this area.
To back up the SSD, just do a network 'dd' to a big disk somewhere else, or a file by file copy, rsync, something along those lines. I can even automate it now because the SSD is super quick and I'm not wearing it out the same as with an SD card. My little machine may be a little behind, but the data is stored on my NAS, and who cares if a log file got out of date. I'll definitely be looking into that in the next couple of weeks (well maybe).
I could totally eliminate power fail corruption for all the machines I want to someday have if I can come up with a house-wide power-fail shutdown idea that doesn't include $60 UPS devices out in the yard. Remember, my power goes out every time the weather sneezes, or a random drop of water falls from the sky. I've gone through several SD cards along the way. I tried a USB card to solve the problem, but the USB card died in a particularly annoying fashion <link>. I won't go that route again.
I want to step through the requirements for a UPS of some kind so you folks understand (and maybe suggest something):
1. cheap
2. It has to sense power failure and tell the Pi to halt while holding power on
for a minute or more while the Pi actually halts.
3. It has to turn power off to the Pi.
3. It has to sense power coming back, wait a bit for those messy power failures, and supply power to the Pi if it has turned the power to the Pi off.
4. Small
5. cheap
Requirement 3 is important because there is no power management on the Pi. The only way out of a halt condition is to cycle the power. Requirement 4 is important because the power can bounce around a bit and I don't want a bunch of half boots where the Pi has just enough time to start booting before the power goes out again.
I've thought a bit about a little Arduino to do this job for me. If I combine it with one of those cell phone power extenders and a good wall wart, I might be able to come up with something suitable.
Now, I'm going to check out the Chinese vendors for really good buys.
TL;DR version: It didn't work for me because I messed up, but I found another solution that is pretty darn compelling in the process of trying it out.
First, I found the Pi blog post here <link>, and read it over about three hundred times because it was the kind of thing I've been fighting for years now. Then, in typical form I got on Amazon and ordered a solid state disk and a little box to hold it and adapt it to USB.
Wait, before you go off and do the same thing I did, check out the link above and read the rest of this post. Also, the reason I said to use my link is because it points to the 'official' post about the boot from MSD, there are a lot of copies out there on the web and some of them are wrong. Go to the real source and start from there. I won't go into the details of what to do since I would only be copying someone else's hard work and I might make a mistake that would screw you up.
Here's the hardware I'm using:
These things cost me about $35, and I'm sure I could have gotten them cheaper if I was willing to wait for a boat from Taiwan, but I wanted to try this out right the heck now.
I went into Raspberry Pi's github repository <link> for the instructions and followed them exactly on my Pi 3B, and of course, it didn't work. Not because the instructions were bad, but because, in exuberance, I ordered a USB 3.0 device. They specifically say they don't support USB 3 and I just ignored that when I looked for the stuff I needed. However, it impressed on me something that I had overlooked way back when I tried a USB stick to overcome the problems with SD cards.
You ONLY NEED TO BOOT FROM THE SD CARD !! You don't need to run with it. That means, you put the boot stuff on the card, boot from it, and then ... get ready for this ... you mount it READ ONLY so a power failure won't corrupt the card because of files left open when the little guy dies. If you don't write to the card, it won't get messed up.
Sure, there will be a thing or two to consider doing this, for example when I do an update-upgrade (shudder), it will probably fail if there are changes to the boot code. Fine, I'll just make a note to myself to remember to remount the boot file system RW before I do that; or more likely, I'll fix it after the upgrade fails with some obscure error message. I'm actually running one of my little machines this way right now and it seems to be doing fine, and it boots awesomely fast compared to the SD card.
I've pulled the power plug a few times to see what happens, and YES darn it, I managed to corrupt the file system on the SSD. But, and this is a really big thing to me, fsck fixed it and it just kept on keeping on. I hardly noticed the problem.
Let's think about this a bit more. I don't have to even think about the long tedious process of backing up the SD card any more. I just make a couple of copies of Raspbian lite on cheap little SD cards just big enough to hold it and stick them to the wall taped to a 3x5 index card with a clear label I'll remember later. The SD card dies because of some random act, I grab another card, plug it in, and away the Pi goes because all the stuff that really matters is on the SSD. I can also use this technique on any of the Pi's I have, even the oldest. You just need to be able to read the SSD to finish the boot process; I don't need a whole system on the SD card. An unexpected benefit of this is that you have a fully boot-able system on the SD card that you can use to repair something if you need to.
Here's the cmdline.txt from the /boot on my Pi3B:
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/sda2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
And the entry I have in fstab to set the boot to read only:
/dev/mmcblk0p1 /boot vfat ro,auto,user,exec,async 0 2
To back up the SSD, just do a network 'dd' to a big disk somewhere else, or a file by file copy, rsync, something along those lines. I can even automate it now because the SSD is super quick and I'm not wearing it out the same as with an SD card. My little machine may be a little behind, but the data is stored on my NAS, and who cares if a log file got out of date. I'll definitely be looking into that in the next couple of weeks (well maybe).
I could totally eliminate power fail corruption for all the machines I want to someday have if I can come up with a house-wide power-fail shutdown idea that doesn't include $60 UPS devices out in the yard. Remember, my power goes out every time the weather sneezes, or a random drop of water falls from the sky. I've gone through several SD cards along the way. I tried a USB card to solve the problem, but the USB card died in a particularly annoying fashion <link>. I won't go that route again.
I want to step through the requirements for a UPS of some kind so you folks understand (and maybe suggest something):
1. cheap
2. It has to sense power failure and tell the Pi to halt while holding power on
for a minute or more while the Pi actually halts.
3. It has to turn power off to the Pi.
3. It has to sense power coming back, wait a bit for those messy power failures, and supply power to the Pi if it has turned the power to the Pi off.
4. Small
5. cheap
Requirement 3 is important because there is no power management on the Pi. The only way out of a halt condition is to cycle the power. Requirement 4 is important because the power can bounce around a bit and I don't want a bunch of half boots where the Pi has just enough time to start booting before the power goes out again.
I've thought a bit about a little Arduino to do this job for me. If I combine it with one of those cell phone power extenders and a good wall wart, I might be able to come up with something suitable.
Now, I'm going to check out the Chinese vendors for really good buys.