1.本发明涉及linux操作系统领域，特别涉及一种基于包管理的安全启动方法及计算机存储介质。
背景技术：
：：2.在linuxfoundation的支持下，给出了fhs(filehierarchystandard，文件系统层次化标准)，有众多的开发版开发者基于fhs发布了linux/gnu操作系统。但是这些发布版仅仅基于fhs给出了标准的树形管理架构，而上述架构下并不涉及文件的可靠性设计，可靠性完全交给文件系统保证。3.在这个背景下，我们经常能观察到一些异常情况下，比如正常运行时掉电，再次启动时文件系统会进行完整性检查，给出上一次关机“不干净”，需要执行fsck(filesystemcheck，文件系统检测)操作来解决文件存储出现的异常。虽然相关动作在很多情况下能够解决一些异常，但是在极端情况下，fsck无能为力。而嵌入式场景下，由于系统、应用软件通常采用烧写器写入到flash存储器中，一旦出现异常，可能需要使用编程器对flash存储器重新写操作，这对于嵌入式设备的最终用户来说是无法接受的。4.针对这个问题，对于嵌入式设备可靠性要求较高的应用场景下，常规的做法有双镜像、差异化数据存储法，均能不同程度的解决问题，但不够灵活且使用成本、管理成本均不理想。技术实现要素：5.本发明实施例提供一种基于包管理的安全启动方法及计算机存储介质，以解决相关技术中的问题。6.一方面，本发明实施例提供了一种基于包管理的安全启动方法，其特征在于，采用boot引导内核与根文件系统启动计算机系统，所述方法包括步骤：7.将一个或多个版本的计算机操作系统及对应的应用软件分解为多个软件包，并将所述软件包保存在单分区的系统区中；8.将所述多个软件包分为roofts包和非rootfs包，使所述rootfs包的内容以软链的形式指向其对应的实际文件或目录；9.通过建立软链将存储的所述软件包汇总到确定路径下的rootfs包中；10.启动时将所述rootfs包作为根文件系统完成启动。11.一些实施例中，将所述软件包保存在单分区的系统区中，包括步骤：12.对于存储受限设备，将所述软件包以未展开的包形式直接保存到指定地点；13.对于存储充裕设备，将所述软件包展开后对应存储到store目录下。14.一些实施例中，所述通过建立软链将存储的所述软件包汇总到确定路径下的rootfs包中，包括步骤：15.在硬件存储器的根目录下创建store目录；16.在所述store目录下创建pkg目录，将所述软件包在pkg目录中展开并根据所述软件包的哈希值命名所述pkg目录；17.在硬件存储器的根目录下创建boot目录，并在所述boot目录下创建指向所述rootfs包的软链。18.一些实施例中，所述在所述boot目录下创建指向所述rootfs包的软链，包括步骤：19.创建至多三个软链，所述软链分别为：指向上一次启动成功版本的rootfs包的软链rootfs_prev、指向当前使用版本的rootfs包的软链rootfs_curr以及指向下一次使用版本的rootfs包的软链rootfs_next；20.在所述boot目录下创建指向路径rootfs_curr/boot/initramfs和路径rootfs_curr/boot/kernel的软链以使设备上电时使用所述路径rootfs_curr/boot/initramfs和路径rootfs_curr/boot/kernel下的initramfs与内核。21.一些实施例中，所述启动时将所述rootfs包作为根文件系统完成启动，包括步骤：22.启动时，检查rootfs_next与rootfs_curr的一致性，若不一致则检查rootfs_next环境的完整性，并在rootfs_next环境具备完整性时基于rootfs_next启动；23.在rootfs_next环境不具备完整性时基于rootfs_curr启动；24.从rootfs_next启动失败，则保持当前rootfs_next、rootfs_curr以及rootfs_prev的值不变，并记录从rootfs_next启动失败；25.从rootfs_next启动成功，则将rootfs_prev修改为指向rootfs_curr，将rootfs_curr修改为指向rootfs_next，将rootfs_next指向null，其中null表示空。26.一些实施例中，所述启动时将所述rootfs包作为根文件系统完成启动，包括步骤：27.通过kexec引导展开到store目录下的内核；28.启动内核后在对应的initramfs中的/dev/路径下创建存储池并将外存挂载到所述存储池对应的路径中，所述存储池对应的路径为/dev/diskpools/$externaldisk。29.一些实施例中，所述启动时将所述rootfs包作为根文件系统完成启动，包括步骤：30.将rootfs_curr对应的路径/dev/diskpools/$externaldisk/store/runtime/[hash_of_rootfs]挂载到/newroot/；[0031]将/dev/diskpools/$externaldisk/store/以只读形式挂载到/newroot/store；[0032]通过switchroot动作切换到/newroot/。[0033]一些实施例中，新增软件包时，若对应新增软件为单次运行使用的，则将所述新增的软件包直接展开到内存运行；[0034]若对应新增软件在设备重启后还继续使用的，则：[0035]保存到rootfs_addon配置目录下，并在所述rootfs_addon配置目录内写入指向新增软件的软链；[0036]在rootfs_addon配置目录下创建prev、curr、next三个软链，其中prev指向上一次启动的新增软件包的软链，curr指向当前使用的新增软件包的软链，next指向下一次使用的新增软件包的软链，并使所有版本rootfs中的opt指向rootfs_addon/curr。[0037]一些实施例中，手动添加软件包时，建立软链将添加的软件包软链到所述rootfs_addon配置目录中,使软链rootfs/opt/bin/excutable_binary指向路径addon/[hash_of_rootfsx]/opt/bin/excutable_binary所在的实体文件。[0038]另一方面，本发明实施例还提供一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，其中所述计算机程序被处理器执行时，实现如权利要求1至9中任一项所述安全启动方法的步骤。[0039]本发明提供的技术方案带来的有益效果包括：通过在单分区中保存操作系统、应用软件包，操作系统及上层应用软件统一使用包的形式存储(软件包展开保存或以包的形式直接保存)，灵活方便；由于将系统拆散成为小的包独立存储，设备的实际存储空间的利用率得到大大提高。根据实际需要，可以随时增加需要软件，重启后可恢复原状，确保系统的完整性可靠性、可扩展性。附图说明[0040]为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。[0041]图1为本发明实施例提供的一种基于包管理的安全启动方法的流程示意图；具体实施方式[0042]为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。[0043]如图1所示，本发明实施例提供了一种基于包管理的安全启动方法，其特征在于，采用boot引导内核与根文件系统启动计算机系统，该方法包括步骤：[0044]s100:将一个或多个版本的计算机操作系统及对应的应用软件分解为多个软件包，并将所述软件包保存在单分区的系统区中；[0045]s200:将所述多个软件包分为roofts包和非rootfs包，使所述rootfs包的内容以软链的形式指向其对应的实际文件或目录；[0046]s300:通过建立软链将存储的所述软件包汇总到确定路径下的rootfs包中；[0047]s400:启动时将所述rootfs包作为根文件系统完成启动。[0048]需要说明的是，对于x86台式机，有使用uefi或bios的引导，继而拉起grub后引导内核及根文件系统。而本发明实施例主要是在嵌入式环境下使用uboot引导内核及根文件系统(rootfs)的过程，使用grub引导内核及根文件系统的方法相似不赘述。本发明实施例提供的基于包管理的安全启动方法，允许保存一个或多个“完整的操作系统及应用软件”版本，并提供原子操作对版本进行切换。步骤s100中，操作系统、应用软件被分解为多个存在相互依赖关系的软件包，分拆形成的软件包存在多种属性，包括：内核软件包、驱动软件包、应用软件包、热补丁软件包。各软件包内部包含详细的包描述信息，并可使用较高压缩率的压缩方案，形成压缩包。压缩包内的文件架构可基于linuxfoundation定义的fhs(filehierarchystandard)构建。[0049]可以理解的是，将软件包保存在单分区的系统区中，对于单存储器设备，分区分为boot区和系统区；部分设备有独立的boot存储器，则系统区无需分区。本发明提供的基于包管理的安全启动方法都是将操作系统、应用软件包保存在单分区中，其有益效果在于：[0050]假设存储器总体空间为64m，若采用常规镜像方案，则实际有效空间是64m/2＝32m。事实上嵌入式设备软件不会用完32m的存储区，假设整体应用软件实际占用20m空间，由于双镜像方案为了保证当前运行镜像的可靠性，只能利用非本次运行的这一半镜像的空间，实际有效利用空间为32m。有32-20＝12m的空间在当前运行镜像分区，无法使用。相较而言，本发明实施例中，由于系统区不再分区，整体存储空间不存在分割。实际整体软件占用20m，因此实际有效空间为64-20＝44，有效利用空间提高37％。[0051]步骤s200中，rootfs包是指完整的操作系统软件包，但其中所有文件替换为指向实体文件的软链，非rootfs软件包是指根据需求拆分独立发布的支持库、文件形成的文件包。[0052]本实施例中，通过在单分区中保存操作系统、应用软件包，操作系统及上层应用软件统一使用包的形式存储(软件包展开保存或以包的形式直接保存)，灵活方便；由于将系统拆散成为小的包独立存储，设备的实际存储空间的利用率得到大大提高。基于本实施例的启动方式，可根据实际情况，随时增加所需软件，重启后可恢复原状，确保系统的完整性可靠性、可扩展性。[0053]一些实施例中，s100中将所述软件包保存在单分区的系统区中，包括步骤：[0054]s110：对于存储受限设备，将所述软件包以未展开的包形式直接保存到指定地点；[0055]s120：对于存储充裕设备，将所述软件包展开后对应存储到store目录下。[0056]需要说明的是，store中允许存储同一功能软件包的多个版本的rootfs配置，便于版本切换。[0057]一些实施例中，s300包括步骤：[0058]s310:在硬件存储器的根目录下创建store目录；[0059]s320:在所述store目录下创建pkg目录，将所述软件包在pkg目录中展开并根据所述软件包的哈希值命名所述pkg目录；[0060]s330:在硬件存储器的根目录下创建boot目录，并在所述boot目录下创建指向所述rootfs包的软链。[0061]需要说明的是，允许存在多个版本分解后的rootfs包(如rootfs_1、rootfs_2等)，而rootfs包本身是一个特殊的软件包，用于描述存放于pkg目录下的其他非rootfs软件包如何使用。rootfs包本身置于pkg目录下，其内容以软链的形式指向其对应的实际文件、目录。[0062]一些实施例中，s330包括步骤：[0063]s331:创建至多三个软链，所述软链分别为：指向上一次启动成功版本的rootfs包的软链rootfs_prev、指向当前使用版本的rootfs包的软链rootfs_curr以及指向下一次使用版本的rootfs包的软链rootfs_next；[0064]s332:在所述boot目录下创建指向路径rootfs_curr/boot/initramfs和路径rootfs_curr/boot/kernel的软链以使设备上电时使用所述路径rootfs_curr/boot/initramfs和路径rootfs_curr/boot/kernel下的initramfs与内核。[0065]本实施例中，由于rootfs使用rootfs_prev、rootfs_curr、rootfs_next软链维护，操作系统升级动作转变成为rootfs软链切换动作，该动作无限接近原子操作，可最大限度防止切换升级时的异常，保证了可靠性，对于可靠性要求较高的场景下能够保证100％可靠。[0066]一些实施例中，s400包括步骤：[0067]s410:启动时，检查rootfs_next与rootfs_curr的一致性，若不一致则检查rootfs_next环境的完整性，并在rootfs_next环境具备完整性时基于rootfs_next启动；[0068]s420:在rootfs_next环境不具备完整性时基于rootfs_curr启动；[0069]s430:从rootfs_next启动失败，则保持当前rootfs_next、rootfs_curr以及rootfs_prev的值不变，并记录从rootfs_next启动失败；[0070]s440:从rootfs_next启动成功，则将rootfs_prev修改为指向rootfs_curr，将rootfs_curr修改为指向rootfs_next，将rootfs_next指向null，其中null表示空。[0071]需要说明的是，正常启动时，核对rootfs_next与rootfs_curr的一致性，若不一致，则检查rootfs_next指向的配置中对应的所有软件包的完整性(检查rootfs_next环境的完整性)，若具备完整性则从rootfs_next启动，不具备完整性则从rootfs_curr启动。若从rootfs_next启动失败，则保持指针的值不做修改，并记录从rootfs_next启动失败，记录启动失败的目的在于使随时可切换为上一个可靠的配置。[0072]需要说明的是，在需要切换系统为rootfs_prev时，可采用rollback动作，将rootfs_next的值设置为与rootfs_prev一致，然后重启设备；设备重启时，依旧基于对rootfs_next的校验启动，其启动流程可与版本升级过程一致。[0073]可优选地，boot引导一个默认版本的内核和默认版本的initramfs，这个默认的版本永远不会被修改、替换。通过默认版本的initramfs，执行前述核对rootfs_next、rootfs_curr一致性的动作，继而引导对应配置下指定的内核与rootfs(根文件系统)。[0074]需要说明的是，rootfs的引导过程，根据实际设备不同，存在一定的差异。对于存储受限设备，rootfs是在系统启动时通过配置信息(根文件系统本身的需求)构建，具体构建过程包括：校验并展开配置信息中指定的每一个包，将每一个包直接展开到tmpfs下，在tmpfs下形成基于fhs的rootfs，其中内核展开到内存中；若校验失败则切换至上一次成功启动的版本。可优选地，设置路径为/store/pkg的软链指向tmpfs，并在/store/localmirror中保存原始的软件包。通过包管理软件识别到本地配置为存储受限设备，initramfs中启动时，首先创建tmpfs及对应目录，根据rootfs配置展开对应软件包到tmpfs中，并将之挂载为/store。[0075]对于存储空间充裕设备，rootfs是基于展开的store路径下内容，通过建立软链，将所有文件汇总到一个确定路径下的“虚拟”出来的文件系统，“虚拟”出的rootfs的文件结构整体符合fhs要求。[0076]一些实施例中，s400的启动过程均包括：通过kexec引导展开到store目录下的内核；启动内核后在对应的initramfs中，在/dev/路径下创建存储池并将外存挂载到所述存储池对应的路径中，所述存储池对应的路径为/dev/diskpools/$externaldisk。[0077]需要说明的是，通过kexec引导展开到store目录下的内核，并引导与该内核相关的rootfs。[0078]一些实施例中，s400包括步骤：将rootfs_curr对应的路径/dev/diskpools/$externaldisk/store/runtime/[hash_of_rootfs]挂载到/newroot/；将/dev/diskpools/$externaldisk/store/以只读形式挂载到/newroot/store；通过switchroot动作切换到/newroot/。[0079]需要说明的是，切换到/newroot/意味着切换到工作的rootfs。使用switchroot切换rootfs，根据不同的应用场景，即存储受限设备或充裕设备，差异在于rootfs的具体位置处于内存的tmpfs中还是在固定的flash存储器(或硬盘)中。对于存储受限设备，在启动过程中，其使用的initramfs需要将pkgcache中的未展开的软件包展开到挂载为tmpfs的/store/runtime/目录；而存储充裕设备，pkgcache目录并不需要保存原始未展开的压缩包，而是将包完全展开到磁盘的/store/runtime路径下。无论存储受限、充裕设备，实际引用rootfs的实际路径均处于/store/runtime/[hash_of_rootfs]路径下。[0080]一些实施例中，s400包括步骤：启动时，将所述store目录以只读方式挂载，且挂载emmc到路径/mnt下。将store目录以只读方式挂载，确保未来更新、替换版本时可用。[0081]一些实施例中，新增软件包时，若对应新增软件为单次运行使用的，则将所述新增的软件包直接展开到内存运行；若对应新增软件在设备重启后还继续使用的，则保存到rootfs_addon配置目录下，并在所述rootfs_addon配置目录内写入指向新增软件的软链；同时在rootfs_addon配置目录下创建prev、curr、next三个软链，其中prev指向上一次启动的新增软件包的软链，curr指向当前使用的新增软件包的软链，next指向下一次使用的新增软件包的软链，并使所有版本rootfs中的opt指向rootfs_addon/curr。[0082]可以理解的是，可开发管理软件包的软件，管理软件包的增删，对于存储受限设备，灌入的软件包以软件包的形式直接保存到指定地点；对于存储充裕设备，灌入的软件包展开，将对应的软件包灌入store目录下存储。可以理解的是，无论存储受限与否，工具均需要管理前文所述的rootfs_prev、rootfs_curr、rootfs_next三个软链所指向的rootfs目录，以此来确定软件包应该如何使用。[0083]可以理解的是，新增软件包时，对管理软件包的软件下达新增软件包的指令，对于新增软件包的属性不同，下达的指令可以有一定差异，是否重启后还可使用取决于实际产品的需求。新增软件为单次运行使用是指当次运行生效，设备重启后就不再使用的情况，这种情况下，对应的软件包直接展开到内存中，然后直接运行即可；新增软件设备重启后还继续使用的，则将新增的软件包保存rootfs_addon配置。在rootfs中的opt总是指向rootfs_addon/curr，实际使用时，新安装的二进制工具在以下路径($tools指代新安装的二进制)：[rootfs]/opt/bin/$tools。[0084]一些实施例中，可根据实际需要，随时增加需要软件，可选择永久保留或重启恢复原状，确保系统的完整性可靠性的同时，确保可扩展性。[0085]一些实施例中，手动添加软件包时，建立软链将添加的软件包软链到所述rootfs_addon配置目录中，使软链rootfs/opt/bin/excutable_binary指向路径addon/[hash_of_rootfsx]/opt/bin/excutable_binary所在的实体文件。[0086]需要说明的是，其中excutable_binary是指向.../store/[hash_of_pkg]/bin/excutable_binary这个实体文件的软链。在具体的rootfs中，还创建了一个/opt指向.../addon/[hash_of_rootfsx]/opt，可以理解的是，其他类型文件如配置文件、各类资源文件可依此方式类推。[0087]一些实施例中，系统启动、升级成功后，将store目录的路径设置为只读。[0088]一些实施例中，将emmc挂载到/def/diskpool/emmc[0089]其根目录下创建store目录的方式如下：[0090]/dev/diskpool/emmc/store/pkg/[hash_of_package_1.0][0091]/dev/diskpool/emmc/store/pkg/[hash_of_package_1.1][0092]/dev/diskpool/emmc/store/pkg/[hash_of_package_2.0][0093]/dev/diskpool/emmc/store/pkg/[hash_of_package_3.0][0094]/dev/diskpool/emmc/store/pkg/[hash_of_package_3.1][0095]/dev/diskpool/emmc/store/pkg/[hash_of_package_n.0][0096]/dev/diskpool/emmc/store/pkg/[hash_of_rootfs_1.0][0097]/dev/diskpool/emmc/store/pkg/[hash_of_rootfs_2.0][0098]/dev/diskpool/emmc/boot/rootfs_curr-》/store/pkg/[hash_of_rootfs_1.0][0099]/dev/diskpool/emmc/boot/rootfs_next-》/store/pkg/[hash_of_rootfs_2.0][0100]/dev/diskpool/emmc/rootfs_addon/[hash_of_rootfs_1.0]/curr[0101]/dev/diskpool/emmc/rootfs_addon/[hash_of_rootfs_2.0]/curr[0102]其中，可以理解的是，hash_of_package_1.0是指版本为1.0的软件包hash_of_rootfs_1.0是指版本为1.0的rootfs文件。[0103]一些实施例中，一个版本的rootfs(rootfs1)内，其内容包括：[0104]bin/file1-》/store/pkg/[hash_of_pkg_1.0]/bin/file1[0105]lib/libfile1.so-》/store/pkg/[hash_of_pkg_1.0]/lib/libfile1.so[0106]usr/lib/libfile1.so-》/store/pkg/[hash_of_pkg_1.0]/usr/lib/libfile1.so[0107]bin/file2-》/store/pkg/[hash_of_pkg_2.0]/bin/file2[0108]另一个版本的rootfs(rootfs2)内容包括：[0109]/bin/file1-》/store/pkg/[hash_of_pkg_1.1]/bin/file1[0110]/lib/libfile1.so-》/store/pkg/[hash_of_pkg_1.1]/lib/libfile1.so[0111]/usr/lib/libfile1.so-》/store/pkg/[hash_of_pkg_1.1]/usr/lib/libfile1.so[0112]/bin/file2-》/store/pkg/[hash_of_pkg_2.1]/bin/file2[0113]rootfs挂载到/newroot下后，/newroot下创建/boot，并将emmc中的boot目录使用mount‑‑bind方法挂载到该目录，则有下面路径：[0114]/newroot/boot/rootfs_curr-》[hash_of_rootfs_1.0][0115]/newroot/boot/rootfs_curr-》[hash_of_rootfs_2.0][0116]/newroot/boot/rootfs_addon/[hash_of_rootfs_1.0]/curr[0117]/newroot/boot/rootfs_addon/[hash_of_rootfs_2.0]/curr[0118]在一个具体的实施例中，涉及针对存储充裕设备的实施过程。本实施例中使用的环境为arm64位cpu，启动使用u-boot，外存为4g的emmc。[0119]首先，使用ipk进行软件包构建，在ipk软件包的基础上，在包内增加对软件包的进一步描述，说明本软件包的用途。外存emmc格式化为一个ext4分区，使用orderd方式挂载以保证可靠性。[0120]然后，在emmc根目录下创建store目录，并在store下创建pkg目录；将所需要的软件包展开，目录名为该软件包的哈希值；其中，有一个或多个特殊的包，是rootfs目录，其下的子目录为某一个完整的rootfs(该rootfs中所有的文件、目录)，目录名依然为该软件包的哈希值，其内部的文件是以软链的形式指向其对应的实际文件、目录。[0121]在emmc根目录下创建boot目录，该目录下创建至多三个软链分别是roofs_prev、roofs_curr、roofs_next，需要注意的是在首次系统构建时，并不需要创建roofs_prev和roofs_next两个软链,在设备多次更新系统rootfs配置后，才会存在roofs_prev和roofs_next软链。软链指向前文中所述pkg下rootfs的哈希值目录。[0122]boot目录下，继续创建initramfs、kernel的软链，分别指向rootfs_curr/boot/initramfs，rootfs_curr/boot/kernel；这个路径下的initramfs与内核是在设备上电时使用的。将软链指向roofs_curr中对应内容，可在磁盘存在新写入数据不完整的情况下，永远从上一次可正常加载的环境启动。[0123]在加载的initramfs中检查rootfs_curr与rootfs_next的关系，如果rootfs_next与rootfs_curr不同(不一致)，检查rootfs_next环境的完整性(检查rootfs_next指向的配置中对应的所有软件包的完整性)，若完整则使用kexec启动一个全新的基于rootfs_next的环境；若不完整则直接基于rootfs_curr启动。无论基于哪个rootfs启动，启动内核后，做switchroot操作，切换到正式工作的rootfs下。[0124]在还处于initramfs环境中时，挂载emmc到/dev/diskpool/emmc/。switchroot操作前，emmc同样挂载到/newroot/dev/diskpool/emmc下，并使用mount‑‑bind-oro方法(只读挂载)：[0125]将/newroot/dev/diskpool/emmc/store挂载到/newroot/store；[0126]将/newroot/dev/diskpool/emmc/boot挂载到/newroot/boot；[0127]在switchroot操作后，在新的rootfs中也能够基于/store访问到前面多个步骤中列出的相关目录：处于emmc根目录的boot目录；处于emmc根目录的store目录。[0128]开发的包管理软件支持将软件包展开到当前使用的根文件系统的/store目录下(实际/store对应的物理路径是前文提及的/dev/diskpool/emmc/store)。[0129]在设备首次生产时，由boot将初始initramfs拉到本地后，由该initramfs中的包管理软件根据初始rootfs，将对应软件包拉到本地并展开，展开是以对应软件包的哈希值为目录名，展开完成后对包中所有文件做校验。每一个包中的所有文件校验正确后，才做下一个包的展开动作，确保每一个文件的正确写入。需要注意的是，rootfs本身也是一个特殊软件包，正式使用的rootfs由包管理软件在独立的/boot/下创建的rootfs_curr软链，指向/store/pkg/下对应的哈希目录名的rootfs。[0130]所有文件准备好以后，才建立rootfs_curr软链指向前述roofs配置目录下的软链出的目录、建立/boot下指向kernel、initramfs的软链。首次生产的时候不建立rootfs_prev以及rootfs_next目录。[0131]在设备软件更新时，包管理软件从指定的升级源中抓取rootfs，并基于上述配置拉取相关的包，如果存在哈希值相同的则表明本地已经存在对应的包，无需重新拉取；找不到相同的哈希值时，拉取到本地并展开。与设备首次生产时相同，所有文件成功后建立软链，rootfs_next指向本次的rootfs哈希值目录；[0132]在设备启动时，boot从emmc的/boot目录下获得kernel和initramfs并加载，加载后挂载emmc到/dev/diskpool/emmc/，并根据前文所述挂载store、boot等路径到/newroot下，继而开始校验和比对rootfs_curr与rootfs_next软链，不存在rootfs_next时，认为是普通的启动，进行switchroot操作进入到最终的完整rootfs即可；若存在rootfs_next，并与rootfs_curr不相同，认为是升级后的首次启动，使用kexec加载rootfs_next中指定的内核，使用switchroot切换到rootfs_next中指定的rootfs即可。在设备启动过程中，如果出现异常掉电重启，因本次emmc中的数据未做任何改变，下次启动依然符合上述启动流程。[0133]启动完成后，由包管理软件接管，开始对本地的配置进行检查，存在以下情况：若仅存在rootfs_curr，表示为干净的正常启动，不做任何动作；若存在rootfs_next，并与rootfs_curr不相同，认为是升级后的首次启动。此时，执行下面三个动作，将rootfs_curr软链拷贝一份为curr_backup；将rootfs_next文件名修改为rootfs_curr；将curr_backup修改为rootfs_prev。[0134]若在这个过程中出现异常掉电，导致上述动作没有完成，可能以下异常：若有curr_backup冗余文件以及rootfs_next文件，则表明是在备份完成rootfs_curr后、修改rootfs_next前出现的异常，由于rootfs_curr还存在，系统可正常启动，后续的修改可照常进行。若有curr_backup冗余文件也有rootfs_curr文件，但没有rootfs_next文件，则表明是在rootfs_next文件修改为rootfs_curr后、curr_backup文件还未修改为rootfs_prev时出现的异常，由于rootfs_next已经修改为rootfs_curr了，本次系统也已正常启动，后续修改可照常进行。从上述情况看，无论何时出现异常，均能够正常工作。[0135]新增软件包时，在/boot/rootfs_addon/路径下，创建当前rootfs目录哈希值为目录名的目录，并建立/opt软链指向之。在rootfs中/opt软链有效时，表示当前rootfs“被修改”并非默认rootfs，不是工程原始发布版本，便于问题排查与跟踪。[0136]手动添加的软件包时，通过与维护rootfs一致的方法，将所有文件软链到到上述rootfs_addon/[hash_of_rootfsx]中使用。本实施例中，addon路径处于emmc存储区，软件安装完成后二次依然可用。如仅需当前环境临时使用，addon路径可定制在/dev/shm或tmpfs中，以使下次启动对应软链不生效，软件不工作，可确保初始发布软件的完整性。[0137]考虑到/store、/boot是只读挂载的，在系统正常运行时，上述路径下所有的内容不可被更改，保证了设备的可靠性。[0138]在需要更新或新增软件包时，需要再次挂载解开/store、/boot的只读挂载，通过重复挂载自己，但增加rw属性，其中$targetdir为/store、/boot：[0139]mount‑‑bind-orw$targetdir$targetdir[0140]在修改、更新完成后，需要解除上述挂载：[0141]umount$targetdir[0142]本发明实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，其中所述计算机程序被处理器执行时，可实现前述实施例中所提到的安全启动方法的步骤。本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤可以被实施为软件、固件、硬件及其适当的组合。这样的软件可以分布在计算机可读存储介质上，计算机可读存储介质可以包括计算机可读存储介质(或非暂时性介质)和通信介质(或暂时性介质)。[0143]以上所述仅是本发明的具体实施方式，使本领域技术人员能够理解或实现本发明。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。当前第1页12当前第1页12