I look forward to it!
Unfortunately i don’t believe so much.
No detailed data is provided about mAh/Ah available on USB A Ports.
Here it is, as said the hard way… possible you can do it much easier with cloning software. But you be rewarded with a fresh, optimal aligned install on your SSD with really unique UUID for the disk and partitions!
NOTE; THIS IS A WRITE UP FROM MEMORY, DID NOT REPEAT THE COMMANDS !!
DO NOT JUST COPY PASTE !!!
First be sure your RPI4 has the latest EEPROM firmware.
[root@rpi4 ~]# vcgencmd bootloader_version Dec 11 2020 11:15:17 version c3f26b6070054bca030366de2550d79ddae1207a (release) timestamp 1607685317
To update the EEPROM you need the lastest Raspberry PI OS. (I used the minimal without GUI)
On the RPI (OS does not matter now) downlaod the Nethserver image for the Raspberry PI: (At the time of writing RC2…)
decompress the image:
xz -d -T 0 -k Nethserver-7.9.2009-RC2-RaspberryPi-img.raw.xz
his may take a while… despite we are telling to use as many threats possible (-T 0) it seem to run just one.
now attach a loop-device to the decompressed image on the disk:
sudo losetup -f -P Nethserver-7.9.2009-RC2-RaspberryPi-img
in this the -f is for find a available loopdevice and -P attech the partitions too. It finds most probably the first loop-device meaning
/dev/loop0p2 should exist now
make an (arbitrary) directory for the mount point of the source image:
and mount the loop-devices attached to the NS-image:
sudo mount /dev/loop0p2 source sudo mount /dev/loop0p1 source/boot
Attach the SSD and partition it as you wish, but the first partition needs to FAT32 minimal 256MB (I made it 512MB), a second partition type linux. I like GPT partitiontables more (they live on both “sides” of the disk, you have an backup if you mess up) so used gdisk with this result:
[root@rpi4 ~]# gdisk -l /dev/sda GPT fdisk (gdisk) version 0.8.10 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 976773168 sectors, 465.8 GiB Logical sector size: 512 bytes Disk identifier (GUID): 85B4599F-8B98-4F9F-A907-70D2C33AE3EE Partition table holds up to 128 entries First usable sector is 34, last usable sector is 976773134 Partitions will be aligned on 2048-sector boundaries Total free space is 908615661 sectors (433.3 GiB) Number Start (sector) End (sector) Size Code Name 1 2048 1050623 512.0 MiB 0700 Microsoft basic data 2 1050624 68159487 32.0 GiB 8300 Linux filesystem
format the disks: (in here
/dev/sda is assumed to be the SSD check this!!)
sudo mkfs.msdos /dev/sda1 sudo mkfs.ext4 /dev/sda2
make an (arbitrary) directory for the mount point of the SSD and mount the partitions:
mkdir target sudo mount /dev/sda2 target mkdir target/boot sudo mount /dev/sda1 target/boot
copy the content from source to target
sudo cp -rp source/* target/.
(this takes a while… we are allmost done )
now we need disk-id’s (UUID) and the part-id of the new rootfs which is /dev/sda2 .
On my system: (Note this system boots without SD-Card hence it does not show up)
[root@rpi4 ~]# sudo blkid /dev/sda1: UUID="D17B-9F4F" TYPE="vfat" PARTLABEL="Microsoft basic data" PARTUUID="6995254a-06c6-44d0-ab93-b9fb910f257e" /dev/sda2: UUID="c64adf56-cf9f-46ef-9751-5f119dae26ad" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="45e458a4-8f16-4b32-a61e-45d34b51f28a" /dev/zram0: UUID="4e7e5bcd-c0aa-4c99-bc9c-f69743189e67" TYPE="swap"
edit the kernel command line so the kernel can find the rootfs, look for root= and change it to root=PARTUUID= and make it to fit your PARTUUID, Here is mine:
sudo nano target/boot/cmdline.txt
here is mine: (substitute your PARTUUID of /dev/sda2)
console=serial0,115200 console=tty1 root=PARTUUID=45e458a4-8f16-4b32-a61e-45d34b51f28a rootfstype=ext4 elevator=deadline rootwait
and edit the fstab to match your disks
sudo nano target/etc/fstab
Again here is mine : (substitute your UUID’s )
UUID=c64adf56-cf9f-46ef-9751-5f119dae26ad / ext4 defaults,noatime 0 0 UUID=D17B-9F4F /boot vfat defaults,noatime 0 0
Well you may want to remove the “first-boot” flag so you can reboot your RPI without running system-init.
sudo rm target/var/spool/first-boot
Poweroff end remove the SD-Card and power on again:
If your systems boots from SSD and you are happy:
IIRC it’s max 1 amp for al the USB ports combined IF you use a good => 3A power supply
USB - Wikipedia
Well… this seems “debatable”.
Wikipedia reports for USB 2.0, 0.5A each port; 0.9 for USB 3 (port A), 1.2A for BatteryCharging protocol, 3A for USB-C (without PowerDelivery enabled, which could switch to different voltage than 5.)
Ouf of that standards, some computers provide up to 1A on each port, USB 2 or 3 Type A connector (desk, tower, and so).
Sometimes, connecting a “greedy” 2.5 HD Drive make a Y-cable needed to feed enough power for controller and SATA drive.
Well, you should not connect a hyperfast random read/write 7200 rpm spinning drive;
also recommend to stay a way from m.2 NMVe SDD’s, waist of money used in a USB3 application and power greedy.
Out of curiosity attached 2 WD blue nand-ssd’s in a sata-to-USB3 enclosure and copied aprox 250GB of data without a glitch, wasn’t very fast in sata therms thought.
Run one RPI4 for quite a while as aarch64 build-node, which means quite a lot of disk read/writes while compiling without issues.
For testing this build-node is also used as a KVM/QEMU/Libvirt hypervisor to fire up armhfp and aarch64 vm’s with snapshots to go back and forth…
In short: Tend to say it’s tested and proven to work well
Thanks for your experience, @mark_nl but using WD Blue SSD is quite “cheating”
3.8 W of maximum consumption, AKA 0,7A@5 volt
Perfectly into specs without third USB interface
You are right, it was (is) a deliberate choice.
OK - have done what I thought was right and am up to the first reboot without the SD-Card and get to
Any idea what has gone wrong?
hard to say, best guess is the kernel cannot find the root_fs
Can you boot it from a sd-card and mount sda2 and sda1 again:
then look if it resembles a rootfs:
ls target/ (without the *) should look like this:
bin dev home lost+found mnt proc run srv tmp var boot etc lib media opt root sbin sys usr
if so… can you post the blkid’s :
and post your kernel commandline and fstab:
cat target/boot/cmdline.txt cat target/etc/fstab
I missed the PARTUUID= specification in the cmdline.txt. Put it in and all good other than I get given the default address of 192.168.1.1, despite the DHCP quite happily handing out a 192.168.178.xx address previously…
Did you remove the first-boot flag or is system-init already done?
I did as below:
So does this mean system-init isn’t done?
If you did this:
Yes after aprox 2 minutes it’s done…
Note: this is valuable information in the proces to go to “final”
the network scrips (ifup / ifdown) have problems with the eth0 of the RPI4.
In my case it works out fine as it did @royceb, but not all dhcp servers are the same,;
So we need to take more precautions after-all
I repeated it i.e. touched the file to create it and then rebooted - it didn’t seem to do anything extra or different. Is there a simple way to find out if it has done its work?
Secondly, if its not doing what it should with the ethernet, what should I do?
Do I even need to log in to the console, or should I just leave it for a few minutes at the console prompt and then try to connect via a web browser (assuming it gets the right address).
First the analysis what went wrong: during system init Network-manager is stopted and network.service takes over. In your case network.service was not able to fetch a ip from the dhcp server. system-init gave it the most common ip out there:
A hack to salvage your install:
And give it a fixed IP and network properties matching your situation:
here is mine:
DEVICE=eth0 BOOTPROTO=none GATEWAY=10.0.10.100 IPADDR=10.0.10.5 NETMASK=255.255.255.0 NM_CONTROLLED=no NSLABEL= ONBOOT=yes TYPE=Ethernet USERCTL=no
then restart network:
systemctl restart network
check your ip :
Go to the web interface (on his IP) and assign your fixed ip again there.
It all seems to be going OK now - many thanks for all your help.
Is there a better place to put all the raspberry pi nethserver questions?
Glad you are sorted out ! and as said the feedback is valuable
No it’s fine here, you may give the extra tag arm:
This triggers the arm team to have an look, and others know it may be arm specific.
Could you mark the write-up form my (poor) memory as the solution of the topic, after all it did get the RPI4 booting from the USB dive
I meant mark it a solution here:
So other people can find a answer quickly without reading the hole post.