System restoration method and device, and electronic device

Abstract

This application provides a system restore method, apparatus, and electronic device. The method includes: in a temporary operating system environment, modifying the partition information of a non-boot drive to first partition information; transferring file data from each partition of the boot drive to the corresponding partition of the non-boot drive; copying the partition boot code and partition boot flag from the master boot record (MBR) of the boot drive to the corresponding partition area of ​​the non-boot drive; modifying the partition information of the boot drive to second partition information and clearing the master boot record of the boot drive; installing a system boot manager on the non-boot drive; and swapping the identification information of the boot drive and the non-boot drive. The technical solution provided by this application can migrate the system and important data to an existing non-boot drive in an electronic device after the boot drive is damaged, realizing the role swapping of the boot drive and the non-boot drive and reducing the hardware cost of system restore.

Description

Technical Field

[0001] This application relates to the field of computer and information technology, and in particular to a system restoration method, apparatus and electronic device. Background Technology

[0002] In modern urban rail transit operation systems, turnstile systems rely on specific hardware configurations and software systems to work together, playing a crucial role in ensuring smooth passenger passage, accurately recording transaction data, and maintaining overall operational order.

[0003] Gate systems typically use Linux. In Linux, the boot drive stores the Linux boot manager, allowing users to choose which kernel to boot from. Therefore, damage to the boot drive severely impacts the system's boot data, rendering it unable to boot. Currently, when a boot drive fails, the usual approach is to replace the boot drive first and then restore the Linux system using backup and restore tools. However, this method is costly in terms of hardware. Summary of the Invention

[0004] In view of this, embodiments of this application provide a system restore method, apparatus, and electronic device to reduce the hardware cost of system restore.

[0005] To achieve the above objectives, in a first aspect, embodiments of this application provide a system restoration method, which is applied to an electronic device, and the method includes: In a temporary operating system environment, the partition information of the non-boot drive is modified to the first partition information, wherein the first partition information is consistent with the partition information of the boot drive, and the file system type of each partition corresponding to the first partition information is consistent with the file system type of each partition in the boot drive. The file data of each partition of the boot drive is transferred to the partition corresponding to the non-boot drive; Copy the partition boot code and partition boot flag from the master boot record of the boot drive to the partition area corresponding to the non-boot drive; The partition information of the boot drive is modified to the second partition information, and the master boot record of the boot drive is cleared; the second partition information is consistent with the partition information of the non-boot drive before modification, and the file system type of each partition corresponding to the second partition information is consistent with the file system type of each partition of the non-boot drive before modification; Install a system boot manager on the non-boot drive, and swap the identification information of the boot drive and the non-boot drive. The identification information includes a universally unique identifier and / or drive letter information.

[0006] In one possible implementation of the first aspect, before modifying the partition information of the non-boot drive to the first partition information, the method further includes: The system boots into the temporary operating system environment based on the system boot file pre-stored in the system boot disk. The system boot file is an image file of a distribution that is the same as or similar to the operating system environment of the electronic device.

[0007] In one possible implementation of the first aspect, before modifying the partition information of the non-boot drive to the first partition information, the method further includes: Back up the data stored in the non-boot drive to the storage medium; After modifying the partition information of the boot drive to the second partition information, the method further includes: The data stored in the storage medium is stored in the boot drive.

[0008] In one possible implementation of the first aspect, after copying the partition boot code and partition boot flag from the master boot record of the boot drive to the partition area corresponding to the non-boot drive, the method further includes: Check the partition boot flag of the non-boot drive. If the value of the partition boot flag is not 1, change the value of the partition boot flag to 1.

[0009] In one possible implementation of the first aspect, after copying the partition boot code and partition boot flag from the master boot record of the boot drive to the partition area corresponding to the non-boot drive, the method further includes: Check if the non-boot drive has bad blocks, and if so, repair the bad blocks.

[0010] In one possible implementation of the first aspect, a file synchronization transfer tool is used to transfer file data from each partition of the boot drive to the corresponding partition of the non-boot drive.

[0011] Secondly, embodiments of this application provide a system restore apparatus, the apparatus comprising: The modification module is used to modify the partition information of a non-boot drive to the first partition information in a temporary operating system environment, wherein the first partition information is consistent with the partition information of the boot drive, and the file system type of each partition corresponding to the first partition information is consistent with the file system type of each partition in the boot drive. A transmission module is used to transfer file data from each partition of the boot drive to the partition corresponding to the non-boot drive; The copy module is used to copy the partition boot code and partition boot flag from the master boot record of the boot drive to the partition area corresponding to the non-boot drive; The modification module is further configured to: modify the partition information of the boot drive to the second partition information, and clear the master boot record of the boot drive; the second partition information is consistent with the partition information of the non-boot drive before modification, and the file system type of each partition corresponding to the second partition information is consistent with the file system type of each partition of the non-boot drive before modification; install a system boot manager in the non-boot drive, and exchange the identification information of the boot drive and the non-boot drive, wherein the identification information includes a universally unique identifier and / or drive letter information.

