On Wed, May 13, 2020 at 6:29 PM Philip Prindeville <
philipp_s...@redfish-solutions.com> wrote:
>
> My lights-out machine rooms all have a dialup line, a terminal server, and
> a power strip where I can cycle outlets… because I don’t like driving 7
> hours each way for 1 hour of productive work.
>
> [snip]
>
> (2) If the box is in an indeterminate state then it’s not always clear that
> there’s a safe path forward, and sometimes this is something that a human
> needs to ascertain.
>
> There's no human that can ascertain anything. The board that is being
> upgraded is being upgraded f
>
> How the entire upgrade process works would be a good subject for
> documenting on the Wiki if it’s not already.
>
Feel free :-)
> How long are you thinking this I/O will take to complete?
>
Longer than the blazing speed of /bin/sh looping over /proc/*
(1) It shouldn’t be happening very of
> On May 13, 2020, at 1:41 PM, John Clark via openwrt-devel
> wrote:
>
> I’ve never had this problem with ‘reboot’, but there doesn’t seem to be a
> really nice way to ‘reboot into a firmware upgrade initram image’, do the
> work, then reboot with new firmware.
kexec?
_
> On May 13, 2020, at 11:59 AM, Michael Jones wrote:
>
> E.g. if /lib/upgrade/script2 has returned, at all, the system needs to
> reboot, because at this point /sbin/upgraded should be the only process
> running.
>
> if /lib/upgrade/script2 has not returned after 1 hour, there's no chance th
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Hauke Mehrtens
> Sent: Mittwoch, 13. Mai 2020 23:42
> To: openwrt-devel@lists.openwrt.org
> Cc: Hauke Mehrtens ; Tobias Schramm
>
> Subject: [OpenWrt-Devel] [PATCH] ath79: Fix ubnt_ed
Inline...
> On May 12, 2020, at 11:17 PM, Michael Jones wrote:
>
> I've been investigating a problem with sysupgrade failing with the error
> message "Failed to kill all processes", and then hanging indefinitely.
>
> This happens maybe once every 10-20 sysupgrades, and it's kind of a pain.
>
switch-bcm53xx-mdio does not exists, use kmod-switch-bcm53xx-mdio
instead.
Signed-off-by: Hauke Mehrtens
Cc: Tobias Schramm
---
target/linux/ath79/image/generic-ubnt.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/a
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
> > --
From: Philip Prindeville
Make sure no buffer overruns present a vulnerability in the firewall.
Get rid of unsafe string functions: strcpy, strncpy, strcat, strncat,
sprintf, etc. Doing pointer arithemetic with the return value of
sprintf() is inherently unsound. Per the sprintf() man page:
śr., 13 maj 2020 o 21:19 Matthias Schiffer
napisał(a):
>
> 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
> (a
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 ---
> On May 12, 2020, at 10:17 PM,
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 ---
> On May 12, 2020, at 10:17 PM,
Signed-off-by: Matthias Schiffer
---
tools/zstd/Makefile | 20 ++
...re-portable-header-prefix-usage-1987.patch | 61 +++
2 files changed, 81 insertions(+)
create mode 100644 tools/zstd/Makefile
create mode 100644
tools/zstd/patches/0001-build-issu
We are looking into enabling CONFIG_COLLECT_KERNEL_DEBUG by default for
Gluona [1], but at the moment the increase in build time is prohibitive
for a fast development cycle: the bzip2 compression takes 18s on my
notebook, 15s on a more powerful machine - more than 10% of the total
incremental buil
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
otherw
On Wed, May 13, 2020 at 1:53 PM Eric Romano wrote:
> It does seem like process supervision would be a nice capability to
> have within procd.
>
> Previously I've done this by a combination of:
> 1. trying to crash / exit the process when an inconsistent state is hit.
> 2. monitoring for delayed w
It does seem like process supervision would be a nice capability to
have within procd.
Previously I've done this by a combination of:
1. trying to crash / exit the process when an inconsistent state is hit.
2. monitoring for delayed writes to a timestamp pidfile in temp.
procd's respawn directive
On Wed, May 13, 2020 at 12:29 PM Michael Jones
wrote:
>
>
> On Wed, May 13, 2020 at 3:58 AM Jo-Philipp Wich wrote:
>
>> Hi,
>>
>>
> Stuff like umounting external disks, fsync / swapoff etc. come to mind as
>> well
>> which should be doable at this point.
>>
>>
>>
> Right, that's also feasible.
>
I have a critical service on my OpenWRT system that needs monitoring and
re-starting if it's failed.
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.
It seems to me like this
On Wed, May 13, 2020 at 3:58 AM Jo-Philipp Wich wrote:
> Hi,
>
> >
> > That loop-kill-all thing should be a kind of last resort really,
> what's
> > actually needed is some kind of "init 1" procd equivalent which
> shuts down all
> > services in a more or less clean manner.
> >
> >
>
On Wed, May 13, 2020 at 4:42 AM Kevin 'ldir' Darbyshire-Bryant <
l...@darbyshire-bryant.me.uk> wrote:
>
>
> > On 13 May 2020, at 09:57, Jo-Philipp Wich wrote:
> >
> > Hi,
> >
> >>
> >>That loop-kill-all thing should be a kind of last resort really,
> what's
> >>actually needed is some kin
On Wed, May 13, 2020 at 03:19:32PM +0100, Daniel Golle wrote:
> On Wed, May 13, 2020 at 04:01:03PM +0300, Jouni Malinen wrote:
> > On Wed, May 13, 2020 at 11:46:03AM +0100, Daniel Golle wrote:
> > > The build environment is currently on an otherwise unused system wired
> > > up to the two QCA devic
On Wed, May 13, 2020 at 04:01:03PM +0300, Jouni Malinen wrote:
> On Wed, May 13, 2020 at 11:46:03AM +0100, Daniel Golle wrote:
> > Odd, but could be endian or sizeof(int) related differences. I assume
> > you are testing on x86_64 glibc while I'm testing this on MIPS24kc
> > (big endian!) with musl
This drops some ancient kernel version switches from patches on
bcm27xx target. The patch only adjusts the latest kernel 5.4, as
doing it a second time for an older kernel seems a waste of time
for a cosmetic change.
Refresh remaining target patches.
Signed-off-by: Adrian Schmutzler
---
.../950
This drops some ancient kernel version switches from patches on
lantiq target. The patch only adjusts the latest kernel 5.4, as
doing it a second time for an older kernel seems a waste of time
for a cosmetic change.
Signed-off-by: Adrian Schmutzler
---
.../0001-MIPS-lantiq-add-pcie-driver.patch
This drops kernel version switches for versions not supported by
OpenWrt master at the moment. This only adjusts local code, but
doesn't touch patches to existing external packages.
Signed-off-by: Adrian Schmutzler
---
.../kernel/gpio-nct5104d/src/gpio-nct5104d.c | 22 --
.../ltq-adsl-m
This drops the obsolete version switches for non-supported kernels
from local drivers in generic target.
Signed-off-by: Adrian Schmutzler
---
.../drivers/mtd/mtdsplit/mtdsplit_uimage.c| 20 ---
.../files/drivers/net/phy/b53/b53_priv.h | 7 +--
.../generic/files/driv
On Wed, May 13, 2020 at 11:46:03AM +0100, Daniel Golle wrote:
> Odd, but could be endian or sizeof(int) related differences. I assume
> you are testing on x86_64 glibc while I'm testing this on MIPS24kc
> (big endian!) with musl libc running on QCA SoCs.
Unfortunately, I don't have any convenient
Hi Jouni,
thanks for the quick reply!
On Wed, May 13, 2020 at 11:38:17AM +0300, Jouni Malinen wrote:
> On Tue, May 12, 2020 at 10:46:12PM +0100, Daniel Golle wrote:
> > After hours of bisecting which change between hostapd_2_8 and
> > hostapd_2_9 broke SAE in mesh mode with WolfSSL we got a resul
> On 13 May 2020, at 09:57, Jo-Philipp Wich wrote:
>
> Hi,
>
>>
>>That loop-kill-all thing should be a kind of last resort really, what's
>>actually needed is some kind of "init 1" procd equivalent which shuts
>> down all
>>services in a more or less clean manner.
>>
Beware th
Hi,
>
> That loop-kill-all thing should be a kind of last resort really, what's
> actually needed is some kind of "init 1" procd equivalent which shuts
> down all
> services in a more or less clean manner.
>
>
> Oddly enough, the /lib/upgrade/stage2 script has some aspect of this.
On Tue, May 12, 2020 at 10:46:12PM +0100, Daniel Golle wrote:
> After hours of bisecting which change between hostapd_2_8 and
> hostapd_2_9 broke SAE in mesh mode with WolfSSL we got a result:
>
> > commit 6c9543fcb7962e26c2a91c43089abe171d073b44
> > Author: Jouni Malinen
> > Date: Thu Apr 25 2
> That loop-kill-all thing should be a kind of last resort really, what's
> actually needed is some kind of "init 1" procd equivalent which shuts down
> all
> services in a more or less clean manner.
>
>
Oddly enough, the /lib/upgrade/stage2 script has some aspect of this. It
explicitly shuts down
Hi Michael,
> [...]
>
> Now that the very rough summary is out of the way, I have 4 questions.
>
> 1) I notice that the shell script /lib/upgrade/stage2 is doing a tight loop
> with kill -9 to terminate processes. However, it's only looping a maximum of
> 10 times, and its going as fast as the s
35 matches
Mail list logo
