Root server not starting after reboot

Hi

I have a root server running FreeBSD 13. After a reboot this evening it stops at the bios screen with "Booting from Hard Disk..." and not progressing.

No settings were changed.

Also according to the stats a single core on the CPU is running at maximum.

Why would this be happening?

What is the best way to proceed to get the host back up and running?

Thank you for any help.

I have done the live cd and mounted the drive Ran fsck and only issue found is incorrect free blocks in superblock. This was correct, yet the problem remains. I am waiting for support to get back to me, but it's sunday.

Ouch.

Guess I'll wait.

Machine hosts DNS so I grabbed another vhost and got that up and running.

If it was my installation that was at fault it would at least show information on the drive being booted, but it is just sitting there doing nothing. Doesn't look like a installation issue. I managed to get in and even switched back to older kernel and still the issue persists. I will wait for them on take a look on Monday morning.

So only received response 2 days later and that was just to try the rescue system boot.

Digging around for information I see that qemu has issues booting from GPT partitions. In this VM it is using SeaBIOS to boot so that's probably too old to work with GPT. But switching to UEFI boot doesn't find the drive either because it was not installed with UEFI.

The real question is why, after running for months now, do I suddenly have this issue?

It's not like it is the first time I have rebooted this VM. Not like I actually changed partition types either.

Has me stumped. With this slow response to helping with the issue, it looks like my best bet might be to just purchase another root server and try and copy everything across.

Zitat von ThomasChr

Do you have any output of a failed boot on the console screen?

pasted-from-clipboard.png

This is all I am getting.

Then single core starts going nuts.

Zitat von m_ueberall

AFAIK, SeaBIOS has GPT support and should have had it for quite some time now (or else your setup would never have worked, as SeaBIOS has been used from the start):

Code

# sfdisk --list /dev/vda
Disk /dev/vda: 600 GiB, 644245094400 bytes, 1258291200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A9C778FD-783B-4CCB-B1CF-055A7F3DFE28

Device        Start        End    Sectors   Size Type
/dev/vda1      2048    1050623    1048576   512M EFI System
/dev/vda2   1050624    9439231    8388608     4G Linux swap
/dev/vda3   9439232   13633535    4194304     2G Solaris boot
/dev/vda4  13633536 1258291166 1244657631 593,5G Solaris root
/dev/vda5        48       2047       2000  1000K BIOS boot

Partition table entries are not in disk order.

Alles anzeigen

pasted-from-clipboard.png

IIRC, Netcup use the SeaBIOS version that comes with RedHat (which means that not necessarily the newest one is available, but updates get deployed and your KVM instance will encounter/use those after a reboot). Maybe the last update had some side effects? The only way to find out would be that you try to recreate the environment at home and/or ask around in *BSD forums. Netcup do not disclose existing configurations/service contracts (but then, which cheap(er) service provider does?)

I have tried UEFI and it won't boot either. Complains it can't find drive. I will get screenshot of that error later.

I also don't think they'd be using a old version of SeaBIOS. But then I don't quite know where the issue is here. Clutching at straws really.

Resolved!

Popped onto the freebsd forums and got some rapid help. Turns out I needed to restore the bootcode. No idea why it changed or got damaged.

What a frustrating few days. For all intents and purposes it looked to be a BIOS issue.