GCP Compute Engine full disk not resized file system on public image

GCP VM with 99,8% full disk has not resized its file system after increasing the disk capacity in google console.

I have a small VM on GCP based on public image ubuntu-2004-focal-v20220419. There was a 10GB disk with root partition and file system. Some logs occupied 99,8% of the disk capacity. I am able ssh the VM because GCP can still copy ssh keys to it, but to detect a heavy folder I had to use another disk to keep temporary files:

sudo du -Sh | sort -rh -T /dev/tmp | head -5

instead of

sudo du -hs * | sort -rh | head -10

I increased the disk size to 15GB (without removing any data) and restarted the VM. Documentation says:

For VMs with public images, Compute Engine automatically resizes the root partition and file system after you increase the size of the boot disk and restart the VM.

however, I can see that file system was not resized

~$ sudo lsblk
sda       8:0    0    15G  0 disk 
├─sda1    8:1    0   9.9G  0 part /
├─sda14   8:14   0     4M  0 part 
└─sda15   8:15   0   106M  0 part /boot/efi

Right after restarting the VM I can se following message in Logs Explorer:

{
  insertId: "1"
  jsonPayload: {
    @type: "type.googleapis.com/cloud_integrity.IntegrityEvent"
    bootCounter: "13"
    earlyBootReportEvent: {
      actualMeasurements: [8]
      policyEvaluationPassed: false
      policyMeasurements: [3]
    }
  }
  logName: "projects/<vm name>/logs/compute.googleapis.com%2Fshielded_vm_integrity"
  receiveTimestamp: "2022-11-30T09:12:33.141683678Z"
  resource: {2}
  severity: "ERROR"
  timestamp: "2022-11-30T09:12:32.752150154Z"
}

I followed steps on jhanley.com and there are no entries regarding resizing. There are also neither expand-root.sh script nor expand-root service.

I am wondering why is it so? I expected that additional 5GBs will be merged with sda1 automatically based on above documentation. Could it be, that the disk is so full, so some GCP background processes are not able to resize the file system?

[EDIT] I created a snapshot of the disk and resized file share manually. In the serial port output I can now see:

Nov 30 11:55:30 <vm name> kernel: [    9.016905] EXT4-fs (sda1): resizing filesystem from 4165883 to 4428027 blocks
Nov 30 11:55:30 <vm name> kernel: [    9.021130] EXT4-fs (sda1): resized filesystem to 4428027

Finally I was able to fix it. In my case disk was too full what prevented system from running resizing file system scripts.

After reading John Hanley blog post I realized that file system resizing has never happened. I resized file system and partitions myself as described here:

sudo parted /dev/sda

and then, I extended the file system:

sudo resize2fs /dev/sda1

That should have been done automatically, what normally happens, but again, due to disk clogging mostly, the process was not able to be performed. After manual resizing of file system and resizing the disk capacity in GCP I see that now it works as it is suppose to:

Nov 30 11:55:30 <vm name> kernel: [    9.016905] EXT4-fs (sda1): resizing filesystem from 4165883 to 4428027 blocks
Nov 30 11:55:30 <vm name> kernel: [    9.021130] EXT4-fs (sda1): resized filesystem to 4428027

> lsblk
sda       8:0    0    17G  0 disk 
├─sda1    8:1    0  16.9G  0 part /
├─sda14   8:14   0     4M  0 part 
└─sda15   8:15   0   106M  0 part /boot/efi

> sudo df -Th
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/root      ext4       17G   11G  6.2G  63% /