Patent Application
20060112313
This invention relates to the field of computer maintenance. In particular, this invention is drawn to the maintenance of a computer using a boot image.
Computer systems typically include hardware components such as processors, power supplies, nonvolatile storage, peripheral devices, etc. Some of the components have firmware that can be modified by the user to tailor the component configuration for the particular system it is installed within. Application software for any number of applications may also be installed. Typically such software is installed on a magnetic or optical disk for nonvolatile storage.
Unfortunately, the computer system can malfunction as a result of either software or hardware problems. Sources of malfunction include failing components, misconfigured components, conflicts between application programs, operating system errors, etc. Exposure of the computer system to sources of malicious software (e.g., viruses, worms, etc.) may also result in malfunction when such software is executed.
Frequently the malfunction is the result of a corrupted or missing critical file. Correction of the malfunction requires the capability of returning the computer to a prior known state, for example, by restoring the critical file.
One recovery approach provides the user with an optical compact disk (CD) containing a restoration program and a trusted version of the critical files. The user may not have a CD drive at their disposal, however. Such peripheral devices may have been deliberately omitted from the computer configuration in order to prevent users from installing unauthorized software. Alternatively, the user may be using a laptop or other mobile system without ready access to a CD drive.
Even if the computer system is provided with a drive to support recovery operations, restoration from the removable media typically eliminates current user-data and re-instates obsolete user specific data and critical files. Although the CD may provide a trusted version of the critical files, the CD frequently does not accurately reflect a recent state of the computer. The user is then forced to rebuild or re-install various software components to bring the computer system up-to-date with current drivers and operating system components. This approach is somewhat impractical when dealing with a large base of computer systems because of the need to distribute and maintain the removable media.
In view of limitations of known systems and methods, various methods and apparatus for operating a computer are described. In one embodiment, a method of operating a computer includes initiating a standard operating system boot process utilizing critical files stored in associated standard locations on a first peripheral device. The critical files are copied from the first peripheral device into a boot image residing on the first peripheral device after a successful boot. The computer can optionally boot from the boot image during a subsequent operating system boot process.
In another embodiment, a method of operating a computer includes initiating a computer operating system boot from a boot image residing on a first peripheral device. Files critical to a standard operating system residing elsewhere on the first peripheral device are copied from the boot image to associated standard locations on the first peripheral device after a successful boot from the boot image.
The boot image includes an operating system and critical files associated with booting the operating system. The boot image is stored as a contiguous file on the first peripheral device.
The boot loader is an executable program (e.g., “bld.com”) that configures the computer system to perceive the boot image as a peripheral device when executed. At the time the boot loader is stored on the first peripheral device, the boot loader may need to be patched to indicate the physical location of the boot image on the first peripheral device. Alternatively, the boot loader may dynamically determine the location of the boot image.
In order to ensure that the boot image and boot loader are not fragmented by a file system or disk maintenance application, the boot image and boot loader are provided with a file system attribute to prevent or protect from fragmentation. For example, the boot image and boot loader may be provided with a “system” attribute to identify them as critical files that should not be fragmented.
In step 120 a computer system boot process is initiated. The boot process is described more fully with respect to
In Microsoft® Windows®-type operating systems, the “boot.ini” file is the file used to specify selectable operating systems. (Microsoft Corporation located in Redmond, Wash. is the manufacturer of Windows® brand operating systems). At the time the boot loader, copy script, and boot image are stored on the first peripheral device in step 110, the “boot.ini” file may be modified to provide an option to boot from the boot image. Once the boot process is initiated, an operating system is selected for booting in step 130. Once the boot image is stored on the first peripheral device, there will be at least two possible operating systems to be booted. The user may select to boot from the operating system within the boot image. Alternatively, the user may select to boot using the operating system already residing on the first peripheral device.
Given that the boot image and the other operating systems are stored on the same first peripheral device, the term “standard” is used to imply locations on the first peripheral device other than the region that the boot image resides on.
Step 250 effectively ensures that the boot image will have copies of critical files that resulted in a successful boot. Critical files may include drivers, bootstrap loaders, boot sector code, operating system kernels, registry hives, etc. A registry hive is a subset of keys appearing in the registry of a Microsoft® Windows® brand operating system. The files deemed critical for a successful boot will depend, of course, upon the hardware configuration and the operating system at issue. The critical files are those files necessary to be able to boot an operating system.
Once the copying has been performed, the user may utilize the computer system as usual. If the user installs hardware or software that modifies the critical files, the copy of the critical files within the boot image will not be modified until after the next successful boot. Thus if the modifications result in an inability to perform a standard boot, the user will be able to boot using the boot image which does not yet incorporate the problematic critical files. On the other hand, once the user successfully reboots the computer system, the boot image will have a copy of the critical files (including any modifications made in the prior session) that have been effectively validated as a result of the successful boot.
In the event the user is unable to boot using the critical files from the standard locations on the first peripheral device (i.e., the user is unable to perform a standard boot) or the user does not want to perform a standard boot, the user may choose to boot from the boot image.
In step 360, an operating system is booted from the boot image. Upon a successful boot, the critical files are copied from the boot image to their associated standard locations on the first peripheral device in step 370. The copying may be performed by a restoration program that is executed upon a successful boot of the operating system within the boot image. Similar to the copy script, the restoration program may be scheduled as a task to be performed (within the boot image operating system files) upon a successful boot.
Although the user could continue working under the operating system booted from the boot image, the computer system would preferably be rebooted after step 370 to prevent inadvertent modifications to the critical files stored within the boot image.
The boot image operating system may be the same operating system as the standard operating system such that the boot and standard operating systems are different instances of the same operating system. Alternatively, the boot image operating system and the standard operating system may be distinct operating systems. For example, the boot image operating system could be one of a Unix®, Linux, MS-DOS®, or other non-Microsoft® Windows® operating system while the standard operating system is a Microsoft® Windows® brand operating system. The boot image operating system need not support the full functionality that the standard operating system provides. Even if the boot and standard operating systems are different instances of the same operating system, the boot image operating system may have considerably reduced functionality and size compared to the standard operating system.
The processes illustrated in
Some of the computers are referred to as host computers or servers because they provide services upon request. The computers issuing the requests are referred to as client computers. The network environment of
The host computers/servers (e.g., 450) and client computers (e.g., 420) can be entirely different architectures, however, to facilitate communication on network 410 they communicate by using a common communication protocol. In one embodiment, this protocol is the Transmission Control Protocol/Internet Protocol (TCP/IP).
In one embodiment, a client computer 420 accesses a host computer 450 to obtain a boot image file, copy script, and an associated boot loader. The users, for example, may execute a browser application to access a multimedia enhanced document (e.g., a “web page”) residing on a host computer/server from which the user may select the appropriate files to download.
In an alternative embodiment, the files are “pushed” from a server 450 to the client 420. Typically, this requires co-operative components to have already been installed on both the server and client computers. Microsoft Corporation's System Management Server is one example of a product that provides such co-operative components. With the appropriate components installed on each of the server and the client computers, the client will accept software “pushed” to it from the server (i.e., without the client initiating a request for the software). Organizations with a large base of installed users often already have such management tools available to them such that the boot loader, copy script, and boot image may be readily distributed to a large base of users across a network without the need for physical media such as CDs.
Once the boot image is stored on the client computer, additional steps are required to enable the client computer to be able to boot from the boot image. Some understanding of the client computer architecture, standard boot process, and hard disk layout may be helpful in the discussion of the modifications required to make the boot image bootable.
RAM 560 is typically a volatile memory and does not retain its contents once power is removed from the computer system. Computer 500 includes nonvolatile memory 570 for storing configuration information even when the computer is powered down. Often parameter information that identifies specific features of the input/output devices is stored in nonvolatile memory 570. For example, parameter information might describe the number of disk drives, disk drive type, number of heads, tracks, amount of system RAM, etc. as well as the sequence in which peripherals are accessed when attempting to boot the computer (peripheral boot sequence). Various types of nonvolatile media such as electrically erasable programmable read only memory (EEPROM), flash memory, battery-backed complementary metal oxide semiconductor (CMOS) are available.
The computer additionally has one or more peripherals 590, 592 such as a floppy drive, a hard drive, or an optical drive that supports nonvolatile storage. Compact disks (CDs) and Digital Video Disks (DVDs) are examples of media used with optical drives.
Mouse 520, keyboard 530, display 540, RAM 560, nonvolatile memory 570, and boot ROM 580 are communicatively coupled to processor 510 through one or more buses such as bus 550.
Initialization of the computer system is performed upon power-up of the computer system or hardware or software reset operations. In one approach, the processor 510 is designed to read a pre-determined memory location when the processor is reset or powered up. The pre-determined memory location stores a pointer or an address that directs the processor to the beginning of the bootstrap routines. The pointer or address is referred to as a boot vector. For some types of resets (e.g., a “hard” or “cold” reset), the boot vector is always set to a value determined at the time of manufacture of the processor. Other types of resets (e.g., “soft” or “warm” reset) permit an alternative boot vector to be used.
For hard resets, the boot vector typically points to an address in the boot read-only memory (ROM) 580. For soft resets, however, the boot vector may point to a RAM location. The boot ROM stores the bootstrap loader and typically stores other initialization routines such as power on system test (POST). Although referred to as a ROM, the boot ROM is typically embodied at least partially as a re-writable, nonvolatile memory to permit updates.
The boot ROM may include routines for communicating with input/output devices in the computer system. In some computer systems these routines are collectively referred to as the Basic Input Output System (BIOS). The BIOS provides a common interface so that software executing on the processor can communicate with input/output devices such as the keyboard, mouse, nonvolatile mass memory storage device, and other peripheral devices.
The BIOS typically permits the user to boot an operating system from any one of the floppy drive, hard drive, or optical drive. The computer follows the peripheral boot sequence in an attempt to boot from the peripheral devices. Proceeding in boot sequence order, the computer attempts to boot from the first device in the boot sequence that is bootable. One embodiment of a boot process is illustrated in
Upon initialization, the processor starts executing the BIOS code stored in the boot ROM. The BIOS includes instructions for performing a Power On Self Test as indicated in step 610. The BIOS follows a peripheral boot sequence to locate a boot device in step 620. The BIOS transfers control to code located within the boot sector of the boot device as indicated in step 630. The boot sector code is operating system- and file system-specific. The BIOS, however, is still used to access the boot device.
In some architectures, the user will have the option to select from more than one operating system. Thus in step 640, an operating system to be loaded is selected. Typically, a default operating system is defined and will automatically load unless the user acts within a pre-determined time period. Steps 610-640 are referred to as a “pre-OS boot” phase.
The Microsoft® Windows operating systems family utilizes a file called “boot.ini” for prompting the user to select a particular operating system.
Referring back to the boot process of
Steps 650-690 are referred to as the operating system boot phase of the boot process. Steps 650-690 are intended to represent a generic operating system boot process. The process may vary depending upon the specifics of the operating system being loaded.
Each partition includes a data area 814, 834, 884, 894. Extended partitions may be further subdivided into logical partitions 880, 890. Although the location and size of the extended and primary partitions are determined from the MBR partition table, the size of each logical partition 890 is determined by a partition table within the boot sector 892 of that logical partition. The location of each logical partition is determined by the location of the extended partition 870 and the size of any preceding logical partitions 880 within the extended partition as defined by the partition table in their respective boot sectors 882.
One or more files may be stored within the data area of each partition. The file system utilized may vary from partition to partition. The manner of storing and accessing the files is determined by the file system used by that partition. File A 816 and File B 818 may be stored within primary partition 810, for example. A file is the information contained by one or more logically related sectors of the hard drive. The sectors are not necessarily contiguous or sequential, but they do reside within the same partition. If the sectors of a selected file are non-sequential, the file is termed “fragmented”.
During the boot process, peripheral devices are checked in a pre-determined sequence to determine whether they are bootable. A bootable hard drive will have an active partition with an operating system bootstrap loader. Program control is transferred several times to bootstrap ever larger portions of the operating environment until the operating system is booted.
Once program control is transferred to the MBR code, the MBR code locates an active partition 830 from the partition table and transfers control to the code within the boot sector 832 of the active partition 830. The active partition is usually the partition from which the computer will attempt to load the operating system. The first sector of the active partition is the partition boot sector. The code within the active partition boot sector is also referred to as the boot sector bootstrap. The boot sector bootstrap is operating system specific.
The code in the active partition boot sector directs the computer to execute a loader program for loading the operating system. The boot sector code is specific to the file system used by the active partition because it must be able to locate files within the partition. The loader program may be designed to load a specific operating system (e.g., OS1) or the loader program may permit a selection from a variety of operating systems (“multi-boot”). In the illustrated embodiment, the loader is one of the OS1 support files 844-846 that loads the OS1 kernel 842. The loader then proceeds to load the operating system of choice.
Microsoft® Windows® operating systems provide a modifiable file “boot.ini” to permit the user to select a particular instance of the Microsoft® Windows® operating system to boot. Different instances, for example, may load different drivers or may otherwise be tailored for specific applications. In this case, “boot.ini” is modified to append a reference to the boot loader “bld.com” for the boot image and to identify “bld.com” as the default.
When the environment supports multiple operating systems, typically the one designated as the default will be loaded unless the user acts within some pre-determined time frame or otherwise executes an option to prevent the default from being loaded. In one embodiment, the boot loader for the operating system residing within the boot image is designated as the default within the “boot.ini” file so that it will automatically be selected unless the user intervenes. In an alternative embodiment, the user will need to intervene to select the boot image operating system during the boot process.
The boot image 1000 is similar to another partition on the hard drive with the exception that the boot image is a contiguous file. In particular, the boot image includes an operating system kernel (OS2 kernel 1020), the operating system support files 1010, and any other files 1030 deemed appropriate. The boot image includes a boot sector 1002 that functions the same as a boot sector on any other partition of the first peripheral device. The terms “OS1” and “OS2” are intended to further distinguish the operating system that resides within the boot image from the operating system residing on the first peripheral device outside of the region used by the boot image. In one embodiment, OS1 and OS2 are different instances of the same operating system. Alternatively, OS1 and OS2 may be different operating systems.
Preferably recovery should occur in a “trusted” environment. This requires the computer to be booted with a trusted operating system such as the boot image operating system rather than trying to perform the recovery within an operating system or environment that may have been compromised as a result of unknown elements. The active partition boot sector, for example, may be corrupted. In order to ensure that recovery takes place in a trusted environment, the boot loader associated with the boot image enables the boot image to be recognized as a peripheral in the boot sequence so that the computer can be booted from the boot image.
Upon an initial reset, the computer begins the boot process illustrated in
Referring to
The boot image boot loader then issues an instruction to perform a reset in step 1120. The reset of 1120 is a “soft” reset so that the re-direction instructions are intact upon reset.
A specific sector L of the boot image, for example, begins at the location D+f(L) within the active partition of the first peripheral device. D is the logical block address from the beginning of the active partition to the beginning of the boot image residing on the hard drive. f(L) is a mapping function designed to accommodate for the differences in sector sizes between the second drive that the boot image represents and the first drive that the boot image is actually stored on. The XBDA program code “hooks” the BIOS interrupt 13h function and performs the appropriate mapping to re-direct the access requests. In step 1220, an interrupt 19h (INT 19h) is executed to perform a soft reset.
Although a boot sequence may include a floppy drive, optical drive, and hard drive, the sequence typically starts with the floppy drive. Upon the reset performed by the boot image boot loader, the boot sequence is effectively modified to ensure that floppy drive access requests are directed to the boot image. An attempt to retrieve the boot sector from the first drive (e.g., floppy drive) is re-directed to provide the boot sector within the boot image residing on the hard drive. The boot process continues to load the operating system of the boot image and launch the recovery process. This boot image is sufficient to load an operating system, perform a recovery program to copy critical operating system files from the boot image to the standard locations on the first peripheral device, and exit.
A hard reset should be performed at the conclusion of the recovery to prevent subsequent resets of the computer from automatically booting the boot image as a result of the re-direction. The hard reset eliminates the re-direction (and effective re-sequencing) of the boot sequence that was caused by the boot image boot loader code.
The boot image and associated techniques disclosed permit effectively changing the peripheral boot sequence (at least temporarily) without modifying any parameter data stored in the nonvolatile memory and without performing firmware BIOS modifications. Modification of boot sectors is not required.
If the boot image is not selected as determined by step 1330, then the standard operating system is booted using critical files stored in standard locations (i.e., locations distinct from the boot image) on the first peripheral device in step 1340. Upon a successful boot, the copy script is executed to copy the critical files to the boot image residing on the first peripheral device in step 1350.
If the boot image is selected for booting, then the boot loader (“bld.com”) is executed to re-direct access requests for a second peripheral device to the boot image residing on the first peripheral device in step 1360. The re-direction may be accomplished using program code within the XBDA that hooks BIOS interrupt 13h. The program code includes processor executable instructions for re-mapping access requests from the second peripheral device to the boot image. A reset is then performed in step 1362. The reset of step 1362 is a soft reset to preserve the re-direction instructions. The computer will then proceed through the peripheral boot sequence until it finds a bootable peripheral. The re-direction code ensures that the computer will boot the boot image operating system in step 1364.
Once the boot image operating system is successfully booted, a recovery program within the boot image copies critical files from the boot image to their associated standard locations on the first peripheral device in step 1370. The boot image may be delivered with the recovery program already scheduled to be executed upon successful boot of the boot image operating system. A reset is performed in step 1380 to prevent further activity from altering the critical files within the boot image. The reset of step 1380 is a hard reset to eliminate the re-direction of peripheral device access requests. For example, the hard reset may clear or flush RAM 560 to ensure that the program code stored within the XBDA is eliminated.
Thus methods and apparatus enabling recovery of operating system critical files have been provided. The disclosed techniques enable recovery of critical files without the need for removable media.
In the preceding detailed description, the invention is described with reference to specific exemplary embodiments thereof. Methods and apparatus enabling recovery of certain critical files have been provided. Various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
