Hi all,
We are currently having a major problem with our OVH server not booting after a technician replaced a HDD which was failing.
It was configured in a software RAID1, which should boot regardless of having a HDD removed and a new blank one put in, but it won't boot. The EFI partition is not part of the RAID1 oddly, just the main OS drive.
Any ideas?
It's currently causing us a major problem as most of our services are down.
Many thanks.
Hello,
We do not use RAID on the EFI partitions at the moment as we need to make sure that it doesn't cause problems at boot with the various motherboard models we use. Instead, we install the bootloader to several EFI partitions: one on each of the disks selected for installation.
Do you see an EFI partition on the second disk, the one which was not replaced? I assume there should be a working EFI system partition there.
If none of the disks have an EFI partition or if the secondary EFI partition is corrupted, you may have to reinstall the Windows boot loader from the Windows Rescue system, see https://help.ovhcloud.com/csm/en-dedicated-servers-ovhcloud-rescue-windows?id=kb_article_view&sysparm_article=KB0063091. I'm no Windows expert but it looks like this is something which may be achieved with `bcdboot`.
Hi, already resolved this, but I'll detail how below using OVH Windows rescue. Please note how you're existing, working drive is partitioned. If it comes up as "Foreign Disk", you'll need to "Import" them before you can see them. Be VERY careful, one wrong command, and you could wipe all your data on the disk that remains! Get backups before-hand just in-case.
This shows you how to MANUALLY re-create the EFI partition. You can also do this on the EFI partition if it's become corrupt, but just remember your Windows partition will be on this drive already! Careful.
1). The new disc will be uninitialised, so initialise as GPT.
2). Use Disk Manager to create 350MB, or however big the EFI partition is on your other drive. This will be at the front of the new drive.
3). Use Disk Man to partition the rest, no need to format for now.
4). Remove 350MB partition.
5). Run "diskpart" and select the new disk, (make sure this is correct).
6). Then run: "create partition EFI". This will create the EFI partition on the new drive.
7). Then use diskpart to assign a drive letter as below:
(You need to select the correct Volume. List them in diskpart with: list vol)
sel vol x (replace the "x" with the correct number from "list vol" as above).
assign letter=v
exit
8). Once done, run the below on the new partition with the drive letter to format as FAT32:
format v: /fs:fat32
(You need to point the server's windows install, NOT the rescue partition! In my case, it was E:\Windows)
bcdboot E:\Windows /s v: /f UEFI
Now the important part! If you're using a Software Raid 1, you will need to rebuild the software array AND wait for it to complete. Can take hours on say 4TB HDD drive. As this new drive will be booting, it needs the data to sync back. If you have an SSD for boot and OS, it will be quick, and you can sort the larger HDD drivers later once you're back into your main Windows OS.
Once done, reboot using Server Boot HD and hopefully it's back up. Not the best guide, but it got me back up and running.
hello @le_sbraz we have a similar problem (though for linux server using OVH image)
we note the /boot/efi partition isn't on the raid - we are worried that is the disk with /boot/efi were to fail and we removed from the array the server wouldn't be able to boot.
Can you clarify the information you provided - are you saying it has been installed to the second efs partiton and will auto detect this? (even though there is not /boot/efs mount point to the second partition? would we have to update FSTAB to the other drive in the event the first one failed?
Can you provide any info or steps
Hello @tazau
> are you saying it has been installed to the second efs partiton and will auto detect this
Yes, when the OS was installed, all ESPs were synced by our system. Usually, the ESPs only contain a stub GRUB config file that rarely needs to be updated.
When a disk is changed, the rEFInd bootloader will detect the EFI applications on the secondary ESP and use them.
> would we have to update FSTAB to the other drive in the event the first one failed?
If you're using our default installation, we mount the ESP by its label and all ESPs have the same so you wouldn't need to change it.
However, I would still recommend creating a new ESP on the replaced disk, setting its label with `fatlabel` and syncing data to it.
Here's a script I provided that relies on labels to sync all ESPs: https://community.ovh.com/t/Partition-EFI-sur-raid-apr%C3%A8s-changement-de-disque/60512/9