With the rpi2ZW sdcard unmounted you can make a copy if it with 'dd' to some file. It's by no means certain you'll be able to put that image back onto another sdcard of the same size because they are not always exactly the same size. If the target sdcard is even a single byte smaller than the original, 'dd' will error at the end. You'll likely get away with it though (fsck). If this is the first and only time you'll ever do this it's probably worth trying. You could use a larger sdcard for the new sdcard of course.
Otherwise:
There are a couple of tools which allow you to mount the image file as though it were a disk. The command I use is 'udisksctl'. I forget the name of the other one. This will create a "loopback" device. You could, at this point, create a another loopback device which is slightly smaller and experiment with methods to get the larger original loopback image into the slightly smaller new loopback device. There's 'sfdisk' (and other commands) which can do this from the command line. Note you can use gparted on a loopback device if you launch it from the terminal specifying the "/dev/loop?" device. Remember to undo the loopback before trying to 'dd' it back to an sdcard.
However:
Unless you desire to learn about the above (it will take a lot of time and is error-prone) just use one of the existing card copying tools. I tend to only use 'dd' to make an image of an existing sdcard. I might periodically shutdown my rpi DNS/DHCP server, rapidly 'dd' the sdcard to an image then fire it back up again. Then I compress the image. This is for older OS versions. Since bullseye I've been moving to 'rsync' but that has its own problems unless you're prepared to devote a lot of time into testing it can be restored.
Your (1) method is kind of what they do on servers. There's a stock OS image which gets installed then changes are applied. It's not viable to do this by hand: something will always be neglected. Arguably the progenitor of this approach would be the redhat "kickstart file" which has long been overtaken by Ansible/Kubernetes I believe. I have no experience of those tools but again, much time will be required to become proficient in them.
The method I used to upgrade my (x86) hypervisors was to not upgrade them at all. All the data is one place, the OS in another. They were both running centos. I created a debian virtual machine on my PC, then made that VM into a third hypervisor. With packages, settings and my code copied across, the final thing I did was edit its hostname to be the same as one of the real hypervisors then shut it down. I did a cold backup (clonezilla) of it. Then I removed the VM virtual disk and attached a physical SSD using pass-through to the VM, fired it up, (net booting clonezilla) and restored the cold backup onto the SSD. Shut down the VM. Shutdown the physical hypervisor. Replaced its OS disk with the VM SSD and it was back up and running soon after. The only way I managed this was because I made copies of every single file I ever edited from years back and (quite importantly) hypervisors can almost be considered stateless so there wasn't a lot to install. Couple of weeks later I restored that VM image to another SSD for the other hypervisor - only requirement was to edit the hostname on the VM SSD so even simpler. My distant plan is to experiment with having a couple of rpi5 hypervisors because most of what I run now doesn't need to be x86.
I do use "timeshift" on some rpi. Just shove a thumb drive in and have timeshift use that. Trouble is, it's a pig to restore a timeshift image on an rpi because the command line doesn't work. You have to write a GUI image onto an sdcard, install timeshift then use the timeshift GUI to trigger the restore onto the sdcard you just wrote. Even then, there's issues (rpi has no GRUB).
Summary:
"dd if=/dev/sda of=./z.img status=progress" will copy all of /dev/sda (partition table, contents and unused space) so will take an absolute age for a 256Gb sdcard, even longer writing it back and don't forget 'sync' or you'll end up yanking the new sdcard before data in the (ram) file cache has been comitted to the sdcard (hint: iostat to be paranoid).
Otherwise:
There are a couple of tools which allow you to mount the image file as though it were a disk. The command I use is 'udisksctl'. I forget the name of the other one. This will create a "loopback" device. You could, at this point, create a another loopback device which is slightly smaller and experiment with methods to get the larger original loopback image into the slightly smaller new loopback device. There's 'sfdisk' (and other commands) which can do this from the command line. Note you can use gparted on a loopback device if you launch it from the terminal specifying the "/dev/loop?" device. Remember to undo the loopback before trying to 'dd' it back to an sdcard.
However:
Unless you desire to learn about the above (it will take a lot of time and is error-prone) just use one of the existing card copying tools. I tend to only use 'dd' to make an image of an existing sdcard. I might periodically shutdown my rpi DNS/DHCP server, rapidly 'dd' the sdcard to an image then fire it back up again. Then I compress the image. This is for older OS versions. Since bullseye I've been moving to 'rsync' but that has its own problems unless you're prepared to devote a lot of time into testing it can be restored.
Your (1) method is kind of what they do on servers. There's a stock OS image which gets installed then changes are applied. It's not viable to do this by hand: something will always be neglected. Arguably the progenitor of this approach would be the redhat "kickstart file" which has long been overtaken by Ansible/Kubernetes I believe. I have no experience of those tools but again, much time will be required to become proficient in them.
The method I used to upgrade my (x86) hypervisors was to not upgrade them at all. All the data is one place, the OS in another. They were both running centos. I created a debian virtual machine on my PC, then made that VM into a third hypervisor. With packages, settings and my code copied across, the final thing I did was edit its hostname to be the same as one of the real hypervisors then shut it down. I did a cold backup (clonezilla) of it. Then I removed the VM virtual disk and attached a physical SSD using pass-through to the VM, fired it up, (net booting clonezilla) and restored the cold backup onto the SSD. Shut down the VM. Shutdown the physical hypervisor. Replaced its OS disk with the VM SSD and it was back up and running soon after. The only way I managed this was because I made copies of every single file I ever edited from years back and (quite importantly) hypervisors can almost be considered stateless so there wasn't a lot to install. Couple of weeks later I restored that VM image to another SSD for the other hypervisor - only requirement was to edit the hostname on the VM SSD so even simpler. My distant plan is to experiment with having a couple of rpi5 hypervisors because most of what I run now doesn't need to be x86.
I do use "timeshift" on some rpi. Just shove a thumb drive in and have timeshift use that. Trouble is, it's a pig to restore a timeshift image on an rpi because the command line doesn't work. You have to write a GUI image onto an sdcard, install timeshift then use the timeshift GUI to trigger the restore onto the sdcard you just wrote. Even then, there's issues (rpi has no GRUB).
Summary:
"dd if=/dev/sda of=./z.img status=progress" will copy all of /dev/sda (partition table, contents and unused space) so will take an absolute age for a 256Gb sdcard, even longer writing it back and don't forget 'sync' or you'll end up yanking the new sdcard before data in the (ram) file cache has been comitted to the sdcard (hint: iostat to be paranoid).
Statistics: Posted by swampdog — Thu Dec 05, 2024 11:23 pm