I have an Orange Pi 4 LTS that I have built a smoothly running Dietpi image on. It was built from an Armbian CLI distro that had been moved to eMMC via “nand-sata-install”. The conversation to Dietpi was simple and quick.
Now that I have completed the testing I built it for, I would like to make this SBC available to do additional testing for the Dietpi project.
To make this available. I would like to make an image of the eMMC so I can reinstall it at a later date.
The question is, how can I do this? I am not a linux/debian etc programming master. So, I will need fairly detailed instructions.
You could do it via the dd
command copying the eMMC contents to another location, e.g. a USB disc or an SD Card.
It then looks like
dd if=/dev/<eMMC name> of=<path and file name of mounted target location> bs=1M status=progress
To recover this backup file, also a dd
can be used.
Can you send your output of lsblk
that we could give more hints about the complete command line.
Depending on your system (with or without graphical user interface) it could be a good option to shrink the eMMCs partition, e.g. via gparted to get a smaller image file.
Best would be to create a clean new image on SD card and use this one right after DietPi transformation as base to build an image from, using our dietpi-imager
. This should be printed as information right after transformation finished. Why using an SD card? Because this will be easier creating an image from as it requires another linux box. Last line on our docs Supported hardware - DietPi.com Docs
Depending on your system (with or without graphical user interface) it could be a good option to shrink the eMMCs partition, e.g. via gparted to get a smaller image file.
better use to countswitch in dd, too :
- shrink the Datapartition wiht gparted to the smallest size (on the sdcard at an other PC)
- get in gparted with “information” the value of the last sector and notice it
- use the value of the last sectot for the count switch for dd (count=xxxxxxx)
command: dd if=/dev/<eMMC name> of=<path and file name of mounted target location> bs=1M count=<value of the last Sector> status=progress
- after this you can expand the datapartion wiht gparted on the sdcard.
That is the best pratice.
Yes, I have seen that info, but honestly, the instructions DO NOT make sense to me. It says on the last screen of the conversion to “Poweroff” the SBC, then run that script on a different PC. How is that going to work if the Dietpi SBC is powered off?
Should I just keep the SBC powered up, and then run the script on the separate linux PC? Does the script ask to be pointed to the new Dietpi SBC?
That’s what I tried to explain above to perform the install on SD card. This way you can poweroff the SBC, place SD card within another Linux box as USB drive and run the script.
Ah, now I see.
- Convert an image on SD to Dietpi.
- Power off the SBC.
- Remove the SD from the SBC, before doing the first boot process.
- Insert the SD into a separate linux PC, and run the script there.
- The created .img can be moved or stored as per user preference.
Return the SD to the SBC and continue to the First Boot as before.
Do these steps look correct?
1 Like
The purpose of the dietpi-imager is to create an image of you already set up system. Like you did the first boot installation of the system (or in your case you ran the install script over your existing OS) and then you did all the software installation you wanted and when you are finished with all that stuff, you can create an ready-to-flash image of this working system (for this particular device).
The problem is, you can’t do this on a running system (or at least it is not recommended), the copy process could be corrupt since files are changing on a running system.
So you finished your whole setup on eMMC. Then you flash dietpi (or any other compatible OS) on SD/USB and you boot from this.
Then you run the imager to create an image from the eMMC drive (the imager should a
OR
You do not install the system on the eMMC but on SD card, which you can simply take out and insert it to another linux machine to run the imager script (This is what joulinar meant, I believe. It’s easier because you don’t have to copy the content of the eMMC elsewhere, you can just take out the SD card)
BTW the imager script should take care of minimising root partition and filesystem
(https://github.com/MichaIng/DietPi/blob/master/.build/images/dietpi-imager)
1 Like
not necessarily. Aim is to create and shrink images of any status. However, if you like a master image (without configuration) to be able to share with other, it’s always recommended to create the image right after conversion.
yes. Theoretically every DietPi system or VM would fit to run the imager
Hello there !
I’m following up on this thread to keep dietpi-imager topics together.
It remains unclear to me what is the output of dietpi-imager:
- a .img file saved where ?
- simply a more compressed file system on the drive to be imaged ? In that case it should be followed by a call to dd ?
Thanks for clarifying. Having a full copy of the existing fully functional drive proves helpful
It does:
- Create new .img file from drive
or use an existing .img file
or use Clonezilla to generate a bootable installer ISO from drive for x86_64 systems
- Minimises root partition and filesystem
- Compresses the final image ready for release
https://raw.githubusercontent.com/MichaIng/DietPi/master/.build/images/dietpi-imager
Thanks for the quick answer. For some reason, I can’t find the .img file, or do not reach this point.
Would you like to share the last lines of the imager script? And was it finished successfully?
Thanks Joulinar, your questions guided me to the solution, I did not have enough disk space on my sd card. It is indeed not surprising, as my use case was to backup a large installation.
For reference, I resorted to the following solution:
Voila !
Admittedly, the creation of the archive takes a very long time though, so this kind of full image creation is only worth to save specific dietpi setups.
Thanks again to Jappe and Joulinar for their quick feedback, I hope these details will help the community
yes, it will be a fully compressed image of the entire system.