Move/copying RPi mate 20.04 to usb preserving the drive contents?

[mccurly]

Hello everyone. First post here as an Ubuntu Mate Raspberry Pi 4B 4G user.

Is it possible to fully move/copy the OS to an external usb? How could this be achieved?

It is puzzling to me that some files on the current mounted boot partition are symlinks to files residing there as well. And being that the boot partition filesystem is a FAT32 fs, how could I workaround this puzzling feature?

I rsync'ed most of the files except the symlink ones which 'apparently' aren't allowed within that file system... And this makes me wonder in the first place, how come there are symlinks in the micro sdcard boot partition in the first place? And mind you, sdcard's boot partition is FAT32 as well...

Is there any way to replicate this and (maybe) therefore install the system onto the current ssd without having to flash it with the rpi-imager tool? (As I was saying with rsync maybe?)

Any other way without having to move all the current files residing on the ssd elsewhere?

Thank you in advance.

[M.aD]

Hello & welcome to the Ubuntu Mate Community

Do you also want to boot from USB? If so then i have to disappoint you, 20.04 doesn't boot from usb only 20.10.

USB Booting
Ubuntu MATE 20.10 and newer support USB booting, but Ubuntu MATE 20.04 does not.
https://ubuntu-mate.org/ports/raspberry-pi/

[dandnsmith]

/boot is part of the / partition, while the fat32 partition is mounted as /boot/firmware. All the symlinks are outside the /boot/firmware and so not subject to the fat32 restriction.
Its possible with rsync to perform the full copy as long as you preserve the overall structure with the fat32 mouted as part of the new /boot 'folder'
Derek

[mccurly]

Hi thank you, both @M.aD and @dandnsmith, I'm feeling welcome already.

Since I have already tried the road of 20.04 LTS I reckon I am going to push it a little further and see if "replicating" the structure of the / system to the external ssd drive, could I achieve my goal.

I'll post my findings back here in a while.

See you and thank you very much!

[mccurly]

Hello again.

I made it and thanks to @dandnsmith and @M.aD as well.

Actually it was really just around the corner 'sort of'... Because I wasn't really on 20.04 LTS (as I thought I was).

I mean, I had flashed 20.04 LTS alright but I had subsequently run apt-get dist-upgrade, and totally forgot that this would upgrade the system to its latest version. And that is 20.10...if I am not mistaken (again... )

Then, following the lead of @dandnsmith, I ran rsync on the / of the micro-sdcard (with its boot partition at /boot/firmware). This task was made from an updated arch linux system. I can post more details if needed.

Then I made the adjustments to the cmdline.txt file at the ssd boot partition to point to its own ext4 root partition (with the root=LABEL=... kernel parameter, and whilst there I added up the ssd case usb-storage.quirks=...:...:u parameter since my external ssd case is one of the uas boxes that doesn't play well with the RPi...).

Finally, I edited the fstab file to encompass all these changes and removed the x-systemd.growfs mount parameter the root partition of the ssd, because that was already accomplished (the root partition was already taking all the size it could take on the external ssd drive).

Then, I booted up and here am I...

One last thing before marking this topic as solved: Can anybody here advise me/suggest a better suited topic title? Since this was a mishap from the beginning... Even though misleading it still gives the solution to my original problem)... So if any of the fellow forum members / admins is watching, please lend your opinion or intervene as you see fit.

See you in a while.

Thank you.

[commissioningeng]

Cool that you achieved this.

I also want to do the same thing by moving 20.10 onto an existing SSD that has an unused fat partition, an unused ext4 partition and a fairly full NTFS partition so it would be good if you please give some more detailed steps. Probably there are also others out there who would like to do this.

The FAT partition was for EFI boot so it is sizeable, do I need to make it small ?

[mccurly]

@commissioningeng, hi and sorry for this (perhaps) late response.

I get that you want to somehow do the same thing that I did. But before jumping into more detailed explanations, could you please post the info from this command: vcgencmd bootloader_config?

See you soon

[commissioningeng]

Thanks for the quick reply.

BOOT_UART=0

WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41

I think it looks like this is OK for USB boot ?

