[OpenWrt-Devel] Upgraded to 19.07.2 and my file shares disappeared
Hello, I feel that this really needs to be added to either the Samba setup documentation and/or the storage documentation: *Enable also anon_mount in your /etc/config/fstab* submitted by* hnyman* at https://forum.openwrt.org/t/mounting-usb-block-info-block-detect-not-able-to-see-exfat-solved/1244/10 After upgrading and reinstalling the necessary packages to get my USB connected SSD drive recognized my data was no where to be found. gdisk reported a missing gpt header which it fixed (q - without saving any changes in a panic) And in Lede under mount points a weirdly sized partition was reported with no used space at all (my panic greatly increased) I had not made a back-up of my partition table, something I have taken care of now. As I morosely read the man-page for gdisk and how to repair a partition and tried a few things without saving the changes, nothing continued to be found. I stumbled across the above change to fstab in bold. I crossed my fingers, made the change, saved and rebooted *Everything is back,* nothing missing and nothing corrupted. I realize that my problem is probably self-caused in how I setup my samba shares in the first place. In my defense all I did was follow the instructions in the OpenWRT documentation pages regarding: USB storage and Samba fileshares. Sincerely, David B. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] build: compress kernel debuginfo using zstd
Could we use that for the SDK/ImageBuilder as well? Best, Paul -- May 13, 2020 9:20:39 AM Matthias Schiffer : zstd with its default settings (compression level -3) compresses better than bzip2 -9 (which is the default setting), and is an order of magnitude faster. I made the following measurements for the most common compression tools (all standard Debian Buster versions, default flags unless noted otherwise), using the debug information of a large x86-64 kernel with ALL_KMODS: * kernel-debug.tar: 376M * kernel-debug.tar.gz: 101M, compressed in ~12s * kernel-debug.tar.bz2: 91M, compressed in ~15s * kernel-debug.tar.xz: 57M, compressed in ~101s * kernel-debug.tar.zst: 86M, compressed in ~1s With zstd, there is still some room for improvement by increasing the compression, but the slight increase in compression ratio (22.83% -> 19.46%) does not justify the significant increase in compression time (about 5 times on my machine) in my opinion. Note that multithreaded compression (-T argument) does not affect reproducibility with zstd. Signed-off-by: Matthias Schiffer --- include/kernel-build.mk | 2 +- tools/Makefile | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/include/kernel-build.mk b/include/kernel-build.mk index c371e78ab9b0..32c91a5b8359 100644 --- a/include/kernel-build.mk +++ b/include/kernel-build.mk @@ -70,7 +70,7 @@ ifdef CONFIG_COLLECT_KERNEL_DEBUG $(FIND) $(KERNEL_BUILD_DIR)/debug -type f | $(XARGS) $(KERNEL_CROSS)strip --only-keep-debug $(TAR) c -C $(KERNEL_BUILD_DIR) debug \ $(if $(SOURCE_DATE_EPOCH),--mtime="@$(SOURCE_DATE_EPOCH)") \ - | bzip2 -c -9 > $(BIN_DIR)/kernel-debug.tar.bz2 + | zstd -T0 -f -o $(BIN_DIR)/kernel-debug.tar.zst endef endif diff --git a/tools/Makefile b/tools/Makefile index 02556d4b83f3..169f36c5bb69 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -37,6 +37,7 @@ tools-y += lzma squashfskit4 zip tools-$(BUILD_B43_TOOLS) += b43-tools tools-$(BUILD_ISL) += isl tools-$(CONFIG_USE_SPARSE) += sparse +tools-$(CONFIG_COLLECT_KERNEL_DEBUG) += zstd tools-$(CONFIG_TARGET_apm821xx)$(CONFIG_TARGET_gemini) += genext2fs tools-$(CONFIG_TARGET_tegra) += cbootimage cbootimage-configs -- 2.26.2 ___ 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
Re: [OpenWrt-Devel] [PATCH v2 1/1] firewall3: harden string functions that might overflow
So that I may craft the rewrite appropriately, it would help to know what your objection to strlcpy() is. Sent from my iPhone > On May 14, 2020, at 7:24 PM, Philip Prindeville > wrote: > > What should I use instead of strlcpy or strcpy? > > Sent from my iPhone > >> On May 14, 2020, at 11:04 AM, Jo-Philipp Wich wrote: >> >> Hi, >> >> the sprintf() to snprintf() changes are fine to me. Please omit the >> conversions to strlcpy() and please don't use fmemopen(). >> >> ~ Jo >> >> ___ >> 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
Re: [OpenWrt-Devel] Quectel RM500Q failing to get ip address assignment with netifd and modemmanager
On Wed, 13 May 2020 16:33:57 -0500 Alex Ballmer wrote: > On Tue, 12 May 2020 10:41:36 +0200 > Aleksander Morgado wrote: > > > Hey, > > > > > > > > root@localhost:~# mmcli -b 2 > > > > > > General| dbus path: > > > /org/freedesktop/ModemManager1/Bearer/2 > > > | type: default > > > > > > Status | connected: yes > > > | suspended: no > > > | interface: wwan0 > > > | ip timeout: 20 > > > > > > Properties |roaming: allowed > > > > > > IPv4 configuration | method: dhcp > > > > This is the issue here. It shouldn't say DHCP, it should say > > "static", because the WWAN network interface of all the new 5G > > modules are always in raw-ip instead of 802.3, and therefore MM > > should fallback to request static IP addressing instead of DHCP. > > > > Please try to backport the following fix: > > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/commit/a8fd33ebaa80a0844c375fdb39173736d18f71cb > > > > I really haven't spent much time backporting 5G related fixes to the > > 1.12 branch, because they will all be released together in 1.14 > > soon. > > > > I found it easier to switch my own setup to use the libqmi master > branch and modemmanager from the commit you mentioned. It works just > fine so far, wwan0 gets the correct address and the modem can ping > fine now. > > I attached the makefiles and patches I used for my openwrt build if > anyone needs them. In order to build the master branch, I also needed > to add > > https://github.com/autoconf-archive/autoconf-archive > > as a build dependency. I have another quick question about modemmanager support for the Quectel RM500Q. The commit a8fd33ebaa80a0844c375fdb39173736d18f71cb on the modemmanager git isn't in the current release. Will it be slated for the next release, and if so is there a rough time estimate as to when that will be? Thanks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ubus based service watchdog?
On Thu, May 14, 2020 at 5:56 PM Wes Turner wrote: > FWIW, k8s has Liveness, Readiness and Startup Probes > > https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/ > :: > > > The kubelet uses startup probes to know when a container application has > started. If such a probe is configured, it disables liveness and readiness > checks until it succeeds, making sure those probes don’t interfere with the > application startup. This can be used to adopt liveness checks on slow > starting containers, avoiding them getting killed by the kubelet before > they are up and running. > > Good suggestion. It's starting to look like people like the idea of having procd poke the service and require a reply, instead of the other way around. That's fine with me. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ubus based service watchdog?
On Fri, May 15, 2020 at 9:57 AM Henrique de Moraes Holschuh wrote: > On 15/05/2020 03:58, Petr Štetiar wrote: > > In other words I think, that one can solve this use case with current > > solutions, no need to bloat procd. > > And if you're going to bloat procd, it pays to look at what the > equivalent systemd functionality provides (it has a per-service > application-aware watchdog and a > please-wait-a-bit-more-I-am-doing-a-clean-shutdown API), to better know > the problem space. > > I have a mild objection to the quick jump to the word "bloat", which I've observed used on this list frequently That being said, yes, I'm a heavy user of the systemd watchdog functionality, and is part of the reason why I want to add this to procd. Thank you for making sure this aspect of service management was brought to the list's attention though. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ubus based service watchdog?
On Fri, May 15, 2020 at 4:35 AM Petr Štetiar wrote: > Michael Jones [2020-05-15 02:39:52]: > > > What's wrong with monit is that it's documentation is gigantic > > Good documentation with a lot of examples is hardly a problem, its a bonus > point for me. > > I think you misunderstood. Monit has a massive feature surface. I'm not even going to consider it, it goes far far beyond the level of capability that's appropriate for my use case. > > for a relatively trivial need. > > Your need, your current trivial use case. Overall project > goals/design/universe should be taken into account. > Sure, accept the patch or don't. I'm happy to take guidance from the OpenWRT community, but ultimately will implement the things I need the way I need them. Designing patches so that they are palatable to OpenWRT is a secondary concern. Once I have it working to the level that I'm happy with, the patch will be provided under the appropriate license, and then it's not my problem beyond helping serious efforts at integrating it. > If ubus is failing, there's a much larger problem than my service failing. > > And you don't want to recover from this even more critical situation? > If UBus fails, there's not a realistic recovery option beyond restarting the system, I'd rather that be PID 1's responsibility as well. > This requires that my program be able to communicate with ubus natively > and > > offer a ubus endpoint that can be queried. > > Then use file, socket or whatever suits your use case. > Of course, I will do what suits my use case. In this situation, the use case is that I want service monitoring built into the daemon that manages services. I was responding to your suggestion of advertising a status string on ubus, and explaining why that's not viable. > More complicated than a simple timer in procd. > > Which is not flexible enough, tailored exactly to your very simple use > case. > Perfect is the enemy of the good. My proposal is very simple, and very flexible. It's not literally as flexible as it possibly can be while simultaneously having no negatives, but no solution is. > It's hardly bloat. > > Just take a look one step further. Once OpenWrt accepts this feature its > official. What is going to happen afterwards in the OpenWrt universe? > > Folks will of course start using this feature, adding support for this > feature > into their critical services (take your answer to ISC dhcp support as > example), which would in most cases mean local patch(es) as this feature > could > be hardly upstreamed. > Lots of projects accept patches for specific init system features. If systemd specific patches can be upstreamed, so can procd patches. Also consider that OpenWRT already has patches for lots of programs to communicate over ubus. Are you insinuating that those patches are undesirable? This is the cost that comes with maintaining your own set of system services that no other project family uses. You don't see procd used in desktop distributions, or cellphones, or "infotainment" systems in cars, etc. (That I'm aware of, I'm happy to be corrected). Custom tools require customization to things. Procd does not have the feature set that I require for my purposes. I am happy with other parts of the OpenWRT ecosystem, so instead of switching to a different distribution, I'm open to making contributions so everyone can benefit. So in the end, we're going to have not so trivial amount of local patches > for > ubus service watchdog support, which would break DRY principle, Hardly. Each package is different, so the decision making logic to communicate with a service watchdog will be different. At worst, you have 10-20 lines of code duplicated per package, and that'll be whatever quantity of boilerplate communicating with UBus requires. > and probably result in additional maintenance/QA work with every package > version bump. > Trade off between additional reliability and code complexity. It's a tale as old as software. > In order to avoid this bloat, unnecessary patch hell, one would perhaps > need > to implement kind of monit/cron solution in procd/umonitd, so it would be > possible to have custom/generic service liveliness checks defined in the > service init scripts or UCI configuration. > > Maybe all is needed is some kind of monitrc generator from UCI configs/init > scripts? > Your counter proposal to a (estimated) 200-300 lines of code patch in procd, which could even be a compile-time-option, is to have services depend on a package that has more features than I know what to do with? How is monit going to work with procd's jails? The whole point of the jails is to isolate services into their own mini-container type thing. So now we have to poke a hole in the jail to allow monit to monitor the service? And monit isn't some magical drop-in solution. Imagine a service that doesn't already have a strong indicator of "liveness". Now that program needs to be patched for compatibility with monit, j
Re: [OpenWrt-Devel] Ubus based service watchdog?
On 15/05/2020 03:58, Petr Štetiar wrote: In other words I think, that one can solve this use case with current solutions, no need to bloat procd. And if you're going to bloat procd, it pays to look at what the equivalent systemd functionality provides (it has a per-service application-aware watchdog and a please-wait-a-bit-more-I-am-doing-a-clean-shutdown API), to better know the problem space. -- Henrique de Moraes Holschuh ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ubus based service watchdog?
Michael Jones [2020-05-15 02:39:52]: > What's wrong with monit is that it's documentation is gigantic Good documentation with a lot of examples is hardly a problem, its a bonus point for me. > for a relatively trivial need. Your need, your current trivial use case. Overall project goals/design/universe should be taken into account. > If ubus is failing, there's a much larger problem than my service failing. And you don't want to recover from this even more critical situation? > This requires that my program be able to communicate with ubus natively and > offer a ubus endpoint that can be queried. Then use file, socket or whatever suits your use case. > More complicated than a simple timer in procd. Which is not flexible enough, tailored exactly to your very simple use case. > It's hardly bloat. Just take a look one step further. Once OpenWrt accepts this feature its official. What is going to happen afterwards in the OpenWrt universe? Folks will of course start using this feature, adding support for this feature into their critical services (take your answer to ISC dhcp support as example), which would in most cases mean local patch(es) as this feature could be hardly upstreamed. So in the end, we're going to have not so trivial amount of local patches for ubus service watchdog support, which would break DRY principle, and probably result in additional maintenance/QA work with every package version bump. In order to avoid this bloat, unnecessary patch hell, one would perhaps need to implement kind of monit/cron solution in procd/umonitd, so it would be possible to have custom/generic service liveliness checks defined in the service init scripts or UCI configuration. Maybe all is needed is some kind of monitrc generator from UCI configs/init scripts? -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ubus based service watchdog?
On Fri, May 15, 2020 at 1:58 AM Petr Štetiar wrote: > Michael Jones [2020-05-13 12:48:49]: > > Hi, > > > I have a critical service on my OpenWRT system that needs monitoring and > > re-starting if it's failed. > > whats wrong with monit[1]? It was designed exactly for this purpose and is > much more flexible. > > What's wrong with monit is that it's documentation is gigantic for a relatively trivial need. This disqualifies it as being designed exactly for the purpose. > > I've been looking for a mechanism in procd that would allow me to request > > that my service be terminated if it did not periodically notify some > > watchdog endpoint via ubus. > > So instead of proper error handling and crashing your service ASAP, you're > now > going to add another ubus layer which might possibly fail as well. If ubus is failing, there's a much larger problem than my service failing. > You know, your service could happily ping the watchdog endpoint, yet still > fail in other > parts. You want something more robust. > Ubus would only be pinged when the service does the thing it's designed to do. In this case, there'll be some communication with the internet that involves bi-directional communication. No risk of false positives. > > I would simply add ubus status method to that critical service, This requires that my program be able to communicate with ubus natively and offer a ubus endpoint that can be queried. UBus is fundamentally incompatible with programs that have their own event loop. Or was, last I investigated. I have not had time to dig into ubox to make the necessary improvements to allow external loop drivers. Having the program being managed call "ubus call service.$servicename.watchdog " in whatever way it wants to is more flexible. All programs can launch sub processes, even if they have to resort to fork+exec. > then check the > output in the cron shell/Lua script and kill the service if the output of > the > ubus status method wouldnt match liveliness for that service. > More complicated than a simple timer in procd. > In other words I think, that one can solve this use case with current > solutions, no need to bloat procd. > > It's hardly bloat. It's a very simple feature that serves a core need in service management as a generic concern. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
