I have a dualboot with Windows 10, and the IT people deleted the Fedora boot partition, while restoring windows itself (long story).
So the result is that Windows boots, but Fedora doesnt.
I tried a Windows tool to make the Windows Boot Manager boot other OSses, but it didnt detect any OS. The UEFI also has no boot partition listed, so the Fedora boot is really gone. In KDE Partitionmanager I also couldnt find an option.
I have a live USB Fedora KDE stick, as you can actually use that live. On the Laptop is Kinote, with the boot partition deleted. I can access all my LUKS files through the LiveUSB, but made lots of configs I wouldnt want to delete.
How can I copy the boot from the live USB to the install? Or is there another way?
Or is there a good way to copy all KDE configs (system stuff I will have to redo) and reinstall the OS?
I think this question is too specific, with OSTree and all, to find solutions elsewhere.
I googled restore linux bootloader fedora and got many different pages, most of which look like reasonable answers to your question.
Iâve never tried any of those myself, because I work with a bunch of different computers with fixed and removable bootable copies of Fedora and I know what goes where (for EFI boot systems) and find it easier to just copy the destroyed files back to where they go.
However you go about fixing that, you need to start by knowing whether you are booting EFI or legacy.
I donât know what you mean by that.
There if you are using UEFI, there is an EFI partition (or you would not be able to boot Windows). The EFI partition should have a directory in it for Windows and a directory in it for Fedora. Do you mean that partition doesnât exist (so you are booting Windows in legacy boot) or do you mean there is no fedora directory in the EFI partition? Or do you mean the BIOS boot menu has no entry corresponding to that Fedora directory (even though it exists)? Or what?
Typically, the grup.cfg file in the fedora directory in the EFI partition identifies the boot partition by UUID. Typically there is a boot partition for fedora. But other configurations are possible. Your original dual boot may have had /boot as a normal subdirectory inside / and the above grub.cfg pointed there. The main grub.cfgis within /boot and found using the stub grub.cfg mentioned above.
If the whole problem were deleting that boot partition, your symptoms wouldnât fit.
If you canât just follow one of the instructions found by the above google search, then posting details of your current partitions would help someone understand your problem and give less vague instruction. A screen clip from any Linux partition manager is one way to show us details of your current partitioning.
To add a tiny detail to the above.
A repair of windows boot basically seems to disable using grub to boot and the system will only boot windows.
If you boot to the live media you noted then you should be able to see exactly what exists on the disk.
Windows should have 4 partitions for a normal uefi boot.
Those would be
hidden
EFI
OS
rescue
Installing fedora should then give you 2 additional partitions with an automatic partitioning install.
/boot (ext4)
btrfs containing the root and home subvolumes.
If you run sudo fdisk -l it should show those 6 (or more) partitions. lsblk -f should also give you that info and maybe more.
If all those partitions exist then It would be reasonable to say that the boot partition (EFI) was not deleted but that instead grub cannot be accessed to boot.
If that seems the case then it would be reasonable to believe that booting to the live image and mounting the installed file systems with a chroot into the installed environment would allow one to repair grub to boot both OSes.
I like the format of lsblk better, but Iâve used some live linux images that donât have it and installing it after booting may be inconvenient and of course doesnât stay through the next boot (vs. fdisk that seems to be included).
More importantly, the unpartitioned space may be important in diagnosing and correcting the problem of this thread, depending on what really is behind the phrase âdeleted the Fedora boot partitionâ. Some methods of showing partition info (including fdisk) let you deduce the size and position of unpartitioned space. Others donât. So far as I understand, you canât see or deduce unpartitioned space with lsblk
Thanks! So in the Efi partition is no Fedora entry. Before, when Windows was gone, there was no Windows entry. This means there also is no way to boot into Fedora.
Thanks for your responses! I already tried finding unallocated space, KDEs partition manager is really good.
The place of the boot should be the one used by ostree, will have to look that up. I will see what fdisk tells me, but as there is this hidden partition I think there is no unallocated space. But I will quickly look
It would appear that your system may have all the data, but also may need repair.
nvme0n1p1 is the efi partition
nvme0n1p5 seems to be /boot
nvme0n1p6 seems to be the btrfs with the root and home subvolumes.
This may provide some pointers on how to recover. Read through the linked thread as well since that has pertinent info.
Rather than how the BIOS sees it, Iâd be more confident if we saw what was actually there.
I should have suggested you mount /dev/nvme0n1p1 (your EFI partition) and look at it in Linux (tree would be a bit verbose, but acceptable for that, or a gui file explorer or just looking in a few spots with ls). That was harder to suggest before seeing your partitioning.
It does seem like the fedora directory is missing. I would copy the fedora directory from a different systemâs EFI partition and then edit the UUID in the grub.cfg in that directory and likely it would all work after that. But that is me. The above mentioned online instructions are still a good choice. To follow those you need to know that
/dev/nvme0n1p1 is your boot/efi partition /dev/nvme0n1p5is your boot partition /dev/nvme0n1p6either is or contains the / partition you will chroot to after setting the others up below it. (sorry, I know nothing about luks2 so Iâm ambiguous to avoid the risk of being wrong).
Anyway, my guess that unpartitioned space might be relevant was wrong and your belief that the boot partition was removed was wrong. Best guess, the fedora directory of the EFI partition was removed (Iâd guess they deleted and recreated the whole EFI partition).
Since you know how to access the files in your luks2 from the liveUSB, you know (and I donât) how to chroot to the right spot in it matching / in your normal system (after binding boot and boot/efi corectly under it). That is the only non obvious part of following any of the instructions mentioned above.
As mentioned in the instruction Jeff linked, if the EFI partition has been deleted and recreated, then its UUID is new, so it needs to be fixed in /etc/fstab. Compared to some of the other online instructions for this, that one is a bit light on details of setting up for chroot, while some of the ones clearer about setting up for chroot miss the detail that the UUID changed (I sure forgot that detail before following Jeffâs link). (That is a different UUID issue than the one I mentioned for doing it the way I would myself without chroot)
If you do it the way I would, you need to know two UUIDs:
The UUID of EFI ( /dev/nvme0n1p1) must be edited into the right place in /ect/fstab inside your luks
The UUID of boot ( /dev/nvme0n1p5) must be edited into /boot/efi/EFI/fedora/grub.cfg
The hard part is that first you must copy the /boot/efi/EFI/fedora/ directory from somewhere. I donât know whether your live USB has that.
If you do it the normal way, only that first edit step is required because the whole /boot/efi/EFI/fedora/ directory will be created automatically.
The hard part of that method is getting the right things mounted in the right places before doing the chroot
Okay so I would try to just edit the UUID of the EFI, because Windows changed that, into my /etc/fstab, add the boot entry (how to get that?) to the efi file and then do a grub2-install?
NO
Read this about managing the grub boot loader. That command is only for use with legacy booted systems and does not work on a UEFI booted system.
In fact, if you have booted and done a proper chroot so all the proper partitions are mounted where they should be â (/, /home, /boot, /boot/efi) â then removing the files /boot/grub2/grub.cfg and /boot/efi/EFI/fedoar/grub.cfg followed by a reinstall of the grub files dnf reinstall grub-common grub-efi* should reinstall the appropriate files and rebuild both those files with the proper data so you do not need to edit them.
As long as your /etc/fstab file is correct and both those grub.cfg files are properly built then it falls on to the bios to properly recognize and boot the OS.
The links I provided in post #7 ends with repairing the bios link to grub after all else was done.
Do you mean the boot partitionâs UUID in /boot/efi/EFI/fedora/grub.cfg?
If not, I have no idea what you mean.
If you use the dnf reinstall grub-common grub-efi* method Jeff suggested, that will create /boot/efi/EFI/fedora/grub.cfg for you including the correct UUID. You only need to verify that /boot/efi/EFI/fedora/grub.cfg doesnât exist before doing that.
I think we are expecting that all of /boot/efi/EFI/fedora will be missing. So just verify that. You canât delete /boot/efi/EFI/fedora/grub.cfg when the directory it would be in doesnât exist.
I wonder whether boredsquirrel knows how to find the UUID. If not, there are many ways.
I usually use lsblk, such as lsblk -o NAME,UUID but I expect that isnât installed in your live image.
In gparted you can select a partition and right click and select Information. That will include the UUID
In KDE partitionmanager right click on a partition and select Properties. You want the UUID, not the âPartition UUIDâ. It displays both.
True, and if that is the case, simply by having â/bootâ and â/boot/efiâ mounted one can run dnf reinstall 'grub2-*' 'shim*' and it will rebuild everything grub related for the entire system including the shim files needed.
