At the core of the Ubuntu operating system is the Linux kernel, which manages and controls the hardware resources like I/O (networking, storage, graphics and various user interface devices, etc.), memory and CPU for your device or computer. It is one of the first software programs a booting device loads and runs on the central processing unit (CPU). The Linux kernel manages the system’s hardware environment so other programs like the operating system’s user space programs and application software programs can run well without modification on a variety of different platforms and without needing to know very much about that underlying system.
Identifying a kernel
The easiest way to determine the kernel you’re running is to type cat /proc/version_signature on the terminal. For example:
Ubuntu 5.4.0-12.15-generic 5.4.8
This output provides important information about the kernel:
- Canonical adds ” Ubuntu “
- Ubuntu kernel-release = 5.4.0-12.15-generic
- kernel version is 5.4 , which is identical to upstream stable kernel version
- .0 is an obsolete parameter left over from older upstream kernel version naming practices
- -12 application binary interface (ABI) bump for this kernel
- .15 upload number for this kernel
- -generic is kernel flavour parameter, where -generic is the default Ubuntu kernel flavour
Kernel and OS releases
Canonical provides long-term support (LTS) kernels for Ubuntu LTS releases. Canonical also provides interim operating system releases with updated kernels every 6 months.
For customers and business partners that don’t have specialised bleeding-edge workloads or latest hardware needs, the latest LTS release “-generic” kernel is the best option for them such as the 4.15 default kernel in Ubuntu 18.04 LTS. Customers who need the latest hardware support capability can install the latest HWE kernel such as the ones contained in interim releases, keeping in mind the shorter support lifespan associated with these kernels (9 months). HWE kernel customers are recommended to upgrade to a newer LTS release that supports their hardware and/or software needs as soon as it is available. Another option for customers is to use point releases. For example, there is an 18.04.4 point release as of February 2020, which includes an updated 5.3.x kernel but is also considered LTS, exactly like the original GA 4.15 kernel in 18.04.
The Canonical Kernel Team’s primary focus is the careful maintenance of kernels and their variants for regular delivery via the Ubuntu SRU process and the Canonical livepatch service. This includes rigorous management of all Linux kernel Common Vulnerabilities and Exposures (CVE) lists (with a focus on patching all high and critical CVEs) review and application of all relevant patches for all critical and serious kernel defects in the mailing lists and then rigorously testing newly updated kernels end-to-end each SRU cycle.
General Availability (GA) and variant Ubuntu kernels
The complete functionality of any given kernel is determined by the included modules and the kernel configuration for both hardware and the expected workloads that are run on it.
Kernel modules are binary programs that extend a kernel’s ability to control the computing system’s hardware or add additional system capabilities like high-performance networking or non-standard graphics, etc. The GA kernel that is shipped by default, with the Canonical Ubuntu Long Term Support (LTS) and Hardware Enablement (HWE) releases, are tuned for stable, reliable, secure, high-performance operation over a wide variety of hardware platforms and workloads.
A kernel variant is a kernel that deviates from the generic GA kernel by changes to its configuration, and/or by having modules added and/or removed.
Canonical advocates for customers to use the GA kernel shipped with Ubuntu as the best and most cost-effective option in their business environment. We also offer the option for customers to customize their own Ubuntu kernels. Several of our enterprise, Telco and cloud provider customers have systems and workload needs, which justify both the time investment to optimise their kernels and the pay to develop and maintain those optimised kernels over time.
© 2021 Canonical Ltd. Ubuntu and Canonical are registered trademarks of Canonical Ltd.
The Android build system doesn’t compile kernel on-fly. It just contains a prebuilt kernel binary which will be added to the target image. This approach may be good enough for the arm emulator target, but not suitable for x86 platforms. The x86 platforms have various hardware. The kernel binary and its modules may need to be adjusted at compile time or runtime.
This article explains an extra feature of the android-x86 build system. That is, the ability to build kernel and modules by a predefined or customized config during the building process.
Prepare the source tree
We have modified the Android build system to compile a kernel image on-fly. You need to use our repository to get this feature. Read the article for details.
Build the target default kernel
We put default configs of supported targets of android-x86 in kernel/arch/x86/configs/. The corresponding defconfig of a selected target will be used automatically. For example,
By specifying the TARGET_PRODUCT to android_x86_64, the build system automatically selects the config android-x86_64_defconfig to compile the kernel binary and its modules. The binary will be generated in out/target/product/x86_64/kernel, and the modules is put under out/target/product/x86_64/system/lib/modules/. The final target out/target/product/x86_64/android_x86_64.iso will contain the kernel binary and its modules.
Build and update kernel solely
To build the kernel and its modules solely, change the goal iso_img to kernel:
Then you can copy $OUT/kernel and $OUT/system/lib/modules/ to the target device. Put the former to the android-x86 installation directory, and the latter to /system/lib/modules. Note the /system must be installed as read-write mode.
Specify kernel architecture
Since Android 5.0 it supports both 32-bit and 64-bit images. Usually 32-bit userspace works with 32-bit kernel, while 64-bit userspace must work with 64-bit kernel. Android-x86 build system supports both since lollipop-x86.
Sometimes you may want to run 32-bit userspace with 64-bit kernel. In this case, you may specify kernel architecture by TARGET_KERNEL_ARCH:
Force recompilation of the kernel
Android and kernel use entirely different build systems. Though we combine them together, the integration doesn’t work very well. An example is if you modify the kernel tree, Android build system won’t notice the change. That means, the kernel won’t be rebuilt automatically if you rebuild the image.
There are several ways to overcome that. One is to touch the defconfig like:
Or remove the kernel config in the out/ directory:
Or remove the kernel image:
Replace the kernel
Since we build kernel with modules support, to replace the kernel of an installed system, you have to replace the corresponding modules as well. To do that, copy the kernel image to the android-x86 installation directory, and copy modules to /system/lib/modules. You can do that by booting to debug mode like:
Detecting Android-x86. found at /dev/sda1
Type ‘exit’ to continue booting.
Running MirBSD Korn Shell.
Use Alt-F1/F2/F3 to switch between virtual consoles
Type ‘exit’ to enter Android.
Running MirBSD Korn Shell.
mount /dev/sdb1 /hd
cp /hd/kernel /src
rm -rf /system/lib/modules/*
cp -a /hd/modules/* /system/lib/modules
sync; umount /hd; reboot -f
Build a customized kernel
Suppose you already have a workable kernel config for you hardware, it’s easy to tell the build system to use your config to build the iso. Just put your config file to kernel/arch/x86/configs/, and run (suppose the name of your config is my_defconfig)
Customize the kernel configuration
It is never advisable to edit the kernel config file directly, as it may generate faulty configuration (dependencies not met etc.). The correct way to customize the kernel config is (on the top of android-x86 tree)
If you get an error message Unknown option: -C, change make to /usr/bin/make. That’s because since Android 8 the build system overrides the default make command of the system by its own make function (to invoke soong rules) which doesn’t recognize the -C option. To overcome that, just use the make command of the system.
The generated config is $OUT/obj/kernel/.config. Copy it to where you want it to be.
DO NOT issue make menuconfig in the kernel/ directory directly. If you do so, the build rules may be broken. In this case, try this way to recover it (on the top of android-x86 tree):
Use a prebuilt kernel
If you have a workable prebuilt kernel binary for your hardware, you can generate the iso with it:
Compile kernel for ARM (deprecated)
The kernel build system can also be used to compile kernel for ARM. For example, to compile kernel 2.6.29 for the goldfish CPU of the arm emulator, run
Is there a list of Ubuntu versions with default corresponding Linux kernel versions somewhere?
I would specifically like to know the most recent version of Ubuntu that still used Linux Kernel 2.x.
6 Answers 6
- 16.04, 18.04, and 20.04 are the only currently supported releases (as of Aug 18, 2020).
- This lists the kernel version that ships with Ubuntu, but new minor versions may be installed during the Ubuntu installation if updates have been released since.
You can get the list of the Ubuntu versions and their corresponding kernels from Wikipedia:
kernel/info/kernel-version-map.html and this: launchpad.net/ubuntu/trusty/+package/… At the same time I have a laptop with Trusty Tahr whose kernel version is 3.19 (still receiving updates).
Take a look at this version table or this directory listing. I think that is what you are interested in.
You can see which packages are pre-installed as mentioned at: How to get a list of preinstalled packages?
Then, since I know that my kernel is located at: /boot/vmlinuz-4.4.0-141-generic, to find the package name I did:
So I just search for linux-image- in the .manifest and it gives:
so I conclude that Ubuntu 18.04 comes with Linux kernel 4.15.
If you search for the package name on Google: linux-image-4.15.0-29-generic , it also leads us to the packages.ubuntu.com page: https://packages.ubuntu.com/bionic/linux-image-4.15.0-29-generic
Then, on the breadcrumb navigation in that page, there is a link to the “kernels” section: https://packages.ubuntu.com/bionic/kernel/
And by searching for linux-image- in that page, we find several kernels that can be installed in the system.
I am planning to write some device drivers and I need to get the Linux kernel source. My Linux kernel version is 3.2.0-23-generic-pae and I downloaded the image from this. In many of the articles I have read, it tells me that I need to have the entire kernel tree to start inserting new modules.
Is it enough if I download this image and paste it into the usr/src/ folder or do I have to do something else?
4 Answers 4
This will get the source of the stock kernel:
You can check what version of the kernel is running like this:
Which will print something like:
You can find a list of current source package versions available on your system via:
To get the upstream version of the kernel:
In the above link, ‘trusty’ is the codename for the version of Ubuntu. You can find out the codename for the version of Ubuntu you have installed via:
is the easiest way. It will download the source from your repository – and it’ll be the same as the version you’re running (assuming you haven’t already customised it).
But if you want to find where the source is maintained you can run:
Look for the ‘Vcs-‘ attribute (Version control system). It’ll usually be a git (Vcs-Git) or mercurial repository.
Note – these commands work with any package. Just substitute ‘linux’ with the package you’re interested in. And also note that ‘apt-get source’ doesn’t need sudo access and will dump the source in your current directory.
It is not uncommon to see a custom version of Ubuntu deployed on multiple PCs in various for-profit and non-profit organizations. In order to make it easier to deploy a custom variant of Ubuntu, these organizations bake their changes in the Live CD or Live USB itself.
Usually it takes a lot of steps and tinkering to customize an Ubuntu Live CD if you go through command line route. However it is now much easier to create an Ubuntu Remix and distribute it as a Live CD to friends or colleagues, thanks to an excellent GUI app called Cubic.
Cubic is a graphical application featuring an integrated command line chroot environment terminal. It allows you to create a customized bootable Live ISO image from an existing Ubuntu ISO file and makes tweaking extremely easy by using a step by step navigation structure. You can navigate through your customization project using backward and forward buttons and quit any time you wish. Next time when you launch a Cubic project again, it will resume with all the previous customizations made by you in the ISO.
This article will walk you through all major customization options available in Cubic, tested with latest ISO image of Ubuntu 19.10. To install Cubic, run the commands below:
Launch it from application launcher and you will be greeted with a welcome screen. Enter a path to your desired project folder where all your customizations and final customized ISO will be stored.
On the next screen under “Original ISO…” field, click on “Select” button to choose an ISO image. Cubic will automatically populate all details and metadata in visible input boxes. You can change details under “Custom ISO…” field as per your requirements. By default, Cubic will assign a version number and date to your Custom ISO build.
Click the next button to see Cubic working on the original ISO to create an environment for customization.
Once the process is finished, you will be taken to a chroot terminal. Chroot allows you to run commands inside a sandboxed file system completely unaware and disconnected from any other file systems present on the system. Any changes made inside chroot affect root directory of its running processes and children only. Cubic passes all the changes made in chroot to the Live ISO.
Inside the chroot environment, we will begin by adding universe repository to increase the number of apps available to install:
You can now start customizing the ISO. Since Cubic creates a chroot for full Ubuntu filesystem extracted from the ISO, you can run all terminal commands that you would typically do in a full blown Ubuntu desktop installation. These customizations can be endless depending on your requirements, this article will touch only some of them. Lets install VLC app:
You can add a PPA repository and flatpak packages as well. Unfortunately, in my testing, Snap packages didn’t work at all. I was successful in installing them in chroot, but none of these packages ended up in the final ISO build. Let’s install Steam flatpak by running commands below in chroot:
Any files that you want to end up in custom ISO can be dragged on chroot window. One typical use case is to add additional wallpapers in “usr/share/backgrounds” directory. After you drag and drop a file on chroot window, a new window for uploading files appears. Click on “Copy” button to add files to the root of custom ISO filesystem.
Below is a small example where I have added a new wallpaper to /usr/share/backgrounds directory in the chroot filesystem.
Once you are done with chroot, click on the next button to reach advanced settings layout. The first tab allows you to select packages that you want to be removed after installation finishes from your customized live ISO.
The second tab allows you to select a specific kernel for the customized live ISO.
The third tab allows you to customize preseed files. These preseed files are used to automate installation. For example, if you are building this ISO for users in a specific time zone, you can modify preseed files to choose that time zone and it will be automatically selected during installation. It is possible to completely automate installation process by choosing predetermined values for every field in the default installer.
The last tab allows you to customise boot parameters and boot behaviour of the live ISO.
When you are finished with all the customizations, click on the “Generate” tab. You can always go to previous step during any stage of customization.
Finally, click on the finish button to end the customization of ISO image.
Cubic will then show all details and metadata about your custom ISO. Your customized build will be located in the project directory.
After booting into the custom ISO, we can see the customizations made in previous steps through Cubic.
To make any new customizations to an ISO already built by Cubic, just reopen the already existing project folder.
This marks the end of this article. Cubic is the only graphical ISO customization tool available today for Ubuntu. There have been other projects in the past, but development activities have ceased for them over time. The only other alternative to Cubic is to use numerous terminal commands to modify an Ubuntu ISO. But thanks to Cubic’s user friendly and intuitive interface, we don’t have to resort to lengthy and error prone command line mechanics to build an ISO.
About the author
I am a freelancer software developer and content writer who loves Linux, open source software and the free software community.
I have installed Ubuntu 17.10 on my notebook. However, I cannot connect to wi-fi because there is a “No Wi-Fi Adapter Found” message.
I don’t have any idea what to do next.
- My notebook : Asus X555LN-XX507H
- Network Adapter : Broadcom 802.11n BCM43142 (14e4:4365)
(This is a follow-on from my earlier post, https://unix.stackexchange.com/questions/415639/kali-linux-no-wifi-adapter-found, where I was advised to try an easier system than Kali.)
11 Answers 11
Just connect using usb cable to do usb tethering, open terminal by Ctrl+Alt+T and type:
So, the issue for me was because of secure-boot, uefi and the restriction on third party libraries which would be usually required for the network devices to work.
Following Rajat’s comment proved useful for me on Ubuntu 18.04
Reboot your OS and then follow instructions about Enrolling MUC. Once that is done, third party libraries should be able to interact with your devices and everything should work.
A problem with Broadcom BCM43142 (14e4:4365). the problem has been known for a long time. You need to download and install the package bcmwl-kernel-source
First, you’ll need to find the exact model of the Broadcom network adapter chip your notebook has. “802.11n” is just the name of the Wi-Fi standard it supports: Broadcom has several wireless chips supporting that standard.
lspci -nn would be a good command to list all PCI(e) devices on your laptop and their PCI ID numbers: those numbers would allow a more accurate identification. lsusb will do the same for USB devices.
The lspci -nn listing line might look something like this:
Here, the numbers [14e4:4359] are the Device ID. The first part specifies the vendor (Broadcom = 14e4) and the second part identifies the device model.
The lsusb listing is a bit different, but the Device ID number is similar: 4 hexadecimal digits for the vendor id, a colon, and then 4 hexadecimal digits for the product ID.
You can check here for the Linux support status of various Broadcom chip models: https://wireless.wiki.kernel.org/en/users/drivers/brcm80211
Note that the supported Broadcom chips will need firmware: it is probably available pre-packaged in Ubuntu. If Ubuntu uses the same naming scheme as Debian, the firmware package name should be firmware-brcm80211 .
With a bit of luck, installing this firmware package and rebooting might be enough to get your Wi-Fi functional if the necessary driver is already in kernel.