Linux system starting method and device, electronic equipment and storage medium

Abstract

The invention provides a starting method and device of a linux system, electronic equipment and a storage medium. The starting method comprises the following steps: acquiring metadata of a slot partition; the metadata comprises a slot identifier of a successfully started partition, the number of times of retry after starting failure and a slot identifier of a recently successfully upgraded partition; determining a to-be-started partition according to the metadata; the linux system in the partition to be started is started; updating the metadata according to a starting result of the linux system in the partition to be started; the updated metadata is used for starting the linux system. According to the method, the metadata of the slot partition is designed for the linux system, starting of the linux system under the multi-system architecture is achieved according to the designed metadata, the implementation mode is simple, the method can be well matched with the Linux system, and effectiveness and stability of starting of the Linux system are ensured.

Description

Technical Field

[0001] The present disclosure relates to the technical field of system startup, and in particular to a startup method, device, electronic device, and storage medium for a Linux system. Background Art

[0002] Devices running Linux (an operating system) typically use a single system, employing a two-stage boot process. After powering on the device chip, the romcode (a type of firmware) is first launched, followed by the first-level loader, which then loads the second-level loader (boot code). The second-level loader then verifies security-related content before loading the kernel. After the kernel boots, the rootfs (root file system) is mounted, completing the system boot. To improve device system robustness, some adopt AB systems, but these simply apply Android solutions, resulting in complex implementations that don't mesh well with Linux. Summary of the Invention

[0003] The technical problem to be solved by the present disclosure is to overcome the above-mentioned defects in the prior art and to provide a method, device, electronic device and storage medium for starting a Linux system.

[0004] The present disclosure solves the above technical problems through the following technical solutions:

[0005] In a first aspect, a method for booting a Linux system is provided, which is applied to an electronic device, wherein the electronic device includes at least two slot partitions, each of which stores a Linux system; the booting method comprises:

[0006] In response to a system startup request, metadata of the slot partition is obtained; the metadata includes the following parameters: the slot identifier of the successfully started partition, the number of startup failure retries, and the slot identifier of the most recently successfully upgraded partition; the slot identifier of the successfully started partition represents the slot partition identifier of the last successfully started Linux system; the number of startup failure retries represents the number of consecutive startups of the slot partition to which the Linux system to which the startup failed has belonged; the slot identifier of the most recently successfully upgraded partition represents the slot partition identifier of the most recently successfully upgraded Linux system;

[0007] Determine the partition to be started according to the slot identifier of the successfully started partition, the slot identifier of the most recently successfully upgraded partition, and the number of startup failure retries;

[0008] Start the Linux system in the partition to be started;

[0009] The metadata is updated according to the startup result of the Linux system in the partition to be started; the updated metadata is used for starting the Linux system next time.

[0010] Optionally, determining the partition to be started according to the slot identifier of the successfully started partition, the slot identifier of the most recently successfully upgraded partition, and the number of startup failure retries includes:

[0011] In response to the slot identifier of the successfully started partition being different from the slot identifier of the most recently successfully upgraded partition and the number of startup failure retries corresponding to the slot identifier of the most recently successfully upgraded partition being less than or equal to a number threshold, determining the most recently successfully upgraded partition as the partition to be started;

[0012] In response to the slot identifier of the successfully started partition being different from the slot identifier of the most recently successfully upgraded partition and the number of startup failure retries corresponding to the slot identifier of the most recently successfully upgraded partition being greater than the number threshold, determining the slot identifier of the successfully started partition as the partition to be started;

[0013] In response to the slot identifier of the successfully started partition being the same as the slot identifier of the most recently successfully upgraded partition and the number of failed startup retries of the successfully started partition being greater than the number threshold, the other slot partition is determined as the partition to be started; the other slot partition is a slot partition other than the successfully started partition among the at least two slot partitions.

[0014] Optionally, updating the metadata according to the startup result of the Linux system in the partition to be started includes at least one of the following:

[0015] In response to the startup result being a startup failure, increasing the startup failure retry count of the partition to be started by 1;

[0016] In response to the startup result being a successful startup and the slot identifier of the partition to be started being different from the slot identifier of the successfully started partition, changing the slot identifier of the successfully started partition to the slot identifier of the partition to be started;

[0017] In response to the startup result being a successful startup, the number of startup failure retries is reset to 0.

[0018] Optionally, the metadata further includes: an enable flag of a multi-system startup scheme; in response to the enable flag being enabled, executing a step of acquiring metadata of the slot partition;

[0019] And / or, the updating of the metadata further comprises: after a Linux system of a slot partition is successfully upgraded, updating the slot identifier of the partition that has been most recently successfully upgraded;

[0020] And / or, the Linux system includes: a boot loader and a kernel; in response to at least one of the boot loader and the kernel failing to load, determining the startup result as a startup failure.

[0021] In a second aspect, a boot device for a Linux system is provided, which is applied to an electronic device, wherein the electronic device includes at least two slot partitions, each of which stores a Linux system; the boot device includes:

