<!--
     Please make sure you've read and understood our contributing guidelines:
     https://github.com/Azure/SONiC/blob/gh-pages/CONTRIBUTING.md

     ** Make sure all your commits include a signature generated with `git commit -s` **

     If this is a bug fix, make sure your description includes "fixes #xxxx", or
     "closes #xxxx" or "resolves #xxxx"

     Please provide the following information:
-->

#### Why I did it

The build fails if kdump is enabled on the build host, even though the relevant build step is performed in a dockerized chroot.

```
+ sudo LANG=C chroot ./fsroot-cisco-8000 kdump-config symlinks 5.10.0-23-2-amd64
Cannot change symbolic links when kdump is loaded ... failed!
```

Fixes sonic-net#5097, Fixes sonic-net#17023

##### Work item tracking
- Microsoft ADO **(number only)**:

#### How I did it

kdump installation checks if kdump is already running and aborts if so. This is good in most cases, but it's not relevant when installing into a chroot inside a docker container. This adds a basic patch to disable this check during build.

Note that the kdump status of the build host is imported into the docker build container via the sysfs file system:

```
$ ls -id /sys/kernel/kexec_crash_loaded && cat /sys/kernel/kexec_crash_loaded
7824 /sys/kernel/kexec_crash_loaded
0

$ docker run --rm debian bash -c "ls -id /sys/kernel/kexec_crash_loaded && cat /sys/kernel/kexec_crash_loaded"
7824 /sys/kernel/kexec_crash_loaded
0
```

The inodes and file content are identical inside and outside of the container.

#### How to verify it

<!--
If PR needs to be backported, then the PR must be tested against the base branch and the earliest backport release branch and provide tested image version on these two branches. For example, if the PR is requested for master, 202211 and 202012, then the requester needs to provide test results on master and 202012.
-->

1. Enable kdump on the build host
2. Confirm baseline build fails with the "Cannot change symbolic links when kdump is loaded" error
3. Apply this change and build succeeds

#### Which release branch to backport (provide reason below if selected)

<!--
- Note we only backport fixes to a release branch, *not* features!
- Please also provide a reason for the backporting below.
- e.g.
- [x] 202006
-->

- [x] 202405
- [x] 202411
- [x] 202505

#### Tested branch (Please provide the tested image version)

<!--
- Please provide tested image version
- e.g.
- [x] 20201231.100
-->

master (2975205)

#### Description for the changelog
<!--
Write a short (one line) summary that describes the changes in this
pull request for inclusion in the changelog:
-->

[build] fix build failure on kdump-enabled hosts

<!--
 Ensure to add label/tag for the feature raised. example - PR#2174 under sonic-utilities repo. where, Generic Config and Update feature has been labelled as GCU.
-->

#### Link to config_db schema for YANG module changes
<!--
Provide a link to config_db schema for the table for which YANG model
is defined
Link should point to correct section on https://github.com/Azure/sonic-buildimage/blob/master/src/sonic-yang-models/doc/Configuration.md
-->

#### A picture of a cute animal (not mandatory but encouraged)

Fix sonic-net#5097, Fix sonic-net#17023

Why I did it
The build fails if kdump is enabled on the build host, even though the relevant build step is performed in a dockerized chroot.

+ sudo LANG=C chroot ./fsroot-cisco-8000 kdump-config symlinks 5.10.0-23-2-amd64
Cannot change symbolic links when kdump is loaded ... failed!

How I did it
kdump installation checks if kdump is already running and aborts if so. This is good in most cases, but it's not relevant when installing into a chroot inside a docker container. This adds a basic patch to disable this check during build.

Note that the kdump status of the build host is imported into the docker build container via the sysfs file system:

$ ls -id /sys/kernel/kexec_crash_loaded && cat /sys/kernel/kexec_crash_loaded
7824 /sys/kernel/kexec_crash_loaded
0

$ docker run --rm debian bash -c "ls -id /sys/kernel/kexec_crash_loaded && cat /sys/kernel/kexec_crash_loaded"
7824 /sys/kernel/kexec_crash_loaded
0
The inodes and file content are identical inside and outside of the container.

How to verify it
Enable kdump on the build host
Confirm baseline build fails with the "Cannot change symbolic links when kdump is loaded" error
Apply this change and build succeeds