A method for updating CF card operating system

Abstract

The present invention discloses a method for updating a CF card operating system. The method comprises the following steps: deleting and recreating an extlinux file on a CF card using a debugfs tool of a Linux system, adding a boot parameter rd.live.ram to make the CF card readable and writable; updating the operating system kernel, initrd, and extlinux files in the CF card; and updating the boot parameter rd.live.ram of the extlinux file. After the upgrade, the initrd finds the root file system located in the root partition of a hard disk. After the initrd completes preparations, the pivot_root instruction is executed to switch to the root file system of the root partition, thereby upgrading the running CF card operating system. The present invention can upgrade the operating system without removing the CF card, thus avoiding the drawbacks of service suspension and factory re-burning.

Description

Technical Field

[0001] The invention belongs to the technical field of storage device system update, and in particular relates to a method for updating a CF card operating system. Background Art

[0002] Due to its open-source nature, low software licensing fees, and abundant application development resources, the Linux system has gained widespread adoption and is finding a growing number of users in consumer, office, and development settings. The CF card (Compact Flash) revolutionized the storage device by utilizing flash memory, offering permanent data storage, no power requirements, high speed, light weight, low power consumption, and compact size. CF cards can be directly installed into the on-chip controller interface, lacking a driver or moving parts, minimizing mechanical failure and enhancing data security. This makes them an excellent and versatile storage system. The portable controller makes CF cards compatible with a variety of platforms, making them suitable for software manufacturers to produce operating system images containing their software products. Simply inserting a CF card into a computer's CF card slot boots the Linux operating system. However, later upgrading the operating system on an already-produced CF card requires removing the card and returning it to the manufacturer to re-burn a new operating system.

[0003] Upgrading the Linux operating system on a CF card is much more difficult than upgrading a regular Linux operating system. This is primarily because, by default, during the boot process, the initrd mounts squahsFS read-only to the CF card directory instead of loading it into memory, which can severely impact system performance. Therefore, the CF card is not writable while the operating system is running. To upgrade, you must shut down the system, stop the running operating system, remove the CF card, and then burn the new operating system to the CF card for the upgrade. This inevitably impacts ongoing services.

[0004] The prior art CN200710043619.0 discloses a method for updating a flash memory operating system based on a memory card of a mobile device. The flash memory operating system needs to be re-burned through the memory card on the mobile device. The system needs to be powered off when updating the operating system. This method is not suitable for upgrading devices that have already left the factory because it means that the CF card must be returned to the factory for re-burning and the programs running in the system must be forced to stop.

[0005] SquashFS is a compressed, read-only file system used by the Linux kernel. Its size typically exceeds 1GB, and after decompression, it can reach several GB. In a CF card operating system, SquashFS resides on the CF card and is decompressed and mounted during system startup. Mounting it directly to the CF card directory renders the card read-only and prevents write operations. Loading it into memory, however, allows reading and writing to the card. However, SquashFS can reach several GB in size, and loading it into memory can severely impact system performance.

[0006] Therefore, the present invention provides a CF card operating system update method, which can upgrade the CF card operating system while it is running without removing the CF card or turning off the power, thereby ensuring the continuous operation of the running program. Summary of the Invention

[0007] The purpose of the present invention is to provide a method for updating a CF card operating system, aiming to solve the above problems.

[0008] The present invention is mainly achieved through the following technical solutions:

[0009] A method for updating a CF card operating system comprises the following steps:

[0010] Step S100: Upload the upgrade package to the computer with the CF card inserted, the upgrade package including the operating system kernel, initrd, root file system, extlinux file and update script;

[0011] Step S200: Run the upgrade package, decompress the upgrade package, run the update script, and perform the update;

[0012] Step S300: The initrd of the CF card will choose whether to mount squahsFS according to the value of the boot parameter rd.live.ram in extlinux. First, the old extlinux file on the CF card is deleted using the debugfs of the Linux system, a new extlinux file is created, and the boot parameter rd.live.ram=1 is added. During the startup process, the squashFS image in the CF card is copied to the memory for execution, making the CF card readable and writable.

[0013] Step S400: backing up files in the CF card and the computer hard disk to prevent data loss due to subsequent operation failures;

[0014] Step S500: Replace the operating system kernel, initrd, and extlinux files in the CF card, and modify the boot parameter rd.live.ram of the extlinux file so that initrd can find the root file system on the hard disk partition after the upgrade, switch to the root file system, and decompress the root file system of the new operating system to the hard disk partition to implement the operating system update.

[0015] In order to better implement the present invention, further, in step S500, another partition in the hard disk is selected as the root partition of the new operating system, and the root partition is the partition where the root file system is located; the partition is formatted and the partition label is set to root so that the root file system of the new operating system can be decompressed to the hard disk partition.

[0016] In order to better implement the present invention, further, in the step S500, when modifying the boot parameter rd.live.ram of the extlinux file, the original boot parameter rd.live.ram=1 is deleted, and then a new kernel parameter is added to inform the kernel of the location of the new root file system, the modified rd.live.ram=LABEL=root, so that initrd can find the root file system located in the root partition on the hard disk after the upgrade, and after initrd completes the preparation work, execute the pivot_root instruction to switch to the root file system of the root partition.

[0017] In order to better implement the present invention, step S300 further includes the following steps:

[0018] Step S301: the newly created extlinux on the CF card reads the extlinux boot file, passes kernel parameters to the kernel according to the configuration file, loads the kernel and initializes the memory;

[0019] Step S302: The kernel converts the initrd into a normal memory file system and releases the memory used by the initrd;

[0020] Step S303: initrd is mounted as root, and the CF card is given read and write permissions.

[0021] In order to better implement the present invention, further, step S500 includes the following steps:

[0022] Step S501: linuxrc is executed and any executable file is initialized;

[0023] Step S502: Linuxrc decompresses the SquashFS image in the CF card and mounts the real root file system in read-only mode;

[0024] Step S503: linuxrc uses the pivot_root system call to put the root file system in the root directory;

[0025] Step S504: executing a normal startup program on the root file system;

[0026] Step S505: After the upgrade is successful, remove the initrd file system.

[0027] In order to better implement the present invention, further, in step S500, after the decompression is successful, the squashFS image file on the CF card is deleted, because the system no longer needs to decompress and mount the squashFS, and deleting the squashFS file can save CF card space.

[0028] In order to better implement the present invention, further, if the system upgrade is successful, the backup file in step S400 is deleted.

[0029] The beneficial effects of the present invention are as follows:

[0030] (1) The present invention can upgrade the operating system without removing the CF card, thus avoiding the cost of business interruption and factory re-burning;

[0031] (2) The present invention can delete and recreate the extlinux file on the CF card through the debugfs tool of the Linux system, and add the boot parameter rd.live.ram=1 to make the CF card readable and writable; it does not directly replace the files in the CF card through debugfs, which greatly reduces the risk during the upgrade process;

[0032] (3) The original CF card operating system uses a compressed read-only root file system. Due to the limited read and write speed of the CF card itself, its performance is not as good as that of the operating system installed on the hard disk. The present invention decompresses the new root file system directly to the hard disk, making the new operating system far better than the old operating system in terms of read and write performance. At the same time, the kernel and initrd are still retained in the CF card, which can retain the original CF card operating system's ability to be compatible with hard disk arrays (RAID) or encrypted hard disk scenarios.

[0033] (4) This invention decompresses the new root file system onto the hard disk and deletes the old squashFS on the CF card, eliminating the need to decompress and mount the squashFS during subsequent boots. This simplifies future upgrades, ensuring that the CF card remains readable and writable. It also saves space on the CF card, ensuring sufficient space for the new kernel and initrd. Finally, it improves the operating system's read and write performance. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 Flowchart of the present invention. DETAILED DESCRIPTION

[0035] Example 1:

[0036] A method for updating a CF card operating system, such as Figure 1 As shown, the following steps are included:

[0037] Step S100: Upload the upgrade package to the computer with the CF card inserted, the upgrade package including the operating system kernel, initrd, root file system, extlinux file and update script;

