When fstools is unable to parse our root=<...> arg correctly, it can
fall back to scanning all block devices for a 'rootfs_data' partition.
This fallback was deemed wrong (or at least, a breaking/incompatible
change) for some targets, so we're forced to opt back into it with
On Tue, Jan 24, 2023 at 10:28:14PM -0800, Brian Norris wrote:
> We want to return NULL if the param does *not* match 1 -- i.e., a
> non-zero strcmp().
>
> Fixes: 1ea5855e980c ("partname: Introduce fstools_partname_fallback_scan
> option")
Hmm, sorry for the quick self-reply, but after
We want to return NULL if the param does *not* match 1 -- i.e., a
non-zero strcmp().
Fixes: 1ea5855e980c ("partname: Introduce fstools_partname_fallback_scan
option")
Signed-off-by: Brian Norris
---
libfstools/partname.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 1/24/23 18:08, Koen Vandeputte wrote:
Hi,
I think our previous mails overlapped a bit as I didn't notice your
previous response :)
I'll send the data tomorrow.
I'm also wondering if adding a sleep before ubiformat in the old way
would influence/break it's behaviour?
possibly yes
Hi Koen,
On 24.01.2023 22:08, Koen Vandeputte wrote:
[...]
Piotr,
Would you have any idea here?
Not really, very strange.
What makes me wondering is that it doesn't look like a h/w related thing
(e.g. watchdog fire or some sudden current consumption spike resulting
in reset) and more
On Tue, Jan 24, 2023 at 9:46 PM Lanchon wrote:
>
>
>
> On 1/24/23 17:35, Lanchon wrote:
> >
> >
> > On 1/24/23 13:25, Koen Vandeputte wrote:
> >> On Tue, Jan 24, 2023 at 4:26 PM Koen Vandeputte
> >> wrote:
> >>> On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote:
> hi Koen, thanks again.
>
On 1/24/23 17:35, Lanchon wrote:
On 1/24/23 13:25, Koen Vandeputte wrote:
On Tue, Jan 24, 2023 at 4:26 PM Koen Vandeputte
wrote:
On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote:
hi Koen, thanks again.
i copied your log here for ease of reference:
On 1/24/23 13:25, Koen Vandeputte wrote:
On Tue, Jan 24, 2023 at 4:26 PM Koen Vandeputte
wrote:
On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote:
hi Koen, thanks again.
i copied your log here for ease of reference:
https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db
first let
I have been trying to characterize a very difficult bug in the ac and
ax support on a new mt76 product, where
for mu-mimo and related, it seems to be generating an invalid or
flipped mac address on small (but not large) packets, eventually
getting through.
This shows up in my flent data as huge
As far as I know, device support can be backported from master into the
release branch. So you are able to add the device support if a release
already happened.
Bests
Nick
On 1/24/23 20:56, Peter Naulls wrote:
On 1/24/23 14:48, Nick wrote:
Hey,
We have testing-support for 5.15 in almost all
On 1/24/23 14:48, Nick wrote:
Hey,
We have testing-support for 5.15 in almost all targets, so we may be able to
release it shortly [0]? WIP 6.1 support is already underway in OpenWrt [1]. We
are using GCC 12 as our default compiler version[2]. Binutils has been updated
to version 2.40. Could
Hey,
We have testing-support for 5.15 in almost all targets, so we may be
able to release it shortly [0]? WIP 6.1 support is already underway in
OpenWrt [1]. We are using GCC 12 as our default compiler version[2].
Binutils has been updated to version 2.40. Could we fill out the Release
Goals
When there's no network cable connected to LAN, then odhcpd does this:
Tue Jan 24 18:32:04 2023 daemon.err odhcpd[2017]: Failed to send to
ff02::1%lan@br-lan (Address not available)
Tue Jan 24 18:32:20 2023 daemon.err odhcpd[2017]: Failed to send to
ff02::1%lan@br-lan (Address not available)
On Tue, Jan 24, 2023 at 5:49 PM wrote:
>
> On 24.01.2023 17:13, Lanchon wrote:
> > the problem lies elsewhere: on your platform something is rebooting the
> > system asynchronously while it is updating. this is very dangerous and must
> > be fixed elsewhere in code.
>
> just a wild guess.
On 24.01.2023 17:13, Lanchon wrote:
the problem lies elsewhere: on your platform something is rebooting the system
asynchronously while it is updating. this is very dangerous and must be fixed
elsewhere in code.
just a wild guess. faulty power supplies sometimes lead to reboots if the power
On Tue, Jan 24, 2023 at 4:26 PM Koen Vandeputte
wrote:
>
> On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote:
> >
> > hi Koen, thanks again.
> >
> > i copied your log here for ease of reference:
> > https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db
> >
> >
> > first let me say:
> >
>
On 1/24/23 12:26, Koen Vandeputte wrote:
On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote:
hi Koen, thanks again.
i copied your log here for ease of reference:
https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db
first let me say:
- ubinized sysupgrade is not used by any of my
From: Tomasz Maciej Nowak
Some packages offer functionalities guarded by these options and it'll
be impossible to reach them without changing Config-build.in. So allow
to toggle these in more friendly way, by exposing them in configuration
menu.
Signed-off-by: Tomasz Maciej Nowak
---
On Tue, Jan 24, 2023 at 7:59 AM Lanchon wrote:
>
> hi Koen, thanks again.
>
> i copied your log here for ease of reference:
> https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db
>
>
> first let me say:
>
> - ubinized sysupgrade is not used by any of my devices.
>
> - ubinized
19 matches
Mail list logo
