| Summary: | When attempting a M6->M7 upgrade install from one of the Classical isos in Vbox, the reboot fails with a core dump if "nokmsboot" is one of the kernel boot options. | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Thomas Andrews <andrewsfarm> |
| Component: | RPM Packages | Assignee: | Kernel and Drivers maintainers <kernel> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | fri, isobuild, lewyssmith, mageia, marja11 |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | FOR_ERRATA7 | ||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: | journal from a failed M6->7 upgrade reboot | ||
|
Description
Thomas Andrews
2019-04-14 22:56:42 CEST
Created attachment 10933 [details]
journal from a failed M6->7 upgrade reboot
Following a suggestion from Martin W. removing "nokmsboot" from the kernel boot options allowed the guest to boot normally, and it looks very good. It would seem to me that this is something that we'll need to fix before the release, lest we have armies of angry Vbox users coming after us brandishing sharpened farm implements. New evidence shows that the guest involved must have been created using one of the beta M6 isos, updated and re-updated over and over again, keeping it current. Guests created with the Official M6 iso and one of the Official M6.1 Live isos do NOT use "nokmsboot" as a boot option. This means the problem wouldn't be nearly as widespread as I had feared. The likelihood that someone outside of QA would be carrying over an M6 beta guest, then upgrading it is remote, at best. Most users that run into this would probably just do a clean install of the guest if the upgrade failed. On the off chance it does happen to someone else, it probably shouldn't be ignored. A mention in the Errata is probably sufficient. Severity:
major =>
normal (In reply to Thomas Andrews from comment #3) > New evidence shows that the guest involved must have been created using one > of the beta M6 isos, updated and re-updated over and over again, keeping it > current. Guests created with the Official M6 iso and one of the Official > M6.1 Live isos do NOT use "nokmsboot" as a boot option. > > This means the problem wouldn't be nearly as widespread as I had feared. The > likelihood that someone outside of QA would be carrying over an M6 beta > guest, then upgrading it is remote, at best. Most users that run into this > would probably just do a clean install of the guest if the upgrade failed. > > On the off chance it does happen to someone else, it probably shouldn't be > ignored. A mention in the Errata is probably sufficient. Do you mind adding it to the Errata? CC'ing KDE team, so they'll know about it in case users report this issue directly to them. Whiteboard:
(none) =>
FOR_ERRATA7 I do not think it is kde/plasma issue but more a kernel's one or driver video's one. CC:
(none) =>
geiger.david68210 (In reply to David GEIGER from comment #5) > I do not think it is kde/plasma issue but more a kernel's one or driver > video's one. Agreed. I assumed the reporter, who tests many ISOs for QA team, only hit this issue with SDDM and not with other DMs @ TJ Was that assumption correct? (In reply to Marja Van Waes from comment #6) > (In reply to David GEIGER from comment #5) > > I do not think it is kde/plasma issue but more a kernel's one or driver > > video's one. > > Agreed. I assumed the reporter, who tests many ISOs for QA team, only hit > this issue with SDDM and not with other DMs > > @ TJ > > Was that assumption correct? Yes, and no. I only hit it with sddm, but so far, that's the only DM I've tried with a M6->7 upgrade. To be sure, much past experience has shown me that sddm and Plasma are particularly fussy when it comes to video drivers, much more so than the other DMs/DEs. I have a M6 Xfce guest that I can check, but it was created more recently than the problem one, and probably doesn't use "nokmsboot." I'll "fix" that, and give it a try today before I put something in Errata. Confirmed, it is NOT a Plasma-only problem. Same symptoms show up with LibhtDM in a 64-bit Xfce upgrade install. So, off to compose something for Errata... @TJ
Re the previous comment c8, you do not say whether "nokmsboot" is involved; c7 suggests you were going to add it. From c3:
> Guests created with the Official M6 iso and one of the Official M6.1 Live
> isos do NOT use "nokmsboot" as a boot option.
You can change the bug title if the problem is not Plasma specific.
This seemed to hinge on the "nokmsboot" kernel boot option - and Vbox? The ERRATA note could say how to remove it.CC:
(none) =>
lewyssmith To attempt to clarify: Over the course of time, some M6 vbox guests required "nokmsboot" to run properly. Any guest created at that time, and kept updated, would still have "nokmsboot" as one of the command options. This was fixed later, and eventually M6 vbox video drivers would work with or without "nokmsboot." The video drivers for M7 vbox guests will not work with "nokmsboot," so it must be removed if an upgrade is to boot. The M6 Plasma guest where I first saw the problem had been created a long time ago, and kept updated. It did have "nokmsboot" as an option, so the upgrade failed to boot. The M6 Xfce guest that I used for a test did not have "nokmsboot," so in order to have a valid test of other DEs I had to add it. I did that ONLY for testing purposes. Summary:
When attempting a M6->M7 Plasma upgrade from the beta3 Round 3 iso in Vbox, the reboot fails with an sddm core dump. =>
When attempting a M6->M7 upgrade install from one of the Classical isos in Vbox, the reboot fails with a core dump if "nokmsboot" is one of the kernel boot options. Thanks for the clarification. One solution might be for the upgrade (which must re-install kernel) to make sure that "nokmsboot" is NOT present. In your experience, would that cause non-Vbox problems? It could. Some non-Vbox video drivers require "nokmsboot." The proprietary nvidia drivers, for example. Could be others - my experience is limited in that regard. (In reply to Lewis Smith from comment #11) > Thanks for the clarification. One solution might be for the upgrade (which > must re-install kernel) to make sure that "nokmsboot" is NOT present. In > your experience, would that cause non-Vbox problems? (In reply to Thomas Andrews from comment #12) > It could. Some non-Vbox video drivers require "nokmsboot." The proprietary > nvidia drivers, for example. Could be others - my experience is limited in > that regard. Assigning to our kernel maintainer(s) and CC'ing the isobuilders. Maybe someone finds a solutions :-) Component:
Installer =>
RPM Packages Assuming we can trust it to always do the right thing, a solution would be to get some package to call '/sbin/display_driver_helper --setup-boot-kms' when it is upgraded from mga6 to mga7. CC:
(none) =>
mageia It seems an errata entry was never made. Do this problem still exist? CC:
(none) =>
fri Since both mga6 and mga7 are long EOL, and I haven't seen it in more recent testing/upgrades, I am closing this bug as "old." If it shows up again, I will file a new bug. Resolution:
(none) =>
OLD |