Raspberry Pi Home Server v2: Booting from the hard drive

Note: This post is part of a series. Each post builds on the previous ones. If you are just trying to add one thing to an existing system that was not built following this series, then I cannot promise that these instructions will work for you, although they probably will. If you’ve started from something other than a non-NOOBS Raspbian image, then you’ll probably need to adjust for that.

Please refer to the series Introduction for a list of all the different posts in the series.

Self-Promotion: I have recorded this series as a screencast for Pluralsight:
If you have a Pluralsight subscription, please consider watching it. Reading the instructions is one thing, but watching it done demystifies the whole process.

Thank you!

Running the Raspberry Pi off of an SD card is simple, affordable, and very convenient. SD cards are also very small compared to hard drives, though, and they can only be written to a finite number of times. That number is ridiculously large, but it can still be used up faster than you think by things like virtual memory swap files which are written and re-written constantly.

If you plan to run this server 24/7 and actually use it, you’re probably going to want something a little more robust. My current setup is using a 120GB SSD for the system drive. I’m using an SSD because it can be powered entirely from the Pi’s USB port. I could have gone with something smaller, both storage-wise and physically by buying a small MSata drive and an adapter, but in the end it was cheaper to buy a normal 2.5″ SSD and put it in a case I already had.

This SSD has two partitions on it. The first is the “os” partition, which I left free back in the post “Adding a Hard Drive“. The second is my “data” partition, and holds information about my collection such as MiniDLNA’s database. I don’t actually put my media files or public share on the data partition anymore. My public share now lives entirely on an external RAID enclosure. In the original version of this post, I used the RAID box as the system drive, but over time I have discovered that RAIDs don’t work very well in this capacity, so I just use the RAID for my shares now. Everything that is the Raspberry Pi Home Server itself lives on the SD card and on the SSD.

Your setup doesn’t need to have as many moving parts, though. A typical Raspberry Pi Home Server setup might consist of a Raspberry Pi attached to a single, very large, hard drive. You can get 5TB external drives for under $150 these days. You only need to partition off a small space for the Pi to boot from, and the rest is yours to store most, if not all, of your stuff. This is how my CrashPi works.

Booting from a hard drive

Okay, I’ll level with you. You can’t actually boot entirely from the hard drive, at least not yet. The Raspberry Pi 3 has a USB boot mode, but it’s still considered experimental at this time and you have to do some tweaks to even make it available. You can boot mostly from the hard drive today though, and it should be easy enough to adapt this post in the future when the Pi 3’s alternate boot modes are considered finished.

When the Raspberry Pi boots up, it looks to the first partition on the SD card for instructions on what to do next. That boot partition contains just a tiny piece of the boot process. You can easily move all the stuff that comes after that first step to a different device, such as the external hard drive. All that stays behind on the SD card is a very small boot partition, everything else moves to the hard drive.

The resulting system should run faster and smoother, and you won’t be using up your SD card’s limited number of write cycles on high-frequency stuff like a virtual memory swap file.


This article would not have been possible if not for others that went before me. In particular, Ted Hale’s article at http://raspberrypihobbyist.blogspot.com/2013/07/running-from-external-hard-drive.html is pretty much the blueprint I started from. In turn, that article was based on a forum post by “Rattus” at http://www.raspberrypi.org/phpBB3/viewtopic.php?f=26&t=10914&p=129474&hilit=resizefs#p122476.

I’ve added my own bits, such as consulting the boot/cmdline.txt file rather than simply assuming the root file system’s location, using UUIDs to identify the partitions, and expanding the existing swap file rather than creating a separate swap partition.

I’ve turned these resources into a walkthrough that matches the rest of this series, but I wanted to at least point out where my source material originated.

Shut down services

We’d like as little to be going on with this partition as possible while we’re copying it. If you have another Linux system, or another Raspberry Pi handy and a USB adapter for your SD card, then your best shot is to let another system do this copy, but for this tutorial, I’m assuming you only have the one Pi available. To make sure things are as “quiet” as possible, we’re going to want to exit the desktop, shut down any of the background services we’ve installed, and do the copy from the command line.

First, let’s boot to the command line. If you’ve configured the Pi to boot to the desktop, then unfortunately there’s no option to simply exit the desktop, so we’ll need to tweak the configuration first. Use the desktop configuration tool or raspi-config to set the pi to boot to the command line.


Reboot the Pi, and connect via SSH using a tool like PuTTY, or connect the Pi to a monitor and work directly from the Pi. I’ll be using PuTTY for this demo.

Once you’re logged in, shut down any of the services you’ve installed so far. For me, that’s Samba, MiniDLNA, OpenVPN, Resilio Sync, and NUT. If you have any other services like CrashPlan or Transmission running, you’ll want to stop those too.

sudo service samba stop
sudo service minidlna stop
sudo service openvpn stop
sudo service btsync stop
sudo service nut-monitor stop
sudo service nut-client stop
sudo service nut-server stop
sudo service nut-driver stop

We want as little activity going on as possible while we clone the OS partition.

Copy the old root partition to the new drive

The file /boot/cmdline.txt specifies the location of the root filesystem. You’ll need to edit this file later in order to boot from the hard drive, but for now, you just need to know for sure where the root filesystem currently resides. Show the cmdline file’s contents like this:

cat /boot/cmdline.txt


The part immediately to the right of “root=” specifies the device and partition that holds the root filesystem, and that’s the partition whose contents you need to move to the hard drive. In my case, it says “mmcblk0p2”. If you started from a raw Raspbian image, then yours probably says the same thing. I can’t guarantee that the default Raspbian image might not change in the future though, so it’s best to check.

Copy the existing root partition’s contents to the new 16GB partition (sda1) on the hard drive, changing the highlighted part to match the current root filesystem path from above.

Important: Be very careful here. Make sure that sda1 is the partition you set aside for the OS. If you configured your server differently, then double-check before continuing.

sudo dd if=/dev/mmcblk0p2 of=/dev/sda1 bs=32M conv=noerror,sync

This can run for quite a while, depending on how large your SD card is. Unfortunately, the dd command doesn’t give you any kind of feedback. In this case, no news is good news. As long as the drive appears to be busy, then keep waiting.

Here’s what that all means:

  • “dd” copies things
  • “if” specifies the input file, in this case an entire partitions
  • “of” specifies the output file
  • “bs” specifies how many bytes to copy in one chunk, here it’s 32 MB
  • “conv” specifies how to convert things as they are copied
    • noerror says to continue if anything goes wrong
    • sync does some padding during the copy

When the copy process eventually finishes, check the target partition on the hard drive for errors.

sudo e2fsck -f /dev/sda1

Press enter at the prompts to fix any errors that it finds. You can probably expect one about the free block count, and one about the free inodes count.

Since the image that you just copied over from the SD card needs to be smaller than the partition you copied it to, you’ll want to expand it to fill up the available space.

sudo resize2fs /dev/sda1

Uniquely identifying a drive

This next section is a partial repeat from the “Adding a Hard Drive” post, but I’ll include it again for completeness, and so that you don’t have to bounce back and forth between the posts.

Warning: Because the next section involves copying around large strings of unmemorizable data, I recommend performing the steps through a remote SSH window, or from a terminal on the X desktop. The ids you’ll need to copy must be copied verbatim, letter for letter, or you’ll find yourself unable to boot, and you’ll have to start over again from your last backup.

Currently, the cmdline.txt file specifies that the root file system is on the second partition of the internal SD card (/dev/mmcblk0p2). We’d like that to say “/dev/sda1″ instead, but there’s a problem. As I mentioned earlier, we don’t have any guarantee that this particular drive will be called “sda” in the future. What we need is a way to uniquely refer to this drive no matter what letter it get assigned on any given day.

This was why we built the drive with a GUID Partition Table. Each partition on a GPT device is assigned a universally-unique identifier (UUID).

Note: The difference between GUID and UUID is not important here, they are different terms for the same thing; a very long, randomly-assigned number.

Get the partition UUID for /dev/sda1

sudo blkid /dev/sda1

The piece of information we’re interested is the “PARTUUID” value. Take a picture, write it down very carefully, or select and copy the text if you are doing this through a remote terminal connection like I am.

Boot Configuration

The new root filesystem’s partition is now uniquely identifiable, but the Raspberry Pi doesn’t know to use it. Edit the /boot/cmdline file to change where the bootloader will look for the root filesystem.

sudo nano /boot/cmdline.txt

Find the part that says “root=/dev/mmcblk0p…” and change it to “root=PARTUUID=” and whatever your Partition unique GUID was from above. Also add the string “rootdelay=5” at the end. This will give the Raspberry Pi time to discover the USB drive before it tries booting from it.

The result should look like this (sorry for the small picture):


Exit Nano, saving your changes (ctrl-x,y,enter)

Reboot (Important, do not skip this step)

