Score:0

Hosted VPS various boot issues, can't boot, in a Kernel Panic state?

vn flag

Thanks for reading,

VPS running Ubuntu 18.04

My VPS hosted with OVH is not booting, however the problem seems random. It seems to boot a couple of days ago after me trying it a few times, but then it crashes again. It has been fine for 8 months, no issues, then just stopped.

I know pretty much nothing about how to deal with an Ubuntu VPS unfortunately, just have experience with Windows.

I have been trying to get OVH to assist on this issue for the past 2 weeks, that is how long the VPS has been down. They are simply unhelpful, unresponsive.

Does the the attached image mean anything helpful ? / is there anything I can do in terms of running some sort of diags and resetting / reinstalling something without losing all the data and my proprietary apps and sites etc etc ? I guess I can't even get to a system prompt if the system is stopping at the attached screen ?

Thanks

UPDATE

Appreciate the replies and apologies for the delay in responding, had some trouble getting what I hope is the additional info being sought.

For what it's worth, my gut is telling me it is a hard disk read error type issue but I do not know how to confirm this via Rescue Mode on a VPS. Looking that up now but so far I can't find anything that makes sense to me.

[ 7.406756] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 
[ 7.406756] run-init: /sbin/init: No such file or directory 
[ 7.408399] CPU: 2 PID: 1 Comm: run-init Not tainted 4.15.0-163-generic #171-Ubuntu 
[ 7.409686] Hardware name: OpenStack Foundation OpenStack Nova, BIOS 2:1.10.2-58953eb7 04/01/2014 
[ 7.411085] Call Trace: 
[ 7.411585] dump_stack+0x6d/0x8b 
[ 7.412189] panic+0xe4/0x247 
[ 7.412730] do_exit+0x7fb/0xb90 
[ 7.413304] SyS_exit+0x17/0x20 
[ 7.413907] do_syscall_64+0x73/0x130 
[ 7.414531] entry_SYSCALL_64_after_hwframe+0x41/0xa6 
[ 7.415378] RIP: 0033:0x20d459 
[ 7.415947] RSP: 002b:00007ffcb9277b08 EFLAGS: 00000246 ORIG_RAX: 000000000000003c 
[ 7.417175] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000020d459 
[ 7.418266] RDX: 00007f675b332120 RSI: 0000000000000000 RDI: 0000000000000001 
[ 7.419337] RBP: 0000000000000001 R08: 000000000020d4b0 R09: 00007f675b32a000 
[ 7.420463] R10: 000000000020d459 R11: 0000000000000246 R12: 00007ffcb9277b68 
[ 7.421488] R13: 00000000004001ba R14: 0000000000000000 R15: 0000000000000000 
[ 7.422935] Kernel Offset: 0x2d200000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) 
[ 7.424592] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 
[ 7.424592] 

enter image description here

jp flag
show entire log
djdomi avatar
za flag
i think the question would better fit on superuser, however just restore from backup or reinstall the vm, moreover 1804 is afaik soon or already EOL. take care about using a more current version
in flag
18.04 is perfectly fine, it's supported until 2023. I'd switch too a better hoster if the support is that bad.
in flag
Since you have access to the console, try booting a different kernel. Ubuntu usually keeps the last two or three. You can select them via the grub menu.
djdomi avatar
za flag
it could be that a required module is not loaded or supported. as Told i suggest to use a newer version as it might support the case out of the box. But show us more log in case of same issue. And i also agree with Gerald, if the support is such bad look for another hoster, depending on where you citizenship is, myself is happy with netcup
jp flag
The panic seems to indicate a missing initrd
vn flag
Appreciate the replies and apologies for the delay in responding, had some trouble getting what I hope is the additional info being sought. Add above.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.