Feuerfest

This article could also be labelled: How to wreck your business model.

For over a decade OnePlus released solid Android phone who didn't need to shy away from other competitors flagship models. I owned a OnePlus 3 and currently use a OnePlus 8, what convinced me in the first place was the commitment to provide security updates for up to 5 years. This really stood out back at the time - only matched or beaten by Google's Pixel phones. As I run LineageOS nowadays I am not dependent on vendor updates. However I still held OnePlus' phones in high regards. This drastically changed today.

The reason? OnePlus started rolling out updates for its ColorOS which contain an hardware-level Anti-Rollback (ARB) mechanism. This is a so-called eFuse inside the processor itself and cannot be changed via software.

The result? If your OnePlus 13/13T/15 is on ColorOS 16.0.3.501 you can't install any custom ROM or downgrade the OS. If you try you brick your phone. No recovery possible. The only chance users have to install custom ROM is, if their firmware is build with the same or higher ARB/security level. Which are not yet available. And even then it will always be a ride on razors edge if you brick your phone when updating the ROM - or not.

This change wasn't announced publicly. It wasn't communicated in any way. And when asked OnePlus provided no answer - but they removed old firmware files from their servers for the affected models. Which the community takes as proof that this change is intentional and not just an extremely unfortunate bug or oversight.

It's unclear if other models are affected too or if they will get the same "treatment". Effectively robbing people of their freedom of choice regarding which OS they want on their phones.

And while ColorOS is used for OnePlus devices in China (devices outside of China run OxygenOS) this whole affair has a bad taste to it.

For me it effectively means that I won't buy a OnePlus phone as my next mobile.

Looks like OnePlus started its enshittyfication process.

Source:

• https://xdaforums.com/t/critical-warning-coloros-16-0-3-501-updates-permanent-anti-rollback-arb-fuse-blown-do-not-downgrade.4775930/
• https://docs.qualcomm.com/doc/80-Y8730-8/topic/anti_rollback.html#anti-rollback-version-upgrade

Speculating about the reason

China flashers

I was interested in why this was suddenly happening and someone on Reddit mentioned the big flasher market in China. Basically it goes like this:

• OnePlus sells phones in China with ColorOS, for EU/US/global ship the phones with OxygenOS
• People buy OnePlus phones in China for a considerably lower price than in EU/US
• The device is flashed with OxygenOS or other ROMs
• Now the device is sold outside China, making a big profit

This of course affects OnePlus directly. Their business model, their revenue, everything. So from a business point of view it is comprehensible that they did this. Also the lacking communication upfront and after the ARB discovery is sufficiently explained following this logic.

Still a shitty move. It would certainly help if OnePlus would finally comment on how they plan going forward with this, if other regions will be affected too in the future, etc.

And it also explains why people from all over the world report problems with the ColorOS 16.0.3.501 update. As they likely imported/bought a OnePlus from China and are now getting the ARB-affected OTA updates. As ARB has no method of knowing in which region a phone is operated in.

Then again there is this post on XDA Developers forum where some user claims "CPH2581_16.0.3.500 just dropped on OP12 EU." Where CPH2581 is the model code for the OnePlus 12 Global/EU version. And immediately after that post someone comments: "It's fused" showing a screenshot from a tool which checks the presence of the eFuse in the firmware.

Other users also confirm that their Global/EU/US region models received an eFused update.

So yeah.. OnePlus should really finally comment on this.

Also, the user who reported all this in the XDA Developers forum got his Reddit account banned shortly after, for yet unknown reasons.

Quick Update: My Reddit hub (u/AdaUnlocked) was suspended shortly after I shared this research. I'm not sure if it’s a technical glitch or due to coordinated reporting, but I've filed an appeal. For now, I will keep all technical updates centralized here on XDA.

OnePlus in trouble?

And then there is this article about OnePlus being in trouble because of declining sales and that it is possible that they will exit the US and EU market.

So.. This is a move to secure their market share in China? After all. Samsung has a similar feature with Samsung Knox. Just that... You know.. It doesn't brick your phone. It just disables some of the features Knox offers.

Channels to follow

Welcome to a new series in this blog: CTF. No, not capture the flag. Channels to follow. I'll use this series to present various accounts, channels, websites, etc. which are worthy to visit from time to time, or even leave a follow/subscribe. As over the years I accumulated a small list of channels with interesting which are not that much known to the wider Internet. At least based on the feedback I get when I mention them in conversations.

