A full fc40 installation from img file

Ask Fedora
1

I have a Windows11 laptop, say LT1-WIN11+FED.

Partition nvme0n1p1is where the Windows boot stuff is. I made a 100GB ext4 partition, nvme0n1p4, and installed fedora 40 workstation withnvme0n1p4 mounted at / and with nvme0n1p1 mounted at /boot/efi, and no other mounts (so /boot is a normal directory, with nothing mounted to it).
Windows11, fedora and dual-boot etc all work perfectly. The fedora is fully updated, including kernel 6.10.11.

I made an image of the fedora partition, nvme0n1p4, let’s call it IMG-MYFED.

There is an identical 2nd laptop (LT2-WIN11) with the same BIOS version, but only the original OS, ie Windows11, on it (with tons of different setup, different updates, apps and data as it was used and evolved totally independently).

Now, if we skip the why for the moment (even if you think this is bonkers), my question is, can I create a new partition on laptrop LT2-WIN11 and somehow use the image, IMG_MYFED and a fedora 40 workstation “live CD” to add exactly the same fedora setup on LT2-WIN (with all specific app versions, tweaks for weird hardware, flatpacks, VMs, dev environemnts, settings, favourites, gnome extensions and their config, all the keyring stuff and docker & VirtualBox and other specifics - all of which took months to setup/fine-tune and would be a huge loss) all exactly the same?

I was thinking that I should create a new EFI partiton on LT2-WIN11 for the new fedoara installations UEFI boot mechanisms so there is nothing(?) shared with the Windows11 installation, and fix fstab from the image to mount it at /boot/efi.

Would appreciate all input/guidance that takes into account all the above.

2

Beware that there are IDs in the image that need to be unique for each running system.

I’m not sure of them all or where you can find them.

  • ssh system ID
  • machine ID
  • DHCP lease will have been saved and mean both system attempt to use the same IP address
  • Others…

Personal what I do run the installer and login and run a bash script to complete the installation of apps and config.

At scale I would be using customised kickstart to do the installs and something like ansible to do the post install config.

3

@barryascott - thanks for the insight re ids and tips re planning ahead for such eventualities/requirements.

If I was doing this in a planned, sensible, controlled way, I agree that having a script could make it a bit easier, but this is not like that (in reality it is much more of an emergency) and it would take me months to get back to the exact system I had, if I could ever even remember all the stuff I had to do to get all the hardware working, all the apps and versions that I need and their settings and loads of other stuff I partially listed previously.

What I want to know is if there is any way I can get that partition restored onto the new machine and retrofit a boot mechanism around it so it looks exactly like the way it as on the original laptop (albeit with the proviso that I would have to go in via a live disk and try to fix the unique ids you brought up, and no doubt some other stuff too people might be able to warn/advise about).

4

I’m not sure about the steps to get the image working, and I’ll not guess.

In case it helps.

You can get a list of all the packages you have installed from rpm -qa.
If you use flatpak’s then list which of those are installed.

All your config will be in /etc somewhere.

With the list of RPM you can diff a list from the old system against the new and dnf install any that are missing.

I’d do the same with the config in /etc, diff the new systems /etc against the old /etc and see what changed.

Backing up and restoring /home will get all your user’s customisations.

That is what I do when faced with the situation you are in.

5

I have all of that (since the old partition is still intact, afaics from mounting it in a different fedora instance) but some of what you recommend needs to be running the fedora instance I can’t get in to properly, and much of the other stuff I listed is not as easy to rediscover (even if I could get back in!). But, I am trying a few more things, and have asked about specific solutions (eg convincing the boot mechanism to use another partition for /) I still want to give more of a chance to, before, in the end, I will have no choice to do something along the lines of what you suggest. Thanks again for the positive, solution-orineted approach.

6

I don’t think you should or can have two efi partitions.

Your /boot is already contained in the image of / (p4) since it’s a normal subdirectory in your case. So, what you are missing on the new (target) machine is anything fedora-specific in /boot/efi.

On the old (source) machine, possibly using a live ISO, I would:

  • check EFI boot order etc using efibootmgr and the like
  • backup /boot/efi (you might need EFI/fedora in there only)

On the target machine, using a live ISO:

  • (make room for and) create a partition for your /, at least the necessary size
  • restore your / there
  • backup the EFI partition
  • restore your EFI/fedora to the EFI partition of the target machine
  • possibly restart and check/modify EFI boot order using efibootmgr

I would hope that most references to the filesystem are by UUID, which remains unchanged here. grub and fstab are possible candidates where you may need to change device names if your new / is not on /dev/nvme0n1p4.

Alternatively, reinstalling grub may reinstall the efi bits, but I’m not sure about this one.

7

@mjg - this is pretty much in line with what I have been trying to do for hours/days now, and I still think it should be possible. And your logic is sound, to my ears. But I still feel something is missing, or I would have had it by now.
Partitions are referenced by UUID in most places I have seen so far.
I have been maintaining fedora, Microsoft and Boot under /boot/efi/EFI since I can’t drop Windows yet.
Restoring the old partition is the easy bit.
I too think that a clean reinstall of grub2 with everything else in/pointing at the right place might fix everything but I have not achieved that yet.

8

Except the UUID for /boot (the main fedora partition) will be different and grub will need a simple fix to correct that. The file /boot/efi/EFI/fedora/grub.cfg is a pointer to the file /boot/grub2/grub.cfg and uses the UUID to identify that file.

With that change so it points to the proper device partition your fix seems like it should work. Grub would also need installed on the new laptop so it can take over the dual boot process and that would be a little more than just transferring files.

9

Yes, but first transfer all the files, then after booting to a live usb image for fedora mount the fedora file system and /boot/efi and chroot into the installed fedora OS. From there do the grub reinstall.
The steps I would suggest would be

  1. boot to the live image and open a terminal window
  2. su (since every thing from here on will require root privileges)
  3. mount <your fedora partition> /mnt
  4. for SYS in sys proc dev run sys/firmware/efi/efivars ; do mount -o bind /$SYS /mnt/$SYS ; done to mount all the required pieces.
  5. mount <your efi partition> /mnt/boot/efi
  6. chroot /mnt
    At this point you would be in the installed OS environment as the root user.
  7. rm /boot/efi/EFI/fedora/grub.cfg /boot/grub2/grub.cfg
  8. Now it should only require reinstalling all parts of grub to make the proper configs. dnf reinstall 'grub2*' 'shim*' 'efi*'
    This reinstall may be overkill but should not hurt.
10

I was not explicitly doing rm /boot/efi/EFI/fedora/grub.cfg /boot/grub2/grub.cfg, so this gives hope again, thank you!

The rest is almost verbatim except step 3 I had to mount somewhere other than /mnt (presumably where the mountpoint is is not significant as long as it is consistently used instead of /mnt everywhere) and your step 4 loop is fancier than my one at a time.
I hope to to try again shortly, thanks!

11

If those files already exist they do not get updated. When removed they are built new according to the existing file systems and should contain the proper data.

Note that /etc/fstab (in the chroot environment) should contain the proper UUID for the efi file system. As soon as you have entered the chroot environment that should be edited for proper mounting when you reboot

Another step I overlooked is the creation of a new initramfs image for the new environment. dracut --force --kver <latest installed kernel version> should manage that and would require both the update to /etc/fstab and grub before running dracut. The kernel version info would be in the same format shown when using uname -r but the live install image would probably be using kernel 6.8.5 while
the installed kernel is probably 6.10.10 or similar. You can see what is installed with dnf list installed kernel. Use ‘man dracut’ for more information.