Description of problem: On an upgrade install of Mageia 8 Plasma from the latest 64-bit "final" CI, I received two script errors: The first was at the end of the packages installed from the iso itself, and concerned samba-client 4.10.18-1.1. After getting the notice, things proceeded without further incident until the end of upgrading packages from the online repositories, and concerned the boomaga package. On the first boot, things seemed normal, except that the MageiaSync and Isodumper packages had been completely removed, not upgraded. Looking with drakrpm, It appears that the samba-client package had been installed, as was the mga8 boomaga package, but the mga7 boomaga package had not been removed. And I was able to confirm that MageiaSync and Isodumper were no longer installed. I tried "urpmi --auto-update" which generated no updates but did give me a long list of orphaned packages. I removed them with a bit of trepidation, but apparently suffered no ill effects. Affected hardware: Intel motherboard, i5 2500, 16GB RAM, Intel graphics, wired Internet connection, HP Laserjet CP1215 printer, HP Deskjet 5650 printer, HP Officejet 6500 all-in-one.
Calling this a release blocker until the actual extent of the samba-client script error can be ascertained. I suspect the removal of Mageia sync and Isodumper may be related to this error, but I don't know enough to be at all sure of it. The boomaga error, while annoying and it looks bad, is probably easily fixed manually by the user.
Keywords: (none) => 8finalPriority: Normal => release_blocker
did you upgrade without online medias added ? if so that explains mageiasync and isodumper as they are not on isos, so since they probably depends on specific python, tey get nuked in the upgrade
(In reply to Thomas Andrews from comment #1) > Calling this a release blocker until the actual extent of the samba-client > script error can be ascertained. I suspect the removal of Mageia sync and > Isodumper may be related to this error, but I don't know enough to be at all > sure of it. > > The boomaga error, while annoying and it looks bad, is probably easily fixed > manually by the user. for samba-client, this is on x86_64. Note that David Hodgins does not seem to see this this morning and he closed Bug https://bugs.mageia.org/show_bug.cgi?id=28042. So. Reopening this.
CC: (none) => ouaurelien
I set for_errata, but await for more input or fix
Keywords: (none) => FOR_ERRATA8CC: (none) => fri
there is no errata stuff here... samba bits are already being tracked in the othet bug
Keywords: FOR_ERRATA8 => (none)
(In reply to Thomas Backlund from comment #2) > did you upgrade without online medias added ? > > if so that explains mageiasync and isodumper as they are not on isos, so > since they probably depends on specific python, tey get nuked in the upgrade No, online media was added. That was how I got the boomaga script error.
Do you have the logs from the upgrade install? Was the online media added at the beginning of the install or at the end?
CC: (none) => davidwhodgins
(In reply to Dave Hodgins from comment #7) > Do you have the logs from the upgrade install? > I remember they are there someplace, but have forgotten where they are stored or how to access them. It's been a couple of years, at least. > Was the online media added at the beginning of the install or at the end? At the end. I didn't know you could add online media until the Internet connection had been started after the install. Other upgrades have "just worked," though they didn't have as much "extra" stuff as this one.
I was able to easily install both MageiaSync and Isodumper. They brought in a bunch of dependencies, but they might have been removed when I dumped what urpmi told me were now orphans. I removed the mga7 boomaga, which removed the boomaga printer, but going to system-config-printer and adding it back again was successful. I had to go there anyway and tell the server not to publish the shared printers, so that only one of each showed when I printed something.
(In reply to Thomas Andrews from comment #8) > (In reply to Dave Hodgins from comment #7) > > Do you have the logs from the upgrade install? > > > I remember they are there someplace, but have forgotten where they are > stored or how to access them. It's been a couple of years, at least. Look for /root/*.log or /root/*/*.log depending on how the upgrade was done.
Created attachment 12376 [details] Mageia 8 upgrade install log Found it in /root/drakx.
Created attachment 12377 [details] ddebug.log
* chkconfig not installed, %triggerun(samba-client-4.10.18-1.1.mga7.x86_64) scriptlet failed, exit status 1 In Mageia 7 ... ]# rpm -q --triggers samba-client triggerin scriptlet (using /bin/sh) -- cups ln -sf /usr/libexec/samba/cups_backend_smb /usr/lib/cups/backend/smb || : # Remove the symlink if either samba-client or cups is removed triggerun scriptlet (using /bin/sh) -- cups [[ $1 == 0 || $2 == 0 ]] && rm -f /usr/lib/cups/backend/smb # Clean up alternatives from 3.x dropped with 4.x: triggerpostun scriptlet (using /bin/sh) -- samba-client < 4.10.9 /usr/sbin/update-alternatives --remove smbclient /usr/bin/smbclient3 || : # There seems to be no other way to do this: rm -f /var/lib/alternatives/smbclient ### KRB5-PRINTING In my upgrade test, I removed as many large packages as I could prior to the upgrade, which included removing task printing scanning and all it's orphans, including cups, so that's why I didn't encounter it. Anyway, it doesn't cause the transaction to fail or negatively impact the upgrade except for the message briefly on the screen, and later in the logs. Decreasing the priority. We know the fix, it just has to get built as an update in Mageia 7.
Priority: release_blocker => NormalSeverity: major => normal
> The first was at the end of the packages installed from the iso itself, and concerned samba-client 4.10.18-1.1. After getting the notice, things proceeded without further incident Unfortunately, the problem is the trigger of the package on your installed system prior to the upgrade, not from the one you are upgrading to. We can fix getting the warning during the upgrade, but only by pushing an update that will also give the warning when installing the update.
Status: NEW => ASSIGNEDCC: (none) => bgmilne
Samba stuff is handled in Bug 28042, which is in errata.
Depends on: (none) => 28393
Created attachment 12434 [details] Testing Mageia 7 to 8 with boomaga and isodumper and Qarepo installed MGA 7 Plasma x86_64 Virtual Machine. Fully updated. Boomaga installed default printer (cups running) and also isodumper and QARepo. using Thomas's methodology: Classic ISO with online repositories. Rebooting on the VM. Choose Upgrading Mageia 7 Enabling online repositories (http://ftp.free.fr/) Nearly over 2325 packages to updates. Only get the attached error (boomaga script and samba script) No other errors. Later, right after reboot: $ rpm -qa | grep isodumper isodumper-1.33-1.mga8 isodumper-qt-1.33-1.mga8 $ rpm -qa | grep qarepo qarepo-1.6-5.mga8 Boomaga still the printer in system-config-printer. Able to print a PDF... See Boomaga 3.0.0 in Help => About BUT: $ rpm -qa | grep boomaga boomaga-3.0.0-3.mga8 boomaga-3.0.0-1.mga7 So, NO, this needs a proper fix. Also, on a side note about samba script error: $ rpm -qa | grep samba vlc-plugin-samba-3.0.12.1-2.1.mga8.tainted samba-winbind-modules-4.12.11-1.mga8 samba-common-4.12.11-1.mga8 samba-winbind-4.12.11-1.mga8 samba-winbind-clients-4.12.11-1.mga8 lib64heimntlm-samba4_1-4.12.11-1.mga8 lib64samba1-4.12.11-1.mga8 samba-client-4.12.11-1.mga8 lib64kdc-samba4_2-4.12.11-1.mga8 lib64samba-dc0-4.12.11-1.mga8 No mga7 packages.
(To make more readable, I cut my comment, so this is the next part) Having 2 boomaga packages is not recommended, notably the mga7 one. So, # urpme boomaga-3.0.0-1.mga7 désinstallation de boomaga-3.0.0-1.mga7.x86_64 désinstallation du paquetage boomaga-3.0.0-1.mga7.x86_64 1/1: désinstallation de boomaga-3.0.0-1.mga7.x86_64 ########### (CUT) writing /var/lib/rpm/installed-through-deps.list Hum. No boomaga printer in system-config-printer... but, mga8 package still here... # urpmi boomaga Package boomaga-3.0.0-3.mga8.x86_64 is already installed # urpmi --replacepkg boomaga $MIRRORLIST: media/core/release/boomaga-3.0.0-3.mga8.x86_64.rpm installing boomaga-3.0.0-3.mga8.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ########################################################################################################################################################################### 1/1: boomaga ########################################################################################################################################################################### lpadmin: The printer or class does not exist. error: %preun(boomaga-3.0.0-3.mga8.x86_64) scriptlet failed, exit status 1 ERROR: 'script' failed for boomaga-3.0.0-3.mga8.x86_64 error: boomaga-3.0.0-3.mga8.x86_64: erase failed lpadmin: The printer or class does not exist. error: %preun(boomaga-3.0.0-3.mga8.x86_64) scriptlet failed, exit status 1 ERROR: 'script' failed for boomaga-3.0.0-3.mga8.x86_64 error: boomaga-3.0.0-3.mga8.x86_64: erase failed This is a silly bug... hum. I can't uninstall it there after...
# urpme boomaga --force removing boomaga-3.0.0-3.mga8.x86_64 lpadmin: The printer or class does not exist. error: %preun(boomaga-3.0.0-3.mga8.x86_64) scriptlet failed, exit status 1 ERROR: 'script' failed for boomaga-3.0.0-3.mga8.x86_64 error: boomaga-3.0.0-3.mga8.x86_64: erase failed lpadmin: The printer or class does not exist. error: %preun(boomaga-3.0.0-3.mga8.x86_64) scriptlet failed, exit status 1 ERROR: 'script' failed for boomaga-3.0.0-3.mga8.x86_64 error: boomaga-3.0.0-3.mga8.x86_64: erase failed lpadmin: The printer or class does not exist. error: %preun(boomaga-3.0.0-3.mga8.x86_64) scriptlet failed, exit status 1 ERROR: 'script' failed for boomaga-3.0.0-3.mga8.x86_64 error: boomaga-3.0.0-3.mga8.x86_64: erase failed I think this is because there is no longer a boomaga printer class device in cups config... How to readd this?
Summary: Upgrade Plasma install from the CI has two script errors, removes Mageiasync and isodumper => Upgrade Plasma install has boomaga script error, lead to 2 packages boomaga installed.
There were also some quirk in latest mga7 boomaga update, that it was removed from system-config-printing, user had to reconfigure it https://bugs.mageia.org/show_bug.cgi?id=26032#c14 So maybe still the same packaging problem at the bottom?
Blocks: (none) => 28393Depends on: 28393 => (none)
(In reply to Aurelien Oudelet from comment #17) > I can't uninstall it there after... Use "rpm -e --noscripts boomaga" to uninstall it.
(In reply to Morgan Leijström from comment #19) > There were also some quirk in latest mga7 boomaga update, that it was > removed from system-config-printing, user had to reconfigure it > > https://bugs.mageia.org/show_bug.cgi?id=26032#c14 > > So maybe still the same packaging problem at the bottom? Yes, I think so. On my original upgrade, removing the mga7 boomaga also removed the configured printer. Using system-config-printer I was then able to install the mga8 boomaga printer onto the system. So far, my vbox test install has been left alone, still with mga7 and mga8 versions left installed. What we found in bug 26032 was this: Installing boomaga automatically creates an active printer. Removing boomaga removes the active printer it created. Updating boomaga removes the existing active printer, but doesn't actively replace it. The replacement is there, but has to be activated manually. I believe this behavior is somehow at the heart of the problem.
The original log shows: %triggerun(samba-client-4.10.18-1.1.mga7.x86_64) scriptlet failed, exit status 1 removing upgraded package samba-client-4.10.18-1.1.mga7.x86_64 This indicates that no, the samba-client scriptlet error did not result in any upgrade issues. As such, I am removing myself from the CC on this bug. If there really is a problem with samba-client that can be fixed without giving the same error with the fix (the problem here existed in samba-client prior to 4.10.18, IOW the one that was installed on your Magiea 7 system), feel free to add me back. (I don't have boomaga installed on any systems, didn't know what it was until today ...)
CC: bgmilne => (none)
Hum for this: Boomaga mga7 version should be removed manually by user. Currently in a mga7 Plasma VM + boomaga installed and setup + updated to Mageia 8 using urpmi, this leads me to an unpleasant situation. (In reply to Dave Hodgins from comment #20) > (In reply to Aurelien Oudelet from comment #17) > > I can't uninstall it there after... > > Use "rpm -e --noscripts boomaga" to uninstall it. This can't run well saying me: error: "boomaga" specifies multiple packages: boomaga-3.0.0-3.mga8 boomaga-3.0.0-3.mga8 boomaga-3.0.0-3.mga8 Note the same version number. Completely useless. urpmi --reinstall boomaga $MIRRORLIST: media/core/release/boomaga-3.0.0-3.mga8.x86_64.rpm installation de boomaga-3.0.0-3.mga8.x86_64.rpm depuis /var/cache/urpmi/rpms Préparation... ########################################################################################################################################################################### 1/1: boomaga ########################################################################################################################################################################### lpadmin : The printer or class does not exist. erreur : %preun(boomaga-3.0.0-3.mga8.x86_64) scriptlet échoué, état de sortie 1 ERROR: 'script' failed for boomaga-3.0.0-3.mga8.x86_64 erreur : boomaga-3.0.0-3.mga8.x86_64: effacer échoué lpadmin : The printer or class does not exist. erreur : %preun(boomaga-3.0.0-3.mga8.x86_64) scriptlet échoué, état de sortie 1 ERROR: 'script' failed for boomaga-3.0.0-3.mga8.x86_64 erreur : boomaga-3.0.0-3.mga8.x86_64: effacer échoué lpadmin : The printer or class does not exist. erreur : %preun(boomaga-3.0.0-3.mga8.x86_64) scriptlet échoué, état de sortie 1 ERROR: 'script' failed for boomaga-3.0.0-3.mga8.x86_64 erreur : boomaga-3.0.0-3.mga8.x86_64: effacer échoué Why running this 3 times? because 3 multiples packages above? I don't have any clue on this. I only recommend to advertise user to remove boomaga from their Mageia 7 installation before attempting upgrade. Or, I shall try to remove .mga8 version before the .mga7 version...
Assigning to boomaga registered maintainer.
Keywords: 8final => (none)Priority: Normal => HighComponent: Release (media or process) => RPM PackagesSource RPM: (none) => boomaga-3.0.0-3.mga8.src.rpmSeverity: normal => critical
CC: (none) => geiger.david68210
Assignee: bugsquad => dglent
Status comment: (none) => boomaga virtual printer unavailable after upgrade. Must be removed beforeSummary: Upgrade Plasma install has boomaga script error, lead to 2 packages boomaga installed. => Boomaga from M7 is still installed after upgrading to M8, leading to 2 boomaga packages installed
Trying to find a workaround in VirtualBox for those who had already gone through the upgrade and found themselves with both boomagas still installed. I was unable to remove either or both boomagas using drakrpm. I tried removing the boomaga printer from system-config-printer, same result. Re-installing the boomaga printer in hopes that the mga8 version would be the one installed, allowing the mga7 version to be removed, same result. However, running "rpm -e --noscripts boomaga" as Dave suggested netted me this: # rpm -e --noscripts boomaga error: "boomaga" specifies multiple packages: boomaga-3.0.0-1.mga7 boomaga-3.0.0-3.mga8 "rpm -e --noscripts boomaga-3.0.0-1.mga7" successfully removed the mga7 package. Going back to system-config-printer, the boomaga printer was still there, and trying it from gwenview showed that it still functions. So, I'm concluding that the boomaga printer now installed on the system is the mga8 version.
After latest upgrade test with testing repos enabled only boomaga-3.0.0-3.mga8 left installed.
Keywords: (none) => validated_updateWhiteboard: (none) => MGA8-64-OK
Was the printer also still configured and working? (we had problem earlier, with it "dissapearing", despite package was installed)
I only know from the upgrade log that it installed cleanly leaving only one boomaga package. Due to bug 28522 the upgrade was left with a non working gui, and a number of other problems, so not easy to confirm the printer status. I'll check that after I repeat the upgrade test once the opencv-devel bug is fixed.
Removing the validation until I confirm the printer remains configured.
Keywords: validated_update => (none)
(In reply to Dave Hodgins from comment #26) > After latest upgrade test with testing repos enabled only > boomaga-3.0.0-3.mga8 > left installed. Ah. That type of upgrade is more or less the same as installing updates. Yes, that would probably work. It's the script connected with upgrading from the various isos that won't remove the mga7 boomaga.
That shouldn't matter. Clearly the online repos were enabled, as boomaga is not on any of the iso images. The installation process for an upgrade is the same whether it's run from an iso with online media enabled or from an existing install being upgraded using urpmi. The only difference is that there are packages on the iso that are also on the online release repos, so they don't have to be downloaded again. The boomaga package is not on the iso images so whether the iso is used or not, it's downloading from the online repos. The only difference between that and the test I did was that I also enabled the online testing repos as update repos using drakrpm-edit-media --expert.
Just to make sure it's clear, my test was to confirm whether or not the updates testing version fixed the issue so that the update can be validated. I'll repeat the test tomorrow to see if opencv-devel has been fixed, which if it is will allow me to confirm whether or not system-config-printer still shows the boomaga printer enabled.
(In reply to Dave Hodgins from comment #31) > > The only difference between that and the test I did was that I also enabled > the online testing repos as update repos using drakrpm-edit-media --expert. But there IS another difference. Between now and the time I tried an upgrade of a system in Virtualbox with boomaga installed, there have been many updates to both mga7 and mga8. Since (according to qarepo) there isn't any boomaga package in updates testing, perhaps one of them inadvertently fixed the problem. I'll try an upgrade from the CI iso in vbox again tomorrow, to see what happens there now.
Ah. I assumed there was one in updates testing. My mistake.
Ran two tests on upgrading a 64-bit Mageia 7 Plasma vbox guest, fully updated and with boomaga installed. The first was run with the virtual printer installed in system-config-printer, and the second was done with that printer removed but the rpm still in place. The upgrades were done using the CI iso, with the math.princeton http online media activated at the beginning of the process. Both 64-bit and 32-bit media were activated, including tainted. Both upgrades informed me at the end of the installation that there had been script errors concerning samba-client and boomaga. I finished the install, checking for updates, and of course there were none. Both guests rebooted to a working desktop, and both had two boomagas installed, one for M7 and one for M8. Both upgrades showed 180 orphans with urpme --auto-orphans, but boomaga was not on either list. I removed the orphans on each, and each rebooted to a working desktop, with both boomagas still installed. That's as far as I took it. Clearly, there is a difference in the upgrade process used by the isos and the one used by urpmi.
Think I've figured out what's going on. During install, boomaga starts cups if it isn't already running, then adds the printer Boomga. The uninstall scriptlet fails if either cups is not running, or the Boomaga printer has been previously manually removed from cups. If cups is running, and the Boomaga printer is defined, then the package uninstall works fine. My recommendation for changes to the boomaga package ... In the preuninstall scriptlet, Set a variable to indicate if cups is running. If cups is not running, start it just like it does in the pre-install scriptlet. Only run lpadmin -x "Boomaga" if "lpstat -h localhost -v" output includes a line starting with 'device for Boomaga". If cups was not running before the preuninstall, stop cups. I think this will fix the problem, assuming cups can be started in the middle of an upgrade. The change will also fix uninstalling boomaga without cups running, during normal Mageia usage.
Thinking about it more, my suggestion only works if using urpmi to upgrade. It won't work if using the iso to upgrade since cups will not be able to start. So the question becomes "how to remove the printer with cups not running?" Any ideas?
I think we should apply the changes in comment 36, so boomaga can be uninstalled without cups currently running. That's needed for removing boomaga during normal Mageia usage, as well as during upgrades using mgaapplet or urpmi/dnf. For upgrading using an iso or other methods such as a chroot, boomaga must be uninstalled before starting the upgrade, since cups can not be started when using those upgrade methods. It may be reinstalled after the upgrade, if desired. Opinions?
Another idea. :-) Change the preinstall, postinstall and preuninstall scriptlets to all return a status code of zero whether the work or not by adding a line with just true to the end of each of the three scriptlets. This is the simplest, and safest change I can think of though it may mask problems later.
Keywords: (none) => IN_ERRATA8Whiteboard: MGA8-64-OK => MGA8-64-OK
TL;DR; for the previous comments, but please try boomaga-3.0.0-3.2.mga8 from core/updates testing. IT contains the following changes/additions: https://svnweb.mageia.org/packages?view=revision&revision=1713095 https://svnweb.mageia.org/packages?view=revision&revision=1713138
CC: (none) => jani.valimaa
Advisory committed to svn. Testing using an iso for upgrade shortly.
Whiteboard: MGA8-64-OK => (none)
Argh. Just realized that when using an iso, there is no way to activate the testing repo as an updates repo. Validating the update based on it installing cleanly on an existing m8 install, with no scriplet errors reported. Will open a new bug report if after it's pushed to updates problems are found.
Whiteboard: (none) => MGA8-64-OKKeywords: (none) => advisory, validated_update
Assignee: dglent => qa-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2021-0066.html
Resolution: (none) => FIXEDStatus: ASSIGNED => RESOLVED
Noted in errata, with comment to configure Boomaga again if it disappeared.
With regard to a simple update in Mageia 8, with boomaga already installed: As we saw in Bug 26032, after the update is finished, the boomaga printer must be re-installed in system-config-printer before it can be used. Also as in Bug 26032, attempting to print a test page from system-config-printer generates an error which stops the printer until the job is cancelled. Workaround is to set the boomaga printer to "abort job" if an error occurs. A subject, I suppose, for a new bug.
Yes please open a bug for that.
Removing the mga7 boomaga package after upgrade and both are installed, it fail to uninstall. Anyway, Boomaga works with both installed. - working, but no elegant. $ LC_ALL=C sudo urpme boomaga-3.0.0-1.mga7 removing boomaga-3.0.0-1.mga7.x86_64 lpadmin: The printer or class does not exist. error: %preun(boomaga-3.0.0-1.mga7.x86_64) scriptlet failed, exit status 1 ERROR: 'script' failed for boomaga-3.0.0-1.mga7.x86_64 error: boomaga-3.0.0-1.mga7.x86_64: erase failed I have found this problem on the two systems I upgraded online. Adjusted Errata. If there is a simple clean way to really remove the mga7 package, we should note it in errata.
Try using the rpm command (from Comment 25, refined from Dave Hodgins suggestion in Comment 20.) to remove it: "rpm -e --noscripts boomaga-3.0.0-1.mga7" Dave's original command failed for me because there were two Boomagas present. It needed to be made more specific as to which one was to be removed.
Perfect, thanks! Updated Errata.