Please raise the new case with priority P2, as we are observing the RE rebooted and the core dump generated.

dev = gpt/junos, ino = 1321813, fs = /.mount
panic: ffs_freefile: freeing free inode
cpuid = 0
newpanic = 1, trace_on_panic = 0, debugger_on_panic = 0
[panic] rebooting kernel with options 104
Uptime: 54m27s
Dumping 1014 out of 16319 MB:..2%..12%..21%..32%..41%..51%..62%..71%..81%..92%
Dump complete

From core dump backtrace, we can see a filesystem inconsistency, which is related to filesystem getting corrupted during the operation.

There is no fix for this & reboot is the only way to clear the issue, which was already done by system here.

This is updated via PR 1514871.

RCA based on the PR:

The filesystem inconsistency is not something boot-time FSCK can fix, nor is it allowed to. At boot, the set of errors FSCK will repair are limited to those specifically caused by an unclean shutdown via panic, power loss, etc. There were also some soft update inconsistencies, so it is possible something else is corrupting the filesystem during operation. The panic of "Freeing free inode" also seems to indicate that.

The only way to correct errors like this is to boot the device off alternate media and do a full FSCK of the partition that holds /dev/gpt/junos. However, although this could technically correct the specific piece of damage, it is likely that the system has other damage to the filesystem too, and files/directories may no longer be consistent.

If multiple reboots with same core are seen, we can replace the RE proactively.