OME 3.4.1 upgrade failed

Sorry for the typo. Sadly one cannot edit posts here. It's actually OME 4.3.1 failed

_Armin_,

It sounds like there must be an issue with the current appliance that needs to be addressed before it can upgrade. Now with the console logs we might see what the deal is and be able to get in and fix it, so without them we are limited. You could call in and work with the OpenManage group directly, to let them see if they can resolve it, or another option would be to remove 4.2 and then just clean install 4.3.1.

Let me know if this helps.

Hello,

As Chris mentioned, the issue would be due to the state of appliance prior to upgrade. From Engineering, we haven't seen the issue yet and hence would recommend checking the following.

• Is there any jobs in running state when upgrade was triggered ? Check for both User & System generated ones.
• How about the storage availability for the VM deployed ? As Update Manager plugin is installed, having more repository bundles can consume higher storage space.  

Well...

I didn't check for any running jobs. I'll do next time. Thanks.

Update Manager is using 1.2 GB for images currently. The deployment was done from the recommendations. On the main dashboard it says, that 4.06% storage is used.

I don't have that much things in OME which cannot be generated. Just a few reports and some configuration compliance templates. So maybe also a re-install is possible. I hope this won't be the "normal" upgrade way in the future.

I'll try an ugprade again and check back with the results...

Looks like it went through successfully this time. Not sure what was different this time.

There were no jobs running. I kicked out some stale user sessions. But that's it.

The upgrade seems to run different for 4.3. It looks like there are 2 phases. After the reboot there were again packages installed. And it took longer than the previous 4.2 upgrades.

There is still one thing bothering me. The post upgrade job seems to start ALL present discoveries. And it looks like a lot of them are stale. Associated servers were removed weeks or months ago, but it looks like their discoveries are still there and executed. And they fail.

Is there a better practice to remove servers from OME than just deleting them from the server view?

Glad to hear you got it updated.

As seen on page 105-106 here, the only steps to remove the server is to

1. Go to the All Devices screen by clicking Devices.
2. From the devices list, select the check boxes corresponding to the devices that you want to delete.
3. Click the More Actions drop-down menu and click Delete Devices.
4. At the prompt indicating that the devices will be deleted and offboarded from OpenManage Enterprise, click YES.

Well, obviously that's not enough, or there is a bug, or "feature". At least in my environment, but I can imagine that others see this also.

It seems to get "visible" though only after an upgrade when the post-upgrade task is running.

Calculating from the percentage complete, the post-upgrade task will run the whole day. I have over 400 discovery objects under Monitor->Discovery compared to 130 servers in the server view.

Let me get a svc tag from you so I can take this up with the OpenManage group to consider what may be the cause. I will send you a private message you can reply to with it.

@_Armin_​ : Glad to hear that the upgrade is successful. As part of offboarding devices from OME, user needs to delete server(s) from "All Devices" page, and update the corresponding discovery task created (in Monitor > Discovery) to ensure that the non-existent server IP's are not attempted for rediscovery.

@jimmy_muraleedharan How do you guys imagine that people should do this? One discovery can contain 1 machine, or 100. Decommissioning will not happen the same way as onboarding. The list of discoveries in the discovery tab contains of hundreds of "Server Discovery" entries. No name, no ip address, no other detail. So you can just click one after the other. If you find the right one, you cannot delete it from this view. You need to go back... and start again from the beginning. So maintenance of discovery entries is basically not possible at all.

The only way which works for me, is, to wait for an upgrade, check all failing discoveries manually and delete them.

This is not what I call enterprise ready. I like almost everything else, but you can improve heavily here :-)

@_Armin_ I had the same exact issue about 2 weeks back and gave up. I had to do a revert from snapshot which I thankfully made. Post update the vm appliance was just stuck in the endless reboot loop and couldn't find the database and whatnot. 

Hoping this new version alieviates that. Was going from 4.2 I think to 4.?  Wish I would have recorded the versions when it was broke at the time but that was so last week's problem.

In my case the update to 4.3.1 seems to have corrected the issue. I did verify that the appliance had the correct hardware requirements, saw that in a different thread. I wanna say I was attempting to update to the version prior to 4.3.1 so that installer may have had a bug in it. Issue fixed now though.

Hello

today I update from version 4.2 to version 4.4.1.2 without any problems.
Before I start the update, I disabled the Power Manager and Update Manager. After Upgrade to 4.4.1.2 I updated the Power Manager and Update Manager. All without problems as I can see so far.

Good luck.

Ralf