一种Linux系统下基于细粒度系统状态检测的升级方法与流程

本申请属于linux系统升级技术领域，具体地说，涉及一种linux系统下基于细粒度系统状态检测的升级方法。

背景技术：

随着终端设备的不断更新，操作系统的不断完善，终端设备每隔一段时间就需要进行一次系统的升级。目前主流操作系统升级方法是：将最新的升级包放在升级服务器，终端设备如果检测到有新的系统版本，则会提示用户升级，待用户确认后，将从升级服务器下载最新的升级包进行升级。

这种常规升级方法存在以下不足：

(1)不同于windows将系统关键组件和用户软件分别处理，linux系统关键组件和普通软件是以同一种形态存在的，即软件包。而因为软件包之间的复杂依赖关系，用户在安装、卸载、升级软件包时可能会直接或间接地影响系统关键组件。此时，安装固定不变的系统升级包可能对系统已经不起作用，甚至导致系统混乱。这也是升级linux系统经常出现异常问题的原因；

(2)在实际应用中，面对不同的客户和使用环境，操作系统会衍生出不同的类型、分支、版本、甚至体系结构，面对这四种情况，所需要的升级包也各不相同，手动制作升级包、手动匹配终端和升级服务器都会产生巨大的工作量；

(3)常规方法只能统一将操作系统升级到固定的最新版本，无法选择升级到一个中间状态。

中国发明专利“一种linux操作系统及其安全升级方法”(申请号cn102662647a)，该发明通过对所要升级的计算机进行保密级别的判断并通过可移动存储介质来进行升级，克服了在断网或计算机要求保密的情况下操作系统无法升级的技术问题，达到了对操作系统进行安全升级的目的。和本专利区别：本专利是一种linux系统下基于细粒度系统状态检测的升级方法，专利方向不一样。

中国发明专利“系统升级方法及装置”(申请号cn105242945a)，该发明升级过程对用户终端存储的升级准则进行查询，并对比服务器的升级准则，若满足升级条件就对用户系统进行升级。和发明区别：本发明会对系统状态、软件包状态和配置文件状态进行检测及进行软件包冲突判断，且能对于不同项目和应用场景的操作系统，可自动区分，各项目拥有自己的版本状态和升级路线，可选择升级到路线中任意可用的版本状态。

中国发明专利“一种智能终端的系统升级方法及装置”(申请号cn105045671a)，该发明获取已连接智能终端的存储容量值；将所述获取的存储容量值与系统升级包适用的智能终端的存储容量值进行匹配；如果匹配成功，则向所述已连接智能终端发送所述系统升级包进行升级。和本发明区别：本发明会对系统状态、软件包状态和配置文件状态进行检测及进行软件包冲突判断，且能对于不同项目和应用场景的操作系统，可自动区分，各项目拥有自己的版本状态和升级路线，可选择升级到路线中任意可用的版本状态。

中国发明专利“一种unix环境软件系统升级方法”(申请号cn105117263a)，该发明为升级包预先建立目录结构，根据所有应用服务器中两两之间的配置差异建立规则映射表，然后将该规则映射表预先存储至所有应用服务器内，综合规则映射表将安装成功的升级包适用到其他应用服务器上，完成所有应用服务器完成自适应升级包的安装部署。和本发明区别：本发明是一种linux系统下基于细粒度系统状态检测的升级方法，专利方向不一样。

中国发明专利“终端系统升级方法、装置及服务器”(申请号cn104778057a)，该发明接收终端发送的版本升级请求；根据当前系统版本和用户标识，确定终端的待升级版本；检测是否存储了待升级版本与当前系统版本之间的差分包；如果未存储差分包，则将待升级版本的大包和当前系统版本的大包进行差分处理，得到差分包；将差分包下发至终端，终端用于根据差分包进行系统升级。和本发明区别：本发明会对系统状态、软件包状态和配置文件状态进行检测及进行软件包冲突判断，且能对于不同项目和应用场景的操作系统，可自动区分，各项目拥有自己的版本状态和升级路线，可选择升级到路线中任意可用的版本状态。

中国发明专利“一种终端更新系统及其更新方法”(申请号cn104572212a，该发明主要通过更新配置文件1与本地更新配置文件0、本地临时更新配置文件l比较确定需要下载的文件列表，然后根据文件列表下载需要更新文件。和本发明区别：本发明是一种linux系统下基于细粒度系统状态检测的升级方法，专利方向不一样。

技术实现要素：

有鉴于此，本申请为了解决现有技术存在的缺陷和不足，提供了一种linux系统下基于细粒度系统状态检测的升级方法，以解决传统操作系统升级可能产生的版本混乱等问题。

为了解决上述技术问题，本申请公开了一种linux系统下基于细粒度系统状态检测的升级方法，并采用以下技术方案来实现。

一种linux系统下基于细粒度系统状态检测的升级方法，步骤包括：s1：生成带有当前系统完整状态的升级校验文件；

s2：根据所述升级校验文件计算出可升级版本；

s3：从所述可升级版本中选择需要升级的目标版本；

s4：计算出升级列表，进行包冲突判断；

s5：生成静态升级文件；

s6：将所述静态升级文件和升级到所述目标版本需要用到的指令执行程序打包成升级包，并进行版本升级。

进一步的，所述升级校验文件基于客户端对系统状态进行细粒度检测而生成，所述细粒度检测的内容包括：

a)用户系统认证信息：若未经授权或激活，则停止升级程序；

b)出库序列号：若无所述出库序列号或所述出库序列号在数据库中无记录则停止升级程序；

c)系统版本号：用于定位所述用户系统版本所属项目和/或历史节点；

d)系统架构：用于定位所述用户系统版本的可升级版本；

e)软件包列表：用于在选定所述目标版本后进行包列表对比。

进一步的，所述升级校验文件生成的具体步骤包括：

s11：获取未生成的校验文件；

s12：检测用户系统的出库序列号是否为空，若不为空则查询数据库看是否记录在案，否则不予升级；

s13：检测出库版本，若验证出库版本为非正常出库版本，则停止生成校验文件，进入s11；否则进入下一步；

s14：检测用户授权文件是否完整，若完整则进入下一步，若不完整或系统未进行激活认证，则不予升级；

s15：判断所述系统是否被授权或被激活，若未授权或未激活，则停止生成校验文件，进入s11；否则进入下一步；

s16：获取系统版本号、系统架构和/或已安装包列表；

s17：将获取到的所述系统版本号、所述系统架构及所述已安装包列表整合成升级校验文件。

进一步的，所述包冲突判断的判断步骤包括：s41：第一次包冲突判断：将所述升级校验文件与所述目标版本进行包列表和包版本的包冲突判断，得出升级安装包列表；s42：第二次包冲突判断：将所述需要升级安装包列表与当前系统版本中已安装包列表进行包冲突判断。

更进一步的，所述包冲突判断的判断步骤还包括：s43：所述包冲突判断结果若为存在冲突包，则无法正常升级，选择放弃升级或自动卸载所述冲突包；若卸载所述冲突包则并继续升级到所述目标版本；若继续升级，将会保持所述目标版本的包完整性。

再进一步的，判断已安装包与被列入所述升级安装包列表的包是否存在相容性冲突；判断已安装包的依赖包或库的版本，与被列入所述升级安装包列表的包所依赖的包或库是否存在版本冲突。

进一步的，所述s2的具体内容为：根据所述升级校验文件中的系统版本号和架构查询数据库，通过架构信息定位所述系统对应的位数，再通过所述系统版本号定位所述系统所属项目和/或版本系列，最终根据所述系统版本号得出在版本系统中的节点位置，确定所述可升级版本。

一种基于细粒度状态检测的系统，包括：

客户端(101)：检测当前操作系统的信息，对检测的所述信息进行整合及格式处理生成升级校验文件，将所述升级校验文件发送给处理中心(102)；接收所述处理中心(102)发来的可升级版本供选择，并将选择的目标版本发送给所述处理中心(102)，接收所述处理中心(102)生成的升级包进行安装升级；

所述处理中心(102)：接收所述客户端(101)发送的所述升级校验文件，根据所述校验文件匹配数据库(103)中的信息，得出所述可升级版本的集合并发送给所述客户端(101)；并根据所述目标版本生成升级包发送给所述客户端(101)；

和数据库(103)：用于保存所有系统架构、项目、系统版本、包列表信息，供所述处理中心(102)进行查询和获取。

一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现以上任一所述升级方法的步骤。

一种基于细粒度状态检测的升级装置，包括存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以上任一所述升级方法的步骤。

与现有技术相比，本申请可以获得包括以下技术效果：对操作系统整体状态进行细粒度判断，生成的升级校验文件更可靠；排除冲突后精细化生成升级包，确保各种状态的操作系统都可以安全统一的升级到规定的版本状态；对于不同项目和应用场景的操作系统，可自动区分，各项目拥有自己的版本状态和升级路线，可选择升级到路线中任意可用的版本状态。

当然，实施本申请的任一产品必不一定需要同时达到以上所述的所有技术效果。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是本申请一个实施例的整体架构示意图。

图2是本申请一个实施例的主流程示意图。

图3是本申请一个实施例的用户升级校验文件生成过程。

具体实施方式

以下将配合附图及实施例来详细说明本申请的实施方式，藉此对本申请如何应用技术手段来解决技术问题并达成技术功效的实现过程能充分理解并据以实施。

图1示出本发明实施例整体架构示意图，主要包含客户端101、处理中心102和数据库103三部分。

客户端101检测用户系统的版本信息、包信息等，对检测的信息进行整合及格式处理生成校验文件，将校验文件发送给处理中心102。

客户端101接收处理中心102分析得出的可升级版本供用户选择，并将用户选择好的目标版本发送给处理中心102，接收处理中心102最终生成的升级包进行安装升级。

客户端101通过http协议与处理中心102进行通信和文件传输，包括校验文件、可升级版本信息交互及最终升级包传输。

处理中心102接收客户端101发送的校验文件，根据校验文件匹配数据库103中各项目版本信息，得出可升级版本节点的集合并发送给客户端101。

处理中心102接收用户选择的目标版本后，根据校验文件中的包列表信息计算出升级到目标版本需要新安装的包列表、升级的包列表，及处理脚本，将以上静态升级文件和预存的指令执行程序打包成最终升级使用的安装包发给客户端101。

数据库103保存所有系统架构、项目、系统版本、包列表等信息，给处理中心102提供信息查询和获取。

图2示出本发明实施例主流程示意图，展示了基于细粒度系统状态检测的升级技术的主要过程。

一种linux系统下基于细粒度系统状态检测的升级方法，步骤包括：

s1：用户系统客户端对系统状态进行细粒度检测，通过检测生成带有系统完整状态的升级校验文件，升级校验文件内容按一定的格式约定并能直接被处理中心的脚本读取及分析；

s2：处理中心数据库保存和组织了各类项目系统的版本形态，处理中心根据客户端生成的升级校验文件，与数据库中各类项目系统的版本进行对比，计算出用户系统版本可升级的节点集合供用户选择，若用户已经是最新版本，则将提示用户版本已是最新状态；

s3：在用户选择目标版本后，处理中心读取数据库中该目标版本的包列表，与用户系统的校验文件中包列表进行对比，计算出目前用户系统状态升级到目标版本需增量安装和需升级的包列表，两者统称为升级包列表；同时将升级包列表与用户系统原有包列表进行包冲突判断，防止因包版本或包依赖冲突而导致升级失败；

s4：在冲突判断后，处理中心根据生成的包列表拉取相关静态升级文件及升级到目标版本需要用到的指令执行程序，将二者打包成最终版本升级使用的安装包(即升级包)，发送给客户端进行安装升级。

以上4步的具体步骤如图2所示，包括：

s201：利用当前系统版本，获取用户系统升级前的状态；

s202：启动客户端；当用户需要进行升级时，运行客户端软件即可开始检测系统状态；

s203：检测系统状态生成升级校验文件；

用户系统客户端对系统状态进行细粒度检测，通过检测生成带有系统完整状态的校验文件。

