CN117707629B

CN117707629B - System startup method, readable storage medium and electronic device

Info

Publication number: CN117707629B
Application number: CN202311000387.6A
Authority: CN
Inventors: 高明
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2023-08-09
Filing date: 2023-08-09
Publication date: 2024-08-30
Anticipated expiration: 2043-08-09
Also published as: CN117707629A

Abstract

The application relates to the technical field of terminals, and discloses a system starting method, a readable storage medium and electronic equipment. When the electronic equipment fails to mount the data partition through the preset mounting parameters in the process of starting the operating system, the electronic equipment can re-mount the data partition by utilizing the mounting parameters which are supported by the file system corresponding to the data partition and are different from the preset mounting parameters. After the electronic equipment successfully mounts the data partition by using the mounting parameters different from the preset mounting parameters, continuing the starting flow of the operating system of the electronic equipment. Therefore, under the condition that the damaged or faulty part of the storage medium of the electronic equipment storing the data partition is only related to part of the mounting parameters, the electronic equipment can still mount the data partition, so that an operating system of the electronic equipment can be normally started, and the electronic equipment can be normally started.

Description

System startup method, readable storage medium, and electronic device

Technical Field

The present application relates to the field of terminal technologies, and in particular, to a system startup method, a readable storage medium, and an electronic device.

Background

The boot process of an operating system of an electronic device typically includes a Bootloader (Bootloader) phase, a kernel (kernel) phase, an initialization (init) phase, a process incubator (zygote) phase, a system services (SYSTEM SERVER) phase, and a desktop launcher (desktop) phase. In the init phase, the electronic device may mount different partitions, such as a system partition, a data partition, and so on, so as to load data in a subsequent phase.

In some scenarios, if there is a failure in the memory of the electronic device, such as a corruption, abnormality, etc. of the storage medium used to store the data partition, the electronic device may fail to load the data partition. Thus, the electronic device may not enter the subsequent stage, and the operating system of the electronic device may not be started normally.

Disclosure of Invention

In view of this, the present application provides a system startup method, a readable storage medium, and an electronic device.

In a first aspect, the present application provides a system startup method, where an electronic device includes a data partition; and the method comprises the following steps: mounting a data partition based on N mounting parameters in the starting process of an operating system of the electronic equipment, wherein the mounting parameters are mounting parameters corresponding to a file system of the data partition, and N is an integer greater than 1; mounting the data partition based on N mounting parameters fails, and mounting the data partition based on N-K mounting parameters, wherein K is a natural number and is smaller than N; and after the data partition is successfully mounted based on the N-K mounting parameters, operating the desktop starter.

According to the method, in the starting process of the operating system of the electronic equipment, after the data partition is mounted based on the N mounting parameters, the data partition can be re-mounted based on the N-K mounting parameters. And operating the desktop starter after the data partition is successfully mounted based on the N-K mounting parameters. Thus, if the damaged or failed portion of the storage partition medium in the electronic device is only related to a portion of the mounting parameters, the electronic device may still be started up normally.

Alternatively, if the electronic device is successful in mounting the data partition based on the N mounting parameters, the process incubator, the system service process, and the desktop initiator may be run.

In a possible implementation manner of the first aspect, the mounting data partition based on N-K mounting parameters includes: and selecting N-K mounting parameters from the N mounting parameters, and mounting the data partition based on the N-K mounting parameters.

In a possible implementation of the first aspect, the method further includes: and mounting the data partition based on the N-K mounting parameters and failing to mount the data partition based on the N-K-1 mounting parameters.

That is, if the electronic device fails to mount the data partition based on the N-K mount parameters, the mount parameters may also be continuously reduced to mount the data partition. If the mounting data partition is successful, the operating system of the electronic device can be continuously started. If the data partition can not be successfully mounted without mounting any mounting parameters, the starting of the operating system of the electronic equipment fails.

In one possible implementation of the first aspect, after the mounting of the data partition based on the N-K mounting parameters is successful, operating a desktop starter includes: and after the N-K mounting parameters are successfully partitioned, running a process incubator, a system service process and a desktop starter.

That is, the boot process of the operating system of the electronic device may include mounting a data partition, running a process incubator, a system service process, and a desktop launcher. After the data partition is successfully mounted, the electronic equipment can operate a process incubator, a system service process and a desktop starter.

In a possible implementation of the first aspect, the method further includes: in the process of running the process incubator, the system service process and the desktop starter, the starting of the operating system is incomplete; the method comprises the steps that based on incomplete starting of an operating system, data partitions are mounted on the basis of N-P mounting parameters, wherein P is greater than or equal to K, and at least one mounting parameter in the N-K mounting parameters is different from one mounting parameter in the N-P mounting parameters; and after the data partition is successfully mounted based on the N-P mounting parameters, a process incubator, a system service process and a desktop starter are operated.

That is, if the data partition is successfully mounted based on the N-K mounting parameters, but the operating system of the electronic device fails to be started in the processes of the run-time incubator, the system service process and the desktop starter, the electronic device may further re-mount the data partition using N-P mounting parameters different from the N-K mounting parameters. And after the data partition is successfully mounted based on the N-P mounting parameters, the process incubator, the system service process and the desktop starter are restarted. In this way, the possibility of the operating system of the electronic device to start functions can be further improved.

In a possible implementation of the first aspect, the method further includes: and starting the virtual machine of the operating system in the process of running the process incubator.

In a possible implementation of the first aspect, the method further includes: in the process of running the system service process, the service of the operating system is started.

In a possible implementation of the first aspect, the method further includes: in the process of running the desktop initiator, a finishBooting function is called to set the flag bit sys.boot_ completed to be valid based on the completion of operating system startup.

In some implementations, the flag bit sys.boot_ completed, when valid, is used to indicate that the operating system boot is complete.

In a possible implementation of the first aspect, the method further includes: after the data partition is successfully mounted based on the N-K mounting parameters, the abnormal flag bit is set to be valid, and the fact that the data partition is valid means that the data partition is not mounted through the N mounting parameters is not achieved.

In a possible implementation of the first aspect, the method further includes: after the starting of the operating system is completed, based on the fact that the abnormal flag bit is valid, a first interface is displayed, and the first interface comprises information for prompting that a memory of the electronic equipment is damaged.

That is, if the electronic device mounts the data partition by the mounting parameters other than the N mounting parameters during the starting of the operating system, the electronic device may prompt the user that the memory may be lost after the starting of the operating system is completed, so that the user may backup the data in time.

In a possible implementation of the first aspect, the method further includes: and in response to a user operation of backing up the data at the first interface, backing up at least part of the data in the data partition.

In a possible implementation of the first aspect, the N mounting parameters include at least one of the following mounting parameters ：rw,seclabel,nosuid,nodev,noatime,background_gc＝on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,extent_cache,mode＝adaptive,active_logs＝6,inlinecrypt,alloc_mode＝default,fsync_mode＝nobarrier.

In a possible implementation manner of the first aspect, the mounting data partition based on N-K mounting parameters includes:

and mounting the data partition by using a mount instruction, wherein the mount instruction comprises N-K mounting parameters.

In a second aspect, the present application provides a readable storage medium comprising instructions which, when executed by an electronic device, cause the electronic device to implement the above-described first aspect and any one of the possible implementations of the above-described first aspect.

In a third aspect, the present application provides an electronic device comprising: a memory for storing instructions; at least one processor configured to execute instructions to cause an electronic device to implement the above first aspect and any one of the possible implementations of the above first aspect to provide a system start-up method.

In a fourth aspect, the present application provides a program product which, when run on an electronic device, causes the electronic device to implement the above-described first aspect and any one of the possible implementations of the above-described first aspect to provide a system boot method.

The advantages of the second aspect to the fourth aspect may be referred to the description of the first aspect, and are not described here.

Drawings

FIG. 1 illustrates a software architecture diagram of an electronic device, according to some embodiments of the application;

FIG. 2 illustrates a schematic diagram of a startup process of an electronic device, according to some embodiments of the application;

FIG. 3 is a schematic diagram illustrating a display of a hint after an operating system of an electronic device is booted according to some embodiments of the present application;

FIG. 4 illustrates a flow diagram of a system startup method, according to some embodiments of the application;

fig. 5 illustrates a schematic diagram of the structure of an electronic device 10, according to some embodiments of the application.

Detailed Description

Illustrative embodiments of the application include, but are not limited to, a system boot method, a readable storage medium, and an electronic device.

The technical scheme of the application is described below with reference to the accompanying drawings.

The system starting method provided by the embodiment of the application can be applied to any electronic equipment, including but not limited to mobile phones, tablet computers, wearable equipment, head-mounted displays, mobile email equipment, portable game machines, portable music players, reader equipment, laptop computers, intelligent home equipment and the like.

First, take the operating system of the electronic device asOperating system for example, the process of starting an operating system of an electronic device is described.

Fig. 1 illustrates a software architecture diagram of an electronic device, according to some embodiments of the application.

As shown in fig. 1, the software architecture of the electronic device includes an application layer, an application framework layer, a native layer, and a kernel layer.

The application layer includes application programs in the electronic device, such as desktop launchers (also known as desktops, desktop applications, etc.), and the like. In some embodiments, the launcher process may, at run-time, call finishBooting () function to set a flag bit (e.g., flag bit sys. Boot_ completed) that indicates that the system operating system is complete to be valid.

The application framework layer is used to provide an application programming interface (application programming interface, API) and programming framework for application programs of the application layer.

In some embodiments, the application framework layer may include system services (SYSTEM SERVER) that, when run, corresponding SYSTEM SERVER processes may be used to launch various services in the Java framework, such as: a device identifier policy service (DeviceIdentifiersPolicyService, DIPS), a power manager (PowerManagement, PM), a system recovery service (RecoverySystemService, RSS), a backlight service (LIGHTSSERVICE, LS), a system service manager (SYSTEMSERVICEMANAGER, SSM), an input management service (InputManagerService, IMS), a window management service (WindowManagerService, WMS), and the like.

The native (native) layer may include a C language base library, a C language tool library, init processes, service management (SERVICEMANAGER), and the like. The init process may mount a file system in the electronic device, load a security-enhanced linux (security policy) rule, initialize an operating system, start SERVICEMANAGER a process, and start zygote a process when running.

In other embodiments, the native layer may further include further modules, such as a hardware abstraction layer, etc., without limitation.

The application framework layer and the native layer communicate via Java native calls (Java NATIVE INTERFACE, JIN). zygote processes are interposed between the application framework layer and the native layer, zygote processes may start up virtual machines (Dalvik virtual machines or ART virtual machines), SYSTEM SERVER processes at runtime. The zygote process may also define a port (socket) for receiving a request for the campaign management service (ACTIVITYMANAGERSERVICE, AMS) to launch an application.

The kernel (kernel) layer may include kthreadd processes, swapper processes, drivers, etc.

Swapper processes, when running, can be used to initialize process management, memory management, load drivers, start init processes and threadd processes. kthreadd processes are the first processes of the operating system kernel to create kernel daemons such as kernel worker thread kworkder, soft interrupt thread ksoftirqd, and thermal.

Optionally, in other embodiments, the software architecture of the electronic device may further include more layers, and each layer may also include more modules, which is not limited herein.

The following is a procedure for starting up the operating system of the electronic device in connection with the software architecture shown in fig. 1.

FIG. 2 illustrates a schematic diagram of a boot process of an operating system of an electronic device, according to some embodiments of the application.

As shown in fig. 2, the process of operating system startup of the electronic device includes the following stages:

S01, bootRom stage.

After the electronic device is started, for example, after a user presses a start button of the electronic device, the electronic device is powered on, and the BootRom stage is entered. In the BootRom phase, the electronic device boot chip code starts executing from a predefined memory location (e.g., read-only memory (ROM) cured in the electronic device), loads a boot program (e.g., bootloader) into a random access memory (random access memory, RAM, e.g., memory of the electronic device or cache of a processor of the electronic device) of the electronic device, and then starts executing.

S02, bootloader stage.

After Bootloader is loaded into RAM, the electronic device enters Bootloader phase. The Bootloader, also called a boot loader, is a section of program that runs before the operating system of the electronic device runs, and is used to copy the image file of the operating system into the RAM, and then jump to the entry of the image file to execute the file, which may also be called entering a boot loader mode.

Optionally, in some embodiments, the electronic device may launch a master Bootloader (application primary boot loader, APPS PBL), an extensible Bootloader (extensible boot loader, XBL), an application Bootloader (applications boot loader, ABL), and the like in the Bootloader phase. Wherein the APPS PBL may be used for initialization of an operating system security environment, determining a boot device (e.g., memory) of an operating system, etc.; the XBL is used for initializing the hardware environment, code security environment and the like of the electronic equipment; ABL may be used to initialize the display driver, provide a quick start (fastboot) function, direct the electronic device into the kernel phase (e.g., start swapper processes in kernel), etc.

Optionally, in some embodiments, the electronic device may also launch a small kernel (LITTLE KERNEL, LK) during the Bootloader phase. LK may be used to initialize the hardware of the electronic device, to boot the electronic device into a kernel phase (e.g., start swapper processes in kernel), etc.

S03, kernel stage.

The kernel phase, the electronic device runs the process in kernel layer. For example, swapper processes may be run to launch kthreadd processes, as well as to initialize the electronic device operating system kernel (e.g., set up caches, protected memory, schedule lists, load drivers, etc.). At the end of the kernel start phase, the electronic device may start the init process.

S04, init stage.

And in an init stage, the electronic equipment runs an init process. The electronic device may mount a file system in the electronic device by running an init process, load a security-enhanced linux (security policy) rule, initialize an operating system, start a service management (SERVICEMANAGER) process in a local layer, and start a zygote process.

For example, in the process of mounting a file system in an electronic device by the electronic device, a partition related to the electronic device may be mounted, such as a boot (boot) partition, an initial boot (init_boot) partition, a system (system) partition, a recovery (recovery) partition, a data (data) partition, and so on.

In some embodiments, the data partition, also referred to as a user data (userdata) partition, is used to store data of a user of the electronic device, such as a user-installed application, user image/video/audio, or other forms of files, etc.

In some embodiments, different partitions may correspond to different file systems, and different file systems may be mounted via mounting parameters supported by the file systems. For example, for data partitioning, it is typically possible to mount as F2FS (FLASH FRIENDLY FILE SYSTEM, a file system for NAND storage). The F2FS supports a plurality of mount parameters, and when a partition (e.g., a data partition) of the file system F2FS is mounted, one or more mount parameters may be selected from the plurality of mount parameters to mount the data partition. The electronic device typically mounts the data partition during init phase by presetting mounting parameters (e.g., all mounting parameters supported by F2 FS). The mounting parameters supported by F2FS will be described in detail below, and will not be described in detail herein.

Alternatively, in some embodiments, the partition with the file system F2FS may be mounted without attaching a mount parameter, which is not limited herein.

S05, zygote stage.

At stage zygote, the electronic device runs zygote process, zygote process is the parent of all Java processes. For example, zygote may launch a virtual machine (Dalvik virtual machine or ART virtual machine), SYSTEM SERVER process. The zygote process may also define a port (socket) for receiving a request for the campaign management service (ACTIVITYMANAGERSERVICE, AMS) to launch an application.

S06, SYSTEM SERVER stage.

At stage SYSTEM SERVER, the electronic device may initiate services in the electronic device operating system by running SYSTEM SERVER processes of the application framework layer.

For example, the electronic device may run the AMS and load a service library of the operating system, call createSystemContext (), create ACTIVITYTHREAD, and load various services, such as loading DIPS, PM, RSS, LS, SSM, IMS, WMS.

S07, a laboratory stage.

And in the launcher stage, the electronic device runs the launcher process. During the running process of the Launcher process, a finishBooting () function may be called to set a flag bit (e.g., flag bit sys. Boot_ completed) to be valid (e.g., set to 1) indicating that the operating system is complete and that the operating system boot is complete.

The above-mentioned phase division in the starting process of the operating system of the electronic device is only an example, and in other embodiments, the starting process of the operating system of the electronic device may include more or less phases, and may also combine or split part of the phases, which is not limited herein.

In the init stage of the starting process of the operating system of the electronic device, the electronic device mounts the data partition through the preset mounting parameters. In the case that a storage medium of the electronic device for storing the data partition is damaged or fails, if the damaged or failed part is related to a preset mounting parameter, the mounting of the data partition fails. After the data partition fails to be mounted, the starting of the operating system of the electronic device is stopped at the init stage, and the following zygote stage, SYSTEM SERVER stage and launcher stage are not continuously performed, so that the operating system of the electronic device cannot be started normally and the electronic device cannot be started normally.

If the damaged or faulty part of the storage medium of the electronic device storing the data partition is related to only a part of the mounting parameters, the electronic device can mount the data partition without using the part of the mounting parameters when mounting the data partition.

In this way, the embodiment of the application provides a system starting method, after the electronic device fails to mount the data partition through the preset mounting parameters in the process of starting the operating system, the electronic device can re-mount the data partition by using the mounting parameters different from the preset mounting parameters among other mounting parameters supported by the file system corresponding to the data partition. After the electronic device successfully mounts the data partition by using a certain set of mounting parameters, the electronic device continues to start other stages of the electronic device operating system starting process. Therefore, under the condition that the damaged or faulty part of the storage medium of the electronic equipment storing the data partition is only related to part of the mounting parameters, the electronic equipment can still mount the data partition, so that an operating system of the electronic equipment can be normally started, and the electronic equipment can be normally started.

In some embodiments, the mount parameters are file system definition parameters corresponding to the data partitions, and each mount parameter may correspond to a certain function of the file system, or a certain attribute of the file system, etc. When the electronic device mounts the data partition, the data partition may be mounted by one or more (or may not) mounting parameters, and each mounting parameter may correspond to a certain function of opening/closing the file system, configuring a certain attribute of the file system, and so on.

In some embodiments, the preset mounting parameters include a plurality of mounting parameters employed for mounting the data partition during an operating system start-up of the electronic device set by an operating system or developer of the electronic device.

In some embodiments, if the electronic device mounts the data partition through a mounting parameter other than the preset mounting parameter, the electronic device may also prompt the user "the storage medium may be damaged, please backup the data in time or go to the after-sales service center" after the operating system is started successfully. Therefore, the user can timely process the faults of the storage medium, and data loss is avoided.

For example, when the electronic device mounts the data partition by presetting the mounting parameters with different mounting parameters, the abnormality flag may be set to be valid. After the electronic device completes the starting of the operating system, for example, after setting the sys.boot_ completed flag bit to be valid through the foregoing finishBooting () function, in the case that the exception flag is valid, the prompt message 21 shown in fig. 3 is displayed to prompt the user that the storage medium may be damaged, please back up the data in time or go to the after-sales service center.

In some embodiments, in the case that the electronic device mounts the data partition through a mounting parameter different from the preset mounting parameter, a user or a serviceman may connect the electronic device to another device (hereinafter referred to as a debug device) after the operating system of the electronic device is successfully started, and send an android debug bridge (android debug bridge, ADB) instruction to the electronic device by using the debug device to backup data in the electronic device to the debug device. In this way, user data loss can be avoided.

In some embodiments, in the process of backing up data in an electronic device to a debug device through an ADB instruction, if an input/output (IO) error occurs when a certain file is backed up, the file may be deleted or moved to another directory and then another file in the directory where the file is located is backed up, or all files in the target where the file is located may be packaged (for example, packaged into a file in tar format or another format), and then the packaged file is backed up. Thus, even if a file which cannot be accessed exists (namely, a storage area corresponding to the file may be damaged or malfunction), other files of the electronic device can be backed up.

In some embodiments, when the electronic device mounts the data partition through a mounting parameter different from the preset mounting parameter, after the operating system of the electronic device is started, a jump entry of an application program or a service for backing up the data may be displayed, so that a user may directly backup the data through the entry. For example, referring to FIG. 3, the electronic device may display a "backup" control 211 such that the electronic device may run an application or service that the electronic device may backup data to backup data in the electronic device in response to a user's operation of the "backup" control 211.

In some embodiments, the file system to which the data partition corresponds may be F2FS.

In some embodiments, mount parameters supported by a partition of the file system F2FS (e.g., the aforementioned data partition) may be null or include at least one of the following mount parameters:

rw, mounting the partition through a readable and writable mode.

The setting bit of the set user identification (user identification, UID) or group identification (group identification, GID) is turned off.

Nodev, configured to not read a character or block device on the file system.

Dev, configured to read characters or block devices on the file system.

An atime configured to update an access time of an inode (a data structure) each time data is accessed.

Noatime, configured not to update an access time of an inode (inode) each time data is accessed.

Backspace_gc=% s, configure the way F2FS performs space reclamation (garbage collection). When the% s is on (i.e. the mounting parameter is background_gc=on), indicating that the electronic device can perform space recovery when the storage medium is idle; when the% s is off (i.e. the mounting parameter is background_gc=off), indicating that the electronic device cannot perform space recovery; when% s is sync (i.e., the mounting parameter is background_gc=sync), the electronic device is instructed to perform space reclamation in the background during the operation of the storage medium.

Disable_roll_forward, disable the roll-forward recovery procedure (roll-forward recovery routine). Front roll recovery is a way of recovering data or implementing post-crash recovery by which F2FS does not recover data or instances after they crash after disabling the front roll recovery procedure.

Norecovery, when the partition is read-only loaded, the roll-forward restore procedure is disabled.

Discard or nodiscard, enable or disable the real-time discard (real-TIME DISCARD) function of F2 FS. When the real-time discard function is on, if a segment in the F2FS is cleared, the F2FS will send a discard/TRIM instruction.

No_heap, heap segment allocation (heap-STYLE SEGMENT allocation) is disabled. Heap segment allocation is a memory allocation manner that F2FS does not allocate memory after heap segment allocation is disabled.

