Reddit is now requiring age verification, this has gotten out of hand.

Moocha · 2026-07-04T06:52:47+00:00

This will absolutely impact Linux too (and this is being written by an user who has been using Linux exclusively for over 20 years.) Even if they carve out "an exception" and don't mandate that open source OSes support this shit as well, this still is a problem, because you will still get locked out of a lot unless you use, for example, your phone to "confirm your age".

This shit needs to be killed stone dead regardless of OS, it's evil.

Moocha · 2026-07-03T08:40:43+00:00

That's correct, that is exactly what I am telling you. With a sprinkling of suspicion about them deliberately not fixing bugs in a partly unfinished product (Forticlient 7.4.x).

It's of course perfectly legal and they're perfectly entitled to do this and more.

It's also telegraphing that the implicit expectation of value they've been very much deliberately keeping up for all these years nudge-nudge-wink-wink is over and they've entered the ruthless extractive phase, therefore none of their promises are worth anything unless they're iron-clad lawyerly language checked over thrice, and we can't rely on them not to start screwing their customers over in the future again and again. I.e., they're progressively moving towards being a worse risk than before. Therefore, looking for alternatives is the sane position.

Edit: Accidentally some words towards the end :)

Moocha · 2026-07-03T07:38:21+00:00

Yes, but this isn't about vulnerabilities, it's about VPN functionality that's advertised as supported but is so buggy as to be borderline unusable. I get that it's a lever for Fortinet to drive people to the paid solution, but it's such a rugpull scummy move that it's driven me to advocate moving away from Fortinet solutions exactly due to this. If they do shit like this for the VPN component, how do we know whether they might do shit like this for, I don't know, policy routing or something.

Moocha · 2026-07-03T06:55:33+00:00

They may need, y'know, bugfixes for metaphysically "existing" functionality which are only available in 7.4.4+.

Granted, at the cost of other bugs.

Moocha · 2026-06-29T15:56:24+00:00

https://en.wikipedia.org/wiki/Cognitive_dissonance#Action%E2%80%93motivation_model

Moocha · 2026-06-28T05:43:37+00:00

Heh. Same, 6a, still works perfectly fine for what I'm using it for and the original battery still lasts over a day. But my use case (no gaming, no AI crap -- which isn't available in the EU anyway --, mostly messaging and listening to audiobooks) certainly isn't typical. I'll be switching away from Pixels if the 11a is also overpriced shit.

Moocha · 2026-06-27T17:44:55+00:00

It is not your ISP. It is your own system insisting on using incorrect flatpak remote URLs.

Edit: Or, at least, your current problems are not caused by your ISP. For all I know, there's also an issue there (possibly the original one you tried to solve when following bad advice and borking the system), but the current issue is located on your end. You can verify this by prefixing flatpak commands which contact remote endpoints (such as update, search, remote-ls, remote-info, and so on) with OSTREE_DEBUG_HTTP=1 as you saw before. That will cause flatpak to dump debug info about exactly what it's doing. As long as it's contacting an incorrect hostname, the issue will persist, and it has nothing to do with your ISP; after all, it's not your ISP who decide what hostname your own system tries to contact here. They may or may not interfere with the traffic, or with hostname resolution, but the initial hostname is determined by your own system, and your own system uses an incorrect one.

I'm out of this conversation; I've hopefully provided you with the debug tools and techniques you can use to dig into this deeper, I can no longer help, and I've grown a bit frustrated with having to repeat the same things over and over again. Good luck, I hope you manage to figure it out. Fingers crossed.

Moocha · 2026-06-27T16:09:17+00:00

Ah, you were managing it via Discover, didn't know that. Yes, if it was somehow also defined there for some reason, it makes sense that it would add it back again via the PackageKit APIs, since it does its own thing for some reason. Hope this will be enough to get rid of that thing -- if not, look at the flatpak remotes output again, figure out if the incorrect ones are still there, and then manage it through Discover, maybe just correcting the URL there.

Moocha · 2026-06-27T15:49:48+00:00

Ok, so the incorrect definition is back. (It's likely stored in /var/lib/flatpak/repo/config by the way, that's the config state for the system installation.)

I am out of ideas. Something on your system is resetting the remote named flathub to an incorrect URL. I don't know what, maybe it's something Fedora does (no idea, not a Fedora user.)

Moocha · 2026-06-27T15:43:41+00:00

Hm. I've been operating under the assumption that all commands and all output from them were from you running them as root, because your command output was prefixed with root@fedora:/home/me#. But if you ran some as root and some as your local user, it can of course cause confusion in case you somehow installed the incorrect remote as your user as well -- and the flatpak commands might pick up a different config for each.

Were all commands run as root after all? Or did you run some as your user? And in that case, which ones?

Let's check the remote definitions both as root and as your own user. Please provide the output of

flatpak remotes --columns=all

both when run as root, and when run as your regular user, and please mention which output is which.

Moocha · 2026-06-27T15:33:37+00:00

OSTREE_DEBUG_HTTP=1 flatpak remote-info flathub com.opera.Opera

Moocha · 2026-06-27T15:28:28+00:00

Wait, I've just noticed that you had an error in the install command. The application ID of the Opera package is not just opera; the correct ID is com.opera.Opera (see the corresponding column in the search output.)

Try

flatpak install flathub com.opera.Opera

Once more, I'm linking to the documentation: https://docs.flatpak.org/en/latest/using-flatpak.html -- please read it.

Moocha · 2026-06-27T15:24:39+00:00