[0038] Step S200: Run the upgrade package, decompress the upgrade package, run the update script, and perform the update;

[0039] Step S300: The initrd of the CF card will choose whether to mount squahsFS according to the value of the boot parameter rd.live.ram in extlinux. First, the old extlinux file on the CF card is deleted using the debugfs of the Linux system, a new extlinux file is created, and the boot parameter rd.live.ram=1 is added. During the startup process, the squashFS image in the CF card is copied to the memory for execution, making the CF card readable and writable.

[0040] Step S400: backing up files in the CF card and the computer hard disk to prevent data loss due to subsequent operation failures;

[0041] Step S500: Replace the operating system kernel, initrd, and extlinux files in the CF card, and modify the boot parameter rd.live.ram of the extlinux file so that initrd can find the root file system on the hard disk partition after the upgrade, switch to the root file system, and decompress the root file system of the new operating system to the hard disk partition to implement the operating system update.

[0042] Preferably, in step S500, another partition in the hard disk is selected as the root partition of the new operating system, where the root partition is the partition where the root file system is located; the partition is formatted and the partition label is set to root so that the root file system of the new operating system can be decompressed to the hard disk partition.

[0043] Preferably, in step S500, when modifying the boot parameter rd.live.ram of the extlinux file, the original boot parameter rd.live.ram=1 is deleted, and then a new kernel parameter is added to inform the kernel of the location of the new root file system, the modified rd.live.ram=LABEL=root, so that initrd can find the root file system located in the root partition on the hard disk after the upgrade, and after initrd completes the preparation work, execute the pivot_root instruction to switch to the root file system of the root partition.

[0044] Preferably, in step S500, after the decompression is successful, the squashFS image file on the CF card is deleted, because the system no longer needs to decompress and mount the squashFS, and deleting the squashFS file can save CF card space.

[0045] The present invention can upgrade the operating system without pulling out the CF card, avoiding the cost of business suspension and returning to the factory for re-burning. The present invention can delete and recreate the extlinux file on the CF card through the debugfs tool of the Linux system, and add the boot parameter rd.live.ram=1 to make the CF card readable and writable; it does not directly replace the files in the CF card through debugfs, which greatly reduces the risk in the upgrade process. The original CF card operating system uses a compressed read-only root file system, which is limited by the read and write speed of the CF card itself, and its performance is not as good as the operating system installed on the hard disk. The present invention decompresses the new root file system directly to the hard disk, so that the new operating system has much better read and write performance than the old operating system; at the same time, the kernel and initrd are still retained in the CF card, which can retain the original CF card operating system's ability to be compatible with hard disk arrays (RAID) or encrypted hard disk scenarios.

[0046] Example 2:

[0047] A method for updating a CF card operating system utilizes the feature of debugfs to set a CF card to be readable and writable after startup. The extlinux file on the CF card can be deleted and recreated through the debugfs tool of the Linux system, and the boot parameter rd.live.ram=1 is added to make the CF card readable and writable.

[0048] Then, decompress the root file system of the new operating system to the hard disk. Replace the operating system kernel, initrd, and extlinux files in the CF card with those of the new operating system. Update the boot parameter rd.live.ram=LABEL=root in the extlinux file so that initrd can find the root file system in the root partition on the hard disk after the upgrade. After initrd completes its preparations, execute the pivot_root command to switch to the root file system in the root partition, thus upgrading the running CF card operating system.

[0049] Specifically, the steps of updating the CF card operating system are as follows:

[0050] ① The extlinux on the CF card reads the extlinux boot file, passes kernel parameters to the kernel according to the configuration file, loads the kernel and initializes the memory.

[0051] ② The kernel converts initrd into a normal memory file system and releases the memory used by initrd.

[0052] ③ initrd is mounted as root and granted read and write permissions.

[0053] ④ / linuxrc is executed (this can be any executable file, such as a script, running in uid 0, which can do any initialization).

[0054] ⑤ Linuxrc decompresses the SquashFS image in the CF card and mounts the real root file system in read-only mode. This step will make the CF card unwritable.

[0055] ⑥ linuxrc uses the pivot_root system call to place the root file system in the root directory.

[0056] ⑦ The normal startup program ( / sbin / init) is executed on the root file system.

[0057] ⑧ The initrd file system is removed.

[0058] The present invention can upgrade the operating system without removing the CF card, thus avoiding the cost of stopping business and returning the card to the factory for re-burning. The present invention can delete and recreate the extlinux file on the CF card through the debugfs tool of the Linux system, and add the boot parameter rd.live.ram=1 to make the CF card readable and writable; it does not directly replace the files in the CF card through debugfs, which greatly reduces the risk during the upgrade process. The original CF card operating system uses a compressed read-only root file system, which is limited by the read and write speed of the CF card itself, and its performance is not as good as that of the operating system installed on the hard disk. The present invention decompresses the new root file system directly to the hard disk, so that the new operating system has much better read and write performance than the old operating system; at the same time, the kernel and initrd are still retained in the CF card, which can retain the original CF card operating system's ability to be compatible with hard disk arrays (RAID) or encrypted hard disk scenarios.

[0059] Example 3:

[0060] A method for updating a CF card operating system, such as Figure 1 As shown, the following steps are included:

[0061] (1) The user uploads the upgrade package to the computer with the CF card inserted through the network and runs the upgrade package. The upgrade package contains the kernel, initrd, root file system, extlinux file and update script.

[0062] (2) Unzip the upgrade package, run the update script, and execute the update logic

[0063] The CF card initrd will choose whether to mount squashFS read-only based on the value of the live_ram boot parameter in extlinux. Therefore, first use debugfs to delete the old extlinux files on the CF card, create new extlinux files, and add the kernel boot parameter rd.live.ram=1. In the extlinux boot file, kernel parameters can be used to specify the root file system partition, livecd loading configuration, whether to enable RAID, and many other functions. The parameter rd.live.ram=1 causes the system to copy the squashFS image on the CF card to memory during startup, allowing the system to read and write to the CF card. After squashFS is loaded into memory, the CF card is no longer mounted read-only.

[0064] (3) Back up the data in the CF card and hard disk to an unused partition on the hard disk. This step is to prevent data loss that may occur when replacing the CF card file or decompressing the root file system fails.

[0065] (4) Select another partition on the hard disk as the root partition for the new operating system. The root partition is the partition where the new root file system is located. Format the partition, set the partition label to root, and decompress the root file system of the new operating system to the hard disk partition. If the decompression fails, roll back and restore the CF card and hard disk data.

[0066] (5) Delete the old squashFS file on the CF card. After the update, the system no longer needs to decompress and mount squashFS. Deleting the squashFS file can save space on the CF card. For some CF cards with smaller capacity, if this deletion step is not performed, the subsequent replacement of the CF card file may encounter insufficient capacity, resulting in replacement failure and upgrade abort. Replace the operating system kernel and initrd file in the CF card; modify the extlinux file. First, delete the original boot parameter rd.live.ram=1. After the update, the system is no longer in LiveCD format and the squashFS image is deleted in the previous step. Secondly, a new kernel parameter needs to be added to inform the kernel of the location of the new root file system. Because the new root file system is now located in the root partition on the hard disk, the kernel boot parameter root=LABEL=root needs to be added. In this way, after the upgrade is completed and the system is restarted, initrd can find the root file system located in the root partition on the hard disk, and execute the pivot_root command to switch to the root file system of the root partition after initrd completes the preparation work. If the replacement fails, roll back and restore the CF card data.

[0067] (6) After the upgrade is successful, delete the data in the backed-up CF card and hard disk and restart the computer.

[0068] Furthermore, the startup sequence of the CF card operating system is as follows:

[0069] ① Extlinux on the CF card reads the Extlinux boot file, passes kernel parameters to the kernel according to the configuration file, loads the kernel and initializes the memory

[0070] ② The kernel converts initrd into a normal memory file system and releases the memory used by initrd

[0071] ③ initrd is mounted as root and granted read and write permissions.

[0072] ④ / linuxrc is executed (this can be any executable file, such as a script, running in uid 0, which can do any initialization).