Nouser _xattr, disable user extension properties. When the user extension attribute is disabled, the electronic device cannot customize the file attribute of the file in the F2FS, i.e., cannot add the user-customized attribute in the field of the record file or directory attribute.

ACL, enable portable operating system interface access control list (portable operating SYSTEMINTERFACE ACCESS control list, POSIX ACL).

Noacl, disable the portable operating system interface access control list.

Seclabel, configure F2FS to support Selinux (security-enhanced linux), a security policy. When the loading parameters include seclabel parameters, F2FS may support Selinux after loading.

Active_logs=% u, number of configuration activity logs (active logs) (% u). Illustratively,% u may be 2,4,6, i.e. the mounting parameter may be active_logs=2, active_logs=4 or active_logs=6. Alternatively, in other embodiments,% u may be other values, not limited herein.

Disable_ext_identification, disable the extension list of mkfs (MAKE FILE SYSTEM, a file system) configuration. When the extension list of mkfs configuration is disabled, the F2FS cannot identify cold files (cold files, i.e., files with a lower frequency) such as multimedia files.

Inline xattr, enables embedded extended attribute (inline xattrs feature) functionality. After the embedded extended attribute (inline xattrs feature) function is enabled, the user may write the user-defined attributes (i.e., extended attributes) into an inode block (inode block).

Noinline _xattr, disable the embedded extended properties function.

The size of the embedded extension attribute is configured as% u. That is, allowing a user to write an extended attribute of size% u into an inode block (inode block).

Inline_data enables a data embedding function. After the data embedding function is enabled, the electronic device may write the data of the newly created file into an inode block (inode block).

Noinline _data, disable the data embedding function.

Inline dentry, using a directory embedding function. After the directory embedding function is enabled, the electronic device may write the newly created directory entry (directory entries) into an inode block (inode block).

Noinline _ dentry, disable the directory embedding function.

Inlinecrypt configured to preferentially encrypt using the blk-crypto (an encryption framework) framework.

Flush_merge enables the refresh merge function. After the refresh merge function is enabled, the electronic device merges and executes concurrent cache refresh instructions (concurrent cache flush commands) as much as possible.

Nobarrier, disable the cache refresh function. After the cache flush function is disabled, F2FS will not issue the cache flush instruction (cache_ flush commands).

Fastboot, enable quick mount.

Extension_cache enables extended data block caching based on rb tree (rb-tree). The extended data block cache based on the rb tree (rb-tree) can cache a plurality of extended data blocks mapped between consecutive logical addresses and physical addresses for each index node (inode), thereby improving the cache hit rate.

Noextent _cache, the extended data block cache based on the rb tree (rb-tree) is disabled.

Data_flush, enabling the data refresh function. After the data refresh function is enabled, F2FS enables data refresh (data flush) before checkpoints (checkpoints).

Reserved_root=% d, a memory space of% d (hereinafter referred to as reserved space (reserved blocks)) is reserved for a privileged user (PRIVILEGED USER) that specifies UID or GID, the reserved space having a unit of 4KB. For example, at% d=10, the reserved space is 40KB.

Resuid =% d, the UID (% d) of a privileged user who can use the above-described reserved space is specified. For example, if the mount parameter is "resuid =1001", a privileged user whose UID is 1001 may use the reserved space.

Resgid =% d, GID (% d) of the group to which the privileged user who can use the above-described reserved space belongs is specified. For example, if the mount parameter is "resgid =1002", then all users in the group with GID 1002 can use the reserved space.

Fault_injection=% d, fault injection function is enabled. After the fault injection function is enabled, the electronic device may inject faults at a frequency of% d.

Fault_type=% d, configuring the fault type to be injected by the fault injection function, wherein% d represents the identification of the fault type to be injected. The identification of the different fault types is defined by the operating system or file system of the electronic device and is not described in detail herein.

Mode=% s, block allocation pattern (% s) of the profile system. In some embodiments, the block allocation pattern may include "adaptive" and "lfs", that is, the value of% s may be "adaptive" or "lfs".

Io_bits=% u, and in the case of the allocation block mode lfs, the number of bits (% u) of an Input Output (IO) request is input.

Usrquota, enable a generic user (player) disk quota accounting (disk quota accounting) function.

Grpquota, enable a generic group (player) disk quota accounting (disk quota accounting) function.

Prjquota, enable the plain project disk quota accounting (disk quota accounting) function.

Usrjquota = < file >, a file and a type of an ordinary user are specified during mounting.

Grpjquota = < file >, the files and types of the normal group are specified during mount.

Prjjquota = < file >, a file and a type of an ordinary item are specified during mounting.

Jqfmt = < quota type >, specify a type of disk quota, which may include vfgold, vfsv0, vfsv1, i.e. < quota type > may be vfgold, vfsv0 or vfsv1.

Offusrjquota, closing the quota that the user has used.

Offgrpjquota, closing the quota that the group has used.

Offprjjquota, closing the quota that the item has used.

Quota, enable the generic user (player user) disk quota accounting (disk quota accounting) function.

Noquota, disable all common disk quota accounting (disk quota accounting) functions.

Whint _mode=% s, write hint (WRITE HINTS) transfer mode (% s) is configured. For example, the write hint modes may include "off", "user-based", and "fs-based". Wherein the "off" mode (i.e., where% s is off) indicates that F2FS does not pass write hints to the block layer (block layer) of the operating system; the "user-based" mode (i.e., the%s is user-based) instructs the F2FS to pass the write hint sent by the user to the chunk layer; the "FS-based" mode (i.e.,% s is FS-based) indicates that F2FS passes write hints to the block layer according to the rules defined by F2 FS.

Alloc_mode=% s, configure block allocation policy. Illustratively, the block allocation policy may include "resuse" and "default", i.e., the value of% s may be "resuse" or "default".

Fsync _mode=% s, configure file synchronization pattern. Illustratively, the file synchronization patterns may include "posix", "struct" and "nobarrier", i.e., the values of% s may be "posix", "struct" or "nobarrier". "POSIX" indicates that F2FS performs file synchronization according to POSIX language; "struct" indicates that the F2FS performs file synchronization strictly according to a log file system (XFS for short), a fourth generation extended file system (fourth generation extended FILE SYSTEM, ext 4), and a BTRFS (button FILE SYSTEM, a file system); the "nobarrier" mode differs from the "posix" mode in that the mode does not support non-atomic files. .

The test_dummy_encryption enables a dummy encryption (dummy encryption) function. The pseudo-encryption function is used to provide a fake context for fscrypt (an encryption management tool).

Checkpoint=% s configures the checkpoint function. When the value of the% s is disable, closing the check point function of the F2 FS; when the value of the% s is enabled, the check point function of the F2FS is started.

Compression_algorithm=% s, a compression algorithm of F2FS compressed data is configured. Illustratively, the compression algorithm may include "lzo" and "lz4". That is, when the value of% s is "lzo", the F2FS compresses the data by lzo algorithm; when the value of the% s is "lz4", the data is compressed by the f2fs through the lz4 algorithm.

The cluster (cluster) size when compressing data is configured. Illustratively, the cluster size when F2FS compresses data is 4KB× (1 < <% u), where "<" represents a binary number shift left. For example, at% u=0010, 1< <% u=00100 represents a decimal number of 4, and the corresponding cluster size is 16KB.

Compression_extension=% s, which may be an extension of any file type, configures the extension of the file that F2FS compresses. For example, a file with an extension of ". Ext" may be compressed corresponding to%s=. Ext, i.e. with a mount parameter of compression_extension=. Ext, F2 FS.

Optionally, in other embodiments, the F2FS may further include more mounting parameters, which are not described herein.

Optionally, other file systems, such as ext4, BTRFS, and the like, may also include the same or different mount parameters as F2FS, which is not described herein.

In the following, taking a file system of a data partition as an example, the technical scheme of the present application is described.

Fig. 4 illustrates a flow chart of a system start-up method, according to some embodiments of the application. As shown in fig. 4, the flow includes the steps of:

S401: the electronic device copies the image file of the operating system into RAM and executes the boot program.

The electronic device copies the image file of the operating system into RAM and executes the boot program.

In some embodiments, the electronic device may initiate APPS PBL, XBL, ABL and direct the electronic device into a kernel phase (e.g., initiate swapper processes in kernel) or the like during execution of the boot program. Specific reference may be made to the aforementioned step S02, and details are not described here.

In some embodiments, the electronic device may also initiate LK and boot the electronic device into a kernel phase (e.g., initiate swapper processes in kernel) during execution of the boot program, etc. Specific reference may be made to the aforementioned step S02, and details are not described here.

In some embodiments, after the electronic device is started, for example, after a user presses a start button of the electronic device, the electronic device is powered on to enter a BootRom phase. The electronic device loads a boot program (e.g., bootloader) into the RAM of the electronic device and then begins executing the boot program.

S402: the electronic device initializes a kernel of the operating system.

After the electronic device executes the boot program, a kernel may be run to initialize the kernel of the operating system. I.e. the start-up procedure of the operating system of the electronic device goes into the kernel phase.

The electronic device may set caches, protected memories, planning lists, load drivers, etc. during the initialization of the operating system kernel. After initializing the kernel of the operating system, the electronic device may also start an init process.

S403: the electronic device mounts the file system.

After the init process is started, an operating system of the electronic device starts to an init stage, and the electronic device may mount a file system, for example, mount a partition in the electronic device, for example, a boot partition, an initial boot partition, a system partition, a recovery partition, a data partition, and the like.

In some embodiments, the electronic device may mount the various partitions based on mounting instructions defined by the operating system of the electronic device, such as mount instructions.

S404: the electronic device fails to mount the data partition.

Under the condition that the data partition mounting fails, the electronic equipment triggers the system starting method provided by the application.

Optionally, in some embodiments, after the electronic device fails to mount the data partition, a flag bit corresponding to the mount instruction may be valid, and the electronic device determines that the mounting data partition fails in response to the flag bit corresponding to the mount instruction being valid.

Illustratively, assume that an instruction mount (/ data, fs_options, mountflags) corresponding to a data partition is mounted, where/data indicates a data partition, fs_options, mountflags mount parameter. The electronic device may generate a flag bit ret corresponding to the mount instruction through ret=mount (/ data, fs_options, mountflags). When ret=0, that is, when ret is invalid, it is indicated that the data partition is successfully mounted based on the mounting instruction; and when ret is not equal to 0, namely, when ret is valid, indicating that the data partition mounting based on the mounting instruction fails.

Optionally, in some embodiments, when the electronic device fails to mount the data partition, a log of the failure of mounting the data partition may also be recorded. For example, the electronic device may record, in a log of mounting data partition failures, mounting parameters employed at the time of mounting, a cause of mounting failure, an error code, or the like.

Alternatively, assuming that the number of partitions to be mounted on the electronic device is P, the electronic device mounts the P partitions one by one. In some embodiments, P may be obtained based on an operating system defined function fstab.

S405: the electronic device decrypts a header of metadata (metadata) to generate the DM device.

The electronic device may decrypt the header of the metadata of the data partition to obtain a mapping device (DEVICE MAPPER, DM) device in case of failure to mount the data partition.

In some embodiments, the header of metadata is encrypted data corresponding to the access path of the data in the data partition, the information of the storage medium corresponding to the data partition, and the like, and the DM device is plaintext data corresponding to the encrypted data, where the plaintext data may be used for mounting the data partition by the electronic device.

Alternatively, in some embodiments, if the header of the data partition metadata is not encrypted, step S405 may not be performed, which is not limited herein.

S406: the electronic device checks the metadata of the data partition or the entire data of the data partition using fs_check.

And when the electronic equipment obtains the DM equipment corresponding to the data partition, checking the metadata of the data partition or the whole data partition by using fs_check so as to be convenient for modifying the errors of the data partition.

In some embodiments, fs_check is a tool or function defined by the operating system or developer of the electronic device for modifying a file system or partition. The electrons can repair partial errors of the data partition by calling fs_check to check the metadata of the data partition or the entire data of the data partition.

S407: the electronic device mounts the data partition based on the N mounting parameters and the DM device.

After repairing the data partition by using fs_check, the electronic device mounts the data partition based on the N mounting parameters and the DM device. Specifically, the electronic device executes a mounting instruction carrying N mounting parameters, and in the process of executing the mounting instruction, the electronic device can mount the data partition based on the DM device (i.e., the data access path in the data partition, the plaintext data corresponding to the information of the storage medium corresponding to the data partition, etc.).

In some embodiments, if the electronic device successfully mounts the data partition based on the N mount parameters, then other instructions of the operating system in the init stage (such as instructions to load the Selinux rule, initialize the operating system, start the service management process and zygote processes, etc.) are executed, and after the execution is completed, the process goes to step S409. If the electronic device fails to mount the data partition based on the N mount parameters, it goes to step S408.

In some embodiments, N is an integer greater than 1. The N mounting parameters are defined by a developer or operating system of the electronic device. In some embodiments, the N mount parameters may include all mount parameters that can be used simultaneously among mount parameters supported by the data partition.

When the electronic device mounts the data partition, a flag bit corresponding to the mount instruction may be generated, for example, a flag bit ret corresponding to the mount instruction may be generated by ret=mount (/ data, fs_options, mountflags). Wherein/data represents the data partition, fs_options, mountflags represents the mount parameters used to mount the data partition. Further, when ret=0, namely ret is invalid, indicating that the data partition is successfully mounted; when ret is not equal to 0, that is, ret is valid, the data partition mounting failure is indicated.

In some embodiments, the electronic device may mount the data partition to the DM device by presetting the mount parameter by: "mount-t f fs/dev/block/dm-20/data preset mount parameters". Wherein F2FS represents that the file system on which the data partition is mounted is F2FS, "/dev/block/DM-20" represents the identification of the DM device, and "/data" represents the data partition.

The above instruction "mount-t f fs/dev/block/dm-20/data preset mount parameters" is just one example. In some embodiments, "/dev/block/DM-20" in the instruction may be replaced with the identity of other DM devices, such as "/dev/block/DM-xx", where xx is any number. In other embodiments, the "/data" in the instruction may be replaced with other identifiers representing data partitions, which are not limited herein.

S408: when the mounting of the data partition based on the N mounting parameters fails, the electronic equipment mounts the data partition based on the N-K mounting parameters, increases K by 1, and sets the abnormality mark as effective, wherein the initial value of K is 1.

When the electronic device fails to mount the data partition based on the N mounting parameters (for example, when ret is not equal to 0), N-K mounting parameters can be selected from the N mounting parameters (for example, K mounting parameters are removed from the N mounting parameters), the K is increased by 1, and the exception flag is set to be valid.

