How To Install Linux Kernel 4.15 (Includes Patches for Meltdown and Spectre) In Ubuntu Linux And Its Derivatives
As usual, Sunday (28, JAN 2018), Linux creator Linus Torvalds officially announced the final release of Linux Kernel 4.15, Which includes patches for two critical bugs Meltdown and Spectre. Apart from patches for Meltdown and Spectre bugs there also some other inresting things comes with Linux 4.15, such as support for the RISC-V architecture, support for AMD Secure Encrypted Virtualization, as well as support for the User-Mode Instruction Prevention feature on Intel CPUs..
As Soon as it was released, immediately it will be available for rolling release distros such as Arch Linux, Solus, or even openSUSE. Soon it will be available for Fedora users also.. But for Ubuntu, you have to manually install Linux 4.15, if you want to upgrade your current Linux kernel installed in your system. Here I am going to show you how to install Linux 4.15 in Ubuntu Linux and It's derivatives.
Warning : The Linux kernel is a critical element of the system. To do the upgrade costs when one of your hardware devices is not working properly, and the new kernel may fix this problem. But at the same time installing a new kernel unnecessarily can lead to undesirable regressions, such as: no network connection, no sound or even the inability to boot the system, so install a new kernel on your own risk.
Installation Steps :
Before starting... Update your system package source list and upgrade all installed packages to latest version by running following commands..
sudo apt-get update; sudo apt-get upgrade
Now make a new folder/directory to download and store required binaries files...
mkdir linux4.15 && cd linux4.15
Now download required files with following command..
Or if you want to download manually.. you can download from here.. and put them in one directory.
if you are downloading manually.. download correct binaries for your architecture...
If you are not sure about your OS architecture.. Run getconf LONG_BIT command.. This will tell you whether the kernel is 64 bit or 32 bit.. See More On Finding System Architecture..
How To Solve gvfsd-smb-browse 100% CPU usage Issue in Linux
Shortly, after installing Ubuntu 16.04 LTS and SAMBA file sharing in one of my friends laptop, I noticed that his laptop hangs on file open, save and on some other system operations... I have found this is caused by gvfsd-smb-browse. Yes, the theif is gvfsd-smb-browse. it's consuming 100% of your system's CPU, that makes Ubuntu 16.04 lagging badly..
Ubuntu isn't the only Linux distro which is affected by this bug, after googling about this issue, I found that Fedora Linux and some other Linux distros also affected by this gvfs issue. Someone already filed a bug about this issue on Launchpad and Red Hat Bugzilla. Hope soon we will get bug-fix update for this issue..
However, we can also get rid of this issue by small workaround.. I found this workaround on Ask Ubuntu forms..
Solution
We can fix this issue just by changing the permission of gvfsd-smb-browse file located in /usr/lib/gvfs/ to 744. So that we can prevent gvfsd-smb-browse from starting on system startup and now it can only be executed by sudo or root user.
open Terminal app in your Linux system and run the following command to change the the permission..
sudo chmod 744 /usr/lib/gvfs/gvfsd-smb-browse
Solution 2 :
One of our facebook page follower commented another solution for this issue..
That solution is posted in Red Hat Bugzilla.. According to that post mentioned in Red hat bugzilla, we can solve this issue just by adding single line in /etc/samba/smb.conf file
Note : This change only addresses the 100% CPU usage when opening the Nautilus file browser after a initial boot or reboot. I am not sure what other issues with gvfsd-smb-browse and 100% CPU usage this may impact so your experience may vary.
Step 1 :
Make a back up of your /etc/samba/smb.conf file.
Step 2 :
Using your preferred editor edit the smb.conf file and add the following line below the "[global]" statement
name resolve order = wins lmhosts bcast
Step 3 :
Your file should look like this:
[global]
name resolve order = wins lmhosts bcast
Step 4 :
Save the file and reboot.
This should resolve the 100% CPU usage problem and you should notice
that the "Network" Icon and label should appear in your file browser
much quicker that before.
If you find any changes required to this post or find any typo error please let us know about it.. please drop your comment on our facebook page message box fb.com/opensourceinside
Animation showing how the date would reset, represented as a signed 32-bit integer (at 03:14:08 UTC on 19 January 2038).
The Year 2038 problem is an issue for computing and data storage situations in which time values are stored or calculated as a signed 32-bit integer, and this number is interpreted as the number of seconds since 00:00:00 UTC on 1 January 1970 ("the epoch"). Such implementations cannot encode times after 03:14:07 UTC on 19 January 2038, a problem similar to but not entirely analogous to the "Y2K problem" (also known as the "Millennium Bug"), in which 2-digit values representing the number of years since 1900 could not encode the year 2000 or later. Most 32-bit Unix-like systems store and manipulate time in this "Unix time" format, so the year 2038 problem is sometimes referred to as the "Unix Millennium Bug" by association.
The year of 2000 which marked a significant date in the computer industry. Those days raised the heat of Y2K - Year 2000 or Millennium bug with all computing systems. If you remember those days, it was supposed to make a huge negative impact if it were not corrected at right time. The bug was fixed properly which saved the computer industry from great failure. A similar problem may occur on all Unix based systems on 19th of January, 2038 if they are not upgraded from 32 bit to 64 bit. Here is a note about what happened in 2000 (Y2K) and what will happen in year 2038.
What is Y2K ? Why was it caused ?
Computers during initial days were made to "think" in two digits for year while counting dates. They were done with intent of keeping the first 19 as constant and changing the last two digits like in 1998, 1999 etc. This was supposed to cause a major problem of resetting everything on some programmed computers as a result of overflow of date from 1999 to 1900. Anyway major nations took it seriously and developers succeeded to fix the problem which resulted in reducing losses on a major part.
What is Year 2038 Problem?
Now, its time for Unix for a Millenium Bug, it is also called as Unix Millenium Bug. This is caused due to the Unix time is computed on a binary format and the counting will be valid from 1970 to 2038. On January 19th 2038 at 03:14:37 this resetting will take place and lead the Unix systems to count the date from 1970. This can be fixed by Unix vendors when they switch from 32 bit to 64 bit versions. Thought it is a long time ahead, it could cause a problem for programs which work for very future dates.
Here is how the date gets reset on year 2038.
Note that the image contains an error that the counting will reset to 1901 which is not the same as in the explanation. One more confusion is the time region that wikipedia says as UTC. Do you think the time zone would matter for any system to reset? I think its that time in any region the computer is set for.
Simply say, it is when the computer software can't interpret the date properly past the year 2038 and it reverts back to December 13, 1901. It will cause the software to fail. It is caused because the system time is a 32-bit integer. It is often referred to as the Unix Milennium Bug.
According to Wikipedia the software will "interpret this number as the number of seconds since 00:00:00 UTC on Thursday, 1 January 1970. The furthest time that can be represented this way is 03:14:07 UTC on Tuesday, 19 January 2038. Times beyond this moment will "wrap around" and be stored internally as a negative number, which these systems will interpret as a date in December 13, 1901 rather than January 19, 2038. This is caused by integer overflow. The counter "runs out" of usable digits, "increments" the sign bit instead, and reports a maximally negative number (continuing to count up, toward zero). This is likely to cause problems for users of these systems due to erroneous calculations."
Will affect you?
Most new computers use a 64-bit system and should not have an issue with the programs that run in 64-bit mode. However, older computers, 64-bit computers that have programs running in 32-bit mode, or embedded systems that use dates to compute or run diagnostics will verly likely be affected by the Unix Milennium Bug (2038 bug). Transportation systems and cars have embedded systems. Basically, anything with a computer embedded in it that uses dates, can suffer from this. Think of all of the objects around us that have a computer chip in it.
So why worry now? It is only 2016.
Any embedded system that is 32-bit and uses future dates 24 years in the future must be fixed by 2016.
What do you do ?, what is the solution ?
There is no universal solution for the Year 2038 Bug. Any change to the definition of the time_t data type would result in code compatibility problems in any application in which date and time representations are dependent on the nature of the signed 32-bit time_t integer. For example, changing time_t to an unsigned 32-bit integer, which would extend the range to the year 2106, would adversely affect programs that store, retrieve, or manipulate dates prior to 1970, as such dates are represented by negative numbers. Increasing the size of the time_t type to 64-bit in an existing system would cause incompatible changes to the layout of structures and the binary interface of functions.
The only real solution is to upgrade your equipment to 64-bit systems before the problem affects you. While your own personal equipment may not cause you any issues, the major concern is everything around you. Transportation systems, streetlgihts, etc...
Starting with NetBSD version 6.0 (released in October 2012), the NetBSD operating system uses a 64-bit time_t for both 32-bit and 64-bit architectures. Applications that were compiled for an older NetBSD release with 32-bit time_t are supported via a binary compatibility layer, but such older applications will still suffer from the Year 2038 problem.
OpenBSD since version 5.5, released in May 2014, also uses a 64-bit time_t for both 32-bit and 64-bit architectures. In contrast to NetBSD, there is no binary compatibility layer. Therefore, applications expecting a 32-bit time_t and applications using anything different from time_t to store time values may break.
Linux uses a 64-bit time_t for 64-bit architectures only; the pure 32-bit ABI is not changed due to backward compatibility. There is ongoing work, mostly for embedded Linux systems, to support 64-bit time_t on 32-bit architectures, too.
The x32 ABI for Linux (which defines an environment for programs with 32-bit addresses but running the processor in 64-bit mode) uses a 64-bit time_t. Since it was a new environment, there was no need for special compatibility precautions.
Alternative proposals have been made (some of which are in use), such as storing either milliseconds or microseconds since an epoch (typically either 1 January 1970 or 1 January 2000) in a signed 64-bit integer, providing a minimum range of 300,000 years. Other proposals for new time representations provide different precisions, ranges, and sizes (almost always wider than 32 bits), as well as solving other related problems, such as the handling of leap seconds. In particular, TAI64 is an implementation of the Temps Atomique International standard, the current international real-time standard for defining a second and frame of reference.