[0022] An acquisition module is configured to obtain metadata of the slot partition in response to a system startup request; the metadata includes the following parameters: a slot identifier of a successfully started partition, a number of startup failure retries, and a slot identifier of a recently successfully upgraded partition; the slot identifier of the successfully started partition represents the identifier of the slot partition to which the last successfully started Linux system belongs; the number of startup failure retries represents the number of consecutive startups of the slot partition to which the failed startup Linux system belongs; the slot identifier of the recently successfully upgraded partition represents the identifier of the slot partition to which the last successfully upgraded Linux system belongs;

[0023] A determination module, configured to determine a partition to be started based on the slot identifier of the successfully started partition, the slot identifier of the most recently successfully upgraded partition, and the number of startup failure retries;

[0024] A startup module, used to start the Linux system in the partition to be started;

[0025] The updating module is used to update the metadata according to the startup result of the Linux system in the partition to be started; the updated metadata is used for starting the Linux system next time.

[0026] Optionally, the determining module is specifically configured to:

[0027] In response to the slot identifier of the successfully started partition being different from the slot identifier of the most recently successfully upgraded partition and the number of startup failure retries corresponding to the slot identifier of the most recently successfully upgraded partition being less than or equal to a number threshold, determining the most recently successfully upgraded partition as the partition to be started;

[0028] In response to the slot identifier of the successfully started partition being different from the slot identifier of the most recently successfully upgraded partition and the number of startup failure retries corresponding to the slot identifier of the most recently successfully upgraded partition being greater than the number threshold, determining the slot identifier of the successfully started partition as the partition to be started;

[0029] In response to the slot identifier of the successfully started partition being the same as the slot identifier of the most recently successfully upgraded partition and the number of failed startup retries of the successfully started partition being greater than the number threshold, the other slot partition is determined as the partition to be started; the other slot partition is a slot partition other than the successfully started partition among the at least two slot partitions.

[0030] Optionally, the update module is specifically configured to:

[0031] In response to the startup result being a startup failure, increasing the startup failure retry count of the partition to be started by 1;

[0032] and / or, in response to the startup result being a successful startup and the slot identifier of the partition to be started being different from the slot identifier of the successfully started partition, changing the slot identifier of the successfully started partition to the slot identifier of the partition to be started;

[0033] And / or, in response to the startup result being a successful startup, the number of startup failure retries is reset to 0.

[0034] Optionally, the metadata further includes: an enable flag of a multi-system startup scheme; in response to the enable flag being enabled, executing a step of acquiring metadata of the slot partition;

[0035] And / or, the updating of the metadata further comprises: after a Linux system of a slot partition is successfully upgraded, updating the slot identifier of the partition that has been most recently successfully upgraded;

[0036] And / or, the Linux system includes: a boot loader and a kernel; in response to at least one of the boot loader and the kernel failing to load, determining the startup result as a startup failure.

[0037] In a third aspect, an electronic device is provided, comprising a memory, a processor, and a computer program stored in the memory and used to run on the processor, wherein when the processor executes the computer program, the method for starting the Linux system described in any one of the first aspects is implemented.

[0038] In a fourth aspect, a computer-readable storage medium is provided, on which a computer program is stored, wherein when the computer program is executed by a processor, the method for starting a Linux system according to any one of the first aspects is implemented.

[0039] On the basis of conforming to the common sense in this field, the above-mentioned preferred conditions can be arbitrarily combined to obtain the preferred embodiments of the present disclosure.

[0040] The positive progress of the present disclosure is that: the present disclosure designs metadata of slot partitions for the Linux system, and mainly realizes the startup of the Linux system under a multi-system architecture based on three parameters: the slot identifier of the successfully started partition, the number of startup failure retries, and the slot identifier of the most recently successfully upgraded partition. The implementation method is simple and can fit well with the Linux system, ensuring the effectiveness and stability of the Linux system startup. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] Figure 1 A flowchart of a method for starting a Linux system provided by an exemplary embodiment of the present disclosure;

[0042] Figure 2 A schematic diagram of a module of a boot device for a Linux system provided by an exemplary embodiment of the present disclosure;

[0043] Figure 3 The present invention provides a structural diagram of an electronic device according to an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0044] The present disclosure is further illustrated below by way of examples, but the present disclosure is not limited to the scope of the examples.

[0045] In the embodiments of the present disclosure, prefixes such as "first" and "second" are used only to distinguish different description objects, and have no limiting effect on the position, order, priority, quantity or content of the described objects. In the embodiments of the present disclosure, the use of prefixes such as ordinal numbers to distinguish description objects does not constitute a limitation on the described objects. For the statement of the described objects, please refer to the description in the context of the claims or embodiments, and no unnecessary limitations should be constituted due to the use of such prefixes. In addition, in the description of this embodiment, unless otherwise specified, the meaning of "plurality" is two or more.

[0046] In the embodiments of the present disclosure, the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0047] Figure 1This is a flowchart of a method for booting a Linux system provided by an exemplary embodiment of the present disclosure. The booting method is applied to an electronic device. The electronic device includes at least two slot partitions. Each slot partition stores a Linux system. The versions of the Linux systems stored in each slot partition can be the same or different. The number of slot partitions can be set according to actual conditions and can be 2, 3, or even more. This embodiment of the present disclosure does not specifically limit this. Figure 1 , the startup method includes the following steps:

[0048] Step 101: In response to a system startup request, obtain metadata of a slot partition.

[0049] The system startup request may be generated based on a power-on instruction of the electronic device.

[0050] The metadata includes the following parameters: the slot identifier (current_mode) for the successfully booted partition, the number of retries (retry_count) for failed boots, and the slot identifier (retry_mode) for the most recently successfully upgraded partition. Additionally, the metadata may include the multi-system boot flag (double_copy) and the system upgrade status (startota).

[0051] The slot ID of the successfully booted partition indicates the slot ID of the last successfully booted Linux system. For example, if an electronic device contains slot partitions A and B, current_mode = A indicates that the last successful boot of the Linux system in slot partition A; current_mode = B indicates that the last successful boot of the Linux system in slot partition B.

[0052] The multi-boot flag indicates whether the multi-boot scheme is enabled. For example, double_copy = y indicates the multi-boot scheme is enabled, while double_copy = n indicates the multi-boot scheme is disabled. A multi-boot scheme means that an electronic device has multiple Linux systems, each deployed in a single slot partition.

[0053] The number of boot failure retries indicates the number of consecutive boot attempts for the slot partition to which the Linux system that failed to boot has been assigned. If a slot partition fails to boot and the number of boot failure retries is less than or equal to the threshold, the Linux system in that slot partition will continue to boot. If a slot partition fails to boot and the number of boot failure retries exceeds the threshold, the Linux system in another slot partition will be booted. The threshold can be set based on actual conditions. For example, setting it to 5 means that the maximum number of boot failure retries allowed is 5.

[0054] The slot identifier of the most recently successfully upgraded partition represents the slot identifier of the Linux system that most recently successfully upgraded. For example, on an electronic device containing slot partitions A and B, retry_mode = 0 indicates that the Linux systems in slot partitions A and B have never been upgraded; retry_mode = A indicates that the most recently successfully upgraded Linux system in slot partition A; and retry_mode = B indicates that the most recently successfully upgraded Linux system in slot partition B. It should be noted that a Linux system upgrade can refer to a successful upgrade from a lower-version Linux system to a higher-version Linux system, or a successful upgrade from a higher-version Linux system to a lower-version Linux system.

[0055] If startota=0 is the system upgrade status, the Linux system in the target slot partition will not be upgraded. If startota=1 is the system upgrade status for another slot partition. If startota=2 is the system upgrade status for the target slot partition, the Linux system upgrade is successful, and current_mode needs to be modified. If startota=3 is the system upgrade status for the target slot partition, the Linux system upgrade fails. The target slot partition can be specified based on actual needs. For example, if an electronic device contains slot partitions A and B, if slot partition A is specified as the target partition, upgrading the Linux system in the other slot partition also upgrades the Linux system in slot partition B. If slot partition B is specified as the target partition, upgrading the Linux system in the other slot partition also upgrades the Linux system in slot partition A.

[0056] In one embodiment, the metadata is stored in a misc partition of the electronic device.

[0057] Step 102: Determine the partition to be started based on the slot identifier of the successfully started partition, the slot identifier of the partition that was recently successfully upgraded, and the number of startup failure retries.

[0058] In one embodiment, in response to the slot identifier of the successfully booted partition being the same as the slot identifier of the most recently successfully upgraded partition, the successfully booted partition or the most recently successfully upgraded partition is used as the initial partition to be booted; a determination is made as to whether the number of failed boot retries of the initial partition to be booted is less than or equal to a threshold number; in response to the number of failed boot retries being less than or equal to the threshold number, the successfully booted partition or the most recently successfully upgraded partition is determined as the final partition to be booted; in response to the number of failed boot retries being greater than the threshold number, a rollback mechanism is executed, i.e., another slot partition is determined as the final partition to be booted. The other slot partition is a slot partition other than the successfully booted partition or the most recently successfully upgraded partition among the at least two slot partitions.

[0059] In this embodiment, the effectiveness and stability of Linux system startup can be improved through the above startup logic verification.

[0060] In one embodiment, in response to the slot identifier of the successfully started partition being different from the slot identifier of the most recently successfully upgraded partition being different, the most recently successfully upgraded partition is used as the initial partition to be started; it is determined whether the number of startup failure retries of the initial partition to be started is less than or equal to a number threshold; in response to the number of startup failure retries being less than or equal to the number threshold, the most recently successfully upgraded partition is determined as the partition to be started; in response to the number of startup failure retries being greater than the number threshold, the successfully started partition is determined as the partition to be started.

[0061] The slot identifier of the successfully booted partition is different from the slot identifier of the most recently successfully upgraded partition. This indicates that the Linux system was upgraded between the last system startup and this system startup, and the slot partition that was successfully upgraded is different from the last successfully booted Linux system.

[0062] In this embodiment, the priority of the partition that has been successfully upgraded recently is higher than the partition that has been successfully started, that is, the Linux system that has been recently upgraded is tried to be started first. If the Linux system that has been recently upgraded fails to start and the number of failed startup retries is less than or equal to the number threshold, then the Linux system that has been recently upgraded will continue to be tried to start, that is, the partition that has been successfully upgraded will be determined as the partition to be started; if the Linux system that has been recently upgraded fails to start and the number of failed startup retries is greater than the number threshold, then the rollback mechanism will be executed, that is, the partition that has been successfully started will be determined as the partition to be started, and the Linux system of the partition that has been successfully started will be started. The Linux system in the partition that has been successfully started is most likely a normal Linux system. After the partition that has been successfully upgraded fails to start, the partition that has been successfully started will be used as the partition to be started, which can improve the success rate of system startup.

[0063] In this embodiment, the effectiveness and stability of Linux system startup can be improved through the above startup logic verification.

[0064] Step 103: Start the Linux system in the partition to be started.

[0065] The Linux system includes a boot loader and a kernel. Booting a Linux system involves first running the boot loader to initialize the electronic device's hardware, set up the startup environment, and then loading the kernel into memory. The detailed implementation process is described in the relevant technical description and will not be repeated here.

[0066] In one embodiment, as long as at least one of the boot loader and the kernel fails to load, the startup result of the Linux system is determined to be a startup failure; if both the boot loader and the kernel are loaded successfully, the startup result of the Linux system is determined to be a startup success.

[0067] Step 104: Update metadata according to the startup result of the Linux system in the partition to be started; the updated metadata is used for starting the Linux system next time.

[0068] In this embodiment, the metadata is updated every time the Linux system in the partition to be started is started, so that the system can be started according to the latest metadata next time, thereby improving the effectiveness and stability of system startup.

[0069] In this embodiment, the metadata of the slot partition is designed for the Linux system, and the startup of the Linux system under the multi-system architecture is mainly realized based on three parameters: the slot identifier of the successfully started partition, the number of startup failure retries, and the slot identifier of the most recently successfully upgraded partition. The implementation method is simple and can fit well with the Linux system, ensuring the effectiveness and stability of the Linux system startup.

[0070] In one embodiment, the step of updating metadata includes at least one of the following:

[0071] In response to a startup result of startup failure and the number of startup failure retries being less than or equal to a threshold, the number of startup failure retries of the partition to be started is increased by 1;

[0072] In response to the boot result being a successful boot and the slot identifier of the partition to be booted being different from the slot identifier of the successfully booted partition, changing the slot identifier of the successfully booted partition to the slot identifier of the partition to be booted;

[0073] In response to the startup result being a successful startup, the number of startup failure retries is reset to 0.

[0074] For example: assuming that the partition to be started is slot partition A, if the boot result of the Linux system in the partition to be started is a boot failure and the number of boot failure retries is less than or equal to the number threshold, then the number of boot failure retries of slot partition A is increased by 1; if the boot result of the Linux system in the partition to be started is a boot failure and the number of boot failure retries is greater than the number threshold, then current_mode=A is updated to current_mode=B, and the number of boot failure retries is reset to 0; if the boot result of the Linux system in the partition to be started is a boot success, then current_mode=A is set and the number of boot failure retries is reset to 0.

[0075] In one embodiment, when the metadata includes a flag indicating that a multi-system boot scheme is enabled, the step of obtaining metadata for the slot partition in step 101 is performed in response to the flag being enabled. In response to the flag being disabled, the Linux system of the designated slot partition is booted. The designated slot partition can be selected by the user.

[0076] In this embodiment, the user can choose whether to start the Linux system using the multi-system startup solution.

[0077] In one embodiment, in addition to updating metadata based on the boot result of the Linux system in the partition to be booted, the boot method further includes: after a Linux system upgrade is successfully completed in a slot partition, updating the slot identifier of the partition that was most recently successfully upgraded. Specifically, after each successful Linux system upgrade, retry_mode can be set to 0, which is equivalent to initializing the upgrade. The next upgrade can determine the partition to be booted by logically verifying the current-mode.

[0078] In this embodiment, as long as the Linux system is successfully upgraded, the slot identifier of the partition that has been recently successfully upgraded is updated, so that the user can use the recently upgraded Linux system in a timely manner, thereby improving the user experience.

[0079] The following example further illustrates the Linux system boot logic, using an electronic device with slot partitions A and B, using Uboot as the boot loader, and using SPLloader (a small program) as the boot loader. The following table shows the Linux system boot logic under different metadata conditions.

[0080]

[0081]

[0082]

[0083]

[0084]

[0085] The metadata for the scenario in the first row of the table above includes: current_mode = A, retry_mode = 0, double_copy = y. This indicates that the slot identifier for the successfully booted partition is slot partition A. The Linux systems in slot partition A and slot partition B have never been upgraded. If the A / B solution is enabled, slot partition A is booted by default. This means that the partition to be booted is determined to be slot partition A. Uboot and the kernel in slot partition A are booted sequentially. If both Uboot and kernel boot successfully (Uboot boot = Y, kernel boot = Y), no rollback mechanism is required (rollback partition = N). The metadata is updated, specifically: Uboot writes the corresponding metadata to the misc partition; the kernel writes the corresponding metadata to the misc partition. The metadata written by Uboot includes: retry_mode = 0, retry_count = 0->1, double_copy = y, current_mode = A, and starttota = 0. When the kernel detects that the conditions retry_mode = 0 & retry_count > 0 & retry_count < 5 (number thresholds) are met, the kernel writes metadata including: retry_mode = 0, retry_count = 1->0, double_copy = y, current_mode = A, and starttota = 0. The next system boot is performed based on the new metadata.

[0086] The metadata for the second row of the table above includes: current_mode = A, retry_mode = 0, double_copy = y. This indicates that the slot identifier for the successfully booted partition is slot partition A. The Linux systems in slot partition A and slot partition B have never been upgraded. If the A / B scheme is enabled, slot partition A is booted by default. This means that the partition to be booted is determined to be slot partition A. The Uboot and kernel in slot partition A are booted sequentially. If Uboot boot succeeds (Uboot boot = Y), kernel boot fails (Kernel boot = N), and retry_count > 5, the rollback mechanism is executed and the metadata is updated. Specifically, the Uboot rollback mechanism writes the corresponding metadata to the misc partition. The kernel does not need to perform metadata writes (N / A). The metadata written by the Uboot rollback mechanism includes: retry_mode = 0, retry_count = 6->0, double_copy = y, current_mode = A->B, and starttota = 0. The next system boot is based on the updated metadata.

[0087] The metadata for the scenario in the third row of the table above includes: current_mode = B, retry_mode = 0, double_copy = y. This indicates that the slot identifier for the successfully booted partition is slot partition B. The Linux systems in slot partitions A and B have never been upgraded. If the A / B solution is enabled, slot partition B is booted by default. This means that the partition to be booted is slot partition B. Uboot and the kernel in slot partition B are booted sequentially. If both Uboot and kernel boot successfully (Uboot boot = Y, kernel boot = Y), no rollback mechanism is required (rollback partition = N). The metadata is updated, specifically: Uboot writes the corresponding metadata to the misc partition; the kernel writes the corresponding metadata to the misc partition. The metadata written by Uboot includes: retry_mode = 0, retry_count = 0->1, double_copy = y, current_mode = B, and starttota = 0. The kernel detects that the condition retry_mode = 0 & retry_count > is met. 0&retry_count<=5(times When the number threshold is reached, the metadata written by the kernel includes: retry_mode = 0, retry_count = 1->0, double_copy = y, current_mode = B, starttota = 0. The next system startup is performed based on the new metadata.

[0088] The metadata for the fourth row of the table above includes: current_mode = B, retry_mode = 0, double_copy = y. This indicates that the slot identifier for the successfully booted partition is slot partition B. The Linux systems in slot partitions A and B have never been upgraded. If the A / B solution is enabled, slot partition B is booted by default. This means that the partition to be booted is determined to be slot partition B. The Uboot and kernel in slot partition B are booted sequentially. If Uboot boot succeeds (Uboot boot = Y), kernel boot fails (Kernel boot = N), and retry_count > 5, the rollback mechanism is executed and the metadata is updated. Specifically, the Uboot rollback mechanism writes the corresponding metadata to the misc partition. The kernel does not need to perform metadata writes (N / A). The metadata written by the Uboot rollback mechanism includes: retry_mode = 0, retry_count = 6->0, double_copy = y, current_mode = B->A, and starttota = 0. The next system boot is based on the updated metadata.

[0089] The metadata for the scenario in the fifth row of the table above includes: current_mode = A, double_copy = y, retry_mode = B. This indicates that the partition successfully booted is slot partition A. The Linux system in slot partition B was recently successfully upgraded, and the A / B solution is enabled. Therefore, the partition to be booted is determined to be slot partition B. Uboot and the kernel in slot partition B are started sequentially. If both Uboot and kernel boot successfully (Uboot startup = Y, kernel startup = Y), no rollback is required. Instead, the metadata is updated. Specifically, Uboot writes the corresponding metadata to the misc partition, and the kernel writes the corresponding metadata to the misc partition. When Uboot detects that the conditions for retry_mode! = 0 & starttota == 2 are met, the metadata written by Uboot includes: retry_mode = B, retry_count = 0->1, double_copy = y, current_mode = A, and starttota = 2. The kernel detects that the conditions for retry_mode! = 0 & starttota == 2 are met. = 0 & retry_count > 0 & retry_count < 5 & startota == 2, the kernel writes metadata including: retry_mode = B->0, retry_count = 1->0, double_copy = y, current_mode = A->B, startota = 2->0. The next system boot is based on the new metadata. retry_mode = B->0 sets retry_mode to 0. This eliminates the need to check this field. Retry_mode is set to 0 for each system upgrade, simplifying the logic and reducing computational complexity.

[0090] The scenario in the sixth row of the table above is: current_mode = A, double_copy = y,retry_mode = B; this indicates that the partition successfully booted is slot A. The Linux system in slot B was recently successfully upgraded, and the A / B scheme is enabled. Therefore, the partition to be booted is determined to be slot B. Uboot and the kernel in slot B are started sequentially. If Uboot boot succeeds (Uboot boot = Y), kernel boot fails (kernel boot = N), and retry_count > 5, the rollback mechanism is executed and metadata is updated. When the Uboot detection conditions meet: retry_mode! = 0 & startota == 2, the metadata written by Uboot includes: retry_mode = B->0, retry_count = 0->6, double_copy = y, current_mode = A, startota = 2->3. When the kernel detection conditions meet: retry_mode! = 0 & retry_count > 5 & startota == 3, the metadata written by the kernel includes: retry_mode = 0, retry_count = 6->0, double_copy = y, current_mode = A, startota = 3->0. The next system startup is performed based on the new metadata.

[0091] The metadata for the scenario in row 7 of the table above includes: current_mode = B, double_copy = y, and retry_mode = A. This indicates that the partition successfully booted is slot partition B. The Linux system in slot partition A was recently successfully upgraded, and the A / B solution is enabled. Therefore, the partition to be booted is determined to be slot partition A. Uboot and the kernel in slot partition B are booted sequentially. If both Uboot and kernel boot successfully (Uboot boot = Y, kernel boot = Y), no rollback is required and the metadata is updated. When Uboot detects that the conditions for retry_mode! = 0 & starttota == 2 are met, the metadata written by Uboot includes: retry_mode = A, retry_count = 0->1, double_copy = y, current_mode = B, and starttota = 2. The kernel detects that the conditions for retry_mode! = 0 & starttota == 2 are met. = 0 & retry_count > 0 & retry_count < = 5 & startota == 2, the kernel writes metadata including: retry_mode = A->0, retry_count = 1->0, double_copy = y, current_mode = B->A, startota = 2->0. The next system boot is based on the new metadata.

[0092] The scenario in the eighth row of the table above is: current_mode = B, double_copy = y, retry_mode = A; this indicates that the slot identifier of the successfully booted partition is slot partition B. Recently, the Linux system in slot partition A was successfully upgraded, and the A / B scheme was enabled. The partition to be booted is determined to be slot partition A. Uboot and Kernel in slot partition A are started in sequence. If Uboot boot succeeds (Uboot boot = Y), Kernel boot fails (Kernel boot = N), and retry_count > 5, Execute the rollback mechanism and update the metadata. Uboot detection conditions meet retry_mode! = 0&startotWhen a == 2, the metadata written by Uboot includes: retry_mode = A->0, retry_count = 0->6, double_copy = y, current_mode = B, and startota = 2->3. When the kernel detects that the conditions retry_mode = 0 & retry_count > 5 & startota == 3 are met, the metadata written by the kernel includes: retry_mode = 0, retry_count = 6->0, double_copy = y, current_mode = B, and startota = 3->0. The next system boot is based on the new metadata.

[0093] Corresponding to the aforementioned embodiment of the booting method of the Linux system, the present disclosure also provides an embodiment of a booting device of the Linux system.

[0094] Figure 2 This is a module diagram of a boot device for a Linux system provided by an exemplary embodiment of the present disclosure. The boot device is applied to an electronic device, wherein the electronic device includes at least two slot partitions, each of which stores a Linux system; the boot device includes:

[0095] The acquisition module 21 is configured to acquire metadata of the slot partition in response to a system startup request; the metadata includes the following parameters: the slot identifier of the successfully started partition, the number of startup failure retries, and the slot identifier of the most recently successfully upgraded partition; the slot identifier of the successfully started partition represents the slot partition identifier of the last successfully started Linux system; the number of startup failure retries represents the number of consecutive startups of the slot partition to which the failed-to-start Linux system belongs; the slot identifier of the most recently successfully upgraded partition represents the slot partition identifier of the most recently successfully upgraded Linux system;

[0096] A determination module 22 is configured to determine a partition to be started based on the slot identifier of the successfully started partition, the slot identifier of the most recently successfully upgraded partition, and the number of startup failure retries;

[0097] A startup module 23 is used to start the Linux system in the partition to be started;

[0098] The updating module 24 is configured to update the metadata according to the startup result of the Linux system in the partition to be started; the updated metadata is used for starting the Linux system next time.

[0099] Optionally, the determining module is specifically configured to:

[0100] In response to the slot identifier of the successfully started partition being different from the slot identifier of the most recently successfully upgraded partition and the number of startup failure retries corresponding to the slot identifier of the most recently successfully upgraded partition being less than or equal to a number threshold, determining the most recently successfully upgraded partition as the partition to be started;

[0101] In response to the slot identifier of the successfully started partition being different from the slot identifier of the most recently successfully upgraded partition and the number of startup failure retries corresponding to the slot identifier of the most recently successfully upgraded partition being greater than the number threshold, determining the slot identifier of the successfully started partition as the partition to be started;

[0102] In response to the slot identifier of the successfully started partition being the same as the slot identifier of the most recently successfully upgraded partition and the number of failed startup retries of the successfully started partition being greater than the number threshold, the other slot partition is determined as the partition to be started; the other slot partition is a slot partition other than the successfully started partition among the at least two slot partitions.

[0103] Optionally, the update module is specifically configured to:

[0104] In response to the startup result being a startup failure, increasing the startup failure retry count of the partition to be started by 1;

[0105] and / or, in response to the startup result being a successful startup and the slot identifier of the partition to be started being different from the slot identifier of the successfully started partition, changing the slot identifier of the successfully started partition to the slot identifier of the partition to be started;

[0106] And / or, in response to the startup result being a successful startup, the number of startup failure retries is reset to 0.

[0107] Optionally, the metadata further includes: an enable flag of a multi-system startup scheme; in response to the enable flag being enabled, executing a step of acquiring metadata of the slot partition;

[0108] And / or, the updating of the metadata further comprises: after a Linux system of a slot partition is successfully upgraded, updating the slot identifier of the partition that has been most recently successfully upgraded;

[0109] And / or, the Linux system includes: a boot loader and a kernel; in response to at least one of the boot loader and the kernel failing to load, determining the startup result as a startup failure.

[0110] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to the partial description of the method embodiments. The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, and the components of the units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the disclosed solution.

[0111] Figure 3 This is a structural diagram of an electronic device showing an example embodiment of the present disclosure. The electronic device includes a memory, a processor, and a computer program stored in the memory and configured to run on the processor. When the processor executes the computer program, the Linux system startup method described in any of the above embodiments is implemented. Figure 3 The electronic device 30 shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0112] like Figure 3 As shown, the electronic device 30 may be a general-purpose computing device, such as a server device. Components of the electronic device 30 may include, but are not limited to, the at least one processor 31, the at least one memory 32, and a bus 33 connecting different system components (including the memory 32 and the processor 31).

