0

I recently installed Ubuntu onto an SSD in a Gen8 HP Microserver. It worked perfectly fine for a few weeks, but now it won't boot.

Randomly one day it started refusing to boot, giving an error along the lines of 'no system disk or disk error'.

I managed to boot off a Ubuntu LiveUSB and from there could access the drive and all of its contents, so the disk appeared healthy.

I tried running Boot Repair but it made no difference.

I attempted to wipe the drive and reinstall Ubuntu - the first time it failed citing 'unable to install the bootloader at the desired location'. The second time, it appeared to install fine, but I still can't boot into it - the BIOS doesn't seem to find any bootable drives and then starts trying to boot from NIC.

Any suggestions as to what I could try, or is it likely a faulty drive?

Pete Williams
  • 101
  • 1
  • 1
  • Have you checked so your microserver does really boot from you SSD? Do you have the SSD in instead of you CD drive? – Orphans Sep 27 '16 at 09:32

3 Answers3

2

Your GRUB isn't being installed to the disk properly. This is usually due to buggy firmware or something related to that. OR you could have a faulty disk.

Are you indeed using BIOS? I ask because the CSM modules (a BIOS compatibility layer) on a lot of board are rather limited and buggy. You would be better served in most cases to boot using EFI, with an ESP partition on your boot disk formatted as VFAT. GRUB still gets installed, but it is called upon by a standard firmware extension that's provided by the OS drive itself. It's actually a form of chain-loading, but it's very reliable (and more reliable to make changes to).

If you have to use a BIOS, a stubborn firmware will usually accept a "manual" GRUB install. The reasons we have to install manually vary, but usually have to do with invalid values coming back during automatic disk detection. For this, you'll need to boot using a live distribution (Ubuntu will do fine) and create a chroot environment. This guide will help if you're lost on that: http://www.cyberciti.biz/faq/unix-linux-chroot-command-examples-usage-syntax/

Once in the chroot, you will have to know a thing or two about your disk. You should be able to successfully write a GRUB out to an MBR with the following command: grub-install /dev/sda (or something similar based on your needs for this system). If you get errors we can deal with those, but this way you get more output.

Alternatively, check your disk for defects. You can do this with the manufacturer tools for integrity checks, or you can use smartmontools. Smartmontools will give you detailed report of the life of the drive, including if it has any unrecoverable sectors or pending sectors. These are sure signs of failing disk, and you should replace it if you see these things.

apt-get install smartmontools will get the utility installed, if it isn't already. smartctl -a /dev/sda will print a full report of your disk, which you can peruse through for failures. smartctl -t long /dev/sda will run a test that you can see the results of after a period of time (won't take long on an SSD).

And lastly, if you still have problems installing in BIOS mode, boot the installer in EFI mode and use that instead. The installer must be booted in EFI mode in order to install an EFI system. The Ubuntu installer does this fine.

Hopefully one of these suggestions helped, as GRUB boot issues can be caused by a whole world of different problems. These are the most typical.

Spooler
  • 7,016
  • 16
  • 29
  • 1
    Also, start simple and maybe check what you're booting off of. It could be as simple as your BIOS / EFI booting from the wrong device (or your actual boot device excluded from the boot order list). – Spooler Sep 27 '16 at 01:40
  • Yeah, that is propably the issue. He should start checking the connection, does'nt seem to be a problem with Linux itself. – Orphans Sep 27 '16 at 09:34
  • Thanks all, but I think the problem was a slightly different one that is specific to the Gen9 MicroServer - I had to create a RAID0 array on the SSD before it would allow me to boot from it. All working now thanks. – Pete Williams Sep 30 '16 at 21:34
0

I believe your issue might be the array controller marking the SSD as failed:

https://serverfault.com/a/1048582/590139

deeess
  • 51
  • 1
  • THANK YOU for replying to an almost 5 year old discussion! Because believe it or not I'm still having the same issue 5 years on - I have to regularly re-create the array on the SSD in order to get it to boot. I have now made the change you suggest and will patiently wait to see if it works! – Pete Williams Jan 16 '21 at 22:44
  • Sadly it didn't work. Still loses the array when it reboots, and the Surface Scan Analysis Priority setting gets reset as it's stored with the array. – Pete Williams Jan 18 '21 at 22:10
  • Sorry to hear - I thought this fixed my ML310e Gen8 v2 with same issue. It's survived quite a few reboots without the error but I'll check if it comes up after giving it more time. If it doesn't, I'll try to investigate. – deeess Jan 20 '21 at 02:53
0

This seems like a very common problem with the HP ProLiant servers booting in BIOS mode (exp. https://forum.proxmox.com/threads/grub-error-on-reboot-device-not-found.38616). Unfortunately Microserver Gen8 cannot boot in uEFI, which makes workaround not easy.

What I believe is happening is that the HP BIOS has a bug and it incorrectly reports the drive size. GRUB will not look past the reported sector and will fail to find the files it needs.

I have experienced this with booting from ZFS (almost whole disk) and from MD-array located at the end of the drive, even with current BIOS - from May 2018. Especially with ZFS it is nasty - at first the data required by GRUB might be within the reported boundaries, so it boots fine. It just stops one day... I guess similar issue might happen with LVM...

The solution that worked for me was to create a partition for /boot data that is physically located at the beginning of the disk.

Grogi
  • 289
  • 2
  • 5