[OpenWrt-Devel] [PATCH] Change of location of linux-pam sources
Hi Nikos, The linux-pam tarball location has been changed: --- feeds/packages/libs/libpam/Makefile.orig2014-08-12 12:37:26.964048714 +0100 +++ feeds/packages/libs/libpam/Makefile2014-08-12 11:56:46.650173845 +0100 @@ -12,7 +12,7 @@ PKG_VERSION:=1.1.8 PKG_RELEASE:=4 PKG_SOURCE:=Linux-PAM-$(PKG_VERSION).tar.bz2 -PKG_SOURCE_URL:=http://www.linux-pam.org/ +PKG_SOURCE_URL:=http://www.linux-pam.org/library/ PKG_MD5SUM:=35b6091af95981b1b2cd60d813b5e4ee PKG_INSTALL:=1 PKG_FIXUP:=autoreconf Please can you apply? It is unclear from the site if going forward this will continue to be the correct location or if it will change to: https://fedorahosted.org/releases/l/i/linux-pam/ Thanks Stephen Parry ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [Pull request]
Dear Felix, I have patched the BusyBox package to allow it to build correctly when CONFIG_BUSYBOX_CONFIG_PAM is set. The use case here is that I want to secure the console with a login where I hope to selectively allow or deny given users access based on their entries in LDAP. I have not fully tested the resulting login behaviour, but this patch does at least allow BusyBox to build without breaking. Can this please be included in fixes for the final release of BB? Many Thanks Stephen Parry --- The following changes since commit 7a828618dc7fc7205f73013d14f91a252fa19672: odhcpd: multiple DHCPv4 improvements (thx Christian Mehlis) (2014-08-12 13:30:38 +) are available in the git repository at: https://github.com/sgparry/openwrt-patched.git sgp-bb-pam-patch for you to fetch changes up to c71833c06a8d95c0560d5df1bb7fe0bb3ba551d6: Patch to BusyBox Makefile to build correctly when PAM support is enabled. (2014-08-12 21:38:27 +0100) Stephen Parry (1): Patch to BusyBox Makefile to build correctly when PAM support is enabled. package/utils/busybox/Makefile | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile index 3380885..668679e 100644 --- a/package/utils/busybox/Makefile +++ b/package/utils/busybox/Makefile @@ -17,7 +17,7 @@ PKG_SOURCE_URL:=http://www.busybox.net/downloads \ http://distfiles.gentoo.org/distfiles/ PKG_MD5SUM:=337d1a15ab1cb1d4ed423168b1eb7d7e -PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc +PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc BUSYBOX_CONFIG_PAM:libpam PKG_BUILD_PARALLEL:=1 PKG_CHECK_FORMAT_SECURITY:=0 @@ -42,7 +42,7 @@ define Package/busybox MAINTAINER:=Felix Fietkau TITLE:=Core utilities for embedded Linux URL:=http://busybox.net/ - DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc + DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam MENU:=1 endef @@ -80,6 +80,12 @@ ifdef CONFIG_BUSYBOX_USE_LIBRPC LDLIBS += rpc endif +ifdef CONFIG_BUSYBOX_CONFIG_PAM + TARGET_CFLAGS += -I$(STAGING_DIR)/usr/include + export LDFLAGS=$(TARGET_LDFLAGS) + LDLIBS += pam pam_misc pthread +endif + define Build/Compile +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ CC="$(TARGET_CC)" \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] / [Pull request] Patches to BusyBox to fix build errors when PAM support is enabled.
Dear Felix, I have patched the BusyBox package to allow it to build correctly when CONFIG_BUSYBOX_CONFIG_PAM is set. The use case here is that I want to secure the console with a login where I hope to selectively allow or deny given users access based on their entries in LDAP. I have not fully tested the resulting login behaviour, but this patch does at least allow BusyBox to build without breaking. Can this please be included in fixes for the final release of BB? Many Thanks Stephen Parry --- Patch to BusyBox Makefile to fix build errors when PAM support is enabled. Signed-off-by: Stephen G. Parry --- The following changes since commit 7a828618dc7fc7205f73013d14f91a252fa19672: odhcpd: multiple DHCPv4 improvements (thx Christian Mehlis) (2014-08-12 13:30:38 +) are available in the git repository at: https://github.com/sgparry/openwrt-patched.git sgp-bb-pam-patch for you to fetch changes up to 0a0a5ab6458e27c153f1c07329f1df88372acecd: Patch to BusyBox Makefile to fix build errors when PAM support is enabled. (2014-08-15 13:57:06 +0100) Stephen Parry (1): Patch to BusyBox Makefile to fix build errors when PAM support is enabled. package/utils/busybox/Makefile | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile index 3380885..668679e 100644 --- a/package/utils/busybox/Makefile +++ b/package/utils/busybox/Makefile @@ -17,7 +17,7 @@ PKG_SOURCE_URL:=http://www.busybox.net/downloads \ http://distfiles.gentoo.org/distfiles/ PKG_MD5SUM:=337d1a15ab1cb1d4ed423168b1eb7d7e -PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc +PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc BUSYBOX_CONFIG_PAM:libpam PKG_BUILD_PARALLEL:=1 PKG_CHECK_FORMAT_SECURITY:=0 @@ -42,7 +42,7 @@ define Package/busybox MAINTAINER:=Felix Fietkau TITLE:=Core utilities for embedded Linux URL:=http://busybox.net/ - DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc + DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam MENU:=1 endef @@ -80,6 +80,12 @@ ifdef CONFIG_BUSYBOX_USE_LIBRPC LDLIBS += rpc endif +ifdef CONFIG_BUSYBOX_CONFIG_PAM + TARGET_CFLAGS += -I$(STAGING_DIR)/usr/include + export LDFLAGS=$(TARGET_LDFLAGS) + LDLIBS += pam pam_misc pthread +endif + define Build/Compile +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ CC="$(TARGET_CC)" \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] GIT or SVN for patch diffs
Dear All, Can someone tell me please: a) Is git the preferred way of making patches as suggested here: https://dev.openwrt.org/wiki/SubmittingPatches/Svn ? b) Can I submit a patch against HEAD on a branch (e.g. 14.07) or only against trunk? c) Which commands of the many possible git permutations should I use the generate the patch ? I have searched extensively online but am still confused. Many Thanks Stephen Parry ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] GIT or SVN for patch diffs
Dear All, Can someone tell me please: a) Is git the preferred way of making patches as suggested here: https://dev.openwrt.org/wiki/SubmittingPatches/Svn ? b) Can I submit a patch against HEAD on a branch (e.g. 14.07) or only against trunk? c) Which commands of the many possible git permutations should I use the generate the patch ? I have searched extensively online but am still confused. Many Thanks Stephen Parry ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Subject: [PATCH] Busybox: Fix pam_start link errors when PAM support is enabled
From: Stephen G. Parry Patch to BusyBox Makefile to fix linker errors when PAM support is enabled by CONFIG_BUSYBOX_CONFIG_PAM=y. Typical errors include: login.c:(.text.login_main+0x122): undefined reference to `pam_start' Signed-off-by: Stephen Parry --- package/utils/busybox/Makefile | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile index 3380885..668679e 100644 --- a/package/utils/busybox/Makefile +++ b/package/utils/busybox/Makefile @@ -17,7 +17,7 @@ PKG_SOURCE_URL:=http://www.busybox.net/downloads \ http://distfiles.gentoo.org/distfiles/ PKG_MD5SUM:=337d1a15ab1cb1d4ed423168b1eb7d7e -PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc +PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc BUSYBOX_CONFIG_PAM:libpam PKG_BUILD_PARALLEL:=1 PKG_CHECK_FORMAT_SECURITY:=0 @@ -42,7 +42,7 @@ define Package/busybox MAINTAINER:=Felix Fietkau TITLE:=Core utilities for embedded Linux URL:=http://busybox.net/ - DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc + DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam MENU:=1 endef @@ -80,6 +80,12 @@ ifdef CONFIG_BUSYBOX_USE_LIBRPC LDLIBS += rpc endif +ifdef CONFIG_BUSYBOX_CONFIG_PAM + TARGET_CFLAGS += -I$(STAGING_DIR)/usr/include + export LDFLAGS=$(TARGET_LDFLAGS) + LDLIBS += pam pam_misc pthread +endif + define Build/Compile +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ CC="$(TARGET_CC)" \ -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Subject: [PATCH] Busybox: Fix pam_start link errors when PAM support is enabled
I have sent as a git patch. I will follow up with an svn one. Please let me know which is more preferable. If possible please apply to BB as well as trunk. Thanks. On 15/08/14 17:25, Stephen Parry wrote: > From: Stephen G. Parry > > Patch to BusyBox Makefile to fix linker errors when PAM support is enabled by > CONFIG_BUSYBOX_CONFIG_PAM=y. Typical errors include: > login.c:(.text.login_main+0x122): undefined reference to `pam_start' > > Signed-off-by: Stephen Parry > --- > package/utils/busybox/Makefile | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile > index 3380885..668679e 100644 > --- a/package/utils/busybox/Makefile > +++ b/package/utils/busybox/Makefile > @@ -17,7 +17,7 @@ PKG_SOURCE_URL:=http://www.busybox.net/downloads \ > http://distfiles.gentoo.org/distfiles/ > PKG_MD5SUM:=337d1a15ab1cb1d4ed423168b1eb7d7e > > -PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc > +PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc BUSYBOX_CONFIG_PAM:libpam > PKG_BUILD_PARALLEL:=1 > PKG_CHECK_FORMAT_SECURITY:=0 > > @@ -42,7 +42,7 @@ define Package/busybox >MAINTAINER:=Felix Fietkau >TITLE:=Core utilities for embedded Linux >URL:=http://busybox.net/ > - DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc > + DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam >MENU:=1 > endef > > @@ -80,6 +80,12 @@ ifdef CONFIG_BUSYBOX_USE_LIBRPC >LDLIBS += rpc > endif > > +ifdef CONFIG_BUSYBOX_CONFIG_PAM > + TARGET_CFLAGS += -I$(STAGING_DIR)/usr/include > + export LDFLAGS=$(TARGET_LDFLAGS) > + LDLIBS += pam pam_misc pthread > +endif > + > define Build/Compile > +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ > CC="$(TARGET_CC)" \ > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [package] busybox: Fix pam_start link errors when PAM support is enabled
From: Stephen G. Parry Patch to BusyBox Makefile to fix linker errors when PAM support is enabled by CONFIG_BUSYBOX_CONFIG_PAM=y. Typical errors include: login.c:(.text.login_main+0x122): undefined reference to `pam_start' Signed-off-by: Stephen Parry --- Index: trunk/package/utils/busybox/Makefile === --- trunk/package/utils/busybox/Makefile(revision 42167) +++ trunk/package/utils/busybox/Makefile(working copy) @@ -17,7 +17,7 @@ http://distfiles.gentoo.org/distfiles/ PKG_MD5SUM:=337d1a15ab1cb1d4ed423168b1eb7d7e -PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc +PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc BUSYBOX_CONFIG_PAM:libpam PKG_BUILD_PARALLEL:=1 PKG_CHECK_FORMAT_SECURITY:=0 @@ -42,7 +42,7 @@ MAINTAINER:=Felix Fietkau TITLE:=Core utilities for embedded Linux URL:=http://busybox.net/ - DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc + DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam MENU:=1 endef @@ -80,6 +80,12 @@ LDLIBS += rpc endif +ifdef CONFIG_BUSYBOX_CONFIG_PAM + TARGET_CFLAGS += -I$(STAGING_DIR)/usr/include + export LDFLAGS=$(TARGET_LDFLAGS) + LDLIBS += pam pam_misc pthread +endif + define Build/Compile +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ CC="$(TARGET_CC)" \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] GIT or SVN for patch diffs
Thank Jonas, that really helps - I will use this in future patches to core. Could this please be wiki'd? On 15/08/14 17:40, Jonas Gorski wrote: > Hi, > > On Fri, Aug 15, 2014 at 5:30 PM, Stephen Parry wrote: >> Dear All, >> Can someone tell me please: >> a) Is git the preferred way of making patches as suggested here: >> https://dev.openwrt.org/wiki/SubmittingPatches/Svn ? > > Git is the recommended way as it makes it quite easy to create and > send working patch emails, but you are not required to use it. > >> b) Can I submit a patch against HEAD on a branch (e.g. 14.07) or only >> against trunk? > > Patches should be against trunk and will be backported to affected > branches if needed. If the issue only affects the branch, then an > patch against the branch is fine. This is to ensure that fixes can't > get "lost" in a branch. > >> c) Which commands of the many possible git permutations should I use the >> generate the patch ? > > git format-patch is what I use. > > My workflow is basically (for a single patch) > > a) edit stuff > b) ensure it compiles > c) git add > d) git commit -s > e) > f) git show -1 (to review the patch) > f) git format-patch -1 > g) git send-email --to=... --cc=... 0001-* > > for patch series, do a to f accordingly, then git format-patch -, > where x = number of patches, or (maybe also a --cover-letter), > then send the patch series. > > > Jonas > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] [package] busybox: Fix pam_start link errors when PAM support is enabled
Patch to BusyBox Makefile to fix linker errors when PAM support is enabled by CONFIG_BUSYBOX_CONFIG_PAM=y. Typical errors include: login.c:(.text.login_main+0x122): undefined reference to `pam_start' Signed-off-by: Stephen Parry --- New version of patch - now against trunk and using git package/utils/busybox/Makefile | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile index 3380885..668679e 100644 --- a/package/utils/busybox/Makefile +++ b/package/utils/busybox/Makefile @@ -17,7 +17,7 @@ PKG_SOURCE_URL:=http://www.busybox.net/downloads \ http://distfiles.gentoo.org/distfiles/ PKG_MD5SUM:=337d1a15ab1cb1d4ed423168b1eb7d7e -PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc +PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc BUSYBOX_CONFIG_PAM:libpam PKG_BUILD_PARALLEL:=1 PKG_CHECK_FORMAT_SECURITY:=0 @@ -42,7 +42,7 @@ define Package/busybox MAINTAINER:=Felix Fietkau TITLE:=Core utilities for embedded Linux URL:=http://busybox.net/ - DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc + DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam MENU:=1 endef @@ -80,6 +80,12 @@ ifdef CONFIG_BUSYBOX_USE_LIBRPC LDLIBS += rpc endif +ifdef CONFIG_BUSYBOX_CONFIG_PAM + TARGET_CFLAGS += -I$(STAGING_DIR)/usr/include + export LDFLAGS=$(TARGET_LDFLAGS) + LDLIBS += pam pam_misc pthread +endif + define Build/Compile +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ CC="$(TARGET_CC)" \ -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] [package] busybox: Fix pam_start link errors when PAM support is enabled
Can someone please give me some feedback as to whether this patch now meets the canonical standard, and whether it's likely to get applied. I have a number of others to come and I would like to make sure I get them right. Thanks, Stephen Parry On 17/08/14 23:30, Stephen Parry wrote: > Patch to BusyBox Makefile to fix linker errors when PAM support is enabled by > CONFIG_BUSYBOX_CONFIG_PAM=y. Typical errors include: > login.c:(.text.login_main+0x122): undefined reference to `pam_start' > > Signed-off-by: Stephen Parry > --- > New version of patch - now against trunk and using git > package/utils/busybox/Makefile | 10 -- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile > index 3380885..668679e 100644 > --- a/package/utils/busybox/Makefile > +++ b/package/utils/busybox/Makefile > @@ -17,7 +17,7 @@ PKG_SOURCE_URL:=http://www.busybox.net/downloads \ > http://distfiles.gentoo.org/distfiles/ > PKG_MD5SUM:=337d1a15ab1cb1d4ed423168b1eb7d7e > > -PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc > +PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc BUSYBOX_CONFIG_PAM:libpam > PKG_BUILD_PARALLEL:=1 > PKG_CHECK_FORMAT_SECURITY:=0 > > @@ -42,7 +42,7 @@ define Package/busybox >MAINTAINER:=Felix Fietkau >TITLE:=Core utilities for embedded Linux >URL:=http://busybox.net/ > - DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc > + DEPENDS:=+BUSYBOX_USE_LIBRPC:librpc +BUSYBOX_CONFIG_PAM:libpam >MENU:=1 > endef > > @@ -80,6 +80,12 @@ ifdef CONFIG_BUSYBOX_USE_LIBRPC >LDLIBS += rpc > endif > > +ifdef CONFIG_BUSYBOX_CONFIG_PAM > + TARGET_CFLAGS += -I$(STAGING_DIR)/usr/include > + export LDFLAGS=$(TARGET_LDFLAGS) > + LDLIBS += pam pam_misc pthread > +endif > + > define Build/Compile > +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ > CC="$(TARGET_CC)" \ > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt-devel Digest, Vol 104, Issue 68
I for one second this patch. I have just bricked my router trying to get the current trx image to work on my WNR3500L. I am not sure why it worked previously but it does not now, but it was doing just as described, hanging at "Starting program at 0x80001000". I thought it was because the MTD command had failed, so I tried from CFE and inadvertently overwrote my CFE - doh! Stephen Parry On 18/08/14 22:31, openwrt-devel-requ...@lists.openwrt.org wrote: > Message: 2 > Date: Mon, 18 Aug 2014 21:44:46 +0200 > From: Rafa? Mi?ecki > To: Hauke Mehrtens ,openwrt-devel@lists.openwrt.org > Subject: [OpenWrt-Devel] [PATCH] brcm47xx: image: build alternative > TRX using less optimized LZMA > Message-ID: <1408391086-7330-1-git-send-email-zaj...@gmail.com> > Content-Type: text/plain; charset=UTF-8 > > There is a group of devices that lzma-loader doesn't work with. They > simply hang at "Starting program at 0x80001000" which is really hard to > debug and we didn't find any solution for this for years. > > Broadcom doesn't use lzma-loader on these devices anyway. They decided > to drop lzma-loader and use less optimal LZMA compression that can be > handled by CFE itself (it doesn't use dictionary). > > So support these devices we will need kernel compressed with different > parameters and trx without a loader. > > Signed-off-by: Rafa? Mi?ecki > --- > target/linux/brcm47xx/image/Makefile | 8 > 1 file changed, 8 insertions(+) > > diff --git a/target/linux/brcm47xx/image/Makefile > b/target/linux/brcm47xx/image/Makefile > index 584bb6c..d19a13e 100644 > --- a/target/linux/brcm47xx/image/Makefile > +++ b/target/linux/brcm47xx/image/Makefile > @@ -12,7 +12,12 @@ define Build/Clean > endef > > define Image/Prepare > + # Optimized LZMA compression (with dictionary), handled by lzma-loader. > cat $(KDIR)/vmlinux | $(STAGING_DIR_HOST)/bin/lzma e -si -so -eos -lc1 > -lp2 -pb2 > $(KDIR)/vmlinux.lzma > + > + # Less optimal LZMA compression (no dictionary), handled by CFE. > + $(STAGING_DIR_HOST)/bin/lzma e -so -d16 $(KDIR)/vmlinux > > $(KDIR)/vmlinux-nodictionary.lzma > + > gzip -nc9 $(KDIR)/vmlinux > $(KDIR)/vmlinux.gz > ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) > cat $(KDIR)/vmlinux-initramfs | $(STAGING_DIR_HOST)/bin/lzma e -si -so > -eos -lc1 -lp2 -pb2 > $(KDIR)/vmlinux-initramfs.lzma > @@ -230,6 +235,9 @@ define Image/Build > $(STAGING_DIR_HOST)/bin/trx -o $(BIN_DIR)/$(IMG_PREFIX)-$(1).trx \ > -f $(KDIR)/loader.gz -f $(KDIR)/vmlinux.lzma \ > $(call trxalign/$(1),$(1)) > + $(STAGING_DIR_HOST)/bin/trx -o > $(BIN_DIR)/$(IMG_PREFIX)-$(1)-noloader-nodictionary.trx \ > + -f $(KDIR)/vmlinux-nodictionary.lzma \ > + $(call trxalign/$(1),$(1)) > $(STAGING_DIR_HOST)/bin/trx -o $(BIN_DIR)/$(IMG_PREFIX)-$(1)-gz.trx \ > -f $(KDIR)/vmlinux.gz \ > $(call trxalign/$(1),$(1)) > -- 1.8.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt-devel Digest, Vol 104, Issue 85
The thing that makes my blood boil is this - there are plenty of use cases where initramfs is a must: - ELF boot from external media - KEXEC to external media - TFTP boot None of these currently work in BB whereas they used to. And you cannot easily add the scripts to support them because all the 'hookability' is outside of process id 1. This means when you try switch_root it blows up in your face. If you try pivot_root it fails cause you can't pivot_root ramfs. I have raised a bug - but no response yet. I have also submitted a small patch which was bounced? On 22/08/14 08:21, openwrt-devel-requ...@lists.openwrt.org wrote: > Message: 3 Date: Thu, 21 Aug 2014 21:33:15 +0200 From: Rafa? Mi?ecki > To: Hauke Mehrtens Cc: OpenWrt > Development List Subject: Re: > [OpenWrt-Devel] Firmware without SquashFS (initramfs + overlay) > Message-ID: > > Content-Type: text/plain; charset=UTF-8 On 20 August 2014 23:22, Hauke > Mehrtens wrote: >> > You want to use initramfs because the SquashFS image is booting very >> > unreliable or are there any other reasons? > Because firmware with SquashFS boot in unreliable :| > > >> > This boot problems seams to be in the boot loader. The boot loader >> > should not see a difference between an initramfs and a SquashFS image, >> > could it be that the boot loader does not like small images or not >> > aligned images? > Could be some timing issue in OpenWrt as well. No idea how to debug that. > > -- Rafa? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] brcm47xx: image: build alternative TRX using less optimized LZMA
I for one second this patch. I have just bricked my router trying to get the current trx image to work on my WNR3500L. I am not sure why it worked previously but it does not now, but it was doing just as described, hanging at "Starting program at 0x80001000". I thought it was because the MTD command had failed, so I tried from CFE and inadvertently overwrote my CFE - doh! Stephen Parry P.S. Sorry for first post without subject - noob error. On 18/08/14 22:31, openwrt-devel-requ...@lists.openwrt.org wrote: > Message: 2 > Date: Mon, 18 Aug 2014 21:44:46 +0200 > From: Rafa? Mi?ecki > To: Hauke Mehrtens ,openwrt-devel@lists.openwrt.org > Subject: [OpenWrt-Devel] [PATCH] brcm47xx: image: build alternative > TRX using less optimized LZMA > Message-ID: <1408391086-7330-1-git-send-email-zaj...@gmail.com> > Content-Type: text/plain; charset=UTF-8 > > There is a group of devices that lzma-loader doesn't work with. They > simply hang at "Starting program at 0x80001000" which is really hard to > debug and we didn't find any solution for this for years. > > Broadcom doesn't use lzma-loader on these devices anyway. They decided > to drop lzma-loader and use less optimal LZMA compression that can be > handled by CFE itself (it doesn't use dictionary). > > So support these devices we will need kernel compressed with different > parameters and trx without a loader. > > Signed-off-by: Rafa? Mi?ecki > --- > target/linux/brcm47xx/image/Makefile | 8 > 1 file changed, 8 insertions(+) > > diff --git a/target/linux/brcm47xx/image/Makefile > b/target/linux/brcm47xx/image/Makefile > index 584bb6c..d19a13e 100644 > --- a/target/linux/brcm47xx/image/Makefile > +++ b/target/linux/brcm47xx/image/Makefile > @@ -12,7 +12,12 @@ define Build/Clean > endef > > define Image/Prepare > + # Optimized LZMA compression (with dictionary), handled by lzma-loader. > cat $(KDIR)/vmlinux | $(STAGING_DIR_HOST)/bin/lzma e -si -so -eos -lc1 > -lp2 -pb2 > $(KDIR)/vmlinux.lzma > + > + # Less optimal LZMA compression (no dictionary), handled by CFE. > + $(STAGING_DIR_HOST)/bin/lzma e -so -d16 $(KDIR)/vmlinux > > $(KDIR)/vmlinux-nodictionary.lzma > + > gzip -nc9 $(KDIR)/vmlinux > $(KDIR)/vmlinux.gz > ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) > cat $(KDIR)/vmlinux-initramfs | $(STAGING_DIR_HOST)/bin/lzma e -si -so > -eos -lc1 -lp2 -pb2 > $(KDIR)/vmlinux-initramfs.lzma > @@ -230,6 +235,9 @@ define Image/Build > $(STAGING_DIR_HOST)/bin/trx -o $(BIN_DIR)/$(IMG_PREFIX)-$(1).trx \ > -f $(KDIR)/loader.gz -f $(KDIR)/vmlinux.lzma \ > $(call trxalign/$(1),$(1)) > + $(STAGING_DIR_HOST)/bin/trx -o > $(BIN_DIR)/$(IMG_PREFIX)-$(1)-noloader-nodictionary.trx \ > + -f $(KDIR)/vmlinux-nodictionary.lzma \ > + $(call trxalign/$(1),$(1)) > $(STAGING_DIR_HOST)/bin/trx -o $(BIN_DIR)/$(IMG_PREFIX)-$(1)-gz.trx \ > -f $(KDIR)/vmlinux.gz \ > $(call trxalign/$(1),$(1)) > -- 1.8.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Firmware without SquashFS (initramfs + overlay)
The thing that makes my blood boil is this - there are plenty of use cases where initramfs is a must: - ELF boot from external media - KEXEC to external media - TFTP boot None of these currently work in BB whereas they used to. And you cannot easily add the scripts to support them because all the 'hookability' is outside of process id 1. This means when you try switch_root it blows up in your face. If you try pivot_root it fails cause you can't pivot_root ramfs. I have raised a bug - but no response yet. I have also submitted a small patch which was bounced? P.S. Sorry for first post without subject - noob error. On 22/08/14 08:21, openwrt-devel-requ...@lists.openwrt.org wrote: > Message: 3 Date: Thu, 21 Aug 2014 21:33:15 +0200 From: Rafa? Mi?ecki > To: Hauke Mehrtens Cc: OpenWrt > Development List Subject: Re: > [OpenWrt-Devel] Firmware without SquashFS (initramfs + overlay) > Message-ID: > > Content-Type: text/plain; charset=UTF-8 On 20 August 2014 23:22, Hauke > Mehrtens wrote: >> > You want to use initramfs because the SquashFS image is booting very >> > unreliable or are there any other reasons? > Because firmware with SquashFS boot in unreliable :| > > >> > This boot problems seams to be in the boot loader. The boot loader >> > should not see a difference between an initramfs and a SquashFS image, >> > could it be that the boot loader does not like small images or not >> > aligned images? > Could be some timing issue in OpenWrt as well. No idea how to debug that. > > -- Rafa? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [boot] /init: allow easier customisation of ramfs boot.
/init is the first pid 1 process in an initramfs environment. This fix adds lines to check for the existence of /bin/ramfsinit or /sbin/ramfsinit and exec if present. This allows packages to switch root early in the boot process. This will help support booting or kexecing from external storage and go some way toward fixing ticket #17465. Signed-off-by: Stephen Parry --- target/linux/generic/base-files/init | 8 1 file changed, 8 insertions(+) diff --git a/target/linux/generic/base-files/init b/target/linux/generic/base-files/init index 514be57..cae515d 100755 --- a/target/linux/generic/base-files/init +++ b/target/linux/generic/base-files/init @@ -1,4 +1,12 @@ #!/bin/sh # Copyright (C) 2006 OpenWrt.org export INITRAMFS=1 + +if [ -e /bin/ramfsinit ]; then + exec /bin/ramfsinit +fi +if [ -e /sbin/ramfsinit ]; then + exec /sbin/ramfsinit +fi + exec /sbin/init -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] brcm47xx: image: build alternative TRX using less optimized LZMA
No sorry - I did not explain carefully enough: 1. About 9 months ago I built a trx using trunk that flashed and worked OK. 2. Two weeks ago I built a new image. This loaded and tested fine as ELF via tftp boot so I flashed the trx using MTD command. the resulting image hung after "starting program at 8001000" just as you described. 3. I incorrectly thought the problem was that I had flashed incorrectly so tried CFE flash command instead. 4. I got parameters of flash command wrong and overwrote CFE. 5. I saw your patch and kicked myself for not having seen it sooner. I was supporting (seconding) your patch by trying to explain that had I seen it 15 minutes earlier it would have saved me from a dead router. Rafa? Mi?ecki wrote: >First of all, I really don't think this patch itself may cause any > problem with MTD/partitions/bricking. > I don't understand much of your report. > It was working previously? But > then you say it was hanging? Then you > mention some MTD command > failing...? What did you do in CFE? Which firmware did you try to > install at all? What was the log of firmware booting & destroying your > CFE? > This "report" says nothing :(___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [boot] /init: allow easier customisation of ramfs boot.
@John: If you mean /sbin/ramfsinit, it doesn't exist until provided by a.n.other package or by the developer under $ROOT/files - it's just a hook. I have an example I wrote and tested that mounts external usb storage and switches root but it isn't neccesarily up to fully generalised use. If you mean /init, that lives in $ROOT/target/linux/generic/base-files/init Stephen___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] brcm47xx: image: build alternative TRX using less optimized LZMA
I still have the original trx (I think) and the source plus the notes of how I built the trx. However, there are a lot of differences between the two builds: - The openwrt startup has changed dramatically in the last 9 months or so. - The old image was squashfs plus minimal writable jffs2; the new is an initramfs only build. My gut instinct is that the fault is loader related because the new image in ELF format (no lzma-loader) loads and runs fine via tftp boot. I am waiting for a jtag cable to recover CFE (the serial console is dead). Once I have that I can test whether the patch helps or not. One gap in my my knowledge: which code actually loads squashfs into memory - is that lzma-loader or something between lzma-loader and kernel start please? On 26 August 2014 08:25:44 BST, Mathias Adam wrote: >Hi Stephen, > >do you still have the old working trx, or better, remember how you >created >it? > >That might help debugging the "Starting program" hang... > >Mathias > > >Am Di, 26.08.2014, 04:34 schrieb Stephen Parry: >> No sorry - I did not explain carefully enough: >> 1. About 9 months ago I built a trx using trunk that flashed and >worked >> OK. >> 2. Two weeks ago I built a new image. This loaded and tested fine as >ELF >> via tftp boot so I flashed the trx using MTD command. the resulting >image >> hung after "starting program at 8001000" just as you described. >> 3. I incorrectly thought the problem was that I had flashed >incorrectly so >> tried CFE flash command instead. >> 4. I got parameters of flash command wrong and overwrote CFE. >> 5. I saw your patch and kicked myself for not having seen it sooner. >> >> I was supporting (seconding) your patch by trying to explain that had >I >> seen it 15 minutes earlier it would have saved me from a dead router. >> >> Rafa? Mi?ecki wrote: >>>First of all, I really don't think this patch itself may cause any >>> problem with MTD/partitions/bricking. >> >>> I don't understand much of your report. > It was working previously? >But >>> then you say it was hanging? Then you > mention some MTD command >>> failing...? What did you do in CFE? Which firmware did you try to >>> install at all? What was the log of firmware booting & destroying >your >>> CFE? >>> This "report" says nothing >>> :(___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] brcm47xx: image: build alternative TRX using less optimized LZMA
On 26 August 2014 10:00:35 BST, "Rafał Miłecki" wrote: >On 26 August 2014 10:26, Stephen Parry wrote: >> One gap in my my knowledge: which code actually loads squashfs into >memory - is that lzma-loader or something between lzma-loader and >kernel start please? > >SquashFS? It's loaded much later, but the Linux kernel. After platform >registers flash and partitioning driver creates partitions. So in a normal openwrt boot is squashfs the first root filesystem loaded / mounted or is a ramfs loaded with the kernel and then replaced? I've been through the code so many times now I've lost track completely... > >Please don't top post. Is inline the preferred style on this list? Sorry I couldn't find any guidelines on posting style - only on patch formatting. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [PATCH V2] [boot] /init: allow easier customisation of ramfs boot.
/init is the first pid 1 process in an initramfs environment. This fix adds lines to check for the existence of /bin/ramfsinit or /sbin/ramfsinit and exec if present. This allows packages to switch root early in the boot process. This will help support booting or kexecing from external storage and go some way toward fixing ticket #17465. Signed-off-by: Stephen Parry --- V2: Improved script structure using elif --- target/linux/generic/base-files/init | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/target/linux/generic/base-files/init b/target/linux/generic/base-files/init index 514be57..e80b324 100755 --- a/target/linux/generic/base-files/init +++ b/target/linux/generic/base-files/init @@ -1,4 +1,11 @@ #!/bin/sh # Copyright (C) 2006 OpenWrt.org export INITRAMFS=1 -exec /sbin/init + +if [ -e /bin/ramfsinit ]; then + exec /bin/ramfsinit +elif [ -e /sbin/ramfsinit ]; then + exec /sbin/ramfsinit +else + exec /sbin/init +fi -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] brcm47xx: image: Enhance initramfs support to create chk and alternative nodictionary images
Enhance support for initramfs: - added commands to create chk images for flashing via tftp or stock firmware gui - added commands to generate nodictionary and noloader variants of trx images Signed-off-by: Stephen Parry --- target/linux/brcm47xx/image/Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/target/linux/brcm47xx/image/Makefile b/target/linux/brcm47xx/image/Makefile index d19a13e..42461d3 100644 --- a/target/linux/brcm47xx/image/Makefile +++ b/target/linux/brcm47xx/image/Makefile @@ -21,6 +21,7 @@ define Image/Prepare gzip -nc9 $(KDIR)/vmlinux > $(KDIR)/vmlinux.gz ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),) cat $(KDIR)/vmlinux-initramfs | $(STAGING_DIR_HOST)/bin/lzma e -si -so -eos -lc1 -lp2 -pb2 > $(KDIR)/vmlinux-initramfs.lzma + $(STAGING_DIR_HOST)/bin/lzma e -so -d16 $(KDIR)/vmlinux-initramfs > $(KDIR)/vmlinux-initramfs-nodictionary.lzma endif rm -f $(KDIR)/loader.gz $(MAKE) -C lzma-loader \ @@ -228,6 +229,8 @@ endef define Image/Build/Initramfs $(STAGING_DIR_HOST)/bin/trx -o $(BIN_DIR)/$(IMG_PREFIX)-initramfs.trx -f $(KDIR)/loader.gz -f $(KDIR)/vmlinux-initramfs.lzma + $(STAGING_DIR_HOST)/bin/trx -o $(BIN_DIR)/$(IMG_PREFIX)-initramfs-noloader-nodictionary.trx -f $(KDIR)/vmlinux-initramfs-nodictionary.lzma + $(call Image/Build/$(SUBTARGET)/squashfs,initramfs) endef # $(1): filesystem type. -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Issues with MTD parsing in absence of rootfs - Proposed patch, advice please
Thanks, that's close to what I've come up with myself. I'll test this evening. If it works can we commit the patch please? On 29 October 2014 06:23:32 GMT+00:00, "Rafał Miłecki" wrote: >On 29 October 2014 02:17, Stephen G. Parry >wrote: >> As some of you will be aware I have been working on an initramfs only >> image with no lzma-loader, used to kexec main kernel from external >> storage on a bcrm47xx based router (Netgear WNR3500L v1). I have >> encountered two unpleasant issues: >> >> 1. The parsing routines in bcm47xxpart.c do not currently cope with a >> non-existent rootfs, i.e. one where the trx header shows zero >relative >> offset after the main linux image. the result is thus: >> >> [1.04] 7 bcm47xxpart partitions found on MTD device >bcm47xxsflash >> [1.05] Creating 7 MTD partitions on "bcm47xxsflash": >> [1.06] 0x-0x0004 : "boot" >> [1.06] 0x0004-0x007d : "firmware" >> [1.07] 0x0004001c-0x0004 : "linux" >> [1.08] mtd: partition "linux" must either start or end on >erase >> block boundary or be smaller than an erase block -- forcing read-only >> [1.09] 0x0004-0x007d : "rootfs" >> [1.10] mtd: device 3 (rootfs) set to be root filesystem >> [1.11] mtdsplit: no squashfs found in "rootfs" >> [1.11] mtdsplit: no squashfs found in "bcm47xxsflash" >> [1.12] 0x007d-0x007e : "POT" >> [1.13] 0x007e-0x007f : "board_data" >> [1.13] 0x007f-0x0080 : "nvram" > >Try this: >http://git.infradead.org/l2-mtd.git/commitdiff/a1ff7d64c5361c15bac653708a679de13506d283 -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] (BACKPORT to 3.14) mtd: bcm47xxpart: only register partitions if the trx header was filled
Sometimes the trx offsets are 0, in that case there is no partition and
we should not try to add one.
Signed-off-by: Hauke Mehrtens
[Brian: rewrapped]
Signed-off-by: Brian Norris
[Stephen Parry: Backported to 3.14]
Signed-off-by: Stephen Parry
---
...art-skip_adding_partitions_for_zero_trx_offsets | 39 ++
1 file changed, 39 insertions(+)
create mode 100644
target/linux/generic/patches-3.14/432-mtd-bcm47xxpart-skip_adding_partitions_for_zero_trx_offsets
diff --git
a/target/linux/generic/patches-3.14/432-mtd-bcm47xxpart-skip_adding_partitions_for_zero_trx_offsets
b/target/linux/generic/patches-3.14/432-mtd-bcm47xxpart-skip_adding_partitions_for_zero_trx_offsets
new file mode 100644
index 000..cc50446
--- /dev/null
+++
b/target/linux/generic/patches-3.14/432-mtd-bcm47xxpart-skip_adding_partitions_for_zero_trx_offsets
@@ -0,0 +1,39 @@
+--- a/drivers/mtd/bcm47xxpart.c
b/drivers/mtd/bcm47xxpart.c
+@@ -192,20 +192,28 @@ static int bcm47xxpart_parse(struct mtd_
+ i++;
+ }
+
+- bcm47xxpart_add_part(&parts[curr_part++], "linux",
+- offset + trx->offset[i], 0);
+- i++;
++ if (trx->offset[i]) {
++ bcm47xxpart_add_part(&parts[curr_part++],
++ "linux",
++ offset + trx->offset[i],
++ 0);
++ i++;
++ }
+
+ /*
+* Pure rootfs size is known and can be calculated as:
+* trx->length - trx->offset[i]. We don't fill it as
+* we want to have jffs2 (overlay) in the same mtd.
+*/
+- name = bcm47xxpart_trx_data_part_name(master,
+-offset +
trx->offset[i]);
+- bcm47xxpart_add_part(&parts[curr_part++], name,
+- offset + trx->offset[i], 0);
+- i++;
++ if (trx->offset[i]) {
++ name = bcm47xxpart_trx_data_part_name(master,
++ offset +
trx->offset[i]);
++ bcm47xxpart_add_part(&parts[curr_part++],
++ name,
++ offset + trx->offset[i],
++ 0);
++ i++;
++ }
+
+ last_trx_part = curr_part - 1;
+
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