[0012] In one possible implementation of the second aspect, the modification module is further configured to: Before modifying the partition information of the non-boot drive to the first partition information, the temporary operating system environment is entered based on the system boot file pre-stored in the system boot disk. The system boot file is an image file of a distribution that is the same as or similar to the operating system environment of the electronic device.

[0013] In one possible implementation of the second aspect, the modification module is further configured to: Before modifying the partition information of the non-boot drive to the first partition information, the data stored in the non-boot drive is backed up to the storage medium; After modifying the partition information of the boot drive to the second partition information, the data stored in the storage medium is stored in the boot drive.

[0014] In one possible implementation of the second aspect, the copying module is further configured to: after copying the partition boot code and partition boot flag from the master boot record of the boot drive to the partition area corresponding to the non-boot drive, check the partition boot flag of the non-boot drive, and if the value of the partition boot flag is not 1, modify the value of the partition boot flag to 1.

[0015] In one possible implementation of the second aspect, the copying module is further configured to: after copying the partition boot code and partition boot flag from the master boot record of the boot drive to the partition area corresponding to the non-boot drive, check whether there are bad blocks in the non-boot drive, and repair the bad blocks if there are bad blocks in the non-boot drive.

[0016] In one possible implementation of the second aspect, the transmission module is specifically used to: use a file synchronization transmission tool to transfer file data from each partition of the boot drive to the partition corresponding to the non-boot drive.

[0017] Thirdly, embodiments of this application provide an electronic device, including: a memory and a processor, wherein the memory is used to store a computer program; and the processor is used to execute the method described in the first aspect or any embodiment of the first aspect when the computer program is invoked.

[0018] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect or any embodiment of the first aspect.

[0019] Fifthly, embodiments of this application provide a computer program product that, when run on an electronic device, causes the electronic device to execute the system restore method described in any one of the first aspects.

[0020] The technical solution provided in this application embodiment can modify the partition information of a non-boot drive to first partition information in a temporary operating system environment. The first partition information is consistent with the partition information of the boot drive, and the file system type of each partition corresponding to the first partition information is consistent with the file system type of each partition in the boot drive. Then, the file data of each partition of the boot drive is transferred to the corresponding partition of the non-boot drive, and the partition boot code and partition boot flag in the master boot record of the boot drive are copied to the corresponding partition area of ​​the non-boot drive. Next, the partition information of the boot drive can be modified to second partition information, and the master boot record of the boot drive is cleared. The second partition information is consistent with the partition information of the non-boot drive before modification, and the file system type of each partition corresponding to the second partition information is consistent with the file system type of each partition of the non-boot drive before modification. A system boot manager is installed in the non-boot drive, and the identification information of the boot drive and non-boot drive is swapped. The identification information includes a universally unique identifier and / or drive letter information. The technical solution provided in this application embodiment can migrate or swap the system and important data to the existing non-bootable drive in the device during system restoration. This not only utilizes the existing small-capacity non-bootable drive on the device to complete the system boot task, but also fully releases the storage capacity of the original boot drive, transforming it into a high-efficiency data storage disk. Therefore, by swapping the roles of the boot drive and the non-bootable drive, the use of additional hardware devices can be effectively reduced while achieving system restoration, thereby lowering hardware procurement and maintenance costs. Furthermore, this can also reduce data security risks and potential economic losses caused by drive malfunctions, providing a more economical and reliable solution for system operation and maintenance. Attached Figure Description

[0021] Figure 1 A schematic diagram of the first system restoration process provided in this application embodiment; Figure 2 A schematic diagram of the second system restoration process provided in this application embodiment; Figure 3 A schematic diagram of the logic flow of system restoration provided in the embodiments of this application; Figure 4 This is a schematic diagram of the system restoration device provided in the embodiments of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0022] To facilitate understanding of the technical solutions in the embodiments of this application, some terms involved in the embodiments of this application will be explained below: Linux: An open-source, Unix-like operating system created by Linus Torvalds in 1991. Strictly speaking, Linux is only the kernel, not a complete operating system. In everyday language, "Linux" usually refers to a Linux distribution that includes the kernel and its accompanying software.

[0023] Kernel: The core of the operating system, responsible for managing hardware resources (central processing unit, memory, devices, etc.), process scheduling, security control and other low-level functions.

[0024] Boot drive: The hard drive that can boot a computer's operating system is called a boot drive or boot disk. The boot drive is the core storage device that reads and executes the bootloader and operating system kernel files first when the system starts up, and it can be recognized as the preferred boot device by the Basic Input / Output System (BIOS).

[0025] Non-boot drive: A storage device (such as a hard drive, solid-state drive, or external storage) that does not contain the core files of the operating system. Non-boot drives are only used to store data, applications, or expand system capacity and cannot boot the operating system independently.

[0026] Master Boot Record (MBR): Stored in the first sector (512 bytes) of the hard drive, it contains the disk partitioning and boot management scheme. Its core function is to define the partition structure and boot the operating system. The 512-byte structure is divided into 446 bytes of boot code (or partition boot code), 64 bytes of partition table, and 2 bytes of boot signature bytes.

[0027] Basic Input / Output System (BIOS): Firmware program embedded in the motherboard chip, responsible for hardware initialization, self-test, and booting the operating system during the initial computer startup. It is the first software to run after the computer is powered on, providing the operating system with a low-level hardware control interface.

[0028] A bootable disk is a bootable storage medium (such as a USB flash drive, CD-ROM, or external hard drive) that stores the operating system boot loader and system installation / rescue files. Typically, it is inserted into the Universal Serial Bus (USB) interface of an electronic device and can be selected to boot from the device via the BIOS. It is used to install the system, repair faults, or run a standalone operating system, similar in principle to a system boot drive permanently installed in the electronic device.

[0029] Universally Unique Identifier (UUID): A 128-bit (16-byte) string used to uniquely identify a drive, storage device, or partition.

[0030] Drive letter: In Linux, all drives are treated as files, and the sdx filenames stored under / dev / are used to identify the corresponding drive.

[0031] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is only for explaining specific embodiments and is not intended to limit the application. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0032] In the Linux system architecture, storage devices are functionally divided into two categories: one boot drive and 0, 1, or more non-boot drives. The former has a larger capacity and is used to host the boot partition, operating system files, and boot manager, responsible for system startup and kernel selection; its procurement cost is higher. The latter has a smaller capacity and serves as independent data storage media, not directly related to the system boot process; its procurement cost is lower. While this physical isolation design improves system stability, in high-reliability industrial scenarios such as subway turnstile systems, long-term uninterrupted operation (e.g., continuous power supply for 2-3 years) accelerates the aging of the boot drive (such as a solid-state drive), leading to large areas of bad blocks in critical storage areas and severely impacting system boot data. Non-boot drives, on the other hand, lack the ability to boot the Linux system and are isolated from the boot drive; their data is usually unaffected in the event of a system crash.

[0033] Currently, the industry standard solution after a system crash is to restore the system by replacing hardware (such as replacing the faulty solid-state drive) combined with backup and restore tools. However, such tools have significant technical limitations: the storage capacity of the target boot drive (the one to be replaced) must be greater than or equal to the capacity of the original drive (the one to be replaced); otherwise, a complete restoration of the system image cannot be achieved. This constraint is particularly prominent in hardware upgrade scenarios. While this solution can restore a crashed system, from a lifecycle management perspective, it increases hardware procurement costs, increases maintenance complexity, and generates higher hidden costs.

[0034] In view of this, embodiments of this application provide a system restore method, apparatus, and electronic device that can eliminate the limitation that the storage capacity of the target boot drive must be greater than or equal to the capacity of the original drive during system restore, thereby enabling the interchange of boot drives and non-boot drives and reducing hardware costs.

[0035] System restore methods can be applied to electronic devices, for example, Figure 1 A schematic diagram of the first system restoration process provided in this application embodiment is shown below. Figure 1 As shown, the method may include the following steps: Step S110: In the temporary operating system environment, modify the partition information of the non-boot drive to the first partition information.

[0036] Taking Linux as an example for electronic devices, a temporary operating system environment can be selected as the Linux Live environment (Live Mode). The Linux Live environment is a complete Linux operating system mode that can be booted directly from removable storage media (such as CDs, USB drives, or memory cards) without installation. As a lightweight Linux rescue / maintenance system running in memory, it can operate independently of the main system on the hard drive, used for repairing crashed systems, recovering data, partitioning, or hardware diagnostics. Its core features are that it requires no installation, runs entirely in Random Access Memory (RAM), has a large number of built-in utilities (partitioning, file recovery, network testing, password reset, etc.), supports mainstream hardware drivers, and can automatically erase all changes after shutdown, while also possessing the advantage of isolation.

[0037] In practice, you can use the `fdisk` command to create a Disk Operating System (DOS) type to meet the requirements of the MBR. Then, based on the partition information of the boot drive, modify the partition information of the non-boot drive to match the first partition information. The first partition information can be identical to the partition information of the boot drive, creating the same number and size of partitions as the boot drive. Since the file system structures of the non-boot drive and the boot drive are different—for example, the boot drive's file system type can be a Fourth Extended File System (ext4), while the non-boot drive's file system type can be a B-tree File System (Btrfs)—you can format the non-boot drive to have the same file system type as the partitions in the boot drive, ensuring that the non-boot drive and the boot drive have the same structure.

[0038] Furthermore, the pseudocode for modifying the partition information of the non-boot drive to the information of the first partition is as follows: #View the original boot drive partition information and file system type fdisk / dev / sda –l # Setting up and formatting non-boot drive partitions fdisk / dev / sdb $d (Delete partition) $ o (Create a DOS type disk, which is the type required by MBR) $ n (Create a new partition) -> Primary partition -> First partition -> Starts at 2048 bytes -> Ends at disk $ p (Print partition table information) $ w (Save) #Format to ext4 format mkfs.ext4 / dev / sdb1 #Mount two drive partitions separately mkdir / source mount / dev / sda1 / source mount / dev / sdb1 / mnt Figure 2 This is a schematic diagram of the second system restoration process provided in the embodiments of this application. (See attached diagram.) Figure 2 In some embodiments, the system restoration method may also include step S210 before step S110.

[0039] Step S210: Enter the temporary operating system environment based on the system boot files pre-stored in the system boot disk.

[0040] The system boot disk can store system boot files, which can be image files of a distribution that is the same as or similar to the operating system environment of the electronic device. The image file can be in ISO or GHOST format, etc., and this application embodiment does not limit this. For example, if the operating system of the electronic device is Fedora 20, burning tools such as Rufus or Ventoy can be used to burn Fedora 20 to a bootable storage medium (such as a USB flash drive, optical disc, or external hard drive) to create a system boot disk.

[0041] Understandably, users can choose a Linux distribution based on their needs. For example, when creating a system boot disk, they can choose to burn Fedora 23 to a bootable storage medium. This way, system recovery can be achieved while system updates are performed, ensuring that users can obtain the latest features and security patches in a timely manner.

[0042] After creating the system boot disk, you can connect it to an electronic device and select to boot from that device via the BIOS to enter a temporary operating system environment, where you can then perform subsequent operations.

[0043] In some embodiments, since the non-bootable drive is mounted in the operating system environment, if important data files are stored on it, the system restore method may also include step S220.

[0044] Step S220: Back up the data stored in the non-boot drive to the storage medium.

[0045] Before step S110, important data files stored on the non-bootable drive can be copied to a storage medium such as a USB flash drive or external hard drive for temporary data transfer and backup.

[0046] In some embodiments, to improve operational reliability and enable system recovery in the event of subsequent operational failures, a complete image backup of the Linux operating system environment on the current electronic device, including all drives mounted in the system, can be created using Linux backup and restore tools such as Acronis True Image or Clonezilla while the system is in normal use.

[0047] Step S120: Transfer the file data of each partition of the boot drive to the corresponding partition of the non-boot drive.

[0048] Taking system file data as an example, since both the boot drive and non-boot drives are mounted in the operating system environment, system file data in the boot drive can be transferred to the corresponding partition of the boot drive.

[0049] In some embodiments, compression tools can be used for system file data transfer. For example, the system file data of the boot drive can be compressed and packaged into a tar archive using a tar archive, stored on a USB drive as a temporary transfer, and then the tar archive can be decompressed onto a non-boot drive to achieve system file data transfer.

[0050] Since the tar command is a compression command, although packaging into tar can take up less space, it also means that the process of decompressing to the drive is very time-consuming.

[0051] Preferably, a file synchronization tool can be used to synchronize and transfer system file data. For example, the rsync tool can be used to transfer system file data to a non-bootable drive. An example of pseudocode for synchronizing and transferring files between bootable drive partitions is as follows: rsync -avP / source / mnt&&sync By using file synchronization and transfer tools, files can be copied quickly and incrementally, transferring only the differences between the source and target files. This can greatly save file transfer time and improve file migration efficiency.

[0052] Step S130: Copy the partition boot code and partition boot flag from the master boot record of the boot drive to the partition area corresponding to the non-boot drive.

