Post reboot survivability

If you've rebooted, then you may have noticed some problems. Or, even if you haven't rebooted yet, but you have experience with such matters, then you may just have a hunch that a reboot could cause catastrophe. 'Tis true: rebooting causes temporary statuses to be eliminated. While that fact can cause some problems to stop continuing, that same fact can cause some good situations to stop working well. If the system reboots, and the system doesn't re-create positive scenarios that accomplish good things, then good things might not work properly. In other words, things could break, just because the system reboots, if things aren't set up ideally.

So, let's start taking care of that. By setting things up properly, good things can happen when the system reboots.

Bad shutdown

If the system wasn't shut down properly before, see: required disk check.

Now, the good news is that a lot of the rest of the configuration has been done by editing files. Those files must have had changes made if the functionality was working temporarily before the reboot. However, other functionality could have been implemented by running a specific command that caused a temporary effect. Even if there was an attempt to modify a file so that the system would have processed things right after a reboot, that might not have been tested. So, errors could have caused no noticeable impact until the system rebooted.

This guide is primarily about checking some of those settings which frequently have not been set correctly, causing very noticeable problems but usually not until after the system reboots.

Environment variables

In this guide, the environment variables that have been used most frequently, are:

Hopefully most people can quickly memorize a preferred value for VISUAL memorized. For the others, those may change based on things like data storage locations, names of projects, and names of individual computers. So it's probably best to rely on documentation. Simply check your documentation for those values.

Virtual machine

The virtual machine may not be started. directions for auto-start are not included here, yet

Note: If this hasn't been handled properly yet, and the system reboots, there is now some information about how to get the machine operational quickly, manually. This is at: rdyvmgo.

Virtual machine display

This guide shows how to start Qemu without really having a visible display (by using -vnc none, although the display can be enabled. Keep in mind that, even after enabling the display, TCP port forwarding may be needed.

To enable the display, review: Using Qemu's VNC server. That includes information about setting up the necessary TCP port forwarding.

PuTTY does support using a conneciton profile to store details about desired TCP port forwarding. (Then, a connection can be made with the settings of that connection profile, by using PuTTY's -load parameter.) However, ideally the virtual machine will be getting less dependent on using the local display, so this ought to be a rather short term issue. So, that's probably not worth investing much in.

Network settings
IP addresses

IP address settings may be lost.

First, back up the config file.

If using DHCP/IPv4

Make sure that the DHCP/IPv4 server is running. Presumably, if it has worked once already, then it is already configured. It just needs to be started.

See: virtual machine NIC settings: details about automatically using DHCP.


Check whether packets are still being forwarded.

The settings should have been placed in the /etc/sysctl.conf file, as described by enable network traffic forwarding (which provided details about backing up /etc/sysctl.conf, and then referred to the Implementations for forwarding traffic).

This is most likely to be an issue if you were relying on NAT, but if the NAT is no longer happening. See: enabling network traffic forwarding: starting the packet filter (post-configuration).