In some embodiments, the electronic device may select N-K mounting parameters from N mounting parameters with N ≡! (N-K)/(K)! K selection modes. The electronic device may perform each time step S408 is performed, can traverse through N-! (N-K)/(K)! K selection modes selected N-! (N-K)/(K)! And (5) N-K mounting parameter groups of K groups, and attempting to mount the data partition. If the mounting of the data partition is successful, executing other instructions of the operating system in the init stage (such as instructions for loading the Selinux rule, initializing the operating system, starting the service management process, zygote processes, etc.), and after the execution is completed, going to step S409; if the N-! (N-K)/(K)! And if none of the mounting parameters selected by the K selection modes can successfully mount the data partition, increasing K by 1, and repeating the step S408.

For example:

when step S408 is executed for the 1 st time, k=1, the electronic device may mount the data partition using N-1 parameters from which the 1 st mount parameter is removed from the N mount parameters; if the data mounting by using the N-1 mounting parameters fails, the electronic equipment can use the N-1 parameter mounting data partitions with the 2 nd mounting parameter removed from the N mounting parameters. And so on, until the electronic equipment fails to mount the data partition by utilizing the N-1 parameters after the Nth mounting parameter is removed from the N mounting parameters, the electronic equipment increases K by 1.

When step S408 is executed for the 2 nd time, k=2, the electronic device may mount the data partition using N-2 parameters from which the 1 st and 2 nd mount parameters are removed from the N mount parameters; if the data mounting by using the N-2 mounting parameters fails, the electronic equipment can use the N-2 parameter mounting data partitions after removing the 1 st and 3 rd mounting parameters from the N mounting parameters. And so on, until the electronic device fails to mount the data partition using the N-2 mount parameters determined from the N× (N-1)/2 manner, the electronic device increases K by 1.

Similarly, if the electronic device successfully mounts the datSup>A partition through N-Sup>A mounting parameters when k=Sup>A (Sup>A < N), the electronic device executes other instructions of the operating system in the init phase (such as instructions for loading the Selinux rule, initializing the operating system, starting the service management process, starting the zygote process, etc.), and after the execution is completed, the process goes to step S409; if the data partition still cannot be successfully mounted when k=n, the electronic device may stop starting the operating system.

In some embodiments, when k=Sup>A (Sup>A < N), the electronic device may record k=Sup>A that the datSup>A partition was successfully mounted by N-Sup>A mounting parameters. At the next execution of step S408, if a+1 is taken as the initial value of K, the data partition is mounted.

Optionally, in some embodiments, when k=Sup>A (Sup>A < N), the electronic device may record k=Sup>A when the datSup>A partition is successfully mounted by N-Sup>A mounting parameters (the mounting parameters adopted when the mounting is successful are referred to as nSup>A parameters). When step S408 is performed next, if Sup>A is taken as the initial value of K, N-Sup>A mount parameter mount datSup>A partitions different from NA parameters are selected from the N mount parameters.

Alternatively, in other embodiments, the process of mounting the data partition based on the N-K mounting parameters may be that N ≡ corresponding to N-K mounting parameters selected from the N mounting parameters is determined first! (N-K)/(K)! K kinds of mounting parameter groups, and traversing the N-! (N-K)/(K)! and/K kinds of mounting parameter sets for mounting the data partition.

In some embodiments, the electronic device may select N-K mounting parameters from N mounting parameters with N ≡! (N-K)/(K)! K selection modes. In some embodiments, when the abnormality flag is valid, for example, when the abnormality flag flag=1, the electronic device is instructed to mount the data partition by a mount parameter different from the preset mount parameter.

Optionally, in some embodiments, when the electronic device fails to mount the data partition, a log of the mount data partition may also be recorded, for example, a log of the mount data partition failure or a log of the mount data partition success. In other embodiments, the log of each mount data partition may further include a mount parameter used when the electronic device mounts the data partition, and the log of the mount data partition failure may further include a cause or error code that causes the mount data partition failure.

Based on the method for re-mounting the data partition, the data partition can be mounted by using mounting parameters in the preset mounting parameters as much as possible, so that the mounted data partition can support more functions or characteristics.

S409: the electronic device runs zygote processes, SYSTEM SERVER processes, and a launcher process.

After the data partition is successfully mounted and all instructions in the init stage are executed, the electronic device sequentially runs zygote processes, SYSTEM SERVER processes and a launcher process to execute related instructions of the operating system in the zygote stage, SYSTEM SERVER stage and the launcher stage respectively. Reference may be made specifically to the foregoing embodiment shown in fig. 2, and details are not described here.

In some embodiments, if the operating system is not started to be completed in the process of sequentially running zygote processes, SYSTEM SERVER processes, and launcher processes by the electronic device, the process may go to step S408; if the operating system is started up after the electronic device runs zygote processes, SYSTEM SERVER processes, and the launcher processes in order, the process goes to step S410.

S410: when the operating system of the electronic device is started and the abnormality flag is valid, the electronic device prompts the user to "the storage medium may be damaged, please backup the data in time or go to the after-sales service center".

The electronic device responds to the completion of the starting of the operating system of the electronic device (for example, when the flag bit sys. Boot_ completed is valid) and the exception flag is valid (indicating that the electronic device mounts the data partition through the mounting parameter different from the preset mounting parameter), and prompts the user to "the storage medium may be damaged, please backup the data in time or go to the after-sale service center".

In some embodiments, the electronic device may prompt the user by displaying a prompt window, playing prompt audio, or otherwise, "the storage medium may be damaged, please backup the data in time, or go to an after-market service center.

Optionally, in some embodiments, if an application or service for backing up data exists in the electronic device, the electronic device may also display a jump control for the application or service for backing up data, or go directly to the application or service for backing up data, so that the user may backup data to the server or other devices connected to the electronic device in time. For example, referring to FIG. 3, the electronic device can run an application or service that backs up data in response to a user's operation of the "backup" control 211, backing up data in the electronic device to a server or other electronic device connected to the electronic device.

Optionally, in some embodiments, in the process of backing up data by an application program or a service of backing up data, if an input/output (IO) error occurs during backing up a certain file, the file may be deleted or moved to another directory and then another file in the directory where the file is located may be backed up, or all files in the target where the file is located may be packaged (for example, packaged into a file in tar format or another format), and then the packaged file may be backed up. Thus, even if a file which cannot be accessed exists (namely, a storage area corresponding to the file may be damaged or malfunction), other files of the electronic device can be backed up.

Optionally, in some embodiments, after the operating system of the electronic device is started successfully, the user or the serviceman may backup the data in the electronic device by using the ADB instruction.

According to the method provided by the embodiment of the application, in the starting process of the electronic equipment, if the data partition is failed to be mounted through the preset mounting parameters, the data partition can be mounted through the mounting parameters different from the preset mounting parameter groups. If the electronic equipment is successfully partitioned by using the mounting parameters different from the preset mounting parameters, the starting flow of the electronic equipment can be continued. Therefore, even if the data partition mounting by using the preset mounting parameters fails, the electronic equipment can be started normally, and a user of the electronic equipment can backup data in time, so that the data loss is avoided.

In addition, after the electronic equipment mounts the datSup>A partition through N-A mounting parameters which are different from the preset mounting parameters, if the electronic equipment still fails to be started, the electronic equipment can re-mount the datSup>A partition through N-B mounting parameters (B is less than or equal to A, and at least one mounting parameter in the N-B mounting parameters is different from at least one mounting parameter in the N-A mounting parameters), so that the possibility of successful starting of an operating system of the electronic equipment can be further improved. .

