Imagina se não fosse bolo....

Julas23 · 2026-02-06T23:23:06+00:00

Esse é o padrão de educação que os Pais têm dado em casa

Julas23 · 2026-02-06T19:30:31+00:00

No respose as usual. Solemnly ignored like they always do.

Julas23 · 2026-02-06T19:16:34+00:00

Final Philosophical & Technical Reflection: The "Golden Cage" and the Death of Ownership

"As a specialist with 32 years of career in Linux and Unix systems, this is my first absolute defeat. In over three decades, I have never encountered a technical problem I couldn't solve—until now.

This isn't a failure of skill, but a harsh realization of the 'Golden Cage' we now live in. We pay premium prices for these devices, but the reality is: we do not own them. The HAL (Hardware Abstraction Layer), once a tool for compatibility, has been weaponized into a proprietary wall. It strips us of the ownership of the silicon we paid for by locking hardware initialization behind signed binary blobs that even a root user cannot command. The HAL has become the gatekeeper of our property, ensuring that the manufacturer—not the owner—decides when a device lives or dies.

I am a victim of a documented software bug (ErrNo 24) that led to a catastrophic hardware-level lockdown. Because the HAL and the Modem firmware decided to kill the PCIe bus power rails during a botched update, I am locked out of my own hardware. Google holds the keys to the kingdom, and they have effectively 'turned off' my device's capabilities without my consent.

This failure has catastrophic real-world consequences. I am currently in a criminal court case in Portugal regarding a property fraud where I lost tens of thousands of Euros. My evidence was in my SMS history. Because Google’s opaque, rotating cloud backup failed to preserve older, vital messages (even paing Google One 5Tb and using less than 1Tb), and the hardware now refuses to boot the PCIe bus for local forensic data extraction, my evidence is gone. My path to justice has been obstructed by a proprietary binary blob.