系统状态的细粒度检测，可通过指令或直接查看系统文件获取，检测内容包括：

a)用户系统认证信息(即版本的授权激活)：若都未经授权或激活，将停止升级程序；

b)出库序列号：若无出库序列号或序列号在处理中心库中无记录则视为盗版，将停止升级程序；

c)系统版本号：用于定位用户系统版本所属项目及历史节点；

d)系统架构：用于定位用户系统版本可升级版本；

e)软件包列表：用于用户选定升级的目标版本后进行包列表对比。

然后，校验文件的生成需要：检测出库序列号、检测版本授权激活、获取系统版本号、获取架构及包列表等步骤；根据约定格式对内容进行处理，最后整合成处理中心脚本能直接读取和分析的升级校验文件，用于之后的升级节点定位，获取具体步骤如图3所示：

s301：获取未生成的校验文件；

s302：检测用户系统的出库序列号是否为空，若不为空则发送给处理中心查询数据库看是否记录在案，否则视为盗版不予升级；

s303：如果经过验证为非正常出库版本，将停止生成校验文件，进入步骤301；否则继续检测流程，进入下一步；

s304：检测用户授权文件是否完整，若完整则进一步检测用户系统是否已经激活，若授权文件内容不完整或系统未进行激活认证都不予升级；

s305：判断系统是否被授权或被激活，如果检测出系统未授权或未进行系统激活，将停止生成校验文件，进入步骤301；否则，继续检测流程，进入下一步；

s306：通过指令或查询系统文件，获取系统版本号和系统架构，例如在ubuntu系统中，可通过命令行lsb_release-a或查看/etc/lsb-release文件查询相关信息。通过指令获取系统已安装包列表，例如在ubuntu系统中，可通过dpkg-l来获取系统中的包列表及这些包的版本号，定向输出到文件后再根据约定进行格式调整及删除非必须的信息；

s307：将获取到的系统版本号、系统架构及包列表整合成升级校验文件发送给处理中心。

以上7步生成升级校验文件。

s204：判断是否符合升级条件，如果不符合则停止升级，进入步骤201；否则继续升级流程，进入下一步；判断是否符合升级条件具体是对系统状态进行判断，例如出库序列号、版本授权激活等检测；

s205：处理中心根据升级校验文件中的系统版本号和架构查询数据库，通过架构信息定位是x86还是arm版本，是64位还是32位系统，再通过版本号定位用户系统所属项目、版本系列等，最终根据版本号得出在版本系统中的节点位置，确定可升级版本后返回给用户选择；

s206：判断是否有可升级版本，如果处理中心计算出用户系统为最新版本，则提示用户系统为最新版本无需升级，进入步骤201；否则进入下一步；

s207：用户选择目标升级版本；将可升级版本的集合提供给用户选择，用户勾选自己想要升级到的节点版本提交给处理中心用于生成升级包；

在用户选择目标版本后，处理中心读取数据库中该目标版本的包列表，与用户系统的校验文件中包列表进行对比，计算出目前用户系统状态升级到目标版本需增量安装和升级的包列表。

s208：进行包冲突判断并生成静态升级文件；

通过脚本用升级校验文件中的包列表及包版本号与数据库中目标版本的包列表及包版本号进行增量对比，计算出目标版本比校验文件中包列表多的包为需要安装的，目标版本比校验文件中版本高的包为需要升级的，从而得出升级到目标版本需要额外安装及升级的包列表。

用户升级校验文件与目标版本包列表和包版本对比具体步骤包括：

a)目标系统相对用户系统新增的包，将被列入“增量安装包列表”；

b)目标系统比用户系统包版本更高的包，将被列入“版本升级包列表”；

c)用户系统相对目标系统额外的包，将需要与上述被列入“增量安装包列表”的包进行冲突判断。

经以上对比，得出升级安装包列表后，还需与用户目前版本中已安装的包进行包冲突判断，因为用户可能在系统使用中自己安装了不少包，这些包有可能会与升级到目标版本需要额外安装的包有依赖冲突问题，包冲突判断可以防止因包版本或包依赖冲突而导致升级失败。

