It might work, but probably not without a little tweaking.

A lot of things will reference drive identifiers or drive path to know where to mount them. These things don't get copied by dd.

You can just use `# cat /dev/your-disk > /dev/your-stick, no need for a (dd) scalpel there.

If your system uses UUID's in /etc/fstab, you have to change them to match the current partitions to have it bootable. lsblk -o+UUID is nice for that.

#Big tip: use chatGPT to help you with commands.

You can say something like "I want to backup my entire file system using [this program]. I want to create a tar file, and then copy that to an external drive. I want the program to display progress while it's copying, then verify the files have been copied correctly once it has finished. I am using [whatever distro]. Please give me the commands I need to achieve this."

Then it will spit out the commands you need to input with the correct syntax.

The best part is that you can then ask it to clarify any parts of its answer so you can learn how it all works and make sure the commands are doing what you asked. And if your computer spits out an error, just paste that back into chatgpt and it will help you resolve it.

Seriously, chatgpt is like a 24 hour on call Linux guru friend. It's saved me so much time and effort over the last few months doing things like this.

First tar up your filesystem. You can use gzip to save space. Once that's done copy it over. Make sure you use a good filesystem on the USB device that isn't going to cause data loss. (ie not fat)

Keep in mind that you can't do this live and that copying the archive over will take time and the drive may lie to you. Its always best practice to run sync or eject before unplugging.

you can copy your system live, but that would involve other tools than dd too.

with dd when copying the whole device (instead of just partitions) everything gets cloned. This includes uuids, labes, lvm devices with the names of their lv and vg names and raid devices in case you have any. all of these (c|w)ould collide unless the original disk was taken out or either the new or old disks labrls uuids etc are previously to the boot changed to prevent collusions or accidently mounting/booting the original partitions. also if (!) you use device names i.e. in fstab, crypttab, scripts or such, like with the uuids things could break. also you might have to take action for your bios to actually boot from the stick. most people disable usb boot on notebooks for security reasons.

using dd, cloning the full disk to the full stick, then removing the original disk + set bios boot setting might work out of the box, i'ld try that first as it takes only the effort to boot from another os to do the dd-copy offline (preventing filesystem damage while copying).

a live copy could be done by cloning only the partition layout and bootloader, then setting up new filesystems (with new uuids) and new lvm group/volumes etc if any, copying original disk using rsync then (maybe "bind" mounting to separate partitions if needed), then adjusting boot config to match new uuids/labels. This could be done while running the system to be copied, but of course even running rsync twice might lack some updates of currently open files by sth like desktop programs or logfiles.

Without knowing the exact setup, only limited answers can be given, but you have to make sure the boot process will work, so at least the boot loader (grub?) and its files will be needed, which -at least in the past and for old lilo/grub- could not reside at some position on the disk after some "high value" like some number GBs. if that limitation is still there, your new exact partition layout on the usb stick might be relevant for success, but try/error should give you the hints you need.

you might use "language models" for getting hints, but they are language models, not friends, their "solution" might break your system and delete your data, and they are trained to say they are sorry afterwards, but the are'nt sorry, its just a sequenze of probabilities and words to them not more.

So always only work on data that has been backed up and prooven to be suitable for you to recover everything you need from scratch, no matter if friends, language models or lemmy users assist you ;-)

UPDATE: just learned that batocera is "designed" to be just copied to usb stick and run from there, so it will most likely already include everything you need. best is to follow their instructions how to create the usb stick to boot from. if you already have it running from partition, you most likely can copy your current data using rsync. but beware, if you have two copies with the same uuids (partition +usb) that might not work as expected.

If you dd your entire laptop drive to the entire flash drive it should be able to boot. It might not work the same with just one partition though. Also, how big is your USB stick!?!?