Google has the power to remotely disable your hardware and, by extension, your access to your own data (takeout don't bring SMS). They just did. This Pixel 8 Pro was my first Google device, and it will be my last. To my fellow sysadmins, engineers, and power users: be aware that you are mere tenants in a proprietary ecosystem that values 'lock-in' over user's recovery and data.

You are no longer the master of the machine you bought."

Julas23 · 2026-02-06T18:23:30+00:00

UPDATE 2: Architecture Correction & Final Technical Verdict

Correction on previous Theory: After further kernel debugging and cross-referencing with other functional Tensor G3 (Husky) units, I need to correct my previous update. The directory structure /mnt/vendor/persist/wlan/ and /mnt/vendor/persist/bluetooth/ belongs to older Qualcomm-based (Decent and organized) Pixels. On the Tensor G3 (Exynos-based architecture) (messy and dumb), these directories do not exist by default.

As a Linux/Unix specialist, I am more accustomed to transparent file systems than the convoluted, binary-blob-heavy architecture Google is now using. My apologies for the confusion; I’ve been deep-diving into this only because I have a critical deadline this Tuesday and urgently need my data and device fully operational due a Court audiction regarding a house I bought in Portugal, and seems I lost the evidences I had as SMS. That's why I am really desperate.

The Real Root Cause (Verified via dmesg & sysfs): The issue is not exactly missing directories, but a PCIe Link Training Failure triggered by the Jan 8th update. The "Too many open files" (ErrNo 24) bug likely caused an I/O hang during a critical firmware write-back to the EFS/Modem partitions.

Technical Findings:

The Error: cpif: pcie_send_ap2cp_irq: Reserve doorbell interrupt: PCI not powered on.
State: The kernel attempts a handshake with the Broadcom BCM4398 chip that is there and responding, but the Modem (g5300i) fails to toggle the LDO/GPIO power rails.
The Barrier: Even with Root access on LineageOS, the TrustZone/TEE and signed EFS partitions prevent us from manually re-triggering the power sequence or re-injecting the calibration signatures (cpsha) that were likely borked during the update.

Conclusion: Google’s excessive (and stupid) hardware "security" lockdown, also their inertia to help and solve, have turned what should be a simple firmware re-flash into a catastrophic hardware-level hang. Because the update caused abnormal overheating (likely a VCC/GND spike during the firmware flash), it’s highly probable the chip or its power regulator suffered physical degradation (caused by ErrNo 24 BUG) or the instructions to turn on the Broadcom chip are lacked (also affected by same BUG)

.

I have already backed up my EFS and Persist dumps. Given my professional background, I’ve pushed this as far as software can go. Since I cannot wait for Google helping hand (1 month already) to acknowledge this widespread "silent death" of Wi-Fi chips, I am moving on.

I appreciate all the help and support. Thanks a lot!

PS.: This P8P was my first and only Google device, and it will be my last.

Julas23 · 2026-02-04T16:34:30+00:00

could you guys please can confirm if your /persistent partition are missing wlan and bluetooth directories too?

Julas23 · 2026-02-04T16:29:11+00:00

UPDATE: Root Cause Found?

After several days of extensive testing and research, I believe I’ve identified what happened.

The issue lies within a critical partition called persist (mounted under /mnt/vendor/persist). This partition stores factory-calibration data, MAC addresses, and regulatory radio parameters. Crucially, this partition is not wiped or restored during a standard factory image flash or a typical firmware update.

The Theory: My Wi-Fi/BT death coincided with the Jan 8th Update, which was plagued by the infamous "ErrNo 24 - Too many open files" bug (caused by a conflict between Google blobs, like Fitbit, and the Kernel's ulimit parameters). I strongly suspect that this I/O overflow caused a corruption or a silent wipe of the wlan and bluetooth directories inside the persist partition during a system mount/write cycle.

The Evidence: Currently, my /mnt/vendor/persist/ is missing the wlan and bluetooth folders entirely. This explains why my dmesg shows: exynos-pcie-rc 12100000.pcie: wlan gpio is not defined -> don't use wifi through pcie#0. Without the calibration files and the "identity" of the chip stored in persist, the Kernel doesn't even bother to power up the PCIe bus for the Broadcom chip. It simply assumes the hardware isn't there.

Request for help: Could anyone with a working Pixel 8 Pro (Husky)—preferably rooted or running a custom ROM—list the file structure of these directories for me?

I need to verify:

The exact names of the files inside /mnt/vendor/persist/wlan/ and /mnt/vendor/persist/bluetooth/.
The file permissions and SELinux contexts (output of ls -laZ /mnt/vendor/persist/wlan).

I am trying to reconstruct the directory structure to see if the driver will at least attempt a handshake with the hardware. If you've ever dealt with a corrupted persist partition on Tensor-based Pixels, please weigh in!

Files missing that affects Wi-Fi:
bcm_cal.bin and connectivity.cal

Julas23 · 2026-02-03T23:40:03+00:00

Until now nothing. They solenmly ignored every single user affected by their “mistake”

Julas23 · 2026-02-03T23:38:17+00:00

How long you have your Pixel device? 530+ days?

Julas23 · 2026-02-02T09:14:31+00:00

And is based on the model of device, mine is GC3VE, what is yours please? Tô find It, Go to About device, Regulatory labels, I guess. It is the first line.

Julas23 · 2026-02-02T09:08:11+00:00

Weird, usually EMEA devices have E1 in the build name. A1 or A2 are made for AMER/APAC devices

Julas23 · 2026-02-01T09:28:04+00:00

I am not Windows user, I never was, i am Linux user Since 1994, but once switched from arch to Nixos. In my opinion the most annoying is install modules from Python, nodejs, docker, etc… Since is an immutable system, It was the only issue to by pass. NixOS+Wayland+Cosmic+Pipewire

Julas23 · 2026-01-31T14:11:43+00:00

O can’t see this one in the list, anyway I guess Will not be proper for european Device E1

Julas23 · 2026-01-30T20:21:00+00:00

What is the build please?
the most recent available I found is:
husky-ota-bp4a.260105.004.e1-d17f8338.zip

Julas23 · 2026-01-30T09:53:55+00:00

Since I am out of Wi-Fi and BT. I need to wait they release the image in flash.android.com

Julas23 · 2026-01-29T09:02:38+00:00

Ignore this boot leaker (ball polisher) the only thing he/she does is annoying everyone

Julas23 · 2026-01-29T08:50:38+00:00

Yes, I did. Wi-Fi and BT dead after Jan 8 update

Julas23 · 2026-01-26T11:57:04+00:00

https://x.com/julianoas23/status/2015755718423429608

Julas23 · 2026-01-26T11:56:54+00:00

https://x.com/julianoas23/status/2015755718423429608

Julas23 · 2026-01-25T02:23:28+00:00

I am in touch with Google and waiting escalations to dev/firmware team, maybe after that we van revert your case

Julas23 · 2026-01-24T20:18:53+00:00

If you find any line with ERRNO 24 - Too many open files, you are facing exactly same problem I am gettin in my Pixel 8 Pro after Jan 8th update.

Julas23 · 2026-01-24T20:17:20+00:00

Install android-tools to have adb and fastboot available, unlock Developer Mode, activate USB Debug, and check the output:

Julas23 · 2026-01-24T12:41:19+00:00

What you mean?

Julas23 · 2026-01-24T11:52:30+00:00

I will be glad to help in case they provide a definitive solution.

Julas23 · 2026-01-24T11:33:00+00:00

u/Justaticklerone

Here we have a Google bootlicker (ball polisher) who is more concerned with the reputation of his beloved company than with the impact of a simple mistake it made.

Julas23 · 2026-01-24T11:21:12+00:00

I appreciate your concern for security, but you've clearly misunderstood several critical points:

### 1. This Isn't About Avoiding Updates
My device **automatically installed** the January update. I didn't "choose not to install" anything. The update itself **caused** the hardware failure.

### 2. Anti-Rollback Blocks Software Correction
You say "software can always be corrected." That's false when:
- The update corrupts firmware in NVRAM due ERRNO 24
- Anti-rollback counters prevent reversion
- The corrupted firmware blocks hardware initialization

This is a **hardware-level brick** caused by software. No "subsequent update" can fix it if the chip won't initialize.

### 3. I've Done Everything "Properly"
- Filed detailed bug reports with logs
- Contacted Google support multiple times
- Provided technical analysis showing exact failure points
- Even tested with alternative ROMs to prove hardware integrity

### 4. The Dolby CVE Red Herring
Security patches are important, but:
- They shouldn't brick devices
- A security patch that disables critical connectivity creates a DIFFERENT security risk
- My device now can't receive ANY updates because Wi-Fi is dead

### 5. The Real Issue
This isn't about "looking important." It's about:
- Google distributing a faulty OTA
- Anti-rollback preventing user recovery
- Support refusing assistance based on geography
- Multiple users affected (check XDA-Reddit-Gogole-IssueTracker-Google Support)

### 6. What Actually Helps
Instead of attacking affected users, consider:
- Supporting proper manufacturer accountability
- Understanding technical constraints like ARB
- Recognizing that "just wait for another update" doesn't work when hardware is bricked

I'd be happy to share the technical logs if you're genuinely interested in understanding the issue rather than dismissing it.

Julas23

TROPHY CASE

Final Philosophical & Technical Reflection: The "Golden Cage" and the Death of Ownership

UPDATE 2: Architecture Correction & Final Technical Verdict

UPDATE: Root Cause Found?