1

this may sound stupid and appear to have a bunch of duplicates but I have spent almost 3 days looking for a solution without look, see, I accidentally issued a mkfs.xfs command on /dev/sda2 instead of /dev/sdd2 and completely wiped my /boot partition (along with all vmlinuz and initrd files), and so I tried the standard recovery method from live media (with a few changes since my system was installed with LVM partitions and in EFI mode):

mkdir /mnt/fedsys
mount /dev/fedora/root /mnt/fedsys
mount /dev/sda2 /mnt/fedsys/boot
mkdir /mnt/fedsys/boot/efi (I had to create a new efi dir since it was lost)
mount /dev/sda1 /mnt/fedsys/boot/efi
mount --bind /proc/ /mnt/fedsys/proc
mount --bind /sys/ /mnt/fedsys/sys
mount --bind /dev/ /mnt/fedsys/dev
chroot /mnt/fedsys

It worked fine up until here, then I tried regenerating the grub.cfg file:

grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

However it fails with the following messages:

WARNING: Failed to connect to lvmetad. Falling back to device scanning.
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
device-mapper: reload ioctl on osprober-linux-sdd1 failed: Invalid argument
Command failed
done

I then ignore the errors and proceed to install grub:

grub2-install /dev/sda

And it gives the following output:

Installing for x86_64-efi platform.
EFI variables are not supported on this system.
EFI variables are not supported on this system.
Installation finished. No error reported.

And when I reboot I am greeted with the grub prompt. Now, I think the problem lies in the fact that either vmlinuz nor initrd are anywhere to be found (of course, because I nuked /dev/sda2) but I can't find a way to either rebuild them or make the system boot.

What can I do? Is there a way to rebuild those files from live media? The system I'm trying to rescue was running Fedora 25 64 bits on EFI mode and on LVM.

Improve this question

3 Answers 3

Reset to default
2

Here is a generic method you can try to fix your system. Package names might vary between distributions so you might need to google some specifics.

  1. Boot into the live media
  2. Mount your hdd root partition somewhere (for example /mnt).
  3. Mount all system-necessary partitions inside this root - your /boot and any other you might have.
  4. Mount with -o bind folders /dev, /proc and /sys from the live media root into your hdd root in /mnt
  5. You can now safely chroot into your /mnt. It should give you a fully functional system.
  6. Reinstall grub package and either run mkinitramfs or better yet reinstall linux kernel as well.
  7. Generate your grub configuration and install grub into MBR (if you use it), you should have all that is necessary now.
  8. Exit the chroot back into live media and umount all in reverse order.
  9. Try to reboot into your original system.

Edit: By chrooting you enter environment of your local write-able disk installation. All libraries and executables are used from this environment with the exception of already running processes and kernel - so you will be able to use your installed package manager and package database. Mounting /dev, /proc and /sys is necessary to give you access to the hardware and control over processes, you will need it in order to generate new linux image in /boot, configure grub properly and access the network to download the packages. Chrooting is especially useful if you had to use the live media from another distribution.

As for reinstalling grub - package names could differ between distros, reinstalling grub* can't do any harm though. Don't forget that just installing the packages might not be enough. You might also need to run grub-install after you setup your configuration.

Improve this answer
1
  • Specifically which grub package should I reinstall? Or just dnf reinstall grub*? I don't know much about chroot but wouldn't installing packages only applies to the live media? or are they actually being installed in the underlying (chroot-ed) system? would it be using the mounted root's dnf lists or the live media's?
    – arielnmz
    Jul 27, 2017 at 15:52
2

I had a similar problem, where I accidentally deleted the boot partition. The answer by @Marek proved very helpful in may case. For reference, I will write the commands that I used (since @Marek's answer was generic, I had to search online for some commands)

I have a Fedora 30 PC. The boot partition is on /dev/sda3 and the root partition is on an LVLM named Fedora-root.  I ran all commands with the root account.

  1. I booted from the Fedora live media (from a USB drive)

  2. Mount my root partition

    mount /dev/mapper/Fedora-root /mnt
  3. Mount my boot partition 
    mount /dev/sda3 /mnt/boot
  4. Copy the kernel from the live partition to the intended boot partition 
    cp /boot/vmlinuz-$(uname -r) /mnt/boot/
  5. Mount system partitions 
    mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
  6. Change root to /mnt 
    chroot /mnt
  7. Generate the initramfs 
    dracut /boot/initramfs-$(uname -r).img $(uname -r) -v
  8. Re-install grub and re-configure it 
    grub2-mkconfig -o /boot/grub2/grub.cfg

For some reason which I don't know, generating the initramfs was very slow and couldn't finish on my system (step 6). However, the command worked normally when I didn't chroot the filesystem. So, I skipped the steps from 3 onwards. I also had to modify the dracut configuration to point to the root system.

So, the new steps are:

  1. Point to the root location in the dracut configuration 
    echo "root=/dev/mapper/Fedora/root" > /etc/dracut.conf.d/kernel.conf
  2. Re-install the kernel and generate the initramfs 
    dracut /dev/sda/initramfs-$(uname -r).img $(uname -r) -v
  3. I then followed steps 3-6 above, so I can rebuild the grub configuration (this step may be not needed, I was over cautious) 
    mount /dev/mapper/Fedora-root /mnt`  
mount /dev/sda3 /mnt/boot
cp /boot/vmlinuz-$(uname -r) /mnt/boot/
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
chroot /mnt
  4. Re-install grub and re-configure it 
    grub2-install /dev/sda
grub2-mkconfig -o /boot/grub2/grub.cfg

Note for NVIDIA owners
I have a NVIDIA GPU, and I had the proprietary drivers installed before the incident.
The restored kernel from the live media used the Nouveau drivers (as it is the default driver in Fedora). The restored kernel was also not the latest version. When I updated the kernel afterwards using the GUI interface, it used the NVIDIA proprietary drivers.

Improve this answer
2
  • 1
    Re-install the kernel How did you do this exactly? one of my problems was that I couldn't install any packages because dnf was complaining about the environment while chroot'ed
    – arielnmz
    Jul 5, 2019 at 22:55
  • I just copied it from the live media /boot. I also failed to install it via dnf. I will modify the answer to illustrate this step.
    – hnagaty
    Jul 6, 2019 at 7:45
0

I suggest you try boot repair disk first,it will repair most of MBR problems.. This article may come in handy too..https://www.linux.com/learn/how-rescue-non-booting-grub-2-Linux

Improve this answer
1
  • Slight correction on @Marek's post you also need mount -o bind /dev /mnt/dev (this is why lvmetad is failing it's needed bits are in /run)
    – linuxdev2013
    Aug 1, 2017 at 12:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.