Description of problem: since the last upgrade when attempting to shut down the system by any mean (clicking on the shutdown icon, or typing under root systemctl isolate runlevel0.target), the system initiate the normal shutdown process up to "power off", but the computer doesn't turned off, and the mention"kernel panic" appears; nevertheless, by pressing the reset button, the system normally boot. here as attached file, the journalctl content from the beginning of the shutdown process to the end of the reboot (about 4 mn) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
Created attachment 11356 [details] journalctl -a --since "2019-11-15 01:17" --until "2019-11-15 01:21"
There is no kernel panic in the log, so you better take a camera picture of the panic so we can see the panic Also, you should remove any nvidia-current package on that system. As the log shows, your nVidia GPU is handled by the nvidia340 driver: NVRM: The NVIDIA GeForce 9800 GTX/9800 GTX+ GPU installed in this system is NVRM: supported through the NVIDIA 340.xx Legacy drivers
CC: (none) => tmb
(In reply to Thomas Backlund from comment #2) > There is no kernel panic in the log, so you better take a camera picture of > the panic so we can see the panic > > Also, you should remove any nvidia-current package on that system. > As the log shows, your nVidia GPU is handled by the nvidia340 driver: > > NVRM: The NVIDIA GeForce 9800 GTX/9800 GTX+ GPU installed in this system is > NVRM: supported through the NVIDIA 340.xx Legacy drivers my immediate problem is not this one of nvidia, which works well, but the fact that one of my mga7 system can't shutdown after the last update; I guess the problem comes from the packages webkit2, since this pkgs prevent the update to be achieved with dnf: [root@magaux alain4]# LANGUAGE=C dnf --refresh upgrade created by dnf config-manager from http://dl.google.com/linux/chrome/rpm/stable/x86_64 81 kB/s | 1.3 kB 00:00 Mageia 7 - i586 25 kB/s | 4.3 kB 00:00 Mageia 7 - i586 - Updates 22 kB/s | 3.4 kB 00:00 determining the fastest mirror (1 hosts).. done. [ === ] --- B/s | 0 B --:-- ETA Mageia 7 - i586 - Nonfree 5.1 kB/s | 3.8 kB 00:00 Mageia 7 - i586 - Nonfree - Updates 22 kB/s | 3.3 kB 00:00 Mageia 7 - x86_64 - Nonfree 8.0 kB/s | 3.8 kB 00:00 Mageia 7 - x86_64 - Nonfree - Updates 22 kB/s | 3.3 kB 00:00 Mageia 7 - i586 - Tainted 26 kB/s | 4.2 kB 00:00 Mageia 7 - i586 - Tainted - Updates 21 kB/s | 3.3 kB 00:00 Mageia 7 - x86_64 - Tainted 36 kB/s | 4.2 kB 00:00 Mageia 7 - x86_64 - Tainted - Updates 28 kB/s | 3.3 kB 00:00 Mageia 7 - x86_64 23 kB/s | 4.3 kB 00:00 Mageia 7 - x86_64 - Updates 21 kB/s | 3.4 kB 00:00 Opera packages 101 kB/s | 2.9 kB 00:00 skype (stable) 20 kB/s | 2.9 kB 00:00 vivaldi 433 kB/s | 2.9 kB 00:00 Error: Problem: webkit2-jsc-2.24.4-1.mga7.i586 has inferior architecture - package webkit2-plugin-process-gtk2-2.24.4-1.mga7.x86_64 requires webkit2-jsc = 2.24.4-1.mga7, but none of the providers can be installed - cannot install both webkit2-jsc-2.26.2-1.mga7.x86_64 and webkit2-jsc-2.24.4-1.mga7.x86_64 - cannot install the best update candidate for package webkit2-plugin-process-gtk2-2.24.4-1.mga7.x86_64 - cannot install the best update candidate for package webkit2-jsc-2.24.4-1.mga7.x86_64 (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) with mgapplet, I have forced the installation, hence the shutdown problem; here attached the journalctl of the shutdown of my 2nd system, not yet "infected" by the updates
Created attachment 11357 [details] return of journalctl -a --since "2019-11-15 12:55" --until "2019-11-15 12:57" > Documents/normal_shutdown.txt
(In reply to Thomas Backlund from comment #2) > There is no kernel panic in the log, so you better take a camera picture of > the panic so we can see the panic > > Also, you should remove any nvidia-current package on that system. > As the log shows, your nVidia GPU is handled by the nvidia340 driver: > > NVRM: The NVIDIA GeForce 9800 GTX/9800 GTX+ GPU installed in this system is > NVRM: supported through the NVIDIA 340.xx Legacy drivers as attached file the camera picture you ask me the problem is that I can't make the updates in my others system as long as the problem is not solved; it is sure it comes from one of the updated packages, but I don't know which
Created attachment 11358 [details] screen snapshot
i have the same problem on my two notebooks, i updated this packages: - cpio-2.13-1.mga7.x86_64 - fribidi-1.0.5-2.1.mga7.x86_64 - lib64fribidi0-1.0.5-2.1.mga7.x86_64 - lib64javascriptcore-gir4.0-2.26.2-1.mga7.x86_64 - lib64javascriptcoregtk4.0_18-2.26.2-1.mga7.x86_64 - lib64webkit2gtk-gir4.0-2.26.2-1.mga7.x86_64 - lib64webkit2gtk4.0_37-2.26.2-1.mga7.x86_64 - libfribidi0-1.0.5-2.1.mga7.i586 - python2-numpy-1.16.3-1.mga7.x86_64 - python3-numpy-1.16.3-1.mga7.x86_64 - timezone-2019c-1.mga7.x86_64 - timezone-java-2019c-1.mga7.noarch - webkit2-2.26.2-1.mga7.x86_64 i will upload photos of my screen
CC: (none) => alda.cerny
Created attachment 11359 [details] after Mageia 7 update - HP Zbook 17
Created attachment 11360 [details] after Mageia 7 update - Lenovo Thinkpad T440p
@Peter Thanks for the screenshot and dnf output of the iffy update. BTW The first attachment c1 seems to be from Mageia 6 (either unsupported or soon to be); but the second c4 I suppose is Mageia 7. To test whether the webkit update is responsible, can you please try *downgrading* it to the previous version (urpmi --downgrade webkit2). Given that it alone messed the entire update batch comment 3, you could have excluded it to do the others; maybe you did. @Alex Thank you for both screenshots, which show the same scenario. Your list of the updated packages in comment 2 is helpful, and agrees with Peter's surmise. All the panics look the same, and the kernel version is the same 5.3.7-*-4 Peter's the server one, Alex's the desktop one. Await Peter's webkit2 downgrade result before assigning the bug.
CC: (none) => lewyssmith
(In reply to Lewis Smith from comment #10) > @Peter > Thanks for the screenshot and dnf output of the iffy update. > BTW The first attachment c1 seems to be from Mageia 6 (either unsupported or > soon to be); but the second c4 I suppose is Mageia 7. > To test whether the webkit update is responsible, can you please try > *downgrading* it to the previous version (urpmi --downgrade webkit2). > Given that it alone messed the entire update batch comment 3, you could have > excluded it to do the others; maybe you did. > > @Alex > Thank you for both screenshots, which show the same scenario. Your list of > the updated packages in comment 2 is helpful, and agrees with Peter's > surmise. > > All the panics look the same, and the kernel version is the same 5.3.7-*-4 > Peter's the server one, Alex's the desktop one. > > Await Peter's webkit2 downgrade result before assigning the bug. downgrading of webkit2 was not successfully achieved: [root@mga6-64 alain4]# LANGUAGE=C urpmi --downgrade webkit2 The following package has to be removed for others to be upgraded: webkit2-2.26.2-1.mga7.x86_64 (in order to install webkit2-2.26.2-1.mga7.x86_64) (y/N) y http://mirrors.mageia.org/api/mageia.7.x86_64.list: media/core/updates/webkit2-2.26.2-1.mga7.x86_64.rpm installing webkit2-2.26.2-1.mga7.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ################################################################################################################################# 1/1: webkit2 ################################################################################################################################# 1/1: removing webkit2-2.26.2-1.mga7.x86_64 ################################################################################################################################# [root@mga6-64 alain4]# rpm -qa |grep webkit2 lib64qtwebkit2.2_4-2.3.4-13.mga7 webkit2-jsc-2.26.2-1.mga7 webkit2-2.26.2-1.mga7 lib64webkit2gtk4.0_37-2.26.2-1.mga7 lib64webkit2gtk-gir4.0-2.26.2-1.mga7 [root@mga6-64 alain4]# I try to do it manually
successfully done manually with dnf; now: [root@mga6-64 alain4]# rpm -qa |grep webkit2 lib64qtwebkit2.2_4-2.3.4-13.mga7 lib64webkit2gtk-gir4.0-2.24.4-1.mga7 lib64webkit2gtk4.0_37-2.24.4-1.mga7 webkit2-2.24.4-1.mga7 webkit2-jsc-2.24.4-1.mga7 [root@mga6-64 alain4]#
bad news, the problem persists, webkit2 and relative pkgs are clearly not responsible of the problem since any of my system mga7 needs 3mn to boot, this research is very tedious
(In reply to Lewis Smith from comment #10) > @Peter > Thanks for the screenshot and dnf output of the iffy update. > BTW The first attachment c1 seems to be from Mageia 6 (either unsupported or > soon to be); but the second c4 I suppose is Mageia 7. > To test whether the webkit update is responsible, can you please try > *downgrading* it to the previous version (urpmi --downgrade webkit2). > Given that it alone messed the entire update batch comment 3, you could have > excluded it to do the others; maybe you did. > > @Alex > Thank you for both screenshots, which show the same scenario. Your list of > the updated packages in comment 2 is helpful, and agrees with Peter's > surmise. > > All the panics look the same, and the kernel version is the same 5.3.7-*-4 > Peter's the server one, Alex's the desktop one. > > Await Peter's webkit2 downgrade result before assigning the bug. BINGO! I've found the resposible pkg, it is cpio-2.13-1.mga7.x86_64; when downgrading it to cpio-2.12-5.mga7.x86_64, the problem no longer subsists
the responsible update is cpio-2.13-1.mga7.x86_64
(In reply to Ales Cerny from comment #9) > Created attachment 11360 [details] > after Mageia 7 update - Lenovo Thinkpad T440p yesterday, I have found the responsible of the bug, but got no reaction: it's the update cpio-2.13-1.mga7.x86_64; to fix temporarily this problem, you can downgrading to cpio-2.12-5.mga7.x86_64;
(In reply to Lewis Smith from comment #10) > @Peter > Thanks for the screenshot and dnf output of the iffy update. > BTW The first attachment c1 seems to be from Mageia 6 (either unsupported or > soon to be); but the second c4 I suppose is Mageia 7. > To test whether the webkit update is responsible, can you please try > *downgrading* it to the previous version (urpmi --downgrade webkit2). > Given that it alone messed the entire update batch comment 3, you could have > excluded it to do the others; maybe you did. > > @Alex > Thank you for both screenshots, which show the same scenario. Your list of > the updated packages in comment 2 is helpful, and agrees with Peter's > surmise. > > All the panics look the same, and the kernel version is the same 5.3.7-*-4 > Peter's the server one, Alex's the desktop one. > > Await Peter's webkit2 downgrade result before assigning the bug. why have you not yet remove cpio-2.13-1.mga7.x86_64 from the updates, since it is responsible of the problem?
(In reply to peter lawford from comment #17) > why have you not yet remove cpio-2.13-1.mga7.x86_64 from the updates, since > it is responsible of the problem? Because for now, it seems that for most users, it causes no issues what so ever. And it fixes actual security issues. So we need to figure out what in the affected systems trips over this... In order to reproduce it, can you provide a list of packages installed so we can try to replicate the issue. Can you do a: rpm -qa >bug25698-rpmlist and attach that list to this report
(In reply to peter lawford from comment #16) > (In reply to Ales Cerny from comment #9) > > Created attachment 11360 [details] > > after Mageia 7 update - Lenovo Thinkpad T440p > > yesterday, I have found the responsible of the bug, but got no reaction: > it's the update cpio-2.13-1.mga7.x86_64; to fix temporarily this problem, > you can downgrading to > cpio-2.12-5.mga7.x86_64; hi, i have to add cdrom again to my sources, i always remove it after installation :) after entering this command urpmi --downgrade cpio-2.12-5.mga7.x86_64 the package was downgraded and shutdown already works
Created attachment 11361 [details] rpm -qa - my packages on Lenovo Thinkpad T440p
(In reply to Thomas Backlund from comment #18) > (In reply to peter lawford from comment #17) > > > > why have you not yet remove cpio-2.13-1.mga7.x86_64 from the updates, since > > it is responsible of the problem? > > Because for now, it seems that for most users, it causes no issues what so > ever. > And it fixes actual security issues. > > So we need to figure out what in the affected systems trips over this... > > In order to reproduce it, can you provide a list of packages installed so we > can try to replicate the issue. > > Can you do a: > > rpm -qa >bug25698-rpmlist > > and attach that list to this report you are totally right: I have 3 mga7 systems, all obtained by upgrading a former mga6, and a 4th one, I use only for trials, on which I have installed no applications, directly obtained by installation of the iso.image of mageia7 from the depos; on the latter, I've just achieved the last update, INCLUDED cpio-2.13-1.mga7.x86_64, and the shutdown normally worked. This means that upgrading and upgrading linux distribs versions (not only mageia I suppose) is not a good idea; it's better sometimes to reconstruct from zero a new version, but this is very tedious to retune it I shall post the complete list of my packages, but it will be for you a huge task to examin the whole; by advance I apologize
create attachment rpm -qa >bug25698-rpmlist
Created attachment 11362 [details] rpm -qa >bug25698-rpmlist
(In reply to Ales Cerny from comment #20) > Created attachment 11361 [details] > rpm -qa - my packages on Lenovo Thinkpad T440p Created attachment 11362 [details] rpm -qa >bug25698-rpmlist
I would just add that I did not upgrade Mageia 7 from the previous version
(In reply to Ales Cerny from comment #25) > I would just add that I did not upgrade Mageia 7 from the previous version but perhaps have you add the package(s) which conflict(s) with cpio-2.13-1.mga7 my trial system is native, I've never added any application
(In reply to Thomas Backlund from comment #18) > (In reply to peter lawford from comment #17) > > > > why have you not yet remove cpio-2.13-1.mga7.x86_64 from the updates, since > > it is responsible of the problem? > > Because for now, it seems that for most users, it causes no issues what so > ever. > And it fixes actual security issues. > > So we need to figure out what in the affected systems trips over this... > > In order to reproduce it, can you provide a list of packages installed so we > can try to replicate the issue. > > Can you do a: > > rpm -qa >bug25698-rpmlist > > and attach that list to this report sorry, but just one question: my attached file 11362 bug25698-rpmlist contains exactly 3978 names of packages: do you intend to test individually each of them to check if they conflict or not with cpio-2.13-1.mga7.x86_64? if so, I think it is the end of linux as human supported system
hi For information : i have the same kind of problems with 2 on my 3 laptops when i shutdown them. My 3 laptops are under Gnome. The first laptop is an quite old ldlc (clevo) w840su (intel) use wayland. This one has no problems after the update of friday, november 15. The second (lenovo thinkpad x220i) and third (lenovo thinkpad x240) laptops have LVM encrypt partitions, use Xorg have kernel panics at shutdown. May be this kind of description can help.
Created attachment 11363 [details] kernel panic at shutdown on my lenovo X220i A picture to complete my last post
CC: (none) => p.opter
(In reply to peter lawford from comment #26) > (In reply to Ales Cerny from comment #25) > > I would just add that I did not upgrade Mageia 7 from the previous version > > but perhaps have you add the package(s) which conflict(s) with > cpio-2.13-1.mga7 > my trial system is native, I've never added any application i don't think, i use only official repositories (+ repository from Google for Google Chrome, only on one laptop i added repository for Brave browser via DNF), i use Xfce, all i did is that i switched from net_applet to NetworkManager, my booth laptops have LVM encrypted partitions too like Pierre Opter
(In reply to Ales Cerny from comment #30) > (In reply to peter lawford from comment #26) > > (In reply to Ales Cerny from comment #25) > > > I would just add that I did not upgrade Mageia 7 from the previous version > > > > but perhaps have you add the package(s) which conflict(s) with > > cpio-2.13-1.mga7 > > my trial system is native, I've never added any application > > i don't think, i use only official repositories (+ repository from Google > for Google Chrome, only on one laptop i added repository for Brave browser > via DNF), i use Xfce, all i did is that i switched from net_applet to > NetworkManager, > > my booth laptops have LVM encrypted partitions too like Pierre Opter I too use official mageia repos packages, excepted google chrome, skypeforlinux, opera and vivaldi; for me, using official mageia packages is not a guarantee that everything will be OK; a mistake somewhere is always possible all my systems, but the trial one, and all my backup and stockage volumes are lvm2, and all vg's lie on logical (mdadm) RAID volumes
(In reply to peter lawford from comment #17) > why have you not yet remove cpio-2.13-1.mga7.x86_64 from the updates, since > it is responsible of the problem? Peter, I do not live chained to my computer. It is just a day since my last comment (10), and could well be much longer. Also, my e-mail provider has been off-air for over a day, so I could not see posts that way. BTAIM Thank you for all the research you did. This is bound to be helpful. Thank you also Ales & Pierre for your contributions. All 3 of you reported the problem on portable computers, and the panics look the same. A hardware dependency? Some of the systems were upgrades, others new installs. @tmb : thank you for your comment 18. Assigning to the kernel group.
CC: lewyssmith => (none)Assignee: bugsquad => kernel
(In reply to Lewis Smith from comment #32) > (In reply to peter lawford from comment #17) > > why have you not yet remove cpio-2.13-1.mga7.x86_64 from the updates, since > > it is responsible of the problem? > Peter, I do not live chained to my computer. It is just a day since my last > comment (10), and could well be much longer. Also, my e-mail provider has > been off-air for over a day, so I could not see posts that way. > BTAIM Thank you for all the research you did. This is bound to be helpful. > > Thank you also Ales & Pierre for your contributions. > > All 3 of you reported the problem on portable computers, and the panics look > the same. A hardware dependency? Some of the systems were upgrades, others > new installs. > > @tmb : thank you for your comment 18. > Assigning to the kernel group. I understand you, but my computer IS NOT portable, far from it, it's a big tower with 8 internal hdds and 2 external USB, all my systems, backup and stockage are lvm2 and all vg's lies on level5 mdadm RAID volumes I very much hope that the problem will be fixed as soon as possible, and that future cpio versions won't be incompatible with lvm and mdadm tomorrow, if it could help, I'll post a screen picture of a successfull shutdown for my config best regards
Created attachment 11364 [details] after Mageia 7 update - Lenovo R500 with encrypted LVM I tried to install Mageia 7 on my old Lenovo R500 laptop in the first case, I created an unencrypted boot partition and an encrypted LVM partition where I have the /root, /home, and swap partition - after the update I got the same result as you see in the picture in the second case, I didn't create an encrypted LVM partition and after the update everything works I see the connection in my cases with using LVM encryption
(In reply to Ales Cerny from comment #34) > Created attachment 11364 [details] > after Mageia 7 update - Lenovo R500 with encrypted LVM > > I tried to install Mageia 7 on my old Lenovo R500 laptop > > in the first case, I created an unencrypted boot partition and an encrypted > LVM partition where I have the /root, /home, and swap partition - after the > update I got the same result as you see in the picture > > in the second case, I didn't create an encrypted LVM partition and after the > update everything works > > I see the connection in my cases with using LVM encryption exactly as for me, all my mga7 system lie on an lvm2 vg, and shutdown doesn't work; but for the "trial" system I've created from an iso image (and not by updating from mga6) shutdown properly works but this sytem lies on physical partitions of a hdd (no lvm) I think it's the key of the problem
(In reply to Lewis Smith from comment #32) > (In reply to peter lawford from comment #17) > > why have you not yet remove cpio-2.13-1.mga7.x86_64 from the updates, since > > it is responsible of the problem? > Peter, I do not live chained to my computer. It is just a day since my last > comment (10), and could well be much longer. Also, my e-mail provider has > been off-air for over a day, so I could not see posts that way. > BTAIM Thank you for all the research you did. This is bound to be helpful. > > Thank you also Ales & Pierre for your contributions. > > All 3 of you reported the problem on portable computers, and the panics look > the same. A hardware dependency? Some of the systems were upgrades, others > new installs. > > @tmb : thank you for your comment 18. > Assigning to the kernel group. Hi, I think you should read comment 34, provided you are chained to your computer (joke) I think here is the key of problem; many users have their system encrypted by lvm (especially the big servers) it's seems to me urgent to release a new version of cpio bye
(In reply to Thomas Backlund from comment #18) > (In reply to peter lawford from comment #17) > > > > why have you not yet remove cpio-2.13-1.mga7.x86_64 from the updates, since > > it is responsible of the problem? > > Because for now, it seems that for most users, it causes no issues what so > ever. > And it fixes actual security issues. > > So we need to figure out what in the affected systems trips over this... > > In order to reproduce it, can you provide a list of packages installed so we > can try to replicate the issue. > > Can you do a: > > rpm -qa >bug25698-rpmlist > > and attach that list to this report please read comment 34
(In reply to Thomas Backlund from comment #18) > (In reply to peter lawford from comment #17) > > > > why have you not yet remove cpio-2.13-1.mga7.x86_64 from the updates, since > > it is responsible of the problem? > > Because for now, it seems that for most users, it causes no issues what so > ever. because there are 2 categories of users: 1) those whose system lies on hdd's physical partitions: those have no problem with cpio-2.13-1 2)those, like me, whose system lies on lvm vg, with logical volumes as partitions, and these ones have shutdown issues according to comment 34 of course > And it fixes actual security issues. > > So we need to figure out what in the affected systems trips over this... > > In order to reproduce it, can you provide a list of packages installed so we > can try to replicate the issue. > > Can you do a: > > rpm -qa >bug25698-rpmlist > > and attach that list to this report
Created attachment 11366 [details] webkit2 ? I forget that when i did the update for my second laptop lenovo x220i after the first laptop (lenovo x240), i made a screenshot of the MCC. And, in fact i'm quite sure that when i made the update of my ldlc (clevo) laptop (no lvm, just encrypt hdd) the mcc did not ask to me to desinstall this webkit2 package (cf the screen capture). I dont'know if this information can help you.
I've managed to reproduce the cpio bug and am currently bisecting it
Please test with cpio-2.13-1.1.mga7 (currently building)
(In reply to Thomas Backlund from comment #41) > Please test with cpio-2.13-1.1.mga7 (currently building) shutdown runs now OK
Advisory, added to svn type: bugfix subject: Updated cpio packages fix system crash on shutdown or reboot. src: 7: core: - cpio-2.13-1.1.mga7 description: | The cpio update to 2.13 in MGASA-2019-0326 contained an upstream fix for CVE-2015-1197 symlink attack. Unfortunately that fix caused a regression on atleast some systems using lvm or mdadm, causing them to crash on shutdown or reboot. This update solves this by reverting the upstream fix, and reverting to the older well tested variant of the fix that is known to not cause crashes. references: - https://bugs.mageia.org/show_bug.cgi?id=25698
Assignee: kernel => qa-bugsWhiteboard: (none) => MGA7-64-OKKeywords: (none) => advisory, validated_update
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2019-0213.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED