[PATCH procd] utils: fix get_active_console when kernel returns multiple values
/sys/class/tty/console/active may return multiple values on
kernels where framebuffer support is enabled but the system
is supposed to be using a serial console.
e.g
$ cat /sys/class/tty/console/active
tty0 ttyS0
On such systems, tty0 is a dummy console:
[0.008273] Console: colour dummy device 80x25
[0.012742] printk: console [tty0] enabled
The serial console doesn't appear until much later:
[0.092468] 21c0500.serial: ttyS0 at MMIO 0x21c0500
[1.713893] printk: console [ttyS0] enabled
So far this only appears to happen on systems using
device tree.
In these circumstances, use the last console device
shown in the sysfs active file.
Fixes: 2cfc26f ("inittab: detect active console from kernel if no console=
specified")
Signed-off-by: Mathew McBride
---
utils/utils.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
diff --git a/utils/utils.c b/utils/utils.c
index f0c4a90..43b24c6 100644
--- a/utils/utils.c
+++ b/utils/utils.c
@@ -138,6 +138,10 @@ blobmsg_list_equal(struct blobmsg_list *l1, struct
blobmsg_list *l2)
char *get_active_console(char *out, int len)
{
char line[CMDLINE_SIZE + 1];
+ char *sptr, *token;
+ char *console = NULL;
+
+ memset(line, 0, sizeof(line));
int fd = open("/sys/class/tty/console/active", O_RDONLY);
ssize_t r;
@@ -152,15 +156,22 @@ char *get_active_console(char *out, int len)
if (r <= 0)
return NULL;
- /* The active file is terminated by a newline which we need to strip */
- char *newline = strtok(line, "\n");
-
- if (newline != NULL) {
- strncpy(out, newline, len);
- return out;
+ /* There may be multiple 'active' consoles.
+* On kernels that support both graphical and
+* serial consoles, Linux may create a 'dummy'
+* framebuffer console on tty0 if no other console
+* device has been probed yet. Often a serial
+* driver (e.g ttyS0) might only be probed later
+* in the boot process.
+*/
+ for (token = strtok_r(line, " \t\n", ); token;
+token = strtok_r(NULL, " \t\n", )) {
+ strncpy(out, token, len);
+ console = out;
}
+ out[len-1] = '\0';
- return NULL;
+ return console;
}
char* get_cmdline_val(const char* name, char* out, int len)
--
2.30.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 and 19.07 minor release
On 1/24/22 22:53, Hauke Mehrtens wrote: Hi, I would like to tag a new 21.02 and 19.07 minor release in about one week. I am not aware of a severe security problem, it was just some time since the last release. Are there any known regressions in the current stable branches compared to the last release and should we fix them? If we should backport some changes from master please just answer to this mail with the commit and a reason why you need it. There are already some pull requests on github: https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F21.02 https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F19.07 Hauke There are some security patches available for hostapd. Is someone working on backporting them to OpenWrt 21.02 or 19.07? https://w1.fi/security/2022-1/ Dnsmasq also has some new CVEs assigned. Is someone working on backporting these fixes? https://nvd.nist.gov/vuln/detail/CVE-2021-45951 https://nvd.nist.gov/vuln/detail/CVE-2021-45952 https://nvd.nist.gov/vuln/detail/CVE-2021-45953 https://nvd.nist.gov/vuln/detail/CVE-2021-45954 https://nvd.nist.gov/vuln/detail/CVE-2021-45955 https://nvd.nist.gov/vuln/detail/CVE-2021-45956 https://nvd.nist.gov/vuln/detail/CVE-2021-45957 Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02 and 19.07 minor release
Hi, I would like to tag a new 21.02 and 19.07 minor release in about one week. I am not aware of a severe security problem, it was just some time since the last release. Are there any known regressions in the current stable branches compared to the last release and should we fix them? If we should backport some changes from master please just answer to this mail with the commit and a reason why you need it. There are already some pull requests on github: https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F21.02 https://github.com/openwrt/openwrt/pulls?q=is%3Apr+is%3Aopen+label%3Arelease%2F19.07 Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: move bootargs-append patch to generic
This moves bootargs-append support patch from ipq40xx and ipq806x to
generic. This way we can append additional boot arguments from DTS instead
of only being able to overwrite them.
This is a preparation for kirkwood support of ipTIME NAS1.
Signed-off-by: Sungbo Eo
---
.../hack-5.10/920-device_tree_cmdline.patch} | 0
.../hack-5.4/920-device_tree_cmdline.patch} | 0
.../patches-5.10/900-arm-add-cmdline-override.patch | 4 ++--
.../patches-5.10/997-device_tree_cmdline.patch | 12
.../102-powerpc-add-cmdline-override.patch | 4 ++--
5 files changed, 4 insertions(+), 16 deletions(-)
rename target/linux/{ipq40xx/patches-5.10/997-device_tree_cmdline.patch =>
generic/hack-5.10/920-device_tree_cmdline.patch} (100%)
rename target/linux/{ipq40xx/patches-5.4/997-device_tree_cmdline.patch =>
generic/hack-5.4/920-device_tree_cmdline.patch} (100%)
delete mode 100644
target/linux/ipq806x/patches-5.10/997-device_tree_cmdline.patch
diff --git a/target/linux/ipq40xx/patches-5.10/997-device_tree_cmdline.patch
b/target/linux/generic/hack-5.10/920-device_tree_cmdline.patch
similarity index 100%
rename from target/linux/ipq40xx/patches-5.10/997-device_tree_cmdline.patch
rename to target/linux/generic/hack-5.10/920-device_tree_cmdline.patch
diff --git a/target/linux/ipq40xx/patches-5.4/997-device_tree_cmdline.patch
b/target/linux/generic/hack-5.4/920-device_tree_cmdline.patch
similarity index 100%
rename from target/linux/ipq40xx/patches-5.4/997-device_tree_cmdline.patch
rename to target/linux/generic/hack-5.4/920-device_tree_cmdline.patch
diff --git
a/target/linux/ipq806x/patches-5.10/900-arm-add-cmdline-override.patch
b/target/linux/ipq806x/patches-5.10/900-arm-add-cmdline-override.patch
index 830a14924c..dba917872c 100644
--- a/target/linux/ipq806x/patches-5.10/900-arm-add-cmdline-override.patch
+++ b/target/linux/ipq806x/patches-5.10/900-arm-add-cmdline-override.patch
@@ -17,9 +17,9 @@
default ""
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
-@@ -1056,6 +1056,17 @@ int __init early_init_dt_scan_chosen(uns
+@@ -1059,6 +1059,17 @@ int __init early_init_dt_scan_chosen(uns
if (p != NULL && l > 0)
- strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
+ strlcat(data, p, min_t(int, strlen(data) + (int)l,
COMMAND_LINE_SIZE));
+/* CONFIG_CMDLINE_OVERRIDE is used to fallback to a different
+ * device tree option of chosen/bootargs-override. This is
diff --git a/target/linux/ipq806x/patches-5.10/997-device_tree_cmdline.patch
b/target/linux/ipq806x/patches-5.10/997-device_tree_cmdline.patch
deleted file mode 100644
index bdcba2a21c..00
--- a/target/linux/ipq806x/patches-5.10/997-device_tree_cmdline.patch
+++ /dev/null
@@ -1,12 +0,0 @@
a/drivers/of/fdt.c
-+++ b/drivers/of/fdt.c
-@@ -1055,6 +1055,9 @@ int __init early_init_dt_scan_chosen(uns
- p = of_get_flat_dt_prop(node, "bootargs", );
- if (p != NULL && l > 0)
- strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
-+ p = of_get_flat_dt_prop(node, "bootargs-append", );
-+ if (p != NULL && l > 0)
-+ strlcat(data, p, min_t(int, strlen(data) + (int)l,
COMMAND_LINE_SIZE));
-
- /* CONFIG_CMDLINE_OVERRIDE is used to fallback to a different
- * device tree option of chosen/bootargs-override. This is
diff --git
a/target/linux/mpc85xx/patches-5.10/102-powerpc-add-cmdline-override.patch
b/target/linux/mpc85xx/patches-5.10/102-powerpc-add-cmdline-override.patch
index 652e8ee6c3..a2fd800ced 100644
--- a/target/linux/mpc85xx/patches-5.10/102-powerpc-add-cmdline-override.patch
+++ b/target/linux/mpc85xx/patches-5.10/102-powerpc-add-cmdline-override.patch
@@ -17,9 +17,9 @@
help
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
-@@ -1056,6 +1056,17 @@ int __init early_init_dt_scan_chosen(uns
+@@ -1059,6 +1059,17 @@ int __init early_init_dt_scan_chosen(uns
if (p != NULL && l > 0)
- strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
+ strlcat(data, p, min_t(int, strlen(data) + (int)l,
COMMAND_LINE_SIZE));
+/* CONFIG_CMDLINE_OVERRIDE is used to fallback to a different
+ * device tree option of chosen/bootargs-override. This is
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Re: coreutils
If you are talking about the https://github.com/uutils/coreutils project then it's far from completion. Also the Rust compiler is not so good for MIPS targets which are used by most routers. OpenWrt is based on BusyBox utils which is a clone of coreutils but with many options stripped to keep space. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] x86: geode: use kernel [hwrng] to provide randomness
I wonder, does it applicable for all targets with HW RNG support? Is it necessary to have quality of HW RNG not less than 1000 for kernel to use /dev/hwrng directly without user space tools like rng-tools? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] wireguard-tools: allow generating private_key
Hey ynezz, I tried to bump this in #openwrt-devel yesterday; as your last message there is from december, I thought I do it here instead. We've been using the patch for a few months now. Is there something I can help to progress this faster? Thanks for the effort Aiyion On 9/15/21 03:09, Leonardo Mörlein wrote: [...] ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
