Locate the boot failure
Locate the boot stage on the console before repair. Running can coexist with a bootloader, filesystem or network failure.
A Running panel badge does not show where boot failed. After an authorised start, use the console to distinguish boot errors from network trouble; use the status guide for a Stopped or suspended service.
Boot repair can damage data if the underlying cause is unknown. A managed VPS owner should involve the provider under its service boundary. A self-managed administrator should work from a recovery plan and verified backup. Do not reinstall or run copy-pasted bootloader commands simply because a forum example appears similar.
Capture what the console actually shows
Open the provider-supported console for the correct VPS and record the displayed stage, exact error text and timestamp. Is it blank before firmware, at a boot menu, a grub rescue prompt, a filesystem error, a kernel panic, a login prompt, or a normal boot with only network services unavailable? These observations lead to different owners. If the console requires a password, do not expose it in a screenshot.
Check recent events: OS updates, disk-full alerts, guest configuration changes, snapshot or storage maintenance and the last successful boot. Record whether one start attempt was made and its panel result. Avoid repeated forced power cycles, which can alter the evidence and increase filesystem risk.
Route the issue by boot stage
If the VPS is stopped or suspended, resolve that panel/account state first. If the console reaches a login prompt but network access fails, use network or SSH diagnostics instead of boot repair. If a bootloader or filesystem error appears, preserve the exact text and ask the authorised administrator to assess disk layout, backup freshness and supported rescue access. Virtualizor documents rescue and GRUB procedures, but those are operator-specific repair workflows, not safe generic steps for every guest.
If the console is blank or the virtual disk is absent, escalate to the provider with the VPS ID and panel error. Do not assume the guest OS caused a host-storage problem.
Illustrative branch: a login prompt means boot completed far enough for guest access; a GRUB rescue prompt needs a disk and recovery review before any write.
Agree a repair plan before writing to disk
Before any rescue-mode mount or filesystem change, verify there is a restorable backup or image and a rollback route, including how changes to the virtual disk will be recorded. A managed-service operator should decide whether to repair, restore or replace. The customer should not change boot order or attach recovery media unless explicitly authorised. After repair, confirm a normal boot, application data integrity, external reachability and scheduled jobs.
If recovery fails, retain console captures and stop repeating writes until the operator has assessed the disk. Reinstallation is a separate destructive decision governed by the related guide, not the default next step.
A rescue environment may see disks under different names. Confirm disk identity and backup before any mount or repair that writes.
Common questions
Does a Running state mean Linux booted? No. Inspect the console.
Should I run a GRUB repair command now? Only after the authorised operator identifies the exact disk and backup state.
What if the console shows a login prompt? Boot likely completed; investigate network or application access.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.