Further, fig. 5 illustrates a schematic diagram of an electronic device 10, according to some embodiments of the application.

As shown in fig. 5, the electronic device 10 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (universal serial bus, USB) interface 130, a charge management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, keys 190, a motor 191, an indicator 192, a camera 193, a display 194, and a subscriber identity module (subscriber identification module, SIM) card interface 195, etc. The sensor module 180 may include a pressure sensor 180A, a gyro sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, and the like.

The processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (IMAGE SIGNAL processor, ISP), a controller, a video codec, a digital signal processor (DIGITAL SIGNAL processor, DSP), a baseband processor, and/or a neural-Network Processor (NPU), etc. Wherein the different processing units may be separate devices or may be integrated in one or more processors.

In some embodiments, the processor 110 may call and execute the corresponding instruction of the system startup method provided by each embodiment of the present application stored in the memory, so as to implement the system startup method provided by the embodiment of the present application. For example, the processor 110 may be configured to execute instructions for mounting a data partition with mounting parameters different from the preset mounting parameters, instructions for setting an exception flag to active, instructions for prompting a user in response to the exception flag being active, and the like.

The USB interface 130 is an interface conforming to the USB standard specification, and may specifically be a Mini USB interface, a Micro USB interface, a USB Type C interface, or the like. The USB interface 130 may be used to connect a charger to charge the electronic device 10, or may be used to transfer data between the electronic device 10 and a peripheral device. And can also be used for connecting with a headset, and playing audio through the headset. The interface may also be used to connect other electronic devices.

The charge management module 140 is configured to receive a charge input from a charger. The charging management module 140 may also supply power to the electronic device through the power management module 141 while charging the battery 142.

The power management module 141 is used for connecting the battery 142, and the charge management module 140 and the processor 110. The power management module 141 receives input from the battery 142 and/or the charge management module 140 to power the processor 110, the internal memory 121, the display 194, the camera 193, the wireless communication module 160, and the like.

The wireless communication function of the electronic device 10 may be implemented by the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, and the like.

The antennas 1 and 2 are used for transmitting and receiving electromagnetic wave signals.

The mobile communication module 150 may provide a solution for wireless communication including 2G/3G/4G/5G, etc. applied to the electronic device 10. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (low noise amplifier, LNA), etc. The mobile communication module 150 may receive electromagnetic waves from the antenna 1, perform processes such as filtering, amplifying, and the like on the received electromagnetic waves, and transmit the processed electromagnetic waves to the modem processor for demodulation. The mobile communication module 150 can amplify the signal modulated by the modem processor, and convert the signal into electromagnetic waves through the antenna 1 to radiate. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be disposed in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 may be provided in the same device as at least some of the modules of the processor 110.

The wireless communication module 160 may provide solutions for wireless communication including wireless local area network (wireless local area networks, WLAN) (e.g., wireless fidelity (WIRELESS FIDELITY, wi-Fi) network), bluetooth (BT), global navigation satellite system (global navigation SATELLITE SYSTEM, GNSS), frequency modulation (frequency modulation, FM), near field communication (NEAR FIELD communication, NFC), infrared (IR), etc., as applied to the electronic device 10. The wireless communication module 160 may be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, modulates the electromagnetic wave signals, filters the electromagnetic wave signals, and transmits the processed signals to the processor 110. The wireless communication module 160 may also receive a signal to be transmitted from the processor 110, frequency modulate it, amplify it, and convert it to electromagnetic waves for radiation via the antenna 2.

The display screen 194 is used to display images, videos, and the like. The display 194 includes a display panel. The display panel may employ a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), an active-matrix organic LIGHT EMITTING diode (AMOLED), a flexible light-emitting diode (FLED), a mini-LED, a micro-OLED, a quantum dot light-emitting diode (QLED), or the like. In some embodiments, the electronic device 10 may include 1 or N display screens 194, N being a positive integer greater than 1.

The electronic device 10 implements display functions via a GPU, a display screen 194, an application processor, and the like. The GPU is a microprocessor for image processing, and is connected to the display 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or change display information.

For example, in some embodiments, the display 194 may be used to display an interface of an application as well as a first animation.

The camera 193 is used to capture still images or video. The object generates an optical image through the lens and projects the optical image onto the photosensitive element. The photosensitive element may be a charge coupled device (charge coupled device, CCD) or a Complementary Metal Oxide Semiconductor (CMOS) phototransistor. The photosensitive element converts the optical signal into an electrical signal, which is then transferred to the ISP to be converted into a digital image signal. The ISP outputs the digital image signal to the DSP for processing. The DSP converts the digital image signal into an image signal in a standard RGB, YUV, or the like format. In some embodiments, electronic device 10 may include 1 or N cameras 193, N being a positive integer greater than 1.

The external memory interface 120 may be used to connect an external memory card, such as a Micro SD card, to enable expansion of the memory capabilities of the electronic device 10. The external memory card communicates with the processor 110 through an external memory interface 120 to implement data storage functions. For example, files such as music, video, etc. are stored in an external memory card. In some embodiments, the electronic device may backup the data in the foregoing data partition to an external memory card, so that the user may store the backed-up data to other devices or storage media through the external memory card.

The internal memory 121 may be used to store computer executable program code including instructions. The internal memory 121 may include a program memory area and a data memory area. The program storage area may store an operating system, application programs required for at least one function, and the like. The data storage area may store data created during use of the electronic device 10, etc. In addition, the internal memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (universal flash storage, UFS), and the like. The processor 110 executes various functional applications of the electronic device 10 by executing instructions stored in the internal memory 121 and/or instructions stored in a memory provided in the processor 110. In some embodiments, the data partitions of the electronic device 10 may be stored in the internal memory 121.

The electronic device 10 may implement audio functions through an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, an application processor, and the like. Such as music playing, recording, etc.

The audio module 170 is used to convert digital audio information into an analog audio signal output and also to convert an analog audio input into a digital audio signal. The audio module 170 may also be used to encode and decode audio signals.

The speaker 170A, also referred to as a "horn," is used to convert audio electrical signals into sound signals.

A receiver 170B, also referred to as a "earpiece", is used to convert the audio electrical signal into a sound signal.

Microphone 170C, also referred to as a "microphone" or "microphone", is used to convert sound signals into electrical signals.

The earphone interface 170D is used to connect a wired earphone.

The pressure sensor 180A is used to sense a pressure signal, and may convert the pressure signal into an electrical signal. In some embodiments, the pressure sensor 180A may be disposed on the display screen 194. The pressure sensor 180A is of various types, such as a resistive pressure sensor, an inductive pressure sensor, a capacitive pressure sensor, and the like.

The acceleration sensor 180E may detect the magnitude of acceleration of the electronic device 10 in various directions (typically three axes). The magnitude and direction of gravity may be detected when the electronic device 10 is stationary. But also to recognize the gesture of the electronic device, to determine whether the electronic device 10 is in a landscape state, pedometer, etc.

The ambient light sensor 180L is used to sense ambient light level. The electronic device 10 may adaptively adjust the brightness of the display 194 based on the perceived ambient light level. The ambient light sensor 180L may also be used to automatically adjust white balance when taking a photograph. Ambient light sensor 180L may also cooperate with proximity light sensor 180G to detect whether electronic device 10 is in a pocket to prevent false touches.

