You are not logged in.
All, I am writing this post to hopefully also help other people, but mainly also to recap what I went through to recover a completely lost /boot partition, as I have seen this question pop up from time to time while searching. My contribution is that I fell into a couple of pitfalls and below is how I addressed them.
Solution:
I think the general idea is that if you loose your /boot partition, no matter the reason, the main idea is to get a hold of a live usb arch installation and recreate it with the latest linux kernel and re-run fstab and reinstall the bootloader. I think this is still true but I ran into a number of issues in doing so.
Why the boot partition was lost in my case:
I have a development box that has 5+ operating systems, this is to be able to test hardware on all. The OSs have access to nvidia cards as well as other video and sound equipment. It is just cheaper to do it this way. Virtualization is not an option as it has performance degradation and not a real-life testing situation. The OSs are: redhat, ubuntu, windows 11, windows 10 and the one who has saved my skin so many times: arch. In general it is easier to have each OS on a separate disk and even linux'es have their own separate efi boot partition. This mostly works, except my windows 10 installation crapped out and I had to reinstall it. Now, this is why people hate this OS, I disconnected all drives and installed windows 10 on its own separate disk. Isolated. I had to install items on it and after I was done, I reconnected all other drives. I am unsure why, but arch-grub disappeared completely after this from the motherboard UEFI boot menu. I have no explanation to this, but I am assuming windows 10, writes to non-volatile RAM on the motherboard when installing, and the foreign OS entry got deleted, however ubuntu(grub) and redhat(grub also) were fine, so I am unsure why only grub-arch disappeared. Here it is where it went sideways, while checking the different boot managers I found out some had errors, including some did not mount at some point earlier in the year and an automated script I had written to update and control them wrote to /boot partition info inside the mounted root partitions, that is, the root disks had a /boot folder with bootloaders, fstabs were wrong and some kernels were out of date. Arch's boot entry was now residing in a windows 11 EFI partition as well as the ubuntu one. I am not going to touch windows bootloaders, but at this point, I wanted to re-create a grub arch partition in a specifically designed partition in a disk with arch to be clean, accurate, updated and organized.
Issues I ran into:
1. My arch live usb was 1 year old. For all the above OS's I have live usb's that are years old and help me get going, and I just assumed Arch would be ok to use from a year ago, since it downloads the latest packages anyway, but I was wrong. As soon as I setup the boot partition and tried to install the linux package (either with pacstrap -K /mnt linux or inside chroot and pacman -S linux), I had keyring /pacman issues, because they were not trustworthy, this was either from the usb directly or chroot'ed into the existing arch root partition. I had to recreate the live usb to the absolute latest. This fixed the pacman issues.
2. Kernel mkinitcpio was erroring out by not finding any of the modules that I knew were in the root partition. Especially the modules for the hardware I mentioned at the start. I am unsure why the installation was updating the arch kernels just this week normally (looking for the modules in /usr/lib), but with the new live USB, it was looking for them directly in /lib. I am not sure why, but creating a symbolic link from /usr/lib to /lib fixed this.
Once I figured the above two, I was able to create a /boot volume along with fresh vmlinuz images and grub and boot back normally into arch. And after working with redhat, ubuntu and windows, I think arch is the easiest to recover, by far. If a Windows bootloader gets corrupted, I don't believe it is recoverable, or even diagnosable. But reading the documentation and forum messages made it not only feasible in arch, but relatively fast and easy. Did so in less than a day. As for redhat and ubuntu, I think the general idea is to follow arch's guidelines, however redhat doesn't have a live usb that allows to fix the boot volume, while ubuntu could, but I don't think it would be as clearly documented as arch.
Anyway, thanks again for all volunteers that chime in to rescue installations, this helped me out today! Thanks!!
Offline