再次对比校验文件包列表和目标版本包列表，得出校验文件包列表比目标版本中多的包，这些包即是用户使用时另外安装的包及老版本到目标版本剔除的包(这部分包肯定不会与目标版本有冲突问题)，得出用户额外安装的包后，与系统升级需要额外安装的包进行包冲突判断。例如在ubuntu系统中可通过脚本对比包中的“conflicts”信息，检测是否存在依赖冲突的包，软件包的“conflicts”信息可通过命令行：apt-cacheshow接包名，通过显示包信息即可查看，也可从源码中control文件查看，以上对比和处理都可通过脚本自动化完成，若无冲突，将得到静态升级文件包。

本步骤的第二次包冲突判断的内容包括：

a)判断用户已安装包与被列入增量安装包列表的包是否存在相容性冲突，即是否为不能共存包；

b)判断用户已安装包的依赖包或库的版本，与被列入增量安装包列表的包所依赖的包或库是否存在版本冲突，例如原有包依赖低版本的库，而升级需安装的包依赖高版本的同一个库，则将会导致版本冲突。

s209：判断当前系统是否存在与系统冲突的包，如果存在冲突包，则提示给用户冲突包名，用户可选择放弃升级，返回步骤201；否则会自动卸载系统上的冲突包，并进入下一步；

用户自己安装过的包与升级到目标系统需增量安装的包若存在s208中两种冲突中任意一种，将会无法正常升级，提示给用户冲突包名，用户可选择放弃升级或自动卸载系统上的冲突包并继续升级到目标系统；若继续升级，将会以保持目标系统包完整性为主。

s210：加入指令执行程序，生成升级包；

指令执行程序主要包括：包的升级安装指令和部分包的特殊处理指令。若升级到目标版本中的包存在需要特殊处理的，如有些包不能覆盖安装，需要先卸载后安装；有些包安装完后需要进行特殊配置等。这些特殊处理脚本将会和目标版本一起保存在数据库中，当需要升级到某个版本时，将数据库中保存的指令文件路径下对应脚本加入到升级包中即可，最终将静态升级文件和指令执行程序打包成升级包发送给用户进行升级；

s211：运行升级包，将系统升级到目标系统；客户端收到处理中心的升级包后直接运行进行系统升级，升级界面将会自动引导用户完成升级。

本申请的有益效果是：对操作系统整体状态进行细粒度判断，生成的升级校验文件更可靠；排除冲突后精细化生成升级包，确保各种状态的操作系统都可以安全统一的升级到规定的版本状态；对于不同项目和应用场景的操作系统，可自动区分，各项目拥有自己的版本状态和升级路线，可选择升级到路线中任意可用的版本状态。

以上对本申请实施例所提供的一种linux系统下基于细粒度系统状态检测的升级方法，进行了详细介绍。以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

如在说明书及权利要求当中使用了某些词汇来指称特定组件。本领域技术人员应可理解，不同机构可能会用不同名词来称呼同一个组件。本说明书及权利要求并不以名称的差异来作为区分组件的方式，而是以组件在功能上的差异来作为区分的准则。如在通篇说明书及权利要求当中所提及的“包含”为一开放式用语，故应解释成“包含但不限定于”。“大致”是指在可接收的误差范围内，本领域技术人员能够在一定误差范围内解决所述技术问题，基本达到所述技术效果。说明书后续描述为实施本申请的较佳实施方式，然所述描述乃以说明本申请的一般原则为目的，并非用以限定本申请的范围。本申请的保护范围当视所附权利要求所界定者为准。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的商品或者系统不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种商品或者系统所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的商品或者系统中还存在另外的相同要素。

上述说明示出并描述了本申请的若干优选实施例，但如前所述，应当理解本申请并非局限于本文所披露的形式，不应看作是对其他实施例的排除，而可用于各种其他组合、修改和环境，并能够在本文所述发明创造构想范围内，通过上述教导或相关领域的技术或知识进行改动。而本领域人员所进行的改动和变化不脱离本申请的精神和范围，则都应在本申请所附权利要求的保护范围内。