Linus Torvalds announced the availability of Linux 5.10 a few days ago (December 13, 2020), version that brings many new features, improvements, new drivers and updated drivers for better hardware support. And it is that after seven weeks of development, Linux 5.10 is finally here as the latest version of the kernel for GNU / Linux distributions that want first-rate hardware support. Also, it is a long-term supported branch (LTS), which means that it will likely receive support for the next 5 years.
After this release it took only 24 hours for the corrective update for "Linux 5.10.1" to be released. As a first point release it would normally not arrive until a few days or weeks after the Linux 5.10 release. However, this time it happens a day later.
Linux 5.10.1 has only two fixes, both of which affect the storage code. There is a rollback to a previous solution around DISCARD RAID limits for RAID1 and RAID10 in the device mapper code.
The commitment simply says
"This is causing sad problems."
The other fixes the sector variable of the MD code block from an unsigned int to a simple int, also on the grounds that "this is causing problems." The latest MD code change ended up disrupting the mounting of at least the RAID6 configurations on Linux 5.10 and was quickly noticed by previous developers when switching to the final kernel version.
The problems are serious enough (especially when bugs affect storage-related kernel code) and thus led to the immediate release of Linux 5.10.1.
Therefore, Linux 5.10.1 is available and users are encouraged to upgrade if they are not already on this latest LTS series.
Regarding the Highlights of the new LTS branch include support for the ARMv8.5 memory tagging extension, support for the SM2 digital signature algorithm, support for CAN ISO 15765 2: 2016 transport protocol, support for the IGMPv3 / MLDv2 multicast protocol, and support for Amazon Nitro enclaves. The EXT4 file system now comes with a "quick commit" mode that dramatically reduces latency for multiple file operations, the ZoneFS file system has a new mount option called explicit open, and the OverlayFS file system can now ignore all defsync forms.
It also presents the ability for MIPS architecture to start Zstd compressed kernels (ZStandard), the ability to transmit data through multiple streams simultaneously, and support for the hypervisor KVM refer to an LTS process 'user space to manage access to unknown MSRs (model specific records).
Also, the file system Btrfs received a performance improvement for fsync () operations, and there is a new SEV-ES feature that extends AMD's Secure Encrypted Virtualization (SEV) to also encrypt the guest processor registers so they cannot be accessed by the host with the exception of the guest explicitly sharing them.
Among other notable changes, the subsystem_uring received support for creating restricted rings, the pidfd_open () system call gained support for creating non-blocking file descriptors. The RISC-V architecture has also been improved and it is now possible to boot to EFI systems.
As well, we must not forget the setting of the timestamp XFS extends the time of UNIX systems for a few centuries.
The team is still studying alternatives to solve the problem of the year 2038, which is supposed to bring Unix systems back to 1901. To do so, Darrick J. Wong, the maintainer of the XFS file system, has submitted fixes for XFS for Linux. 5.10 which is expected to delay the 2038 issue for XFS by 448 more years. This should be enough to find a real long-term solution.
It is from kernel version 5.6, released last March, that the team began to propose fixes to solve the problem of the year 2038. This is a long-ago error in coding in time on similar systems to Unix, including Linux, macOS, and other POSIX-compatible operating systems. In these systems, the computation time is based on seconds elapsed since January 1, 1970 at 00:00:00 UTC (also called the epoch). A day will, for example, 86.400 seconds and a year 31.536.000 seconds.
We finished. now I am going to explain the problems I have had on a system with Manjaro, from which Grub also started a partition with LMDE-4. Once started, both systems were frozen and had to be reset by the brave. First it happened to me in the LMDE without having updated Manjaro, and after updating this it also happened in him.
I had already assumed it was the kernel, but had a lot of difficulty getting the main system working after reinstalling it without updating. Even downgrading the original installation (?).
At this time I have replaced the main system with the Sylvia version of Linux Mint assuming that I would mount an older kernel. I will retest my esteemed Manjaro which has always performed nobly on the systems I have installed it on.
Thank you very much for the information.