Skip to main content

Webmin update 1.941 to 1.960 corrupted...

Posted by Anonymous (not verified) on Sat, 10/24/2020

Newbie here... hello everyone!!

I've been playing with a new installation from the currently available (el6.1) multi-tenant iso...

Today the Webmin tab informed me that ~20 packages needed to be updated... so I did that. Seemed to go OK.

Immediately afterwards, a separate area of the Webmin tab gui announced that there was an upgrade available for Webmin (v1.941 to v1.960). I did that - and lost control... now in my browser I'm getting the message

Failed to determine Webmin root from SERVER_ROOT, SCRIPT_FILENAME or the full command line

Looking for a quick/hack fix... I noticed in my OS environment there was no value set for "SERVER_ROOT", so I set that to the /etc/webmin/miniserv.config indicated path /usr/libexec/webmin... restarted webmin... but this rig did nothing to address the browser error message... so I'm still locked out of the gui...

I can reinstall the iso from scratch (and start using the snapshot capability of my XCPng (XenServer) VM host)... but maybe there's still the option for a quicker fix via the cli?


Submitted by volodya on Sun, 10/25/2020 Permalink

Hello!

You should be using only Webmin installed with the ISO or from the Thirdlane repository. Run "yum downgrade webmin" command to resolve the problem.

Submitted by goodbot on Sun, 10/25/2020 Permalink

Hmmm... got kicked off your forum system between yesterday and today... just re-registered using my exact same credentials as yesterday. My yesterday post is showing above as originating from an unknown/anonymous user... maybe I didn't respond fast enough here? If so... sorry for the delay!

My problem is persisting - the recommended downgrade command failed seemingly due to the rpgdb being changed outside of yum (illustrated below)...

I didn't upgrade webmin consciously using street repos (as opposed to your provided/supported house repos). Recalling my steps... I was in the webmin tab and received the alert (in the lower right portion of the gui) that several packages were out of date and I should execute an upgrade. I was at a quiet time in my work here... so I went along with this recommendation. The process took a few minutes. I didn't notice anything that looked like an error message - so I concluded that upgrade (of approximately ~20 packages) was a success. Immediately after this, I noticed a yellow warning label in the center left portion of the screen (still in the webmin tab) informing me that this webmin version I was on had an available upgrade- so I executed this offered upgrade (causing my trouble here).

In hindsight, maybe I should have paid more attention to the different screen area this notification was coming to me from - not the same lower right area I had just successfully upgraded many packages from... but instead an isolated/unique-to-webmin upgrade area.

If webmin v1.941 is the latest version Thirdlane is using/supporting... but this gui upgrade installed v1.960... then seemingly this upgrade process worked separately outside of the Thirdlane yum/rpg captive environment... like I said - I didn't intentionally do this... I didn't intentionally over-ride the confines of the defined repos to upgrade via street available later versions...

I don't have too much customization invested in this instance yet... so if it's helpful, I can redo this install from the start and pay closer attention to what's going on... maybe/helpfully grab a set of screen prints to more precisely document whats happening where & when...

FYI - Here's what happened when I attempted the webmin downgrade:

[root@pbx2 webmin]# yum downgrade webmin
Loaded plugins: fastestmirror
Setting up Downgrade Process
Loading mirror speeds from cached hostfile
* base: mirror.dst.ca
* extras: mirror.dst.ca
* thirdlane: mirror-us.thirdlane.com
* updates: centos.mirror.netelligent.ca
base | 3.7 kB 00:00
extras | 3.4 kB 00:00
thirdlane | 2.9 kB 00:00
updates | 3.4 kB 00:00
Resolving Dependencies
--> Running transaction check
---> Package webmin.noarch 0:1.941-1 will be a downgrade
---> Package webmin.noarch 0:1.960-1 will be erased
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package Arch Version Repository Size
================================================================================
Downgrading:
webmin noarch 1.941-1 thirdlane 22 M

Transaction Summary
================================================================================
Downgrade 1 Package(s)

Total download size: 22 M
Is this ok [y/N]: y
Downloading Packages:
webmin-1.941-1.noarch.rpm | 22 MB 00:00
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction

Rpmdb checksum is invalid: pkg checksums: webmin-0:1.941-1.noarch
[root@pbx2 webmin]#

Here's another example of my continuing challenge:

[root@pbx2 yum.repos.d]# yum history packages-list webmin epel-release
Loaded plugins: fastestmirror
ID | Action(s) | Package
-------------------------------------------------------------------------------
2 | Install | webmin-1.941-1.noarch E<
1 | Install | epel-release-6-8.noarch >
Warning: RPMDB altered outside of yum.
history packages-list
[root@pbx2 yum.repos.d]#

It appears that my webmin upgrade attempt caused this problem (of my stable v1.941 being upgraded to an unstable v1.960).

This all happened via the gui. While I AM playing root at the cli... I didn't do any yum/rpg stuff on the webmin package at all...

Submitted by goodbot on Mon, 10/26/2020 Permalink

The "yum clean all" idea didn't fix the corrupted rpgdb file checksum test... so I created a new vm instance from the Thirdlane installation iso...

When I sign into the gui using the root account, I'm presented 2 tabs... the left tab for Webmin and the right tab for Thirdlane (this is the admin gui). In the Webmin page, it shows two update areas... one for all system packages (see screen grab below... currently showing 20 available package updates) and a separate area of the screen for Webmin updates. You'll see here that this area is pointing toward the latest street available version of Wbmin (v1.960), not the preferred/required Thirdlane version (v1.941).

So now I've learned not to pay attention to this gui warning to update the Webmin package (I re-installed a new vm instance)... but now I'm equally worried about the other 20 packages being reported to me requiring updates.

Is it safe to follow Webmin's advice here and proceed to update these 20 indicated packages? Or should I instead NOT do any upgrades here and just proceed to work with the (stable?) installation the iso buys me?

Submitted by volodya on Tue, 10/27/2020 Permalink

Hello,

You should just run "yum update" command to update everything safely.

Submitted by chrisc@accents… on Tue, 10/27/2020 Permalink

goodbot, ignore all update notifications and only update via the yum update command as volodya has stated. Thirdlane controls all the update packages in their repos and if you step out of that update stream you will get errors and conflicts within the system.

In reply to by volodya

Submitted by aponnath on Tue, 10/27/2020 Permalink

I ran into the same issue as I used the command line to update the dependency's. Since you cant do yum update , otherwise it will update all of thirdlane stuff and if your update is not included you have no longer access. Would be actually nice to have a license checker build in which will check if you entitled or not and gives you choice to upgrade. In any case after i upgraded webmin i get sam error but for me a yum clean and downgrade restored the old version and is working fine