Before the next set of changes will “stick”, you’ll need to reboot so that the Raspberry Pi uses the hard drive for the initial load. If you don’t reboot now, nothing you’re about to do will count, and you’ll just have to do it all again. You’ve been warned.

sudo reboot

If everything goes well, you should find yourself back at a login, and you can continue. If something went wrong, go back to your most recent backup and try again.

Mounting filesystems

Partitions and filesystems are not the same thing. Linux now knows what partition to load the OS from, and that’s great, but as things stand right now, it’s still going to mount the root filesystem from the SD card.

To complete the transition to the hard drive, you’ll need to edit the filesystem table. This file controls what gets mounted where, and in what order, and it needs to know where the root filesystem is. Take a look at the current contents.

cat /etc/fstab


Note: You’ll probably have an entry here for your data partition that we added earlier in the series.

That third line is the root filesystem, which you can tell by the “/” in the second column. Unfortunately, it’s still loading from the 2nd partition on the SD card (mmcblk0p2). You could change this to say “/dev/sda1”, but that would only work as long as the drive continues to get the name “sda”.

Fortunately, you can use a very similar UUID-based trick here to uniquely identify the filesystem no matter what letter the device gets. Filesystems have UUIDs too, and you can see them all with this command:

sudo blkid


If you look carefully, you may notice a problem. both /dev/mmblk0p2 and /dev/sda1 have the same UUID. So much for being unique, right? This is because of the way we cloned the old root filesystem into a new location. It brought the whole filesystem over, including its UUID. Before you can use a unique Id to identify the drive, you’ll need to make sure it’s actually unique.

You need to give /dev/sda1 a new UUID. You can hand-assign your favorite UUID, or just let the computer pick a random one. Use the following command to assign a new UUID to the first partition on the hard drive:

sudo tune2fs /dev/sda1 -U random

Note: At the time of this edit, there seems to be an issue with the newer “Jessie” release of Raspbian, and it may prevent you from changing the UUID on the partition. If you see an error that says “The UUID may only be changed when the filesystem is unmounted.”, even though it’s NOT mounted, then you’ll need to perform one more tweak. The magic words are

sudo tune2fs -O ^uninit_bg /dev/sda1

I can’t take credit for this one at all. I just found it here. After reading the man page on tune2fs, I still don’t honestly even understand what this has to do with anything, but it does seem to do the trick, so if you get the above error, give this command a shot, then try the “-U random” command again and it should succeed.

Either way, display the device Ids again, just to be sure

sudo blkid


Copy down the UUID value (not the PARTUUID value) for /dev/sda1. You’ll need it in a minute. Open the filesystem table in an editor.

sudo nano /etc/fstab

Change “/dev/mmcblk0p2” on the third line to “/dev/disk/by-uuid/” and the new UUID you just assigned to /dev/sda1.

The end result should look like this:


Your ids will obviously differ, but the important thing is that you have pointed the root filesystem to the hard drive. Any other mounts you’ve defined should appear here as well. Don’t worry about the columns lining up, it doesn’t matter, but I’m presenting mine to the public, so I’ve gone ahead and made it pretty

Exit Nano, saving your changes (ctrl-x,y,enter)

That’s it. you’re ready to reboot again, and this time, everything should be faster.

sudo reboot

You’ll notice that the activity light on the Raspberry Pi will not blink much anymore. That’s because the SD card is no longer being accessed for anything other than the boot partition. The hard drive’s activity light will now blink where the Raspberry Pi’s activity light used to.

When the system has rebooted, double-check your filesystem table to make sure your changes are still there.

cat /etc/fstab

If you see /dev/mmcblk0p2, and no line for your data partition, it’s because you skipped that “Reboot” step above. See? I told you it was important. Redo everything in the “Mounting filesystems” section, and reboot again.

Swap configuration

One thing you may have noticed if you’ve looked at other walkthroughs for booting from the hard drive is that they usually create a “swap” partition on the hard drive to be used as virtual memory.

If you look back at the filesystem table from the beginning of this post, though, you’ll notice that Raspbian never had a swap partition in the first place. That’s because Raspbian is set up to use swap files instead of swap partitions. Raspbian’s swap file lives at /var/swap, and since we just moved the whole root filesystem onto the hard drive, the swap file came along for the ride.

At this point, you’re already running your swap file from the hard drive, and you didn’t even have to do anything. Check it out with the “swapon” command:

sudo swapon –s

