Delete /dev/shm/yumwrapper/* and Try Again BUG..ISSUE

I have asked about this exact same error prior on version 13 and it has also occurred to me on version 14. So here I am on version 15.0.16.73 and tonight had seven modules needing upgrade. Went to the Module Admin and whammy, Good old whoops screen again and this message as part of the error.

In searching the forums again, there is really not a whole lot of help on this issue. It is irritating and I have a standard system, nothing custom or weird. Vanilla.

Deleting the files in that directory allows me to move forward but no one should have to do this, do they? I mean, shouldn’t this stuff be taken care of by the system?

NOT SO FAST! Now I am ticked… I updated the current modules fine after deleting the files in yumwrapper. I went to check on system update and it errors again telling me to delete the files. I do, run the update again and it errors again. I delete the files, check for system updates again, it starts as it should and errors out telling me to delete the files in yumwrapper.

Every time I get this error. Did one of the updates cause this continued issue?

My system was perfect until tonight.

So, I will ask this question again; Why does this oocur? What can I do to prevent it? How do I fix it? How does Sangoma fix it? What do you want me to do?

Below is the yum-check-updates.log. A lot of misc junk seems to be in there unless it’s some sort of key.

Thanks!

John

TITLE 1598847141 yum-check-updates
[ timestamp: 2020-08-30 21:12:21 ]
START 1598847141 yum-clean-metadata
STOP 1598847142 yum-clean-metadata 0 TG9hZGVkIHBsdWdpbnM6IGZhc3Rlc3RtaXJyb3IsIHZlcnNpb25sb2NrCkNsZWFuaW5nIHJlcG9zOiBzbmctYmFzZSBzbmctZXBlbCBzbmctZXh0cmFzIHNuZy1wa2dzIHNuZy11cGRhdGVzCjE2IG1ldGFkYXRhIGZpbGVzIHJlbW92ZWQKMTAgc3FsaXRlIGZpbGVzIHJlbW92ZWQKMCBtZXRhZGF0YSBmaWxlcyByZW1vdmVkCg==
START 1598847142 yum-check-updates
[ timestamp: 2020-08-30 21:12:22 ]
[ timestamp: 2020-08-30 21:12:33 ]
STOP 1598847153 yum-check-updates 100 Ckdlb0lQLng4Nl82NCAgICAgICAgICAgICAgICAgICAgICAgICAgMS41LjAtMTQuZWw3ICAgICAgICAgICAgICAgICAgIHNuZy1iYXNlICAgCkltYWdlTWFnaWNrLng4Nl82NCAgICAgICAgICAgICAgICAgICAgNi45LjEwLjY4LTMuZWw3ICAgICAgICAgICAgICAgIHNuZy1iYXNlICAgClNETC54ODZfNjQgICAgICAgICAgICAgICAgICAgICAgICAgICAgMS4yLjE1LTE2LmVsNyAgICAgICAgICAgICAgICAgIHNuZy1iYXNlICAgCmFjbC54ODZfNjQgICAgICAgICAgICAgICAgICAgICAgICAgICAgMi4yLjUxLTE1LmVsNyAgICAgICAgICAgICAgICAgIHNuZy1iYXNlICAgCmFsc2EtbGliLng4Nl82NCAgICAgICAgICAgICAgICAgICAgICAgMS4xLjgtMS5lbDcgICAgICAgICAgICAgICAgICAgIHNuZy1iYXNlICAgCmFwci54ODZfNjQgICAgICAgICAgICAgICAgICAgICAgICAgICAgMS40LjgtNS5lbDcgICAgICAgICAgICAgICAgICAgIHNuZy1iYXNlICAgCmFzdGVyaXNrMTYtZzcyOS54ODZfNjQgICAgICAgICAgICAgICAgMjAwMi0xLnNuZzcgICAgICAgICAgICAgICAgICAgIHNuZy1wa2dzICAgCmF0ay54ODZfNjQgICAgICAgICAgICAgICAgICAgICAgICAgICAgMi4yOC4xLTIuZWw3ICAgICAgICAgICAgICAgICAgIHNuZy1iYXNlICAgCmF1ZGl0Lng4Nl82NCAgICAgICAgICAgICAgICAgICAgICAgICAgMi44LjUtNC5lbDcgICAgICAgICAgICAgICAgICAgIHNuZy1iYXNlICAgCmF1ZGl0LWxpYnMueDg2XzY0ICAgICAgICAgICAgICAgICAgICAgMi44LjUtNC5lbDcgICAgICAgICAgICAgICAgICAgIHNuZy1iYXNlICAgCmF2YWhpLng4Nl82NCAgICAgICAgICAgICAgICAgICAgICAgICAgMC42LjMxLTIwLmVsNyAgICAgICAgICAgICAgICAgIHNuZy1iYXNlICAgCmF2YWhpLWxpYnMueDg2XzY0ICAgICAgICAgICAgICAgICAgICAgMC42LjMxLTIwLmVsNyAgICAgICAgICAgICAgICAgIHNuZy1iYXNlICAgCmJhc2gueDg2XzY0ICAgICAgICAgICAgICAgICAgICAgICAgICAgNC4yLjQ2LTM0LmVsNyAgICAgICAgICAgICAgICAgIHNuZy1iYXNlICAgCmJpbmQtbGlicy54ODZfNjQgICAgICAgICAgICAgICAgICAgICAgMzI6OS4xMS40LTE2LlAyLmVsN184LjYgICAgICAgIHNuZy11cGRhdGVzCmJpbmQtbGlicy1saXRlLng4Nl82NCAgICAgICAgICAgICAgICAgMzI6OS4xMS40LTE2LlAyLmVsN184LjYgICAgICAgIHNuZy11cGRhdGVzCmJpbmQtbGljZW5zZS5ub2FyY2ggICAgICAgICAgICAgICAgICAgMzI6OS4xMS40LTE2LlAyLmVsN184LjYgICAgICAgIHNuZy11cGRhdGVzCmJpbmQtdXRpbHMueDg2XzY0ICAgICAgICAgICAgICAgICAgICAgMzI6OS4xMS40LTE2LlAyLmVsN184LjYgICAgICAgIHNuZy11cGRhdGVzCmJpbnV0aWxzLng4Nl82NCAgICAgICAgICAgICAgICAgICAgICAgMi4yNy00My5iYXNlLmVsN184LjEgICAgICAgICAgIHNuZy11cGRhdGVzCmJpb3NkZXZuYW1lLng4Nl82NCAgICAgICAgICAgICAgICAgICAgMC43LjMtMi5lbDcgICAgICAgICAgICAgICAgICAgIHNuZy1iYXNlICAgCmJsdWV6LWxpYnMueDg2XzY0ICAgICAgICAgICAgICAgICAgICAgNS40NC02LmVsNyAgICAgICAgICAgICAgICAgICAgIHNuZy1iYXNlICAgCmJvb3N0LWZpbGVzeXN0ZW0ueDg2XzY0ICAgICAgICAgICAgICAgMS…
THIS JUNK GOES ON FOR EVER
…
FINISH 1598847153

I’d never seen this problem until this week myself. Came back again this weekend on some systems. I’m assuming is some issue on the repository side esp. given that there were repository issues in the last week? The one where could not upgrade the OS to 7.8 and then this weekend the freepbx repositories were not reachable at all.

same issue even if i delete the files in /dev/shm/yumwrapper/*

Bump… Are we the only three folks that have suddenly had this issue?

Should I update my system from the CLI? Any thoughts, hints, tips or tricks?

Thanks!!

John

I wouldn’t assume that out of hand, but based on the number of panicked forum posts, it’s not impossible. If that’s the case, the root cause is probably something specific to the way the three of you got to this particular version update.

It might be worth making an image backup of your system and sending it to Sangoma to see if they can find the root cause of this unusual problem spot.

That’s a great idea and thanks Dave! I wonder what or why ours are different? This has reared its head in past versions I have had too.

Now to figure how to get it to Sangoma.

John

I have another system, identical, which has done the same thing. The only thing to have been done to either of them prior to this happening was going to Edge and updating the main panel to play with the new notes ability.

Just aggravating. Makes it impossible to do system updates via the webgui.

John

FreePBX Distro 14.0.13.34

I started seeing the same problem for the first time on 09/03. Logging in via ssh the welcome message says that there are 286 system updates available. It’s not a repo issue as “yum check-update” from the shell (ssh) works OK. A workaround is to do all system updates from the shell.

@bitbanger
That is true. The CLI always works. It is just bothersome when a bunch of my vanilla systems has this happen for no apparent reason when trying from the webgui and not much is known from the community or from anyone, via the community, from Sangoma. This was all starting with latter versions of 13, in 14 and now in 15. Sigh…

Thanks!
John

I’m having this very same issue.

My system is really basic and boring. Nothing fancy added. I periodically perform module updates and system updates via the GUI. Last time was about a month ago.

I followed the instructions to delete everything from yumwrapper. Then I was able to perform the module updates - in hopes it would fix the system update GUI.

Nope.

So it would seem that I should run yum from the shell instead of the GUI for system updates?

I wonder if it’s related to the number of system updates to be performed. In my case there were 290 updates to be applied. Perhaps that exceeded the ability of the system to properly display them in the GUI?

Yes. Do them from the CLI. After I did this and updated everything no more yumwrapper issues. An enigma and no one seems to know why or how to prevent it. That’s really odd.

John

Hi All

Noticed a similar issue in our lab recently and just published a new framework v15.0.16.75 with the fix, so request you to please try with this version.

If the issue still exists then please raise FREEPBX Jira for us to dig further.

Thanks
Kapil

1 Like

I have the same issue, it crashes every time I try to do a System Update: click on “Check Updates”, then it looks for about 7 seconds then the error from the OP displays on loop. Only way out is typing the URL again on the location bar. Once you get this error, you can’t access module admin again, as when you try, you get another error, and you can’t get to the module admin again unless you reboot the system.

I’m trying to update the Framework to the 15.0.16.75 version, but using module admin it only goes up to 15.0.16.73, and there’s no other track than “Stable”, so I don’t know how to update to the newer version.

fwconsole ma downloadinstall framework --tag 15.0.16.75
1 Like

I am having the exact same issues. I will try the CLI update.

It appeared suddenly for us.

I have updated the framework to 15.0.16.75 and now the system update works without errors, so this fixed the problem for me.

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.