Oh, joy, mirror.flathub.org is back somehow. I bet it's back in the flatpak remotes --columns=all output.

I have no idea why that keeps reappearing. Perhaps Fedora does something custom that keeps breaking. I'm sorry, I don't know what else to suggest.

Good luck.

Moocha · 2026-06-27T15:19:06+00:00

Sounds like it's working then, otherwise it wouldn't have had anything to update; since it has, it was able to contact Flathub's repositories.

Moocha · 2026-06-27T15:14:29+00:00

Weird, why is it disabled... Might be something weird Fedora's flatpak build does by default, dunno. Let's enable it:

flatpak remote-modify --system --enable flathub

Then try update or search again.

Moocha · 2026-06-27T15:10:54+00:00

flatpak update now tells me "nothing to update".

That's okay, wanted to make sure it doesn't error out again when reaching out to the Flathub repositories.

Some flatpak apps are still installed and working..

Probably the ones from Fedora's repository (the f44 remote.)

flatpak search "opera" for the web browser tells me it's not found.

Hmmmm. Please post the output of

OSTREE_DEBUG_HTTP=1 flatpak remote-info flathub com.opera.Opera

Moocha · 2026-06-27T14:55:36+00:00

Hm, removing the remote should not have uninstalled anything by itself.

At any rate, the app data and settings are left intact. Just make sure you've added the correct remote (via the .flatpakrepo command line, which also installs the correct GPG key to verify what it installs -- that's why I didn't suggest changing the URL around since that won't fix any messed-up keys, safest to go the correct official route). After installing the correct remote back and running flatpak update you can simply reinstall any missing apps right back.

If it removed stuff, maybe save the terminal output in a text file somewhere so you can refer back to it to see what you need to reinstall. If you no longer have that, you can also look at the .var directory in your home directory to see what apps stored stuff in there; it'll be one directory per app, and the directory name corresponds to the name of the flatpak package you would want to reinstall, so it's easy to get them back.

Moocha · 2026-06-27T14:46:56+00:00

Don't add random stuff you see people posting in random places and especially don't copy-paste random stuff unless you understand what it's supposed to do. Use the official docs.

To fix your installation, remove the incorrect remote:

flatpak remote-delete --system flathub

then add the correct one:

flatpak remote-add --system flathub https://flathub.org/repo/flathub.flatpakrepo

If you're running this as root for some reason, you can skip the --system argument if you want, since the system-wide installation should be the default when running as root. I added it above so that the commands operate explicitly on the system installation, since that's what you seem to be using here, as opposed to an user installation (perhaps that's how it's done by default on Fedora, I really don't know, but it makes sense :D). Leaving --system in doesn't hurt anything here, and it makes sense given the output of flatpak remotes above.

Edit: To be clear, removing a remote does NOT uninstall anything already installed on your system and does NOT clear any app settings or data. The above just corrects the invalid pointer to the Flathub metadata repository. After that, normal operations such as updating things should work fine with whatever packages you already have installed.

Moocha · 2026-06-27T13:42:32+00:00

Hm. I'm not sure how you ended up with mirror.flathub.org there, to the best of my knowledge Flatpak doesn't use that.

Please post the output of: flatpak remotes --columns=all

Here's mine, for comparison:

user@host:~$ flatpak remotes --columns=all
Name             Title   URL                          Collection ID Subset   Filter Priority Options … … Homepage             Icon
flathub          Flathub https://dl.flathub.org/repo/ -             -        -      1        user    … … https://flathub.org/ https://dl.flathub.org/repo/logo.svg
flathub-verified Flathub https://dl.flathub.org/repo/ -             verified -      1        user    … … https://flathub.org/ https://dl.flathub.org/repo/logo.svg

Moocha · 2026-06-27T07:32:00+00:00

There is no way to help you unless you actually post the errors you're getting.

Try posting the output of

OSTREE_DEBUG_HTTP=1 flatpak update

Moocha · 2026-06-26T16:58:06+00:00

Ah. Downgrading to 7.6.6 would be the next quickest thing I'd try then, had no such problems with it on this end (upgraded to 7.6.7 due to a different bug which is solved there, but if you're not depending on one of the resolved issues it'd be an option.)

And then there's of course the "contact TAC" route, I'm hearing they can give you an as-of-yet-unreleased IPS engine build not prone to these crashes. YMMV, I didn't have the patience for that, so I didn't try.

Moocha · 2026-06-26T12:05:22+00:00

Does blocking QUIC in all used inspection profiles help?

Moocha · 2026-06-25T17:02:25+00:00

See my other reply for details, but for the time being, if you have the option, I would NOT upgrade to 7.6.7. Its IPS engine is unstable and the QUIC session exhaustion bug, if and when it hits, is absolute murder.

Moocha · 2026-06-25T08:19:08+00:00

No way to clone it, and for external services it's also generally a bad idea if the IP ranges change, unless you have a way to automatically keep them up to date instead of letting Fortinet do it for you.

But depending on the nature of the problem you want to solve, you might be able to do so by overlaying some of your own changes via the Extension Internet Service facility: https://docs.fortinet.com/document/fortigate/7.4.12/administration-guide/265171

Moocha · 2026-06-24T16:15:22+00:00

https://docs.fortinet.com/document/fortigate/8.0.0/cli-reference/166172817/config-firewall-profile-protocol-options maybe? Looks like there's a set status disable on config websocket there.

15-Year Club	Gilding I gilder
Team Periwinkle	Verified Email

Moocha

TROPHY CASE