Bug 28744

Summary:	Distribution upgrade MGA 7 - 8 fails using mgaapplet on wyze thin client
Product:	Mageia	Reporter:	Rolf Pedersen <rolfpedersen>
Component:	RPM Packages	Assignee:	Mageia Bug Squad <bugsquad>
Status:	RESOLVED INVALID	QA Contact:
Severity:	enhancement
Priority:	Normal	CC:	davidwhodgins, fri
Version:	7
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:	mgaonline-3.30-1.mga7.src.rpm	CVE:
Status comment:
Attachments:	report.bug.xz

Description Rolf Pedersen 2021-04-07 20:21:24 CEST

I attempted the MGA 7-8 upgrade via the applet, once that was enabled, on 3 of the 4 machines I have running Mageia 64-bit on the LAN.  2 of those 3 succeeded, one of those a wyze thin client with very similar hardware specs, the other wyze failed with a pop-up install failure message fairly deep into packages installation.  I thought space problems but df shows 1.7G out of 13G on / available.  The successful wyze shows 3.4G out of 15G available on /.  

I thought the details might be of some interest but am not expecting wide-spread applicability.  Thus, enhancement, easily solved as NOTABUG or such, just in case someone would like to investigate.  The machine is not terribly vital but, as part of my daily usage as a pi surveillance cameras monitor, I'll move onto an upgrade installation from Classic iso on usb key before too long.

I booted SystemRescueCD on usb key, set up a chroot to the MGA 7 installation on the 16GB flash drive, and scp'ed the /root/ directory, including some diagnostic text files I generated in the chroot.  Following are the contents of that root/ and fdisk, sda being the machine drive holding the OS.  I'll attach report.bug.xz (Maybe I could xz the entire root/ and attach?).

Thanks.

ls -R:

.:
aif-mount/
all-contents.txt
cpuinfo.txt
df.txt
drakx/
fdisk.txt
fstab.txt
inxi.txt
lspci-v.txt
mageia-release.txt
meminfo.txt
simple-contents.txt
tmp/

./aif-mount:

./drakx:
auto_inst.cfg.pl
ddebug.log
install.log
package_list.pl
README
report.bug.xz
stage1.log

./tmp:

fdisk -l:

Disk /dev/sda: 14.94 GiB, 16013942784 bytes, 31277232 sectors
Disk model: 16GB SATA Flash 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x494aae88

Device     Boot    Start      End  Sectors   Size Id Type
/dev/sda1  *        2048   610469   608422 297.1M ef EFI (FAT-12/16/32)
/dev/sda2         614376 31262489 30648114  14.6G  5 Extended
/dev/sda5         614400 26507249 25892850  12.4G 83 Linux
/dev/sda6       26509312 31262489  4753178   2.3G 82 Linux swap / Solaris


Disk /dev/sdb: 14.43 GiB, 15483273216 bytes, 30240768 sectors
Disk model: DataTraveler 2.0
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3766e750

Device     Boot Start     End Sectors  Size Id Type
/dev/sdb1  *        0 1431551 1431552  699M  0 Empty
/dev/sdb2         236    3115    2880  1.4M ef EFI (FAT-12/16/32)


Disk /dev/loop0: 638.41 MiB, 669409280 bytes, 1307440 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Comment 1 Rolf Pedersen 2021-04-07 20:23:12 CEST

Created attachment 12593 [details]
report.bug.xz

Comment 2 Morgan Leijström 2021-04-07 22:16:23 CEST

Thank you for this report

I see a lot of failures of curl retrieving files
(search that file for "curl failed")

This intermittent failure of curl makes me wonder if this is a case of
Bug 24362 - Change default package downloader to wget

Which seem to depend on machine/wifi hardware

Did you use same connection?
wifi or Ethernet?

CC: (none) => fri

Comment 3 Rolf Pedersen 2021-04-07 22:55:14 CEST

I've got a wifi dongle that uses a driver from github that uses dkms.  Also, the machine has an ethernet connection.  

report.bug has a problem that is maybe related to the ethernet connection:

[rolf@x570i 8]$ grep -i unable report.bug
<7>[    0.433254] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
<4>[   77.047032] r8169 0000:04:00.0 enp4s0: unable to load firmware patch rtl_nic/rtl8168e-3.fw (-2)
[   198.369] (EE) Unable to find a valid framebuffer device
Unable to load plugin module [/usr/lib64/mutter-4/plugins/libdefault.so]: /usr/lib64/mutter-4/plugins/libdefault.so: cannot open shared object file: No such file or directory* lang:en_US charset:C font:DejaVu Sans 12 consolefont:lat0-16
[rolf@x570i 8]$

and lspci shows for the nic:

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
	Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
	Flags: bus master, fast devsel, latency 0, IRQ 17
	I/O ports at 1000 [size=256]
	Memory at 90804000 (64-bit, prefetchable) [size=4K]
	Memory at 90800000 (64-bit, prefetchable) [size=16K]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
	Capabilities: [70] Express Endpoint, MSI 01
	Capabilities: [b0] MSI-X: Enable+ Count=4 Masked-
	Capabilities: [d0] Vital Product Data
	Capabilities: [100] Advanced Error Reporting
	Capabilities: [140] Virtual Channel
	Capabilities: [160] Device Serial Number a7-00-00-00-68-4c-e0-00
	Kernel driver in use: r8169
	Kernel modules: r8169

WRT curl, there are quite a few messages including that term, e.g.:

grep -i failed report.bug

...
* error: curl failed: exited with 22
* retrieval of [/mnt/var/cache/urpmi/oem-theme.rpm] failed
* error: curl failed: exited with 22
* retrieval of [/mnt/var/cache/urpmi/list] failed
* error: curl failed: exited with 22
* retrieval of [/mnt/var/cache/urpmi/list] failed
* error: curl failed: exited with 22
...

Thanks.

Comment 4 Morgan Leijström 2021-04-07 23:10:28 CEST

Umm, I see it was trying to retrieve mga7 packages.
There is not a single instance of "mga8" in this file.

********************************************************************************
* stage1.log
********************************************************************************
* welcome to the Mageia install (mdk-stage1, version 7 built May 18 2019 23:09:17)


So is this the log from a mga7 install?


And the curl failures was only on one rpm, but several other files. Strange.


For the moment i can not say where to find the upgrade log...

Comment 5 Rolf Pedersen 2021-04-07 23:16:11 CEST

Bummer.  My theory is that the files were from the installation of MGA7 and, since installation was aborted, the MGA8 installation files were not written?

Comment 6 Rolf Pedersen 2021-04-07 23:24:42 CEST

I don't think we have anything to work with, here.  Thanks.

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

Comment 7 Dave Hodgins 2021-04-08 01:41:57 CEST

Do make sure kernel-firmware-nonfree is installed for the file
/lib/firmware/rtl_nic/rtl8168e-3.fw

CC: (none) => davidwhodgins

Comment 8 Rolf Pedersen 2021-04-08 03:33:19 CEST

Hi Dave,
I got 'er up and running with the 4G iso update and it turns out there are space problems that I'm juggling through, now.  Maybe I'll get inside and try to upgrade the storage.  Nonetheless,

[rolf@wyze2 ~]$ uname -r
5.10.27-desktop-1.mga8
[rolf@wyze2 ~]$ cat /etc/release
Mageia release 8 (Official) for x86_64

Thanks ;)