You would use the Upload Custom ISO option, but I haven’t tested it.
I tried it on BinaryLane but the system is broken and they can’t be bothered fixing it, or even answering support emails.
RHEL is a bit of a pain with their Registration system though, so Rocky/Alma would be a bit less hassle. On the other hand, it’s the original which the others copy.
Yeah, I don’t like the ISO install method, to much setup to do just get to the VM install, here now I just login and all updates and network is ready to go. And isn’t RHEL just free for developer and individuals?
Solved, its was a Vultr repo, Once I disable it and refresh packages there is no more “possible” updates. Now I got to work out if it is needed or not.
I was able to reproduce this (also on vultr), but I don’t think we can fix it. It is something weird about the vultr repo, maybe?
Here’s what I see when I do a check-update:
# dnf check-update
Last metadata expiration check: 0:05:22 ago on Fri 03 Feb 2023 11:36:14 PM UTC.
Obsoleting Packages
cloud-init.x86_64 97225:22.4_62_gcb128dc_cb128-97225 apprepo
cloud-init.x86_64 99191:22.4_83_g7d57fcf_7d57-99191 @@commandline
cloud-init.x86_64 99191:22.4_83_g7d57fcf_7d57-99191 @@commandline
cloud-init.x86_64 99191:22.4_83_g7d57fcf_7d57-99191 @@commandline
cloud-init.x86_64 99191:22.4_83_g7d57fcf_7d57-99191 apprepo
cloud-init.x86_64 99191:22.4_83_g7d57fcf_7d57-99191 @@commandline
But, then a dnf update:
# dnf update
Last metadata expiration check: 0:06:00 ago on Fri 03 Feb 2023 11:36:14 PM UTC.
Dependencies resolved.
Nothing to do.
Complete!
It may be that we’re interpreting that Obsoleting packages thing wrong. I don’t know what it means. But, I can’t update/upgrade cloud-init, so it seems like something it should not be considered a viable update.
I understand what you’re saying about the ISO install method (it’s much more effort), but the advantage is that you can be sure that the VPS provider (here: Vultr) won’t surreptitiously add a non-standard repo (or something else, for that matter!)
Its a vultr mirror of https://apprepo.de/, its saves downloads for vultr if they have mirrors for repo’s. Common practice. Its not a repo I need so its a non issue.
Yeah, but you don’t know what the hell else they might add. It may be well-intentioned and useful, but I’d rather just start with a stock OS and know exactly what I’m installing.
But it is a good warning to others that it is not a good idea. you get what you might well expect if you deviate from the norm. In this case using Vultr ?
Using an ISO seems like a lot of work to address an extremely simple and harmless issue.
The Vultr cloud-init repo seems to be weird, and makes dnf behave in an incomprehensible way, but it’s nothing to do something crazy about. Jamie has fixed a bug (a bug that could only be hit by this particular combination of weirdness) in the update detection code, but unsurprisingly, we still have a problem with this particular package from this particular repo. It shows up as an available update, in dnf check-update and in Software Packages in Webmin (since dnf check-update is how Webmin figures out what’s available to update), but it cannot be installed, updated or upgraded. It is simply a broken repo that we can’t do anything about. We’re not going to special case our update detection to hide available updates, since there is no way I can see to detect it.
We show what the system package manager tells us. If the system package manager lies because of a broken repo or package, we just have to accept that that kind of thing happens.
In short: Next version of Webmin will still report this available package, and it will still be unable to be updated. But that’s exactly the behavior dnf shows, so it’s not our bug. It’s either a problem with the repo/package or with dnf. If it really bothers you, disabling that problem repo is the only solution I have to offer. Presumably Vultr will fix their package/repo at some point. But, it does fix the mixmatch between the red 1 and showing no packages in the Software Packages module. It’ll show the package in the Software Packages page…but, then if you try to update it simply won’t. Again, we can’t control it. It’s broken upstream of us.
Just for the record there was a similar kind of issue with Digital Ocean and their default repos. I get a something like the following on AlmaLinux 9.1.
That’s not the same issue. I understand it looks similar, but if it showed up as an available update in Software Packages page, and if running dnf update updated the package when run on the command line, it’s not the same problem (the issue with cloud-init package on Vultr is that is literally cannot be updated in any way and it was invisible on the Software Updates page).
Weird that suddenly multiple VM hosting providers all have weird yum repos, though.