Bug 28430

Summary:	When upgrading to mga8 from mga7, the boomaga update fails to remove the mga7 package
Product:	Mageia	Reporter:	Thomas Andrews <andrewsfarm>
Component:	Installer	Assignee:	Mageia tools maintainers <mageiatools>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	Normal	CC:	mageia, ouaurelien
Version:	8
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:
Source RPM:		CVE:
Status comment:
Attachments:	report.bug.xz for the installed system report.bug.xz from a vbox guest

Description Thomas Andrews 2021-02-24 16:26:00 CET

Description of problem:
I recently performed an upgrade install of a 64-bit Plasma system that included the latest mga7 boomaga package. I installed from the CI iso, and didn't set up online media until after starting my wired Internet connection during the "post-install Configuration" screen.

At the end of the update phase, I was informed that there had been a script error concerning boomaga. Later, when examining the update log, I saw that the report was that removal of the mga7 boomaga had failed. 

That was indeed the case, as I found both boomaga versions were still installed. There was one boomaga printer active in system-config-printer, the mga7 one. 

Removing the mga7 package using drakrpm went without incident, and removed the active boomaga printer from system-config-printer. The new one had to be installed by the user. This is consistent with what was discovered in Bug 26032, that when boomaga is first installed it automatically installs the virtual printer to the system, but removes it without installing a new one during an update.

I don't know why the script failed this time, when there was no such stumble during update testing in Bug 26032. My guess is that it had something to do with our installer balking at the removal of a printer during an upgrade. If so, then mga8 probably is also affected, and the same script error will come up when there are upgrades from mga8 to mga9.

I don't know if there is anything we can do about it, but I thought we should be on record as knowing the situation exists.

Comment 1 Aurelien Oudelet 2021-02-24 16:41:10 CET

Hi, thanks reporting this.

Using DrakX to update an already installed system to a higher version, it is strongly mandatory to activate online repositories as all packages installed cannot be on the limited place of the DVD.
That you already know.

Can you provide /root/drakx/report.bug.xz attached here, (from the newer installed system), please?

Added Martin for forensics.

Version: 7 => 8
CC: (none) => mageia, ouaurelien
Component: RPM Packages => Installer

Comment 2 Aurelien Oudelet 2021-02-24 16:42:29 CET

Leaving this in Bugsquad until additional information.

Keywords: (none) => NEEDINFO

Comment 3 Thomas Andrews 2021-02-24 16:55:10 CET

Created attachment 12381 [details]
report.bug.xz for the installed system

Comment 4 Thomas Andrews 2021-02-24 17:10:15 CET

(In reply to Aurelien Oudelet from comment #1)
> Hi, thanks reporting this.
> 
> Using DrakX to update an already installed system to a higher version, it is
> strongly mandatory to activate online repositories as all packages installed
> cannot be on the limited place of the DVD.
> That you already know.
> 
Yes, so I have already been reliably informed, several times lately. My own fault, for failing to RTFL all these years.

So, I will try installing boomaga in a vbox mga7 guest, then upgrading the PROPER way, and see if the same error occurs. Be patient - this may take a while.

> Can you provide /root/drakx/report.bug.xz attached here, (from the newer
> installed system), please?
> 
Done.

> Added Martin for forensics.

Comment 5 Aurelien Oudelet 2021-02-24 17:42:26 CET

Thanks Thomas!

Assigning.

Assignee: bugsquad => mageiatools
Keywords: NEEDINFO => (none)

Comment 6 Thomas Andrews 2021-02-24 19:27:01 CET

(In reply to Thomas Andrews from comment #4)
> Yes, so I have already been reliably informed, several times lately. My own
> fault, for failing to RTFL all these years.
> 
Oops. Wrong acronym. I meant RTFM, of course.

> So, I will try installing boomaga in a vbox mga7 guest, then upgrading the
> PROPER way, and see if the same error occurs. Be patient - this may take a
> while.
> 
So I did the above, installing all of my printers in the vbox guest, just as they are on real hardware. Then I did the upgrade, the proper way. 

I did encounter the samba-client script error (addressed in another bug), but did not see a script error message concerning boomaga. However, when I used MCC to investigate, I learned that the mga7 version of boomaga had NOT been removed. There is still a "generic Boomaga" printer listed in system-config-printer, though I'm not sure how to determine which of the boomagas it belongs to.

Give me a few minutes, and I will attach a report.bug.xz from the vbox guest.

So I feel somewhat vindicated here. This is apparently a problem with the install scripts, but while it needs to be corrected I don't think it's bad enough to hold the release back. It's easily corrected afterward. When I filed the bug I hoped it could be corrected with some kind of update to mga7. What do you guys think?

Comment 7 Thomas Andrews 2021-02-24 19:45:50 CET

Created attachment 12383 [details]
report.bug.xz from a vbox guest

I searched through the file for all instances of "boomaga" and I found where the script error showed up. There was something else on the next line about a workaround that was applied, but I don't know if it's relevant to the discussion.