Re: [OpenWrt-Devel] [PATCH] openvpn: update to 2.4.7
On Wed, Mar 27, 2019 at 12:08 PM Magnus Kroken wrote:
>
> Signed-off-by: Magnus Kroken
> ---
> package/network/services/openvpn/Makefile | 6
> +++---
> .../openvpn/patches/100-mbedtls-disable-runtime-version-check.patch | 2 +-
> .../openvpn/patches/210-build_always_use_internal_lz4.patch | 2 +-
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/package/network/services/openvpn/Makefile
> b/package/network/services/openvpn/Makefile
> index 9eef7f4cdc..e5bd80649a 100644
> --- a/package/network/services/openvpn/Makefile
> +++ b/package/network/services/openvpn/Makefile
> @@ -9,14 +9,14 @@ include $(TOPDIR)/rules.mk
>
> PKG_NAME:=openvpn
>
> -PKG_VERSION:=2.4.6
> -PKG_RELEASE:=3
> +PKG_VERSION:=2.4.7
Note that this and previous versions of OpenVPN will not compile when
deprecated APIs are disabled.
I recommend either adding a dependency on @OPENSSL_WITH_DEPRECATED or
patching them out. I have a GitHub repository where I have done just
that if you are interested:
https://github.com/neheb/openvpn/commits/mangix . The branch is based
on this version.
> +PKG_RELEASE:=1
>
> PKG_SOURCE_URL:=\
> https://build.openvpn.net/downloads/releases/ \
> https://swupdate.openvpn.net/community/releases/
> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
> -PKG_HASH:=4f6434fa541cc9e363434ea71a16a62cf2615fb2f16af5b38f43ab5939998c26
> +PKG_HASH:=a42f53570f669eaf10af68e98d65b531015ff9e12be7a62d9269ea684652f648
>
>
> PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)
> PKG_MAINTAINER:=Felix Fietkau
> diff --git
> a/package/network/services/openvpn/patches/100-mbedtls-disable-runtime-version-check.patch
>
> b/package/network/services/openvpn/patches/100-mbedtls-disable-runtime-version-check.patch
> index 5608fa4430..7fc0089000 100644
> ---
> a/package/network/services/openvpn/patches/100-mbedtls-disable-runtime-version-check.patch
> +++
> b/package/network/services/openvpn/patches/100-mbedtls-disable-runtime-version-check.patch
> @@ -1,6 +1,6 @@
> --- a/src/openvpn/ssl_mbedtls.c
> +++ b/src/openvpn/ssl_mbedtls.c
> -@@ -1394,7 +1394,7 @@ const char *
> +@@ -1406,7 +1406,7 @@ const char *
> get_ssl_library_version(void)
> {
> static char mbedtls_version[30];
> diff --git
> a/package/network/services/openvpn/patches/210-build_always_use_internal_lz4.patch
>
> b/package/network/services/openvpn/patches/210-build_always_use_internal_lz4.patch
> index a99f923644..dc4039c3e6 100644
> ---
> a/package/network/services/openvpn/patches/210-build_always_use_internal_lz4.patch
> +++
> b/package/network/services/openvpn/patches/210-build_always_use_internal_lz4.patch
> @@ -1,6 +1,6 @@
> --- a/configure.ac
> +++ b/configure.ac
> -@@ -1077,68 +1077,15 @@ dnl
> +@@ -1078,68 +1078,15 @@ dnl
> AC_ARG_VAR([LZ4_CFLAGS], [C compiler flags for lz4])
> AC_ARG_VAR([LZ4_LIBS], [linker flags for lz4])
> if test "$enable_lz4" = "yes" && test "$enable_comp_stub" = "no"; then
> --
> 2.11.0
>
>
> ___
> 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] script error in target-metadata.pl
Hi Koen, I hope I fixed the issue with commit 7204736076 IB: fix generating .profile.mk for profiles without metadata Please report back if you also see it fixed by this. Cheers Daniel On Tue, Mar 26, 2019 at 04:18:50PM +0100, Koen Vandeputte wrote: > > On 15.03.19 10:00, Koen Vandeputte wrote: > > Hi Daniel, > > > > When running the image builder for my targets, I'm getting following > > error: > > > > > > "Can't use an undefined value as an ARRAY reference at > > /mnt/ramdisk/koen/firmware/.21128/openwrt-imagebuilder-cns3xxx.Linux-x86_64/scripts/target-metadata.pl > > line 426." > > > > > > It seems you made 2 changes last week on this script file: > > > > d6fa04a43703 IB: include SUPPORTED_DEVICES in 'make info' output > > 13c379e5c6e3 ib: display whether profile comes with image metadata > > > > > > Any idea what's causing this? > > > > > > Thanks, > > > > Koen > > > > Ping :-) > > > Still happening when using the imagebuilder: > > "Can't use an undefined value as an ARRAY reference at > /mnt/ramdisk/koen/firmware/.3421/openwrt-imagebuilder-cns3xxx.Linux-x86_64/scripts/target-metadata.pl > line 426." > > > Regards, > > Koen > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/7] tegra: add new target
W dniu 27.03.2019 o 21:31, Christian Lamparter pisze: > On Wednesday, March 27, 2019 3:07:58 PM CET Tomasz Maciej Nowak wrote: >> Hi Hauke, >> >> W dniu 25.03.2019 o 23:39, Hauke Mehrtens pisze: >>> Hi Tomasz, >>> >>> Soke small comments, this looks mostly ok. >>> >> [snip] +# CONFIG_ARM_LPAE is not set >>> >>> Is LPAE not supported by your SoC? This is needed for KVM support, but >>> not all CPUs support this. >> >> Not really sure, seems it should be enabled for all ARM v7, it was disabled >> in tegra_defconfig. Enabling this shouldn't do any harm, will test this. > > Hm, quick FYI: KVM on ARM needs all CPUs to be in Hypervisor Mode. > You can check this by looking in your dmesg: > > if it says: > [0.005874] CPU: All CPU(s) started in HYP mode. > Then yes: LPAE would be great. > > But if it says: > [0.005306] CPU: All CPU(s) started in SVC mode. > then you probably don't need LPAE since KVM is not an option. Thanks, my case would be that^^. Tested my board with LPAE enabled and kernel and image didn't boot. > > Cheers, > Christian > > Regards -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/7] tegra: add new target
On 3/27/19 9:31 PM, Christian Lamparter wrote: > On Wednesday, March 27, 2019 3:07:58 PM CET Tomasz Maciej Nowak wrote: >> Hi Hauke, >> >> W dniu 25.03.2019 o 23:39, Hauke Mehrtens pisze: >>> Hi Tomasz, >>> >>> Soke small comments, this looks mostly ok. >>> >> [snip] +# CONFIG_ARM_LPAE is not set >>> >>> Is LPAE not supported by your SoC? This is needed for KVM support, but >>> not all CPUs support this. >> >> Not really sure, seems it should be enabled for all ARM v7, it was disabled >> in tegra_defconfig. Enabling this shouldn't do any harm, will test this. > > Hm, quick FYI: KVM on ARM needs all CPUs to be in Hypervisor Mode. > You can check this by looking in your dmesg: > > if it says: > [0.005874] CPU: All CPU(s) started in HYP mode. > Then yes: LPAE would be great. > > But if it says: > [0.005306] CPU: All CPU(s) started in SVC mode. > then you probably don't need LPAE since KVM is not an option. We activated this accidentally for all sunxi SoCs, but the older SoCs didn't support it and they didn't boot any more because this option was activated, now it is only activated for the cortex A7 and cortex A53 subtarget. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: Add RIPEMD160 module
After getting rid of cryptsetup's heavy openssl dependency, there is now the problem of missing RIPEMD160 support. RIPEMD160 is used for True/Vera crypt volumes as well as old LUKS1 ones. Signed-off-by: Rosen Penev --- package/kernel/linux/modules/crypto.mk | 12 1 file changed, 12 insertions(+) diff --git a/package/kernel/linux/modules/crypto.mk b/package/kernel/linux/modules/crypto.mk index 8756aae282..e5b02df479 100644 --- a/package/kernel/linux/modules/crypto.mk +++ b/package/kernel/linux/modules/crypto.mk @@ -597,6 +597,18 @@ endef $(eval $(call KernelPackage,crypto-rsa)) +define KernelPackage/crypto-rmd160 + TITLE:=RIPEMD160 digest CryptoAPI module + DEPENDS:=+kmod-crypto-hash + KCONFIG:=CONFIG_CRYPTO_RMD160 + FILES:=$(LINUX_DIR)/crypto/rmd160.ko + AUTOLOAD:=$(call AutoLoad,09,rmd160) + $(call AddDepends/crypto) +endef + +$(eval $(call KernelPackage,crypto-rmd160)) + + define KernelPackage/crypto-rng TITLE:=CryptoAPI random number generation DEPENDS:=+kmod-crypto-hash +kmod-crypto-hmac +kmod-crypto-sha256 -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/7] tegra: add new target
On Wednesday, March 27, 2019 3:07:58 PM CET Tomasz Maciej Nowak wrote: > Hi Hauke, > > W dniu 25.03.2019 o 23:39, Hauke Mehrtens pisze: > > Hi Tomasz, > > > > Soke small comments, this looks mostly ok. > > > [snip] > >> +# CONFIG_ARM_LPAE is not set > > > > Is LPAE not supported by your SoC? This is needed for KVM support, but > > not all CPUs support this. > > Not really sure, seems it should be enabled for all ARM v7, it was disabled > in tegra_defconfig. Enabling this shouldn't do any harm, will test this. Hm, quick FYI: KVM on ARM needs all CPUs to be in Hypervisor Mode. You can check this by looking in your dmesg: if it says: [0.005874] CPU: All CPU(s) started in HYP mode. Then yes: LPAE would be great. But if it says: [0.005306] CPU: All CPU(s) started in SVC mode. then you probably don't need LPAE since KVM is not an option. Cheers, Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] openvpn: update to 2.4.7
Signed-off-by: Magnus Kroken
---
package/network/services/openvpn/Makefile | 6 +++---
.../openvpn/patches/100-mbedtls-disable-runtime-version-check.patch | 2 +-
.../openvpn/patches/210-build_always_use_internal_lz4.patch | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/package/network/services/openvpn/Makefile
b/package/network/services/openvpn/Makefile
index 9eef7f4cdc..e5bd80649a 100644
--- a/package/network/services/openvpn/Makefile
+++ b/package/network/services/openvpn/Makefile
@@ -9,14 +9,14 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=openvpn
-PKG_VERSION:=2.4.6
-PKG_RELEASE:=3
+PKG_VERSION:=2.4.7
+PKG_RELEASE:=1
PKG_SOURCE_URL:=\
https://build.openvpn.net/downloads/releases/ \
https://swupdate.openvpn.net/community/releases/
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
-PKG_HASH:=4f6434fa541cc9e363434ea71a16a62cf2615fb2f16af5b38f43ab5939998c26
+PKG_HASH:=a42f53570f669eaf10af68e98d65b531015ff9e12be7a62d9269ea684652f648
PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(BUILD_VARIANT)/$(PKG_NAME)-$(PKG_VERSION)
PKG_MAINTAINER:=Felix Fietkau
diff --git
a/package/network/services/openvpn/patches/100-mbedtls-disable-runtime-version-check.patch
b/package/network/services/openvpn/patches/100-mbedtls-disable-runtime-version-check.patch
index 5608fa4430..7fc0089000 100644
---
a/package/network/services/openvpn/patches/100-mbedtls-disable-runtime-version-check.patch
+++
b/package/network/services/openvpn/patches/100-mbedtls-disable-runtime-version-check.patch
@@ -1,6 +1,6 @@
--- a/src/openvpn/ssl_mbedtls.c
+++ b/src/openvpn/ssl_mbedtls.c
-@@ -1394,7 +1394,7 @@ const char *
+@@ -1406,7 +1406,7 @@ const char *
get_ssl_library_version(void)
{
static char mbedtls_version[30];
diff --git
a/package/network/services/openvpn/patches/210-build_always_use_internal_lz4.patch
b/package/network/services/openvpn/patches/210-build_always_use_internal_lz4.patch
index a99f923644..dc4039c3e6 100644
---
a/package/network/services/openvpn/patches/210-build_always_use_internal_lz4.patch
+++
b/package/network/services/openvpn/patches/210-build_always_use_internal_lz4.patch
@@ -1,6 +1,6 @@
--- a/configure.ac
+++ b/configure.ac
-@@ -1077,68 +1077,15 @@ dnl
+@@ -1078,68 +1078,15 @@ dnl
AC_ARG_VAR([LZ4_CFLAGS], [C compiler flags for lz4])
AC_ARG_VAR([LZ4_LIBS], [linker flags for lz4])
if test "$enable_lz4" = "yes" && test "$enable_comp_stub" = "no"; then
--
2.11.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: Utilize tplink-safeloader definition
Currently, tplink-safeloader definition is only used a base for another common definition. This patch adjusts tplink-safeloader so it can be actually used for some targets in generic-tp-link.mk. This patch is cosmetic except for the order of "check-size (IMAGE_SIZE)" and "append-metadata" exchanged for the tplink_re350k-v1 . Signed-off-by: Adrian Schmutzler --- target/linux/ath79/image/common-tp-link.mk | 6 -- target/linux/ath79/image/generic-tp-link.mk | 18 +++--- 2 files changed, 7 insertions(+), 17 deletions(-) diff --git a/target/linux/ath79/image/common-tp-link.mk b/target/linux/ath79/image/common-tp-link.mk index f22da2f801..9054284114 100644 --- a/target/linux/ath79/image/common-tp-link.mk +++ b/target/linux/ath79/image/common-tp-link.mk @@ -99,12 +99,14 @@ endef define Device/tplink-safeloader $(Device/tplink) - KERNEL := kernel-bin | append-dtb | lzma | tplink-v1-header - IMAGE/sysupgrade.bin := append-rootfs | tplink-safeloader sysupgrade | append-metadata + KERNEL := kernel-bin | append-dtb | lzma | tplink-v1-header -O + IMAGE/sysupgrade.bin := append-rootfs | tplink-safeloader sysupgrade | \ +append-metadata | check-size (IMAGE_SIZE) IMAGE/factory.bin := append-rootfs | tplink-safeloader factory endef define Device/tplink-safeloader-uimage $(Device/tplink-safeloader) KERNEL := kernel-bin | append-dtb | lzma | uImageArcher lzma + IMAGE/sysupgrade.bin := append-rootfs | tplink-safeloader sysupgrade | append-metadata endef diff --git a/target/linux/ath79/image/generic-tp-link.mk b/target/linux/ath79/image/generic-tp-link.mk index 19a156be79..5b4543ac57 100644 --- a/target/linux/ath79/image/generic-tp-link.mk +++ b/target/linux/ath79/image/generic-tp-link.mk @@ -110,7 +110,7 @@ endef TARGET_DEVICES += tplink_archer-c7-v5 define Device/tplink_re350k-v1 - $(Device/tplink) + $(Device/tplink-safeloader) ATH_SOC := qca9558 IMAGE_SIZE := 13760k DEVICE_TITLE := TP-Link RE350K v1 @@ -118,15 +118,11 @@ define Device/tplink_re350k-v1 TPLINK_BOARD_ID := RE350K-V1 TPLINK_HWID := 0x0 TPLINK_HWREV := 0 - KERNEL := kernel-bin | append-dtb | lzma | tplink-v1-header -O - IMAGE/sysupgrade.bin := append-rootfs | tplink-safeloader sysupgrade | \ -check-size (IMAGE_SIZE) | append-metadata - IMAGE/factory.bin := append-rootfs | tplink-safeloader factory endef TARGET_DEVICES += tplink_re350k-v1 define Device/tplink_re450-v2 - $(Device/tplink) + $(Device/tplink-safeloader) ATH_SOC := qca9563 IMAGE_SIZE := 6016k DEVICE_TITLE := TP-Link RE450 v2 @@ -135,10 +131,6 @@ define Device/tplink_re450-v2 TPLINK_HWREV := 0 TPLINK_BOARD_ID := RE450-V2 LOADER_TYPE := elf - KERNEL := kernel-bin | append-dtb | lzma | tplink-v1-header -O - IMAGE/sysupgrade.bin := append-rootfs | tplink-safeloader sysupgrade | \ -append-metadata | check-size (IMAGE_SIZE) - IMAGE/factory.bin := append-rootfs | tplink-safeloader factory endef TARGET_DEVICES += tplink_re450-v2 @@ -248,17 +240,13 @@ endef TARGET_DEVICES += tplink_tl-wr1043nd-v3 define Device/tplink_tl-wr1043nd-v4 - $(Device/tplink) + $(Device/tplink-safeloader) ATH_SOC := qca9563 IMAGE_SIZE := 15552k DEVICE_TITLE := TP-Link TL-WR1043N/ND v4 DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport TPLINK_HWID := 0x10430004 TPLINK_BOARD_ID := TLWR1043NDV4 - KERNEL := kernel-bin | append-dtb | lzma | tplink-v1-header -O - IMAGE/sysupgrade.bin := append-rootfs | tplink-safeloader sysupgrade | \ -append-metadata | check-size (IMAGE_SIZE) - IMAGE/factory.bin := append-rootfs | tplink-safeloader factory SUPPORTED_DEVICES += tl-wr1043nd-v4 endef TARGET_DEVICES += tplink_tl-wr1043nd-v4 -- 2.11.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/2] x86: Fix combined squashfs images
Hi, we're currently producing unusable x86 combined squashfs images (18.06.1, 18.06.2 and snapshots) as we don't enable TARGET_IMAGES_PAD, thus providing very small space for the overlay filesystem, leading to the following with OpenWrt 18.06.1 r7258-5eb055306f images on x86 QEMU: root@(none):/# mount | egrep 'root|overlay' /dev/root on /rom type squashfs /dev/loop0 on /overlay type ext4 overlayfs:/overlay on / type overlay root@(none):/# df -h | egrep 'root|overlay|Size' FilesystemSize Used Available Use% Mounted on /dev/root 2.5M 2.5M 0 100% /rom /dev/loop0 113.0K 8.0K 97.0K 8% /overlay overlayfs:/overlay 113.0K 8.0K 97.0K 8% / We should rather ensure proper image padding in image generation code and we shouldn't rely on config options in order to generate usable images. So this small patch series removes TARGET_IMAGES_PAD config option and enforces padding on combined images, which fixes the combined squashfs images and make them usable again. Petr Štetiar (2): build: Remove TARGET_IMAGES_PAD option x86: image: Remove TARGET_IMAGES_PAD option and force padding config/Config-images.in | 8 +--- target/linux/x86/image/Makefile | 2 +- 2 files changed, 2 insertions(+), 8 deletions(-) -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] build: Remove TARGET_IMAGES_PAD option
It's being used only in x86 target to produce combined images, where it's mandatory to have padded images in order to produce working squashfs combined images. Currently we're producing unusable x86 combined squashfs images (18.06.1, 18.06.2 and snapshots) as we don't enable TARGET_IMAGES_PAD, thus providing very small space for the overlay filesystem, leading to the following with OpenWrt 18.06.1 r7258-5eb055306f images on x86 QEMU: root@(none):/# mount | egrep 'root|overlay' /dev/root on /rom type squashfs /dev/loop0 on /overlay type ext4 overlayfs:/overlay on / type overlay root@(none):/# df -h | egrep 'root|overlay|Size' FilesystemSize Used Available Use% Mounted on /dev/root 2.5M 2.5M 0 100% /rom /dev/loop0 113.0K 8.0K 97.0K 8% /overlay overlayfs:/overlay 113.0K 8.0K 97.0K 8% / So we should rather ensure proper image padding in image generation code and we shouldn't rely on config options in order to generate usable images. Signed-off-by: Petr Štetiar --- config/Config-images.in | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/config/Config-images.in b/config/Config-images.in index 6610601d..eb050ca 100644 --- a/config/Config-images.in +++ b/config/Config-images.in @@ -240,23 +240,17 @@ menu "Target Images" bool "Build VirtualBox image files (VDI)" depends on TARGET_x86 select GRUB_IMAGES - select TARGET_IMAGES_PAD select PACKAGE_kmod-e1000 config VMDK_IMAGES bool "Build VMware image files (VMDK)" depends on TARGET_x86 select GRUB_IMAGES - select TARGET_IMAGES_PAD select PACKAGE_kmod-e1000 - config TARGET_IMAGES_PAD - bool "Pad images to filesystem size (for JFFS2)" - depends on GRUB_IMAGES - config TARGET_IMAGES_GZIP bool "GZip images" - depends on TARGET_IMAGES_PAD || TARGET_ROOTFS_EXT4FS || TARGET_x86 + depends on TARGET_ROOTFS_EXT4FS || TARGET_x86 default y comment "Image Options" -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] x86: image: Remove TARGET_IMAGES_PAD option and force padding
Currently we're producing unusable x86 combined squashfs images (18.06.1, 18.06.2 and snapshots) as we don't enable TARGET_IMAGES_PAD, thus providing very small space for the overlay filesystem, leading to the following with OpenWrt 18.06.1 r7258-5eb055306f images on x86 QEMU: root@(none):/# mount | egrep 'root|overlay' /dev/root on /rom type squashfs /dev/loop0 on /overlay type ext4 overlayfs:/overlay on / type overlay root@(none):/# df -h | egrep 'root|overlay|Size' FilesystemSize Used Available Use% Mounted on /dev/root 2.5M 2.5M 0 100% /rom /dev/loop0 113.0K 8.0K 97.0K 8% /overlay overlayfs:/overlay 113.0K 8.0K 97.0K 8% / We should rather ensure proper image padding in image generation code and we shouldn't rely on config options in order to generate usable images. So this patch removes TARGET_IMAGES_PAD config option and enforces padding on combined images. Signed-off-by: Petr Štetiar --- target/linux/x86/image/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/x86/image/Makefile b/target/linux/x86/image/Makefile index 84a3d88..2d04d12 100644 --- a/target/linux/x86/image/Makefile +++ b/target/linux/x86/image/Makefile @@ -80,7 +80,7 @@ ifneq ($(CONFIG_GRUB_IMAGES),) -e 's#@TITLE@#$(GRUB_TITLE)#g' \ ./grub.cfg > $(KDIR)/root.grub/boot/grub/grub.cfg -$(CP) $(STAGING_DIR_ROOT)/boot/. $(KDIR)/root.grub/boot/ - PADDING="$(CONFIG_TARGET_IMAGES_PAD)" SIGNATURE="$(SIGNATURE)" PATH="$(TARGET_PATH)" $(SCRIPT_DIR)/gen_image_generic.sh \ + PADDING="1" SIGNATURE="$(SIGNATURE)" PATH="$(TARGET_PATH)" $(SCRIPT_DIR)/gen_image_generic.sh \ $(BIN_DIR)/$(IMG_PREFIX)-combined-$(1).img \ $(CONFIG_TARGET_KERNEL_PARTSIZE) $(KDIR)/root.grub \ $(CONFIG_TARGET_ROOTFS_PARTSIZE) $(KDIR)/root.$(1) \ -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/7] tegra: add new target
Hi Hauke, W dniu 25.03.2019 o 23:39, Hauke Mehrtens pisze: > Hi Tomasz, > > Soke small comments, this looks mostly ok. > [snip] >> +# CONFIG_ARM_LPAE is not set > > Is LPAE not supported by your SoC? This is needed for KVM support, but > not all CPUs support this. > Not really sure, seems it should be enabled for all ARM v7, it was disabled in tegra_defconfig. Enabling this shouldn't do any harm, will test this. [snip] >> +CONFIG_EXT2_FS=y > > We normally use the ext4 driver to handle ext2. Ack, will change to EXT4_USE_FOR_EXT2. > >> +CONFIG_EXT4_FS=y >> +CONFIG_EXT4_FS_POSIX_ACL=y > > Do you need ACL support? > No, will remove it. [snip] >> +# CONFIG_JFFS2_FS is not set > > This would be needed for overlay filesystems. > I was thinking that if F2FS is enabled, it's used as overlay, will enable it. >> +CONFIG_KALLSYMS=y > > CONFIG_KALLSYMS should not be activated by default. > Ack, will remove it. >> +CONFIG_LIBFDT=y >> +CONFIG_LOCK_SPIN_ON_OWNER=y >> +CONFIG_LZ4HC_COMPRESS=y >> +CONFIG_LZ4_COMPRESS=y >> +CONFIG_LZ4_DECOMPRESS=y >> +CONFIG_LZO_COMPRESS=y >> +CONFIG_LZO_DECOMPRESS=y >> +CONFIG_MANDATORY_FILE_LOCKING=y > > Why do you need CONFIG_MANDATORY_FILE_LOCKING? > It's not needed, this is remnant of basing this config on tegra_defconfig and I didn't delve when i saw MANDATORY, will remove it. Thank You for review, I will send v3 ASAP. Regards -- TMN ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] libfstools: Fix overflow of F2FS_MINSIZE constant
I wasn't able to to use f2fs on armvirt/32 platform and I've found out
that it was due to F2FS_MINSIZE constant overflow leading to value of 13
exabytes instead of 100 megabytes.
Signed-off-by: Petr Štetiar
---
libfstools/rootdisk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libfstools/rootdisk.c b/libfstools/rootdisk.c
index 68a6296..5a6dcb9 100644
--- a/libfstools/rootdisk.c
+++ b/libfstools/rootdisk.c
@@ -11,7 +11,6 @@
* GNU General Public License for more details.
*/
-#define F2FS_MINSIZE (100 * 1024 * 1024)
#define _FILE_OFFSET_BITS 64
#include
@@ -31,6 +30,7 @@
#include
#define ROOTDEV_OVERLAY_ALIGN (64ULL * 1024ULL)
+#define F2FS_MINSIZE (100ULL * 1024ULL * 1024ULL)
struct squashfs_super_block {
uint32_t s_magic;
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] libfstools: Output error in case of loop blkdev failure
Jo-Philipp Wich [2019-03-27 08:05:50]:
Hi,
> I suggest to rephrase the subject to something like "print error in
> case". I kept reading "output error" and wondered what went wrong with
> the output.
Good point.
> > - if (!p->loop_name[0] && rootdisk_create_loop(p) != 0)
> > + if (!p->loop_name[0] && rootdisk_create_loop(p) != 0) {
> > + ULOG_ERR("unable to create loop device\n");
>
> Do we have a valid errno value here? Would be useful to append the
> strerror(3) description as well to see whether its ENOSYS, EINVAL etc.
I was thinking about the same, but I wasn't 100% sure, that the errno after
rootdisk_create_loop() would be always valid and I think, that in some corner
cases errno won't be set at all (strcmp, offset comparison), thus I've chosen
to go with generic error, rather then misleading one.
In order to fix this properly, we would probably need to refactor
rootdisk_create_loop, potentialy open some regressions in some corner cases,
increasing the flash footprint and I'm not sure if it's worth the effort,
since this error (missing loop blkdev kernel module) usually happens only
during the development.
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCHv2] tools/xz: Compile with PIC to fix linking errors
I made a similar change to this here: https://github.com/openwrt/packages/pull/8159 However, it turns out this did not fix the problem as the problem has to do with tools/xz and not the xz package. The error is the same and causes linking errors as can be seen above. Signed-off-by: Rosen Penev --- v2: Reworded a bit and resubmitted. tools/xz/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tools/xz/Makefile b/tools/xz/Makefile index 5d574892bb..21029a74aa 100644 --- a/tools/xz/Makefile +++ b/tools/xz/Makefile @@ -1,4 +1,4 @@ -# +# # Copyright (C) 2006-2015 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. @@ -25,7 +25,8 @@ HOSTCXX := $(HOSTCXX_NOCACHE) HOST_CONFIGURE_ARGS += \ --enable-static=yes \ --enable-shared=no \ - --disable-doc + --disable-doc \ + --with-pic define Host/Install +$(MAKE) $(HOST_JOBS) -C $(HOST_BUILD_DIR) install xzlinks="unxz xzcat" -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] libfstools: Output error in case of loop blkdev failure
Hi Petr,
I suggest to rephrase the subject to something like "print error in
case". I kept reading "output error" and wondered what went wrong with
the output.
> It took me quite some time today(while fixing squashfs+overlay on
> armvirt) to find out, that I was missing support for loop block device
> in kernel, so I'm adding error message which might be helpful for
> someone else in the future as well.
>
> Signed-off-by: Petr Štetiar
> ---
> libfstools/rootdisk.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libfstools/rootdisk.c b/libfstools/rootdisk.c
> index dd00c1b..68a6296 100644
> --- a/libfstools/rootdisk.c
> +++ b/libfstools/rootdisk.c
> @@ -258,8 +258,10 @@ static int rootdisk_volume_init(struct volume *v)
> char str[128];
> int ret = 0;
>
> - if (!p->loop_name[0] && rootdisk_create_loop(p) != 0)
> + if (!p->loop_name[0] && rootdisk_create_loop(p) != 0) {
> + ULOG_ERR("unable to create loop device\n");
Do we have a valid errno value here? Would be useful to append the
strerror(3) description as well to see whether its ENOSYS, EINVAL etc.
> return -1;
> + }
>
> v->type = BLOCKDEV;
> v->blk = p->loop_name;
>
~ Jo
signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