And today I'd like to present to you: Great Art Explained (on YouTube)

The channels description (https://www.youtube.com/@GreatArtExplained) reads as following:

I'm James Payne, a curator, gallerist, and a passionate art lover. I am on a mission to demystify the art world and discover the stories behind the world’s greatest paintings and sculptures. Each episode will focus on one piece of art and break it down, using clear and concise language free of 'art-speak'.

James Payne, @GreatArtExplained

I don't remember clearly how I discovered his channel but what I do remember is that I had a fascinating saturday afternoon listening to him for a good hour explaining The Garden of Earthly Delights by Dutch painter Hieronymus Bosch.

Source: https://commons.wikimedia.org/wiki/File:The_Garden_of_earthly_delights.jpg

I was blown away by the incredible detail in the painting! One can't imagine just how much thought went into it. How every part of the painting is arranged with care. Telling a different part of the story.

Truth to be told: I don't really have a grasp on the world of art. Yes, I know the big painters, maybe some smaller ones. Heard of all the important paintings and that they are valued at millions of US-$, but apart from that? Do I know, really know and understand why this painting is to valuable? Especially culturally? In 99,9% of cases plain and simple: No.

After watching the video, I could see why this painting is so great. And I like it when I learn new things that make me see the wider world in a different way.

In case you prefer something to read, James has also written a book: Great Art Explained: The Stories Behind the World's Greatest Masterpieces (Amazon) and for my German speaking readers: It's also available in German: Meisterwerke der Kunst – großartig erklärt: Was hinter den bedeutendsten Kunstwerken der Welt steckt und wie man sie entschlüsselt (Amazon)

And if you really dislike art but solely enjoy books? James also got the channel Great Books Explained (https://www.youtube.com/@greatbooksexplained371) in which he does exactly the same as in his other channel, but for books.

TL;DR: I updated to Bludit 3.17.2 and this change isn't needed anymore as the Canonical plugin was rewritten and now includes canonical links for tag and category pages.

Google's Search Console has problems with my site regarding duplicate content due to "Duplicate without user-selected canonical". Which is Google's wording for:

The automatically generated site-views for your categories and tags have the same content sometimes. Hence identical content is available under different URLs.

And yes, when I checked the HTML source of these pages there is no canonical link. Despite the canonical-plugin being active.

A single post shows the following:

<!-- Load Bludit Plugins: Site head -->
<link rel="canonical" href="https://admin.brennt.net/please-don-t-remove-your-comment-section">
<link href="/bl-plugins/prism/css/prism.css" rel="stylesheet">

But for https://admin.brennt.net/tag/2fa or https://admin.brennt.net/category/it it only showed the following:

<!-- Load Bludit Plugins: Site head -->
<link href="/bl-plugins/prism/css/prism.css" rel="stylesheet">

ChatGPT to the rescue! - But with a twist!

As it is currently 6am I wasn't in the mood to dig through the code myself. So I asked ChatGPT: "How do I retrieve the tag name element in the Bludit blogging software". Only for ChatGPT to give me an extensive answer. ... For PHP-Code the canonical-plugin didn't have.

Ah.. Yes.. Typical, isn't it? Stupid LLMs, bla bla.

No, turns out on January 15th the canonical-plugins was extensively re-written. Fixing the missing canonical links. Great. So ChatGPT did indeed based it answer on the current code. I quickly searched the Bludit forum and GitHub if there is anything said about a new Bludit release but nothing showed up. And as the last release was in August 2024 I currently don't have high hopes for a release in the near future.

Instead I just copy & pasted the current code completely into ChatGPT - as providing the GitHub link didn't work - and got an answer that looked good.

<?php

class pluginCanonical extends Plugin {

    public function siteHead()
    {
        // Home page
        if ($GLOBALS['WHERE_AM_I'] === 'home') {
            return '<link rel="canonical" href="'.DOMAIN_BASE.'"/>'.PHP_EOL;
        }

        // Single page / post
        elseif ($GLOBALS['WHERE_AM_I'] === 'page') {
            global $page;
            return '<link rel="canonical" href="'.$page->permalink().'"/>'.PHP_EOL;
        }

        // Tag pages
        elseif ($GLOBALS['WHERE_AM_I'] === 'tag') {
            global $url;
            $tagKey = $url->slug();
            return '<link rel="canonical" href="'.DOMAIN_TAGS.$tagKey.'"/>'.PHP_EOL;
        }

        // Category pages
        elseif ($GLOBALS['WHERE_AM_I'] === 'category') {
            global $url;
            $categoryKey = $url->slug();
            return '<link rel="canonical" href="'.DOMAIN_CATEGORIES.$categoryKey.'"/>'.PHP_EOL;
        }
    }

}

The only new lines are the ones for tag pages and category pages.

Editing the bl-plugins/canonical/plugin.php file, reloading a category and a tag page, aaaaaaand we're green on canonical links.

Result for https://admin.brennt.net/tag/2fa:

<!-- Load Bludit Plugins: Site head -->
<link rel="canonical" href="https://admin.brennt.net/tag/2fa"/>
<link href="/bl-plugins/prism/css/prism.css" rel="stylesheet">

Result for https://admin.brennt.net/category/it:

<!-- Load Bludit Plugins: Site head -->
<link rel="canonical" href="https://admin.brennt.net/category/it"/>
<link href="/bl-plugins/prism/css/prism.css" rel="stylesheet">

Great. Now back to the main problem...

For an upcoming blog article I wanted to include a link to a blog I saw in the comment section of the following blog post: James Zhan | Google De-Indexed My Entire Bear Blog and I Don’t Know Why

Only that I couldn't find the comments anymore. What!?

Turns out, as stated in the changelog of his blog, the author removed the comments section and with this, all comments.

Why!? Now all that wisdom is gone. I.. Yeah, ok. It's his blog. I get it. However I'm annoyed since I forgot to make a copy of that page in my Readeck-Instance.

*sigh* Lesson learned. I guess.

But how cool is it to have a changelog for your blog? After all it immediately answered my question.

I encountered an interesting Mastodon post. In it a user describes the problem that the Apache 2, which is running in foreground inside a docker container, stops when the terminal window is resized.

What?

And it is even written to the logfile:

[Mon Jan 12 17:38:14 2026] [notice] caught SIGWINCH, shutting down gracefully

Clearly this must be some strange bug regarding signal handling in Apache, right?

Turns out: No. This is just a misuse of the WINCH signal. Normally it signals a process that the terminal resolution has changed. The process can then adjust output etc.

But Apache uses the signal to initiate a graceful-stop. This is even documented under https://httpd.apache.org/docs/2.4/stopping.html#gracefulstop

"The WINCH or graceful-stop signal causes the parent process to advise the children to exit after their current request [...]"

However, I would prefer if they would explicitly point out that they:

• Re-Use that signal to achieve a completely different thing
• Mention the possible implications this has if your Apache process is executed in the foreground

After ~14 years of service one of the WD Green drives failed. It had a few bad sectors for years, but the count didn't increase. Hence I didn't replace the drive immediately. Now it started reporting I/O errors too a few hours ago.

As the situation was foreseeable I already bought two replacement drives. Now the first one is replaced and the 9TB RAID5 will take roughly more than a day to rebuild.

root@DiskStation:~# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdc3[5] sda3[0] sdd3[4] sdb3[1]
      8776632768 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/3] [UU_U]
      [>....................]  recovery =  0.0% (280704/2925544256) finish=2605.1min speed=18713K/sec

md1 : active raid1 sdc2[2] sda2[0] sdb2[1] sdd2[3]
      2097088 blocks [4/4] [UUUU]

md0 : active raid1 sdc1[2] sda1[0] sdb1[1] sdd1[3]
      2490176 blocks [4/4] [UUUU]

unused devices: <none>

A few minutes later the estimate already went down by 1100 minutes. I'll see how long it really took in the end.

root@DiskStation:~# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdc3[5] sda3[0] sdd3[4] sdb3[1]
      8776632768 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/3] [UU_U]
      [>....................]  recovery =  0.3% (9309952/2925544256) finish=1584.8min speed=30667K/sec

md1 : active raid1 sdc2[2] sda2[0] sdb2[1] sdd2[3]
      2097088 blocks [4/4] [UUUU]

md0 : active raid1 sdc1[2] sda1[0] sdb1[1] sdd1[3]
      2490176 blocks [4/4] [UUUU]

unused devices: <none>

After Christmas I will replace the 4th drive also, as this also reported a bad sector as of today. And having swapped out 2 out of 4 drives is somewhat okay-ish for a 4 drive RAID5 with no hotspare. I don't assume the remaining to drives will fail completely within such a short period, that I can't replace at least one (and let the RAID rebuild, of course!).

Luckily I made my full-backup a few days ago. 😁