[0053] Considering that the first 446 bytes of the Master Boot Record (MBR) contain the partition boot code that runs first during startup and can be used to boot the operating system, for example, the binary data of bytes 0x00 to 0x1BE in the boot drive's MBR can be exported using the dd tool. This includes the boot code in the first 0x00 to 0x1BD bytes and the partition boot flag in byte 0x1BE. Then, the partition boot code and partition boot flag can be used to precisely overwrite the corresponding area data of the non-boot drive using the dd tool. This allows the first 0x1BE (446) bytes of the boot drive to be overwritten at the beginning of the non-boot drive without truncating the subsequent data of the non-boot drive (partition table and the last two boot signature bytes), thus improving the reliability of system startup. An example of pseudocode for overwriting the MBR data of the non-boot drive is as follows: dd if= / dev / sda of= / dev / sdb bs=447 count=1 conv=notrunc In some embodiments, after step S130, refer to Figure 2 The system restore method may also include step S230.

[0054] Step S230: Check the partition boot flag of the non-boot drive. If the value of the partition boot flag is not 1, change the value of the partition boot flag to 1.

[0055] After copying the partition boot code and partition boot flag to the corresponding partition area of ​​the non-bootable drive, you can use a binary / hexadecimal editing and viewing tool to check the value of the overwritten 0x1BE byte partition boot flag in the non-bootable drive. If bit 7 of the value is not 1 (1 indicates bootable, 0 indicates non-bootable), it needs to be changed to 1 to identify the boot partition. Editing and viewing tools can include, but are not limited to, hexdump, HxD hex editor, etc.

[0056] In some embodiments, after step S130, refer to Figure 2 The system restore method may also include step S240.

[0057] Step S240: Check if there are bad blocks on the non-boot drive. If bad blocks are present on the non-boot drive, repair them.

[0058] Optionally, considering the possibility of errors during copying or writing, tools such as e2fsck or fsck.ext4 can be used to check for bad blocks in all areas after the non-boot drive has been overwritten. An example of pseudocode for bad block checking and repair is as follows: e2fsck -f / dev / sdb1 If bad blocks are present, they can be repaired using tools integrated into the Linux operating system.

[0059] Step S140: Modify the partition information of the boot drive to the second partition information and clear the master boot record of the boot drive.

[0060] Since the file data of each partition in the boot drive has been transferred to the partition corresponding to the non-boot drive, the original boot drive is no longer used as the system disk. The partition information of the boot drive can be modified to the second partition information using the `fdisk` command. The second partition information is identical to the partition information of the non-boot drive before the modification, and the file system type of each partition corresponding to the second partition is identical to the file system type of each partition on the non-boot drive before the modification. An example of pseudocode for clearing the boot drive's MBR boot record is as follows: dd if= / dev / zero of= / dev / sda bs=447 count=1 conv=notrunc Through the above implementation method, an equal number of partitions and the same file system type can be created in the boot drive as in the non-boot drive, turning the original boot drive into a data disk that can only be used for data storage.

[0061] In some embodiments, if the data stored in the non-boot drive has been backed up to the storage medium, see [reference]. Figure 2 The system restore method may also include step S250.

[0062] Step S250: Data stored in the storage medium is transferred to the boot drive.

[0063] After modifying the partition information of the boot drive to the second partition information, the important data files of the non-boot drive backed up in step S310 can be restored from the storage medium to the corresponding partition of the newly created boot drive to ensure the integrity of the data during the system restoration process.

[0064] In some embodiments, step S250 may also be performed after the partition information of the boot drive is modified to the second partition information and before the master boot record of the boot drive is cleared.

[0065] To switch the Linux operating system of an electronic device from the original boot drive to the current non-boot drive, and to prevent interference from the partition boot code and partition boot flags of the original boot drive during the boot process, the master boot record of the original boot drive can be cleared.

[0066] Step S150: Install the system boot manager on the non-boot drive and swap the identification information of the boot drive and the non-boot drive. The identification information includes a universally unique identifier and / or drive letter information.

[0067] For example, the `grub2-install` command-line tool can be used to reinstall a Linux boot manager onto a non-bootable drive. The Linux boot manager can be Grub2, Linux Loader, etc. Using Grub2 as an example, the pseudocode for installing a Linux boot manager is as follows: grub2-install --root-directory= / mnt / dev / sdb Afterwards, you can modify the information about the original boot drive's UUID / drive letter in the Linux operating system's boot configuration file grub2.cfg and partition mount point configuration file fstab to the universally unique identifier (UUID) and / or drive letter information of the non-boot drive. Check / boot / grub2 / grub.cfg.

[0068] The above implementation method can be applied to offline business scenarios. In some scenarios where the system is not offline, when installing a Linux boot manager, the bootloader can be installed and repaired by selecting "recommended repair" from the tools menu provided by boot-repair. The boot-repair tool can connect to an online network, add software installation sources, download and install the software, and then use it.

