It finally finished..
5624900b-cb96-41ee-b8f1-29373e262692-image.png

While I was waiting, I looked at pvecm status and found out it thought I had 4 nodes (see expected votes), when I only have 2 nodes.

76a4d9f9-18ba-4fe5-af47-4ea037892bfc-image.png

I used pvecm expected 2 on both and suddenly the updates moved on and I was able to log in to the web interface immediately.
d5ecd18f-8e07-4222-afea-0b04d215775c-image.png

In the web interface, it showed a pve3 and pve4. These were some test setups I did months ago.
I deleted the nodes from the CLI and everything looks clean again.
782c49e5-1457-499d-8c58-5afbc3c2efda-image.png

@jaredbusch said in Upgrading to Fedora 34:

@stacksofplates said in Upgrading to Fedora 34:

I don't care for the new Windows-esque "installing updates don't power off your computer" screen on a reboot that was introduced in 34.

It was in 33 also if you did a clean install.

Ah I haven't used it in a while. I just saw it mentioned the other day.

Upgrading servers today.

Turns out I had a snapshot, restoring it and then regrouping...

So, no idea what I had installed that required python2-lxml

I removed it and the upgrade is proceeding as normal.

2nd attempt worked!

@scottalanmiller there is nothign wrong with the 5.2 kernel.
So put this last line, without the semicolon, in your /etc/dnf/dnf.conf

[main] gpgcheck=1 installonly_limit=3 clean_requirements_on_remove=True ; exclude=kernel*

Then remove the kernel so you can't boot to it (assuming 5.3.7):

sudo dnf remove kernel*5.3.7-200.fc30.x86_64

reboot to be sure it all comes up normal.

sudo reboot

Then do the normal upgrade to 31.

sudo su - dnf upgrade --refresh -y && dnf install dnf-plugin-system-upgrade -y && dnf system-upgrade download --releasever=31 -y && dnf system-upgrade reboot

Then you can comment that exclude out and do a normal update.

sudo dnf upgrade -y --refresh

And if it fails to log in still, so what. just select the 5.2 kernel again like you do now.

@JaredBusch said in Automatically running chocolatey upgrades:

How do various people do this?

Re: Next steps with SaltStack

@marcinozga said in Next steps with SaltStack:

Not salt, but I used https://chocolatey.org/packages/choco-upgrade-all-at which creates the same task, that runs choco upgrade all -y. If salt is using windows task scheduler, then it should just work.

Does that run as the admin account? Users have no rights to run this.

Running the choco install command requires local admin rights - so I assumed either - it ran as system OR it would ask for the creds of the current admin user being used to run the installer.

Clearly you found that it runs as system.

Nevermind, I was being dumb. They have Enterprise licensing here.

So @JaredBusch doesn't have to. FFS Travis, stop with the stupid.

@bnrstnr said in Upgrading Nextcloud via CLI:

@JaredBusch said in Upgrading Nextcloud via CLI:

If you change the entire folder to HTTPD_RW it will work without disabling things.

Ah yeah, probably this. SELinux is a complete mystery to me :man_shrugging:

ls -lashZ /var/www/html Will show you the context on your Nextcloud folder. Technically, just the Z is for the context

The added features from 0.25.2
f7dd1310-4079-4671-ac43-6e22918cccc5-image.png

@black3dynamite said in Nextcloud 14 upgrade follow up warnings:

Is this necessary when doing a new install too?

Based on the message, I would assume no. But I have not installed a new 14 instance.

Just upgraded a SuiteCRM instance in Vultr.

The reboot step was fast as fuck. ❤ Vultr.

@zachary715
You can turn on debug by changing false to true in .env file, so you can see more information instead of Whoops, looks like something went wrong.

# REQUIRED: BASIC APP SETTINGS # -------------------------------------------- APP_ENV=production APP_DEBUG=true APP_KEY= APP_URL= APP_TIMEZONE=America/Denver APP_LOCALE=en

Now as a general recommendation (really never do this), don't install Windows Server onto the bare metal, install your hypervisor to the bare metal. In this case Hyper-V.

Apply your licensing to the 2 VM's that you are allowed to create with Standard (and up licensing) then you'll be allowed to move your VM's around every 90 days or sooner for hardware failures etc.