[Leap 15.3 Beta] After upgrading, not able to boot with 15.3 kernel, only with 15.2 kernel
Hi, everyone! When I knew Leap 15.3 Beta was released, I upgraded from 15.2 just a few days after. It happens that now I have at least 4 kernel images installed: - 5.3.18-47.7-preempt (from Leap 15.3) - 5.3.18-47.7-default - 5.3.18-lp152.63-preempt (presumably left from Leap 15.2) - 5.3.18-lp152.63-preempt I'm not sure what this preempt kernel is or whether it was installed before upgrading... But now I'm able to reach the GNOME desktop only if at the GRUB menu I enter the advanced options and choose one of the 15.2 kernels. If I boot one of the 15.3 kernels, it ends like this: https://paste.opensuse.org/95820671 And later, when I boot the 15.2 kernel, I realize nothing was written to /var/log/messages regarding the previous trial with the 15.3 kernel. This message caught my attention: DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x000000009d800000-0x000000009fffffff], contact BIOS vendor for fixes I believe the problem is with the 15.3 kernel, because I'm able to boot with the 15.2 kernel. Is this a known bug? Or should I report it as a new bug? Thanks! Antonio The Linux Kamarada Project http://kamarada.github.io/
On Thu, 11 Mar 2021 03:54:46 +0100, Linux Kamarada wrote:
Hi, everyone!
When I knew Leap 15.3 Beta was released, I upgraded from 15.2 just a few days after.
It happens that now I have at least 4 kernel images installed:
- 5.3.18-47.7-preempt (from Leap 15.3) - 5.3.18-47.7-default - 5.3.18-lp152.63-preempt (presumably left from Leap 15.2) - 5.3.18-lp152.63-preempt
I'm not sure what this preempt kernel is or whether it was installed before upgrading...
But now I'm able to reach the GNOME desktop only if at the GRUB menu I enter the advanced options and choose one of the 15.2 kernels.
If I boot one of the 15.3 kernels, it ends like this: https://paste.opensuse.org/95820671
And later, when I boot the 15.2 kernel, I realize nothing was written to /var/log/messages regarding the previous trial with the 15.3 kernel.
This message caught my attention:
DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x000000009d800000-0x000000009fffffff], contact BIOS vendor for fixes
I believe the problem is with the 15.3 kernel, because I'm able to boot with the 15.2 kernel.
Is this a known bug? Or should I report it as a new bug?
Not really, it's a harmless firmware bug that is seen commonly on many machines. How did you update to Leap 15.3? On Leap 15.3, the kernel package was split to three sub-packages, kernel-default, kernel-default-extra and kernel-default-optional. (Ditto for kernel-preempt: kernel-preempt, kernel-preempt-extra and kernel-preempt-optional.) Some drivers are put in *-extra or *-optional, and one of them is nouveau driver. So, make sure that you have installed kernel-*-extra driver at least. About preempt vs default: most likely you need only one of them. Takashi
Am Donnerstag, 11. März 2021, 08:54:16 CET schrieb Takashi Iwai:
On Thu, 11 Mar 2021 03:54:46 +0100,
Linux Kamarada wrote:
Hi, everyone!
When I knew Leap 15.3 Beta was released, I upgraded from 15.2 just a few days after.
It happens that now I have at least 4 kernel images installed:
- 5.3.18-47.7-preempt (from Leap 15.3) - 5.3.18-47.7-default - 5.3.18-lp152.63-preempt (presumably left from Leap 15.2) - 5.3.18-lp152.63-preempt
I'm not sure what this preempt kernel is or whether it was installed before upgrading...
But now I'm able to reach the GNOME desktop only if at the GRUB menu I enter the advanced options and choose one of the 15.2 kernels.
If I boot one of the 15.3 kernels, it ends like this: https://paste.opensuse.org/95820671
And later, when I boot the 15.2 kernel, I realize nothing was written to /var/log/messages regarding the previous trial with the 15.3 kernel.
This message caught my attention:
DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x000000009d800000-0x000000009fffffff], contact BIOS vendor for fixes
I believe the problem is with the 15.3 kernel, because I'm able to boot with the 15.2 kernel.
Is this a known bug? Or should I report it as a new bug?
Not really, it's a harmless firmware bug that is seen commonly on many machines.
How did you update to Leap 15.3? On Leap 15.3, the kernel package was split to three sub-packages, kernel-default, kernel-default-extra and kernel-default-optional. (Ditto for kernel-preempt: kernel-preempt, kernel-preempt-extra and kernel-preempt-optional.) Some drivers are put in *-extra or *-optional, and one of them is nouveau driver. So, make sure that you have installed kernel-*-extra driver at least.
About preempt vs default: most likely you need only one of them.
Should the installer not find out what the system needs? A normal user can probably not judge which additional kernel packages one needs. Cheers Axel
On Thu, 11 Mar 2021 10:19:15 +0100, Axel Braun wrote:
Am Donnerstag, 11. März 2021, 08:54:16 CET schrieb Takashi Iwai:
On Thu, 11 Mar 2021 03:54:46 +0100,
Linux Kamarada wrote:
Hi, everyone!
When I knew Leap 15.3 Beta was released, I upgraded from 15.2 just a few days after.
It happens that now I have at least 4 kernel images installed:
- 5.3.18-47.7-preempt (from Leap 15.3) - 5.3.18-47.7-default - 5.3.18-lp152.63-preempt (presumably left from Leap 15.2) - 5.3.18-lp152.63-preempt
I'm not sure what this preempt kernel is or whether it was installed before upgrading...
But now I'm able to reach the GNOME desktop only if at the GRUB menu I enter the advanced options and choose one of the 15.2 kernels.
If I boot one of the 15.3 kernels, it ends like this: https://paste.opensuse.org/95820671
And later, when I boot the 15.2 kernel, I realize nothing was written to /var/log/messages regarding the previous trial with the 15.3 kernel.
This message caught my attention:
DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x000000009d800000-0x000000009fffffff], contact BIOS vendor for fixes
I believe the problem is with the 15.3 kernel, because I'm able to boot with the 15.2 kernel.
Is this a known bug? Or should I report it as a new bug?
Not really, it's a harmless firmware bug that is seen commonly on many machines.
How did you update to Leap 15.3? On Leap 15.3, the kernel package was split to three sub-packages, kernel-default, kernel-default-extra and kernel-default-optional. (Ditto for kernel-preempt: kernel-preempt, kernel-preempt-extra and kernel-preempt-optional.) Some drivers are put in *-extra or *-optional, and one of them is nouveau driver. So, make sure that you have installed kernel-*-extra driver at least.
About preempt vs default: most likely you need only one of them.
Should the installer not find out what the system needs? A normal user can probably not judge which additional kernel packages one needs.
It should, and that's why I asked how he updated. kernel-*-optional has the Supplements tag to the product Leap, so it'll be installed as long as recommends are taken info account by zypper. Takashi
On Thu, Mar 11, 2021 at 4:39 AM Takashi Iwai <tiwai@suse.de> wrote:
On Thu, 11 Mar 2021 10:19:15 +0100, Axel Braun wrote:
Am Donnerstag, 11. März 2021, 08:54:16 CET schrieb Takashi Iwai:
On Thu, 11 Mar 2021 03:54:46 +0100,
Linux Kamarada wrote:
Hi, everyone!
When I knew Leap 15.3 Beta was released, I upgraded from 15.2 just a few days after.
It happens that now I have at least 4 kernel images installed:
- 5.3.18-47.7-preempt (from Leap 15.3) - 5.3.18-47.7-default - 5.3.18-lp152.63-preempt (presumably left from Leap 15.2) - 5.3.18-lp152.63-preempt
I'm not sure what this preempt kernel is or whether it was installed before upgrading...
But now I'm able to reach the GNOME desktop only if at the GRUB menu I enter the advanced options and choose one of the 15.2 kernels.
If I boot one of the 15.3 kernels, it ends like this: https://paste.opensuse.org/95820671
And later, when I boot the 15.2 kernel, I realize nothing was written to /var/log/messages regarding the previous trial with the 15.3 kernel.
This message caught my attention:
DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x000000009d800000-0x000000009fffffff], contact BIOS vendor for fixes
I believe the problem is with the 15.3 kernel, because I'm able to boot with the 15.2 kernel.
Is this a known bug? Or should I report it as a new bug?
Not really, it's a harmless firmware bug that is seen commonly on many machines.
How did you update to Leap 15.3? On Leap 15.3, the kernel package was split to three sub-packages, kernel-default, kernel-default-extra and kernel-default-optional. (Ditto for kernel-preempt: kernel-preempt, kernel-preempt-extra and kernel-preempt-optional.) Some drivers are put in *-extra or *-optional, and one of them is nouveau driver. So, make sure that you have installed kernel-*-extra driver at least.
About preempt vs default: most likely you need only one of them.
Should the installer not find out what the system needs? A normal user can probably not judge which additional kernel packages one needs.
It should, and that's why I asked how he updated. kernel-*-optional has the Supplements tag to the product Leap, so it'll be installed as long as recommends are taken info account by zypper.
Are you _sure_ about that? Supplements: packageand(product(SLED):%{name}_%_target_cpu) Supplements: packageand(product(sle-we):%{name}_%_target_cpu) Supplements: packageand(product(Leap):%{name}_%_target_cpu) I would not expect the above statements to work. There are two issues, one major and one minor: 1. There is no product(Leap) Provides on openSUSE-release. There *is* product(openSUSE), and you should use that. 2. The packageand() hack for Supplements does not consistently work, and we've had a standard RPM feature since SLE 15. Please use that instead. If you rewrite your Supplements statements accordingly: Supplements: (product(SLED) and %{name}_%_target_cpu) Supplements: (product(sle-we) and %{name}_%_target_cpu) Supplements: (product(openSUSE) and %{name}_%_target_cpu) This should work as intended. -- 真実はいつも一つ！/ Always, there's only one truth!
On Thu, 11 Mar 2021 10:59:46 +0100, Neal Gompa wrote:
On Thu, Mar 11, 2021 at 4:39 AM Takashi Iwai <tiwai@suse.de> wrote:
On Thu, 11 Mar 2021 10:19:15 +0100, Axel Braun wrote:
Am Donnerstag, 11. März 2021, 08:54:16 CET schrieb Takashi Iwai:
On Thu, 11 Mar 2021 03:54:46 +0100,
Linux Kamarada wrote:
Hi, everyone!
When I knew Leap 15.3 Beta was released, I upgraded from 15.2 just a few days after.
It happens that now I have at least 4 kernel images installed:
- 5.3.18-47.7-preempt (from Leap 15.3) - 5.3.18-47.7-default - 5.3.18-lp152.63-preempt (presumably left from Leap 15.2) - 5.3.18-lp152.63-preempt
I'm not sure what this preempt kernel is or whether it was installed before upgrading...
But now I'm able to reach the GNOME desktop only if at the GRUB menu I enter the advanced options and choose one of the 15.2 kernels.
If I boot one of the 15.3 kernels, it ends like this: https://paste.opensuse.org/95820671
And later, when I boot the 15.2 kernel, I realize nothing was written to /var/log/messages regarding the previous trial with the 15.3 kernel.
This message caught my attention:
DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x000000009d800000-0x000000009fffffff], contact BIOS vendor for fixes
I believe the problem is with the 15.3 kernel, because I'm able to boot with the 15.2 kernel.
Is this a known bug? Or should I report it as a new bug?
Not really, it's a harmless firmware bug that is seen commonly on many machines.
How did you update to Leap 15.3? On Leap 15.3, the kernel package was split to three sub-packages, kernel-default, kernel-default-extra and kernel-default-optional. (Ditto for kernel-preempt: kernel-preempt, kernel-preempt-extra and kernel-preempt-optional.) Some drivers are put in *-extra or *-optional, and one of them is nouveau driver. So, make sure that you have installed kernel-*-extra driver at least.
About preempt vs default: most likely you need only one of them.
Should the installer not find out what the system needs? A normal user can probably not judge which additional kernel packages one needs.
It should, and that's why I asked how he updated. kernel-*-optional has the Supplements tag to the product Leap, so it'll be installed as long as recommends are taken info account by zypper.
Are you _sure_ about that?
It *should*, but admittedly, not widely tested yet. Again, that's why I asked that question in the first place.
Supplements: packageand(product(SLED):%{name}_%_target_cpu) Supplements: packageand(product(sle-we):%{name}_%_target_cpu) Supplements: packageand(product(Leap):%{name}_%_target_cpu)
I would not expect the above statements to work.
There are two issues, one major and one minor:
1. There is no product(Leap) Provides on openSUSE-release. There *is* product(openSUSE), and you should use that.
Actually, the tag was corrected from product(openSUSE) to product(Leap) by the suggestion from Max Lin. I don't know which one is really the right value, though. Let me know the final answer.
2. The packageand() hack for Supplements does not consistently work, and we've had a standard RPM feature since SLE 15. Please use that instead.
If you rewrite your Supplements statements accordingly:
Supplements: (product(SLED) and %{name}_%_target_cpu) Supplements: (product(sle-we) and %{name}_%_target_cpu) Supplements: (product(openSUSE) and %{name}_%_target_cpu)
This should work as intended.
OK, we can change that, but why packageand() doesn't work for this particular case? At least SLE kernel has relied on this, so if any, we must fix the bug. Takashi
On Thu, Mar 11, 2021 at 5:08 AM Takashi Iwai <tiwai@suse.de> wrote:
On Thu, 11 Mar 2021 10:59:46 +0100, Neal Gompa wrote:
On Thu, Mar 11, 2021 at 4:39 AM Takashi Iwai <tiwai@suse.de> wrote:
On Thu, 11 Mar 2021 10:19:15 +0100, Axel Braun wrote:
Am Donnerstag, 11. März 2021, 08:54:16 CET schrieb Takashi Iwai:
On Thu, 11 Mar 2021 03:54:46 +0100,
Linux Kamarada wrote:
Hi, everyone!
When I knew Leap 15.3 Beta was released, I upgraded from 15.2 just a few days after.
It happens that now I have at least 4 kernel images installed:
- 5.3.18-47.7-preempt (from Leap 15.3) - 5.3.18-47.7-default - 5.3.18-lp152.63-preempt (presumably left from Leap 15.2) - 5.3.18-lp152.63-preempt
I'm not sure what this preempt kernel is or whether it was installed before upgrading...
But now I'm able to reach the GNOME desktop only if at the GRUB menu I enter the advanced options and choose one of the 15.2 kernels.
If I boot one of the 15.3 kernels, it ends like this: https://paste.opensuse.org/95820671
And later, when I boot the 15.2 kernel, I realize nothing was written to /var/log/messages regarding the previous trial with the 15.3 kernel.
This message caught my attention:
DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x000000009d800000-0x000000009fffffff], contact BIOS vendor for fixes
I believe the problem is with the 15.3 kernel, because I'm able to boot with the 15.2 kernel.
Is this a known bug? Or should I report it as a new bug?
Not really, it's a harmless firmware bug that is seen commonly on many machines.
How did you update to Leap 15.3? On Leap 15.3, the kernel package was split to three sub-packages, kernel-default, kernel-default-extra and kernel-default-optional. (Ditto for kernel-preempt: kernel-preempt, kernel-preempt-extra and kernel-preempt-optional.) Some drivers are put in *-extra or *-optional, and one of them is nouveau driver. So, make sure that you have installed kernel-*-extra driver at least.
About preempt vs default: most likely you need only one of them.
Should the installer not find out what the system needs? A normal user can probably not judge which additional kernel packages one needs.
It should, and that's why I asked how he updated. kernel-*-optional has the Supplements tag to the product Leap, so it'll be installed as long as recommends are taken info account by zypper.
Are you _sure_ about that?
It *should*, but admittedly, not widely tested yet. Again, that's why I asked that question in the first place.
Supplements: packageand(product(SLED):%{name}_%_target_cpu) Supplements: packageand(product(sle-we):%{name}_%_target_cpu) Supplements: packageand(product(Leap):%{name}_%_target_cpu)
I would not expect the above statements to work.
There are two issues, one major and one minor:
1. There is no product(Leap) Provides on openSUSE-release. There *is* product(openSUSE), and you should use that.
Actually, the tag was corrected from product(openSUSE) to product(Leap) by the suggestion from Max Lin.
I don't know which one is really the right value, though. Let me know the final answer.
Oh god, this means other stuff is going to break in openSUSE Leap. We have packages in openSUSE Leap that leverage that Provides in 15.x and 42.x. Both first party and third party repositories rely on that (I have packages both in Leap and downstream as an ISV that rely on that). We need to revert that, or at least just re-add the product(openSUSE) Provides. If we want to change how this works, we need to do that for SLE/Leap 16 and message that properly.
2. The packageand() hack for Supplements does not consistently work, and we've had a standard RPM feature since SLE 15. Please use that instead.
If you rewrite your Supplements statements accordingly:
Supplements: (product(SLED) and %{name}_%_target_cpu) Supplements: (product(sle-we) and %{name}_%_target_cpu) Supplements: (product(openSUSE) and %{name}_%_target_cpu)
This should work as intended.
OK, we can change that, but why packageand() doesn't work for this particular case? At least SLE kernel has relied on this, so if any, we must fix the bug.
So there are a couple reasons this is a problem: * RPM can't query it. If you use supplements/whatsupplements queries from RPM, you cannot resolve them to identify candidates. This makes it tough for determining whether these are correct without either writing a parser or just reading and searching yourself. This is also a problem for leveraging ecosystem tooling to validate dependencies, as they pretty much only support standard RPM dependency constructs, including the standard RPM boolean dependencies[1] structure introduced in RPM 4.13. * It's libzypp specific and relies on libzypp reprocessing to generate solvables in libsolv. This has been glitchy in the past, but also people are increasingly using DNF as an alternative in openSUSE Leap, and that doesn't support it at all (only the standard stuff supported in RPM itself). As both libzypp and libdnf support standard RPM boolean dependencies, we should be more aggressively moving to that rather than relying on legacy hacks. [1]: http://rpm.org/user_doc/boolean_dependencies.html -- 真実はいつも一つ！/ Always, there's only one truth!
On Thu, 11 Mar 2021 11:21:55 +0100, Neal Gompa wrote:
On Thu, Mar 11, 2021 at 5:08 AM Takashi Iwai <tiwai@suse.de> wrote:
On Thu, 11 Mar 2021 10:59:46 +0100, Neal Gompa wrote:
On Thu, Mar 11, 2021 at 4:39 AM Takashi Iwai <tiwai@suse.de> wrote:
On Thu, 11 Mar 2021 10:19:15 +0100, Axel Braun wrote:
Am Donnerstag, 11. März 2021, 08:54:16 CET schrieb Takashi Iwai:
On Thu, 11 Mar 2021 03:54:46 +0100,
Linux Kamarada wrote: > Hi, everyone! > > When I knew Leap 15.3 Beta was released, I upgraded from 15.2 just a > few days after. > > It happens that now I have at least 4 kernel images installed: > > - 5.3.18-47.7-preempt (from Leap 15.3) > - 5.3.18-47.7-default > - 5.3.18-lp152.63-preempt (presumably left from Leap 15.2) > - 5.3.18-lp152.63-preempt > > I'm not sure what this preempt kernel is or whether it was installed > before upgrading... > > But now I'm able to reach the GNOME desktop only if at the GRUB menu I > enter the advanced options and choose one of the 15.2 kernels. > > If I boot one of the 15.3 kernels, it ends like this: > https://paste.opensuse.org/95820671 > > And later, when I boot the 15.2 kernel, I realize nothing was written > to /var/log/messages regarding the previous trial with the 15.3 > kernel. > > This message caught my attention: > > DMAR: [Firmware Bug]: No firmware reserved region can cover this > RMRR [0x000000009d800000-0x000000009fffffff], contact BIOS vendor for > fixes > > I believe the problem is with the 15.3 kernel, because I'm able to > boot with the 15.2 kernel. > > Is this a known bug? Or should I report it as a new bug?
Not really, it's a harmless firmware bug that is seen commonly on many machines.
How did you update to Leap 15.3? On Leap 15.3, the kernel package was split to three sub-packages, kernel-default, kernel-default-extra and kernel-default-optional. (Ditto for kernel-preempt: kernel-preempt, kernel-preempt-extra and kernel-preempt-optional.) Some drivers are put in *-extra or *-optional, and one of them is nouveau driver. So, make sure that you have installed kernel-*-extra driver at least.
About preempt vs default: most likely you need only one of them.
Should the installer not find out what the system needs? A normal user can probably not judge which additional kernel packages one needs.
It should, and that's why I asked how he updated. kernel-*-optional has the Supplements tag to the product Leap, so it'll be installed as long as recommends are taken info account by zypper.
Are you _sure_ about that?
It *should*, but admittedly, not widely tested yet. Again, that's why I asked that question in the first place.
Supplements: packageand(product(SLED):%{name}_%_target_cpu) Supplements: packageand(product(sle-we):%{name}_%_target_cpu) Supplements: packageand(product(Leap):%{name}_%_target_cpu)
I would not expect the above statements to work.
There are two issues, one major and one minor:
1. There is no product(Leap) Provides on openSUSE-release. There *is* product(openSUSE), and you should use that.
Actually, the tag was corrected from product(openSUSE) to product(Leap) by the suggestion from Max Lin.
I don't know which one is really the right value, though. Let me know the final answer.
Oh god, this means other stuff is going to break in openSUSE Leap. We have packages in openSUSE Leap that leverage that Provides in 15.x and 42.x. Both first party and third party repositories rely on that (I have packages both in Leap and downstream as an ISV that rely on that).
We need to revert that, or at least just re-add the product(openSUSE) Provides. If we want to change how this works, we need to do that for SLE/Leap 16 and message that properly.
Adding Lubos and Max to Cc. Takashi
On Thu, Mar 11, 2021 at 4:54 AM Takashi Iwai <tiwai@suse.de> wrote:
On Thu, 11 Mar 2021 03:54:46 +0100, Linux Kamarada wrote:
This message caught my attention:
DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x000000009d800000-0x000000009fffffff], contact BIOS vendor for fixes
I believe the problem is with the 15.3 kernel, because I'm able to boot with the 15.2 kernel.
Is this a known bug? Or should I report it as a new bug?
Not really, it's a harmless firmware bug that is seen commonly on many machines.
How did you update to Leap 15.3? On Leap 15.3, the kernel package was split to three sub-packages, kernel-default, kernel-default-extra and kernel-default-optional. (Ditto for kernel-preempt: kernel-preempt, kernel-preempt-extra and kernel-preempt-optional.) Some drivers are put in *-extra or *-optional, and one of them is nouveau driver. So, make sure that you have installed kernel-*-extra driver at least.
Actually, kernel-default-extra, kernel-default-optional, kernel-preempt-extra and kernel-preempt-optional were all already installed. I thought about installing kernel-firmware, but then YaST told me that would uninstall kernel-firmware-all, so I canceled. Antonio The Linux Kamarada Project http://kamarada.github.io/
On Fri, 12 Mar 2021 02:39:51 +0100, Linux Kamarada wrote:
On Thu, Mar 11, 2021 at 4:54 AM Takashi Iwai <tiwai@suse.de> wrote:
On Thu, 11 Mar 2021 03:54:46 +0100, Linux Kamarada wrote:
This message caught my attention:
DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x000000009d800000-0x000000009fffffff], contact BIOS vendor for fixes
I believe the problem is with the 15.3 kernel, because I'm able to boot with the 15.2 kernel.
Is this a known bug? Or should I report it as a new bug?
Not really, it's a harmless firmware bug that is seen commonly on many machines.
How did you update to Leap 15.3? On Leap 15.3, the kernel package was split to three sub-packages, kernel-default, kernel-default-extra and kernel-default-optional. (Ditto for kernel-preempt: kernel-preempt, kernel-preempt-extra and kernel-preempt-optional.) Some drivers are put in *-extra or *-optional, and one of them is nouveau driver. So, make sure that you have installed kernel-*-extra driver at least.
Actually, kernel-default-extra, kernel-default-optional, kernel-preempt-extra and kernel-preempt-optional were all already installed.
OK, then my first guess was wrong.
I thought about installing kernel-firmware, but then YaST told me that would uninstall kernel-firmware-all, so I canceled.
Right, kernel-firmware is the old style package containing the all files in uncompressed format in a single package, while Leap 15.3 follows the package split that is already done in Tumbleweed. So it's a different problem. As suggested in the thread, please try to login there; even without graphics, the system might be able to boot further and we can get logs. thanks, Takashi
On 12/03/2021 08.04, Takashi Iwai wrote:
On Fri, 12 Mar 2021 02:39:51 +0100, Linux Kamarada wrote:
On Thu, Mar 11, 2021 at 4:54 AM Takashi Iwai <tiwai@suse.de> wrote:
On Thu, 11 Mar 2021 03:54:46 +0100, Linux Kamarada wrote:
This message caught my attention:
DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x000000009d800000-0x000000009fffffff], contact BIOS vendor for fixes
I believe the problem is with the 15.3 kernel, because I'm able to boot with the 15.2 kernel.
Is this a known bug? Or should I report it as a new bug?
Not really, it's a harmless firmware bug that is seen commonly on many machines.
How did you update to Leap 15.3? On Leap 15.3, the kernel package was split to three sub-packages, kernel-default, kernel-default-extra and kernel-default-optional. (Ditto for kernel-preempt: kernel-preempt, kernel-preempt-extra and kernel-preempt-optional.) Some drivers are put in *-extra or *-optional, and one of them is nouveau driver. So, make sure that you have installed kernel-*-extra driver at least.
Actually, kernel-default-extra, kernel-default-optional, kernel-preempt-extra and kernel-preempt-optional were all already installed.
OK, then my first guess was wrong.
I thought about installing kernel-firmware, but then YaST told me that would uninstall kernel-firmware-all, so I canceled.
Right, kernel-firmware is the old style package containing the all files in uncompressed format in a single package, while Leap 15.3 follows the package split that is already done in Tumbleweed.
So it's a different problem. As suggested in the thread, please try to login there; even without graphics, the system might be able to boot further and we can get logs.
He posted an error message that indicates the filesystem is read only, but after "startx" runs :-? -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 12/03/2021 10.27, Carlos E. R. wrote:
On 12/03/2021 08.04, Takashi Iwai wrote:
On Fri, 12 Mar 2021 02:39:51 +0100, Linux Kamarada wrote:
On Thu, Mar 11, 2021 at 4:54 AM Takashi Iwai <tiwai@suse.de> wrote:
On Thu, 11 Mar 2021 03:54:46 +0100, Linux Kamarada wrote:
This message caught my attention:
DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR [0x000000009d800000-0x000000009fffffff], contact BIOS vendor for fixes
I believe the problem is with the 15.3 kernel, because I'm able to boot with the 15.2 kernel.
Is this a known bug? Or should I report it as a new bug?
Not really, it's a harmless firmware bug that is seen commonly on many machines.
How did you update to Leap 15.3? On Leap 15.3, the kernel package was split to three sub-packages, kernel-default, kernel-default-extra and kernel-default-optional. (Ditto for kernel-preempt: kernel-preempt, kernel-preempt-extra and kernel-preempt-optional.) Some drivers are put in *-extra or *-optional, and one of them is nouveau driver. So, make sure that you have installed kernel-*-extra driver at least.
Actually, kernel-default-extra, kernel-default-optional, kernel-preempt-extra and kernel-preempt-optional were all already installed.
OK, then my first guess was wrong.
I thought about installing kernel-firmware, but then YaST told me that would uninstall kernel-firmware-all, so I canceled.
Right, kernel-firmware is the old style package containing the all files in uncompressed format in a single package, while Leap 15.3 follows the package split that is already done in Tumbleweed.
So it's a different problem. As suggested in the thread, please try to login there; even without graphics, the system might be able to boot further and we can get logs.
He posted an error message that indicates the filesystem is read only, but after "startx" runs :-?
Ah, in his first message he said:
And later, when I boot the 15.2 kernel, I realize nothing was written to /var/log/messages regarding the previous trial with the 15.3 kernel.
which would indicate it is read only since boot. Maybe "dmesg" might have something in RAM, and might be dumped to another partition or external disk. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Fri, Mar 12, 2021 at 6:30 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 12/03/2021 10.27, Carlos E. R. wrote:
On 12/03/2021 08.04, Takashi Iwai wrote:
On Fri, 12 Mar 2021 02:39:51 +0100, Linux Kamarada wrote:
Actually, kernel-default-extra, kernel-default-optional, kernel-preempt-extra and kernel-preempt-optional were all already installed.
OK, then my first guess was wrong.
I thought about installing kernel-firmware, but then YaST told me that would uninstall kernel-firmware-all, so I canceled.
Right, kernel-firmware is the old style package containing the all files in uncompressed format in a single package, while Leap 15.3 follows the package split that is already done in Tumbleweed.
So it's a different problem. As suggested in the thread, please try to login there; even without graphics, the system might be able to boot further and we can get logs.
He posted an error message that indicates the filesystem is read only, but after "startx" runs :-?
Ah, in his first message he said:
And later, when I boot the 15.2 kernel, I realize nothing was written to /var/log/messages regarding the previous trial with the 15.3 kernel.
which would indicate it is read only since boot.
Maybe "dmesg" might have something in RAM, and might be dumped to another partition or external disk.
I booted with the 15.3 kernel and started GNOME. I'm able to write to my home folder, which is in another partition. Here is my dmesg: https://paste.opensuse.org/58650934 Antonio The Linux Kamarada Project http://kamarada.github.io/
On 12/03/2021 23.25, Linux Kamarada wrote:
On Fri, Mar 12, 2021 at 6:30 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 12/03/2021 10.27, Carlos E. R. wrote:
On 12/03/2021 08.04, Takashi Iwai wrote:
On Fri, 12 Mar 2021 02:39:51 +0100, Linux Kamarada wrote:
He posted an error message that indicates the filesystem is read only, but after "startx" runs :-?
Ah, in his first message he said:
And later, when I boot the 15.2 kernel, I realize nothing was written to /var/log/messages regarding the previous trial with the 15.3 kernel.
which would indicate it is read only since boot.
Maybe "dmesg" might have something in RAM, and might be dumped to another partition or external disk.
I booted with the 15.3 kernel and started GNOME. I'm able to write to my home folder, which is in another partition.
Here is my dmesg: https://paste.opensuse.org/58650934
Here, I think: [ 5.935952] systemd[1]: modprobe@fuse.service: Succeeded. [ 5.936236] systemd[1]: Finished Load Kernel Module fuse. [ 5.942066] btrfs: autodefrag is not supported, load module with allow_unsupported=1 [ 5.942069] BTRFS info (device sda5): use lzo compression, level 0 [ 5.949281] Adding 17825788k swap on /dev/sda6. Priority:-2 extents:1 across:17825788k SSFS [ 5.955645] systemd[1]: Activated swap /dev/disk/by-uuid/53a44eae-e1af-4934-9cb4-e3b5e96d331a. [ 5.956239] systemd[1]: Finished Load Kernel Modules. [ 5.956486] systemd[1]: systemd-remount-fs.service: Main process exited, code=exited, status=1/FAILURE [ 5.956627] systemd[1]: systemd-remount-fs.service: Failed with result 'exit-code'. [ 5.956933] systemd[1]: Failed to start Remount Root and Kernel File Systems. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Fri, Mar 12, 2021 at 7:34 PM Carlos E.R. <robin.listas@gmx.es> wrote:
On 12/03/2021 23.25, Linux Kamarada wrote:
I booted with the 15.3 kernel and started GNOME. I'm able to write to my home folder, which is in another partition.
Here is my dmesg: https://paste.opensuse.org/58650934
Here, I think:
[ 5.935952] systemd[1]: modprobe@fuse.service: Succeeded. [ 5.936236] systemd[1]: Finished Load Kernel Module fuse. [ 5.942066] btrfs: autodefrag is not supported, load module with allow_unsupported=1 [ 5.942069] BTRFS info (device sda5): use lzo compression, level 0 [ 5.949281] Adding 17825788k swap on /dev/sda6. Priority:-2 extents:1 across:17825788k SSFS [ 5.955645] systemd[1]: Activated swap /dev/disk/by-uuid/53a44eae-e1af-4934-9cb4-e3b5e96d331a. [ 5.956239] systemd[1]: Finished Load Kernel Modules. [ 5.956486] systemd[1]: systemd-remount-fs.service: Main process exited, code=exited, status=1/FAILURE [ 5.956627] systemd[1]: systemd-remount-fs.service: Failed with result 'exit-code'. [ 5.956933] systemd[1]: Failed to start Remount Root and Kernel File Systems.
You're right, I too believe the fault is there. But... any ideas of what should I try next? Antonio The Linux Kamarada Project http://kamarada.github.io/
On 17/03/2021 03.02, Linux Kamarada wrote:
On Fri, Mar 12, 2021 at 7:34 PM Carlos E.R. <robin.listas@gmx.es> wrote:
On 12/03/2021 23.25, Linux Kamarada wrote:
I booted with the 15.3 kernel and started GNOME. I'm able to write to my home folder, which is in another partition.
Here is my dmesg: https://paste.opensuse.org/58650934
Here, I think:
[ 5.935952] systemd[1]: modprobe@fuse.service: Succeeded. [ 5.936236] systemd[1]: Finished Load Kernel Module fuse. [ 5.942066] btrfs: autodefrag is not supported, load module with allow_unsupported=1 [ 5.942069] BTRFS info (device sda5): use lzo compression, level 0 [ 5.949281] Adding 17825788k swap on /dev/sda6. Priority:-2 extents:1 across:17825788k SSFS [ 5.955645] systemd[1]: Activated swap /dev/disk/by-uuid/53a44eae-e1af-4934-9cb4-e3b5e96d331a. [ 5.956239] systemd[1]: Finished Load Kernel Modules. [ 5.956486] systemd[1]: systemd-remount-fs.service: Main process exited, code=exited, status=1/FAILURE [ 5.956627] systemd[1]: systemd-remount-fs.service: Failed with result 'exit-code'. [ 5.956933] systemd[1]: Failed to start Remount Root and Kernel File Systems.
You're right, I too believe the fault is there. But... any ideas of what should I try next?
Report in bugzilla. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Wed, Mar 17, 2021 at 6:21 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 17/03/2021 03.02, Linux Kamarada wrote:
You're right, I too believe the fault is there. But... any ideas of what should I try next?
Report in bugzilla.
Done! Bug 1183675 - Getting into console (instead of GDM) when booting with the Leap 15.3 kernel https://bugzilla.opensuse.org/show_bug.cgi?id=1183675 Thanks! Antonio The Linux Kamarada Project https://linuxkamarada.com/ On Wed, Mar 17, 2021 at 6:21 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 17/03/2021 03.02, Linux Kamarada wrote:
On Fri, Mar 12, 2021 at 7:34 PM Carlos E.R. <robin.listas@gmx.es> wrote:
On 12/03/2021 23.25, Linux Kamarada wrote:
I booted with the 15.3 kernel and started GNOME. I'm able to write to my home folder, which is in another partition.
Here is my dmesg: https://paste.opensuse.org/58650934
Here, I think:
[ 5.935952] systemd[1]: modprobe@fuse.service: Succeeded. [ 5.936236] systemd[1]: Finished Load Kernel Module fuse. [ 5.942066] btrfs: autodefrag is not supported, load module with allow_unsupported=1 [ 5.942069] BTRFS info (device sda5): use lzo compression, level 0 [ 5.949281] Adding 17825788k swap on /dev/sda6. Priority:-2 extents:1 across:17825788k SSFS [ 5.955645] systemd[1]: Activated swap /dev/disk/by-uuid/53a44eae-e1af-4934-9cb4-e3b5e96d331a. [ 5.956239] systemd[1]: Finished Load Kernel Modules. [ 5.956486] systemd[1]: systemd-remount-fs.service: Main process exited, code=exited, status=1/FAILURE [ 5.956627] systemd[1]: systemd-remount-fs.service: Failed with result 'exit-code'. [ 5.956933] systemd[1]: Failed to start Remount Root and Kernel File Systems.
You're right, I too believe the fault is there. But... any ideas of what should I try next?
Report in bugzilla.
-- Cheers / Saludos,
Carlos E. R. (from 15.2 x86_64 at Telcontar)
-- Antonio The Linux Kamarada Project https://linuxkamarada.com/
On 18/03/2021 02.12, Linux Kamarada wrote:
On Wed, Mar 17, 2021 at 6:21 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 17/03/2021 03.02, Linux Kamarada wrote:
You're right, I too believe the fault is there. But... any ideas of what should I try next?
Report in bugzilla.
Done!
Bug 1183675 - Getting into console (instead of GDM) when booting with the Leap 15.3 kernel https://bugzilla.opensuse.org/show_bug.cgi?id=1183675
I would have said "system boots to read only filesystem with kernel 5.3.18-47.7" -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
I see already some pending questions from kernel team in the bug. Please have a look at it so we can get it fixed asap. We'll have hackweek in next week so doing so today, early tomorrow is important. Thank you On Thu, 2021-03-18 at 11:23 +0100, Carlos E. R. wrote:
On 18/03/2021 02.12, Linux Kamarada wrote:
On Wed, Mar 17, 2021 at 6:21 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 17/03/2021 03.02, Linux Kamarada wrote:
You're right, I too believe the fault is there. But... any ideas of what should I try next?
Report in bugzilla.
Done!
Bug 1183675 - Getting into console (instead of GDM) when booting with the Leap 15.3 kernel https://bugzilla.opensuse.org/show_bug.cgi?id=1183675
I would have said "system boots to read only filesystem with kernel 5.3.18-47.7"
On Thu, Mar 18, 2021 at 2:07 PM Lubos Kocman <lubos.kocman@suse.com> wrote:
I see already some pending questions from kernel team in the bug. Please have a look at it so we can get it fixed asap.
Sorry for making you wait... I have just answered both of the questions. Actually, I'm facing another problem which prevents me from troubleshooting the original one. Details on the bug report. Antonio The Linux Kamarada Project https://linuxkamarada.com/
The first problem regarding the kernel was solved: https://bugzilla.opensuse.org/show_bug.cgi?id=1183675 And I opened another bug to talk about grub: https://bugzilla.opensuse.org/show_bug.cgi?id=1183884 Thank you everyone! Antonio The Linux Kamarada Project https://linuxkamarada.com/
On 11/03/2021 03.54, Linux Kamarada wrote:
Hi, everyone!
When I knew Leap 15.3 Beta was released, I upgraded from 15.2 just a few days after.
It happens that now I have at least 4 kernel images installed:
- 5.3.18-47.7-preempt (from Leap 15.3) - 5.3.18-47.7-default - 5.3.18-lp152.63-preempt (presumably left from Leap 15.2) - 5.3.18-lp152.63-preempt
I'm not sure what this preempt kernel is or whether it was installed before upgrading...
But now I'm able to reach the GNOME desktop only if at the GRUB menu I enter the advanced options and choose one of the 15.2 kernels.
If I boot one of the 15.3 kernels, it ends like this: https://paste.opensuse.org/95820671
Did you try to login? Because the system did boot. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Thu, Mar 11, 2021 at 8:11 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 11/03/2021 03.54, Linux Kamarada wrote:
But now I'm able to reach the GNOME desktop only if at the GRUB menu I enter the advanced options and choose one of the 15.2 kernels.
If I boot one of the 15.3 kernels, it ends like this: https://paste.opensuse.org/95820671
Did you try to login? Because the system did boot.
Indeed, Carlos, you are right. The system did boot. I wanted the desktop and didn't realize that. I was able to login to the console and start GNOME with startx, without making any changes to my system. But it seems not everything is in place: ✂ -------------------------------------------------------------------------------- # zypper up Warning: The /etc/products.d/baseproduct symlink is dangling or missing! The link must point to your core products .prod file in /etc/products.d. The target filesystem is mounted as read-only. Please make sure the target filesystem is writeable. ✂ -------------------------------------------------------------------------------- I'll boot with the 15.2 kernel to try the other solution proposed: install kernel-*-extra and kernel-*-optional packages. I'll answer the other email telling whether it worked. Antonio The Linux Kamarada Project http://kamarada.github.io/
On 12/03/2021 02.27, Linux Kamarada wrote:
On Thu, Mar 11, 2021 at 8:11 AM Carlos E. R. <> wrote:
On 11/03/2021 03.54, Linux Kamarada wrote:
But now I'm able to reach the GNOME desktop only if at the GRUB menu I enter the advanced options and choose one of the 15.2 kernels.
If I boot one of the 15.3 kernels, it ends like this: https://paste.opensuse.org/95820671
Did you try to login? Because the system did boot.
Indeed, Carlos, you are right. The system did boot. I wanted the desktop and didn't realize that.
I was able to login to the console and start GNOME with startx, without making any changes to my system.
But it seems not everything is in place:
✂ --------------------------------------------------------------------------------
# zypper up Warning: The /etc/products.d/baseproduct symlink is dangling or missing! The link must point to your core products .prod file in /etc/products.d.
The target filesystem is mounted as read-only. Please make sure the target filesystem is writeable.
✂ --------------------------------------------------------------------------------
Wow, filesystem mounted read-only. I'm surprised that you managed to start gnome at all. It is an important symptom, I think. ... -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Thu, Mar 11, 2021 at 3:55 AM Linux Kamarada <linuxkamarada@gmail.com> wrote:
When I knew Leap 15.3 Beta was released, I upgraded from 15.2 just a few days after.
hi list, is it still unsafe or unable to boot a 15.2 dupped system to 15.3 these days? I today tried a zypper dup dry run and it didnt output annoying unresolvable packages (see other thread about samba package unsolvables) these days. Last time i checked was some week or two ago. Is the beta repository constantly being enhanced and filled with newer packages? Thanks for clarification.
participants (8)
-
Axel Braun -
cagsm -
Carlos E. R. -
Carlos E.R. -
Linux Kamarada -
Lubos Kocman -
Neal Gompa -
Takashi Iwai