CN113806139B - 操作系统恢复方法、设备、存储介质及计算机程序产品 - Google Patents

操作系统恢复方法、设备、存储介质及计算机程序产品 Download PDF

Info

Publication number
CN113806139B
CN113806139B CN202110662964.2A CN202110662964A CN113806139B CN 113806139 B CN113806139 B CN 113806139B CN 202110662964 A CN202110662964 A CN 202110662964A CN 113806139 B CN113806139 B CN 113806139B
Authority
CN
China
Prior art keywords
partition
operating system
tray
data
value
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202110662964.2A
Other languages
English (en)
Other versions
CN113806139A (zh
Inventor
陈超
王艳召
张赠辉
黄九林
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202110662964.2A priority Critical patent/CN113806139B/zh
Publication of CN113806139A publication Critical patent/CN113806139A/zh
Application granted granted Critical
Publication of CN113806139B publication Critical patent/CN113806139B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1417—Boot up procedures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1433—Saving, restoring, recovering or retrying at system level during software upgrading
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44536—Selecting among different versions

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本申请实施例提供的一种操作系统恢复方法、设备、存储介质及计算机程序产品，方法应用于电子设备，方法包括：当电子设备的启动过程包含失败的落盘操作时，更新落盘操作失败记录信息；基于更新后的落盘操作失败记录信息，确定需要恢复操作系统时，获取当前版本的操作系统的完整安装镜像；重启电子设备进入恢复模式；在恢复模式下，使用当前版本的操作系统的完整安装镜像恢复电子设备的操作系统；重启电子设备，加载基础分区、第一静态分区或第二静态分区、动态分区的数据以运行操作系统。根据本申请实施例的方法，可以有效避免落盘失败导致重复循环执行落盘操作状况的发生，从而提高操作系统运行稳定性。

Description

操作系统恢复方法、设备、存储介质及计算机程序产品
技术领域
本申请涉及计算机技术领域，具体地涉及一种操作系统恢复方法、设备、存储介质及计算机程序产品。
背景技术
在现有技术的应用场景中，用户终端需要安装操作系统才可以被用户使用。例如，手机上需要安装手机操作系统(例如：IOS系统、安卓系统)才可以被用户使用。
在终端设备安装操作系统后，当操作系统出现版本升级时，需要升级终端设备上所安装的操作系统。在升级操作系统过程中，由于数据错误(例如，操作系统升级安装包数据错误)、设备异常(例如，内存地址跳变、数据传输异常)等原因，会导致操作系统升级失败。因此，需要一种针对操作系统升级失败的应对方法。
发明内容
有鉴于此，本申请提供一种操作系统恢复方法、设备、存储介质及计算机程序产品，以利于解决现有技术中操作系统升级失败的问题。
第一方面，本申请实施例提供了一种操作系统恢复方法，应用于电子设备，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述方法包括：
当所述电子设备的启动过程包含失败的落盘操作时，更新落盘操作失败记录信息，所述落盘操作失败记录信息用于记录所述电子设备的失败的落盘操作；
基于所述更新后的落盘操作失败记录信息，确定需要恢复操作系统时，获取当前版本的操作系统的完整安装镜像；
重启所述电子设备进入恢复模式；
在所述恢复模式下，使用所述当前版本的操作系统的完整安装镜像恢复所述电子设备的操作系统；
重启所述电子设备，加载所述基础分区、所述第一静态分区或所述第二静态分区、所述动态分区的数据以运行操作系统。
在第一方面的一种实现方式中，所述当所述电子设备的启动过程包含失败的落盘操作时，更新落盘操作失败记录信息之前，所述方法还包括：
在所述电子设备启动并成功运行操作系统后，读取落盘状态信息；
当所述落盘状态信息表示未落盘时，判定所述电子设备的启动过程包含失败的落盘操作。
在第一方面的一种实现方式中，所述在所述电子设备启动并成功运行操作系统后，读取落盘状态信息，包括：
在所述电子设备启动并成功运行操作系统后，在第一预设时长后读取所述落盘状态信息。
在第一方面的一种实现方式中，所述落盘操作失败记录信息用于记录所述电子设备的落盘操作的失败次数；
在所述更新落盘操作失败记录信息之后，所述方法还包括：
当所述落盘操作失败记录信息中的落盘操作的失败次数大于第一值时，获取当前版本的操作系统的完整安装镜像。
在第一方面的一种实现方式中，所述落盘操作失败记录信息包括落盘失败项，所述方法包括：
在所述电子设备启动并成功运行操作系统后，读取落盘状态信息；
当所述落盘状态信息表示未落盘时，将所述落盘操作失败记录信息中的落盘失败项的值加1；
当所述落盘操作失败记录信息中的落盘失败项的值大于所述第一值时，获取当前版本的操作系统的完整安装镜像。
在第一方面的一种实现方式中，所述方法还包括：
当所述落盘状态信息表示已落盘时，将所述落盘操作失败记录信息中的落盘失败项的值置为0。
在第一方面的一种实现方式中，同一天内的多次落盘操作失败，在所述落盘操作失败记录信息中被记录为一次落盘操作失败。
在第一方面的一种实现方式中，所述落盘操作失败记录信息包括落盘失败项以及日期项，所述方法包括：
在所述电子设备启动并成功运行操作系统后，读取落盘状态信息；
当所述落盘状态信息表示未落盘时，读取所述落盘操作失败记录信息中所述落盘失败项的值；
当所述落盘失败项的值不为0时，读取所述落盘操作失败记录信息中所述日期项的值；
当所述日期项的值不为当前日期时，将所述落盘失败项的值加1，将日期项的值置为当前日期；
当所述落盘操作失败记录信息中的落盘失败项的值大于所述第一值时，判断需要恢复操作系统。
在第一方面的一种实现方式中，所述方法还包括：
当所述落盘状态信息表示已落盘时，将所述落盘操作失败记录信息中的落盘失败项的值置为0。
在第一方面的一种实现方式中，所述方法还包括：
当所述落盘失败项的值为0时，将所述落盘失败项的值加1，将日期项的值置为当前日期。
在第一方面的一种实现方式中，所述在所述恢复模式下，使用所述当前版本的操作系统的完整安装镜像恢复所述电子设备的操作系统，包括：
从所述完整安装镜像中提取基础分区镜像、静态分区镜像以及动态分区镜像，将所述基础分区镜像、静态分区镜像以及动态分区镜像烧录到所述基础分区、所述第一静态分区、所述第二静态分区以及所述动态分区。
第二方面，本申请还提供一种电子设备，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述处理器用于执行所述存储器上存储的软件代码，以使得所述电子设备执行如第一方面所述的方法流程。
第三方面，本申请还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如权第一方面所述的方法。
第四方面，本申请还提供一种计算机程序产品，所述计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行如第一方面所述的方法。
根据本申请实施例所提出的上述技术方案，至少可以实现下述技术效果：
根据本申请实施例的方法，可以在落盘操作失败后恢复操作系统数据，从而有效避免落盘失败导致重复循环执行落盘操作状况的发生，进而提高操作系统运行稳定性，及时释放用户存储空间。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。
图1所示为根据本申请一实施例的数据存储结构示意图；
图2所示为根据本申请一实施例的操作系统升级的流程图；
图3所示为根据本申请一实施例恢复操作系统的流程图；
图4所示为根据本申请一实施例恢复操作系统的流程图；
图5所示为根据本申请一实施例恢复操作系统的流程图。
具体实施方式
为了更好的理解本申请的技术方案，下面结合附图对本申请实施例进行详细描述。
应当明确，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。
应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，甲和/或乙，可以表示：单独存在甲，同时存在甲和乙，单独存在乙这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
图1所示为根据本申请一实施例的数据存储结构示意图。如图1所示，安卓系统数据存储区包含基础分区(Common)、静态分区(A)(第一静态分区)、静态分区(B)(第二静态分区)、动态分区(Super)、用户数据分区(Userdata)。
用户数据分区(Userdata)用于保存用户的个人数据，例如，用户个人安装的APP、用户个人保存的图片、文档以及视频等个人数据。基础部分中保存的数据为不参与操作系统升级的系统数据。静态分区(A)与静态分区(B)的结构相互对应，子分区命名通过后缀_a以及_b相互区分。例如，静态分区(A)包括bootloader_a、boot_a、vendor_boot_a、dtbo_a、vbmeta_a；静态分区(B)包括bootloader_b、boot_b、vendor_boot_b、dtbo_b、vbmeta_b。动态分区(Super)包含多个子分区(System、system_ext、vendor、product、Cust、Odm)。
在设备启动时，从一个静态分区启动。例如，设备从静态分区(A)启动：依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)；设备从静态分区(B)启动：依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)。
图2所示为针对图1所示实施例的操作系统数据存储结构进行操作系统升级的流程图，当设备当前是从静态分区(A)启动时，设备按照如图2所示的流程实现操作系统的升级。
S200，设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。
S210，设备获取操作系统升级安装包。
示例的，在一种可行的实现方案中，设备定期向搜包服务器发起搜包请求，搜包请求包含设备当前运行的操作系统的版本号(例如版本1.1)；搜包服务器根据搜包请求中的操作系统版本号，检索当前是否存在更新版本号的操作系统安装包(例如版本1.2)；当存在更新版本的操作系统安装包时，搜包服务器向设备反馈操作系统升级安装包(例如，由版本1.1升级到版本1.2的系统增量升级安装包)的下载地址；设备根据操作系统升级安装包的下载地址下载操作系统升级安装包，并将操作系统升级安装包保存到用户数据分区(Userdata)。
S220，设备根据操作系统升级安装包针对静态分区(B)进行数据写入操作以升级静态分区。
例如，版本1.1升级到版本1.2的系统增量升级安装包包含版本1.2的静态分区的全量数据，设备将版本1.2的静态分区的数据覆写到静态分区(B)中。
S230，设备根据操作系统升级安装包在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区写入动态分区(Super)的升级数据。例如，在操作系统升级安装包中包含版本1.2的动态分区的数据，设备在虚拟动态分区中写入版本1.2的动态分区(Super)的数据。
进一步的，在虚拟A/B升级方案中，针对动态分区(Super)，采用增量升级方式。在升级过程中，用户数据分区(Userdata)的虚拟动态分区中保存的并不是升级后新版本的动态分区(Super)的全部文件，而是旧版本的动态分区(Super)中需要升级的数据在升级后的升级结果。即，用户数据分区(Userdata)的虚拟动态分区中保存的是动态分区的更新数据。
以system子分区为例，假设在版本1.1中，system子分区中的数据可以分为system1、system2两部分。从版本1.1升级到版本1.2，数据system2没有发生变化，数据syetem1被升级为system3。那么，在S230中，设备在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区中写入数据system3。
例如，版本1.1升级到版本1.2的系统增量升级安装包包含版本1.1升级到版本1.2的动态分区(Super)更新数据，该动态分区(Super)更新数据包含数据system3。
进一步的，在虚拟A/B升级方案中，基于快照技术(snapshot)实现动态分区(Super)的增量升级。具体的，用户数据分区(Userdata)的虚拟动态分区中，采用写时拷贝(Copy-On-Write，COW)文件保存动态分区(Super)的升级数据。
具体的，用户数据分区(Userdata)中保存的动态分区(Super)的升级数据包含多个COW文件，每个COW文件对应一个动态分区(Super)的子分区，COW文件的命名与其所针对的动态分区(Super)子分区相对应。
在S210所获取的操作系统升级安装包中，动态分区(Super)的升级数据的COW文件以二进制代码形式压缩保存。在操作系统升级安装包中，每个COW文件根据其所针对的动态分区(Super)子分区所命名。例如，针对system子分区的COW文件被命名为system-cow-img.img.0000。
在S230中，设备解包操作系统升级安装包以获取所有的COW文件，为每个COW文件附加A/B分区标记。具体的，当设备当前从静态分区(A)启动时，可以理解为设备当前运行操作系统所加载的动态分区(Super)为动态分区(A)。在升级操作系统时，用户数据分区(Userdata)中创建的虚拟动态分区是针对动态分区(B)。因此，为COW文件附加对应动态分区(B)的名称标记_b。例如，为system-cow-img.img.0000附加_b生成system_b-cow-img.img.0000。
进一步的，在S230中，在用户数据分区(Userdata)中创建Update文件夹，将重命名的COW文件保存到Update文件夹下。例如，在一应用场景中，在向用户数据分区(Userdata)写入COW文件后，用户数据分区(Userdata)的Update文件夹中包含下述文件：
system_b-cow-img.img.0000；
system_ext_b-cow-img.img.0000；
vendor_b-cow-img.img.0000；
product_b-cow-img.img.0000；
cust_b-cow-img.img.0000；
odm_b-cow-img.img.0000。
具体的，COW文件中包含COW文件自身的COW文件地图(快照map)以及升级数据。COW文件地图(快照)与COW文件所针对的动态分区(Super)的子分区的文件地图相对应。动态分区(Super)的子分区的文件地图用于描述当前版本的操作系统(本次升级之前的版本，例如，版本1.1)动态分区(Super)的子分区中的所有文件以及各个文件的保存地址。
COW文件中的升级数据为相较于当前版本的子分区数据，新版本的子分区数据中被更新的文件；COW文件自身的COW文件地图则用于描述被更新的文件与当前版本的子分区中的文件间的对应关系以及被更新的文件的保存地址。
基于动态分区(Super)的子分区的文件地图以及COW文件中的COW文件地图，就可以使用COW文件中的升级数据替换动态分区(Super)的子分区中的对应文件，从而实现动态分区(Super)数据的升级。具体的，在需要获取动态分区(Super)的子分区的文件地图时，可以基于snapshot对动态分区(Super)的子分区的数据进行快照操作以生成动态分区(Super)的子分区的文件地图。也可以在制作操作系统升级安装包时，预先生成动态分区(Super)的子分区的文件地图，将该文件地图加入到COW文件中。
以system子分区为例，假设system子分区中按照以下路径保存数据：
/system/app/A0.XXX；
/system/app/A1.XXX；
/system/app/A2.XXX；
/system/B0.XXX；
/system/B1.XXX；
/system/user/C0.XXX；
/system/user/C1.XXX；
/system/user/C2.XXX；
/system/user/C3.XXX。
system子分区的文件地图可以是：
/system/app/A0.XXX：024010～024013；
/system/app/A1.XXX：024014～024017；
/system/app/A2.XXX：024018～024020；
/system/B0.XXX：024021～024026；
/system/B1.XXX：024027～024028；
/system/user/C0.XXX：024029～024032；
/system/user/C1.XXX：024033～024035；
/system/user/C2.XXX：024036～024040；
/system/user/C3.XXX：024041～024044。
文件名后的数值(例如，/system/app/A0.XXX：024010～024013中的024010～024013)为该文件在动态分区(Super)的system子分区的物理保存地址(块地址)。
假设当前操作系统升级需要更新数据/system/app/A2.XXX以及/system/user/C2.XXX。
可以视为：
/system/app/A2.XXX以及/system/user/C2.XXX为system子分区数据的system1部分；
/system/app/A0.XXX、/system/app/A1.XXX、/system/B0.XXX、/system/B1.XXX、/system/user/C0.XXX、/system/user/C1.XXX以及/system/user/C3.XXX为system子分区数据的system2部分。
那么，针对system子分区的COW文件(system_b-cow-img.img.0000)就包含最新版的/system/app/A2.XXX以及/system/user/C2.XXX。
可以视为，最新版的/system/app/A2.XXX以及/system/user/C2.XXX为system3。升级目标是使用system3更新掉system1。
当COW文件中的更新数据的大小与其所要更新的原始数据的大小一致，并且，COW文件中的更新数据在数据更新后在子分区中的保存位置与其所要更新的原始数据在子分区中的保存位置一致时，COW文件(system_b-cow-img.img.0000)自身的COW文件地图可以为：
/system/app/A2.XXX：
Map1(原super分区中待更新数据的地址)：起始地址address start：024018(相对于system起始地址的偏移量)；偏移量大小size：2(即024018～024020地址段的数据)
Map2(cow文件中存储的更新数据的地址)：起始地址address start：045033(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：2(即045033～045035地址段的数据)；
/system/user/C2.XXX：
Map1(原super分区中待更新数据的地址)：起始地址address start：024036(相对于system起始地址的偏移量)；偏移量大小size：4(即024036～024040地址段的数据)
Map2(cow文件中存储的更新数据的地址)：起始地址address start：045036(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：4(即045036～045040地址段的数据)。
当COW文件中的更新数据的大小与其所要更新的原始数据的大小不一致时，COW文件(system_b-cow-img.img.0000)自身的COW文件地图可以为：
/system/app/A2.XXX：
Map1.1(原super分区中待更新数据的地址)：起始地址address start：024018(相对于system起始地址的偏移量)；偏移量大小size：2(即024018～024020地址段的数据)；
Map2.1(cow文件中存储的，需要覆盖Map1.1地址的更新数据的地址)：起始地址address start：045033(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：2(即045033～045035地址段的数据)；
Map1.2(cow文件中更新数据超出待更新数据大小的那一部分在原super分区中的待写入地址)：起始地址address start：025018(相对于system起始地址的偏移量)；偏移量大小size：1(即025018～025020地址段的数据)；
Map2.2(cow文件中存储的，需要覆盖Map1.2地址的更新数据的地址)：起始地址address start：046033(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：2(即046033～046035地址段的数据)。
在接下来的说明书描述中，为便于描述，仅以当COW文件中的更新数据的大小与其所要更新的原始数据的大小一致，并且，COW文件中的更新数据在数据更新后在子分区中的保存位置与其所要更新的原始数据在子分区中的保存位置一致的应用场景进行举例说明。
在上述例子中，地址段(045033～045035以及045036～045040)分别为COW文件(system_b-cow-img.img.0000)中最新版的/system/app/A2.XXX以及/system/user/C2.XXX在用户数据分区(Userdata)的物理保存地址(块地址)。
这样，如果使用地址045033～045035上的A2.XXX替换掉地址024018～024020上的A2.XXX，并且，使用地址045036～045040上的C2.XXX替换掉地址024036～024040上的C2.XXX，就可以完成动态分区(Super)的system子分区的数据升级。
进一步的，在S230中，在将COW文件写入用户数据分区(Userdata)后，还需要对动态分区(Super)+COW文件进行整体校验，校验动态分区(Super)+COW文件的有效性，验证当前版本的动态分区(Super)数据+COW文件的合成结果是否为新版本的动态分区(Super)数据。
具体的，以从1.1版本升级到1.3版本为例，计算动态分区(Super)中不需要升级的数据(从版本1.1到版本1.2未发生变化的数据)与COW文件中升级数据(从版本1.1到版本1.2需要升级的数据)的合成结果的哈希值，判断该哈希值与1.3版本中动态分区(Super)的完整数据的哈希值是否一致，如果一致，则说明COW文件有效；如果不一致，则说明COW文件无效，升级失败，中断升级进程并报错；其中，1.3版本中动态分区(Super)的完整数据的哈希值被保存在操作系统升级安装包中。
具体的，在校验过程中，基于snapshot合并动态分区(Super)+COW文件。在snapshot的实现过程中，动态分区(Super)与COW文件的合并并不是物理意义上的合并，而是将COW文件中子分区的整体文件地图与COW文件自身的COW文件地图进行合并，生成新版本的子分区数据的文件地图。
例如，将system子分区的文件地图：
/system/app/A0.XXX：024010～024013；
/system/app/A1.XXX：024014～024017；
/system/app/A2.XXX：024018～024020；
/system/B0.XXX：024021～024026；
/system/B1.XXX：024027～024028；
/system/user/C0.XXX：024029～024032；
/system/user/C1.XXX：024033～024035；
/system/user/C2.XXX：024036～024040；
/system/user/C3.XXX：024041～024044。
与COW文件地图：
/system/app/A2.XXX：
Map1：address start：024018；size：2(即024018～024020地址段的数据)；
Map2：address start：045033；size：2(即045033～045035地址段的数据)；
/system/user/C2.XXX：
Map1：address start：024036；size：4(即024036～024040地址段的数据)；
Map2：address start：045036；size：4(即045036～045040地址段的数据)。
合并。则得到system子分区的新版本的文件地图：
/system/app/A0.XXX：024010～024013(指向动态分区(Super)中/system/app下的A0.XXX)；
/system/app/A1.XXX：024014～024017(指向动态分区(Super)中/system/app下的A1.XXX)；
/system/app/A2.XXX：045033～045035(指向用户数据分区(Userdata)中/Update/system_b-cow-img.img.0000中的A2.XXX)；
/system/B0.XXX：024021～024026(指向动态分区(Super)中/system下的B0.XXX)；
/system/B1.XXX：024027～024028(指向动态分区(Super)中/system下的B1.XXX)；
/system/user/C0.XXX：024029～024032(指向动态分区(Super)中/system/user下的C0.XXX)；
/system/user/C1.XXX：024033～024035(指向动态分区(Super)中/system/user下的C1.XXX)；
/system/user/C2.XXX：045036～045040(指向用户数据分区(Userdata)中/Update/system_b-cow-img.img.0000中的C2.XXX)；
/system/user/C3.XXX：024041～024044(指向动态分区(Super)中/system/user下的C3.XXX)。
在新版本的system子分区的文件地图中，/system/app/A2.XXX的保存地址并不是指向存储器上动态分区(Super)上的/system/app/A2.XXX，而是指向存储器上用户数据分区(Userdata)中system_b-cow-img.img.0000中的A2.XXX；/system/user/C2.XXX的保存地址并不是指向存储器上动态分区(Super)上的/system/user/C2.XXX，而是指向存储器上用户数据分区(Userdata)中system_b-cow-img.img.0000中的C2.XXX。
在校验过程中，按照上述合成方式，获取动态分区(Super)的所有子分区的新版本的文件地图(如果用户数据分区(Userdata)中并未写入某个子分区的对应COW文件，则直接以该子分区的文件地图为新版本的文件地图)。将所有子分区的新版本的文件地图组合生成动态分区(Super)的新版本的文件系统。
基于动态分区(Super)的新版本的文件系统读取数据，读取动态分区(Super)的新版本的文件系统所包含的所有文件并计算哈希值。
当COW文件有效时，将基础分区(Common)的元数据分区(/metadata)中的落盘状态信息由“已落盘(merged)”改为“未落盘(wait for merge)”。落盘状态信息用于表示当前是否存在需要落盘到动态分区(Super)的COW文件。具体的，落盘状态信息包含针对动态分区(Super)的整体标识以及针对每个子分区的子分区标识。当整体标识为“已落盘(merged)”时，代表动态分区(Super)的所有子分区均不需要进行落盘操作；当整体标识为“未落盘(wait for merge)”时，代表动态分区(Super)的一个或多个子分区需要进行落盘操作；当子分区标识为“已落盘(merged)”时，代表该子分区不需要进行落盘操作；当子分区标识为“未落盘(wait for merge)”时，代表该子分区需要进行落盘操作。
S231，将设备的启动顺序由从静态分区(A)启动变更为从静态分区(B)启动。
例如，改写主引导记录(Master Boot Record，MBR)的启动顺序标识，将启动顺序标识由A改写为B。在设备上电后，当设备读取到启动顺序标识为A，设备从静态分区(A)启动，启动过程中加载静态分区(A)；当设备读取到启动顺序标识为B，设备从静态分区(B)启动，启动过程中加载静态分区(B)。
S232，设备重启。退出当前的操作系统，切断设备电源，再次开启设备电源。
S240，设备依次加载基础分区(Common)、静态分区(B)。
S241，设备加载动态分区(Super)以及用户数据分区(Userdata)的虚拟动态分区。
具体的，设备读取元数据(/metadata)中的落盘状态信息，基于落盘状态信息确定是否需要从用户数据分区(Userdata)的指定路径中检索COW文件，并采用snapshot合并加载动态分区(Super)以及COW文件。
进一步的，在S241中，设备并不加载动态分区(Super)以及用户数据分区(Userdata)中的全部COW文件，而是根据操作系统运行需求加载对应的文件。具体的，在S241中，设备根据操作系统运行需求确定需要加载的文件，基于snapshot从动态分区(Super)或虚拟动态分区中的COW文件中提取对应的文件进行加载。
具体的，在S241中，当动态分区(Super)的子分区首存在对应的COW文件时，先基于snapshot生成动态分区(Super)各个子分区的新版本的文件地图。生成新版本的文件地图的过程可以参照S230。设备根据操作系统运行需求确定需要加载的文件，基于动态分区(Super)子分区的新版本的文件地图进行文件加载。
例如，操作系统运行需求加载system子分区下目录user(/system/user)中的所有数据。设备读取元数据(/metadata)中的落盘状态信息，落盘状态信息中system子分区的子分区标识为“未落盘(wait for merge)”，因此，设备在用户数据分区(Userdata)中/Update下搜索COW文件，在Update下搜索到COW文件system_b-cow-img.img.0000后，基于snapshot，根据system_b-cow-img.img.0000中的COW文件的文件地图生成system子分区的新版本的文件地图。按照system子分区的新版本的文件地图中/system/user下所有文件的保存地址进行数据加载，例如，根据system子分区的新版本的文件地图中：
/system/user/C0.XXX：024029～024032；
/system/user/C1.XXX：024033～024035；
/system/user/C2.XXX：045036～045040；
/system/user/C3.XXX：024041～024044。
加载地址024029～024032处的C0.XXX、地址024033～024035处的C1.XXX、地址045036～045040处的C2.XXX以及地址024041～024044处的C3.XXX。
进一步的，在加载system子分区下目录user(/system/user)中的所有数据时，当落盘状态信息中system子分区的子分区标识为“已落盘(merged)”时，设备就不会在用户数据分区(Userdata)中/Update下搜索COW文件，而是直接加载system子分区下目录user(/system/user)中的所有数据。
进一步的，在加载system子分区下目录user(/system/user)中的所有数据时，当落盘状态信息中system子分区的子分区标识为“未落盘(wait for merge)”时，如果设备在用户数据分区(Userdata)中/Update下未搜索到对应system子分区的COW文件时，则说明升级过程中数据写入错误(COW文件写入错误或者落盘状态信息写入错误)，此时设备回滚系统并报错。
进一步的，在S241中，在加载文件之前，设备还需要对加载文件进行校验。不同于S230，在S241中，不对动态分区(Super)+COW文件进行整体验证，而是仅对需要加载的文件进行验证。例如，基于dmverity进行校验(dm-verity是dm(device mapper)的一个目标(target)，是一个虚拟块设备，专门用于文件系统的校验)。校验成功则加载文件，校验失败则重启设备，回滚系统或者尝试再次加载文件。
S250，设备成功启动，进入用户交互界面。
S251，设备将虚拟动态分区的数据落盘到动态分区(Super)。
在本申请说明书的描述中，落盘操作指的是，在操作系统升级过程中，将用户数据分区(Userdata)上虚拟动态分区中保存的动态分区(Super)升级文件(COW文件)写入到动态分区(Super)中，使得动态分区(Super)的文件完成数据升级，以便设备在下次启动时不需要加载动态分区(Super)和虚拟动态分区，只需加载动态分区(Super)就可以完成设备启动。
具体的，设备在启动成功后进行开机广播，开机广播后开启升级进程。升级进程读取基础分区(Common)的元数据(/metadata)中的落盘状态信息，如果落盘状态信息为“已落盘(merged)”，则设备进入正常运行模式。
如果落盘状态信息为“未落盘(wait for merge)”，升级进程将用户数据分区(Userdata)中的COW文件落盘到动态分区(Super)中。
具体的，升级进程将用户数据分区(Userdata)中的COW文件中的升级数据写入到动态分区(Super)中的对应地址上，使得动态分区(Super)中的全部数据均为升级后的新版本的数据。
例如，基于system子分区的文件地图中的/system/app/A2.XXX：024018～024020以及COW文件地图中的/system/app/A2.XXX：045033～045035，将地址045033～045035上的数据写入到地址024014～024017上；基于system子分区的文件地图中的/system/user/C2.XXX：024036～024040以及COW文件地图中的/system/user/C2.XXX：045036～045040，将地址045036～045040上的数据写入到地址024036～024040上。
在此之后升级进程删除用户数据分区(Userdata)中的COW文件，将存储空间归还给用户数据分区(Userdata)；并且，将基础分区(Common)的元数据(/metadata)中的落盘状态信息由“未落盘(wait for merge)”改为“已落盘(merged)”。
在S220中，静态分区升级的数据操作是针对静态分区(B)中的操作系统数据的，其并不会影响到当前启动的静态分区(A)的操作系统数据；并且，在S230中，动态分区升级的数据操作是在用户数据分区(Userdata)中所创建的虚拟动态分区上完成的，其并不会影响到当前挂载的动态分区(Super)。因此，在整个操作系统升级的过程中，用户可以正常使用设备；并且，在S231完成后，设备并不需要立即重启，可以由用户自行选择重启时机；这样，操作系统的升级过程并不会对用户的正常手机操作产生影响，从而大大提高了用户体验。进一步的，针对动态分区(Super)，仅在需要进行升级时才会在用户数据分区(Userdata)上创建虚拟动态分区，因此有效提高了数据存储空间利用率。
进一步的，在S251中，落盘操作存在操作失败的情况。例如，在设备进行落盘操作的过程中，在设备将内存中的数据写入动态分区(Super)时，设备内存地址跳变，写入操作失败，导致落盘进程中断。又例如，在设备进行落盘操作的过程中，在设备读取用户数据分区(Userdata)上的COW文件时，用户数据分区(Userdata)出现数据错误，读取操作失败，导致落盘进程中断。
在S251中，如果落盘操作失败，则升级进程就不会删除用户数据分区(Userdata)中的COW文件；并且，也不会将元数据(/metadata)中的落盘状态信息由“未落盘(wait formerge)”改为“已落盘(merged)”。这样，在设备下次重启时，就会再次执行S240～S251。一般的，设备重启会修复导致落盘失败的错误因素(例如，重启后设备内存地址跳变被修复)，因此，重启后设备会顺利执行S240～S251，成功完成落盘操作，设备的操作系统成功完成升级。
然而，在某些应用场景中，导致落盘失败的错误因素是无法修复的，这就会导致设备每次重启后都会执行S240～S251，始终无法完成操作系统升级。
针对上述问题，本申请一实施例提出了一种恢复操作系统的方法，以解决操作系统过程中无法落盘的问题。图3所示为根据本申请一实施例恢复操作系统的流程图。设备执行图2所示流程，在S251中，如果落盘操作失败，升级进程不删除用户数据分区(Userdata)中的COW文件；并且，也不将元数据(/metadata)中的落盘状态信息由“未落盘(wait formerge)”改为“已落盘(merged)”。
在S251之后，设备执行如图3所示的下述步骤：
S300，判断本次设备启动过程是否包含失败的落盘操作；
示例的，在S300中，设备读取元数据(/metadata)中的落盘状态信息；当落盘状态信息为“未落盘(wait for merge)”时，则说明在本次设备启动过程中执行了落盘操作并且落盘操作失败；当落盘状态信息为“已落盘(merged)”时，则说明在本次设备启动过程中没有执行落盘操作，或者执行了落盘操作并且落盘操作成功。
当本次设备启动过程不包含失败的落盘操作(没有执行落盘操作，或者执行了落盘操作并且落盘操作成功)时，流程结束。
当本次设备启动过程包含失败的落盘操作时，执行S310，更新落盘操作失败记录信息，落盘操作失败记录信息用于保存落盘操作失败历史记录；
S320，根据落盘操作失败记录信息判断是否需要恢复操作系统；
例如，当落盘操作失败记录信息记录的落盘操作重复执行次数超过预设的阈值时，判定需要恢复操作系统；
当不需要恢复操作系统时，流程结束；
当需要恢复操作系统时，执行S330，获取当前版本操作系统的完整安装镜像(包括静态分区安装镜像以及动态分区安装镜像)，保存到用户数据分区(Userdata)；S330的具体执行可以参照S210；
S340，将设备的启动顺序变更为从恢复(Recovery)模式启动；例如，改写主引导记录(Master Boot Record，MBR)的启动顺序标识，将启动顺序标识由A改写为R，其中，在设备上电后，当设备读取到启动顺序标识为A，设备从静态分区(A)启动，启动过程中加载静态分区(A)；当设备读取到启动顺序标识为B，设备从静态分区(B)启动，启动过程中加载静态分区(B)；当设备读取到启动顺序标识为R，设备加载运行Recovery模式的数据，进入Recovery模式；
进一步的，在S340中，在主引导记录(Master Boot Record，MBR)中增加“进入recovery执行升级”command命令用于升级。
S350，设备重启；参照S232；
S360，重启后的设备进入Recovery模式；
S361，使用用户数据分区(Userdata)中保存的操作系统的完整安装镜像恢复静态分区以及动态分区的操作系统数据；
例如，在S350之后，设备读取主引导记录(Master Boot Record，MBR)，确认需要进入recovery模式，设备执行“进入recovery执行升级”的command命令，以实现S361的操作。S362，将设备的启动顺序变更为从静态分区启动；
具体的，在S361中，可以仅恢复一个静态分区，也可以恢复两个静态分区。例如，在S361中，恢复静态分区(A)的数据以及动态分区(Super)的数据；在S362中，将设备的启动顺序变更为从静态分区(A)启动。又例如，在S361中，恢复静态分区(A)的数据、静态分区(B)的数据(静态分区(A)与静态分区(B)的数据一致)以及动态分区(Super)的数据；在S362中，将设备的启动顺序变更为从静态分区(A)或静态分区(B)启动。
进一步的，考虑到落盘操作失败只会影响到动态分区(Super)的数据，静态分区上的数据是可以正常加载的正确数据。因此，在一实施例中，在S330中，获取当前版本操作系统的动态分区安装镜像；在S361中，仅恢复动态分区(Super)的数据；在S362中，将设备的启动顺序变更为从静态分区(B)启动；
示例性的，考虑到设备出厂前通常被设置为从静态分区(A)启动，因此，以重启后从静态分区(A)启动为例进行说明，在S362中，将设备的启动顺序变更为从静态分区(A)启动；
S370，设备重启；参照S232；
S380，终端设备加载基础分区(Common)、静态分区(A)以及动态分区(Super)的数据，从静态分区(A)启动运行操作系统；
S390，设备成功启动，进入用户交互界面。
进一步的，在S340中，操作系统的数据恢复并不会涉及到用户数据分区(Userdata)上的数据，而落盘操作失败会使得用户数据分区(Userdata)上的COW文件不会被删除。因此，在一实施例中，在S390之后，设备还执行S391，删除用户数据分区(Userdata)上的COW文件，以释放用户可自由使用的存储空间。
进一步的，在S390之后，设备还执行S392，删除用户数据分区(Userdata)上的操作系统的完整安装镜像，以释放用户可自由使用的存储空间。
根据本申请实施例的方法，可以在落盘操作失败后恢复操作系统数据，从而有效避免落盘失败导致重复循环执行落盘操作状况的发生，进而提高操作系统运行稳定性，及时释放用户存储空间。
进一步的，在本申请的方案中，执行S300的时间节点为S251之后。本申请对S300的执行时序不做具体限制，本领域的技术人员可以根据实际需求设定S300的执行时刻或者触发S300的触发条件。
例如，在一实施例中，设定设备每次启动后的5分钟触发S300的执行。又例如，在一实施例中，设定S300每隔3天被触发执行一次。又例如，在一实施例中，设定设备在进行定期操作系统搜包时触发S300执行一次。
进一步的，本申请对落盘操作失败记录信息的数据结构以及根据落盘操作失败记录信息判断是否需要恢复系统数据的判断逻辑不做具体限制。本领域的技术人员可以采用多种可行的实现方式实现S300～S320。以下通过具体实施例举例说明回复操作系统数据的具体执行过程。
图4所示为根据本申请一实施例恢复操作系统的流程图。设备执行图2所示流程，在S251中，如果落盘操作失败，升级进程不删除用户数据分区(Userdata)中的COW文件；并且，也不将基础分区(Common)的元数据(/metadata)中的落盘状态信息由“未落盘(waitfor merge)”改为“已落盘(merged)”。
在S251之后，设备执行如图4所示的下述步骤：
S400，读取基础分区(Common)的元数据(/metadata)中的落盘状态信息以及落盘操作失败记录信息。
具体的，落盘操作失败记录信息的数据结构如下表所示：
编号 项目名称 项目值
1 error_merge 0
表1
表1中，项目名称：error_merge表示该项为落盘失败的记录，error_merge项的项目值为记录上的落盘失败的次数。
S410，判断落盘状态信息是否为“已落盘(merged)”。
当落盘状态信息为“已落盘(merged)”时，执行S411，将error_merge的项目值置为0，流程结束。
当落盘状态信息为“未落盘(wait for merge)”时，执行S412，令error_merge的项目值+1。
S420，判断error_merge的值是否大于预设的阈值，例如，预设阈值为3，判断error_merge的值是否大于3。
当error_merge的值小于或等于预设的阈值时，流程结束。
当error_merge的值大于预设的阈值时，执行S430～S490，参照S330～S390。
进一步的，在某些应用场景中，短期内设备的多次重启可能不会重置设备状态，也就可能无法修复导致落盘失败的错误因素。例如，短期内设备的多次重启可能无法修复内存地址跳变。这样，短期内设备多次重启并多次落盘操作失败并不能说明导致落盘失败的错误因素是无法修复的。
因此，在本申请一实施例中，在记录落盘操作失败时，会参考设备的重启时间间隔，只有重启时间间隔超过预设时长阈值时，本次落盘操作失败才需要记录。
图5所示为根据本申请一实施例恢复操作系统的流程图。设备执行图2所示流程，在S251中，如果落盘操作失败，升级进程不删除动态分区(Super)的元数据(/supermetadata)中的COW块信息以及用户数据分区(Userdata)中的COW文件；并且，也不将元数据(/metadata)中的落盘状态信息由“未落盘(wait for merge)”改为“已落盘(merged)”。
在S251之后，设备执行如图5所示的下述步骤：
S500，读取元数据(/metadata)中的落盘状态信息以及落盘操作失败记录信息。
具体的，落盘操作失败记录信息的数据结构如下表所示：
编号 项目名称 项目值
1 error_merge 0
2 Date_merge X年/X月/X日
表2
表2中，项目名称：error_merge表示该项为落盘失败的记录，error_merge项的项目值为记录上的落盘失败的次数；Date_merge表示该项为记录落盘失败的时间，Date_merge项的项目值最后一次记录落盘失败的日期。
S510，判断落盘状态信息是否为“已落盘(merged)”。
当落盘状态信息为“已落盘(merged)”时，执行S511，将error_merge的项目值置为0。流程结束。
当落盘状态信息为“未落盘(wait for merge)”时，执行S512，判断error_merge的项目值是否为0；
如果为0，执行S515。
如果不为0，执行S514，判断当前日期与Date_merge的项目值是否一致。
如果一致，说明当前的落盘失败与记录中的上一次落盘失败是在同一天发生的，由于设定为同一天只进行一次落盘失败记录，因此本次落盘失败并不需要进行记录，也不需要判定是否需要恢复操作系统，流程结束。
如果不一致，执行S515，令error_merge的项目值+1，并且，将Date_merge的项目值置为当前日期。
S520～S590，参照S420～S490。
可以理解的是，上述实施例中的部分或全部步骤或操作仅是示例，本申请实施例还可以执行其它操作或者各种操作的变形。此外，各个步骤可以按照上述实施例呈现的不同的顺序来执行，并且有可能并非要执行上述实施例中的全部操作。
进一步的，一般的，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field ProgrammableGate Array，FPGA))就是这样一种集成电路，其逻辑功能由访问方对器件编程来确定。由设计人员自行编程来把一个数字装置“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
因此，本申请实施例所提出的方法流程可以以硬件方式实现，例如，使用控制器，控制器控制触摸屏以实现本申请实施例所提出的方法流程。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
与上述实施例对应，本申请还提供了一种电子设备。电子设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发电子设备执行如本申请实施例所述的方法步骤。
本申请还提供一种计算机程序产品，计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行本申请实施例提供的部分或全部步骤。
本领域的技术人员可以清楚地了解到本发明实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。
本说明书中各个实施例之间相同相似的部分互相参见即可。尤其，对于装置实施例和终端实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例中的说明即可。

Claims (8)

1.一种操作系统恢复方法，其特征在于，应用于电子设备，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述方法包括：
当所述电子设备的启动过程包含失败的落盘操作时，更新落盘操作失败记录信息，所述落盘操作失败记录信息用于记录所述电子设备的失败的落盘操作，所述落盘操作失败记录信息包括落盘失败项以及日期项；在所述电子设备启动并成功运行操作系统后，读取落盘状态信息，当所述落盘状态信息表示未落盘时，读取所述落盘操作失败记录信息中所述落盘失败项的值；当所述落盘失败项的值不为0时，读取所述落盘操作失败记录信息中所述日期项的值，当所述日期项的值不为当前日期时，将所述落盘失败项的值加1，将日期项的值置为当前日期；当所述落盘失败项的值为0时，将所述落盘失败项的值加1，将日期项的值置为当前日期；
基于所述更新后的落盘操作失败记录信息，确定需要恢复操作系统时，获取当前版本的操作系统的完整安装镜像，其中，当所述落盘操作失败记录信息中的落盘失败项的值大于第一值时，判断需要恢复操作系统；
重启所述电子设备进入恢复模式；
在所述恢复模式下，使用所述当前版本的操作系统的完整安装镜像恢复所述电子设备的操作系统；
重启所述电子设备，加载所述基础分区、所述第一静态分区或所述第二静态分区、所述动态分区的数据以运行操作系统。
2.根据权利要求1所述的方法，其特征在于，所述在所述电子设备启动并成功运行操作系统后，读取落盘状态信息，包括：
在所述电子设备启动并成功运行操作系统后，在第一预设时长后读取所述落盘状态信息。
3.根据权利要求1或2所述的方法，其特征在于，所述落盘操作失败记录信息用于记录所述电子设备的落盘操作的失败次数；
在所述更新落盘操作失败记录信息之后，所述方法还包括：
当所述落盘操作失败记录信息中的落盘操作的失败次数大于所述第一值时，获取当前版本的操作系统的完整安装镜像。
4.根据权利要求3所述的方法，其特征在于，同一天内的多次落盘操作失败，在所述落盘操作失败记录信息中被记录为一次落盘操作失败。
5.根据权利要求1所述的方法，其特征在于，所述方法还包括：
当所述落盘状态信息表示已落盘时，将所述落盘操作失败记录信息中的落盘失败项的值置为0。
6.根据权利要求1所述的方法，其特征在于，所述在所述恢复模式下，使用所述当前版本的操作系统的完整安装镜像恢复所述电子设备的操作系统，包括：
从所述完整安装镜像中提取基础分区镜像、静态分区镜像以及动态分区镜像，将所述基础分区镜像、静态分区镜像以及动态分区镜像烧录到所述基础分区、所述第一静态分区、所述第二静态分区以及所述动态分区。
7.一种电子设备，其特征在于，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述处理器用于执行所述存储器上存储的软件代码，以使得所述电子设备执行如权利要求1～6中任一项所述的方法流程。
8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如权利要求1～6中任一项所述的方法。
CN202110662964.2A 2021-06-15 2021-06-15 操作系统恢复方法、设备、存储介质及计算机程序产品 Active CN113806139B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110662964.2A CN113806139B (zh) 2021-06-15 2021-06-15 操作系统恢复方法、设备、存储介质及计算机程序产品

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110662964.2A CN113806139B (zh) 2021-06-15 2021-06-15 操作系统恢复方法、设备、存储介质及计算机程序产品

Publications (2)

Publication Number Publication Date
CN113806139A CN113806139A (zh) 2021-12-17
CN113806139B true CN113806139B (zh) 2023-04-07

Family

ID=78942502

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110662964.2A Active CN113806139B (zh) 2021-06-15 2021-06-15 操作系统恢复方法、设备、存储介质及计算机程序产品

Country Status (1)

Country Link
CN (1) CN113806139B (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117707626A (zh) * 2022-10-09 2024-03-15 荣耀终端有限公司 系统启动方法及电子设备
CN116755938B (zh) * 2023-08-14 2023-11-03 中科三清科技有限公司 计算重启方法、装置、存储介质及电子设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7734945B1 (en) * 2005-04-29 2010-06-08 Microsoft Corporation Automated recovery of unbootable systems
CN106294019A (zh) * 2016-08-11 2017-01-04 浪潮(北京)电子信息产业有限公司 一种操作系统镜像保存和恢复方法及装置
CN112015587A (zh) * 2019-05-31 2020-12-01 烽火通信科技股份有限公司 一种增强操作系统可靠性的方法及装置

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW573275B (en) * 2002-08-30 2004-01-21 Acer Inc Recovery method and device of computer operating system and method for building computer system with BTC model
TW591395B (en) * 2003-02-27 2004-06-11 Acer Inc Recovery method of multi-functional operating system and system thereof
CN102508734B (zh) * 2011-09-30 2015-06-03 Tcl集团股份有限公司 操作系统恢复方法及智能设备
CN102780578A (zh) * 2012-05-29 2012-11-14 上海斐讯数据通信技术有限公司 网络设备的操作系统的更新系统及更新方法
CN103645972A (zh) * 2013-12-17 2014-03-19 广州商科信息科技有限公司 系统自动恢复方法及装置
CN105573864A (zh) * 2015-12-15 2016-05-11 广州视源电子科技股份有限公司 终端系统恢复方法及其系统
CN106933604B (zh) * 2015-12-30 2021-03-05 中移(苏州)软件技术有限公司 一种系统升级方法及装置
CN105955846A (zh) * 2016-04-29 2016-09-21 乐视控股（北京）有限公司 移动终端基于网络升级失败后进行恢复的方法及系统
CN107967141B (zh) * 2017-11-27 2021-04-13 北京小米移动软件有限公司 操作系统升级方法、装置及终端
CN109815053B (zh) * 2019-01-04 2021-04-06 厦门亿联网络技术股份有限公司 一种实现ip话机多模式系统升级失败恢复方法
CN111338660A (zh) * 2020-02-29 2020-06-26 苏州浪潮智能科技有限公司 一种操作系统批量安装结果检查的方法、系统、设备及存储介质
CN111324490B (zh) * 2020-03-18 2023-05-12 深圳市亿晟科技有限公司 一种安卓广告机系统恢复方法
CN112000623A (zh) * 2020-08-07 2020-11-27 北京浪潮数据技术有限公司 一种元数据的存取方法、装置和计算机可读存储介质
CN112486733B (zh) * 2020-12-11 2023-08-18 Oppo广东移动通信有限公司 系统还原方法、装置、终端及存储介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7734945B1 (en) * 2005-04-29 2010-06-08 Microsoft Corporation Automated recovery of unbootable systems
CN106294019A (zh) * 2016-08-11 2017-01-04 浪潮(北京)电子信息产业有限公司 一种操作系统镜像保存和恢复方法及装置
CN112015587A (zh) * 2019-05-31 2020-12-01 烽火通信科技股份有限公司 一种增强操作系统可靠性的方法及装置

Also Published As

Publication number Publication date
CN113806139A (zh) 2021-12-17

Similar Documents

Publication Publication Date Title
CN113805914B (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
CN113821233B (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
KR100750132B1 (ko) 부팅, 소프트웨어 자동 업데이트 및 에러 복원 방법과 그시스템, 그 방법을 기록한 컴퓨터 판독 가능한 기록매체
CN113821235B (zh) 操作系统数据更新方法、设备、存储介质及程序产品
JP4363676B2 (ja) コンピュータシステム
CN113806139B (zh) 操作系统恢复方法、设备、存储介质及计算机程序产品
CN114116023B (zh) 操作系统启动方法、设备、存储介质及计算机程序产品
CN113821221B (zh) 安装操作系统的方法、设备及存储介质
CN114461257B (zh) 操作系统数据配置方法、设备、存储介质及程序产品
WO2022262748A1 (zh) 操作系统的管理方法、设备、存储介质及计算机程序产品
CN113900673B (zh) 系统安装包的管理方法、设备、存储介质及程序产品
CN113805956B (zh) 操作系统的配置方法、设备及存储介质
CN114489813B (zh) 配置操作系统制式的方法、设备及存储介质
CN113157303A (zh) 升级方法、嵌入式系统、终端及计算机存储介质
CN113821234B (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
WO2023005371A1 (zh) 配置操作系统制式的方法、设备及存储介质
CN113467797B (zh) 程序更新方法、装置和系统以及计算机可读存储介质
CN113687851A (zh) 嵌入式设备升级方法及装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant