Re: procd, possible hotplug issue?
On Wed, Feb 21, 2024 at 10:01:30PM +0100, e9hack wrote: > Am 21.02.2024 um 01:21 schrieb Daniel Golle: > > > > Yep, I didn't think about empty variables when I built this... > > > > Can you test this please: > > https://github.com/openwrt/procd/pull/3 > > > > This does fix the issue. > > If I test a modified executable, I replaced it by a link to a link on a > automatically mounted usb stick. The link on the usb stick points to the > modified executable. e.g.: > > /sbin/dnsmasq is renamed to /sbin/dnsmasq.old > /sbin/dnsmasq -> /mnt/test/dnsmasq/dnsmasq > /mnt/test/dnsmasq/dnsmasq -> /mnt/test/dnsmasq/dnsmasq-test-something > > If the modification bricks the router, I replace the last link on the usb > stick by > > /mnt/test/dnsmasq/dnsmasq -> /sbin/dnsmasq.old > > or > > /mnt/test/dnsmasq/dnsmasq -> /rom/sbin/dnsmasq > > and the router is operational again. > > This doesn't work for procd since procd is needed before the usb stick is > mounted. > > How can I do similar things for procd? There isn't any as convenient option, for the reason you named. When hacking on procd the qemu targets (malta, armvirt, x86) are very handy for testing and debugging. Once things work well there I move on to a "friendly" board (ie. with dualboot/recovery feature, serial console, pstore which is also good for PID 1 crashes, ...). > > Regards, > Hartmut > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH firmware-utils] ptgen: fix limitation for active partition in GPT
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
In GPT there is no reason to limit the active partition number to 4.
This limitation is only for MBR, as it corresponds to the maximum number
of primary partitions.
Signed-off-by: Thomas Richard
---
src/ptgen.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/src/ptgen.c b/src/ptgen.c
index b231c28..c7d6bc0 100644
--- a/src/ptgen.c
+++ b/src/ptgen.c
@@ -569,7 +569,7 @@ fail:
static void usage(char *prog)
{
fprintf(stderr, "Usage: %s [-v] [-n] [-g] -h -s -o
\n"
- " [-a 0..4] [-l ] [-G ]\n"
+ " [-a ] [-l ] [-G
]\n"
" [[-t | -T ] [-r] [-N
] -p [@]...] \n", prog);
exit(EXIT_FAILURE);
}
@@ -668,8 +668,6 @@ int main (int argc, char **argv)
break;
case 'a':
active = (int)strtoul(optarg, NULL, 0);
- if ((active < 0) || (active > 4))
- active = 0;
break;
case 'l':
kb_align = (int)strtoul(optarg, NULL, 0) * 2;
@@ -700,6 +698,11 @@ int main (int argc, char **argv)
if (argc || (!use_guid_partition_table && ((heads <= 0) || (sectors <=
0))) || !filename)
usage(argv[0]);
+ if ((use_guid_partition_table && active > GPT_ENTRY_MAX) ||
+ (!use_guid_partition_table && active > MBR_ENTRY_MAX) ||
+ active < 0)
+ active = 0;
+
if (use_guid_partition_table) {
heads = 254;
sectors = 63;
--
2.39.2
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
uhttpd fixes via github
Hello, There is a small fix for uhttpd pending in github. https://github.com/openwrt/uhttpd/pull/2 If github should not be used for that, it would be nice to have it explicitly mentioned in the github project or a Readme.md file. Regards, --- Luiz Angelo Daros de Luca luizl...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ubus running key status
On 2024-02-23 13:43, Ravi Paluri (QUIC) wrote: Can you let us know, is there a way to get a notification when the "running" key value moves to "false" from "true"? OR is there any ubus API to which we can register a callback, which will then be invoked when the execution is complete? Not certain about callbacks - but there is "ubus monitor" "ubus subscribe" "ubus listen" and "ubus wait_for" They're blocking calls, at least. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ubus running key status
Hi OpenWRT team,
We are working on ubus and running a script using ubus_invoke API.
We observed that when the script gets scheduled for execution and then later
once it completes execution, the "running" key value (see below command o/p) is
changing to "false" from "true".
ubus call service list '{"name":"servicemanager.init","verbose":"True"}'
{
"servicemanager.init": {
"instances": {
"instance1": {
"running": true,
"pid": 3690,
"command": [
"/usr/bin/servicemanager"
], }
}
}
Can you let us know, is there a way to get a notification when the "running"
key value moves to "false" from "true"?
OR is there any ubus API to which we can register a callback, which will then
be invoked when the execution is complete?
Thanks,
Ravi
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Linux kernel 6.1 or 6.6 for OpenWrt 24.x release?
Hi, I track the status of the Linux kernel 6.1 migration in this github issue:https://github.com/openwrt/openwrt/issues/14546 There are still many targets on kernel 5.15 without testing support for kernel 6.1 in OpenWrt master. I assume that we need at least 4 months to get everything to 6.1 and more or less stable. Kernel 6.1 support is also missing for some important targets like lantiq, realtek and ramips. Which kernel should we use for the next major OpenWrt release? We have two options and I would like to get some feedback on these: 1. Do the OpenWrt 24.X release with kernel 6.1. Branch off when all or most of the targets are on kernel 6.1 by default. 2. Do the OpenWrt 24.X release with kernel 6.6. Branch off when all or most of the targets are on kernel 6.6 by default. Do not do any stable OpenWrt release which supports kernel 6.1. Doing a OpenWrt release with multiple kernels cases too much maintenance effort from my point of view based on previews experience. I think with kernel 6.1 we can branch off at around May 2024. With kernel 6.6 we could probably branch off around September 2024. The final release will be out about 2 to 4 months later. Currently OpenWrt releases are about 1.5 years behind the Linux LTS releases. When we use kernel 6.1 for the next release we will continue to stay 1.5 years behind. When we switch to kernel 6.6 and do not do any release with kernel 6.1 we will probably only stay 10 months behind Linux LTS kernels. There is already a PR requiring kernel 6.6: https://github.com/openwrt/openwrt/pull/14357 Currently I would prefer to use kernel 6.6 to get closer to the recent Linux LTS releases. Hauke As a developer, having had to do the 5.15 to 6.1 migration, I was frustrated to see that 6.6 was about to be released and knew I had to do the same work + more _again_. So from a developers point of view, Being closer to mainline also means potentially fewer times doing the work. Also having a smaller gap is always much nicer. While I get that some people prefer to make smaller steps or what not, they often forget the amount of work these transitions can be. And while one can argue, 'but you have to do the same work anyway, just in smaller steps, it's also about time and focus. Spending an hour extra during a 2 hour session to make the step, is better then having to spend 2x 1 hour. So yes please, 6.6 asap :) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
