[arch-general] Why move LTS to 5.10 when VirtualBox guests Kernel Panic with 5.10?
Archdevs, You move of both linux and linux-lts to the same kernel is bewildering. That eliminates all fallback capability lts provides. Currently, virtualbox Arch guests are broken on 5.10 (as with most other distros). See: https://www.virtualbox.org/ticket/20055 With linux on 5.10 and lts on 5.4 it was workable to have lts guests. Now you have linux and linux-lts as the same kernel. How does that make sense? -- David C. Rankin, J.D.,P.E.
On Wed, 17 Feb 2021, at 09:48, David C. Rankin via arch-general wrote:
I just would recommend to always add the kernel packages to pacman's IgnorePkg list, and upgrade them only in a strictly controlled way. You can't trust a volunteer project like Arch to take all issues into consideration.
Em fevereiro 17, 2021 11:07 Jens John via arch-general escreveu:
I just would recommend to always add the kernel packages to pacman's IgnorePkg list, and upgrade them only in a strictly controlled way. You can't trust a volunteer project like Arch to take all issues into consideration.
Holding back the kernel can have unintended consequences and it's not a good idea. Of course, new kernels can have bugs and introduce issues, so, temporarily downgrading and reporting the issue is encouraged, while, indefinitely holding back kernels, isn't. Instead of holding back kernels, one should instead build their own needed version. Regards, Giancarlo Razzolini
Am 17.02.21 um 15:18 schrieb Giancarlo Razzolini via arch-general:
One could vote for keeping the linux-tls on 5.4 as long as linux is also an lts release and when linux has moved to the next non-lts then linux-tls would be set to the newes lts available. In this case: linux is 5.10 -> linux-lts stays at 5.4 linux becomes 5.11 -> linux-lts is upgraded to 5.10 But this is up to the maintainers of linux and linux-lts. Regards, Uwe
Em fevereiro 17, 2021 11:37 Uwe Sauter escreveu:
In this case Arch follows upstream, so there's no voting. linux will always follow stable and linux-lts will always follow the highest longterm version.
linux is 5.10 -> linux-lts stays at 5.4 linux becomes 5.11 -> linux-lts is upgraded to 5.10
linux 5.11 is already on [testing], so this is why linux-lts became 5.10.
But this is up to the maintainers of linux and linux-lts.
Indeed, it is. Regards, Giancarlo Razzolini
On 2/17/21 3:48 AM, David C. Rankin via arch-general wrote:
That was an upstream decision. Linux kernel team moved lts to 5.10, so Arch followed suit. https://www.kernel.org/category/releases.html DR
El mié, 17 feb 2021 a las 16:51, David Rosenstrauch via arch-general (<arch-general@lists.archlinux.org>) escribió:
Hi Is strange see the version 5.10 LTS have the EOL in 2022 and the 5.4 in 2025 (4.19 in 2024, 4.14 in 2023, etc) greetings
On Wednesday, 17 February 2021 16:58:18 CET sL1pKn07 SpinFlo via arch-general wrote:
Is strange see the version 5.10 LTS have the EOL in 2022 and the 5.4 in 2025 (4.19 in 2024, 4.14 in 2023, etc)
This is why: https://lore.kernel.org/lkml/YBBkplRxzzmPYKC+@kroah.com/ https://lore.kernel.org/lkml/YA%2FE1bHRmZb50MlS@kroah.com/ -- Iyán Méndez Veiga | Physicist GPG: 0x422E3694311E5AC1
On 2/17/21 9:50 AM, David Rosenstrauch via arch-general wrote:
Thanks DR (and all), I understood why it was done, I follow the kernel announcements, etc, but was a bit bewildered by Arch moving LTS to 5.10 before Linux moved to 5.11. Even today, we have: linux 5.10.16.arch1-1 and linux-lts 5.10.17-1 So the LTS kernel is a release ahead of the Arch mainline kernel. It just seemed like as a distro we would want to be a little more coordinated to ensure both linux and linux-lts move in a coordinated way. (sorry for the late reply here, no power for 6 Days 6 Hours due to Texas ice storm... glaring example of all that is wrong with deregulated energy...) -- David C. Rankin, J.D.,P.E.
Em fevereiro 23, 2021 22:48 David C. Rankin via arch-general escreveu:
You forgot [testing]. linux-lts became 5.10 after linux became 5.11 on [testing]. The fact that it didn't move to [core] yet is irrelevant. Holding back -lts would not be ideal, just so we could release 5.11 and then move -lts to 5.10. Regards, Giancarlo Razzolini
On 2/23/21 8:48 PM, David C. Rankin via arch-general wrote:
I noticed that too. I think it was just a timing issue. 5.11 was in testing for a days before it got released. DR
On 2/17/21 03:48, David C. Rankin via arch-general wrote:
While others have addressed the kernel versioning aspect of this, I'd like to address the VirtualBox aspect of this. Unless you have a very specific need, I'd instead recommend using something like KVM[[0]-backed libvirt[1] or another KVM-backed hypervisor (or just KVM itself). It's fairly easy to convert over your existing Virtualbox guests[2] for something like libvirt. You'll not only see performance gains and some more Linux-host-friendly design/features, but you'll also be guaranteed to have it always work with the newest kernel you have installed (provided you've rebooted after a kernel update), as KVM's kernel integration is part of mainline Linux. [0] https://wiki.archlinux.org/index.php/KVM [1] https://wiki.archlinux.org/index.php/Libvirt [2] https://www.utappia.org/2016/04/how-to-migrate-your-virtual-box.html -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
On Wed, 17 Feb 2021 12:59:51 -0500, brent s. via arch-general wrote:
Unless you have a very specific need, I'd instead recommend using something like KVM
It's exactly the other way round. Virtualbox is a painless out of the box solution satisfying a lot of needs. Only if you have a very special need, consider to migrate to something less comfortable such as KVM.
And if virtualbox performs adequate you gain absolutely nothing from those performance gains, but you'll lose all the out of the box features virtualbox provides, such as file sharing without any effort.
On 2/17/21 13:50, Ralf Mardorf via arch-general wrote:
but you'll lose all the out of the box features virtualbox provides, such as file sharing without any effort.
At the risk of this devolving into off-topic territory, this is a highly subjective statement. e.g. See [0][1]. I switched from VirtualBox to KVM-backed libvirt and I haven't looked back since. I've had incredibly better success with LVM/libvirt. [0] https://archlinux.org/packages/community/x86_64/libguestfs/ [1] https://nts.strzibny.name/how-to-set-up-shared-folders-in-virt-manager/ -- brent saner https://square-r00t.net/ GPG info: https://square-r00t.net/gpg-info
On Wed, 17 Feb 2021 17:48:54 -0300, Giancarlo Razzolini wrote:
Hi, maybe the OP has got a reason to chose Virtualbox in the first place, but the OP might be willing to migrate to virt-manager with KVM, where everything is or is not hassle-free. There's no need for an off-topic discussion, I'm not affected anyway.
I never question it, it's just that if somebody should run Virtualbox to e.g. get a single Windows program running, that doesn't work with wine and there should be no performance issues when running that program in a Virtualbox guest, better performance doesn't matter, since it's not needed at all. I'm well aware that a lot of other use cases are possible, that make KVM a better choice, but I don't remember that the OP asked for a VM with better performance. As long as 4.19 is longterm supported and I shouldn't change my hardware and/or Linux computer usage, I stay with 4.19 rt patched kernels I build myself. For users with different needs and/or different hardware this doesn't make sense. Btw. those using kernels from the repositories would be wise to use "IgnorePkg list, and upgrade them only in a strictly controlled way", e.g. as long as linux 5.11 is in testing and linux and linux-lts are both 5.10 ;). I suspect Jens John won't encourage users to hold back kernel updates, he probably just wanted to point out that even a rolling release might be used for a production environment and holding back a kernel update when being busy, is different to partial upgrades of other packages. Regards, Ralf
On 2021-02-17 19:50, Ralf Mardorf via arch-general wrote:
Hi Ralf, I think you may be confusing technology suggestions with specific software suggestions. You don't need to use KVM, QEMU or libvirtd directly, there is plenty of nice GUI software which uses KVM under the hood. virt-manager is a good starting point. If you want something *more* high-level than virtualbox, have a look at GNOME Boxes, which uses KVM [1] and is the most streamlined VM application I have ever seen. Cheers, Bennett [1]: https://help.gnome.org/users/gnome-boxes/stable/supported-protocols.html.en
Btw. There's still no solution for the Intel GPU issue with kernel versions > 5.4 ;). In my experiences migrating to the "modesetting" driver allows to get rid of some issues, at the expense of new issues. However, somebody mentions already building our own kernels. This is what I do anyway. It's just a pity for those, who were fine with kernels from the repos.
On 17/2/21 9:48, David C. Rankin via arch-general wrote:
Maybe this workaround can help you to build VirtualBox module. Reference: https://bbs.archlinux.org/viewtopic.php?pid=1956756#p1956756 Cheers
participants (11)
-
Bennett Piater
-
brent s.
-
David C. Rankin
-
David Rosenstrauch
-
Giancarlo Razzolini
-
Iyán Méndez Veiga
-
Jens John
-
Joan Figueras
-
Ralf Mardorf
-
sL1pKn07 SpinFlo
-
Uwe Sauter