[0069] Afterwards, in the temporary operating system environment, you can unmount all mounted partitions to prevent data corruption or system boot failure. Then you can exit the temporary operating system environment and enter the BIOS to verify the system boot, attempting to boot the Linux operating system from the non-bootable drive (the new boot drive). An example of pseudocode for exiting the temporary operating system environment is as follows: sync&&reboot -f If the boot process fails, it means that the boot drive and non-boot drive could not be swapped successfully. Troubleshooting can be performed according to the prompts. For example, you can return to the Live environment to re-debug and check and repair the boot and partitions. This application embodiment does not impose any special restrictions on the troubleshooting methods.

[0070] Figure 3 This is a schematic diagram of the logic flow for system restoration provided in an embodiment of this application. (See also...) Figure 3During system restore, a Linux boot disk can be created. This boot disk can store an ISO image of a distribution similar to the operating system environment of the electronic device. The ISO image can be burned using refus or ventoy. The system can then boot from this disk into the Linux live environment.

[0071] In a Linux Live environment, if a non-bootable drive stores important data files, these files can be backed up to an intermediate storage medium (referred to as a storage medium). After the backup is complete, the non-bootable drive should be partitioned and formatted according to the original bootable drive. This allows for the subsequent migration or exchange of the system and important data from the original bootable drive to the non-bootable drive. Using ` / dev / sda` as the original bootable drive and ` / dev / sda` as the non-bootable drive in the Linux system as an example, the partition information and file system type of the original bootable drive can be viewed using `fdisk / dev / sda -1`. The non-bootable drive partition can be configured using the command `fdisk / dev / sdb`, and formatted using the command `mkfs.ext4 / dev / sdb1`. Afterward, the drive partition can be mounted, and the files from the original bootable drive partition can be synchronously transferred to the non-bootable drive using the command `rsync -avP / source / mnt&&sync`. Then, the command `dd if= / dev / sda of= / dev / sdb bs=447 count=1 conv=notrunc` can be used to copy the partition boot code and partition boot flag from the original boot drive's Master Boot Record (MBR) to the corresponding partition area of ​​the non-boot drive, achieving precise overwriting of the MBR data. Afterward, it can be checked whether bit 7 of the partition boot flag in the non-boot drive is 1. If it is, the command `e2fsck -f / dev / sdb1` is used to check and repair bad blocks in the non-boot drive. If not, the partition boot code and partition boot flag from the MBR are rewritten to the non-boot drive. After migrating the original boot drive's functionality and data, the `fdisk / dev / sda` command can be used to select the original boot drive, facilitating the subsequent deletion of partitions on the original boot drive and the re-creation of the primary partition relative to the non-boot drive. The `mkfs.ext4 / dev / sda1` command can then be used to format the file system type, allowing data stored on the storage medium to be migrated to the original boot drive. Afterwards, the `dd if= / dev / zero of= / dev / sda bs=447 count=1 conv=notrunc` command can be used to clear the MBR boot data from the original boot drive.

[0072] In a Linux Live environment, the command `grub2-install --root-directory= / mnt / dev / sdb` can be used to repair and install the Linux boot manager Grub2 on a non-bootable drive. This updates the UUID in ` / etc / ffstab` and checks ` / boot / grub2 / grub.cfg` to modify the system configuration file. Then, the mounted partition is unmounted, the Linux Live environment is exited, and a boot verification is performed. If the adaptation is successful, the Linux system can be rebooted. If the adaptation fails, troubleshooting is performed, which may include returning to the Linux Live environment for debugging, checking and repairing the bootloader and partitions, etc.

[0073] As described above, the above implementation method allows the system and important data in the original boot drive to be migrated or swapped to a non-boot drive within a Linux Live environment. This enables successful booting of the Linux system, system restoration, and the return of the electronic device to normal operation. Both the boot drive (original boot drive) and the non-boot drive are original components of the electronic device, not additional components added later.

[0074] This application provides a system restore method applied to an electronic device. The method includes: in a temporary operating system environment, modifying the partition information of a non-boot drive to first partition information, wherein the first partition information is consistent with the partition information of the boot drive, and the file system type of each partition corresponding to the first partition information is consistent with the file system type of each partition in the boot drive; transferring file data from each partition of the boot drive to the corresponding partition of the non-boot drive; copying the partition boot code and partition boot flag from the master boot record (MBR) of the boot drive to the corresponding partition area of ​​the non-boot drive; modifying the partition information of the boot drive to second partition information and clearing the master boot record of the boot drive; the second partition information is consistent with the partition information of the non-boot drive before modification, and the file system type of each partition corresponding to the second partition information is consistent with the file system type of each partition of the non-boot drive before modification; installing a system boot manager in the non-boot drive, and swapping the identification information of the boot drive and the non-boot drive, the identification information including a universally unique identifier and / or drive letter information. The technical solution provided by this application can realize the swapping of large-capacity boot drives and small-capacity non-boot drives in a Linux operating system, and will not affect any changes, damage, or loss of the source data attributes during system file data synchronization, thus exhibiting good reliability. Furthermore, since the procurement cost of large-capacity boot drives is high, this embodiment of the application uses an existing non-boot drive on the electronic device to replace the original boot drive for system recovery. The original boot drive is also reused as a data disk, which can fully release data storage capacity, thus eliminating the need for additional hardware procurement. For end users, such as those in the rail transit (metro, high-speed rail) industry, this can effectively solve the problem of sudden operational data transaction anomalies caused by drive problems during the operation of the gate system. The system and important data can be promptly migrated or swapped to existing non-boot drives and other new small-capacity drives on the machine, thereby avoiding further financial losses.

[0075] Those skilled in the art will understand that the above embodiments are exemplary and not intended to limit this application. Where possible, the execution order of one or more of the above steps can be adjusted, or they can be selectively combined to obtain one or more other embodiments. Those skilled in the art can arbitrarily select and combine the above steps as needed, and all those that do not depart from the essence of this application fall within the protection scope of this application.

[0076] Based on the same inventive concept, as an implementation of the above method, this application provides a system restoration device. This device embodiment corresponds to the aforementioned method embodiment. For ease of reading, this device embodiment will not repeat the details of the aforementioned method embodiment one by one, but it should be clear that the device in this embodiment can correspondingly implement all the contents of the aforementioned method embodiment.

[0077] Figure 4 This is a schematic diagram of the system restoration device provided in the embodiments of this application, as shown below. Figure 4 As shown, the apparatus provided in this embodiment includes: Modification module 110 is used to modify the partition information of the non-boot drive to the first partition information in a temporary operating system environment. The first partition information is consistent with the partition information of the boot drive, and the file system type of each partition corresponding to the first partition information is consistent with the file system type of each partition in the boot drive. The transmission module 120 is used to transfer file data from each partition of the boot drive to the corresponding partition of the non-boot drive; The copy module 130 is used to copy the partition boot code and partition boot flag from the master boot record of the boot drive to the partition area corresponding to the non-boot drive; The modification module 110 is also used to: modify the partition information of the boot drive to the second partition information and clear the master boot record of the boot drive; the second partition information is consistent with the partition information of the non-boot drive before modification, and the file system type of each partition corresponding to the second partition information is consistent with the file system type of each partition of the non-boot drive before modification; install the system boot manager in the non-boot drive, and swap the identification information of the boot drive and the non-boot drive, the identification information including a universally unique identifier and / or drive letter information.

[0078] In one possible implementation, the modification module 110 is further configured to: Before modifying the partition information of the non-boot drive to the first partition information, a temporary operating system environment is entered based on the system boot file pre-stored in the system boot disk. The system boot file is an image file of a distribution that is the same as or similar to the operating system environment of the electronic device.

[0079] In one possible implementation, the modification module 110 is further configured to: Before modifying the partition information of the non-boot drive to the first partition information, back up the data stored in the non-boot drive to the storage medium; After modifying the partition information of the boot drive to the second partition information, the data stored in the storage medium is stored in the boot drive.

[0080] In one possible implementation, the copy module 130 is further configured to: after copying the partition boot code and partition boot flag from the master boot record of the boot drive to the partition area corresponding to the non-boot drive, check the partition boot flag of the non-boot drive, and if the value of the partition boot flag is not 1, modify the value of the partition boot flag to 1.

[0081] In one possible implementation, the copy module 130 is further configured to: after copying the partition boot code and partition boot flag from the master boot record of the boot drive to the partition area corresponding to the non-boot drive, check whether there are bad blocks in the non-boot drive, and repair the bad blocks if there are bad blocks in the non-boot drive.

[0082] In one possible implementation, the transmission module 120 is specifically used to: use a file synchronization transmission tool to transfer file data from each partition of the boot drive to the corresponding partition of the non-boot drive.

[0083] The system restore device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0084] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0085] Based on the same inventive concept, embodiments of this application also provide an electronic device. Figure 5 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application, such as... Figure 5 As shown, the electronic device provided in this embodiment includes: a memory 210 and a processor 220. The memory 210 is used to store computer programs; the processor 220 is used to execute the method described in the above method embodiment when the computer program is invoked.

