[PATCH fstools v2] partname: Correct fstools_partname_fallback_scan comparison
Commit 1ea5855e980c ("partname: Introduce fstools_partname_fallback_scan
option") had two problems:
1. The strcmp() aborted when the param *matched* 1; we wanted the
inverse
2. It was too aggressive about skipping the fallback behavior. For
devices that had no root= parameter, they would always attempt the
fallback scan.
Fix both of those.
Fixes: 1ea5855e980c ("partname: Introduce fstools_partname_fallback_scan
option")
Signed-off-by: Brian Norris
---
Changes in v2:
* Also restore the pre-1ea5855e980c fallback behavior when no root= is
provided
libfstools/partname.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/libfstools/partname.c b/libfstools/partname.c
index f42322a49d5b..004b249a7fdb 100644
--- a/libfstools/partname.c
+++ b/libfstools/partname.c
@@ -121,6 +121,8 @@ static struct volume *partname_volume_find(char *name)
char *rootdev = NULL, *devname, *tmp;
int j;
bool found = false;
+ bool allow_fallback = false;
+ bool has_root = false;
glob_t gl;
if (get_var_from_file("/proc/cmdline", "fstools_ignore_partname",
rootparam, sizeof(rootparam))) {
@@ -128,24 +130,29 @@ static struct volume *partname_volume_find(char *name)
return NULL;
}
- if (get_var_from_file("/proc/cmdline", "root", rootparam,
sizeof(rootparam)) && rootparam[0] == '/') {
+ /*
+* Some device may contains a GPT partition named rootfs_data that may
not be suitable.
+* To save from regression with old implementation that doesn't use
fstools_ignore_partname to
+* explicitly say that that partname scan should be ignored, make
explicit that scanning each
+* partition should be done by providing
fstools_partname_fallback_scan=1 and skip partname scan
+* in every other case.
+*/
+ if (get_var_from_file("/proc/cmdline",
"fstools_partname_fallback_scan", rootparam, sizeof(rootparam))) {
+ if (!strcmp("1", rootparam))
+ allow_fallback = true;
+ }
+
+ if (get_var_from_file("/proc/cmdline", "root", rootparam,
sizeof(rootparam)))
+ has_root = true;
+
+ if (has_root && rootparam[0] == '/') {
rootdev = rootdevname(rootparam);
/* find partition on same device as rootfs */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/%s/*/uevent",
block_dir_name, rootdev);
} else {
- /*
-* Some device may contains a GPT partition named rootfs_data
that may not be suitable.
-* To save from regression with old implementation that doesn't
use fstools_ignore_partname to
-* explicitly say that that parname scan should be ignored,
make explicit that scanning each
-* partition should be done by providing
fstools_partname_fallback_scan=1 and skip partname scan
-* in every other case.
-*/
- if (!get_var_from_file("/proc/cmdline",
"fstools_partname_fallback_scan", rootparam, sizeof(rootparam)))
+ /* For compatibility, devices with root= params must explicitly
opt into this fallback. */
+ if (has_root && !allow_fallback)
return NULL;
-
- if (!strcmp("1", rootparam))
- return NULL;
-
/* no useful 'root=' kernel cmdline parameter, find on any
block device */
snprintf(ueventgstr, sizeof(ueventgstr), "%s/*/uevent",
block_dir_name);
}
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH fstools] partname: Correct fstools_partname_fallback_scan comparison
On Tue, Jan 24, 2023 at 10:40:26PM -0800, Brian Norris wrote:
> 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 rereading, I noticed
> there's a second reason commit 1ea5855e980c may be incorrect:
>
> This fallback *used* to (pre-1ea5855e980c) be used for any block device
> (eMMC, SATA, etc.) where we *didn't* specify root= in the boot args.
> This could perhaps happen with initramfs systems? (Sorry, I'm not
> extremely familiar with the openwrt ecosystem.)
>
> So do we need to refactor this again, so that we allow the fallback in
> either (or both) of these cases:
>
> (1) no root= arg
> (2) root= (where XXX is not a /device/path) +
> fstools_partname_fallback_scan=1
>
> ?
>
> Anyway, it's probably at least safe to apply my bugfix, but we might
> need more.
>
Hi, you are right but in theory it should not be that hard to rework...
We surely need to handle the case with no root arg.
> > Signed-off-by: Brian Norris
> > ---
> >
> > libfstools/partname.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libfstools/partname.c b/libfstools/partname.c
> > index f42322a49d5b..82c723c02097 100644
> > --- a/libfstools/partname.c
> > +++ b/libfstools/partname.c
> > @@ -143,7 +143,7 @@ static struct volume *partname_volume_find(char *name)
> > if (!get_var_from_file("/proc/cmdline",
> > "fstools_partname_fallback_scan", rootparam, sizeof(rootparam)))
> > return NULL;
> >
> > - if (!strcmp("1", rootparam))
> > + if (strcmp("1", rootparam))
> > return NULL;
> >
> > /* no useful 'root=' kernel cmdline parameter, find on any
> > block device */
> > --
> > 2.39.0
> >
--
Ansuel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: elfutils build failure
On Wed, Jan 25, 2023 at 1:27 PM Peter Naulls wrote: > > > This is elfutils-0.188 in master. No doubt I'm using a bad toolchain combo - I > brought the config over from my 22.03 build: > > CONFIG_GCC_VERSION="11.3.0" > CONFIG_BINUTILS_VERSION_2_38=y > > > > configure:3994: mipsel-openwrt-linux-musl-gcc -Os -pipe -mno-branch-likely > -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts -msoft-float > -mips16 -minterlink-mips16 > -fmacro-prefix-map=/home/peter/awc/openwrt-master/build_dir/target-mipsel_24kc_musl/elfutils-0.188=elfutils-0.188 > -Wformat -Werror=format-security -DPIC -fpic -fstack-protector-strong > -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -D_GNU_SOURCE -Wno-unused-result > -Wno-format-nonliteral -Wno-error=use-after-free > -I/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/usr/include > -I/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/include/fortify > -I/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/include > > -L/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/usr/lib > -L/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/lib > -DPIC -fpic > -specs=/home/peter/awc/openwrt-master/include/hardened-ld-pie.specs > -znow -zrelroconftest.c >&5 > cc1: error: '-Wno-error=use-after-free': no option '-Wuse-after-free' Related: https://github.com/openwrt/openwrt/issues/11837# > > ___ > 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
elfutils build failure
This is elfutils-0.188 in master. No doubt I'm using a bad toolchain combo - I brought the config over from my 22.03 build: CONFIG_GCC_VERSION="11.3.0" CONFIG_BINUTILS_VERSION_2_38=y configure:3994: mipsel-openwrt-linux-musl-gcc -Os -pipe -mno-branch-likely -mips32r2 -mtune=24kc -fno-caller-saves -fno-plt -fhonour-copts -msoft-float -mips16 -minterlink-mips16 -fmacro-prefix-map=/home/peter/awc/openwrt-master/build_dir/target-mipsel_24kc_musl/elfutils-0.188=elfutils-0.188 -Wformat -Werror=format-security -DPIC -fpic -fstack-protector-strong -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -D_GNU_SOURCE -Wno-unused-result -Wno-format-nonliteral -Wno-error=use-after-free -I/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/usr/include -I/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/include/fortify -I/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/include -L/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/usr/lib -L/home/peter/awc/openwrt-master/staging_dir/toolchain-mipsel_24kc_gcc-11.3.0_musl/lib -DPIC -fpic -specs=/home/peter/awc/openwrt-master/include/hardened-ld-pie.specs -znow -zrelroconftest.c >&5 cc1: error: '-Wno-error=use-after-free': no option '-Wuse-after-free' ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: sysupgrade broken on imx nand targets (and maybe others too)
On Tue, Jan 24, 2023 at 11:43 PM Lanchon wrote:
>
>
>
> 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
> >
> >
> > Piotr,
> > Would you have any idea here?
> >
> >
> > Thanks again for your efforts,
> >
> > Koen
>
>
> if your active watchdog device is /dev/MyWatchdog, then...
>
>
> just before the line:
>
> ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach
> -m "$mtdnum"
>
> you could add this to try disable the watchdog:
>
> echo -n V >/dev/MyWatchdog
>
>
> or else you could tickle the watchdog while flashing like this:
>
> ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - 2>&1 | tee
> /dev/MyWatchdog && ubiattach -m "$mtdnum"
>
> BUT... this is a hack, cause shell option pipefail would be needed to
> detect a failure of ubiformat then, as normally only the exit code of
> the last piped process gets returned from the pipe expression.
>
>
> so these are just tests, not fixes.
>
>
> another dirty thing you could do is doubling the watchdog timeout period
> for your platform. this at least could maybe be accepted as a stopgap
> band aid in the openwrt tree. but the race condition remains, and it
> will bite back sometime. a real fix for the race should be implemented.
>
> BTW your watchdog seems to be:
> https://www.kernelconfig.io/config_imx2_wdt
>
>
> thanks!
>
>
Hi all,
Hardware:
Gateworks Ventana gw5200, naked without any additional hardware attached.
Full normal bootlog:
https://pastebin.com/raw/nSBnrHxN
Watchdog info:
root@OpenWrt:~# ubus call system watchdog
{
"status": "running",
"timeout": 30,
"frequency": 5,
"magicclose": false
}
Normal reboot command issued as user after boot:
--> a reboot on Gateworks Ventana is handled by waking the watchdog
which triggers a GPIO, controlling a PMIC to reset power
[ 56.791836] br-wan: port 1(eth0) entered disabled state
[ 56.801236] device eth0 left promiscuous mode
[ 56.805828] br-wan: port 1(eth0) entered disabled state
* reboot command issued by me here *
crond[1416]: USER root pid 2191 cmd /usr/sbin/logrotate
/etc/logrotate/logrotate.conf > /var/log/logrotate.log
[ 61.139944] ci_hdrc ci_hdrc.1: remove, state 1
[ 61.144418] usb usb2: USB disconnect, device number 1
[ 61.150316] ci_hdrc ci_hdrc.1: USB bus 2 deregistered
[ 61.155792] ci_hdrc ci_hdrc.0: remove, state 1
[ 61.160257] usb usb1: USB disconnect, device number 1
[ 61.166336] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
[ 61.173094] imx2-wdt 20bc000.watchdog: Device shutdown: Expect reboot!
[ 61.179787] reboot: Restarting system
Full log sysupgrade failing: (cat ubifile | ubiformat -f -)
https://pastebin.com/raw/QPNbe49K
Time from sysupgrade-start to reboot --> 23.38 sec
Full log sysupgrade working: (ubiformat -f /tmp/ubifile)
https://pastebin.com/raw/qtSMnbDh
Time from sysupgrade-start to reboot --> 33.55 sec
Again ..
I'm NOT saying that feeding the ubi directly is a proper fix.
I'm saying that the watchdog itself seems NOT to be the cause.
It is used as a way to powercycle the board when a "reboot" command is issued.
According to me, somewhere during upgrade a 'reboot' command gets
triggered somewhere at a wrong time ..
Kind regards,
Koen
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