[0113] The bus 33 includes a data bus, an address bus, and a control bus.

[0114] The memory 32 may include a volatile memory, such as a random access memory (RAM) 321 and / or a cache memory 322 , and may further include a read-only memory (ROM) 323 .

[0115] The memory 32 may also include a program tool 325 (or utility) having a set (at least one) of program modules 324, such program modules 324 including but not limited to: an operating system, one or more application programs, other program modules and program data, each of which or some combination may include an implementation of a network environment.

[0116] The processor 31 executes various functional applications and data processing by running the computer program stored in the memory 32, such as the booting method of the Linux system provided in any of the above embodiments.

[0117] The electronic device 30 can also communicate with one or more external devices 34 (e.g., a keyboard, pointing device, etc.). Such communication can occur via an input / output (I / O) interface 35. Furthermore, the electronic device 30 can communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 36. As shown, the network adapter 36 communicates with other modules of the electronic device 30 via a bus 33. It should be understood that, although not shown, other hardware and / or software modules can be used in conjunction with the electronic device 30, including but not limited to microcode, device drivers, redundant processors, external disk drive arrays, RAID (RAID) systems, tape drives, and data backup storage systems.

[0118] It should be noted that although several units / modules or sub-units / modules of the electronic device are mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.

[0119] The embodiments of the present disclosure further provide a computer-readable storage medium having a computer program stored thereon, wherein when the program is executed by a processor, the method for starting a Linux system provided in any of the above embodiments is implemented.

[0120] The readable storage medium may include, but is not limited to, a portable disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0121] An embodiment of the present disclosure further provides a computer program product, including a computer program, which implements any of the above-mentioned Linux system startup methods when executed by a processor.

[0122] The program code for executing the computer program product of the present disclosure may be written in any combination of one or more programming languages, and the program code may be executed entirely on the user device, partially on the user device, as a standalone software package, partially on the user device and partially on a remote device, or entirely on the remote device.

[0123] While specific embodiments of the present disclosure have been described above, those skilled in the art will appreciate that these are merely illustrative and that the scope of protection of the present disclosure is defined by the appended claims. Those skilled in the art may make various changes or modifications to these embodiments without departing from the principles and essence of the present disclosure, and such changes and modifications are intended to fall within the scope of protection of the present disclosure.

Claims

1. A method for starting a Linux system, characterized in that: Applied to electronic devices, the electronic devices include at least two slot partitions, each slot partition stores a Linux system; The startup method includes: In response to a system startup request, metadata of the slot partition is obtained; the metadata includes the following parameters: the slot identifier of the successfully started partition, the number of startup failure retries, and the slot identifier of the most recently successfully upgraded partition; the slot identifier of the successfully started partition represents the slot partition identifier of the last successfully started Linux system; the number of startup failure retries represents the number of consecutive startups of the slot partition to which the Linux system to which the startup failed has belonged; the slot identifier of the most recently successfully upgraded partition represents the slot partition identifier of the most recently successfully upgraded Linux system; Determine the partition to be started according to the slot identifier of the successfully started partition, the slot identifier of the most recently successfully upgraded partition, and the number of startup failure retries; Start the Linux system in the partition to be started; The metadata is updated according to the startup result of the Linux system in the partition to be started; the updated metadata is used for starting the Linux system next time.

2. The method for starting a Linux system according to claim 1, wherein: Determining the partition to be started according to the slot identifier of the successfully started partition, the slot identifier of the most recently successfully upgraded partition, and the number of startup failure retries, including: In response to the slot identifier of the successfully started partition being different from the slot identifier of the most recently successfully upgraded partition and the number of startup failure retries corresponding to the slot identifier of the most recently successfully upgraded partition being less than or equal to a number threshold, determining the most recently successfully upgraded partition as the partition to be started; In response to the slot identifier of the successfully started partition being different from the slot identifier of the most recently successfully upgraded partition and the number of startup failure retries corresponding to the slot identifier of the most recently successfully upgraded partition being greater than the number threshold, determining the slot identifier of the successfully started partition as the partition to be started; In response to the slot identifier of the successfully started partition being the same as the slot identifier of the most recently successfully upgraded partition and the number of failed startup retries of the successfully started partition being greater than the number threshold, the other slot partition is determined as the partition to be started; the other slot partition is a slot partition other than the successfully started partition among the at least two slot partitions.

3. The method for starting a Linux system according to claim 1, wherein: The metadata is updated according to the startup result of the Linux system in the partition to be started, including at least one of the following: In response to the startup result being a startup failure, increasing the startup failure retry count of the partition to be started by 1; In response to the startup result being a successful startup and the slot identifier of the partition to be started being different from the slot identifier of the successfully started partition, changing the slot identifier of the successfully started partition to the slot identifier of the partition to be started; In response to the startup result being a successful startup, the number of startup failure retries is reset to 0.

4. The method for starting a Linux system according to any one of claims 1 to 3, characterized in that: The metadata also includes: an enable flag of a multi-system startup scheme; in response to the enable flag being enabled, executing a step of acquiring metadata of the slot partition; And / or, the updating of the metadata further comprises: after a Linux system of a slot partition is successfully upgraded, updating the slot identifier of the partition that has been most recently successfully upgraded; And / or, the Linux system includes: a boot loader and a kernel; in response to at least one of the boot loader and the kernel failing to load, determining the startup result as a startup failure.

5. A boot device for a Linux system, characterized in that: Applied to electronic devices, the electronic devices include at least two slot partitions, each slot partition stores a Linux system; The starting device comprises: An acquisition module is configured to obtain metadata of the slot partition in response to a system startup request; the metadata includes the following parameters: a slot identifier of a successfully started partition, a number of startup failure retries, and a slot identifier of a recently successfully upgraded partition; the slot identifier of the successfully started partition represents the identifier of the slot partition to which the last successfully started Linux system belongs; the number of startup failure retries represents the number of consecutive startups of the slot partition to which the failed startup Linux system belongs; the slot identifier of the recently successfully upgraded partition represents the identifier of the slot partition to which the last successfully upgraded Linux system belongs; A determination module, configured to determine a partition to be started based on the slot identifier of the successfully started partition, the slot identifier of the most recently successfully upgraded partition, and the number of startup failure retries; A startup module, used to start the Linux system in the partition to be started; The updating module is used to update the metadata according to the startup result of the Linux system in the partition to be started; the updated metadata is used for starting the Linux system next time.

6. The boot device of the Linux system according to claim 5, characterized in that: The determining module is specifically configured to: In response to the slot identifier of the successfully started partition being different from the slot identifier of the most recently successfully upgraded partition and the number of startup failure retries corresponding to the slot identifier of the most recently successfully upgraded partition being less than or equal to a number threshold, determining the most recently successfully upgraded partition as the partition to be started; In response to the slot identifier of the successfully started partition being different from the slot identifier of the most recently successfully upgraded partition and the number of startup failure retries corresponding to the slot identifier of the most recently successfully upgraded partition being greater than the number threshold, determining the slot identifier of the successfully started partition as the partition to be started; In response to the slot identifier of the successfully started partition being the same as the slot identifier of the most recently successfully upgraded partition and the number of failed startup retries of the successfully started partition being greater than the number threshold, the other slot partition is determined as the partition to be started; the other slot partition is a slot partition other than the successfully started partition among the at least two slot partitions.

7. The boot device of the Linux system according to claim 5, characterized in that: The update module is specifically used for: In response to the startup result being a startup failure, increasing the startup failure retry count of the partition to be started by 1; and / or, in response to the startup result being a successful startup and the slot identifier of the partition to be started being different from the slot identifier of the successfully started partition, changing the slot identifier of the successfully started partition to the slot identifier of the partition to be started; And / or, in response to the startup result being a successful startup, the number of startup failure retries is reset to 0.

8. The boot device of a Linux system according to any one of claims 5 to 7, characterized in that: The metadata also includes: an enable flag of a multi-system startup scheme; in response to the enable flag being enabled, executing a step of acquiring metadata of the slot partition; And / or, the updating of the metadata further comprises: after a Linux system of a slot partition is successfully upgraded, updating the slot identifier of the partition that has been most recently successfully upgraded; And / or, the Linux system includes: a boot loader and a kernel; in response to at least one of the boot loader and the kernel failing to load, determining the startup result as a startup failure.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and configured to run on the processor, wherein: When the processor executes the computer program, the method for starting the Linux system according to any one of claims 1 to 4 is implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the startup method of the Linux system according to any one of claims 1 to 4 is implemented.

Images