Subject: Critical System Failure: Permission Loop in Antigravity causing Kernel Panic and SSD Controller Lock (Nobara/Fedora)

Subject: Critical System Failure: Permission Loop in Antigravity causing Kernel Panic and SSD Controller Lock (Nobara/Fedora)

Environment:

  • OS: Nobara Linux (Fedora-based)

  • Kernel: 6.19.5-200.nobara.fc43.x86_64

  • CPU: AMD Ryzen 7 5700G

  • Storage: Kingston A400 1TB SSD (Phison S11 Controller)

Issue Description:

While attempting to initialize Docker-based agents within Google Antigravity, the IDE entered an infinite loop of sudo requests for Docker networking configurations without notifying the user via the UI. This caused a massive spike in system interrupts and resource exhaustion.

Key Error Logs:

  • Firewall Conflict: firewalld[1379]: ERROR: NAME_CONFLICT: new_policy_object(): ‘docker-forwarding’.

  • D-Bus Failure: dbus-broker-launch[1131]: Service file ‘/usr/share/dbus-1/system-services/org.shadowb…’ is invalid.

  • Filesystem Corruption: BTRFS error (device sda3 state EA): failed to run delalloc range.

Critical Consequence:

The relentless loop of failed permission requests and network conflicts led to a Kernel Panic. During the crash, the high volume of corrupt write operations triggered a firmware lock on the Kingston A400 SSD. The drive has since become unresponsive and is no longer detected by the UEFI BIOS (likely a Phison S11 controller panic).

Suggested Fix:

Antigravity must implement a “circuit breaker” or a clear user-facing prompt when Docker commands fail due to permissions or firewalld conflicts, rather than silently retrying and saturating system resources.

I agree that this was poor behavior from AG to continually spam requests,

But it seems like this exposed an underlying issue in the hardware and/or firmware/operating system.

In a normal scenario, such added load shouldn’t cause a cascade failure like that. My past experiences with BTRFS want to point the finger at that.

1 Like