[0073] ⑤ Linuxrc decompresses the SquashFS image in the CF card and mounts the real root file system in read-only mode. This step will make the CF card unwritable.

[0074] ⑥ linuxrc uses the pivot_root system call to place the root file system in the root directory.

[0075] ⑦ The normal startup program ( / sbin / init) is executed on the root file system.

[0076] ⑧ The initrd file system is removed.

[0077] The Linux initial RAM disk (initrd) is a temporary root file system mounted during the system boot process to support the two-stage boot process. The root file system is the first file system mounted when the kernel starts. The kernel code image file is stored in the root file system. After the root file system is mounted, the system boot loader loads some basic initialization scripts and services into memory for execution.

[0078] The initrd file contains various executable programs and drivers. After completing tasks such as loading the driver module, the second stage will switch to the real root file system, execute the init program in the root file system, and complete the system startup. Then, the initrd RAM hard disk will be unloaded and the memory will be released. Linux distributions must adapt to various hardware architectures. It is unrealistic to compile all drivers into the kernel. Initrd technology is the key technology to solve this problem. Linux distributions only compile basic hardware drivers into the kernel. During the installation process, the system hardware is detected and the initrd containing the installed system hardware drivers is generated. This is nothing more than a feasible and flexible solution. Live CDs may face more complex hardware environments, so initrd must also be used.

[0079] Extlinux: Extlinux is a collection of boot loaders that can boot a system from a CF card. Supported file systems include FAT, ext2, ext3, ext4, and the uncompressed single-device Btrfs file system. When the computer boots, the BIOS first loads the 440-byte MBR boot code at the beginning of the hard drive ( / usr / lib / extlinux / bios / mbr.bin or / usr / lib / extlinux / bios / gptmbr.bin). This first-stage MBR boot code searches for an active partition (an MBR partition with the bootable flag set), which in this case is the boot partition on the CF card.

[0080] The MBR boot code executes the volume boot record (VBR) of the boot partition found above. For Extlinux, the VBR is the part of / boot / extlinux / ldlinux.sys located at the beginning sector created by the extlinux --install command.

[0081] Executing the / boot / extlinux / ldlinux.sys VBR will load the remaining components of ldlinux.sys. The sector location of ldlinux.sys must not be changed, otherwise Extlinux will fail to boot. Note that the above method will not work for Btrfs, as the location of the ldlinux.sys sector will constantly change due to file movement. Therefore, in Btrfs, the entire ldlinux.sys file is embedded directly within the Volume Boot Record, rather than being stored at / boot / syslinux / ldlinux.sys as in other file systems. ldlinux.sys then loads the remaining Extlinux kernel components, / boot / extlinux / ldlinux.c32 (this is partially due to file size limitations that prevent the inclusion of core modules within ldlinux.sys). The ldlinux.c32 file should be present in every instance of Extlinux installed and should match the version of ldlinux.sys in the partition; otherwise, Extlinux will fail to boot. Once Extlinux is fully loaded, it will automatically search for the boot configuration file extlinux.conf, load it if found, and search for the kernel and initrd files according to the configuration in extlinux.conf.

[0082] Debugfs is a virtual file system used for kernel debugging. It can directly create or delete inode nodes on the hard drive, unaffected by read-only mount restrictions. However, operating files using debugfs also carries significant risks. Because debugfs operates directly on the underlying inodes of the file system, a failure could damage the file system on the CF card, resulting in the loss of all files on the card and the immediate downtime of the operating system running on squashFS. Therefore, directly using debugfs to replace all files on the CF card is highly risky and cannot be used as a conventional method. Furthermore, since squashFS is occupied during operation by the operating system, debugfs cannot delete squashFS. The present invention uses the debugfs tool in the Linux system to delete and recreate extlinux files on the CF card. Adding the boot parameter rd.live.ram=1 makes the CF card readable and writable. Files on the CF card are not directly replaced using debugfs, significantly reducing the risks during the upgrade process. The present invention only uses debugfs to delete and create extlinux files. Since extlinux files are only a few dozen bytes in size, the risks of debugfs are minimized.

