Information processing device and program

Abstract

This prevents insufficient EEPROM storage capacity caused by backing up boot data created during updates. [Solution] The information processing device includes a storage device 1 that stores a boot program for starting an operating system (OS), a storage device 2 having a storage capacity greater than or equal to that of a first storage medium that stores OS boot data, a storage device 3 having a storage capacity greater than that of a second storage medium that stores software and user data, and an update processing unit that updates at least one of the boot data and the software. When the update processing unit updates the boot data, it stores the updated boot data in the storage device 3, starts the OS using the updated boot data, stores the boot data stored in the storage device 2 in the storage device 3, and replaces the boot data stored in the storage device 2 with the updated boot data.

Description

Technical Field

[0001] Embodiments of the present invention relate to an information processing apparatus and a program.

Background Art

[0002] Conventionally, when updating startup data or software of an operating system (OS) of an information processing apparatus, a technique of creating a backup of the startup data so that it can be used for startup in case of problems during the update has been known. Here, the startup data is a kernel or an initial RAM (Random Access Memory) disk used at the startup of the OS. Also, these startup data are usually stored in a relatively fast-operating EEPROM (Electrically Erasable Programmable Read-Only Memory), and its backup is also usually created in the EEPROM.

Summary of the Invention

Problems to be Solved by the Invention

[0003] The problem to be solved by the present invention is to provide an information processing apparatus and a program that can prevent a shortage of the storage capacity of the EEPROM that occurs in the backup of the startup data created during the update.

Means for Solving the Problems

[0004] The information processing apparatus of the embodiment includes a first storage medium for storing an operating system startup program, a second storage medium having a storage capacity greater than or equal to the storage capacity of the first storage medium for storing startup data for the operating system, a third storage medium having a storage capacity greater than the storage capacity of the second storage medium for storing one or more software and user data, and an update unit for updating at least one of the startup data and the software. When the update processing unit updates the startup data, it stores the updated startup data in the third storage medium, starts the operating system using the updated startup data stored in the third storage medium, stores the startup data stored in the second storage medium in the third storage medium, and replaces the startup data stored in the second storage medium with the updated startup data. [Brief explanation of the drawing]

[0005] [Figure 1] Figure 1 is a hardware configuration diagram of the information processing device according to the first embodiment. [Figure 2] Figure 2 is a functional block diagram of the update processing unit according to the first embodiment. [Figure 3] Figure 3 shows the update process according to the first embodiment. [Figure 4] Figure 4 is a flowchart showing the procedure for the update process according to the first embodiment. [Figure 5] Figure 5 is a functional block diagram of the update processing unit according to the second embodiment. [Figure 6] Figure 6 shows the patch application process according to the second embodiment. [Figure 7] Figure 7 is a flowchart showing the procedure for the patch application process according to the second embodiment. [Figure 8] Figure 8 is a functional block diagram of the update processing unit according to the second embodiment. [Figure 9] Figure 9 shows an example of flag information according to the third embodiment. [Figure 10] Figure 10 shows another example of flag information according to the third embodiment. [Figure 11] Figure 11 is a flowchart showing the procedure for the update process according to the third embodiment. [Modes for carrying out the invention]

[0006] (First embodiment) Figure 1 is a hardware configuration diagram of the information processing device according to the first embodiment.

[0007] The information processing device 10 includes a CPU (Central Processing Unit) 101, ROM (Read Only Memory) 102, EEPROM (Erasable and Programmable Read Only Memory) 103, RAM (Random Access Memory) 104, HDD (Hard Disk Drive) 105, media I / F 108, display 109, network I / F 110, keyboard 111, mouse 112, CD-RW (Compact Disc-Rewritable) drive 114, and bus line 115.

[0008] The CPU 101 controls the overall operation of the information processing device 10.

[0009] ROM102 is a device that stores the program (boot program) that starts the OS. The boot program is, for example, the OS boot program. ROM102 is an example of the first storage medium and is referred to as storage device 1 in this embodiment. Note that EEPROM may be used instead of ROM as the first storage medium.

[0010] EEPROM103 is a device that stores data used when the OS starts up (boot data). Boot data includes, for example, the OS kernel and the initial RAM disk. EEPROM103 has a storage capacity greater than or equal to the storage capacity of ROM102. EEPROM103 is an example of a second storage medium and is referred to as storage device 2 in this embodiment.

[0011] RAM104 is memory used as the work area for CPU101.

[0012] HDD105 is a device that stores various data such as RFS (Root File System), software, and user data. In this embodiment, RFS and software are collectively referred to as software, etc. HDD105 has a larger storage capacity than EEPROM103. HDD105 is an example of a third storage medium and is referred to as storage device 3 in this embodiment. Note that an SSD (Solid State Drive) may be used instead of an HDD as the third storage medium.

[0013] The media interface 108 controls the reading or writing (storage) of data to or from the recording medium 107, such as flash memory.

[0014] Display 109 displays various information such as the cursor, menus, windows, text, or images.

[0015] Network I / F 110 is an interface for data communication using the communication network 100.

[0016] The keyboard 111 is a type of input device equipped with multiple keys for inputting characters, numbers, and various instructions. The mouse 112 is a type of input device used for selecting and executing various instructions, selecting objects to process, moving the cursor, and so on.

[0017] The CD-RW drive 114 controls the reading or writing of various data to the CD-RW 113 as an example of a removable recording medium.

[0018] The information processing apparatus 10 may further be configured to control the reading or writing (storage) of data to an external PC (Personal Computer) or an external device connected by wire or wirelessly such as Wi-Fi (Wireless Fidelity).

[0019] Note that the CD-RW drive 114 may be replaced with a CD-R drive or the like. Further, the information processing apparatus 10 may be constructed by a single computer, or may be constructed by a plurality of computers arbitrarily assigned by dividing each part (function, means, or storage part).

[0020] FIG. 2 is a functional block diagram of the update processing unit 200 according to the first embodiment. The update processing unit 200 is realized by the instruction of the CPU 101 shown in FIG. 1 and performs processing (update processing) necessary for updating startup data and software. The update processing unit 200 includes a data reception unit 201, a parameter change unit 202, a restart unit 203, and a data copy unit 204.

[0021] The data reception unit 201 receives update data such as startup data and software. The update data includes the updated startup data, the updated software, and the like. The update data may be either data read by the media I / F 108 or data received by the network I / F 110.

[0022] The parameter change unit 202 changes a parameter (startup parameter) indicating the read destination of the startup data and a partition (execution partition) where software and the like are executed.

[0023] The restart unit 203 restarts the OS during the update process of the startup data and software.

[0024] The data copy unit 204 creates copies and backups of startup data and software data.

[0025] Next, the update process of this embodiment will be described using Figures 3 and 4. Figure 3 is a diagram showing the update process according to the first embodiment. Figure 4 is a flowchart showing the procedure of the update process according to the first embodiment.

[0026] First, the data receiving unit 201 receives the update data (step S100). The received update data is stored in the storage device 3 (HDD 105). In the example in Figure 3, the updated boot data, RFS, and software A are received and stored in partition 2 of the storage device 3 (Figure 3(a)). In this example, the storage device 3 includes partition 1 and partition 2 as logical partitions, and the pre-update RFS, software A, software B, user data, etc. are stored in partition 1. Also, a logical partition is an example of an area on the third storage medium.

[0027] Next, if the update data includes the updated boot data (step S101: Yes), the parameter change unit 202 modifies the boot parameters so that the updated boot data is used the next time the OS is started (step S102). Then, the restart unit 203 restarts the OS (step S103).

[0028] On the other hand, if the update data does not include the startup data after the update (step S101: No), the process proceeds to step S107.

[0029] When the OS starts up due to the restart in step S103, the data copy unit 204 backs up the boot data from storage device 2 to storage device 3 (step S104). In the example in Figure 3, the boot data before the update is copied as a backup to partition 2 of storage device 3 (Figure 3(b)).

[0030] Next, the data copy unit 204 updates the boot data (step S105). Specifically, the data copy unit 204 copies the updated boot data to storage device 2 and deletes the boot data before the update. In other words, the data copy unit 204 replaces the boot data on storage device 2 before the update with the boot data after the update. As a result, the boot data on storage device 2 becomes the updated boot data. In the example in Figure 3, the boot data on partition 2 of storage device 3 before the update has been replaced with the boot data after the update (Figure 3(c)).

