Commit 78001e35dd for frr

commit 78001e35dda63502fc6e84a1e12a5860db26166a
Author: Minghan Chan <mhchann082@gmail.com>
Date:   Wed Oct 21 20:32:55 2026 +0800

    ci: unload the host's FRR and tshark AppArmor profiles

    With the module packages installed, the amd64 Test jobs on the
    ubuntu-26.04 image now run topotests, but 56 to 58 tests fail, 125
    error out in setup, and the serial rerun of about 70 modules then
    hits the 180-minute job timeout.

    Ubuntu 26.04's apparmor package (5.0.2) ships enforcing profiles for
    18 of the daemons in /usr/lib/frr, among them bgpd, staticd, ospfd and
    isisd. The host loads them at boot, and they attach by path to the
    same binaries inside the privileged topotest container. The profiles
    only allow the packaged paths such as /etc/frr, /run/frr and
    /var/log/frr. So every confined daemon fails to create its log file
    under /tmp/topotests, to open /var/lib/frr/<daemon>.db and to write
    its gcov data. "bgpd -v" then prints the gcov errors ahead of its
    version, and checkRouterVersion() raises "got a invalid version
    string". zebra, mgmtd and sharpd have no profile and are not affected.

    The same package has a profile for /usr/bin/tshark, with a child
    profile for the dumpcap it runs. In the 24.04 container it breaks the
    only two topotests that capture with tshark, tshark/test_tshark.py and
    msdp_topo6/test_msdp_topo6.py: tshark exits 0 with no packets.
    24.04's libpcap (1.10.4) links libibverbs, which reads
    /etc/libibverbs.d/ when dumpcap starts. The profile denies that,
    libibverbs prints a warning, and tshark 4.2 takes it for a message
    from dumpcap and captures nothing:

      tshark: Unknown message from dumpcap reading header, try to show it
      as a string: libibverbs: Warning: couldn't open config directory
      '/etc/libibverbs.d'.

    22.04's libpcap (1.10.1) does not use libibverbs. On an ubuntu-26.04
    runner, tshark 4.2.2 in a privileged 24.04 container captured none of
    the 6 packets of 3 pings across a veth pair while the profile was
    loaded, and all 6 once it was unloaded. tshark 3.6.2 in a 22.04
    container captured all 6 either way.

    The apparmor packages in 22.04 and 24.04 have none of these profiles.

    Before the container starts, unload the profiles that attach to
    /usr/lib/frr or /usr/bin/tshark, if there are any. The host's other
    profiles stay loaded.

    Signed-off-by: Minghan Chan <mhchann082@gmail.com>

diff --git a/.github/workflows/github-ci.yml b/.github/workflows/github-ci.yml
index 9c97197ec7..22a101ca66 100644
--- a/.github/workflows/github-ci.yml
+++ b/.github/workflows/github-ci.yml
@@ -274,6 +274,12 @@ jobs:
           sudo modprobe vrf || true
           sudo modprobe mpls-iptunnel
           sudo modprobe mpls-router
+          # Ubuntu 26.04 loads AppArmor profiles for most FRR daemons and for
+          # tshark. They confine the same binaries inside the container too:
+          # the daemons are denied topotest paths (logs, /var/lib/frr, gcov)
+          # and dumpcap under tshark captures nothing. Unload those profiles.
+          AA_PROFILES=$(grep -lsE -d skip '^profile [^ ]* /usr/(lib/frr/|bin/tshark )' /etc/apparmor.d/* || true)
+          if [ -n "${AA_PROFILES}" ]; then sudo apparmor_parser -R ${AA_PROFILES}; fi
           docker load --input /tmp/frr-${{ matrix.cfg.platform }}.tar

           ADD_DOCKER_ENV=""