This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
How to set up to boot OpenPlotter from an SSD disk
#1
Hi,
I'm coming towards the end of my OpenPlotter build (yes I will document and post when done) but I have one major hurdle left.

I have incorporated an SSD Disk over USB in my build and want to boot from that one instead of from the SD card (yes I know how to tell my RPI-3 to boot from USB).

I downloaded etcher (to my PC) to write an image to the SSD (I think I've understood how to do that).

My challenge is that I need a valid image and Etcher refuse to use the OpenPlotter download that I also copied to my SD card (as per a normal OpenPlotter install). I assume that isn't a plain image so that's why it fails.

I have just installed a fresh OpenPlotter to my SD card and am running the update to the latest version right now. Once this is done, can I copy that image any way to my SSD or how should I go about doing this. I'm totally lost unfortually.

Can I do this on my PC (I'm no Linux wizard to say the least...) or can I mount my SSD (currently fresh without any file system) to my RPI and copy my SD image to the SSD - HOW??

Does anyone know the easiest way fwd??

BR
Lars
Reply
#2
(2018-04-17, 05:17 PM)LarsD Wrote: Hi,
I'm coming towards the end of my OpenPlotter build (yes I will document and post when done) but I have one major hurdle left.

I have incorporated an SSD Disk over USB in my build and want to boot from that one instead of from the SD card (yes I know how to tell my RPI-3 to boot from USB).

I downloaded etcher (to my PC) to write an image to the SSD (I think I've understood how to do that).

My challenge is that I need a valid image and Etcher refuse to use the OpenPlotter download that I also copied to my SD card (as per a normal OpenPlotter install). I assume that isn't a plain image so that's why it fails.

I have just installed a fresh OpenPlotter to my SD card and am running the update to the latest version right now. Once this is done, can I copy that image any way to my SSD or how should I go about doing this. I'm totally lost unfortually.

Can I do this on my PC (I'm no Linux wizard to say the least...) or can I mount my SSD (currently fresh without any file system) to my RPI and copy my SD image to the SSD - HOW??


Does anyone know the easiest way fwd??

BR
Lars
Hi, I am in this process actually (PiDesktop). It seems OP system is bit ackward, maybe due to NOOBS, as all recipes on Element14 have failed so far...
I'am trying to proceed as indicated in instructables.com  (with dd).
Anyhow, it seems you will need an img file,
best tools to be used on a windows station are SDFormater and Win32DiskImager.
SDFormater allows to format volumes larger than 32G with FAT 32 (Windows would refuse) ;
Win32DiskImager will create an img file from your SD card, (or burn an img file to any card if it is large enough !)
Take courage ...
Cordialement
Didier B
Pi4, SSD USB3, OP 3.0 Touch SK 3.2.1 OpenCPN  5.8.4 :  Thank you  Thank you  Thank you


Reply
#3
I use an SSD, and tried for quite a while to get my system to boot directly from it. I could never get it to work - as Didier says there is something about NOOBS that prevents it. So, I installed a new system on an SD card and copied the root partition to the SSD using the dd command. You'll then need to expand the partition to the full size of the SSD. Then you need to make sure that you have configured cmdline.txt on the SD card to point to root on your SSD ("root=/dev/mmcblk0p2" to "root=/dev/sda2" - it is also possible to point to a PARTID if you prefer).

You'll have to leave your SD card plugged in at all times, but it only gets used briefly at boot. After that, your SSD will be used for everything else.

Hopefully if we can get OP just as an image, we can actually set up the system to boot directly from USB, but for now this work-around is fine, and it uses the SD card very little.
Reply
#4
(2018-04-20, 02:09 PM)abarrow Wrote: You'll then need to expand the partition to the full size of the SSD.

I got that Raspbian answer  : "can't expand. This is not an SD card !" 
An attempt to expand using gparted resulted in a kernel panic at next reboot ...
I am stuck at this point now. I'm opening a thread PiDesktop in "How I did it" to share that adventure...
Cordialement
Didier B
Pi4, SSD USB3, OP 3.0 Touch SK 3.2.1 OpenCPN  5.8.4 :  Thank you  Thank you  Thank you


Reply
#5
Unfortunately, you can't expand the partition using Raspbian, you have to use a disk tool like gparted.

Steps (from memory - apologies if it isn't perfect):
1. On an SD card, boot OP NOOBs 10 and upgrade everything to the latest version. Reboot.
2. Open a terminal. enter "mount". You'll see a list of mounted partitions on your SD card. It will probably be something like:

Code:
pi@openplotter:~ $ mount
/dev/mmcblk0p7 on / type ext4 (rw,noatime,data=ordered)
devtmpfs on /dev type devtmpfs (rw,relatime,size=468148k,nr_inodes=117037,mode=755)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,mode=755)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
mqueue on /dev/mqueue type mqueue (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
/dev/mmcblk0p6 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=94552k,mode=700,uid=1000,gid=1000)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/mmcblk0p5 on /media/pi/SETTINGS type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)
The "/dev/mmcblk0p7 on / type ext4 (rw,noatime,data=ordered)" line is the important one. That is the partition you are moving to the SSD. 

3. Plug in your SSD. What I like to do is run the command "tail -f /var/log/syslog" BEFORE I plug it in, then I can watch the output and see what device was selected for the SSD, Most likely it is going to be /dev/sda1 or /dev/sdb1... something like that.

4. Assuming you originally booted from an OP distribution, now you can copy your root partition (in this example /dev/mmcblk0p7) to your SSD (in this example /dev/sda1). It will take a few minutes to complete. Be patient.
Code:
dd if=/dev/mmcblk0p7 of=/dev/sda1 bs=1M

5. After it's done, reboot to clean up.

6. Now you need to expand the partition on the SSD. First install gparted if it isn't already:
sudo apt install gparted

7. Then run it. You'll need to have a screen attached to your RPI, as gparted is a graphical tool. I'm sure there is a command line way to do this in parted, but I never bothered to learn it.
8. You should see a window come up showing the partitions on your SD card. The pulldown in the upper right will give you the opportunity to look at your SSD.
9. You should see one partition there, the one that you just copied from your SD card. Select it, unmount it (right-click pull down), then in the partition menu item at the top, select "Resize/move". You'll get a window with a slider on the top that you can move to the maximum size available on your SSD. Select what you want and execute. It might take a while.
10. Reboot
11. In your terminal, run "sudo nano /boot/cmdline.txt"
12. Change the "root=" phrase to point to the new partition on your SSD (e.g. "root=/dev/sda1") and save.
13. Reboot, and you should be using the SSD with it's new size. If you want to know what size you have now, open a terminal and run "df".

Hopefully this works for you. As I said, I'm doing this from memory, so you might have to fiddle around a little with the  steps to get it to work.

There is one thing you should be aware of. Using /dev/sda or /dev/sdb to identify an external USB drive isn't always reliable. There is a chance that if there is another drive plugged in, device names won't be consistent after a reboot. The way to fix this is to use the PARTID of the partition on the SSD. That's something I definitely can't do from memory! If this gets to be a problem for you, let me know and I'll try to dig up the process for determining the PARTID and using it in cmdline.txt.

Andy
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)