A method for decoupling a Linux operating system image from peripheral device drivers
By using external driver repositories and grub parameters, new driver versions are automatically loaded and installed during the Linux operating system installation phase, resolving driver incompatibility issues caused by hardware updates and achieving seamless driver upgrades and normal system startup.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- KYLIN CORP
- Filing Date
- 2026-05-14
- Publication Date
- 2026-06-12
AI Technical Summary
In Linux operating systems, driver incompatibility during hardware updates can cause system startup failures or network connectivity issues. Current technologies require cumbersome image creation and verification processes.
By using an external driver repository, new driver versions are loaded seamlessly during the operating system installation phase and automatically installed into the operating system after successful installation. The automatic loading and installation of drivers are achieved using grub parameters and the systemd service.
Automatic driver loading and installation can be achieved without updating the base image, reducing operation and maintenance costs, simplifying the image creation process, and ensuring normal system startup and automatic driver upgrades.
Abstract
Description
Technical Field
[0001] This invention relates to the field of driver update technology, specifically a method for decoupling Linux operating system images from peripheral drivers. Background Technology
[0002] Operating system vendors need to update and upgrade various drivers during routine maintenance. When a driver is incompatible with the hardware, or when the hardware is updated but the driver is not yet updated, the system will fail to load the driver. If the driver, such as the graphics card or network card, has a problem, it may cause the system to fail to power on or the network to fail to connect.
[0003] There are two ways to update operating system drivers. One is to manually update the drivers directly on the machine with the target image installed. The other is to update the driver files based on the existing image, including the driver package files and the driver files in the initrd. After updating, a new image file is created and then installed. The first method is obviously the fastest, but it's only suitable if the system can still boot normally even without the target driver, such as the sound card driver. If the graphics card hardware has been updated, the system may fail to power on. The second method can solve this problem, but it involves a tedious image creation and verification process. Summary of the Invention
[0004] To address the aforementioned issues, the present invention aims to provide a method for decoupling Linux operating system images from peripheral drivers. Based on the Linux operating system, without updating the original base image, the method automatically loads drivers from an external driver repository during the operating system installation phase without any noticeable impact, and then proceeds to the system installation interface normally. Furthermore, after successful system installation, the method automatically installs the successfully loaded driver packages into the operating system.
[0005] This invention discloses a method for decoupling Linux operating system images and peripheral drivers, characterized by comprising the following steps: Step S1: Obtain the base image and the new version driver; compile the new version driver based on the kernel of the base image to obtain the .ko file of the new version driver; the base image contains the original driver corresponding to the new version driver; Step S2: Store the new version driver's .ko file and the new version driver's software package in the external driver repository; Step S3: Connect the installation media carrying the base image and the external repository media carrying the external drive repository to the device, enter the operating system installation program and set the grub parameters; Step S4: Mount the external driver repository to the device; if the external driver repository is successfully mounted to the device, create a hidden file in the external driver repository and proceed to step S5; if the external driver repository is not successfully mounted to the device, load the original driver directly and then proceed to step S6. Step S5: Determine and load the new version driver and the original driver; If a new version driver exists in the external driver repository, load the new version driver based on the .ko file of the new version driver in the external driver repository, and store the information of the successfully loaded new version driver in a hidden file, and then execute step S6; If a new version driver does not exist in the external driver repository or the new version driver fails to load, load the original driver, and then execute step S6. Step S6: Install the operating system on the device based on the base image; Step S7: After the operating system is successfully installed, the newly loaded driver version will be installed. The installation of the new driver version is based on the hidden files and the new driver version software package.
[0006] Furthermore, step S1 includes the following steps: Step S11: Obtain the base image and the new driver version; Step S12: Compile the new version driver based on the kernel in the initrd of the base image to obtain the ko file of the new version driver; the initrd of the base image contains the original driver.
[0007] Furthermore, step S2 includes the following steps: Step S21: Obtain an external repository medium, format it as a file system format, and set the label of the external repository medium to DRIVER-REPO; Step S22: Create a driver directory in the external repository media and copy the external driver repository to the driver directory; Step S23: Save the new version driver's .ko file and the new version driver's software package into the new version driver directory in the driver directory.
[0008] Furthermore, step S3 includes the following steps: Step S31: Connect the installation media carrying the base image and the external storage media carrying the external drive warehouse to the device; Step S32: Start the device and enter the operating system installation program from the installation media; Step S33: After entering the operating system installation program from the installation media, add DRIVER_INHANCE_MODE and nomodeset to the grub parameters in the grub interface, and then execute step S4.
[0009] Furthermore, step S4 includes the following steps: Step S41: Load the initrd and kernel from the base image and execute the init script; Step S42: Launch the dracut-init-modules.sh script based on the init script; Step S43: The dracut-init-modules.sh script mounts the external driver repository to the device using the cmdline parameter; if the external driver repository is successfully mounted to the device, a hidden file is created in the external driver repository, and then step S5 is executed; if the external driver repository is not successfully mounted to the device, step S6 is executed.
[0010] Furthermore, in step S5, the determination and loading of the new version driver and the original driver are based on the module-load.sh script.
[0011] Furthermore, in step S43, if the external driver repository is not successfully mounted to the device, it is determined whether the operating system can enter the installation program normally. If the operating system can enter the installation program normally, the operating system executes the installation program normally. If the operating system cannot enter the installation program normally, step S1 is executed again.
[0012] Furthermore, in step S6, after the operating system is installed, the external driver repository is mounted to the chroot environment of the installed operating system.
[0013] Furthermore, in step S7, in the chroot environment of the operating system, the new version driver software package is found through the new version driver information in the hidden file, and the new version driver is installed into the operating system through the new version driver software package.
[0014] Furthermore, step S8 is included: after the operating system completes the installation of the new version driver or the original driver, the operating system restarts and checks the installed new version driver through modinfo.
[0015] The beneficial effects of this invention are: 1. This invention loads new driver versions by mounting them from an external driver repository. Each successfully loaded driver will be marked and the corresponding software package will be installed into the system after installation, without the need for special re-integration of the image to achieve driver updates or upgrades. 2. This invention uses the systemd service to start the dracut service during the initrd stage to specifically identify and mount external driver repositories, and the normal startup of the operating system is not affected regardless of whether this service is started or whether the corresponding script is executed successfully. 3. This invention loads external drivers through the grub parameter "DRIVER_INHANCE_MODE". After the coldplug in the initrd stage, the external driver mounting and loading are completed, realizing seamless driver upgrades for users. The entire image driver upgrade process only requires the user to add the driver loading entry in the grub stage, which greatly reduces the cost of operation and maintenance and image integration. Detailed Implementation
[0016] The technical solutions in the embodiments of the present invention will be clearly and completely described below. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention may also be implemented in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.
[0017] The purpose of this invention is to provide a method for decoupling Linux operating system images and peripheral drivers. Based on the Linux operating system, without updating the original base image, the method automatically loads drivers from an external driver repository during the operating system installation phase without any noticeable difference, and then enters the system installation interface normally. After the system is successfully installed, the successfully loaded driver packages are automatically installed into the operating system.
[0018] This invention discloses a method for decoupling Linux operating system images and peripheral drivers, primarily consisting of five parts: an external driver repository, an external driver loading entry point, a systemd service, an initrd driver loading section, and a driver installation to the target system section. The external driver repository includes driver module files (.ko files) for drivers that need updating (new version drivers) to the current kernel, as well as the software packages for the new version drivers that need to be installed after the driver update. The external driver loading entry point is accessed via grub parameters, allowing the dracut service in the initrd driver loading section to further determine whether the external driver repository has a specific label name to decide whether to execute the external driver repository loader. The systemd service section is mainly used to obtain the loading and startup of the dracut service and external driver services, providing pre-scheduling and environment preparation for the subsequent initrd driver loading section. The initrd driver loading section provides the driver loader, including an additional initrd external driver loading module executed by the dracut service and the original default initrd internal driver loading module. The initrd external driver loading module and the default initrd internal driver loading module are used to load the new version drivers from the external driver repository and the original drivers from the default initrd, respectively. The driver installation to the system section mainly involves installing the newly loaded driver version from the initrd after the operating system is installed.
[0019] The main idea of this invention, a method for decoupling Linux operating system images and peripheral drivers, is as follows: When hardware is updated, the corresponding hardware drivers that need to be supported also need to be updated. At this time, a base image with outdated drivers cannot be installed normally. Currently, an old version image (base image) and a new version driver are available. An external driver repository is created based on the kernel of the old version base image, and a specific label is set so that the driver loader provided by the initrd in the old version base image can recognize and automatically mount the external driver repository. After the system enters the GRUB interface, two GRUB parameters are set: DRIVER_INHANCE_MODE and nomodeset. nomodeset is primarily used to resolve compatibility issues that may exist with older graphics card drivers. DRIVER_INHANCE_MODE is used by the initrd to determine whether to load external drivers: if DRIVER_INHANCE_MODE is not detected, the original driver within the default initrd is loaded normally, and the new version driver from the external driver repository will not affect the normal startup of the operating system. If DRIVER_INHANCE_MODE is detected, the external driver (the new version driver from the external driver repository) is loaded, and the information of the successfully loaded new version driver is written to a hidden file in the external driver repository, which is used to install the new version driver package at the end. If the new version driver is not found in the external driver repository, the original driver within the initrd is loaded by default.
[0020] Therefore, the driver loading part based on initrd in this invention is implemented in two parts: first, the dracut service provided by the systemd service (started by systemd) mounts the corresponding external driver repository after the device information coldplug; second, the driver loading rules in systemd-udev in systemd are used to load external drivers under specific circumstances and write the external driver information after successful loading into a hidden file.
[0021] When a user successfully boots into the installation's graphical environment using the base image and the new driver version, it indicates that the external driver has been successfully loaded. At this point, the user can proceed with the operating system installation normally. Upon completion, the installation script automatically checks if the command-line parameters include `DRIVER_INHANCE_MODE`. If so, it searches for hidden files, finds the successfully loaded new driver information within these files, and then locates and installs the corresponding installation package into the appropriate operating system. The user can then restart the system to obtain the system with the old image file and the new driver installed.
[0022] Coldplug can be understood as cold plugging and unplugging. When the operating system starts, the kernel detects and initializes all connected hardware devices (such as hard drives, USB devices, network cards, etc.). This process is called coldplug. Only after this process is completed will the corresponding device nodes (such as / dev / sda) be created for each device. This invention loads the driver part through initrd, coldplugs it first during the initrd stage, and then mounts the external driver repository, thus avoiding the problem of not being able to find device nodes in the initrd environment.
[0023] First embodiment: This invention discloses a method for decoupling Linux operating system images and peripheral drivers, comprising the following steps: Step S1: Obtain the base image and the new version driver; compile the new version driver based on the kernel of the base image to obtain the .ko file of the new version driver; the base image includes the original driver; The specific steps of step S1 are as follows: Step S11: Obtain the base image and the new driver version; Step S12: Compile the new version driver based on the kernel in the initrd of the base image to obtain the ko file of the new version driver; the initrd of the base image includes the original driver; Step S2: Store the new version driver's .ko file and the new version driver's software package in the external driver repository.
[0024] The specific steps of step S2 are as follows: Step S21: Obtain an external repository medium and format it to a file system format supported by initrd; set the label of the external repository medium to DRIVER-REPO; Step S22: Create a driver directory in the external repository media and copy the external driver repository to the driver directory; Step S23: In the external driver repository, create a new version driver directory and save the new version driver's .ko file and the new version driver's software package into the corresponding new version driver directory.
[0025] Step S3: Connect the installation media carrying the base image and the external repository media carrying the external drive repository to the device and set the grub parameters; Specifically, step S3 includes the following steps: Step S31: Connect the installation media carrying the base image and the external storage media carrying the external drive warehouse to the device; Step S32: Power on the device and select to boot from the installation media via BIOS; Step S33: After entering from the installation media, enter the grub interface, add DRIVER_INHANCE_MODE and nomodeset to the grub parameters in the grub interface, and then execute step S4.
[0026] Step S4: Mount the external driver repository to the device; if the external driver repository is mounted successfully, create a hidden file in the external driver repository, and then proceed to step S5; if the external driver repository fails to mount, load the original driver directly, and then proceed to step S6.
[0027] Step S4 includes the following steps: Step S41: Load the initrd and kernel of the base image and execute the init script; Step S42: Launch the dracut-init-modules.sh script based on the init script; Step S43: The dracut-init-modules.sh script mounts the external driver repository using the cmdline parameter; if the external driver repository is mounted successfully, a hidden file is created in the external driver repository, and then step S5 is executed; if the external driver repository fails to mount, step S6 is executed.
[0028] Step S5: Determining and loading the new driver version versus the original driver; if a new driver version exists in the external driver repository, load the new driver version based on its .ko file and store the successfully loaded driver information in a hidden file; if the external driver repository does not contain a new driver version or the new driver version fails to load, load the original driver. In this step, the determination and loading of the new driver version versus the original driver is based on the module-load.sh script.
[0029] Step S6: Install the operating system on the device based on the base image. After the operating system is installed, if the cmdline parameter contains DRIVER_INHANCE_MODE, then mount the external driver repository media with the label DRIVER-REPO to the chroot environment of the installed operating system.
[0030] Step S7: After the operating system is successfully installed and the external driver repository in the external driver repository media is successfully loaded, the new version driver will be installed. The installation of the new version driver is based on the hidden files and the new version driver software package.
[0031] Specifically, in the chroot environment of the operating system, the new driver package is found by using the information of the successfully loaded new driver version in the hidden file, and the new driver is installed into the operating system using the new driver package.
[0032] Step S8: Restart the system, enter the installed operating system, and check the newly installed driver version using modinfo.
[0033] Second embodiment: This embodiment is a specific implementation example: a method for decoupling Linux operating system images and peripheral drivers, including the following steps: Step S1: Before performing the operating system installation, obtain the base image and the drivers that need to be updated. Extract the initrd from the base image, compile the drivers that need to be updated (new version drivers) based on the kernel in the initrd, and obtain the ko file corresponding to the drivers that need to be updated. The ko file is used to build an external driver repository ( / lib / modules / (uname -r)). Burn the base image to the installation media.
[0034] Step S2: Prepare an external repository medium (USB flash drive or hard drive), format it to a file system format supported by initrd (e.g., ext4), and set its Label to DRIVER-REPO. Create a driver directory in the external repository medium and copy the external driver repository to the driver directory. Create a directory named "updates" under " / driver / lib / modules / (uname -r)" in the driver directory of the external driver repository. Create the driver directory that needs to be updated in the "updates" directory. Place the pre-compiled .ko files into the corresponding driver directories that need to be updated, and put all the missing dependencies into them. Execute the "depmod" command in the driver directory to regenerate the driver dependencies. Place the software package of the driver that needs to be updated into the corresponding driver directory. The software package of the driver that needs to be updated and the .ko file of the driver that needs to be updated should be in the same directory.
[0035] Step S3: Connect the installation media and the external warehouse media to the machine (the device to be installed), start the machine (power on), select to enter from the installation media through the BIOS, press 'e' in the grub interface to enter edit mode, add DRIVER_INHANCE_MODE and nomodeset to the grub parameters, and then press F10 to enter.
[0036] Step S4: Load initrd and kernel, execute init script. In the server version, init script is a systemd service. The systemd service starts the dracut-init-modules.service service, which in turn starts the dracut-init-modules.sh script. The dracut-init-modules.sh script parses cmdline parameters and, after completing the coldplug process, mounts the external driver repository in the external repository media and creates a hidden file .install_driver_device after successful mounting.
[0037] Step S5: Driver loading phase. The systemd service loads drivers during the initrd phase through the 80-drivers.rules file in the / lib / udev / rules.d directory. That is, the loading of each driver will be performed by executing the kmod load operation through the 80-drivers.rules file. On the original driver loading mechanism, the / usr / lib / udev / module-load.sh script is added, and the original kmod load $env(MODALIAS) is modified to / usr / bin / bash / usr / lib / udev / module-load.sh $env(MODALIAS) $devpath, where $env(MODALIAS) is the name of the driver to be loaded, and $devpath represents the relative path of the driver in the sysfs file system ( / sys).
[0038] The `module-load.sh` script performs the following operations: For the read-in driver, it first searches in the external driver repository. If a corresponding driver that needs updating is found in the external driver repository, it loads the driver that needs updating from the external driver repository first. If the driver that needs updating is loaded successfully, it skips the driver already in the initrd. If the driver that needs updating fails to load, it loads the original driver (the driver already in the initrd) normally. It then writes the entire `$devpath` of the successfully loaded drivers that need updating from the external driver repository into the hidden file `.install_driver_device`.
[0039] Step S6: Enter the operating system installation program based on the installation media. If the operating system successfully enters the installation program and all the drivers that need to be updated can run normally, then the operating system installation program will be executed normally.
[0040] When the operating system installation is complete, it checks whether the / proc / cmdline parameter contains the DRIVER_INHANCE_MODE parameter. If the / proc / cmdline parameter does not contain this parameter, it exits normally. If the / proc / cmdline parameter contains this parameter, it mounts the external driver repository with the label DRIVER-REPO to the chroot environment of the installed operating system. Step S7: In the chroot environment, find the name of the driver that needs to be updated that has been successfully loaded under sysfs through the hidden file .install_driver_device in the mounted external driver repository, then find the corresponding package in the external driver repository by the driver name, and install the driver that needs to be updated into the chroot environment of the operating system by package installation.
[0041] Step S8: After completing the driver updates, restart the operating system and check the installed drivers that need updating using modinfo.
[0042] Third embodiment: In this embodiment, in step S4, after the systemd service starts the dracut-init-modules.service service, a judgment sub-step will also be performed; The decision sub-step checks whether the grub parameters contain `DRIVER_INHANCE_MODE`. If `DRIVER_INHANCE_MODE` is present, the subsequent steps proceed normally. If `DRIVER_INHANCE_MODE` is not present, the subsequent steps are skipped, and the existing drivers contained in the initrd are loaded normally. Then, it checks whether the operating system can successfully enter the installation program. If the operating system can successfully enter the installation program, the installation process proceeds normally. If the operating system cannot successfully enter the installation program, step S1 is re-executed.
[0043] In step S4, if the dracut-init-modules.sh script fails to mount the external driver repository in the corresponding external repository medium via the cmdline parameter, it will also determine whether the operating system can enter the installation program normally. If the operating system can enter the installation program normally, the operating system will execute the installation process normally. If the operating system cannot enter the installation program normally, step S1 will be executed again.
[0044] In the operating system installation process of this invention, upon receiving a user's driver update request, the operating system will automatically detect whether there are devices with a specific label in the system devices. If so, it will mount and set them as external driver repositories; otherwise, it will start according to the normal boot process. After mounting the external driver repository, drivers will be loaded in the order of first loading drivers from the external driver repository, and then loading the original drivers. If the driver in the external driver repository is loaded successfully, the path of the driver in the sys directory is saved in a hidden file in the repository. If the external driver cannot be loaded or fails to load, the original driver file will be loaded instead.
[0045] Originally, the image was missing driver files or had outdated driver versions. However, after the system installation environment loaded the new drivers, it successfully entered the installer and executed the installation process normally. In the final stage of the operating system installation process, the installer checks the GRUB parameters to determine whether to install or upgrade external drivers. If successful, it finds the corresponding package in the external driver repository through hidden files and installs it into the system. The entire process is automated. Users only need to add the GRUB parameters after obtaining the base image and external driver repository; no other operations are required, making it simple, convenient, and safe.
[0046] Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.
Claims
1. A method for decoupling Linux operating system images and peripheral drivers, characterized in that, Includes the following steps: Step S1: Obtain the base image and the new driver version; The new version of the driver is compiled from the kernel based on the base image to obtain the .ko file of the new version of the driver; The base image contains the original driver corresponding to the new version of the driver; Step S2: Store the new version driver's .ko file and the new version driver's software package in the external driver repository; Step S3: Connect the installation media carrying the base image and the external repository media carrying the external drive repository to the device, enter the operating system installation program and set the grub parameters; Step S4: Mount the external drive warehouse to the device; If the external driver repository is successfully mounted to the device, a hidden file is created in the external driver repository, and step S5 is executed. If the external driver repository is not successfully mounted to the device, the original driver will be loaded directly, and then step S6 will be executed. Step S5: Determine and load the new version driver and the original driver; If a new version driver exists in the external driver repository, load the new version driver based on the .ko file of the new version driver in the external driver repository, and store the information of the successfully loaded new version driver in a hidden file, and then execute step S6; If a new version driver does not exist in the external driver repository or the new version driver fails to load, load the original driver, and then execute step S6. Step S6: Install the operating system on the device based on the base image; Step S7: After the operating system is successfully installed, the newly loaded driver version will be installed. The installation of the new driver version is based on the hidden files and the new driver version software package.
2. The method for decoupling Linux operating system image and peripheral driver according to claim 1, characterized in that, Step S1 includes the following steps: Step S11: Obtain the base image and the new driver version; Step S12: Compile the new version driver based on the kernel in the initrd of the base image to obtain the ko file of the new version driver; the initrd of the base image contains the original driver.
3. The method for decoupling Linux operating system image and peripheral driver according to claim 2, characterized in that, Step S2 includes the following steps: Step S21: Obtain an external repository medium, format it as a file system format, and set the label of the external repository medium to DRIVER-REPO; Step S22: Create a driver directory in the external repository media and copy the external driver repository to the driver directory; Step S23: Save the new version driver's .ko file and the new version driver's software package into the new version driver directory in the driver directory.
4. The method for decoupling Linux operating system image and peripheral driver according to claim 3, characterized in that, Step S3 includes the following steps: Step S31: Connect the installation media carrying the base image and the external storage media carrying the external drive warehouse to the device; Step S32: Start the device and enter the operating system installation program from the installation media; Step S33: After entering the operating system installation program from the installation media, add DRIVER_INHANCE_MODE and nomodeset to the grub parameters in the grub interface, and then execute step S4.
5. The method for decoupling Linux operating system image and peripheral driver according to claim 4, characterized in that, Step S4 includes the following steps: Step S41: Load the initrd and kernel from the base image and execute the init script; Step S42: Launch the dracut-init-modules.sh script based on the init script; Step S43: The dracut-init-modules.sh script mounts the external driver repository to the device using the cmdline parameter; if the external driver repository is successfully mounted to the device, a hidden file is created in the external driver repository, and then step S5 is executed; if the external driver repository is not successfully mounted to the device, step S6 is executed.
6. The method for decoupling Linux operating system image and peripheral driver according to claim 5, characterized in that, In step S5, the determination and loading of the new version driver and the original driver are based on the module-load.sh script.
7. The method for decoupling Linux operating system image and peripheral driver according to claim 5, characterized in that, In step S43, if the external driver repository is not successfully mounted to the device, it is determined whether the operating system can enter the installation program normally. If the operating system can enter the installation program normally, the operating system executes the installation program normally. If the operating system cannot enter the installation program normally, step S1 is executed again.
8. The method for decoupling Linux operating system image and peripheral driver according to claim 5, characterized in that, In step S6, after the operating system is installed, the external driver repository is mounted to the chroot environment of the installed operating system.
9. A method for decoupling Linux operating system image and peripheral driver according to claim 8, characterized in that, In step S7, within the chroot environment of the operating system, the new version driver package is located through the new version driver information in the hidden file, and the new version driver is installed into the operating system using the new version driver package.
10. A method for decoupling Linux operating system image and peripheral driver according to claim 1, characterized in that, It also includes step S8: After the operating system completes the installation of the new version driver or the original driver, it restarts the operating system and checks the installed new version driver through modinfo.