Bare Metal Dedicated Server IPMI Recovery on openSUSE Leap

Why this recovery runbook matters

If your dedicated server hosting box stops responding after a bad kernel update, a failed firewall rule, or a storage issue, IPMI gives you an out-of-band way back in. This tutorial walks through a bare metal dedicated server IPMI recovery on openSUSE Leap, from the remote console to a verified normal boot.

The sequence is written for real outages. You will confirm the OS, check the BMC path, open the remote console, repair boot access, restore networking, and verify that the machine survives a reboot. If you run databases, ecommerce, or customer portals on a bare metal server, this is the kind of runbook you want ready before a 2 a.m. ticket lands.

For a broader maintenance routine after recovery, Hostperl’s Linux maintenance checklist for VPS in 2026 and the related kernel maintenance guide are useful companions. They cover the patching habits that help prevent this kind of outage.

What you need before you start

• An openSUSE Leap server on bare metal with working IPMI, iLO, iDRAC, or an equivalent BMC.
• Access to the provider control panel or BMC credentials.
• A second terminal on your local computer.
• A copy of your server’s expected IP address, hostname, and root password or rescue credentials.

This guide is specific to openSUSE Leap because the package manager, firewall tooling, and boot-repair commands differ from Debian-family and RHEL-family systems. The recovery flow still helps on other Linux hosts, but the exact commands here are written for openSUSE Leap.

1) Open the first SSH session and identify the OS

On your local computer, open the server connection first:

ssh root@203.0.113.10

203.0.113.10 is a documentation example. Replace it with the real public IP assigned to your server. If your provider gives you a non-root login by default, use that account instead, but keep the same example IP format for your notes.

On the VPS as root, confirm the OS before you change anything:

cat /etc/os-release

You should see openSUSE Leap in the output. If you do not, stop here and adjust the procedure to match the actual platform.

2) Check whether the machine is failing at boot or at the network layer

On the VPS as root, collect the basic state. These commands help you separate a network outage from a boot problem.

hostnamectl status

This confirms the host name and operating system. Then check the current network and boot logs:

ip addr show

ip route show

journalctl -xb --no-pager | tail -n 80

If the machine still responds over SSH, the boot is probably fine and the fault may be networking, firewall rules, or a service crash. If SSH is dead, move to the BMC console.

3) Use IPMI or the BMC to get a remote console

On the provider control panel or BMC interface, open the remote console. The exact layout varies, but you are looking for a KVM-over-IP, HTML5 console, or serial console feature.

If your provider exposes IPMI over the network and you have a Linux workstation, you can also verify the BMC path from the server side later with:

ipmitool lan print

Do not change BMC settings unless you know the management network design. The goal here is to restore access, not redesign remote management during an outage.

4) Repair the bootloader from rescue or local console

Once you can see the console, decide whether the system dropped into rescue mode, a GRUB prompt, or a black screen after kernel handoff. A common recovery path on openSUSE Leap is to boot a rescue environment from the provider and mount the installed system.

On the rescue environment or console shell, find the root filesystem:

lsblk -f

Mount the installed system under /mnt:

mount /dev/sda2 /mnt

Replace /dev/sda2 with your actual root partition. If you use separate boot or EFI partitions, mount them too:

mount /dev/sda1 /mnt/boot/efi

Then chroot into the installed system:

chroot /mnt /bin/bash

Inside the chroot, reinstall GRUB if needed:

grub2-install /dev/sda

grub2-mkconfig -o /boot/grub2/grub.cfg

For UEFI systems, the EFI path may differ. A safer check is:

efibootmgr -v

If the output shows boot entries, the firmware still sees the EFI loader. If not, you may need to repair the EFI boot entry before rebooting.

Safe exit: leave the chroot with exit, then unmount in reverse order:

exit

umount /mnt/boot/efi

umount /mnt

Then reboot from the rescue tool or console menu.

5) Boot back into openSUSE Leap and confirm the system state

After the reboot, reconnect from your local computer:

ssh root@203.0.113.10

Once you are back in, confirm that the correct kernel and services loaded:

uname -r

systemctl --failed

systemctl status sshd

If sshd is inactive or failed, the box may be up but unreachable. Fix that before anything else.

6) Restore network access on openSUSE Leap

openSUSE Leap commonly uses wicked or NetworkManager depending on the install profile. Check which service is active before you edit anything.

On the VPS as root, inspect network services:

systemctl status wicked

systemctl status NetworkManager

If wicked is in use, verify the interface config:

ip addr show

cat /etc/sysconfig/network/ifcfg-eth0

Adjust eth0 to your real interface name. A typical static config looks like this:

DEVICE='eth0'
BOOTPROTO='static'
STARTMODE='auto'
IPADDR='203.0.113.10/24'
GATEWAY='203.0.113.1'
DNS='1.1.1.1 8.8.8.8'

Open the file with your editor:

vi /etc/sysconfig/network/ifcfg-eth0

Save and exit after updating the values for your real interface and network. Then restart the network service:

systemctl restart wicked

Verify that the address and route are present:

ip addr show eth0

ip route show

If NetworkManager is in use instead, list active connections and bring the correct one back:

nmcli connection show

nmcli connection up "System eth0"

Replace System eth0 with the actual connection name shown on your server.

7) Repair firewall access without locking yourself out

Before you change firewall rules, make sure SSH still works from a second terminal. Add the new rule first, test it, and only then remove anything unsafe.

On the VPS as root, check whether firewalld is installed and active:

systemctl status firewalld

If it is active, open SSH and any required service ports:

firewall-cmd --permanent --add-service=ssh

firewall-cmd --permanent --add-port=8000/tcp

firewall-cmd --reload

Use 8000 only if your application or recovery service listens there. Confirm the rules now exist:

firewall-cmd --list-all

If you are using nftables instead of firewalld, inspect the rules before editing them:

nft list ruleset

Make the minimum change needed. Do not flush the full ruleset on a production recovery unless you have console access and a rollback plan.

8) Re-enable core services and test persistence

Some outages leave services disabled after a failed boot or manual rescue session. Check the key units and enable them again only after the server is stable.

On the VPS as root, list critical services:

systemctl list-unit-files | grep enabled | head

Enable SSH and your network service if needed:

systemctl enable sshd

systemctl enable wicked

Now test whether the server comes back cleanly after reboot. This is the step many recovery guides skip. Do not skip it here.

reboot

Wait for the machine to return, then connect again from your local computer:

ssh root@203.0.113.10

Check service status and listening ports:

systemctl status sshd

ss -tulpn

You should see the SSH daemon listening and the network address still present after reboot.

9) Run a functional smoke test

A recovery is not complete until a real service works. Use a lightweight local HTTP check if your server hosts a web app, or test the actual application port you expect to expose.

On the VPS as root, if the server should answer on port 8000, confirm the listener:

curl -I http://127.0.0.1:8000

If the command returns HTTP headers, the local service is alive. If it fails, inspect the application logs with:

journalctl -u your-service-name -n 50 --no-pager

Replace your-service-name with the actual systemd unit for your application. A blank or failed response usually means the application itself still needs repair even though the server is back.

10) Keep the recovery path documented

After the outage is resolved, write down the exact failure mode, the recovery commands that worked, and which BMC access method succeeded. For teams running on Hostperl VPS hosting as well as bare metal, that record shortens the next incident because the support team can see what was restored, what was rebuilt, and what still needs monitoring.

If the failure happened after a storage event, compare your outcome against Hostperl’s RAID 1 recovery guide. The storage layer and the BMC layer often interact during real outages.

Troubleshooting the most likely failures

• SSH still fails after reboot
  Diagnostic: systemctl status sshd and ss -tulpn | grep :22
  Clue: sshd is inactive, or port 22 is not listening.
  Fix: systemctl enable --now sshd and confirm firewall allows SSH.
• The server has no public IP after rescue
  Diagnostic: ip addr show and ip route show
  Clue: the interface is up but has no address or gateway.
  Fix: restore the correct ifcfg file and restart wicked or NetworkManager.
• GRUB drops to rescue prompt
  Diagnostic: grub2-install and grub2-mkconfig from a chroot.
  Clue: firmware cannot find the bootloader or the config file is missing.
  Fix: reinstall GRUB, then verify EFI entries with efibootmgr -v.
• Firewall changes block your access
  Diagnostic: firewall-cmd --list-all or nft list ruleset
  Clue: SSH port missing from the active rule set.
  Fix: add the SSH rule first, reload, and retest before any cleanup.

FAQ

Can I use this recovery flow on Debian or Ubuntu?

Yes, the recovery concept is the same, but the commands differ. openSUSE Leap uses zypper, wicked, and openSUSE boot paths, so you should follow a distro-specific guide for Debian-family systems.

What if my BMC password is unknown?

Use the hosting provider’s control panel or remote-hands process to reset the BMC credentials. Do not guess repeatedly, because some controllers lock after too many attempts.

Should I disable root login after recovery?

Only after you verify a non-root sudo user, SSH keys, and console access. Keep root available until you confirm the server survives a reboot and you can still reach it.

What is the first thing to check after a failed boot?

Check the console for the last error on screen, then run journalctl -xb --no-pager | tail -n 80 once the system is reachable. That usually shows whether the failure is bootloader, filesystem, network, or service-related.