do I need to set usb boot again on a fresh install of raspberry Pi OS?

Hi folks,

I just got my raspberry pi 4 working to boot from from a USB device.

My question is if I decide later in the future to use another image like ubuntu or a fresh install of raspberry pi OS, do I need to do the enable USB booting again?

Or is the eeprom already set for USB booting because It was done already regardless of the image I use? Thanks

Don't think so. It's a firmware update, which IIRC is the files bit of code that loads the chip firmware in /boot. That's in the Pi board itself.

Originally Posted by Tux2025 Hi folks, I just got my raspberry pi 4 working to boot from from a USB device. My question is if I decide later in the future to use another image like ubuntu or a fresh install of raspberry pi OS, do I need to do the enable USB booting again? Or is the eeprom already set for USB booting because It was done already regardless of the image I use? Thanks

Does not matter once you have set it the setting is in the firmware now, the BOOT_ORDER=0xf41.

root@bullseye-raspi:~#  vcgencmd bootloader_config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
TFTP_IP=
TFTP_PREFIX=0
BOOT_ORDER=0xf41
[none]
FREEZE_VERSION=0

@ business_kid

@ HappyTux

Thanks to you both for your experience in the raspberry pi ecosystem, this is good to know.

I'm a late adopter of the raspberry pi. I never owned one until a week ago. It's awesome!!!

It worked with a USB flash drive. But, I'm going to buy an external SSD. I read that the raspberry pi 4 can have some issues booting with certain external SSD's. I will have to research this before buying a SSD.

Anyway, thanks again for your replies.

Originally Posted by Tux2025 @ business_kid @ HappyTux Thanks to you both for your experience in the raspberry pi ecosystem, this is good to know. I'm a late adopter of the raspberry pi. I never owned one until a week ago. It's awesome!!! It worked with a USB flash drive. But, I'm going to buy an external SSD. I read that the raspberry pi 4 can have some issues booting with certain external SSD's. I will have to research this before buying a SSD. Anyway, thanks again for your replies.

It is the dongle that really is the problem if you get unsupported one it will not allow you to boot only from the ssd, only a chainload method keeping the firmware files on the sdcard partition. If you want working trim then you will want to follow that part of the guide in the link below. Now I read through it the trim part is not in that guide but the second link I had. Since you will have working setup already it is a simple matter of copying over the system to the new drive when you get it and the cables shutdown remove the stick and boot with the ssd connected, go for the Kingston A400 mentioned it is good drive and has never caused me a problem, I went with the 120gb for like $20 on Amazon last year at Christmas time as present to myself, a new toy to tinker with a Pi4 8GB. If you want to save problems when doing the copy then you can make sure to setup the system to boot using LABEL= for the mount points and in your cmdline.txt. I show this below, this allows you to copy between drives without have to make changes to get it to boot, I use it for backing up my system over the network before making major changes like kernel update or firmware too. Then of course if not having made a backup in a period of time then I do it too.

https://jamesachambers.com/raspberry...-flash-drives/
https://www.jeffgeerling.com/blog/20...n-raspberry-pi

root@bullseye-raspi:~# cat /etc/fstab 
# The root file system has fs_passno=1 as per fstab(5) for automatic fsck.
LABEL=RASPIROOT / ext4 rw 0 1
# All other file systems have fs_passno=2 as per fstab(5) for automatic fsck.
LABEL=RASPIFIRM /boot/firmware vfat rw 0 2

# Added for rtorrent files.
/dev/sdb1 /home/seeder1/rtorrent    ext4    defaults        0       2
root@bullseye-raspi:~# cat /boot/firmware/cmdline.txt 
console=tty0 console=ttyS1,115200 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0  rootwait

When you get it all together let us know if you run into any problems oh and the commands I use to back it up.

