Raspberry Pi 4 usb boot?

[hardwaremack-orginal]

i wanted to maintain the portable nature of my PI4B so that is why i got the Samsung FIT, the thing is tiny and fast too!

images.jpg (5.26 KiB) Viewed 9616 times

[pagepack]

i wanted to maintain the portable nature of my PI4B so that is why i got the Samsung FIT, the thing is tiny and fast too!

Did you have any joy? I bought exactly the same USB drive and followed this guide;

https://www.tomshardware.co.uk/boot-ras ... 61081.html

to no avail.

[HawaiianPi]

Did you have any joy? I bought exactly the same USB drive and followed this guide;

https://www.tomshardware.co.uk/boot-ras ... 61081.html

to no avail.

That guide seems unnecessarily complicated. I have a quick tutorial in this post.
https://www.raspberrypi.org/forums/view ... 0#p1498774

Or try RonR's script, which should do all the work for you.
Running Raspbian on USB Devices : Made Easy

[chriss44]

If you don't mind using the SD card for an initial boot loader, you can run the OS off a USB drive. Just edit the cmdline.txt in /boot, and add "init=/sbin/usbroot.sh", rsync the OS from the SD card to the usb drive, then create a script "/sbin/usbroot.sh" that mounts the usb, runs pivot_root, and then exec /sbin/init. Now you have the OS running of the usb drive, and the SD card is only in use while the system is initially booting.

If you want, I can put together details and write up a procedure in a separate post.

I like your idea. I was always planning to boot the RPI4 from SSD - your idea seems to be a great solution to bridge the waiting time!

Did you try it on your RPI 4 - is it working?

Do you have a sample of usbroot.sh?

Thank you,
Chriss

[thagrol]

If you don't mind using the SD card for an initial boot loader, you can run the OS off a USB drive. Just edit the cmdline.txt in /boot, and add "init=/sbin/usbroot.sh", rsync the OS from the SD card to the usb drive, then create a script "/sbin/usbroot.sh" that mounts the usb, runs pivot_root, and then exec /sbin/init. Now you have the OS running of the usb drive, and the SD card is only in use while the system is initially booting.

If you want, I can put together details and write up a procedure in a separate post.

I like your idea. I was always planning to boot the RPI4 from SSD - your idea seems to be a great solution to bridge the waiting time!

Did you try it on your RPI 4 - is it working?

Do you have a sample of usbroot.sh?

Thank you,
Chriss

That's more complicated than it needs to be, and there's no need to "pivot_root".

See the links provided by HawaiianPi above but in essence:

• Write the desired raspbian iamge to an SD card.
• Boot your 4B
• Attach your SSD.
• Partition it
• Mount it
• Copy the contents of "/" from the SD card to the SSD.
• Find the correct PARTUUID for the partition on the SSD
• On the SD card: edit cmdline.txt. Replace the PARTUUID with the one from above
• On the SSD: edit [...]/etc/fstab (Note exact path will depend on where you've mounted the partition). In the line for "/" replace the PARTUUID with the one found above
• reboot

[RonR]

Do you have a sample of usbroot.sh?

usb-boot

[HawaiianPi]

I don't start by making a Raspbian SD card. I write Raspbian directly to the USB drive.

1. Write a Raspbian Buster image to your USB drive with Etcher.
2. Edit cmdline.txt on "boot" partition to remove the resize script launch (leave only a single space).
3. Copy all files from USB drive "boot" partition to FAT32 micro SD card.
4. Plug USB drive and card into Pi4 and boot it up.
5. Edit /etc/fstab to mount the SD card as /boot, followed by a restart.
6. Do basic configuration (change password, location, network, update, etc.).
7. If you are using the Desktop version of Buster, install GParted and resize / partition to fill unallocated space on USB drive, then BEFORE YOU REBOOT, edit /boot/cmdline.txt and /etc/fstab with updated PARTUUID.

• For Buster Lite you could use another Raspbian card to resize the partition and edit the files.

That's how I set up mine anyway. When the USB boot enabled firmware drops I'll update then copy the /boot SD card back to the USB drive, edit fstab and I should be good to go for cardless USB boot.

[thagrol]

Yeah, that's a quicker way of doing things. I forgot that writing the image directly to the USBdrive is possible.

[andrum99]

Yeah, that's a quicker way of doing things. I forgot that writing the image directly to the USBdrive is possible.

Imaging the USB drive is the preferred way to do this, since it is also the easiest way to get USB boot working on BCM2837-based Pi's. It's also the method documented in the official documentation.

[HawaiianPi]

Yeah, that's a quicker way of doing things. I forgot that writing the image directly to the USB drive is possible.

It's also ridiculously fast to image a USB 3.0 SSD, compared to any micro SD card (even in a USB 3.0 reader). Etcher flies through the write and verify process at almost comical speed when the SSD is on a USB 3.0 port.

[RonR]

1. Write a Raspbian Buster image to your USB drive with Etcher.
2. Edit cmdline.txt on "boot" partition to remove the resize script launch (leave only a single space).
3. Copy all files from USB drive "boot" partition to FAT32 micro SD card.
4. Plug USB drive and card into Pi4 and boot it up.
5. Edit /etc/fstab to mount the SD card as /boot, followed by a restart.
6. Do basic configuration (change password, location, network, update, etc.).
7. If you are using the Desktop version of Buster, install GParted and resize / partition to fill unallocated space on USB drive, then BEFORE YOU REBOOT, edit /boot/cmdline.txt and /etc/fstab with updated PARTUUID.

• For Buster Lite you could use another Raspbian card to resize the partition and edit the files.

Much simpler and less error-prone:

1. Write a Raspbian Buster image to your USB drive with Etcher.
2. Write a Raspbian Buster image to an SD card with Etcher.
3. Plug the USB drive and SD card into Pi4 and boot it up.
4. Run usb-boot, answering 'No' to 'Replicate BOOT/ROOT contents from /dev/mmcblk0 to /dev/sdX?'.
5. Reboot (the USB drive will boot).

[brainsys]

Would I be right that the advantage of imaging to the USB drive rather than dd-ing the root partition would be that when we do get full USB boot support the USB drive will not need re-partitioning to add the missing boot partition?

By the time full USB boot arrives that could be time consuming task with the added frisson of exposing yourself to possible data loss during the re-partitioning process with your live data?

[Cheeers]

Many thanks, RonR! Your scripts worked well for me after trying HawaiianPi's method a few times without success. The adjusting PARTUUIDs bit was too complicated for me. I am glad that your scripts took care of that.

[Darktrax]

Thank you Pi 4 folk for the great Pi 4 USB boot recipe and advice.

Now suppose the USB drive happens to be a 500GB USB 3.1 SSD (like Samsung T5).
Simply plugging it in (experiment) causes a mounting error (:unknown filesystem 'exfat').
I know it's a Microsoft thing, but my LinuxMint seems to treat the drive just like any other stick.

Before we start
So - maybe the first stage is to get clear what we do to the drive before we try any of this.
FAT32 may be OK for a boot partition, but maybe not for the rest of the drive.
Will Etcher start us off on the right foot? Do we use gparted on it first?

Etcher
Etcher flags a warning about the drive being unusually large, and gives the option to reconsider the action, as if something bad might happen. Will Etcher just make a partition as big as it needs to, and leave us to re-size later (I hope so)?

Wear Levelling ?
Once done, should we try to preserve the USB SSD drive by invoking util-linux and getting into using trimfs?
Should one be getting at system systemctl and starting fstrim.service and fstrim.timer?
Is it to be daily, or weekly, or something else? Are there any actions that should involve cron?

/etc/fstab ?
Should one be modifying fstab? What do the "defaults" mean?
Should whatever partition that ends up as /boot benefit from "noauto, noatime 1 2" ?
Should we see "discard", as in " /dev/sda2 / ext4 noatime,discard 0 1" ?
Are there any folders that are better worked in RAM, perhaps temporary files?

As you may guess from all the questions, I don't even know enough to be dangerous!
I think I need to be moderately confident about most of things that should be in the recipe before I start messing with partitions, or at least be reassured that these things are not actually important any more, or are handled automatically.

This is clearly the right place to ask - thanks in advance if you can help.

[Darktrax]

Much simpler and less error-prone:

1. Write a Raspbian Buster image to your USB drive with Etcher.
2. Write a Raspbian Buster image to an SD card with Etcher.
3. Plug the USB drive and SD card into Pi4 and boot it up.
4. Run usb-boot, answering 'No' to 'Replicate BOOT/ROOT contents from /dev/mmcblk0 to /dev/sdX?'.
5. Reboot (the USB drive will boot).
6. Run raspi-config-usb, to resize the USB drive.

Hi RonR
It did not work quite as expected for me.
I had Etcher write the SD with the latest Buster, and I did the apt upgrades.
The same for the USB SSD drive.
I fetched usb-boot, copied it to the Pi, and tried running usb-boot.

There was no opportunity for any dialogue. Just the briefest blink-flash, and it was gone!
No different when choosing "Run in terminal".

I am sure I can make this happen - but maybe step-by-step.
The bash script does, after all, set it all out.
Many thanks

[RonR]

Hi RonR
It did not work quite as expected for me.
I had Etcher write the SD with the latest Buster, and I did the apt upgrades.
The same for the USB SSD drive.
I fetched usb-boot, copied it to the Pi, and tried running usb-boot.

There was no opportunity for any dialogue. Just the briefest blink-flash, and it was gone!
No different when choosing "Run in terminal".

This post is a little clearer:

https://www.raspberrypi.org/forums/view ... 8#p1506988

Simply write a Raspbian image to both the SD card and the USB drive (adding ssh and wpa_supplicant.conf files if applicable).

Insert the SD card and plug in the USB drive.

Power up and log in as 'pi', but don't do any updates or other configuration at this time.

Place usb-boot in the 'pi' directory.

Run usb-boot from a terminal window:

Code: Select all

chmod +x usb-boot
sudo ./usb-boot

Select the proper USB drive and answer 'No' to 'Replicate BOOT/ROOT contents from /dev/mmcblk0 to /dev/sdX?'.

When usb-boot finishes, simply reboot:

Code: Select all

sudo shutdown -r now

After rebooting, you'll be running from the USB drive.

Place raspi-config-usb in the 'pi' directory and run it from a terminal window to resize the USB drive:

Code: Select all

chmod +x raspi-config-usb
sudo ./raspi-config-usb

Now you're ready to start updating, configuring, etc.

[weberjn]

I just set up my Pi 4 to boot from SD to a WD blue SSD w SATA2USB adapter, using just the command line:

• fdisk the partitions (boot, root, home) as primary partitions
  mkfs
  mount and rsync the SD to SSD
  add the PARTUUIDs to the fstab on the SSD
  point the SD cmdline.txt to the SSD root

Cannot attach a .txt, so here the log inline:

root@karo:~# fdisk -l|more

disk /dev/mmcblk0: 29.7 GiB, 31914983424 bytes, 62333952 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd9baabc9

Device Boot Start End Sectors Size Id Type
/dev/mmcblk0p1 8192 532480 524289 256M c W95 FAT32 (LBA)
/dev/mmcblk0p2 540672 62333951 61793280 29.5G 83 Linux

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: 100T2B0A-00SM50
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0x0a477230

Device Boot Start End Sectors Size Id Type
/dev/sda1 65535 589814 524280 256M c W95 FAT32 (LBA)
/dev/sda2 589815 67697654 67107840 32G 83 Linux
/dev/sda3 67697655 76086134 8388480 4G 82 Linux swap / Solaris
/dev/sda4 76086135 1953525167 1877439033 895.2G 83 Linux


root@karo:~# mkfs -t vfat /dev/sda1
mkfs.fat 4.1 (2017-01-24)
root@karo:~# mkfs -t ext4 /dev/sda2
mke2fs 1.44.5 (15-Dec-2018)
Creating filesystem with 8388480 4k blocks and 2097152 inodes
Filesystem UUID: 7d8f26cd-2e9c-4b5b-84d5-cee147a34be8
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

root@karo:~# mkfs -t ext4 /dev/sda4
mke2fs 1.44.5 (15-Dec-2018)
Creating filesystem with 234679879 4k blocks and 58671104 inodes

root@karo:~# mount /dev/sda1 /mnt/boot/
root@karo:~# rsync -axHAWXS --numeric-ids --info=progress2 /boot /mnt

root@karo:~# mount /dev/sda2 /mnt/root/
root@karo:~# rsync -axHAWXS --numeric-ids --info=progress2 / /mnt/root
2,742,993,749 89% 22.39MB/s 0:01:56 (xfr#58784, to-chk=0/72686)

root@karo:~# mount /dev/sda4 /mnt/home/
root@karo:~# rsync -axHAWXS --numeric-ids --info=progress2 /home /mnt

root@karo:/mnt/root/home# rm -rf weberjn/
root@karo:/mnt/root/home# ll
total 0

root@karo:/mnt/root/etc# blkid
/dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="F661-303B" TYPE="vfat" PARTUUID="d9baabc9-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="8d008fde-f12a-47f7-8519-197ea707d3d4" TYPE="ext4" PARTUUID="d9baabc9-02"
/dev/mmcblk0: PTUUID="d9baabc9" PTTYPE="dos"
/dev/sda1: SEC_TYPE="msdos" UUID="BA86-457C" TYPE="vfat" PARTUUID="0a477230-01"
/dev/sda2: UUID="7d8f26cd-2e9c-4b5b-84d5-cee147a34be8" TYPE="ext4" PARTUUID="0a477230-02"
/dev/sda3: PARTUUID="0a477230-03"
/dev/sda4: UUID="901daf85-0613-4908-9276-c33b0483a30a" TYPE="ext4" PARTUUID="0a477230-04"


root@karo:~# cat /mnt/root/etc/fstab
proc /proc proc defaults 0 0
PARTUUID=d9baabc9-01 /boot vfat defaults 0 2
PARTUUID=0a477230-02 / ext4 defaults,noatime 0 1
PARTUUID=0a477230-04 /home ext4 defaults,noatime 0 1

root@karo:/boot# cat cmdline.txt
dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=0a477230-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

root@karo:~# reboot

weberjn@karo:~ $ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/root ext4 32G 2.6G 28G 9% /
devtmpfs devtmpfs 1.8G 0 1.8G 0% /dev
tmpfs tmpfs 2.0G 0 2.0G 0% /dev/shm
tmpfs tmpfs 2.0G 8.5M 1.9G 1% /run
tmpfs tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup
tmpfs tmpfs 2.0G 0 2.0G 0% /tmp
/dev/mmcblk0p1 vfat 253M 40M 213M 16% /boot
/dev/sda4 ext4 881G 153M 836G 1% /home
tmpfs tmpfs 391M 0 391M 0% /run/user/1001

[Darktrax]

RonR: More thanks. This time I got there!
There are many little situations that can arise..

Clicking on the shell script icon, and letting the GUI offer a choice to "Run" or "Run in Terminal" is what tripped it up. As in your post, the right way is opening a terminal and using sudo ./usb-boot, which gets the expected dialogue.

The dialogue itself is one of those where space-bar Tab cycles the choices and Space-Bar selects.I saw that some years ago. There has been Windows and Android experiences in between

Various other things happened on the way, including getting the message in the terminal " ..aborting".
Huh ??
So I tried again, and this time, the "aborting" message did not happen. Just a silent return to the prompt.
I chose the complete shutdown, power off, restart.

Yes indeed - it seemed to work.
I think the minor stumble may have been because after Etcher had completed the flash write to the USB SSD drive, I I had used gparted to generously re-size the rootfs partition, and then added the planned data partition before connecting it to the Pi-4.

The swift boot-up does let one know something is different, although I am thinking there will be some who will be looking for the way to have more explicit confirmation that all is well.

The white power supply from Pi Hut just cries out for one of those push-button click on-off power switches built into the type-C power lead. Oh yes - getting the whole thing fixed up with everything it needs - maybe an effective passive heat-sink as well, is starting to be fun!

Thanks RonR, we now have something really nice!

[RonR]

Various other things happened on the way, including getting the message in the terminal " ..aborting".
Huh ??
So I tried again, and this time, the "aborting" message did not happen.

You no doubt hit the return key with nothing selected the first time. 'whiptail' (the program that does the semi-gui looking interface) returns as if you hit the escape (abort) key in this case. 'whiptail' is pretty lacking.

The swift boot-up does let one know something is different, although I am thinking there will be some who will be looking for the way to have more explicit confirmation that all is well.

Simply running 'mount' will confirm that: '/dev/sda2 on /'.

Thanks RonR, we now have something really nice!

I'm pleased to hear of your success.

[RonR]

I just set up my Pi 4 to boot from SD to a WD blue SSD w SATA2USB adapter, using just the command line:

• fdisk the partitions (boot, root, home) as primary partitions
  mkfs
  mount and rsync the SD to SSD
  add the PARTUUIDs to the fstab on the SSD
  point the SD cmdline.txt to the SSD root

That's great if know how to manipulate all those commands, but usb-boot does all that for you by simply typing 'sudo ./usb-boot'.

[weberjn]

That's great if know how to manipulate all those commands,

That's the point of playing with a rpi.

Still, some people might prefer a shiny new Mac that just works

[M4dm4rtig4n]

Much simpler and less error-prone:

1. Write a Raspbian Buster image to your USB drive with Etcher.
2. Write a Raspbian Buster image to an SD card with Etcher.
3. Plug the USB drive and SD card into Pi4 and boot it up.
4. Run usb-boot, answering 'No' to 'Replicate BOOT/ROOT contents from /dev/mmcblk0 to /dev/sdX?'.
5. Reboot (the USB drive will boot).

Hi, i have try your method but my Raspi4 don't boot to USB Storage (SSD) :/

[RonR]

Much simpler and less error-prone:

1. Write a Raspbian Buster image to your USB drive with Etcher.
2. Write a Raspbian Buster image to an SD card with Etcher.
3. Plug the USB drive and SD card into Pi4 and boot it up.
4. Run usb-boot, answering 'No' to 'Replicate BOOT/ROOT contents from /dev/mmcblk0 to /dev/sdX?'.
5. Reboot (the USB drive will boot).

Hi, i have try your method but my Raspi4 don't boot to USB Storage (SSD) :/

Are you running headless? If so, did you add an ssh file to the BOOT partition of BOTH the USB drive AND the SD card?

Are you running wireless? If so, did you add wpa_supplicant to the BOOT partition of BOTH the USB drive AND the SD card?

Was there any error messages displayed when you ran usb-boot?

Be patient on the first USB boot after usb-boot is run as the USB drive gets expanded.

[HawaiianPi]

Hi, i have try your method but my Raspi4 don't boot to USB Storage (SSD) :/

How do you know it's not running the OS from USB?

• Is it not booting at all?
• Are you trying to boot without the SD card (currently not supported on the Pi4)?

[harwoodr]

So does anyone know have they made any progress with booting the raspi4 from usb? yet!
All serious users need this facility