[mccurly]

Hi again @commissioningeng,

mine looks like this:

Apparently, taking a look at the Rasbperry pi documentation for the bootloader configuration (here) ... If you take a closer look at that url, more precisely at the section concerning the BOOT_ORDER=... parameter, I'll quote ...

BOOT_ORDER

The BOOT_ORDER setting allows flexible configuration for the priority of different bootmodes. It is represented as 32bit unsigned integer where each nibble represents a bootmode. The bootmodes are attempted in lowest significant nibble to highest significant nibble order.

E.g.0xf41 means continuously trying SD card followed by USB mass storage. Whereas, 0xf12 means continuously trying network boot followed by SD card boot. The retry counters are reset when switching to the next boot mode.

BOOT_ORDER fields
The BOOT_ORDER property defines the sequence for the different boot modes. It is read right to left and up to 8 digits may be defined.

one should (perhaps ) conclude that the order of those hexadecimal numbers at the BOOT_ORDER=... parameter does matter. In my case, I remember that I had to swap the order of the 4 with the 1, and only then could I boot from my external SSD drive. What I mean by that is this: BOOT_ORDER=0xf14 instead of the default BOOT_ORDER=0xf41. Take a look at the sample shot of my own settings, that I shared above.

I think that it should suffice.

If not, just post back your findings and we'll proceed then ok?

See you soon.

[commissioningeng]

Hi @Mccurly,

I took the SD card out, inserted it into a usb card reader and plugged that into the usb3 port on the rpi 4b and it booted without the card in the SD slot so I think the eprom settings should be OK.

What comes next ?

[mccurly]

Hi again @commissioningeng, can you please describe with a little more detail what happens when you use the ssd drive without the micro sd card inserted?

Do you see the 'eeprom' POST () screen ?

What happens after that phase?

Does the boot process hang for instance?

Do you, by any chance, happen to have tried with that particular BOOT_ORDER=0xf14 setting?

Have you modified the cmdline.txt (on the SSD fat partition to hold information such as the one that I am illustrating below)?

(Mind you that the usb-storage.quirks=... parameter is needed in my case, but for you it may be unnecessary, and, if needed, almost certainly it should be customized with the correct VID:PID of your SSD USB adapter, that you can obtain by inspecting the results of either lsusb command and/or dmesg | grep sda before plugging it to the pi and moments after (as well).

Note, I changed that root=LABEL=materoot parameter according to my system, yours will be different. You can get that info by running blkid /dev/sda* and using either the LABEL=, UUID= or the PARTUUID= fields info (without the double quotes I think, assuming, of course, that you have only that one usb drive attached to the system).

Finally, you should update your fstab file on the root partition of your SSD drive to the correct information. That is, the root mount point there should now point to the root partition of the SSD, and the boot mount point should point to the SSD boot / fat32 partition. Mind you, I advise you to keep the mount points column, and do delete the x-systemd.growfs mount option. since it won't be needed and I am not sure if it would harm the rest of the root partition on the SSD.

Well, I think that's about it!

See you soon!

[commissioningeng]

When booting from the USB it goes though 3 steps

1. some sort of Bios screen flashes up.
2. blank screen for some time with the SSD activity light flashing.
3. displays the Ubuntu splash screen with the 5 dots and gets stuck there with the SSD light flashing.

I edited the fstab that is in the /etc folder, is that the correct place ? Mine reads root=LABEL=Linux as I gave the partition the label "Linux" and I removed the grow-fs.

[mccurly]

Hi @commissioningeng.

You've made a mistake. You edited the wrong fstab file AND in a wrong fashion, sort of say.

1.- You've modified the fstab file from the sdcard (you should've changed the one from the SSD drive)...

2.- you must edit the cmdline.txt file lying inside the boot partition of the SSD. You must change the fstab file from the root partition of the SSD as well.

3.- You have put the root=LABEL=... parameter of yours inside the wrong file. It should go to the cmdline.txt file, not the fstab one that I believe was your case. Be precise in what you do! Get acquainted with the formatting of both of those files. That format / syntax is different with each of those files.

All the best!