Re: [OpenWrt-Devel] [PATCH RFC procd] jail: add option to provide /dev/console to containers
Hi Daniel,
Le sam. 25 avr. 2020 à 19:48, Daniel Golle a écrit :
>
> Create UNIX/98 PTY, pass master fd to procd and setup mount-bind of
> slave PTS device on /dev/console inside jail.
> Allow attaching to an instance's console by using the newly introduced
> ujail-console command (no multiplexing for now).
Just curious how far you want to push ujail ?
ie do you want a docker lite / what features do you want to add ?
Regards
Etienne
>
> Signed-off-by: Daniel Golle
> ---
> CMakeLists.txt | 6 ++
> jail/console.c | 209 +
> jail/jail.c| 83 +-
> service/instance.c | 70 +++
> service/instance.h | 3 +
> service/service.c | 71 +++
> 6 files changed, 438 insertions(+), 4 deletions(-)
> create mode 100644 jail/console.c
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index cff47cf..3eb79f9 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -110,6 +110,12 @@ INSTALL(TARGETS ujail
> RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
> )
> ADD_DEPENDENCIES(ujail capabilities-names-h)
> +
> +ADD_EXECUTABLE(ujail-console jail/console.c)
> +TARGET_LINK_LIBRARIES(ujail-console ${ubox} ${ubus} ${blobmsg_json})
> +INSTALL(TARGETS ujail-console
> + RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
> +)
> endif()
>
> IF(UTRACE_SUPPORT)
> diff --git a/jail/console.c b/jail/console.c
> new file mode 100644
> index 000..75ce9c5
> --- /dev/null
> +++ b/jail/console.c
> @@ -0,0 +1,209 @@
> +/*
> + * Copyright (C) 2020 Daniel Golle
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU Lesser General Public License version 2.1
> + * as published by the Free Software Foundation
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static inline int setup_tios(int fd, struct termios *oldtios)
> +{
> + struct termios newtios;
> +
> + if (!isatty(fd)) {
> + return -1;
> + }
> +
> + /* Get current termios */
> + if (tcgetattr(fd, oldtios))
> + return -1;
> +
> + newtios = *oldtios;
> +
> + /* Remove the echo characters and signal reception, the echo
> +* will be done with master proxying */
> + newtios.c_iflag &= ~IGNBRK;
> + newtios.c_iflag &= BRKINT;
> + newtios.c_lflag &= ~(ECHO|ICANON|ISIG);
> + newtios.c_cc[VMIN] = 1;
> + newtios.c_cc[VTIME] = 0;
> +
> + /* Set new attributes */
> + if (tcsetattr(fd, TCSAFLUSH, ))
> + return -1;
> +
> + return 0;
> +}
> +
> +
> +
> +#define OPT_ARGS "i:s:"
> +
> +static struct ustream_fd cufd;
> +static struct ustream_fd lufd;
> +
> +static void usage()
> +{
> + fprintf(stderr, "ujail-console -s [-i ]\n");
> + exit(1);
> +}
> +
> +static void client_cb(struct ustream *s, int bytes)
> +{
> + char *buf;
> + int len, rv;
> +
> + do {
> + buf = ustream_get_read_buf(s, );
> + if (!buf)
> + break;
> +
> + rv = ustream_write(, buf, len, false);
> +
> + if (rv > 0)
> + ustream_consume(s, rv);
> +
> + if (rv <= len)
> + break;
> + } while(1);
> +}
> +
> +static void local_cb(struct ustream *s, int bytes)
> +{
> + char *buf;
> + int len, rv;
> +
> + do {
> + buf = ustream_get_read_buf(s, );
> + if (!buf)
> + break;
> +
> + if ((len > 0) && (buf[0] == 2))
> + uloop_end();
> +
> + rv = ustream_write(, buf, len, false);
> +
> + if (rv > 0)
> + ustream_consume(s, rv);
> +
> + if (rv <= len)
> + break;
> + } while(1);
> +}
> +
> +int main(int argc, char **argv)
> +{
> + struct ubus_context *ctx;
> + uint32_t id;
> + static struct blob_buf req;
> + char *service_name = NULL, *instance_name = NULL;
> + int client_fd, server_fd, tty_fd;
> + struct termios oldtermios;
> + int ch;
> +
> + while ((ch = getopt(argc, argv, OPT_ARGS)) != -1) {
> + switch (ch) {
> + case 'i':
> + instance_name = optarg;
> + break;
> + case 's':
> + service_name = optarg;
> + break;
> + default:
> + usage();
> + }
> + }
[OpenWrt-Devel] [PATCH RFC procd] jail: add option to provide /dev/console to containers
Create UNIX/98 PTY, pass master fd to procd and setup mount-bind of
slave PTS device on /dev/console inside jail.
Allow attaching to an instance's console by using the newly introduced
ujail-console command (no multiplexing for now).
Signed-off-by: Daniel Golle
---
CMakeLists.txt | 6 ++
jail/console.c | 209 +
jail/jail.c| 83 +-
service/instance.c | 70 +++
service/instance.h | 3 +
service/service.c | 71 +++
6 files changed, 438 insertions(+), 4 deletions(-)
create mode 100644 jail/console.c
diff --git a/CMakeLists.txt b/CMakeLists.txt
index cff47cf..3eb79f9 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -110,6 +110,12 @@ INSTALL(TARGETS ujail
RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
)
ADD_DEPENDENCIES(ujail capabilities-names-h)
+
+ADD_EXECUTABLE(ujail-console jail/console.c)
+TARGET_LINK_LIBRARIES(ujail-console ${ubox} ${ubus} ${blobmsg_json})
+INSTALL(TARGETS ujail-console
+ RUNTIME DESTINATION ${CMAKE_INSTALL_SBINDIR}
+)
endif()
IF(UTRACE_SUPPORT)
diff --git a/jail/console.c b/jail/console.c
new file mode 100644
index 000..75ce9c5
--- /dev/null
+++ b/jail/console.c
@@ -0,0 +1,209 @@
+/*
+ * Copyright (C) 2020 Daniel Golle
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU Lesser General Public License version 2.1
+ * as published by the Free Software Foundation
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static inline int setup_tios(int fd, struct termios *oldtios)
+{
+ struct termios newtios;
+
+ if (!isatty(fd)) {
+ return -1;
+ }
+
+ /* Get current termios */
+ if (tcgetattr(fd, oldtios))
+ return -1;
+
+ newtios = *oldtios;
+
+ /* Remove the echo characters and signal reception, the echo
+* will be done with master proxying */
+ newtios.c_iflag &= ~IGNBRK;
+ newtios.c_iflag &= BRKINT;
+ newtios.c_lflag &= ~(ECHO|ICANON|ISIG);
+ newtios.c_cc[VMIN] = 1;
+ newtios.c_cc[VTIME] = 0;
+
+ /* Set new attributes */
+ if (tcsetattr(fd, TCSAFLUSH, ))
+ return -1;
+
+ return 0;
+}
+
+
+
+#define OPT_ARGS "i:s:"
+
+static struct ustream_fd cufd;
+static struct ustream_fd lufd;
+
+static void usage()
+{
+ fprintf(stderr, "ujail-console -s [-i ]\n");
+ exit(1);
+}
+
+static void client_cb(struct ustream *s, int bytes)
+{
+ char *buf;
+ int len, rv;
+
+ do {
+ buf = ustream_get_read_buf(s, );
+ if (!buf)
+ break;
+
+ rv = ustream_write(, buf, len, false);
+
+ if (rv > 0)
+ ustream_consume(s, rv);
+
+ if (rv <= len)
+ break;
+ } while(1);
+}
+
+static void local_cb(struct ustream *s, int bytes)
+{
+ char *buf;
+ int len, rv;
+
+ do {
+ buf = ustream_get_read_buf(s, );
+ if (!buf)
+ break;
+
+ if ((len > 0) && (buf[0] == 2))
+ uloop_end();
+
+ rv = ustream_write(, buf, len, false);
+
+ if (rv > 0)
+ ustream_consume(s, rv);
+
+ if (rv <= len)
+ break;
+ } while(1);
+}
+
+int main(int argc, char **argv)
+{
+ struct ubus_context *ctx;
+ uint32_t id;
+ static struct blob_buf req;
+ char *service_name = NULL, *instance_name = NULL;
+ int client_fd, server_fd, tty_fd;
+ struct termios oldtermios;
+ int ch;
+
+ while ((ch = getopt(argc, argv, OPT_ARGS)) != -1) {
+ switch (ch) {
+ case 'i':
+ instance_name = optarg;
+ break;
+ case 's':
+ service_name = optarg;
+ break;
+ default:
+ usage();
+ }
+ }
+
+ if (!service_name)
+ usage();
+
+ ctx = ubus_connect(NULL);
+ if (!ctx) {
+ fprintf(stderr, "can't connect to ubus!\n");
+ return -1;
+ }
+
+ /* open pseudo-terminal pair */
+ client_fd = posix_openpt(O_RDWR | O_NOCTTY);
+ if (client_fd < 0) {
+ fprintf(stderr, "can't create virtual console!\n");
+ ubus_free(ctx);
+ return -1;
+ }
+ setup_tios(client_fd, );
+ grantpt(client_fd);
+
Re: [OpenWrt-Devel] [PATCH] x86: fix unusable squashfs images by adding missing padding
On Sat Apr 25, 2020 at 2:56 AM PST, Petr Štetiar wrote:
> It was reported, that after image generation rework
> x86-64-generic-squashfs-rootfs.img image won't boot on XenServer x86_64
> anymore:
>
> F2FS-fs (xvda): Magic Mismatch, valid(0xf2f52010) - read(0x84289960)
> F2FS-fs (xvda): Can't find valid F2FS filesystem in 1th superblock
> F2FS-fs (xvda): Magic Mismatch, valid(0xf2f52010) - read(0x4e8ee223)
> F2FS-fs (xvda): Can't find valid F2FS filesystem in 2th superblock
> List of all partitions:
> ca00 4207 xvda
> driver: vbd
> No filesystem could mount root, tried:
> ext3
> ext2
> ext4
> squashfs
> iso9660
> f2fs
>
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(202,0)
>
> So lets fix this by adding back padding which was introduced in commit
> a17d9482f5e2 ("x86: image: fix small disk space in squashfs overlay").
>
> Ref: FS#3036
> Cc: Paul Spooren
> Cc: Tomasz Maciej Nowak
> Fixes: 258f070d1a4f ("x86: fix missing squashfs and ext4 rootfs images")
> Fixes: cb007a7bf619 ("x86: switch image generation to new code")
> Signed-off-by: Petr Štetiar
> ---
> target/linux/x86/image/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/target/linux/x86/image/Makefile
> b/target/linux/x86/image/Makefile
> index 72a4d66ad731..174c272a515e 100644
> --- a/target/linux/x86/image/Makefile
> +++ b/target/linux/x86/image/Makefile
> @@ -111,8 +111,8 @@ define Device/Default
> IMAGE/combined.img.gz := grub-config pc | combined | grub-install | gzip
> | append-metadata
> IMAGE/combined.vdi := grub-config pc | combined | grub-install |
> qemu-image vdi
> IMAGE/combined.vmdk := grub-config pc | combined | grub-install |
> qemu-image vmdk
> - IMAGE/rootfs.img := append-rootfs
> - IMAGE/rootfs.img.gz := append-rootfs | gzip
> + IMAGE/rootfs.img := append-rootfs | pad-to $(ROOTFS_PARTSIZE)
> + IMAGE/rootfs.img.gz := append-rootfs | pad-to $(ROOTFS_PARTSIZE) |
> gzip
> ARTIFACT/image-efi.iso := grub-config iso | iso efi
> IMAGE/combined-efi.img := grub-config efi | combined efi | grub-install
> efi | append-metadata
> IMAGE/combined-efi.img.gz := grub-config efi | combined efi |
> grub-install efi | gzip | append-metadata
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] x86: fix unusable squashfs images by adding missing padding
On Sat Apr 25, 2020 at 2:56 AM PST, Petr Štetiar wrote:
> It was reported, that after image generation rework
> x86-64-generic-squashfs-rootfs.img image won't boot on XenServer x86_64
> anymore:
>
> F2FS-fs (xvda): Magic Mismatch, valid(0xf2f52010) - read(0x84289960)
> F2FS-fs (xvda): Can't find valid F2FS filesystem in 1th superblock
> F2FS-fs (xvda): Magic Mismatch, valid(0xf2f52010) - read(0x4e8ee223)
> F2FS-fs (xvda): Can't find valid F2FS filesystem in 2th superblock
> List of all partitions:
> ca00 4207 xvda
> driver: vbd
> No filesystem could mount root, tried:
> ext3
> ext2
> ext4
> squashfs
> iso9660
> f2fs
>
> Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(202,0)
>
> So lets fix this by adding back padding which was introduced in commit
> a17d9482f5e2 ("x86: image: fix small disk space in squashfs overlay").
>
> Ref: FS#3036
> Cc: Paul Spooren
> Cc: Tomasz Maciej Nowak
> Fixes: 258f070d1a4f ("x86: fix missing squashfs and ext4 rootfs images")
> Fixes: cb007a7bf619 ("x86: switch image generation to new code")
> Signed-off-by: Petr Štetiar
> ---
> target/linux/x86/image/Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/target/linux/x86/image/Makefile
> b/target/linux/x86/image/Makefile
> index 72a4d66ad731..174c272a515e 100644
> --- a/target/linux/x86/image/Makefile
> +++ b/target/linux/x86/image/Makefile
> @@ -111,8 +111,8 @@ define Device/Default
> IMAGE/combined.img.gz := grub-config pc | combined | grub-install | gzip
> | append-metadata
> IMAGE/combined.vdi := grub-config pc | combined | grub-install |
> qemu-image vdi
> IMAGE/combined.vmdk := grub-config pc | combined | grub-install |
> qemu-image vmdk
> - IMAGE/rootfs.img := append-rootfs
> - IMAGE/rootfs.img.gz := append-rootfs | gzip
> + IMAGE/rootfs.img := append-rootfs | pad-to $(ROOTFS_PARTSIZE)
> + IMAGE/rootfs.img.gz := append-rootfs | pad-to $(ROOTFS_PARTSIZE) |
> gzip
> ARTIFACT/image-efi.iso := grub-config iso | iso efi
> IMAGE/combined-efi.img := grub-config efi | combined efi | grub-install
> efi | append-metadata
> IMAGE/combined-efi.img.gz := grub-config efi | combined efi |
> grub-install efi | gzip | append-metadata
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Upgrading LEDE to 19.07
> On Apr 25, 2020, at 11:46 AM, Luca Bertoncello wrote: > > Am 25.04.2020 um 20:44 schrieb Rosen Penev: > >> This is indeed a v1. Strange that it has 64MB of flash. Maybe someone modded >> it... > > With 64MB could I upgrade to 19.07? > This is the only interesting thing for me, right now... :D Sure. There’s no real compatibility issue. Just the 32MB RAM problem. Just don’t run Adblock with a ton of lists. Easy to get OOM like that. > > Regards > Luca Bertoncello > (lucab...@lucabert.de) > > ___ > 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] Upgrading LEDE to 19.07
On 25/04/20 20:30, Luca Bertoncello wrote: Am 25.04.2020 um 20:27 schrieb Alberto Bursi: Hi that's weird, that's 64MB. Maybe a V2 in an older box? What is the CPU? check cat /proc/cpuinfo The V1 has Atheros AR9103. root@OpenWrt:~# cat /proc/cpuinfo system type : Atheros AR9132 rev 2 machine : TP-LINK TL-WR1043ND processor : 0 cpu model : MIPS 24Kc V7.4 BogoMIPS: 265.42 wait instruction: yes microsecond timers : yes tlb_entries : 16 extra interrupt vector : yes hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb] isa : mips1 mips2 mips32r1 mips32r2 ASEs implemented: mips16 shadow register sets: 1 kscratch registers : 0 package : 0 core: 0 VCED exceptions : not available VCEI exceptions : not available It is definitivly NOT a AR9103... Any idea? Sorry I wrote the CPU name wrong. AR9132 is the right CPU for V1 so this is a weird V1.x where they added more RAM for some reason. Afaik this CPU does support 64MB (it's the max for it), so it's possible. Also AFAIK on this target the RAM size was autodetected, so that's why OpenWrt is detecting 64MB even if the device is supposed to have less. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Upgrading LEDE to 19.07
Am 25.04.2020 um 20:44 schrieb Rosen Penev: > This is indeed a v1. Strange that it has 64MB of flash. Maybe someone modded > it... With 64MB could I upgrade to 19.07? This is the only interesting thing for me, right now... :D Regards Luca Bertoncello (lucab...@lucabert.de) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Upgrading LEDE to 19.07
> On Apr 25, 2020, at 11:30 AM, Luca Bertoncello wrote: > > Am 25.04.2020 um 20:27 schrieb Alberto Bursi: > > Hi > >> that's weird, that's 64MB. Maybe a V2 in an older box? >> What is the CPU? >> check cat /proc/cpuinfo >> The V1 has Atheros AR9103. > > root@OpenWrt:~# cat /proc/cpuinfo > system type : Atheros AR9132 rev 2 > machine : TP-LINK TL-WR1043ND > processor : 0 > cpu model : MIPS 24Kc V7.4 > BogoMIPS: 265.42 > wait instruction: yes > microsecond timers : yes > tlb_entries : 16 > extra interrupt vector : yes > hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, > 0x0ffc, 0x0ffb, 0x0ffb] > isa : mips1 mips2 mips32r1 mips32r2 > ASEs implemented: mips16 > shadow register sets: 1 > kscratch registers : 0 > package : 0 > core: 0 > VCED exceptions : not available > VCEI exceptions : not available > > It is definitivly NOT a AR9103... > Any idea? ar9103 is the WiFi chip. This is indeed a v1. Strange that it has 64MB of flash. Maybe someone modded it... > >> openwrt forum https://forum.openwrt.org/ > > OK, thanks! I'll ask there. > > Regards > Luca Bertoncello > (lucab...@lucabert.de) > > ___ > 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] Upgrading LEDE to 19.07
Am 25.04.2020 um 20:27 schrieb Alberto Bursi: Hi > that's weird, that's 64MB. Maybe a V2 in an older box? > What is the CPU? > check cat /proc/cpuinfo > The V1 has Atheros AR9103. root@OpenWrt:~# cat /proc/cpuinfo system type : Atheros AR9132 rev 2 machine : TP-LINK TL-WR1043ND processor : 0 cpu model : MIPS 24Kc V7.4 BogoMIPS: 265.42 wait instruction: yes microsecond timers : yes tlb_entries : 16 extra interrupt vector : yes hardware watchpoint : yes, count: 4, address/irw mask: [0x0ffc, 0x0ffc, 0x0ffb, 0x0ffb] isa : mips1 mips2 mips32r1 mips32r2 ASEs implemented: mips16 shadow register sets: 1 kscratch registers : 0 package : 0 core: 0 VCED exceptions : not available VCEI exceptions : not available It is definitivly NOT a AR9103... Any idea? > openwrt forum https://forum.openwrt.org/ OK, thanks! I'll ask there. Regards Luca Bertoncello (lucab...@lucabert.de) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Upgrading LEDE to 19.07
On 25/04/20 20:16, Luca Bertoncello wrote: Am 25.04.2020 um 20:12 schrieb Alberto Bursi: If I undestand correct, I can upgrade to 19.07, but it will be the last version I can get, is it right? The main issue is the warning about 32MB of RAM you see on the top of that page. I read it... LUCI says, my device has 60664KB RAM, and I can see the same value checking /proc/meminfo If your device is HW Version 1 (white case, black antennas) then it might not have enough RAM to run OpenWrt. I have this device, white cas and three black antennas... But, as I sayd, it seems to have ~60MB RAM... that's weird, that's 64MB. Maybe a V2 in an older box? What is the CPU? check cat /proc/cpuinfo The V1 has Atheros AR9103. Could you suggest me a better place to ask this question? I really think, this list is not the appropriate place... openwrt forum https://forum.openwrt.org/ -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Upgrading LEDE to 19.07
> On Apr 25, 2020, at 11:16 AM, Luca Bertoncello wrote: > > Am 25.04.2020 um 20:12 schrieb Alberto Bursi: > > Hi > >> The only "discontinued" is the "Availability", and that just means if >> you can still find or buy this device new from somewhere. >> It does not mean anything about OpenWrt support of the device. >> The device is still supported. > > OK > >>> If I undestand correct, I can upgrade to 19.07, but it will be the last >>> version I can get, is it right? >> >> The main issue is the warning about 32MB of RAM you see on the top of >> that page. > > I read it... > LUCI says, my device has 60664KB RAM, and I can see the same value > checking /proc/meminfo > >> If your device is HW Version 1 (white case, black antennas) then it >> might not have enough RAM to run OpenWrt. > > I have this device, white cas and three black antennas... > But, as I sayd, it seems to have ~60MB RAM... If it has 64MB RAM, it should be fine. That also means this is not a v1. The v1 is the square/rectangular model. > >> You can try upgrading or asking in the forums if someone has already >> done that. > > Could you suggest me a better place to ask this question? > I really think, this list is not the appropriate place... > > Thanks > Luca Bertoncello > (lucab...@lucabert.de) > > ___ > 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] Upgrading LEDE to 19.07
Am 25.04.2020 um 20:12 schrieb Alberto Bursi: Hi > The only "discontinued" is the "Availability", and that just means if > you can still find or buy this device new from somewhere. > It does not mean anything about OpenWrt support of the device. > The device is still supported. OK >> If I undestand correct, I can upgrade to 19.07, but it will be the last >> version I can get, is it right? > > The main issue is the warning about 32MB of RAM you see on the top of > that page. I read it... LUCI says, my device has 60664KB RAM, and I can see the same value checking /proc/meminfo > If your device is HW Version 1 (white case, black antennas) then it > might not have enough RAM to run OpenWrt. I have this device, white cas and three black antennas... But, as I sayd, it seems to have ~60MB RAM... > You can try upgrading or asking in the forums if someone has already > done that. Could you suggest me a better place to ask this question? I really think, this list is not the appropriate place... Thanks Luca Bertoncello (lucab...@lucabert.de) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Upgrading LEDE to 19.07
On 25/04/20 19:46, Luca Bertoncello wrote: Hi list! I'm not sure, I'm asking to right list, but I didn't found any other list about OpenWRT I can ask... So, I have a "TP-Link TL-WR1043ND v1" running OpenWRT 17.01.4. I'd like to update it to 19.07, but I read on https://openwrt.org/toh/hwdata/tp-link/tp-link_tl-wr1043nd_v1 that my WLAN-Switch is "discontinued"... The only "discontinued" is the "Availability", and that just means if you can still find or buy this device new from somewhere. It does not mean anything about OpenWrt support of the device. The device is still supported. If I undestand correct, I can upgrade to 19.07, but it will be the last version I can get, is it right? The main issue is the warning about 32MB of RAM you see on the top of that page. If your device is HW Version 1 (white case, black antennas) then it might not have enough RAM to run OpenWrt. You can try upgrading or asking in the forums if someone has already done that. It seems Rosen has one so he will probably be able to tell you more about the RAM situation on this device. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Upgrading LEDE to 19.07
Am 25.04.2020 um 19:54 schrieb Rosen Penev: Hi >> So, I have a "TP-Link TL-WR1043ND v1" running OpenWRT 17.01.4. >> I'd like to update it to 19.07, but I read on >> https://openwrt.org/toh/hwdata/tp-link/tp-link_tl-wr1043nd_v1 that my >> WLAN-Switch is "discontinued"... > Never heard of this. Mine works fine. If you read in the page I posted, the device is marked as "discontinued"... My Switch works fine, too, but I'd like to upgrade to 19.07, if possible... Which version of OpenWRT runs on your Switch? > The RAM is the bigger problem. There’s no good way around it. swap is not > really an answer. Of course, swap is not the solution... I must say, that in my WLANs I really don't have many clients... Actually 7 devices... Would my device run with 19.07 or should I better remain on 17.01? Thanks Luca Bertoncello (lucab...@lucabert.de) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Upgrading LEDE to 19.07
> On Apr 25, 2020, at 10:47 AM, Luca Bertoncello wrote: > > Hi list! > > I'm not sure, I'm asking to right list, but I didn't found any other > list about OpenWRT I can ask... > > So, I have a "TP-Link TL-WR1043ND v1" running OpenWRT 17.01.4. > I'd like to update it to 19.07, but I read on > https://openwrt.org/toh/hwdata/tp-link/tp-link_tl-wr1043nd_v1 that my > WLAN-Switch is "discontinued"... Never heard of this. Mine works fine. > > If I undestand correct, I can upgrade to 19.07, but it will be the last > version I can get, is it right? > If so, it would be not a big problem right now, since I can update it > and in future search for a new Switch to install a future version of > OpenWRT... > But the very question is, if 19.07 runs correctly on my device... > I'll expand the FileSystem using an USB-Switch, as I already done in the > past with an old version of OpenWRT (after the update to LEDE the system > didn't use the USB-Stick anymore...). Will it be possible with 19.07, too? The RAM is the bigger problem. There’s no good way around it. swap is not really an answer. > > Thank you for your help > Luca Bertoncello > (lucab...@lucabert.de) > > ___ > 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
[OpenWrt-Devel] Upgrading LEDE to 19.07
Hi list! I'm not sure, I'm asking to right list, but I didn't found any other list about OpenWRT I can ask... So, I have a "TP-Link TL-WR1043ND v1" running OpenWRT 17.01.4. I'd like to update it to 19.07, but I read on https://openwrt.org/toh/hwdata/tp-link/tp-link_tl-wr1043nd_v1 that my WLAN-Switch is "discontinued"... If I undestand correct, I can upgrade to 19.07, but it will be the last version I can get, is it right? If so, it would be not a big problem right now, since I can update it and in future search for a new Switch to install a future version of OpenWRT... But the very question is, if 19.07 runs correctly on my device... I'll expand the FileSystem using an USB-Switch, as I already done in the past with an old version of OpenWRT (after the update to LEDE the system didn't use the USB-Stick anymore...). Will it be possible with 19.07, too? Thank you for your help Luca Bertoncello (lucab...@lucabert.de) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] wireless-regdb: backport three upstream fixes
Petr Štetiar [2020-04-25 14:58:28]: > Another release is overdue for quite some time, so I'm backporting three > fixes from upstream which I plan to backport into 19.07 as well. > > Ref: #2880 sorry, this should've been FS#2880 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] wireless-regdb: backport three upstream fixes
Another release is overdue for quite some time, so I'm backporting three
fixes from upstream which I plan to backport into 19.07 as well.
Ref: #2880
Signed-off-by: Petr Štetiar
---
package/firmware/wireless-regdb/Makefile | 1 +
...ix-overlapping-ranges-for-Switzerlan.patch | 47 +
...ix-ranges-of-EU-countries-as-they-ar.patch | 843 ++
...pdate-regulatory-rules-for-Russia-RU.patch | 44 +
4 files changed, 935 insertions(+)
create mode 100644
package/firmware/wireless-regdb/patches/600-wireless-regdb-Fix-overlapping-ranges-for-Switzerlan.patch
create mode 100644
package/firmware/wireless-regdb/patches/601-wireless-regdb-Fix-ranges-of-EU-countries-as-they-ar.patch
create mode 100644
package/firmware/wireless-regdb/patches/602-wireless-regdb-Update-regulatory-rules-for-Russia-RU.patch
diff --git a/package/firmware/wireless-regdb/Makefile
b/package/firmware/wireless-regdb/Makefile
index 26f470af44c4..86343be04c46 100644
--- a/package/firmware/wireless-regdb/Makefile
+++ b/package/firmware/wireless-regdb/Makefile
@@ -2,6 +2,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=wireless-regdb
PKG_VERSION:=2019.06.03
+PKG_RELEASE:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
PKG_SOURCE_URL:=@KERNEL/software/network/wireless-regdb/
diff --git
a/package/firmware/wireless-regdb/patches/600-wireless-regdb-Fix-overlapping-ranges-for-Switzerlan.patch
b/package/firmware/wireless-regdb/patches/600-wireless-regdb-Fix-overlapping-ranges-for-Switzerlan.patch
new file mode 100644
index ..6febcc060f2f
--- /dev/null
+++
b/package/firmware/wireless-regdb/patches/600-wireless-regdb-Fix-overlapping-ranges-for-Switzerlan.patch
@@ -0,0 +1,47 @@
+From Mon Sep 17 00:00:00 2001
+From: Martin Willi
+Date: Tue, 2 Jul 2019 16:19:44 +0200
+Subject: [PATCH] wireless-regdb: Fix overlapping ranges for Switzerland and
+ Liechtenstein
+
+The commit referenced below changes the 5GHz frequency range 5250-5330
+to 5150-5330, making that range overlapping with the existing range
+5170-5250. This imposes DFS limitations and a reduced maximum power
+level for the range 5170-5250.
+
+The change of the frequency range seems not intentional. Instead the
+commit should have changed the 5170-5250 range to 5150-5250, and the
+5250-5330 range to 5250-5350 (see [1]).
+
+[1] https://www.ofcomnet.ch/api/rir/1010/05
+
+Fixes: 957a7cff72a3 ("wireless-regdb: update regulatory rules for Switzerland
(CH), and Liechtenstein (LI) on 5GHz")
+Signed-off-by: Martin Willi
+Signed-off-by: Seth Forshee
+
+diff --git a/db.txt b/db.txt
+index d47ab94c3aa5..37393e6a793e 100644
+--- a/db.txt
b/db.txt
+@@ -271,8 +271,8 @@ country CF: DFS-FCC
+ # transmitter power control is in use: 5250-5330@23db, 5490-5710@30db
+ country CH: DFS-ETSI
+ (2402 - 2482 @ 40), (20)
+- (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+- (5150 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
++ (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
++ (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
+ # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (57000 - 66000 @ 2160), (40)
+@@ -747,8 +747,8 @@ country LC: DFS-ETSI
+ # transmitter power control is in use: 5250-5330@23db, 5490-5710@30db
+ country LI: DFS-ETSI
+ (2402 - 2482 @ 40), (20)
+- (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+- (5150 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
++ (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
++ (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
+ # 60 GHz band channels 1-4, ref: Etsi En 302 567
+ (57000 - 66000 @ 2160), (40)
diff --git
a/package/firmware/wireless-regdb/patches/601-wireless-regdb-Fix-ranges-of-EU-countries-as-they-ar.patch
b/package/firmware/wireless-regdb/patches/601-wireless-regdb-Fix-ranges-of-EU-countries-as-they-ar.patch
new file mode 100644
index ..f9b97bc88559
--- /dev/null
+++
b/package/firmware/wireless-regdb/patches/601-wireless-regdb-Fix-ranges-of-EU-countries-as-they-ar.patch
@@ -0,0 +1,843 @@
+From Mon Sep 17 00:00:00 2001
+From: Emil Petersky
+Date: Tue, 17 Sep 2019 09:49:19 +0200
+Subject: [PATCH] wireless-regdb: Fix ranges of EU countries as they are
+ harmonized since 2014
+
+This patch unites entries for EU countries, as they have been harmonized
+latest by July 2014...
+
+EU decision 2005/513/EC:
+https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02005D0513-20070213
+EU decision 2006/771/EC:
+https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02008D0432-20080611
+
+Signed-off-by: Emil Petersky
+Signed-off-by: Seth Forshee
+
+diff --git a/db.txt b/db.txt
+index 2e149b6e0ea2..a57452479a9b 100644
+--- a/db.txt
Re: [OpenWrt-Devel] [PATCH] base-files: Add /etc/shinit for non-login shell init
Jeffery To [2019-05-03 02:24:27]: Hi, > Because /etc/profile (and ~/.profile) are read by login shells only, > aliases and functions defined there are not available to non-login > shells, e.g. when using screen or tmux. > > If the ENV environment variable exists (exported by /etc/profile or > ~/.profile) and references an existing file, then all interactive shells > (login or non-login) will read that file as well. > > This sets the ENV environment variable in /etc/profile, pointing to > /etc/shinit. > > This also adds /etc/shinit, which: > > * Contains alias and function definitions originally in /etc/profile > > * Sources /etc/mkshrc if the user is using mksh (also originally in > /etc/profile), as /etc/mkshrc is meant for all interactive shells > > * Sources ~/.mkshrc if the user is using mksh, to compensate for the > fact that mksh will not read ~/.mkshrc if ENV is set > > * Sources ~/.shinit if the user is not using mksh > > This also removes the shebang from /etc/profile, as the file is sourced, > not executed. FYI seems like this didnt played well with bash[1]. 1. https://bugs.openwrt.org/index.php?do=details_id=3019 -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] x86: fix unusable squashfs images by adding missing padding
It was reported, that after image generation rework
x86-64-generic-squashfs-rootfs.img image won't boot on XenServer x86_64
anymore:
F2FS-fs (xvda): Magic Mismatch, valid(0xf2f52010) - read(0x84289960)
F2FS-fs (xvda): Can't find valid F2FS filesystem in 1th superblock
F2FS-fs (xvda): Magic Mismatch, valid(0xf2f52010) - read(0x4e8ee223)
F2FS-fs (xvda): Can't find valid F2FS filesystem in 2th superblock
List of all partitions:
ca004207 xvda
driver: vbd
No filesystem could mount root, tried:
ext3
ext2
ext4
squashfs
iso9660
f2fs
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(202,0)
So lets fix this by adding back padding which was introduced in commit
a17d9482f5e2 ("x86: image: fix small disk space in squashfs overlay").
Ref: FS#3036
Cc: Paul Spooren
Cc: Tomasz Maciej Nowak
Fixes: 258f070d1a4f ("x86: fix missing squashfs and ext4 rootfs images")
Fixes: cb007a7bf619 ("x86: switch image generation to new code")
Signed-off-by: Petr Štetiar
---
target/linux/x86/image/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile
index 72a4d66ad731..174c272a515e 100644
--- a/target/linux/x86/image/Makefile
+++ b/target/linux/x86/image/Makefile
@@ -111,8 +111,8 @@ define Device/Default
IMAGE/combined.img.gz := grub-config pc | combined | grub-install | gzip |
append-metadata
IMAGE/combined.vdi := grub-config pc | combined | grub-install | qemu-image
vdi
IMAGE/combined.vmdk := grub-config pc | combined | grub-install | qemu-image
vmdk
- IMAGE/rootfs.img := append-rootfs
- IMAGE/rootfs.img.gz := append-rootfs | gzip
+ IMAGE/rootfs.img := append-rootfs | pad-to $(ROOTFS_PARTSIZE)
+ IMAGE/rootfs.img.gz := append-rootfs | pad-to $(ROOTFS_PARTSIZE) | gzip
ARTIFACT/image-efi.iso := grub-config iso | iso efi
IMAGE/combined-efi.img := grub-config efi | combined efi | grub-install efi
| append-metadata
IMAGE/combined-efi.img.gz := grub-config efi | combined efi | grub-install
efi | gzip | append-metadata
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