The fingerprint sensor 180H is used to collect a fingerprint. The electronic device 10 may utilize the collected fingerprint characteristics to unlock the fingerprint, access the application lock, take a photograph of the fingerprint, answer an incoming call, etc.

The touch sensor 180K, also referred to as a "touch device". The touch sensor 180K may be disposed on the display screen 194, and the touch sensor 180K and the display screen 194 form a touch screen, which is also called a "touch screen". The touch sensor 180K is for detecting a touch operation acting thereon or thereabout. The touch sensor may communicate the detected touch operation to the application processor to determine the touch event type. Visual output related to touch operations may be provided through the display 194. In other embodiments, the touch sensor 180K may also be disposed on the surface of the electronic device 10 at a different location than the display 194.

The bone conduction sensor 180M may acquire a vibration signal. In some embodiments, bone conduction sensor 180M may acquire a vibration signal of a human vocal tract vibrating bone pieces. The bone conduction sensor 180M may also contact the pulse of the human body to receive the blood pressure pulsation signal.

The keys 190 include a power-on key, a volume key, etc. The keys 190 may be mechanical keys. Or may be a touch key. The electronic device 10 may receive key inputs, generating key signal inputs related to user settings and function controls of the electronic device 10. In some embodiments, the electronic device 10 may start the electronic device 10 in response to a user operation on a power-on key, such as a long-press of the power-on key, and enter a BootRom phase of the start-up procedure of the electronic device 10.

The motor 191 may generate a vibration cue.

The indicator 192 may be an indicator light, may be used to indicate a state of charge, a change in charge, a message indicating a missed call, a notification, etc.

The SIM card interface 195 is used to connect a SIM card.

It should be understood that the structure of the electronic device 10 illustrated in the embodiments of the present application does not constitute a specific limitation on the electronic device 10. In other embodiments of the application, the electronic device 10 may include more or fewer components than shown, or certain components may be combined, or certain components may be split, or different arrangements of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

The configuration of the electronic device 10 shown in fig. 5 is merely an example, and in other embodiments, the electronic device 10 may include more or fewer modules, and may incorporate or split portions of the modules, which are not limited herein.

Embodiments of the disclosed mechanisms may be implemented in hardware, software, firmware, or a combination of these implementations. Embodiments of the application may be implemented as a computer program or program code or program product for execution on a programmable system including at least one processor, a storage system (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device.

Program code may be applied to input instructions to perform the functions described herein and generate output information. The output information may be applied to one or more output devices in a known manner. For the purposes of this disclosure, a processing system includes any system having a processor such as, for example, a digital signal processor, a microcontroller, an application specific integrated circuit, or a microprocessor.

The program code may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. Program code may also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described in the present application are not limited in scope by any particular programming language. In either case, the language may be a compiled or interpreted language.

In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on one or more transitory or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed over a network or through other computer-readable storage media. Thus, a machine-readable storage medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), including but not limited to floppy diskettes, optical disks, magneto-optical disks, random access memories, erasable programmable read-only memories, electrically erasable programmable read-only memories, magnetic or optical cards, flash memory, or a tangible machine-readable memory for transmitting information (e.g., carrier waves, infrared signal digital signals, etc.) using the internet in an electrical, optical, acoustical or other form of propagated signal. Thus, a machine-readable storage medium includes any type of machine-readable storage medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

In the drawings, some structural, module, or method features may be shown in a particular arrangement and/or order. However, it should be understood that such a particular arrangement and/or ordering may not be required. Rather, in some embodiments, these features may be arranged in a different manner and/or order than shown in the illustrative figures. Additionally, the inclusion of structural or methodological features in a particular figure is not meant to imply that such features are required in all embodiments, and in some embodiments, may not be included or may be combined with other features.

It should be noted that in the examples and descriptions of this patent, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Furthermore, the term "comprises/comprising" means that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.

While the application has been shown and described with reference to certain preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the application.

Claims

1. A system startup method, characterized in that the electronic device includes a data partition; and

The method comprises:

During the startup of the operating system of the electronic device, the data partition is mounted based on N mount parameters, wherein the mount parameters are mount parameters corresponding to the file system of the data partition, and N is an integer greater than 1;

If mounting the data partition based on the N mounting parameters fails, mounting the data partition based on N-K mounting parameters, where K is a natural number and K is less than N;

After the data partition is successfully mounted based on the N-K mounting parameters, the desktop launcher is run.

2. The method according to claim 1, characterized in that mounting the data partition based on N-K mounting parameters comprises:

The N-K mount parameters are selected from the N mount parameters, and the data partition is mounted based on the N-K mount parameters.

3. The method according to claim 1, characterized in that the method further comprises:

Mounting the data partition based on the N-K mount parameters fails, and mounting the data partition based on N-K-1 mount parameters.

4. The method according to any one of claims 1 to 3, characterized in that after the data partition is successfully mounted based on the N-K mounting parameters, a desktop launcher is run, comprising:

After the data partition is successfully mounted using the N-K mounting parameters, the process incubator, the system service process and the desktop launcher are run.

5. The method according to claim 4, characterized in that the method further comprises:

During the running of the process incubator, the system service process and the desktop launcher, the startup of the operating system is not completed;

Based on the incomplete startup of the operating system, the data partition is mounted based on N-P mount parameters, where P is greater than or equal to K, and at least one mount parameter among the N-K mount parameters is different from a mount parameter among the N-P mount parameters;

After the data partition is successfully mounted based on the N-P mounting parameters, the process incubator, the system service process and the desktop launcher are run.

6. The method according to claim 4, characterized in that the method further comprises:

During the running of the process incubator, the virtual machine of the operating system is started.

7. The method according to claim 4, characterized in that the method further comprises:

In the process of running the system service process, the service of the operating system is started.

8. The method according to claim 4, characterized in that the method further comprises:

During the running of the desktop launcher, based on the completion of the booting of the operating system, the finishBooting function is called to set the flag bit sys.boot_completed to be valid.

9. The method according to any one of claims 1 to 3, characterized in that the method further comprises:

After the data partition is successfully mounted based on the N-K mounting parameters, an exception flag is set to be valid, and when the exception flag is valid, it means that the data partition is not mounted through the N mounting parameters.

10. The method according to claim 9, characterized in that the method further comprises:

After the operating system is started, based on the validity of the abnormal flag, a first interface is displayed, wherein the first interface includes information indicating that the memory of the electronic device is damaged.

11. The method according to claim 10, characterized in that the method further comprises:

In response to a user's operation of backing up data in the first interface, at least a portion of the data in the data partition is backed up.

12. The method according to claim 1 is characterized in that the N mount parameters include at least one of the following mount parameters: rw, seclabel, nosuid, nodev, noatime, background_gc=on, discard, no_heap, user_xattr, inline_xattr, acl, inline_data, inline_dentry, extent_cache, mode=adaptive, active_logs=6, inlinecrypt, alloc_mode=default, fsync_mode=nobarrier.

13. The method according to claim 1, wherein mounting the data partition based on N-K mounting parameters comprises:

The data partition is mounted using a mount command, wherein the mount command includes the N-K mount parameters.

14. A readable storage medium, characterized in that the readable storage medium includes instructions, and when the instructions are executed by an electronic device, the electronic device implements the method according to any one of claims 1 to 13.

15. An electronic device, comprising:

A memory for storing instructions;

At least one processor is used to execute the instructions so that the electronic device implements the method according to any one of claims 1 to 13.