After bad experiences with Ubunto, I tried Almalinux for installing a server for Llama. It went rather smooth. Serious problems only appeared when I wanted to clone the system onto another disk, to be able to stash away the original.
Did the normal dd copy using Knoppix live. Unfortunately, the copy bootlooped. I had to poke around in the EFI and grub stuff, pretty yucky. Then there was a systemd problem mounting drives which always stopped bootup. It went away after adding nofail to /etc/fstab. Now the copy boots and starts the servers.
So I’d like to ask: What is the recommended approach to clone a working system, be it for backup, or for deployment of more identically configured servers?
Isn’t knoppix meant to create live environments? (I looked it up, it is just a bootable live env)
Just a normal dd without using knoppix should clone the device bit for bit.
Or you can use some other application designed to clone a system like clonezilla.
But when cloning a system, you should as a rule of thumb do that from another system, ie for example boot a live usb and then clone the device.
You can boot into clonezilla, that is why I mentioned that, but any backup software designed to clone should work, but you def should do it without having the system you want to clone running.
Edit
Since you are doing it from a live env, what dd line are you using to make the clone?
Have you made sure the correct UUID:s are being used in boot and fstab?
That the uefi doesn’t boot it directly can absolutely be normal, but should easily be remedied by changing boot order in your uefi, or do you mean it does not pick up the distro at all?
Also, you should physically remove the device you cloned from before trying to boot the newly cloned device, because both devices will have the exact same PARTUUID, UUID etc so it will most likely confuse both boot and fstab.
Thank you for the suggestion. I downloaded and tried clonezilla. Unfortunately, it failed when attempting to mount a filesystem on the clone. Booting from the clone results in a blinking cursor + hang. So clonezilla seems not to work with Almalinux disks.
What I meant with my question is the following problem:
To make a clone, the first step is to dd the original disk over to another drive.
Next, with the original disk stashed away, boot up the system using the clone drive.
systemd fails to mount.home or the like
In the emergency shell find out the drive config (lsblk, blkid)
Then edit that stuff in /etc/fstab, grub, mount the EFI partition and edit there also, so that the old UUID has been replaced with the new UUID everywhere. Then run grub-mkconfig, efibootmgr and all that stuff before rebooting.
In particular part 5 is not trivial for me, had to google a lot. And it still is not yet clean. The need to add nofail only to make the clone boot clearly shows that not all necessary modifications have been done yet.
For this reason I asked for the exact steps necessary to produce a flawless clone.
Sounds strange, you should not have to mount anything to clone. Or rather you should not mount anything when making a clone. You read the block device, not the filesystem.
Did you choose clone or backup? With a backup, yes, things will be mounted, but with a clone it should not.
I don’t remember since it was a long time since I made an actual clone, but IIRC there are options (in expert mode) to choose weather to make a clone or a backup, but I could be wrong.
But using dd in a live env (like knoppix or the installation media for almalinux) should work just fine.
Well, that’s the thing, a dd is a clone, bit for bit, so the UUID should absolutely not change at all.
The nofail option in fstab simply states, “if not able to mount, ignore and do not mount” rather than “fail to boot if unable to mount”.
The question is how is UUID chaning when you make a dd, which is why I asked what exact line you use with dd.
And if fstab fails to mount, so will systemd.
Are you using encryption?
But to answer your question, using dd to clone does not have to be more complicated than sudo dd if=/dev/xxxx of=/dev/xxxx bs=4k, where /dev/xxxx is the device, not a partition.
a) The clonezilla working mode selected was disk→disk clone. It was clonezilla who did a lot of mounts/unmounts while cloning (to do the fine work regarding grub, /EFI etc. The clonezilla error message was, as it wanted to update initrd, it failed to mount /dev/mapper/almalinux-root.
b) The dd command I used:
dd if=/dev/sdx of=/dev/sdy bs=1M status=progress
Anyway, the UUID mismatch error regarded the /home partition/filesystem, which does seem to have no mapper. This is what does not get mounted. And yes, the nofail switch caused systemd to ignore that and continue boot after timing out trying to mount /home.
The user account that has been set up in the Almalinux installation thus cannot log in anymore. So the graphical login does no longer work. As I use the virtual consoles, which still work and allow root login, I do not care much about that.
I completely agree with you, the UUIDs should remain the same on drives that are identical bit for bit. But maybe the WWN or the like is part of the UUID calculation, and then ofc the UUID would change. Maybe this is the reason for Almalinux using /dev/mapper? Maybe this is what needs to be updated? But I really do not know, just guessing. So I have no idea what is normal and what is not.
I do not clone, except VMs on OpenStack, where cloud-init and OpenStack make cloned instances unique.
I do use Ansible playbook to manage machines. It has list of packages that I want to be installed and config for them. It could deploy additional files, like the Llama(?)
User data – both content of home directories and data in databases, web pages, etc I would rather copy/backup as files / database dumps.
Drop the clonezilla thing, I was just suggesting that because I mistakenly thought you were not cloning through a live env.
Should work just fine.
Curious. Is your fstab (and boot stuff) not set to use UUID=xxxxxxx or /dev/disk/by-uuid/xxxxxxx?
(I only use almalinux for an arm SBC, so I don’t have an installation to check against, that is why I ask)
If that is not the case, yes, /dev/xxxx can absolutely change, that is why it is recommended to NOT use that method.