mkdir /tmp/ssdboot
mkdir /tmp/ssdroot
mount /dev/sd?1 /tmp/ssdboot
mount /dev/sd?2 /tmp/ssdroot
rm -r /tmp/ssdboot/*
scp  /boot/firmware/* /tmp/ssdboot/
rsync -ahPHAXx --delete --exclude={/boot/firmware/*,/dev/*,/proc/*,/sys/*,/tmp/*,/run/*,/mnt/*,/media/*,/lost+found} / /tmp/ssdroot/

First I make the mount points then mount them, replace the ? with the drive letter of the ssd. Next I remove any exiting files on the boot target to prevent the accumulation of crud leftovers. Then I rsync the live running system, you will have to adjust the previous command and this one depending on the name of the /boot/firmware in your distro. Once done if using the LABEL= method there is nothing to do but shut down the mahine and boot with the ssd attached and watch it spring back to life. Otherwise the cmdline.txt and /etc/fstab need to be edited to put in the values for the new ssd drive. One last thing the drive partitioning as you can see below I use GPT with a 200M efi system partition created using gdisk.

root@bullseye-raspi:~# fdisk -l
Disk /dev/sda: 111.79 GiB, 120034123776 bytes, 234441648 sectors
Disk model: ASM105x         
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: gpt
Disk identifier: D8A96088-5191-480A-9498-EE006223808B

Device      Start       End   Sectors   Size Type
/dev/sda1      40    409639    409600   200M EFI System
/dev/sda2  409640 234441614 234031975 111.6G Linux filesystem

@ HappyTux

That's alot of info to digest. BUt, I will try it when I buy the SSD. I'm going to buy oe of the the supported cables in the first link and the Kingston A400 ssd.

The trim part looks to confusing to do. If I can get the SSD to boot that is enough for me

Thanks again HappyTux for your info and links. I will read and reread until I get it.

Originally Posted by Tux2025 @ HappyTux That's alot of info to digest. BUt, I will try it when I buy the SSD. I'm going to buy oe of the the supported cables in the first link and the Kingston A400 ssd. The trim part looks to confusing to do. If I can get the SSD to boot that is enough for me Thanks again HappyTux for your info and links. I will read and reread until I get it.

The trim is easy to do buy the a400 and put this for the file needed I almost forgot I needed the second line I have in the file.

root@bullseye-raspi:~# cat /etc/udev/rules.d/10-umap-trim.rules 
# ASMedia ASM1153E, ASM1053E and compatible bridge chips
# Added following guide here https://www.jeffgeerling.com/blog/2020/enabling-trim-on-external-ssd-on-raspberry-pi
# Added second line as they say it is not preserved on reboot in comments further down.

ACTION=="add|change", ATTRS{idVendor}=="174c", ATTRS{idProduct}=="55aa", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
KERNEL=="sda", SUBSYSTEM=="block", ATTR{queue/discard_max_bytes}="2147450880"

And that is it you have working trim with it enabled.

root@bullseye-raspi:~# fstrim -v /
/: 741 MiB (776974336 bytes) trimmed
root@bullseye-raspi:~# apt-file search fstrim
libguestfs-gobject-dev: /usr/include/guestfs-gobject/optargs-fstrim.h
manpages-de: /usr/share/man/de/man8/fstrim.8.gz
manpages-fr: /usr/share/man/fr/man8/fstrim.8.gz
util-linux: /lib/systemd/system/fstrim.service
util-linux: /lib/systemd/system/fstrim.timer
util-linux: /sbin/fstrim
util-linux: /usr/share/bash-completion/completions/fstrim
util-linux: /usr/share/man/man8/fstrim.8.gz
root@bullseye-raspi:~# sysctrl status fstrim
bash: sysctrl: command not found
root@bullseye-raspi:~# systemctl status fstrim
● fstrim.service - Discard unused blocks on filesystems from /etc/fstab
     Loaded: loaded (/lib/systemd/system/fstrim.service; static)
     Active: inactive (dead) since Mon 2021-11-08 01:17:07 AST; 1 day 22h ago
TriggeredBy: ● fstrim.timer
       Docs: man:fstrim(8)
    Process: 226988 ExecStart=/sbin/fstrim --listed-in /etc/fstab:/proc/self/mountinfo --verbose -->
   Main PID: 226988 (code=exited, status=0/SUCCESS)
        CPU: 317ms

Nov 08 01:16:56 bullseye-raspi systemd[1]: Starting Discard unused blocks on filesystems from /etc/>
Nov 08 01:17:07 bullseye-raspi fstrim[226988]: /boot/firmware: 74.3 MiB (77946880 bytes) trimmed on>
Nov 08 01:17:07 bullseye-raspi fstrim[226988]: /: 102.3 GiB (109894193152 bytes) trimmed on /dev/sd>
Nov 08 01:17:07 bullseye-raspi systemd[1]: fstrim.service: Succeeded.
Nov 08 01:17:07 bullseye-raspi systemd[1]: Finished Discard unused blocks on filesystems from /etc/

With the util-linux installed and a systemctl enable fstrim the daemon will run once a week to trim the drive as it shows the last time on mine before the manual I just did was the 8th of this month.

Edit: Had this in my ebay bookmarked items it looks identical to the cables I already have and it supports the USAP which is what is required for working trim and booting. It is the cheapest I have found it listed for anywhere.

https://www.ebay.com/itm/32410439990...53.m1438.l2649

I don't think the RPI4 is 'picky' when it comes to external SSDs. I used first 500G Samsung T5s and T7s with mine. Liked the form factor. I just used Etcher to install PI OS onto the SSDs and the RPIs booted off of them. Then I remembered I had a bunch of 2.5 SATA SSDs stacked in my cabinet from various vendors. This SSDs were replaced with larger capacity SSDs over time in my desktops. So I went and bought a few SATA to USB 3.0 cables (StarTech brand) and those SSDs worked fine with the RPIs also. Just an FYI.

--

Note the when the RPI4 first came out, it was still required to boot from SD card, but you could set the file system to the USB SSD. Later the firmware finally allowed true booting from the USB and you didn't need the SD card any more. Wonderful!

+1 rclark.

If you use a 2.5" disk, it will run off the 500mA available on the usb3 ports.

As mains here is 220VAC and the Pi is an English design (with 240VAC mains) there was a low voltage problem which I solved with a powered usb hub which had a 5.1V supply line. Once I had the system installed & updated, I made a backup, and just restore off that.

Originally Posted by business_kid +1 rclark. If you use a 2.5" disk, it will run off the 500mA available on the usb3 ports. As mains here is 220VAC and the Pi is an English design (with 240VAC mains) there was a low voltage problem which I solved with a powered usb hub which had a 5.1V supply line. Once I had the system installed & updated, I made a backup, and just restore off that.

The advice about the backup and restore is good, the power not so. The Pi was never designed to use a 240V switching power supply connected to main power. It was designed to run off cheap wall warts for cell phones as a power supply and as such is limited to the power those can provide.. The power available can be increased to 1.2A using boot switch.


https://forums.raspberrypi.com/viewtopic.php?t=246844
https://hackaday.com/2015/04/06/more...-pi-usb-ports/
https://kalitut.com/increase-usb-cur...-raspberry-pi/

Edit: And that would be all the ports combined as they have a common power source on the four ports not one for USB3 and then one for the other two ports.

Had this in my ebay bookmarked items it looks identical to the cables I already have and it supports the USAP which is what is required for working trim and booting. It is the cheapest I have found it listed for anywhere.

I have a Wavelink usb3 docking station which has USAP support, uses the uas driver in linux but does not support trim. I conclude that having USAP support, while clearly necessary, may not be sufficient for trim support. The Wavelink has the Asmedia ASM1153E chipset. There are some third party firmware upgrades(windows only) which purport to give the device trim support but I don't trust the source. Have you personally tried your udev workaround on this chipset per your post, and if so, have you run into any problems? I've read reports where forcing trim on unsupported hardware can brick a drive.

Also, can you confirm that the adapter cable you posted on ebay with trim support actually works OK out of the box or is a udev rule workaround required?

Originally Posted by kilgoretrout I have a Wavelink usb3 docking station which has USAP support, uses the uas driver in linux but does not support trim. I conclude that having USAP support, while clearly necessary, may not be sufficient for trim support. The Wavelink has the Asmedia ASM1153E chipset. There are some third party firmware upgrades(windows only) which purport to give the device trim support but I don't trust the source. Have you personally tried your udev workaround on this chipset per your post, and if so, have you run into any problems? I've read reports where forcing trim on unsupported hardware can brick a drive. Also, can you confirm that the adapter cable you posted on ebay with trim support actually works OK out of the box or is a udev rule workaround required?

You have to enable the trim support on the Pi is is not done automatically. For instance just the other day Monday I turn on my spare computer that runs Ubuntu and I notice the hard drive light going crazy I checked the access and it was the fstrim running. I never enabled it on that machine it was done during the OS setup on install. The cable works fine for the purpose of booting from USB on a Pi the topic asked about. The trim only works once you go out of your way to enable (this requires the udev to do) it on supported dongle and drive combination on a Pi. The 1153E is the chipset in my dongle cable as shown below the 1153 chipset is my powered drive tray that holds the hard drive for my install, so yes I can confirm the chipset works with the work around I applied. It was the whole purpose of using it to enable the trim to run. Though now I look at that output take a guess as to which chipset is there of the four listed. All I know is a device with that id (174c:55aa) works perfectly and has for almost the entire year now. As it was early January or late December of last year I bought the cables I have now for that. I have two same as the SSDs that run on the Pi4 I am rather obsessive on that, having a working backup in case one dies. Don't have two of the Pi4s thought the disgusting behaviour of them people lead me to pledge never to give them another cent of my money. I am rather obsessive on this by never giving scumbags another change at getting my dollars again. I use real computer for its backup. Something that has actual power behind it, the Pi is good enough for sitting there and doing essentially nothing most of the time at low power. Certainly beats the 100w+ the computer it took the place of uses 24/7 if it is on and used, I am cheap SOB too.

root@bullseye-raspi:~# lsusb
Bus 002 Device 003: ID 174c:1153 ASMedia Technology Inc. ASM1153 SATA 3Gb/s bridge
Bus 002 Device 002: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge, ASM1053E SATA 6Gb/s bridge, ASM1153 SATA 3Gb/s bridge, ASM1153E SATA 6Gb/s bridge
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

HappyTux, thanks for the info. I have some other questions but this is so off topic, I'll start a new thread.

To the original poster, trim support for usb connected drives can be somewhat convoluted. To mitigate any problems caused by lack of trim support, you can try to partition your SSD with 10% or 15% left unallocated. The SSD firmware can use the unallocated space to work around the lack of trim. This is called "over provisioning".

Trim isn't needed - been using SSD for a long time now with no problems, most have built in systems for keeping the disk in good shape, it was only the very early SSD that could make use of trim. The major problem is the chip used by some external housings & adapter cables - I've been quite lucky, all the ones I've bought work.

With regard to unallocated space, the disk will have their own redundancy built in.

You can just use an SSD as if it was a HDD nowadays without any worries.