Description of problem: The guest is a long-standing M6 Plasma install, that at one time I used for testing the Grand Update. It's been around a while, but I made sure it was fully updated before beginning. It's a basic install, but has a few extras, like Thunderbird, three Plasma games, and a 32-bit version of Google Earth. The iso I used for the upgrade was the 64-bit Classical beta3 from the latest round. The host is a 64-bit M7 Plasma install. The guest is functioning perfectly, even down to the resolution and the auto-mounting shared folders. Package installation went smoothly enough, except that it needed two passes. No problems with the post-install, or in configuring to go after updates using (ugh) MIRRORLIST. The updater told me two mga6 packages had to be removed. I checked them out on another M7 inastall, and found that the names had been changed. I approved the removal, and the updater proceeded to go after some 400+ updates. That appeared to go smoothly. The reboot - not so much. After plymouth's bubbling Cauldron disappeared, I was given a blank screen with a blinking cursor at the top. Then nothing more. I had to "power down" the guest. Rebooting at run level 3 and logging in as root, I tried "startx" to no avail. Then I executed a urpmi --auto-update, and got 292 more packages, including several kf5s - and it told me there is a long list of orphans. I left the orphans there, for now, and tried another boot. Another failure. Returning as root, I learned that the shared folders HAD been automounted, much to my surprise, and I sent a copy of the journal from the failed boot to one of them. I've attached it here. From what I can see, sddm is failing with a core dump, repeatedly. That's as far as my knowledge will take me.
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_ERRATA7CC: (none) => kde, marja11
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 PackagesCC: geiger.david68210, kde => isobuildAssignee: bugsquad => kernel
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) => OLDStatus: NEW => RESOLVED