[0031] Then, the parameter modification unit 202 restores the startup parameters to their original state (step S106). Specifically, the parameter modification unit 202 modifies the startup parameters so that the updated startup data stored in storage device 2 is used the next time the OS is started.

[0032] If the update data includes updated data other than the boot data (step S107: Yes), the parameter change unit 202 changes the execution partition so that the update software, etc., is executed the next time the OS starts (step S108). In the example in Figure 3, the execution partition for software A is changed from partition 1 to partition 2. Then, the restart unit 203 restarts the OS (step S109).

[0033] On the other hand, if the update data does not contain any updated data other than the startup data (step S107: No), the process terminates.

[0034] When the OS starts up due to the restart in step S109, the data copy unit 204 updates data other than the boot data (step S110). Specifically, the data copy unit 204 replaces the software etc. before the update with the software etc. after the update. As a result, the updated software etc. is stored twice on the storage device 3. In the example in Figure 3, the RFS and software A before the update on partition 1 of the storage device 3 are replaced with the RFS and software A after the update on partition 2 (Figure 3(c)).

[0035] Thus, according to this embodiment, since the backup of the startup data created during the update is stored in the storage device 3 with a large storage capacity, it is possible to prevent a shortage of storage capacity in the EEPROM 103 caused by such backup.

[0036] Furthermore, according to this embodiment, since the update process is performed as described above, even if a problem occurs in updating (replacing) the startup data, the OS can be restarted using the backed-up startup data from before the update, and the startup data can be updated again.

[0037] Furthermore, according to this embodiment, update data can be received and stored in the storage device 3 in the background without stopping the normal operation of the information processing device 10. If the update process includes software installation and a restart is required for installation, the installation may be scheduled to be performed at night or on holidays when normal operation is not required.

[0038] Furthermore, according to this embodiment, since the updated software and the like are stored redundantly on different partitions, even if corruption occurs in one partition, it is possible to recover the data using the data in the other partition.

[0039] (Second embodiment) The second embodiment further modifies the software by applying patches. In the following description of the second embodiment, the same parts as the first embodiment will be omitted, and the differences from the first embodiment will be described.

[0040] Figure 5 is a functional block diagram of the update processing unit 200 according to the second embodiment. The difference from Figure 2 is that the update processing unit 200 further includes a patch application unit 210.

[0041] The patch application unit 210 applies a patch to the software to be updated and performs the software update.

[0042] Next, the patch application process will be explained using Figures 6 and 7. Figure 6 is a diagram showing the patch application process according to the second embodiment. Figure 7 is a flowchart showing the procedure for the patch application process according to the second embodiment.

[0043] First, the data receiving unit 201 receives a patch, which is update data (step S200). The received patch is then stored in the storage device 3. In the example in Figure 6, the patch for software A (patch A) is received and stored in partition 2 of the storage device 3 (Figure 6(a)).

[0044] The data copy unit 204 copies the software to be patched to a partition other than the partition in which the software is stored (step S201). In the example in Figure 6, software A stored in partition 1 is copied to partition 2 (Figure 6(a)).

[0045] The data copy unit 204 creates a backup of the target software copied to another partition (step S202). In the example in Figure 6, a backup of software A on partition 2 is created (Figure 6(b)).

[0046] Next, the patch application unit 210 applies the patch to the target software copied to another partition (step S203). In the example in Figure 6, the patch is applied to software A on partition 2 (Figure 6(c)).

[0047] Next, the parameter modification unit 202 changes the execution partition so that the updated software A is executed the next time the OS starts (step S204). In the example in Figure 6, the execution partition for software A is changed from partition 1 to partition 2. Then, the restart unit 203 restarts the OS (step S205).

[0048] When the OS starts up due to the restart in step S109, the patch application unit 210 applies the patch to the target software on the original partition (step S206). In the example in Figure 6, the patch is applied to software A on partition 1 (Figure 6(d)). After the update process for software A is completed, the backup data for software A may be deleted as shown in Figure 6(d), or it may be kept as a backup. If the backup data for software A is kept as a backup, for example, if a problem occurs with software A after the update, the backup can be used to restore software A to its state before the update.

