Regular Preparation Steps

Note: this page is about some “regular preparation steps” often applied to Unix-like systems. For a similar guide for Microsoft Windows systems, you may wish to check out Tutorial: Customizing Microsoft Windows systems.

Adding early programs

Getting priority/primary software.

Use preferred text editor
If sudoedit won't (ERROR: text cut off)
Adjusting user login sequence

See: Adjusting user login sequence (setting environment defaults)

Checking the prompt

Does the prompt look boring? If so, perhaps some directions were skipped. Mainly, the details related to testing the changes to setting environment defaults. (Run the file that was created. That wasn't just intended for “future use”, but was intended to be used right away on all terminal sessions that are logged into that machine.)

Adjusting bootup sequence

This may increase a system's reliability, by resulting in more uptime. See: new bootup sequence.

Enable auto-reboot

These might be desirable for systems that may be a challenge to interact with, but which should be up.

(If you are interested in further reading, this topic is discussed further by Unix panic.)

Auto-reboot on system panic
OpenBSD
cpytobak /etc/sysctl.conf
sudo cp -i /etc/sysctl.conf /etc/sysctl.conf-orig
echo ddb.panic=0 | sudo -n tee -a /etc/sysctl.conf
Microsoft Windows

With Windows XP and newer, this may be automatically enabled by default. Still, here are directions on how to check the option:

(Instructions confirmed for Windows 7...) Go to the “System” control panel applet. (Some older versions of Windows will show the “System Properties” window. If you have a newer version of Microsoft Windows, choose “Advanced System Settings” in the left frame, which will then bring you to the “System Properties” window.) On the “Advanced” tab, in the “Startup and Recovery” section, choose “Settings”. There is an “Automatically restart” checkbox, which defaults to already being checked.

Check the kernel

There are two changes that are frequently worthwhile for the OpenBSD kernel.

The first of these is widely supported. That is to use multiprocessor support.

Multiprocessor support

Most people with modern, powerful processors will probably want to enable multiprocessor support. The term “multiprocessor” was historically only intended to refer to seperate CPUs. With modern CPUs supporting multiple cores, this same “multiprocessor” functionality can be helpful even if just one CPU is being used.

Try:

uname -v

Results:

$ uname -v
GENERIC#123
$

If the name before the hash mark is “GENERIC.MP”, then that effectively means that you're using multiprocessor support. Great.

If the name before the hash mark is just the word “GENERIC” (as shown in the prior example/sample output), then a single processor kernel is being used.

Try this:

ls -l /bsd*
[ -f /bsd.mp ] && echo -n | sudo -n mv -i /bsd /bsd.sp
sudo ln -s /bsd.mp /bsd
ls -l /bsd*

The change will not take effect until the system reboots.

If there is a problem, well, that's why the previous file is still available. Simply remember the filename, and the old kernel can be booted if needed.

Time zone
Background info

This change seems to be less recommended by the developers, but it is documented by the OpenBSD FAQ (time zone).

Time zone: Actions to take

Changes to the kernel file do not take effect until the kernel is restarted. A reboot will be needed for the effect to take place. Go ahead and make that happen.

sudo reboot
Setting time

The time zone may have been set when adjusting the kernel, but there may be other steps to take for a system to have accurate time.

See: system time setting.

Adding support for additional software

See: preparing a package manager with configuration details.

Supporting colors

Now this may be somewhat debatable: people may have some strong feelings over whether color is a good thing or a bad thing.

There are a couple of solid arguments against using colors in directory listings. One is that a common color shown is (dark) blue text on a black background, and that is pretty challenging to read on some displays. (Perhaps projectors are more likely to have it be challenging to read?)

Another reason to not use colors: The extra call to “stat” can slow things down. See: harm.

If, after all these warnings, you want colored ls to be available via an alias:

Note: It is recommended that you place the command in another conveniently-available alias. Then, either leave ls unaltered, or have the ls command simply point to the other alias. That way, the ls alias can be easily disabled, but the other alias can still be conveniently available.

e.g.: maybe an alias called lc (there is a common reference to LC in Unix, which is the LC_ALL and similar (GNU gettext: Locale). The related command is locale, not lc, so that seems to leave lc available. It seems that lc may be widely unused on many systems.

Note: Keep in mind that ls colors can be unpleasant in some circumstances. It may be wise to not have ls show colors by default, especially on a parent image (which would require active work to disable if colors ever become undesirable).

Sample: colorls

Sample is from OpenBSD. Install the program:

sudo -i pkg_add -ivv colorls

Make environment variables, alias:

cpytobak /etc/profile.lcl
echo alias lc=\"colorls\"| sudo -n tee -a /etc/profile.lcl
echo export CLICOLOR=\"\"| sudo -n tee -a /etc/profile.lcl
echo export LSCOLORS=\"Gxfxcxdxbxegedabagacad\"| sudo -n tee -a /etc/profile.lcl
echo ${VISUAL}
sudoedit /etc/profile.lcl

Check results:

. /etc/profile.lcl
cl
env CLICOLOR_FORCE="" colorls / | less -R

(The LSCOLORS value shown above is the default, except it uses bright cyan instead of dark blue for directories. Since dark blue on black can be difficult to see on some displays, and since directories are so common, this customization is recommended by this guide. The default behavior uses the value shown above, except starting with an “e”.

Preliminary wrap-up

There are some additional tasks that have been getting put off, just because most or all of the previous ones are pretty beneficial to do very early... as early as possible.

However, it's time to take care of some other tasks.

Enabling VisualHostKeys
Rationale
Related Reading Material

Visual Host Keys are described further by verifying SSH keys.

Controversy

There is some opposition to this idea. What the controversial aspect basically boils down to is that these offer less security than manually verifying every digit of the SSH key, and some people prefer to hold onto that higher standard, while others would prefer the smaller benefits by doing a partial check instead of what many people actually do in practice, which is to not even do that partial check.

This guide is not trying to take a stand on whether the VisualHostKey functionality is a good thing or a bad thing. However, right now there may be a lot of people who don't use the visual host keys simply because they are unfamiliar with some aspect of the process. Ignorance is generally not the most preferable of reasons to avoid a technology that some people see some benefit in, so this guide does show how to enable the display of VisualHostKeys as an action that generally happens.

Note that this only matters when using the OpenSSH client, since as far as the author of this text has been able to determine so far, at the time of this writing, other software like PuTTY doesn't seem to show these.

On the physical system

On the physical system:

grep -i VisualHostKey ~/.ssh/ssh_config

If there is no such configuration, then...

mkdir ~/.ssh
echo ~
sudo cpytobak ~/.ssh/config
echo VisualHostKey yes| tee -a ~/.ssh/config
chmod go-w ~/.ssh/config
Confusing home directories

If that doesn't work, it could be that ~ is not the same as the home directory for $USER, which might happen when using sudo (which some people might do in an effort to get read permissions to a specific key file). Perhaps the best way to handle that is to use “sudo -H” (or “sudo -i”) instead of “sudo”, as that will cause the home directory to work as anticipated. Alternatively, this variation may be helpful:

export USRSSHDR=$(eval echo \~$(id -un))/.ssh
echo ${USRSSHDR}
mkdir ${USRSSHDR}
sudo cpytobak ${USRSSHDR}/config
echo VisualHostKey yes| tee -a ${USRSSHDR}/config
chmod go-r ${USRSSHDR}/config
unset USRSSHDR

However, if that DOES work, be sure to check the results of any changes that were made during the first attempt. (Undo them if the changes are undesirable, which may be the case if they were accidental.)

Supporting multiple user accounts
Existing accounts
root account
  • If you may be using an SSH client from multiple accounts, such as a primary account and also the superuser “root” account, you may wish to perform the same steps with the other account as well. The recommended process for that is:
    export USRSSHDR=$(eval echo \~$(sudo id -un))/.ssh
    echo ${USRSSHDR}
    sudo mkdir ${USRSSHDR}
    sudo cpytobak ${USRSSHDR}/config
    echo VisualHostKey yes| sudo -n tee -a ${USRSSHDR}/config
    sudo chmod go-r ${USRSSHDR}/config
    unset USRSSHDR
    • Alternatively:
      1. using “ sudo -H ${SHELL} ” (or “ sudo -i ${SHELL} ”),
      2. followed by the steps of one of the prior methods, works.
      3. (Then use exit to leave the sub-shell that was entered by sudo.)
Other accounts
ls -l ~/..

If there are other accounts that need to be updated as well, customize the username in the first line:

export USRSSHDR=$(eval echo \~$(sudo -u username id -un))/.ssh
echo ${USRSSHDR}
sudo mkdir ${USRSSHDR}
sudo cpytobak ${USRSSHDR}/config
echo VisualHostKey yes| sudo -n tee -a ${USRSSHDR}/config
sudo chmod go-r ${USRSSHDR}/config
unset USRSSHDR
Account report

After getting some accounts, it might be easy to lose track of which accounts have had this change be done. The presense of an SSH configuration file can be seen with:

sudo ${SHELL} -c " ls -l /home/*/.ssh/config ~root/.ssh/config "
Future accounts

Copy one of the .ssh/config files to /etc/skel/.ssh/ directory.

sudo cpytobak /etc/skel/.ssh/config
sudo cp -pi ~root/.ssh/config /etc/skel/.ssh/.
sudo ls -l /etc/skel/.ssh/.
On the “virtual machine”

You can also do that on the virtual machine. (Follow the directions that were just given for steps to perform on the “physical system”.)

Acquire data

You're welcome to skip this “Acquire data” section. It was meant as a way to back up the progress that was made so far. However, no solid method of restoring the data has been documented here, so the benefit feels rather incomplete. For now, this guide is not recommending going through the process of trying to go through these manual efforts to back up all the data. (The instructions remain to enable easier potential development of a more thorough, complete plan.)

SSH key fingerprints

It is time to document data that we didn't want to manually write down (SSH keys). Now that networking is functional, enabling SSH can be done, this information ought to be fairly easy to acquire (using copy-and-paste or SCP or the better SFTP).

On the virtual machine:

for x in /etc/ssh/ssh_host_*.pub ; do ssh-keygen -lvf $x ; echo ; done | tee -a ~/sshfngs-$( date "+%Y%m%d%a%b%H%M%S%Z%z" ).txt
ls -ltr ~/sshfngs-*

Now, in your project documentation, make a file that is named after this computer (which is the “virtual machine”), and which contains SSH fingerpints. There are a couple of ways to do something like this.

Using copy-and-paste

For the SSH fingerprints, one effective way to get these stored is to view the output of the previous command. The output of the previous command is stored in a text file, so just viewing that text file will work. Then, use a “copy and paste” feature to get that information copied into some documentation. That is one approach.

This approach may be the most convenient, because you can use the current logged in shell. However, since the SSH fingerprint data likely exceeds the size of one screen, there may be some need to use “scrollback” capabilities. Depending on how easy that is to do, that might be a bit more cumbersome than the alternative. (If you're not doing this as part of a formal classroom training environment, and aren't doing this for anybody else (such as a project), and if you personally don't care about the VisualHostKey randomart data, you could re-make the ~/sshfngs.txt file without the VisualHostKey randomart data, which might be sufficient enough to eliminate the need for dealing with scrollback.)

Or, instead of dealing with scrollback, you could simply “copy and paste” one screen at a time.

echo ${PAGER}
cat ~/sshfngs*.txt | ${PAGER}
Transferring a file

(This section, or at least most of its content, should be moved to another page, so that the information can be easily referenced from multiple parts.)

Transferring a file might, or might not, be a relatively simple way to get the data off of the system. (If the system is remote from the network where the documentation is stored, then network routing might be complex enough that this is not a preferred solution. In other cases, this might be a very easy solution, and worth pulling off.)

For any data, including the SSH fingerprints (or even the entire SSH key files), and any other data, you can get the information off of the system by using a file transfer protocol, such as sftp (built into OpenSSH) or scp (also built into OpenSSH). Both of those come with operating systems that come with OpenSSH. The sftp is generally preferred, since information about SCP notes that OpenSSH FAQ 2.10 identifies scp as a protocol that will not be developed further. However, scp does work more older systems than sftp, since sftp used to not work with OpenSSH's default configuration file. So, knowing about both options could still be a good thing.

Using a file transfer protocol requires certain information: the login credentials (username and password), and the remote system's IP address. Presumably this information is known (because, presumably, you know where you have a place to store data; presumably this may also be where you are storing your documentation). Such details may commonly be part of the documentation that is supplied with a formal training environment, so if such details exist then check those details if there are questions. Classmates might also be a source of this information. Just know that incorrect information could result in information being accessible by unauthorized users, so if there is any doubt about whether a workable solution is correct, do ask official support. Since that may be a highly customized portion of this process, this guide doesn't provide further information about how to obtain those details. Once those details are obtained

sftp -P 22 -p -l username local-file(s) remotesys:.

There should be a directory name at the end of the command line, like the previous example which shows a period at the end of the line. In that case, the period refers to the “current directory” on the remote server when sftp is done logging into the specified user account.

For the remaining data that is being described here, the goal is to simply get a copy of some data off of the “virtual machine”. Even if the only other computer that is convenient to store such data is the “physical” machine that runs the “virtual machine” software, go ahead and get the data copied off. (See the “Transferring a file” section, above, for details.)

Back up user database

If there have been changes made to the user account database, but those haven't been backed up yet, then it probably makes good sense to back up the user account data at this time. Doing so earlier (in the “initial user changes: backing up users” section) may have made a bit less sense, just because networking may not have been completely functional. But there may be little to no compelling reason to delay any further.

Details to do this are covered by backing up the user database. The difference is that before there may have been a recommendation to delay this task until networking was a bit more functional. Now, it is finally getting to be the time to make sure that task has been performed.

Current versions

It is good to have backups of files. Since this guide is not assuming that a “file integrity checking” database is available yet, the way to identify any customized files is to look for files that have been recently changed.

You check out the “later” files using “ls -latrd” (long view, all filesystem objects, time sorted, reverse sorted, directories). Especially see /etc/ and ~root/ (including ~root/bin/ and / (the top-level/“root” directory).

Running these (one at a time), and consider the filenames near the end. Are there customizations that haven't been backed up?

ls -latr /etc/
  • In a recent test, it looked like about 33 filesystem objects, out of the 95 (shown by ls -ltr /etc/) have been updated throughout this process so far.
ls -latr /
  • Kernels have been updated.
sudo ls -latr ~root/
  • sudo ls -latr ~root/bin/
  • sudo ls -latr ~root/.ssh/
  • Similar files/directories may exist elsewhere:
    • ls -latr ~/.ssh/
    • ls -latrd ~/.*
    • ls -latrd /etc/skel/.*
  • ls -latrd /var/log/.

After reviewing the likely cases of some recent activity, if there's any files that need to be backed up, use cpytobak

Original versions

Files which followed the backup user archive file process may have stored files at ~/backup-* files.

cpytobak ~/backup-*

It might be possible that there are multiple locations, such as ~/ being different than ~root/ or some other user's home directory. So check the home directory of all of the administrative user accounts that you may have been logged into.

Do not just run cpytobak with ~root/backup-* as a non-root user. The problem with that is that the wildcard will try to be expanded as the non-root user, who may (and, actually, probably does) not have access to the contents of the ~root/ directory. So, instead, become a root user, and then run the command, as shown here:

sudo ${SHELL}
cpytobak ~/backup-*
exit

Now, a lot of files have a backup copy stored in /origbak/ because that is the location where cpytobak stores files. To get the data off of the machine, go to another system (the “physical” machine that is running the “virtual machine” software can be one option, if there are no better options conveniently available), and get that data copied off.

If you're going to be using a file transfer protocol and intend for that protocol to log in as a non-root user, then make sure that non-root user has “read” access to the /origbak/ directory and the files in that directory.

sudo ${SHELL}
chmod g+rx /origbak/*
chmod g+r /origbak/*/files.tgz
exit

Much of this next example is worthy of considering whether to customize it, so be a bit careful with this particular set of commands. (The example text may show some “style” detail that indicates some parts should be customized. If you're part of a formal training program, make sure to follow any custom instructions. Otherwise, feel free to also customize any, or all, of the rest of this process.) The idea is to run this from a system other than the virtual machine.
mkdir ~/virtmdat/
echo ${VMLILNAM}
mkdir ~/virtmdat/${VMLILNAM}/
pwd
scp -P 22 -C -o VisualHostKey=yes -r username@virtmach.example.zz:/origbak/. ~/virtmdat/${VMLILNAM}/.

Overview: Upcoming steps

Previously, the guide recommended doing a “Reboot test” of the virtual machine, soon. The current recommendations are to skip that test, becaues the system was presumably rebooted recently, after making changes to the kernel configuration (by switching to a multi-processor kernel, and supporting the time zone change).

However, the current recommendations do involve the following upcoming steps:

  • proceed to shut down the “virtual machine”, in order to perform the “handling the disk image” task.
  • compress the disk image. A most excellent side effect is that this ends up creating a backup of the (virtual) primary storage (“hard drive”) device on the “virtual machine”
  • child the image
  • Make sure things are suitably backed up
  • Test recoverability from instability: test improper reboots
Reboot test

For now, just skip this as described in the “Overview: Upcoming steps” that were just mentioned.

First, here's just a few thoughts: If the building's electrical power turned off, how easy would it be to restart the virtual machine? Would the machine still have its IP addresses? When was the last time that the system rebooted?

Verify that documentation is sufficient

Perform a clean shutdown and/or reboot of the virtual machine. e.g.:

Make sure to be careful to do this on the right device! sudo halt -p

Note: It is not recommended to try rebooting the physical machine (which could cause its own set of problems, like broken IP settings on a tun# interface) until after it is verified that the virtual machine can be rebooted. Troubleshooting one piece at a time is likely to make troubleshooting go easier.)

Verifying stoppage

Verify that the virtual machine is stopped.

Rationale

This is essential because you don't want to try to start the machine and then accidentally have two copies of the machine (both trying to use the same resources like a disk image and a TCP port).

How to do this (and, first, how not to)

A machine that is shutting down might disconnect an SSH session before the machine has completed the shutdown, so losing the SSH connection is not necessarily an indication that the disks are no longer being used.

(Having Qemu close the VNC connections that are made to Qemu's internal VNC server is a good indication. Having the Qemu monitor close a Telnet session is also a good indicator. Those things will have happened after the system shuts down.)

This might be doable by verifying that there are no running copies of the software that runs the virtual machines. Whether that technique works may depend on factors like whether there are other virtual machines running, and what software is being used. For instance, that method works for Qemu, but might not work as easily for Hyper-V. The recommended way for Qemu is to verify what instances of Qemu are running. For instance:

echo ${VMLILNAM}
ps -auxww | grep -i qemu | grep -i ${VMLILNAM} | grep -v grep
Some notes about using ps

Note that although the above syntax will work okay with OpenBSD, ps syntax differences are significant enough that no single syntax is preferred by all the Unix implementations. Users of other operating systems may need to adjust the example shown. (Common modifications may include taking out the hyphen right after the word ps and/or removing some parameters, such as one or both of the w characters.)

Multiple redirections are shown. The final redirection is discussed in the section about “Having grep exclude itself”.

Then, perform the steps needed to SSH into the machine. The first thing that you'll need to do is to start up the virtual machine.

If the virtual machine starts in a paused state, tell it to continue the proceses (unpausing). With Qemu, that is done with the “cont” command in the Qemu monitor. (That initial pausing of the virtual machine can be removed; these instructions will recommend doing so after installing the operating system on some more virtual machines.)

Other than that, if everything is working as smoothly as possible, then the machine will boot up and be able to receive a “remote access” connection, such as an SSH connection, without further troubleshooting.

Some other things to do...
Handling the disk image

Quite a bit of work has been done, so far. If the hard drive image still hasn't been backed up, then it may be time to do so. (Some people may consider that to be overdue already.) This section discusses some options which are rather common when working with virtual machines.

Compressing
  • What the author of this guide does recommend is that people follow the steps to compress the first disk.
    • For those who are concerned about disk compression, be sure to check out the CHD Myths section. (A lot of people have some incorrect beliefs about CHDs being slow. They may even be convinced that they know this is true because of experience, since they were convincingly taught this by some misleading experiences. Using CHDs can be a real performance-enhancer, as discussed by that section.)
    • This is probably unnecessary the first time that this guide is followed. However, it also should cause no harm, and may be helpful on a computer that has had these steps be previously performed. (Because the upcoming steps are designed for possible re-use, right here is the proper place to put instructions to clear any undesired pre-existing values.)

      echo VMDskBeg=${VMDskBeg} VMDskSml=${VMDskSml} VMDskEnd=${VMDskEnd}
      unset VMDskBeg VMDskSml VMDskEnd
    • Follow the steps at: Virtual Machine Disk Handling Technologies: Compressing a “Virtual Machine” Disk Image
Childing
  • Then, create a child image by following these steps:
    [#mkdtobak]: making a child disk as a sort of backup method
    • First, make very certain to verify virtualization variable values ...
      echo VMDirBas=${VMDirBas} VMGenNam=${VMGenNam} VMLILNAM=${VMLILNAM}
    • export VMDskDir=${VMDirBas}/diskimgs/baseimgs/${VMGenNam}/${VMLILNAM}/.
      export VMCrDsNm=1
      export VMDskMom=${VMDskDir}/${VMLILNAM}${VMCrDsNm}-initial-changes.qc2
      ls -l ${VMDskMom}
    • The ${VMDskMom} variable should successfully be pointing at a file. So, that last command was a check to make sure that the file exists. (By setting ${VMDskMom} here, that is overriding some default behavior in some upcoming instructions.)
    • Follow these instructions: VM: Mk Kid Disk: Common Steps
Cleaning

Perform some clean-up:

echo ${VMDskDir}
sudo mkdir ${VMDskDir}/old/
ls -ltr ${VMDskDir}/old/
ls -ltr ${VMDskDir}/
ls ${VMDskDir}/${VMLILNAM}${VMCrDsNm}-parent-old-uncompressed.qc2
sudo mv -i ${VMDskDir}/${VMLILNAM}${VMCrDsNm}-parent-old-uncompressed.qc2 ${VMDskDir}/old/
ls -ltr ${VMDskDir}/old/
ls -ltr ${VMDskDir}/

...

Additional reading material
  • These steps are not necessarily being recommended at this part of the process, but references are being provided in case they are useful: For some additional reading material, those who wish to take a different course of action might benefit from reading some material about virtual machine disk (backup/snapshot) handling.
Test improper reboots

This may be a great time to check that improper reboots are being handled well. If they aren't, there might be substantial data loss, or the data might just be rather inaccessible (but not deleted, and rather easily recoverable) until some manual intervention is done to fix things. Until that manual intervention is done, the system might not operate very properly. (For example, in OpenBSD, this has been known to prevent the ability to log in locally. The way to fix that requires a message to be sent to the kernel, which requires rebooting and accessing the device locally.)

The reason why this is a great time to test things is that if things go horribly wrong, there is a very recent backup. (Basically, just delete the child image, and re-create the child image.)

Re-creating the child can require some careful thought, to make sure that filenames are correct. Backing up an existing child image may actually be an even faster way to go.

echo ${VMDskDir}
sudo mkdir -p ${VMDskDir}/old/prebad/
sudo cp -pi ${VMDskDir}/${VMLILNAM}?.qc2 ${VMDskDir}/old/prebad/.
ls -ltr ${VMDskDir}/old/prebad/
ls -ltr ${VMDskDir}/
  • To test this, first start the virtual machine.
    • echo VMDirBas=${VMDirBas} VMGenNam=${VMGenNam} VMLILNAM=${VMLILNAM}
      ${VMDirBas}/execbin/${VMGenNam}/${VMLILNAM}/sysstart/exc_${VMLILNAM}
  • Then, view the machine's local console.
    • (So, use the Qemu monitor to create a VNC connection. See: using the Qemu monitor and then follow the rest of the pertinent steps by using Qemu's built-in VNC server.)
    • After the system is rebooted, usage of the SSH protocol probably won't show as many informative details, including some error messages that may be written to the main console. So, if you have a cause to log in, you may as well do so from the main console.
  • Wait until disks are mounted, in order to maximize the probability of problems.
    • (Once the system has started configuring the network devices, that generally means that /var/ is writable, so that the /var/db/dhclient.leases.* file can be updated.)
    • (Once the system has reached the login prompt, automatically mounted disks are usually mounted. So, simply waiting for that is generally a simple way to safely perform this test well.)
  • Then, the next step will be to perform an ungraceful reset. Note that this should usually be done only as a last resort, due to the possibility of data being lost. However, in this case, the relevant data has been sufficiently backed up, and this is being done to intentionally test recoverability. To do this:

    Qemu improper shutdown

    The recommended way is to use the Qemu monitor to issue the “system_reset” command.

    There may be other ways, like use the Qemu monitor to issue either the “system_powerdown” command or the “quit” command, or simply ending the Qemu software (adjust running software), but those methods will probably take a bit longer, and probably will not add significant benefit. (They probably won't be more beneficial at all.)

If all is well, and this disk image will be used for a critical machine, it may be sensible to use the hard drive image from before the test, just in case the filesystem repairing program (fsck) somehow did an insufficient job. In the future, file integrity checking can be used to more fully verify that nothing got accidentally corrupted. However, for the time being (when “file integrity checker” software has not been used to create an initial “file integrity checker” database, yet), using a “file integrity checker” database is not an available option.

Here are some sample commands.

ls -l ${VMDskDir}
ls -l ${VMDskMom}
ls -l ${VMDskEnd}
ls -l ${VMDskBeg}
Updating the image

DO NOT even try to do this while the virtual machine is actively running!

(Quit the virtual machine first.)

(This is a rare time when there is no reason to perform a clean shutdown when trying to quit the virtual machine. Protecting the filesystem volume's structure won't matter, because it's about to be overwritten anyway.)

Preferred method

If copies of the disk images were created before the “disaster” of “improper” rebooting, those copies can be restored. That ought to correct any problems that were created during the process of testing improper reboots, even if the problems were undetected or if they were fixed improperly.

echo ${VMDskDir}
ls -ltr ${VMDskDir}/
ls -ltr ${VMDskDir}/old/prebad/
sudo cp -pi ${VMDskDir}/old/prebad/${VMLILNAM}?.qc2 ${VMDskDir}/.

Affirm twice.

ls -ltr ${VMDskDir}/
Alternative methods

No need to do the commands shown in either of these methods if the above method was done...

Re-childing method
  • Move the existing filename out of the way.
  • export VMDskDir=${VMDirBas}/diskimgs/baseimgs/${VMGenNam}/${VMLILNAM}/.
    export VMCrDsNm=1
    sudo mv -i ${VMDskDir}/${VMLILNAM}${VMCrDsNm}.qc2 ${VMDskDir}/${VMLILNAM}${VMCrDsNm}-parent-old-with-added-improper-resets.qc2
  • Repeat these steps: making a child disk as a sort of backup method
Another approach

Expect the cp command to request input. Think about the consequences of the decision, and make a choice.

sudo cp -i ${VMDskEnd} ${VMDskBeg}
Reliability test : post-reboot

Shut down the virtual machines. Reboot the physical machine. Manually start up the virtual machines.

That rounds up the section of this guide called “Regular Preparation Steps”. If you're looking to take any sort of extended break (like a multi-day break), it may be worthwhile to do one of the tasks from the next section, which is setting up “file integrity checking”. Once that is set up, performing an actual “file integrity check” can be rather time consuming, so that may be nice to start before leaving. Otherwise, when returning to this project, you may start off with a process that can involve a fair amount of waiting, which may feel slower overall, and possibly with the good reason that it actually is inefficient.