[0083] The original CF card operating system used a compressed, read-only root file system, which was limited by the read and write speed of the CF card itself and had inferior performance to an operating system installed on a hard drive. However, this invention decompresses the new root file system directly onto the hard drive, resulting in significantly better read and write performance for the new operating system than the old one. Furthermore, the kernel and initrd remain on the CF card, preserving the original CF card operating system's compatibility with RAID or encrypted hard drive scenarios.

[0084] Secondly, the present invention decompresses the new root file system onto the hard disk and deletes the old squashFS file system on the CF card, eliminating the need to decompress and mount the squashFS file system during subsequent boots. This simplifies future upgrades by ensuring the CF card remains readable and writable. It also saves space on the CF card, ensuring sufficient space for the new kernel and initrd. Finally, it improves the operating system's read and write performance.

[0085] The above description is only a preferred embodiment of the present invention and does not limit the present invention in any form. Any simple modification or equivalent change made to the above embodiment based on the technical essence of the present invention shall fall within the scope of protection of the present invention.

Claims

1. A method for updating a CF card operating system, characterized in that: The following steps are involved: Step S100: Upload the upgrade package to the computer with the CF card inserted, the upgrade package including the operating system kernel, initrd, root file system, extlinux file and update script; Step S200: Run the upgrade package, decompress the upgrade package, run the update script, and perform the update; Step S300: The initrd of the CF card will choose whether to mount squahsFS according to the value of the boot parameter rd.live.ram in extlinux. First, the old extlinux file on the CF card is deleted using the debugfs of the Linux system, a new extlinux file is created, and the boot parameter rd.live.ram=1 is added. During the startup process, the squashFS image in the CF card is copied to the memory for execution, making the CF card readable and writable. Step S400: backing up files in the CF card and the computer hard disk to prevent data loss due to subsequent operation failures; Step S500: Replace the operating system kernel, initrd, and extlinux files in the CF card, and modify the boot parameter rd.live.ram of the extlinux file so that initrd can find the root file system on the hard disk partition after the upgrade, switch to the root file system, and decompress the root file system of the new operating system to the hard disk partition to implement the operating system update.

2. The method for updating a CF card operating system according to claim 1, wherein: In step S500, another partition in the hard disk is selected as the root partition of the new operating system. The root partition is the partition where the root file system is located; the partition is formatted and the partition label is set to root so that the root file system of the new operating system can be decompressed to the hard disk partition.

3. The method for updating a CF card operating system according to claim 2, wherein: In step S500, when modifying the boot parameter rd.live.ram of the extlinux file, the original boot parameter rd.live.ram=1 is deleted, and then a new kernel parameter is added to inform the kernel of the location of the new root file system, the modified rd.live.ram=LABEL=root, so that initrd can find the root file system located in the root partition on the hard disk after the upgrade, and after initrd completes the preparation work, execute the pivot_root instruction to switch to the root file system of the root partition.

4. The method for updating a CF card operating system according to claim 3, wherein: The step S300 includes the following steps: Step S301: the newly created extlinux on the CF card reads the extlinux boot file, passes kernel parameters to the kernel according to the configuration file, loads the kernel and initializes the memory; Step S302: The kernel converts the initrd into a normal memory file system and releases the memory used by the initrd; Step S303: initrd is mounted as root, and the CF card is given read and write permissions.

5. The method for updating a CF card operating system according to claim 4, wherein: The step S500 includes the following steps: Step S501: linuxrc is executed and any executable file is initialized; Step S502: Linuxrc decompresses the SquashFS image in the CF card and mounts the real root file system in read-only mode; Step S503: linuxrc uses the pivot_root system call to put the root file system in the root directory; Step S504: executing a normal startup program on the root file system; Step S505: After the upgrade is successful, remove the initrd file system.

6. A method for updating a CF card operating system according to any one of claims 1 to 5, characterized in that: In step S500, after the decompression is successful, the squashFS image file on the CF card is deleted because the system no longer needs to decompress and mount the squashFS. Deleting the squashFS file can save CF card space.

7. The method for updating a CF card operating system according to claim 1, wherein: If the system upgrade is successful, the backup file in step S400 is deleted.

Images