The reason for this is:
1) We want to use the same fetch tool for all operational data, to
avoid having duplicated xpaths scattered across the repo.
2) We want to call this directly from the CLI, which means it need to
be escape safe. A unprivileged user shall be able to use it but not
escape into a shell or do other malicious stuff.
Signed-off-by: Richard Alpe <richard@bit42.se>
There's several reasons for this. The main reason is that it was
developed as an intermediate way of getting system information when
the operational datastore was almost empty. There's not a lot of data
available in the operational datastore and we shall rely on that data
primarily. This command isn't safe to run from a jailed CLI as i
doesn't validate input and run commands directly in the shell, making
it hard to protect against a CLI jail break.
In upcoming patches we will introduce a new show tool that relies
solely on operational data and which sanitize the user input.
Signed-off-by: Richard Alpe <richard@bit42.se>
- Update usage text for readability, add example
- Reindent getopts case and add -h
- Allow 'git rm -f' to remove already staged patches
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
- Bump kernel to 6.12.21, same as other tier one boards
- Fix#1006 byt enabling netlink for ethtool (now works!)
- Sync defconfigs:
- LIBXCRYPT now in an rdep of another package
- Disable FORCE check hashes for now
- Drop patches for 6.10 tree (r2s kernel)
- Port RTL8153b patch for R2S LAN LED support
Fixes#1006
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
This silences a bogus warning in the log when runparts is called with no
argument. I.e., when there is no product specific init files available.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
There is no such loglevel 'critical', only 'crit' is defined.
For some reason this issue has not been spotted until the upgrade to
Buildroot 2025.02, which includes sysklogd v2.7.0, and Finit v4.11.
Introduced in 3e48af6, when the concept of failure-config was added.
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
When stopping a container that is (stuck) in setup state, e.g., fetching
its container image, we need to send SIGTERM to the container wrapper
script rather than forwarding the 'stop' command to podman.
With this fix, and the Finit upgrade, there is no longer a 10 second
timeout before Finit sends SIGKILL to the PID. Instead, the script now
immediately react to the initial SIGTERM.
Related to issue #980
Signed-off-by: Joachim Wiberg <troglobit@gmail.com>
Richard Alpe