[0049] Thus, according to this embodiment, since the patched software is stored redundantly on different partitions, even if corruption occurs on one partition, it is possible to recover the data using the data on the other partition.

[0050] (Third embodiment) The third embodiment manages the update process using flag information. In the following description of the third embodiment, the parts that are the same as those of the first embodiment will be omitted, and the parts that differ from the first embodiment will be described.

[0051] Figure 8 is a functional block diagram of the update processing unit 200 according to the second embodiment. The difference from Figure 2 is that the update processing unit 200 further includes a flag information setting unit 220.

[0052] The flag information setting unit 220 sets flag information for managing the update process. Here, setting flag information includes generating flag information and modifying flag information.

[0053] Figure 9 shows an example of flag information according to the third embodiment. In Figure 9, 8-bit flag information capable of managing 8 update targets is shown. Here, each bit position is assigned to each update target, and the flag value at each bit position indicates the flag value for each update target. Patch A represents the patch for software A, and Patch B represents the patch for software B.

[0054] In Figure 9, if the item to be updated is not a patch, a flag value of "1" indicates that the item should be updated, and a flag value of "0" indicates that the item should not be updated. If the item to be updated is a patch, a flag value of "1" indicates that the update data includes the patch, and a flag value of "0" indicates that the update data does not include the patch. In the figure, "-" indicates that the bit position is unused.

[0055] Figure 9(a) shows an example of flag information generated when the update data includes all updated data for all target systems but does not include patches. Figure 9(b) shows an example of flag information generated when the update data includes only the updated startup data. Figure 9(c) shows an example of flag information generated when the update data includes only the updated software, etc. Figure 9(d) shows an example of flag information generated when the update data includes only software patches.

[0056] Figure 10 shows another example of flag information according to the third embodiment. The difference from Figure 9 is that the flag information includes an update flag and a patch flag. The update flag indicates whether or not the updated data for each update target is included in the update data, and the patch flag indicates whether or not each patch is included in the update data. Also, each update data corresponding to Figures 10(a) to (b) is the same as each update data corresponding to Figures 9(a) to (b).

[0057] The flag information setting unit 220 analyzes the update data to generate flag information as shown in Figures 9 and 10, and changes the flag information according to the progress of the update process. For example, when the kernel update is complete, the flag information setting unit 220 changes the kernel flag in Figure 9(a) and the kernel update flag in Figure 10(a) from 1 to 0. Also, for example, when the application of the patch to software A is complete, the flag information setting unit 220 changes the patch A flag in Figure 9(d) and the software A patch flag in Figure 10(a) from 1 to 0. As a result, when all the values ​​of the flag information become 0, it can be determined that the update has been completed successfully.

[0058] Note that the flag value "1" is an example of the first value, and the flag value "0" is an example of the second value. The definition of the flag value is not limited to the above; for example, you could define the target to be updated as value "0" and the target not to be updated as value "1".

[0059] Figure 11 is a flowchart of the update process procedure according to the third embodiment. The difference from Figure 4 is the addition of steps S301, S307, and S313, which set and update flags. The operation of steps S300, S302-S306, and S308-S312 in Figure 11 is the same as the operation of steps S100, S101-S105, and S106-S110 in Figure 4, so the explanation is omitted.

[0060] The flag information setting unit 220 analyzes the update data and generates flag information (step S301). The flag information setting unit 220 also updates the flag information to indicate that the update of the startup data is complete (step S307), and updates the flag information to indicate that the update of data other than the startup data is complete (step S313).

[0061] Thus, according to this embodiment, the update process can be managed using flag information.

[0062] As explained above, according to the first to third embodiments, the backup of the startup data created during the update is stored in the storage device 3 with a large storage capacity, thus preventing a shortage of storage capacity in the EEPROM 103 caused by such backup.

[0063] The programs executed by the information processing device 10 in each embodiment described above are provided as installable or executable files recorded on a computer-readable recording medium such as a CD-ROM, flexible disk (FD), CD-R, or DVD (Digital Versatile Disk).

