I managed finally to find the time and the determination to clone my IPFire system in an external hard drive running on the USB 3.0 port. My purpose was to clone the system in a target disk with a different size than the source, so no dd mirror cloning, but using a manual and elaborate set of steps with the console which could be quite intimidating for a beginner.
I wanted to have a cloned system where I could safely install the testing version of IPFire so that I could help troubleshooting new upcoming versions. I am glad to say that I am writing this post using PFire 2.27 (x86_64) - Core-Update 174 Development Build: master/b7c95899 . So far so good.
This post is to ask the community whether there is interest for a detailed tutorial to accomplish my same goal. It would be quite time consuming, therefore I do not have the inclination to do it if there is no interest. Please give me a feedback and if there are requests I will try to transform my notes in a tutorial and post it here.
It would be nice to have more people trying the testing distribution and improve the reliability of new updates for the rest of the users.
I have cloned IPFire in earlier times, but for a different reason, to work around a crappy BIOS that insisted on a wierd CHS setting for HDD. As you point out, it is a technical and time consuming process.
It would be far simpler to backup IPFire settings from the 1st installation to a workstation, then swap drives and fresh install the testing version, following by restoration of the settings. All users of IPFire will need to fresh install, at some stage, when changes in default partitioning occurs or an update goes awry.
I generally have at least two working installations of IPFire, with one on testing release and I believe that most testers follow similar practice. I don’t think it worth adding a cloning section to the Wiki
You are 100% correct. This is how I normally do as well. From time to time, I install from scratch and restore. I just needed to do this procedure for another project and since I had the protocol fresh in mind, I did it also for IPFire to set an identical machine to run on USB. Also, I am curious and I wanted to see how different it would be for IPFire compared to Debian, and fortunately I learned few things that I did not know in the exercise. I also agree about the wiki, in fact I never intended to make a wiki section out of it.
One potential use of this protocol is for people that do backup of the disk using rsync or borg. I know there are few of them as it was mentioned here in the forum. In this case, to do a proper restore you must know how to deal with restoring the files to a different disk.
I would be interested in the cloning info. Currently all my testing activities are on a VirtualBox VM testbed with an IPFire system which can be cloned for testing or other evaluations and with Arch Linux vm clients 2 on green, 2 on blue and 2 on orange.
I only have one real live hardware installation (Mini Appliance) of IPFire and as a home user with only myself on the network 99.9% of the time, I have no plans to buy duplicate hardware for testing. I suppose I could get a second m2sata drive for the system and swap them round. There is only 1 msata connector on the system.
To be able to do testing using a usb drive, which can be used for booting with the Mini Appliance, would be a good alternative. Thinking about it now, I should be able to install to the USB system directly anyway.
The mini appliance also has an SD card slot which can be booted from so maybe that is another alternative I could use.
A friend of mine, with an apu1, modded the case and connected the sata port to a sata/mstata adapter. The modding is ugly, but functional. He cut open the case to allow the sata cables to be out, and attached to a piece of wood the adapter. Connecting or disconnecting the sata cables from the adapter allows him to boot one disk or the other.
I am not capable of doing these things so I finally went for the USB port of my APU2, and so far is working quite well.
yes, it is easy. I was just afraid I would make a mistake and FUBAR the internal msata drive during the setup stage.
Are you aware that dd is to clone on drive same size or larger, or to … image file.
I use a one liner to dd my drive to image file with on the fly compression .
I used dd many times to do these kind of things. Recently I cloned a failing hard disk this way (with ddrescue which is very similar to dd, very useful). The interesting part is, what do you do with that after creating the image in a disk that is way larger than the original? I guess you could resize it, but I do not like this approach of having to deal with an extra layer. Fine as an intermediate step, but ultimately I prefer to have the same drive as it was before, just with a proper resized partitioning, without any complication.
However, if you have a recipe to go from the image to a regular disk, in a way that is not just copying the files over, I am very interested.
you don’t end up with unused disk space? There are 4 partitions in IPFire, of which three are mounted in the File system. Even wanting to resize them with parted, it is not obvious to me how to proceed. I would love though to learn how to do that.
I used to enlarge a partition with gparted (a GUI of parted), which works quite well. Since the forth partition is the main one, I guess mounting the disk in a host system with a live gparted distro would allow to resize the fourth partition, assuming that the unused space is after the right boundary of it, leaving the other unchanged. I guess it could work. Thanks for the suggestion. I might try this in the future.
You are a making a mirror copy of the original disk in a larger disk. There is unused space. I want to use that space, therefore partitions are very relevant. I have a different goal, you are happy to make mirror copies, sector by sectors. I want to have the same content in a larger space. I hope you are getting my point because so far I have not been able to communicate it with you.
You could simply use dd to clone to a larger drive, then use gparted live to move & resize partitions, carefully following a suitable sequence. ext4 & vfat can be repositioned as well as resized, but some other filesystem types have limitations. The help in gparted explains.
I have used gparted in the past and it works well for growing a partition.
I think this should not be as complex as I thought before. Partition 4 is really the only one needing to be extended and when using dd to transfer a mirror image, it will start filling up the destination disk from the first sector. Therefore the empty space will be on the right hand side of the end of partition 4, making the resizing way more easy than I anticipated.
I think this approach would have the advantage to be simpler to implement than the rsync the files, adjust fstab, chroot into the target, and rebuild the grub boot loader, as I did now.
When I will get the time again to work on it, I will look to do it directly with gprted back end, which is parted. My intent is having a solution entirely done in the console (so, no gparted), better yet a solution that can be converted in a bash script. Anyhow, thanks for the helpful suggestion.