[0086] The electronic device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so they will not be described again here.

[0087] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the methods described in the above-described method embodiments.

[0088] This application also provides a computer program product that, when run on an electronic device, causes the electronic device to implement the method described in the above-described method embodiments.

[0089] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, or magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0090] Those skilled in the art will understand that implementing all or part of the processes in the above embodiments can be accomplished by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium can include various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0091] The naming or numbering of steps in this application does not mean that the steps in the method flow must be executed in the time / logical order indicated by the naming or numbering. The execution order of the named or numbered process steps can be changed according to the technical purpose to be achieved, as long as the same or similar technical effect can be achieved.

[0092] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0093] In the embodiments provided in this application, it should be understood that the disclosed apparatus / devices and methods can be implemented in other ways. For example, the apparatus / device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0094] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0095] In the description of this application, unless otherwise stated, " / " indicates that the objects before and after are in an "or" relationship. For example, A / B can mean A or B. "And / or" in this application is merely a description of the relationship between the related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. A and B can be singular or plural.

[0096] Furthermore, in the description of this application, unless otherwise stated, "multiple" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0097] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0098] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein.

[0099] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0100] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A system restoration method, characterized in that, Applied to electronic devices, the method includes: In a temporary operating system environment, the partition information of the non-boot drive is modified to the first partition information, wherein the first partition information is consistent with the partition information of the boot drive, and the file system type of each partition corresponding to the first partition information is consistent with the file system type of each partition in the boot drive. The file data of each partition of the boot drive is transferred to the partition corresponding to the non-boot drive; Copy the partition boot code and partition boot flag from the master boot record of the boot drive to the partition area corresponding to the non-boot drive; The partition information of the boot drive is modified to the second partition information, and the master boot record of the boot drive is cleared; the second partition information is consistent with the partition information of the non-boot drive before modification, and the file system type of each partition corresponding to the second partition information is consistent with the file system type of each partition of the non-boot drive before modification; Install a system boot manager on the non-boot drive, and swap the identification information of the boot drive and the non-boot drive. The identification information includes a universally unique identifier and / or drive letter information.

2. The method according to claim 1, characterized in that, Before modifying the partition information of the non-boot drive to the first partition information, the method further includes: The system boots into the temporary operating system environment based on the system boot file pre-stored in the system boot disk. The system boot file is an image file of a distribution that is the same as or similar to the operating system environment of the electronic device.

3. The method according to claim 1, characterized in that, Before modifying the partition information of the non-boot drive to the first partition information, the method further includes: Back up the data stored in the non-boot drive to the storage medium; After modifying the partition information of the boot drive to the second partition information, the method further includes: The data stored in the storage medium is stored in the boot drive.

4. The method according to claim 1, characterized in that, After copying the partition boot code and partition boot flag from the master boot record of the boot drive to the partition area corresponding to the non-boot drive, the method further includes: Check the partition boot flag of the non-boot drive. If the value of the partition boot flag is not 1, change the value of the partition boot flag to 1.

5. The method according to claim 1, characterized in that, After copying the partition boot code and partition boot flag from the master boot record of the boot drive to the partition area corresponding to the non-boot drive, the method further includes: Check if the non-boot drive has bad blocks, and if so, repair the bad blocks.

6. The method according to any one of claims 1-5, characterized in that, Using a file synchronization transfer tool, file data from each partition of the boot drive is transferred to the corresponding partition of the non-boot drive.

7. A system restoration device, characterized in that, include: The modification module is used to modify the partition information of a non-boot drive to the first partition information in a temporary operating system environment, wherein the first partition information is consistent with the partition information of the boot drive, and the file system type of each partition corresponding to the first partition information is consistent with the file system type of each partition in the boot drive. A transmission module is used to transfer file data from each partition of the boot drive to the partition corresponding to the non-boot drive; The copy module is used to copy the partition boot code and partition boot flag from the master boot record of the boot drive to the partition area corresponding to the non-boot drive; The modification module is further configured to: modify the partition information of the boot drive to the second partition information, and clear the master boot record of the boot drive; the second partition information is consistent with the partition information of the non-boot drive before modification, and the file system type of each partition corresponding to the second partition information is consistent with the file system type of each partition of the non-boot drive before modification; install a system boot manager in the non-boot drive, and exchange the identification information of the boot drive and the non-boot drive, wherein the identification information includes a universally unique identifier and / or drive letter information.

8. An electronic device, characterized in that, include: A memory and a processor, the memory being used to store a computer program; the processor being used to execute the method as described in any one of claims 1-6 when the computer program is invoked.

9. A computer program product, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1-6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-6.

Images