[0064] Furthermore, the program executed by the information processing device 10 in each embodiment may be stored on a computer connected to a network such as the Internet and provided by downloading it via the network. Alternatively, the program executed by the information processing device 10 in each embodiment may be provided or distributed via a network such as the Internet.

[0065] Furthermore, the programs for each embodiment may be pre-installed and provided in ROM or the like.

[0066] The program executed by the information processing device 10 in each embodiment has a modular configuration that includes the parts included in the update processing unit 200 described above (data receiving unit 201, parameter changing unit 202, restart unit 203, and data copying unit 204, etc.). In actual hardware, the CPU (processor) reads the program from the recording medium and executes it, thereby loading the above parts onto the main memory and generating the program.

[0067] Each function of the embodiments described above can be realized by one or more processing circuits. Hereinafter, "processing circuit" as used herein includes processors programmed to execute each function by software, such as processors implemented by electronic circuits, as well as devices such as ASICs (Application Specific Integrated Circuits), DSPs (Digital Signal Processors), FPGAs (Field Programmable Gate Arrays), and conventional circuit modules designed to execute each function described above.

[0068] While several embodiments of the present invention have been described, these embodiments are presented as examples only and are not intended to limit the scope of the invention. These novel embodiments can be carried out in a variety of other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included in the scope and spirit of the invention, as well as in the claims of the invention and its equivalents. [Explanation of Symbols]

[0069] 10 Information Processing Devices 100 Communication Networks 101 CPU 102 ROM 103 EEPROM 104 RAM 105 HDD 107 Recording media 108 Media I / F 109 displays 110 Network I / F 111 keyboard 112 mice 113 CD-RW 114 CD-RW drive 115 Bus Line 200 Update Processing Unit 201 Data Receiving Unit 202 Parameter Change Section 203 Restart part 204 Data Copy Section 210 Patch application area 220 Flag Information Setting Section [Prior art documents] [Patent Documents]

[0070] [Patent Document 1] Japanese Patent Publication No. 2018-156638

Claims

1. A first storage medium that stores the boot program for starting the operating system, A second storage medium having a storage capacity greater than or equal to the storage capacity of the first storage medium, which stores the startup data for the operating system, A third storage medium having a storage capacity greater than the storage capacity of the second storage medium, which stores one or more software and user data, An update processing unit that updates at least one of the startup data and the software, Equipped with, When the update processing unit updates the startup data, The updated startup data is stored in the third storage medium. The operating system is started using the updated startup data stored in the third storage medium. The startup data stored in the second storage medium is stored in the third storage medium. The startup data stored in the second storage medium is replaced with the updated startup data. An information processing device characterized by the following:

2. When the update processing unit updates the software, The updated software is stored in a separate area of ​​the third storage medium from the software before the update. Switch from the setting to use the software before the update to the setting to use the software after the update. The information processing apparatus according to claim 1, wherein the software before the update is replaced with the software after the update.

3. When the update processing unit updates the software by applying a patch, The patch is stored in the third storage medium. A copy of the software is stored in an area of ​​the third storage medium separate from the software. The information processing apparatus according to claim 2, wherein the patch is applied to the software, and after running the software to which the patch has been applied, the patch is applied to a copy of the software.

4. The information processing apparatus according to claim 1, wherein the update processing unit generates flag information that indicates targets to be updated with a first value, targets not to be updated with a second value different from the first value, and modifies the flag information to indicate targets whose updates have been completed with the first value.

5. The aforementioned boot data consists of the kernel and the initial RAM disk. The information processing apparatus according to any one of claims 1 to 4.

6. Computers, This system functions as an update processing means for updating at least one of the following: startup data for the operating system stored in a second storage medium having a storage capacity greater than or equal to the storage capacity of a first storage medium that stores a startup program for starting the operating system; and one or more software programs stored in a third storage medium having a storage capacity greater than the storage capacity of the second storage medium. When updating the startup data, the update processing means The updated startup data is stored in the third storage medium. The operating system is started using the updated startup data stored in the third storage medium. The startup data stored in the second storage medium is stored in the third storage medium. The startup data stored in the second storage medium is replaced with the updated startup data. A program characterized by the following features.

Images