Bug 24950 - [oops] Upgrading online from mga6 to mga7 using urpmi locked up ~80% complete
Summary: [oops] Upgrading online from mga6 to mga7 using urpmi locked up ~80% complete
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 7
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-14 02:54 CEST by Felix Miata
Modified: 2021-09-07 14:10 CEST (History)
6 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments
.tgz of journalctl -b -1 (upgrade boot) and journalctl -b (finish upgrade) (71.26 KB, application/octet-stream)
2019-06-14 02:54 CEST, Felix Miata
Details

Description Felix Miata 2019-06-14 02:54:56 CEST
Created attachment 11091 [details]
.tgz of journalctl -b -1 (upgrade boot) and journalctl -b (finish upgrade)

Original summary:
[oops] Upgrading online from mga6 to mga7 using urpmi locked up ~80% complete

I was following the urpmi upgrade instruction at:
https://wiki.mageia.org/en/Mageia_7_Release_Notes

I'm only educated guessing that the immutable /boot/initrd.img is the root cause of needing to abort via the power button while auto-select had progressed to ~290 packages remaining to install. Before apparent total lockup I attempted remote login, which failed, but was able to get top running on vtty2. CPU was at 100% with *edid* staying at the top of the command list before lockup became total. .bash_history was not updated, so the session's command history was lost. Reboot using 4.14 kernel succeeded, as did follow-up urpmi --auto-select, followed by urpmi kernel-desktop-latest.

Upgrade phase 1 ran on: AMD/ATI RV610 [Radeon HD2400 PRO] driver: radeon v: kernel bus ID: 01:00.0 chip ID: 1002:94c3, but I removed it to finish, thinking the 100% EDID process may have overheated the GPU, or that a mailing list report of trouble with a Radeon HD3000 on mga7 might be related to the lockup. After installing the new kernel I powered down, reinstalled the HD2400, and rebooted 5.1.9 almost successfully (fixed IP network broken).

Current state:
# inxi -Gxxba
# inxi -Gxxba
System:    Host: hpg33 Kernel: 5.1.9-desktop-1.mga7 x86_64 bits: 64 compiler: gcc v: 8.3.1
           parameters: root=LABEL=mga7sd32 ipv6.disable=1 net.ifnames=0 noresume mitigations=auto consoleblank=0 noxorgconf
           plymouth.enable=0 speedboot=no vga=791 video=1024x768@60 video=1440x900@60 3
           Desktop: Trinity R14.0.4 tk: Qt 3.5.0 wm: Twin dm: startx Distro: Mageia 7 mga7
Machine:   Type: Desktop System: HP-Pavilion product: KJ385AA-ABA a6433w v: N/A serial: MXU81408RY Chassis: Hewlett-Packard
           type: 3 serial: N/A
           Mobo: PEGATRON model: Benicia v: 1.01 serial: X312345678 BIOS: American Megatrends v: 5.43 date: 09/10/2009
CPU:       Dual Core: Intel Core2 Duo E7500 type: MCP arch: Penryn speed: 1600 MHz min/max: 1600/2933 MHz
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] RV610 [Radeon HD 2400 PRO] vendor: Dell driver: radeon v: kernel
           bus ID: 04:00.0 chip ID: 1002:94c3
           Display: tty server: Mageia X.org 1.20.4 driver: ati,radeon unloaded: modesetting,vesa alternate: fbdev
           resolution: 1920x1200~60Hz
           OpenGL: renderer: AMD RV610 (DRM 2.50.0 / 5.1.9-desktop-1.mga7 LLVM 8.0.0) v: 3.3 Mesa 19.1.0 compat-v: 3.0
           direct render: Yes
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet vendor: Hewlett-Packard Asus IPIBL-LB
           driver: r8169 v: kernel port: e800 bus ID: 02:00.0 chip ID: 10ec:8168
Drives:    Local Storage: total: 298.09 GiB used: 83.76 GiB (28.1%)
Info:      Processes: 156 Uptime: 3m Memory: 1.95 GiB used: 235.7 MiB (11.8%) Init: systemd v: 241 runlevel: 3
           target: runlevel5.target Compilers: gcc: N/A Shell: bash v: 4.4.23 running in: konsole inxi: 3.0.34
Comment 1 Martin Whitaker 2019-06-14 19:57:06 CEST
I suspect the hang comes from the post-install script of mageia-theme, which runs /usr/libexec/mga-bg-res, which in turn runs /sbin/monitor-edid. I have seen monitor-edid hang indefinitely when running in a chroot, but haven't seen this on a real system.

CC: (none) => mageia

Comment 2 Felix Miata 2019-06-14 20:22:21 CEST
Comment #1 sounds exactly like what I saw, on real hardware, an HP Pavilion that shipped with Vista.
Comment 3 Marja Van Waes 2019-06-15 11:28:53 CEST
(In reply to Martin Whitaker from comment #1)
> I suspect the hang comes from the post-install script of mageia-theme, which
> runs /usr/libexec/mga-bg-res, which in turn runs /sbin/monitor-edid. I have
> seen monitor-edid hang indefinitely when running in a chroot, but haven't
> seen this on a real system.

CC'ing some monitor-edid submitters

CC: (none) => guillomovitch, marja11, pterjan, shlomif, thierry.vignaud

Marja Van Waes 2019-06-15 11:29:28 CEST

Assignee: bugsquad => mageiatools

Comment 4 Aurelien Oudelet 2021-07-06 13:15:10 CEST
Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.
Comment 5 Marja Van Waes 2021-09-07 14:10:45 CEST
Hi bug reporter and hi assignee and others involved,

Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly.

This report is being closed as OLD because it was filed against Mageia 7, for which  support ended on June 30th 2021.

Thanks,
Marja

Resolution: (none) => OLD
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.