This shows the swap summary, which will tell you what swaps are in use. It should have one entry in it (/var/swap). It’s pretty small, though; only 100MB:


The partition we created for the root filesystem is 16GB (or more if you so chose). There’s plenty of space left to expand the swap file to something roomier.

Edit the swap file configuration:

sudo nano /etc/dphys-swapfile

Find the line that says “CONF_SWAPSIZE=100”. This is the size of the swap file in megabytes. Change the value to 2048, which will create a 2GB swap file, which is a more appropriate for a server running on a Raspberry Pi 2 or 3.

Close Nano, saving your work (ctrl-x,y,enter).

We’ll need to reboot one more time to get this to stick, but there’s another change to make first. If you’d like to return to booting to the desktop, now is the ideal time to set that back up using raspi-config.

sudo raspi-config

Go to “Boot Options”, then “Desktop/CLI”, and set it back to “Desktop”. When you exit raspi-config, it will offer to reboot. Go ahead and let it.

Once the system has rebooted, check the swap file by typing “swapon –s” again. You should see a table similar to the first time you ran this command, only now the swap file is much larger:


Wrapping up

You now have a Raspberry Pi that boots (mostly) from an external USB drive. It also uses this drive for its virtual memory swap file. The whole system should run more smoothly now, and you won’t have to worry about using up your SD card, if that’s the sort of thing you worry about.

Although most of the important stuff is on the hard drive, you should probably make at least one more backup of the SD card for safety.

What’s Next?

In the next post, I’ll show you how to make backups now that the SD card isn’t being used for the root filesystem anymore.

This entry was posted in Computers and Internet, Home Server, Raspberry Pi and tagged , , , . Bookmark the permalink.

31 Responses to Raspberry Pi Home Server v2: Booting from the hard drive

  1. Denis says:

    >> “now that the SD card isn’t being used for the root filesystem anymore.”
    Does that mean I can delete material/folders (ie the redundant openvpn which is now on HD) from the SD card now ? And what folders *must* be retained ?
    I can see now as I write this, it might depend on the sequence in which i followed your tutorial 😦

  2. Mel Grubb says:

    I’ve always just left everything on the card because… why not? It’s not like the freed-up 8-ish GB is going to make a huge difference in my life, plus, you can always put cmdline and fstab back the way they were and continue using the card. Hopefully, when the new boot modes are considered “done”, none of this will matter, and we won’t need the SD card at all.

  3. Denis says:

    True . I don’t need the space. Being relatively new at this , my concern was that I might somehow someday edit/delete/screw up a wrong set of files, if I opened the SD card instead of the HD.

  4. IT Guy Kirk says:

    Hi, Mel. Long time no see. I’m setting up a new raspi-nas, and of course came back here for instructions. Wow, what a change from the old version. I really like it. One thing hasn’t changed, however, at least for me. The command “sudo swapon -s” doesn’t work for me.
    I noticed in one of your screenshots sudo is there, and in the next it is missing. But the discrepancy I have found is that the “-s” argument doesn’t work, either through putty or the cmd on the desktop. A search in the help file for swapon indicates that the flag should be “–show” (note that there are two dashes before “show”. That works, without “sudo”, at least for me.

    I also got a little confused about mounting usb data drives, but I need to work with it a bit more before I can ask an intelligent question. I went right to samba.cfg to get sharing set up, as you suggested, and I can share the data partition from the usb hard drive I boot from.

    More work to do. I’ll probably have more questions.


    Kirk Messinger

  5. Babushka says:

    After I read your earlier instructions on how to move the OS to external storage, along with a bunch of other tutorials, I only manage to invoke the dreaded KERNEL PANIC or get some other errors. I found your new instructions this year and gave it a go again. This time I managed, for the first time(!), to fully boot into the latest Jessie from the external mini SSD. It makes me super happy. Excellent instructions! BTW, I’m using Pi 2 and am waiting for my new Pi 3, which I’m hoping to setup in a similar fashion. Made my day! Much love! 🙂

  6. Tim Milne says:

    Excellent series of blogs! Thanks much!

    Followed through to this point, and realized that though I had created the os partition on my external USB drive, and setup the ext4 filesystem (it had defaulted to ntfs, so I had to replace that), I had never mounted it. Wonder if others missed that as well. I went back and followed the instructions for mounting the USB drive, and added a UUID entry in my /etc/fstab for the os partition, and now I can see it and do the dd command outlined in this blog post. Might want to address that detail for any others.

    Thanks again! This series is great!

    • Mel Grubb says:

      You don’t need to mount it first. Editing fstab automates the mounting part on every reboot. Is it possible that you didn’t reboot after editing fstab, and that’s why you didn’t see it?

  7. el_es says:

    When doing this with Raspbian Stretch (Lite), the
    “sudo tune2fs -O ^uninit_bg /dev/sda1”
    step was not required – it just worked with assigning of the random UUID.

  8. Clay says:

    When I do the “cat /boot/cmdline.txt” step, I see that “root=PARTUUID=10afbf2d-02” rather than /dev/mmcblk0p2 as shown in your example. I’m not sure how to put the PARTUUID into the dd command.

    • Mel Grubb says:

      I’ll have to look into it. The stretch release changed the way drives are referred to. Check out the syntax in fstab in the meantime, or the forums. I’m in the middle of doing a bunch of updates, and this will be part of that, but I haven’t had a chance to go through everything since stretch came out.

    • Mel Grubb says:

      They’ve started using partition IDs in stretch rather than the polite device names. This ensures that no matter what order the devices “arrive” in, they’ll be mounted to the correct locations. I touch on this in the article about booting from the hard drive. What I don’t have is an example of using the dd command to make a backup using the PARTUUID format. Can you try putting “PARTUUID=10afbf2d-02” where “/dev/mmcblk0p2” was? Hopefully that gets interpreted correctly. It’s just a different identifier syntax for talking about the partition, one that’s more universal, and less prone to problems with duplicated names.

      • cglenn0757 says:

        I tried inserting the PARTUUID string, but that didn’t work. So I just identified it the old way as /dev/mmcblk0p2, just as in your example, and that still works!

    • Mine doesn’t show it either, also, fstab show this instead of mmcblk0p2

      PARTUUID=9c87d796-01 /boot vfat defaults 0 2
      PARTUUID=9c87d796-02 / ext4 defaults,noatime 0 1

      I’ll try to do it the old way like cglenn0757 did. (Perhaps this part needs an update 🙂 ).

  9. Mel Grubb says:

    That’s good to know. I haven’t deliberately done that to a fresh Raspbian installation, but all the machines I updated to Stretch kept on working, so I figured that would still be okay.

  10. Clay says:

    Now that I have moved most everything off the SD card, can I go back and clean it up to remove anything that I don’t need? Is /boot/cmdline.txt the only thing I need to keep on the SD card? Can I pull the SD card and plug it into another Linux Box (RPi #2) and go into it and delete every file except for /boot/cmdline.txt? If so, can I then shrink the /boot partition down and then use dd to copy it onto an old 2GB SD card that I found in the bottom of my drawer and use that to start up the RPi Home Server? Or maybe use HDD Raw Copy Tool to take a backup image of the shrunken 32GB SD card, and then restore the image to the 2GB SD card? Is there any reason that I would ever want to move the file system from the hard drive back to the SD card?

    • Mel Grubb says:

      That seems a bit extreme. I wouldn’t feel comfortable deleting everything. I believe all you need it the contents of the boot partition. That’s the FAT partition on the card. You could just do away with the second partition, and that would shrink the image down a lot, although tools like Win32DiskImager and HDD Raw Copy may still want to back up the entire card, empty space and all. I believe what you’re after can be accomplished by just using dd to copy just the first partition to an image file. Sorry that I don’t have the syntax handy at the moment, but it shoudl be something like

      dd if=/dev/sda1 of=/PATH/image.img

      The input file (if) is identifying an individual partition, and the rest is the same as always. You should end up with a very small image file that is just the FAT partition. You could write that to a small SD card and off you go. I haven’t tried this personally, since I build on small cards to begin with, but let me know how it behaves for you.

      • Clay says:

        In Windows, I formatted the 2GB SD card as FAT32. Then I copied all the files from the FAT32 partition on 32GB SD card that I normally use to boot the RPi, over to the 2GB SD card. Then I inserted the 2GB SD card into the RPi and powered it up. There was some activity, but it did fail to boot up. I plugged in a monitor to the HDMI port so I could see what was happening. It said the “root account is locked” and seemed to get stuck on the plymouth-start.service. So I powered down the RPi, removed the 2GB SD card and put the 32GB SD card back in, and everything booted back up normally.
        Is there something in the boot up process that checks for permissions, or maybe UUID’s, such that when I tried to boot from a copy, it refused? It did seem like it was trying to access the HDD during the failed boot up attempt, but got stuck. I did run fsck on the HDD just to make sure nothing got broken during the boot attempt, and there were no errors induced on the HDD.
        I will try using dd to image the /dev/sda1 on the 32GB SD card as you suggested above, and then copy that image over to the 2GB SD card, and see if that works.

      • Clay says:

        I tried using the dd command to create an image from the 32GB SD card boot partition, and then writing that image to the 2GB SDA card, also using the dd command. But I got the same results. Watching on an attached monitor, when the Raspberry Pi Desktop splash screen comes up, it gets stuck at the mnt-data.mount step, and then goes to emergency mode. If I try to continue, it mentions “root account is locked” and hangs on the plymouth-start.service for awhile. It says to check the sulogin(8) man page for more details. So I powered down, and went back to the 32GB SD card, and everything works fine.
        When booting from the HDD, does the boot-up process still look for anything on the original SD card that is not in the FAT32 partition? It seems like it is looking for something and not finding it, or finding something that it didn’t expect. Any thoughts?

  11. Clay says:

    If the HDD should ever fail and need to be replaced, what is the procedure for preparing a new hard drive? If I just restore the sda1 image to the new drive, and then format all remaining drive space as an NTFS partition, is that enough to be able to put the new drive into service and boot from it? I am particularly thinking of the UUID. Does the UUID from the old drive get “cloned” onto the new drive when restoring the sda1 image? Or is some additional step needed in order to recognize the new drive?

  12. Doug Allen says:

    Hi Mel, thank you so much for this. Some peculiar behavior is that after setting the server to boot from the external usb drive, i’m asked to log in after booting to the desktop. The step I did immediately prior to this was installing btsync (and thus, the pre-populated option when the raspberry pi first boots shows btsync), so I imagine that could have something to do with it. BUT, when booting to the desktop prior to this step, I was automatically logged in as ‘pi’. In the Raspberry Pi Configuration, login as user pi is checked. Any thoughts?

  13. producerdoug says:

    Hi Mel, thank you so much for this. Some peculiar behavior is that after setting the server to boot from the external usb drive, i’m asked to log in after booting to the desktop. The step I did immediately prior to this was installing btsync (and thus, the pre-populated option when the raspberry pi first boots shows btsync), so I imagine that could have something to do with it. BUT, when booting to the desktop prior to this step, I was automatically logged in as ‘pi’. In the Raspberry Pi Configuration, login as user pi is checked. Any thoughts?

    • Mel Grubb says:

      Not off the top of my head. Are you able to set the option to automatically log in again after the installation? I’ve never noticed my settings changing on their own apart from maybe when I’ve updated major versions of the OS, and they’ve decided to change the defaults on something.

      • producerdoug says:

        Thank you for the response! I changed the options in the Configuration window from Desktop to CLI, rebooted, then back to Desktop, and that seemed to fix the problem.

  14. Jon Kinne says:

    Hi Mel, thanks again for all of your work. Now that I have all of the NUT configuration done, I was considering booting from the USB drive that is currently mounted for storage. It’s not an “external HDD”…just a 64GB USB thumb drive…will the instructions work for that as well? I have a Pi 3B and it does give the option to reset the bit that allows booting from the USB drive, but I have a question. Right now the SD card is a 32GB card, and obviously I’m using very little of it. I think your instructions said to create on the HDD (my USB thumb?) a boot partition the same size as the current boot partition on the SD card. That seems as if I will waste about half of the USB drive’s capacity…is there a way that I can get what I need off the current 32GB SD card onto a smaller boot partition on the thumb drive?

    • Mel Grubb says:

      First, as long as the drive you are using is fast enough, it doesn’t usually matter what kind of device it is, but flash drives are not usually built for speed, and you may be disappointed with the results.

      Second, it is possible to shrink the size of the backup image, but that is not something I have covered or even done myself. I usually build on a smaller card and then transfer to a larger partition on a hard drive, so I’ve never needed to shrink the filesystem. The instructions are out there though.

  15. My stick was showing SDA instead of SDA1, so I followed your tutorial with that.
    When i did the sudo blkid command it showed: /dev/sda: LABEL=”rootfs” UUID=”87b585d1-84c3-486a-8f3d-77cf16f84f30″ TYPE=”ext4″
    I didn’t see the term PARTUUID, so I just copied above string to put in CMDLINE.TXT.
    Now I’m trying a reboot and it hangs. Any idea why ?

    It is detecting the USB stick. But now it hangs at [138.291116] random: crng init done

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s