CN111596930A - Root file system mirror image manufacturing method and device, storage medium and embedded device - Google Patents
Root file system mirror image manufacturing method and device, storage medium and embedded device Download PDFInfo
- Publication number
- CN111596930A CN111596930A CN202010445778.9A CN202010445778A CN111596930A CN 111596930 A CN111596930 A CN 111596930A CN 202010445778 A CN202010445778 A CN 202010445778A CN 111596930 A CN111596930 A CN 111596930A
- Authority
- CN
- China
- Prior art keywords
- directory
- root
- file system
- embedded device
- file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
- G06F8/63—Image based installation; Cloning; Build to order
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The application relates to the technical field of embedded development and provides a root file system mirror image manufacturing method and device, a storage medium and embedded equipment. The method for manufacturing the mirror image of the root file system comprises the following steps: switching a current directory of a source embedded device to a first directory where a storage device connected with the device is located; creating a mirror image file in a first directory, and formatting the mirror image file; creating a second directory in the first directory; mounting the formatted mirror image file into a second directory; synchronizing files belonging to a root file system under a root directory of the source embedded equipment into a second directory; and unloading the image file from the second directory. The method is executed on the real embedded equipment, so that the environment for manufacturing the root file system mirror image is more consistent with that of the target embedded equipment, the manufactured root file mirror image has good compatibility, and can be normally used without reconfiguration after being burned on the target embedded equipment.
Description
Technical Field
The invention relates to the technical field of embedded development, in particular to a root file system mirror image manufacturing method and device, a storage medium and embedded equipment.
Background
The embedded system mainly includes three parts, which are root file system (root file system), kernel (kernel) and boot loader (bootloader). In Linux, a root file system is the first file system mounted (mount) when a kernel is started, and if the root file system is not provided, an application program in an embedded device cannot run.
In the prior art, a virtual machine simulating a target embedded device is generally deployed on a development host, and then a root file system is created on the virtual machine and an image is made. However, due to the difference between the virtual machine and the real device environment, the manufactured root file system image is abnormal or needs to be reconfigured after being burnt on the target embedded device.
Disclosure of Invention
An object of the present invention is to provide a method and an apparatus for making a root file system image, a storage medium, and an embedded device, so as to improve the above technical problems.
In order to achieve the above purpose, the present application provides the following technical solutions:
in a first aspect, an embodiment of the present application provides a method for making a root file system image, including: switching a current directory of a source embedded device to a first directory where a storage device connected with the source embedded device is located, wherein the source embedded device is a device which needs to make a root file system of the source embedded device as a mirror image; creating a mirror image file in the first directory, and formatting the mirror image file; creating a second directory in the first directory; mounting the formatted mirror image file into the second directory; synchronizing files belonging to the root file system under a root directory of the source embedded device into the second directory; and unloading the image file from the second directory.
In the method, after the mirror image file is mounted in the second directory, the files synchronized in the second directory (i.e., the files belonging to the root file system of the source embedded device) are all saved in the mirror image file, so that the completion of the file synchronization also means that the mirror image production of the root file system of the source embedded device is completed, the produced mirror image file is saved in the storage device, and when necessary, the mirror image can be further burnt to the target embedded device by the storage device (e.g., the device which has completed hardware assembly but does not yet contain the embedded system).
The method carries out mirror image manufacturing on real embedded equipment (source embedded equipment), so that compared with a virtual machine mode, the environment for manufacturing the root file system mirror image is more consistent with that of the target embedded equipment, the manufactured root file mirror image has better compatibility, can be normally used after being burnt on the target embedded equipment, and does not need to be reconfigured. Meanwhile, the mirror image manufacturing process is simple and efficient and is easy to master by technicians.
In an implementation manner of the first aspect, the source embedded device has the same model as a target embedded device that needs to write the root file system image.
In the implementation mode, the source embedded device and the target embedded device are the same type of device, so that the environment of the target embedded device can be considered to be completely simulated on the source embedded device, and the root file system image manufactured in the environment can be directly burnt on the target embedded device for normal use. Of course, before the mirror image is manufactured, the test can be performed on the source embedded device to ensure that the root file system can operate normally.
In an implementation manner of the first aspect, the synchronizing, to the second directory, files belonging to the root file system in the root directory of the source embedded device includes: synchronizing files located under a root directory of the source embedded device and not in an exclude directory into the second directory as files belonging to the root file system.
The files in some subdirectories under the root directory may be files created and used by the embedded system during operation, and these files are operated in the memory of the source embedded device and may not be considered as a part of the root file system, so that in the above implementation, these subdirectories may be listed in the exclusion directory, and the files under the subdirectories listed in the exclusion directory are not synchronized when synchronizing the files.
In an implementation manner of the first aspect, the synchronizing, to the second directory, files belonging to the root file system in the root directory of the source embedded device includes: and synchronizing the content and the attribute of the file belonging to the root file system in the root directory of the source embedded equipment into the second directory.
In one implementation of the first aspect, the attribute of the file includes at least one of file permission, file owner group, soft link, and hard link.
In both implementations, the meaning of synchronizing files is not limited to synchronization of file content, but also includes synchronization of file attributes. The inventor finds that if the file content is simply copied when synchronizing the files of the root file system, the attributes of the files may change, which causes an exception or needs to be reconfigured after the manufactured image of the root file system is programmed onto the target embedded device.
In an implementation manner of the first aspect, the synchronizing, to the second directory, files belonging to the root file system in the root directory of the source embedded device includes: and synchronizing files belonging to the root file system under the root directory of the source embedded device into the second directory by using a data mirror image backup tool rsync.
The rsync is a data mirror image backup tool in the Linux system and supports incremental backup. When the file is synchronized, some commands and parameters preset by the tool can be directly utilized for synchronization.
In one implementation manner of the first aspect, the image file is an empty file with a fixed size.
A fixed-size empty file is understood to mean that a storage space is applied in the storage medium of the storage device, which storage space, in combination with the subsequent formatting step, is understood to mean a specially created partition for storing the root file system. For example, in one common implementation, the size of the image file may be 4 GB.
In a second aspect, an embodiment of the present application provides a root file system image creating apparatus, including: the device comprises a directory switching module, a storage module and a processing module, wherein the directory switching module is used for switching a current directory of a source embedded device to a first directory where a storage device connected with the device is located, and the source embedded device is a device which needs to make a root file system of the source embedded device into a mirror image; the mirror image creating module is used for creating a mirror image file in the first directory and formatting the mirror image file; a directory creation module for creating a second directory in the first directory; the mirror image mounting module is used for mounting the formatted mirror image file into the second directory; the file synchronization module is used for synchronizing files belonging to the root file system under the root directory of the source embedded equipment into the second directory; and the image unloading module is used for unloading the image file from the second directory.
In a third aspect, an embodiment of the present application provides a computer-readable storage medium, where computer program instructions are stored on the computer-readable storage medium, and when the computer program instructions are read and executed by a processor, the computer program instructions perform the method provided by the first aspect or any one of the possible implementation manners of the first aspect.
In a fourth aspect, an embodiment of the present application provides an embedded device, including: a memory in which computer program instructions are stored, and a processor, where the computer program instructions are read and executed by the processor to perform the method provided by the first aspect or any one of the possible implementation manners of the first aspect.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments of the present application will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and that those skilled in the art can also obtain other related drawings based on the drawings without inventive efforts.
Fig. 1 is a schematic diagram illustrating a production scenario of a root file system image according to an embodiment of the present application;
FIG. 2 is a flowchart illustrating a method for mirroring a root file system according to an embodiment of the present disclosure;
FIG. 3 is a block diagram of a root file system mirroring apparatus according to an embodiment of the present application;
fig. 4 shows a structure diagram of an embedded device according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. It should be noted that: like reference numbers and letters refer to like items in the following figures, and thus, once an item is defined in one figure, it need not be further defined and explained in subsequent figures.
The terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such 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. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element. The terms "first," "second," and the like are used solely to distinguish one from another and are not to be construed as indicating or implying relative importance.
Fig. 1 shows a schematic diagram of a production scenario of a root file system image according to an embodiment of the present application. Referring to fig. 1, the scenario includes a source embedded device 100, a storage device 110, and a target embedded device 120.
In the present application, a newly proposed method for making a root file system image needs to be executed on the source embedded device 100, and the root file system of the source embedded device 100 itself is made into an image. The storage device 110 is used to store the manufactured image file, and the storage device 110 may be independent from the source embedded device 100, for example, may be a usb disk, a mobile hard disk, and the like, and is connected thereto through an interface on the source embedded device 100, but it is not excluded that the storage device 110 is integrated with the source embedded device 100, and even the storage device 110 is only a storage component in the source embedded device 100. The target embedded device 120 refers to a device that needs to write a root file system image, that is, the final use of the manufactured root file system image, and usually, an embedded system is not installed on the target embedded device 120. In practice, there may be multiple target embedded devices 120, i.e., one manufactured image may be written to multiple target embedded devices 120.
The scheme of the present application mainly describes how to make a root file system image on the source embedded device 100 and how to save the image in the storage device 110, and for how to write the image in the storage device 110 into the target embedded device 120, reference may be made to the implementation in the prior art, and detailed description is not given. As to the possible specific structure of the source embedded device 100, reference may be made to the following description of fig. 4, and a detailed description thereof will not be provided here.
Fig. 2 shows a flowchart of a method for making a root file system image according to an embodiment of the present application. The method may be executed on the source embedded device (which refers to execution in an embedded system on the device), and may be executed in different ways: for example, the method can be executed by inputting instructions by a user under an embedded system of the source embedded device; for another example, the instruction for creating the root file system may be written into a script, and the script may be run under the embedded system of the source embedded device to automatically complete creation of the root file system image. Referring to fig. 2, the method includes:
step S200: and switching the current directory of the source embedded equipment to a first directory where the storage equipment connected with the equipment is located.
If the connection relationship between the storage device and the source embedded device is not persistent (for example, the storage device is a usb disk), the storage device should be connected to the source embedded device (for example, a usb disk is inserted into the source embedded device) before step S200 is executed, so that the source embedded device can access data from the storage device. After the storage device is connected to the source embedded device, in order to operate the storage device on the source embedded device, the current directory needs to be switched to the directory where the storage device is located, which is not named as the first directory. For example, in a Linux system, the switching directory may employ cd commands.
Step S210: creating a mirror image file in the first directory and formatting the mirror image file.
The image file is used to store the root file system of the source embedded device, and of course, when step S210 is executed, only the image file is created, and the root file system is not stored in the file (for example, an empty file may be created). The file name of the mirror file can be named freely, for example, for the convenience of distinguishing from other types of files, it can be named rootfs. When the image file is created, a fixed size, such as 4GB, may be specified for the image file, so that the operation of creating the image file may also be understood as applying for a block of storage space in the storage medium of the storage device for storing the root file system. For example, a fixed-size empty file may be created by command dd in a Linux system.
Thereafter, a file system may be created in the image file and the image file may be formatted, for example, an ext4 file system may be created and formatted by a command mkfs. The file system creation and formatting are understood to be two operations executed synchronously, or the creation of the file system in the image file is completed while the image file is formatted.
As mentioned above, the image file can be regarded as a block of storage space applied in the storage medium of the storage device, but if the file access is to be performed in this block of storage space, a file system needs to be established and formatted in advance, so that the file written in the storage space can be effectively managed. Similarly to creating a hard disk partition on a computer, it must be formatted (the file system type needs to be selected while formatting, for example, NTFS, FAT32 and the like may be selected in Windows) and then used, where the storage space corresponding to the image file may also be understood as a partition, and the created file system is used to manage the files in the partition (as will be known later, the managed object is a file belonging to the root file system of the source embedded device). It is emphasized that the file system created here is for use in an image file and is not to be confused with the root file system of the source embedded device, and for ease of understanding, the creation of a file system here can also be viewed as an operation that specifies a file system type for a partition.
Step S220: a second directory is created in the first directory.
Step S230: and mounting the formatted mirror image file into a second directory.
The above two steps are described in conjunction. In the Linux system, an mkdir command can be used for creating a directory, and a mount command can be used for mounting a file into a certain directory. After the mirror image file is mounted in the second directory, the file synchronized in the second directory (referring to the file belonging to the root file system of the source embedded device, see step S240 specifically) is stored in the mirror image file, so that the completion of the file synchronization also means that the manufacturing of the mirror image of the root file system is completed.
Step S240: and synchronizing files belonging to the root file system under the root directory of the source embedded equipment into the second directory.
In one implementation, the files under the root directory of the source embedded device may all be considered part of the root file system, so that they may all be synchronized into the second directory. The file referred to herein includes both the file directly under the root directory of the embedded device and the files in the subdirectories under the root directory of the embedded device, and when synchronizing the files, the directory structure of the files is also copied into the second directory.
In another implementation, the files under the root directory of the source embedded device are not considered to all be part of the root file system. Because the files in some subdirectories under the root directory may be created and used by the embedded system during operation, these files are run in the source embedded device memory and may not be considered part of the root file system. Thus, an exclusion directory for file synchronization operation can be set, for example, a file can be created on the source embedded device for recording the exclusion directory, a name or a file name of a subdirectory which is listed in the root directory of the source embedded device and does not need synchronization is excluded, and an item recorded in the exclusion directory is skipped when the file synchronization operation is performed, and synchronization is not performed. Wherein if a certain subdirectory is skipped, the files under that directory are all out of sync.
The above-mentioned file synchronization may refer to only the content of the synchronization file. Or may include both synchronization of the file content and synchronization of the file attributes, where synchronization may be understood as an intact copy. The file attribute, as referred to herein, may include at least one of file authority, file owner group, soft link, and hard link. The file authority can comprise three authorities of reading, writing and executing, each authority comprises that a file owner can read, write and execute, a group to which the file belongs can read, write and execute, and other users can read, write and execute; the file owner refers to the file owner; the file group refers to a group to which the file belongs; the hard link can be regarded as an alias created for the file, and the link file and the original file are actually the same file; the soft link is similar to a shortcut in the Windows system, and a pointer is established, namely the content of the link file is a pointer to the original file, but the soft link itself is not the original file.
The inventor has long studied and found that, when a file of a root file system is synchronized, if the content of the file is simply copied, the attribute of the file may change (for example, since the copying of the file needs to be performed by a user, the copying behavior may cause a change in a file owner and/or a file owner group), which may cause an exception after the manufactured image of the root file system is burned onto a target embedded device or may require reconfiguration (for example, some permission check on the file owner and/or the file owner group may not pass due to the change in the file owner and/or the file owner group). Therefore, when synchronizing files belonging to the root file system, it is also possible to synchronize together with the attributes of the files.
If the embedded operating system on the source embedded device is a Linux system, an rsync data mirror backup tool can be installed in the Linux system, and file synchronization is performed directly by using some commands and parameters preset by the rsync data mirror backup tool, for example, file synchronization operation is performed by using rsync-avx/Linux/commands.
The rsync tool also supports incremental as well as remote synchronization. In some implementations, the storage device mentioned in step S200 may also be a remote device (e.g., a computer), in which case, the connection relationship between the storage device and the source embedded device should be understood as a remote communication connection, in which case, the rsync tool may be installed on the storage device to perform file synchronization of the root file system.
It should be appreciated that rsync is only one tool that can be used for file synchronization, but not the only tool that can be employed.
Step S250: the image file is unloaded from the second directory.
After the synchronization of the files in step S240 is completed, the mirror image of the root file system is also manufactured, and at this time, the mirror image file needs to be unloaded from the second directory, and the unloading may be regarded as a reverse operation of the mounting in step S230, and in the Linux system, a umount command may be used to unload the file from a certain directory.
If the connection relationship between the storage device and the source embedded device is not persistent (for example, the storage device is a usb disk), the connection between the storage device and the source embedded device may also be released (for example, the usb disk is pulled out from the source embedded device) after step S250 is executed.
And storing the manufactured image file in a storage device, and further programming the image to the target embedded device from the storage device when needed.
According to the method for manufacturing the root file system mirror image, the mirror image is manufactured on the real embedded equipment, so that compared with a mode of manufacturing the mirror image on the virtual machine, the environment for manufacturing the root file system mirror image is more consistent with the target embedded equipment, the manufactured root file mirror image is better in compatibility, can be normally used after being burnt on the target embedded equipment, and does not need to be reconfigured. Meanwhile, the mirror image manufacturing process is simple and efficient and is easy to master by technicians.
Furthermore, the method is directly based on the root file system on the real embedded device, the mirror image is manufactured in a file synchronization mode, when the mirror image of the root file system is manufactured, the file content and the file attribute can be completely synchronized, the root file system of the source embedded device is ensured to be cloned into the mirror image file, and the problem that the root file system cannot be normally used after being burnt to the target embedded device due to the difference between the root file system in the mirror image file and the root file system of the source embedded device is solved. In contrast, if an image is created based on the root file system of the virtual machine, since the root file system of the virtual machine is different from the root file system of the real embedded device, especially there may be a difference in file attributes, even if the image file is created, the root file system of the target embedded device may be abnormal in the running process due to the difference after the image file is programmed into the target embedded device.
In addition, in some alternatives, the source embedded device may also adopt a device of the same model as the target embedded device, and at this time, the environment of the target embedded device can be completely simulated on the source embedded device, so that the root file system image manufactured in such an environment can be directly burned on the target embedded device for normal use. Of course, before the mirror image is manufactured, sufficient testing can be performed on the source embedded device to ensure that the root file system can operate normally.
Furthermore, the source embedded device in the application can be used for manufacturing a root file system mirror image and can also be used as a development and test platform of software on an embedded system, and because the embedded system is installed on the source embedded device, related software can run normally. If the source embedded device is to be used for development testing, certain hardware support may be required, and reference may be made to the description of fig. 4. In contrast, if the virtual machine is used as a development and test platform of the embedded system, since the virtual machine cannot completely simulate the hardware of the real embedded device, some software related to the hardware may not run or test normally (if the software unrelated to the hardware generally has no such problem), but the development and test platform using the source embedded device as the software can avoid such problem. Particularly, if the source embedded device and the target embedded device are of the same type, the source embedded device can effectively simulate the hardware environment of the actual running of the software, so that the software can be tested more effectively.
Finally, it is pointed out that, in the development of embedded systems, the virtual machine platform still occupies an absolute dominant position, so that the deployment of the virtual machine is flexible and convenient, various hardware environments are easy to simulate, the hardware development and testing are not necessarily completed during the software development and testing, and the real embedded equipment may be in an unavailable state, so that the software development and testing can be performed only by using the virtual machine. However, the virtual machine platform is not a real device after all, and has its own limitations, such as the various defects indicated above, therefore, after long-term research, the inventors consider that performing embedded system mirroring on a real embedded device (including root file system mirroring in the present solution) and performing related software development testing are better options than using a virtual machine platform on the premise that the real embedded device is available and the real embedded device supports performing development testing, which is different from the conventional knowledge in the art.
Fig. 3 is a functional block diagram of a root file system mirroring apparatus 300 according to an embodiment of the present application. Referring to fig. 3, the root file system image creating apparatus 300 includes:
the directory switching module 310 is configured to switch a current directory of a source embedded device to a first directory where a storage device connected to the source embedded device is located, where the source embedded device is a device that needs to make a root file system of the source embedded device as a mirror image;
a mirror image creating module 320, configured to create a mirror image file in the first directory, and format the mirror image file;
a catalog creation module 330, configured to create a second catalog in the first catalog;
a mirror image mounting module 340, configured to mount the formatted mirror image file into the second directory;
a file synchronization module 350, configured to synchronize files belonging to the root file system in the root directory of the source embedded device into the second directory;
and an image unloading module 360, configured to unload the image file from the second directory.
In one implementation of the apparatus 300 for manufacturing a root file system image, the source embedded device has the same model as a target embedded device that needs to write the root file system image.
In an implementation manner of the root file system mirroring apparatus 300, the file synchronization module 350 synchronizes files belonging to the root file system in the root directory of the source embedded device into the second directory, including: synchronizing files located under a root directory of the source embedded device and not in an exclude directory into the second directory as files belonging to the root file system.
In an implementation manner of the root file system mirroring apparatus 300, the file synchronization module 350 synchronizes files belonging to the root file system in the root directory of the source embedded device into the second directory, including: and synchronizing the content and the attribute of the file belonging to the root file system in the root directory of the source embedded equipment into the second directory.
In one implementation of the root file system image production apparatus 300, the attributes of the file include at least one of file permissions, file owner group, soft link, and hard link.
In an implementation manner of the root file system mirroring apparatus 300, the file synchronization module 350 synchronizes files belonging to the root file system in the root directory of the source embedded device into the second directory, including: and synchronizing files belonging to the root file system under the root directory of the source embedded device into the second directory by using a data mirror image backup tool rsync.
In one implementation of the root file system image production device 300, the image file is an empty file of a fixed size.
The implementation principle and the resulting technical effect of the root file system image creation apparatus 300 provided in the embodiment of the present application have been introduced in the foregoing method embodiments, and for the sake of brief description, reference may be made to corresponding contents in the method embodiments where no part of the apparatus embodiments is mentioned.
Fig. 4 shows a possible structure of an embedded device 400 provided by the embodiment of the present application. Referring to fig. 4, the embedded device 400 includes: processor 410, memory 420, communication interface 430, input device 440, and output device 450, interconnected and in communication with each other via communication bus 460 and/or other form of connection mechanism (not shown).
The Memory 420 includes one or more (Only one is shown in the figure), which may be, but not limited to, a Random Access Memory (RAM), a Read Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a FLASH Memory (FLASH Memory ), and the like. The processor 410, as well as possibly other components, may access, read, and/or write data to the memory 420.
The processor 410 includes one or more (only one shown) which may be an integrated circuit chip having signal processing capabilities. The Processor 410 may be a general-purpose Processor, and includes a Central Processing Unit (CPU), a Micro Control Unit (MCU), a Network Processor (NP), or other conventional processors; or a special-purpose Processor, including a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable logic device, a discrete Gate or transistor logic device, and a discrete hardware component.
The input device 440 is used to input external instructions or data into the embedded device 400. Input devices 440 may include a keyboard, mouse, touch screen, or the like. For example, if the input device 440 includes a keyboard, the steps of the root file system mirroring method provided by the embodiment of the present application may be entered and executed by a user in a manner of instructions.
The output device 450 is used to output internal instructions or data to the outside of the embedded device 400. Output device 450 may include a display screen, a speaker, etc. For example, if the output device 450 includes a display screen, the instruction corresponding to the root file system image production method provided in the embodiment of the present application may be displayed on the display screen, so that the user can browse the instruction.
One or more computer program instructions may be stored in memory 420 and read and executed by processor 410 to implement the root file system mirroring method provided by embodiments of the present application, as well as other desired functions.
It will be appreciated that the configuration shown in FIG. 4 is merely illustrative and that the embedded device 400 may also include more or fewer components than shown in FIG. 4 or have a different configuration than shown in FIG. 4. The components shown in fig. 4 may be implemented in hardware, software, or a combination thereof. For example, the embedded device 400 may be a smart phone, a smart wearable device, a smart appliance, an in-vehicle device, a robot, a drone, or the like.
In the embodiment of the present application, the source embedded device may be implemented by using the structure of the embedded device 400. In some implementations, the source embedded device may have a certain development capability, that is, besides the input device 440 and the output device 450 required for development, certain requirements may be preset on the processing performance of the processor 410 and the storage capability of the memory 420, so as to be able to directly create a root file system for the target embedded device on the source embedded device, and to directly develop, compile, test, and run various types of software for the target embedded device on the source embedded device. It can be understood that, although the source embedded device may adopt a device of the same type as the target embedded device, it does not mean that all components of the source embedded device are necessarily identical to those of the target embedded device, for example, an embedded device of a certain type itself does not have a Universal Serial Bus (USB) keyboard (an input device), and a USB keyboard may be added to implement development functions when the embedded device is used as the source embedded device, but a state without the USB keyboard may be maintained when the embedded device is used as the target embedded device.
The embodiment of the present application further provides a computer-readable storage medium, where computer program instructions are stored on the computer-readable storage medium, and when the computer program instructions are read and executed by a processor of a computer, the method for making a root file system image according to the embodiment of the present application is executed. The computer-readable storage medium may be implemented as the memory 420 in the embedded device 400 in fig. 4, for example.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and there may be other divisions when actually implemented, and for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of devices or units through some communication interfaces, and may be in an electrical, mechanical or other form.
In addition, units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
Furthermore, the functional modules in the embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.
The above description is only an example of the present application and is not intended to limit the scope of the present application, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application shall be included in the protection scope of the present application.
Claims (10)
1. A method for making a root file system mirror image is characterized by comprising the following steps:
switching a current directory of a source embedded device to a first directory where a storage device connected with the source embedded device is located, wherein the source embedded device is a device which needs to make a root file system of the source embedded device as a mirror image;
creating a mirror image file in the first directory, and formatting the mirror image file;
creating a second directory in the first directory;
mounting the formatted mirror image file into the second directory;
synchronizing files belonging to the root file system under a root directory of the source embedded device into the second directory;
and unloading the image file from the second directory.
2. The method of claim 1, wherein the source embedded device is of the same type as a target embedded device that needs to write the root file system image.
3. The method for mirroring a root file system according to claim 1, wherein the synchronizing files belonging to the root file system under a root directory of the source embedded device into the second directory comprises:
synchronizing files located under a root directory of the source embedded device and not in an exclude directory into the second directory as files belonging to the root file system.
4. The method for mirroring a root file system according to claim 1, wherein the synchronizing files belonging to the root file system under a root directory of the source embedded device into the second directory comprises:
and synchronizing the content and the attribute of the file belonging to the root file system in the root directory of the source embedded equipment into the second directory.
5. The method of claim 4, wherein the attributes of the file include at least one of file permissions, file owner group, soft link, and hard link.
6. The method for mirroring a root file system according to claim 1, wherein the synchronizing files belonging to the root file system under a root directory of the source embedded device into the second directory comprises:
and synchronizing files belonging to the root file system under the root directory of the source embedded device into the second directory by using a data mirror image backup tool rsync.
7. The root file system mirroring method according to any one of claims 1 to 6, wherein the mirror file is a fixed size empty file.
8. An apparatus for making a root file system image, comprising:
the device comprises a directory switching module, a storage module and a processing module, wherein the directory switching module is used for switching a current directory of a source embedded device to a first directory where a storage device connected with the device is located, and the source embedded device is a device which needs to make a root file system of the source embedded device into a mirror image;
the mirror image creating module is used for creating a mirror image file in the first directory and formatting the mirror image file;
a directory creation module for creating a second directory in the first directory;
the mirror image mounting module is used for mounting the formatted mirror image file into the second directory;
the file synchronization module is used for synchronizing files belonging to the root file system under the root directory of the source embedded equipment into the second directory;
and the image unloading module is used for unloading the image file from the second directory.
9. A computer-readable storage medium having computer program instructions stored thereon, which when read and executed by a processor, perform the method of any one of claims 1-7.
10. An embedded device, comprising: a memory having stored therein computer program instructions which, when read and executed by the processor, perform the method of any of claims 1-7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010445778.9A CN111596930B (en) | 2020-05-22 | 2020-05-22 | Root file system mirror image manufacturing method and device, storage medium and embedded device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010445778.9A CN111596930B (en) | 2020-05-22 | 2020-05-22 | Root file system mirror image manufacturing method and device, storage medium and embedded device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111596930A true CN111596930A (en) | 2020-08-28 |
| CN111596930B CN111596930B (en) | 2023-03-28 |
Family
ID=72181313
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010445778.9A Active CN111596930B (en) | 2020-05-22 | 2020-05-22 | Root file system mirror image manufacturing method and device, storage medium and embedded device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111596930B (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112328571A (en) * | 2020-11-25 | 2021-02-05 | 创新奇智(重庆)科技有限公司 | Object storage method and device, communication equipment and storage medium |
| CN112363795A (en) * | 2020-10-13 | 2021-02-12 | 南京赛宁信息技术有限公司 | Method and system for quickly starting virtual machine of network security practical training platform |
| CN115033525A (en) * | 2021-03-05 | 2022-09-09 | 荣耀终端有限公司 | File system management method and electronic equipment |
| CN115202830A (en) * | 2022-09-09 | 2022-10-18 | 统信软件技术有限公司 | Root file system preparation method, system, computing device and readable storage medium |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015070521A1 (en) * | 2013-11-12 | 2015-05-21 | 上海斐讯数据通信技术有限公司 | Method for making ubi format system file into factory burnt image file |
| CN109783117A (en) * | 2019-01-18 | 2019-05-21 | 中国人民解放军国防科技大学 | Mirror image file making and starting method of diskless system |
-
2020
- 2020-05-22 CN CN202010445778.9A patent/CN111596930B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2015070521A1 (en) * | 2013-11-12 | 2015-05-21 | 上海斐讯数据通信技术有限公司 | Method for making ubi format system file into factory burnt image file |
| CN109783117A (en) * | 2019-01-18 | 2019-05-21 | 中国人民解放军国防科技大学 | Mirror image file making and starting method of diskless system |
Non-Patent Citations (2)
| Title |
|---|
| XIAODONG LEE: "Scaling the number of DNS root servers with Internet", 《THE 6TH IEEE INTERNATIONAL WORKSHOP ON MANAGEMENT OF EMERGING NETWORKS AND SERVICES》 * |
| 罗波: "Cobbler实现基于Linux内核的操作系统自动部署", 《信息与电脑》 * |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112363795A (en) * | 2020-10-13 | 2021-02-12 | 南京赛宁信息技术有限公司 | Method and system for quickly starting virtual machine of network security practical training platform |
| CN112363795B (en) * | 2020-10-13 | 2021-11-26 | 南京赛宁信息技术有限公司 | Method and system for quickly starting virtual machine of network security practical training platform |
| CN112328571A (en) * | 2020-11-25 | 2021-02-05 | 创新奇智(重庆)科技有限公司 | Object storage method and device, communication equipment and storage medium |
| CN115033525A (en) * | 2021-03-05 | 2022-09-09 | 荣耀终端有限公司 | File system management method and electronic equipment |
| CN115033525B (en) * | 2021-03-05 | 2023-06-09 | 荣耀终端有限公司 | File system management method and electronic equipment |
| CN115202830A (en) * | 2022-09-09 | 2022-10-18 | 统信软件技术有限公司 | Root file system preparation method, system, computing device and readable storage medium |
| CN115202830B (en) * | 2022-09-09 | 2022-12-30 | 统信软件技术有限公司 | Root file system preparation method, system, computing device and readable storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111596930B (en) | 2023-03-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111596930B (en) | Root file system mirror image manufacturing method and device, storage medium and embedded device | |
| US6138179A (en) | System for automatically partitioning and formatting a primary hard disk for installing software in which selection of extended partition size is not related to size of hard disk | |
| US9483492B2 (en) | Terminal and method for providing application-related data | |
| US20150378849A1 (en) | Method and device for backing up, restoring a virtual machine | |
| KR20000052313A (en) | Computing system and operating method for booting and running a graphical user interface(gui) with r/w hard drive partition unavailable | |
| CN103218227B (en) | The method of compatible multiple file system and device on a kind of Android device built-in hard disk | |
| CN110998517B (en) | System and method for customized operating system conversion | |
| CN103186387B (en) | Electronic installation and its method for updating OS | |
| CN101620542B (en) | Compatible updating method of ultrasonic imaging equipment software data | |
| US20120221609A1 (en) | Data Storage System and Method | |
| US10877681B2 (en) | Systems and methods for redundant array data alignment | |
| CN113821221B (en) | Method, apparatus and storage medium for installing operating system | |
| US20190187977A1 (en) | Dual boot operating system installation using multiple redundant drives | |
| CN104407890A (en) | Method for starting Android system from OTG (On-The-Go) equipment | |
| CN104049914A (en) | Method and device for executing write operation on protected partition | |
| US9459883B2 (en) | Modifying disk images | |
| CN106775485A (en) | The method and system that a kind of SD card based on mobile terminal is formatted | |
| CN114356504A (en) | Data migration method and device in cluster, electronic equipment and storage medium | |
| CN108334453B (en) | File debugging method and device, terminal equipment and storage medium | |
| CN109634690A (en) | Data clearing method, device, terminal and storage medium based on WinPE system | |
| CN109117167A (en) | A kind of starting Oftware updating method based on ZYNQ chip | |
| CN114443060A (en) | Operating system deployment method and system | |
| CN1952890B (en) | Starting method of computer and computer apparatus using the same | |
| CN116028100B (en) | Software version upgrading method and electronic equipment | |
| CN114443150B (en) | Method, system, terminal and storage medium for synchronizing factory information of switch |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| CB02 | Change of applicant information |
Address after: Room 501, block a, Haier International Plaza, 939 Zhenwu Road, Jimo Economic Development Zone, Qingdao, Shandong 266200 Applicant after: Qingdao Chuangxin Qizhi Technology Group Co.,Ltd. Address before: Room 04, 02 / F, building 4, software industry base, Yuehai street, Nanshan District, Shenzhen City, Guangdong Province Applicant before: SHENZHEN AINNOVATION TECHNOLOGY Co.,Ltd. |
|
| CB02 | Change of applicant information | ||
| CB02 | Change of applicant information |
Address after: Room 501, block a, Haier International Plaza, 939 Zhenwu Road, Jimo Economic Development Zone, Qingdao, Shandong 266200 Applicant after: Qingdao Chuangxin Qizhi Technology Group Co.,Ltd. Address before: Room 501, block a, Haier International Plaza, 939 Zhenwu Road, Jimo Economic Development Zone, Qingdao, Shandong 266200 Applicant before: Qingdao Chuangxin Qizhi Technology Group Co.,Ltd. |
|
| CB02 | Change of applicant information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |