Re: [OpenWrt-Devel] [PATCH] kernel/build: Fix SetNfsCmdline to work with new .config.set
Florian Fainelli [2016-02-09 19:57:22]:
> Le 09/02/2016 12:16, Petr Štetiar a écrit :
> > Petr Štetiar [2016-02-09 21:04:14]:
> >
> >>>define Kernel/SetNfsCmdline
> >>> rm -f $(LINUX_DIR)/.config.prev
> >>> - mv $(LINUX_DIR)/.config $(LINUX_DIR)/.config.old
> >>> - grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old >
> >>> $(LINUX_DIR)/.config
> >>> - grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed
> >>> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs
> >>> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config
> >>> + mv $(LINUX_DIR)/.config.set $(LINUX_DIR)/.config.old
> >>> + grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old >
> >>> $(LINUX_DIR)/.config.set
> >>> + grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed
> >>> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs
> >>> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config.set
> >>>endef
> >>
> >> This cut/sed kung-fu needs some improvements:
> >>
> >> * it doesn't work correctly in case of empty cmdline, CONFIG_CMDLINE=""
> >> * how to handle custom cmdline options? For example I don't want to use
> >> this
> >>hardcoded cmdline options, but use instead options provided by the
> >> bootloader
> >
> > Hm, now I'm wondering why is this macro needed at all. In case I'll set
> > CONFIG_KERNEL_ROOT_NFS=y, then I can set CONFIG_CMDLINE accordingly also,
> > right?
> >
> > Florian, what's your use case for this SetNfsCmdline macro, that you need to
> > hardcode kernel cmdline options? Thanks.
>
> Not all platforms get their command-line from the bootloader, or Device
> Tree, or whatever, some do actually hardcode the command-line into the
> kernel, that's what motivated this change in the first place.
I see, but I'm not sure how to handle it properly so it works for other use
cases as well. Maybe adding something like CONFIG_CMDLINE_NFSROOT option, but
this seems like overdesigning to me...
FYI, I'm using this base-files-nfs[1] package for development over NFS for a
few years already, currently on i.MX6 with u-boot like this:
setenv nfsroot /opt/devel/openwrt-master.git/bin/imx6/rootfs
setenv nfsargs root=/dev/nfs nfsroot=${serverip}:${nfsroot}
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:apalis:eth0:off nfsrootdebug
I've noticed, that you've added something similar to the OpenWRT config
directly:
buildroot: add options to build the kernel for NFS boot
And I've to test it yet - just wondering if we don't need to use similar
approach to skip network initialization in case we boot over NFS as it's
currently done in base-files-nfs[1] package.
> I am fine dropping this, since obviously; if you turn on the option you
> know what you are doing, can you re-submit the patch you think is
> appropriate?
>From my point of view this macro SetNfsCmdline is not needed as you can
specify CONFIG_CMDLINE directly in your config. If you think also, that we
don't need this SetNfsCmdline macro, then you can just revert it yourself,
right? :-)
Thanks for heads up.
1.
https://github.com/ynezz/openwrt/commit/fe3e0081b603de99dd0f0a71478b8f3a3a941728
-- ynezz
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] libubus.h: marking unused variables
diff --git a/libubus.h b/libubus.h
index 08dac49..d419205 100644
--- a/libubus.h
+++ b/libubus.h
@@ -285,7 +285,7 @@ int ubus_invoke_async(struct ubus_context *ctx, uint32_t
obj, const char *method
int ubus_send_reply(struct ubus_context *ctx, struct ubus_request_data *req,
struct blob_attr *msg);
-static inline void ubus_defer_request(struct ubus_context *ctx,
+static inline void ubus_defer_request(struct ubus_context *ctx
__attribute__((__unused__)),
struct ubus_request_data *req,
struct ubus_request_data *new_req)
{
@@ -293,7 +293,7 @@ static inline void ubus_defer_request(struct ubus_context
*ctx,
req->deferred = true;
}
-static inline void ubus_request_set_fd(struct ubus_context *ctx,
+static inline void ubus_request_set_fd(struct ubus_context *ctx
__attribute__((__unused__)),
struct ubus_request_data *req, int fd)
{
req->fd = fd;
--
2.7.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] libubus.h: marking unused variables
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Isn't it more standard and cross compiler to do instead...
(void)ctx;
Rather than sprinkling gcc attributes around?
Sincerely,
Karl Palsson
Emanuel Taube wrote:
>
> diff --git a/libubus.h b/libubus.h
> index 08dac49..d419205 100644
> --- a/libubus.h
> +++ b/libubus.h
> @@ -285,7 +285,7 @@ int ubus_invoke_async(struct ubus_context *ctx, uint32_t
> obj, const char *method
> int ubus_send_reply(struct ubus_context *ctx, struct ubus_request_data *req,
> struct blob_attr *msg);
>
> -static inline void ubus_defer_request(struct ubus_context
> *ctx, +static inline void ubus_defer_request(struct
> ubus_context *ctx __attribute__((__unused__)),
> struct ubus_request_data *req,
> struct ubus_request_data *new_req)
> {
> @@ -293,7 +293,7 @@ static inline void ubus_defer_request(struct ubus_context
> *ctx,
> req->deferred = true;
> }
>
> -static inline void ubus_request_set_fd(struct ubus_context
> *ctx, +static inline void ubus_request_set_fd(struct
> ubus_context *ctx __attribute__((__unused__)),
> struct ubus_request_data *req, int fd)
> {
> req->fd = fd;
> --
> 2.7.0
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
- --
Sent using Mailpile, Free Software from www.mailpile.is
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAEBAgAGBQJWuzoHAAoJEBmotQ/U1cr2BiIP/0QM/1bxQ4Fr6ZJJqWWHDRIR
+92rSQdVhMXoMdYZFY2UEpzStSWbx4jcbLidptMdEdTfVAUP0ZmCTvfVBTizhB2n
U0StyUW/DAGJ7hOPHJMTZ9FB8q9xyeegtZeg5VPaXyawI/zx7i5cOmd+CItR0fi9
UqjzHRVmuSYKUrcAhE71np1MSP0OaYwYSb6yKcu2fB/V1tZJtfcJDLLiBUZaOcCy
SOCUyDJnIn8utQAfT0ZDNOdgydGyvNz5uANNWOfwD1zcKv7L1kOR3RY/Ax4IEbbR
88UJ3gsSlI+0XlEdNHfWxoVwx6Y385AUMkULEu+Rg7RFUvXkixfFO0TvhHqXtlzL
dWziwRbGPyIxbzwHxzGfJMQwS87HsbIc7JcsyJ1aEkT1vDFDeMR8aREVYLx48ex+
FoZgB8Dh3XhCo4Q1ojGtvHjGRWXSHXnDKzf0tr6Thiq8TUINyt6QX3iUWsbKq1KJ
mhvsvkQRluKVjDCRbhQFnAlou2iosoKMb8W7C0hrOt/9LMGoJYruPNj2omXWrTNJ
EYCmiTl4dCcnsQfMFgR3H4S+3X+DuitHtJ0tADH6b5cgkuQ2DXvJxQT0/t+ccW7H
F2wW6U+sj95n9CeM0Rt5RNqvLXh2n9IvMQhH5WikdUYRXrinMspopsDRoZPzvyWD
G+5hm49Zrpl4ayuKjYxS
=RtlU
-END PGP SIGNATURE-
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Plans for CC 15.05.1 or DD 16.xx release?
John Crispin wrote on 19/01/2016: > > there will be a delay. as usual 90% of tapi packages do not build aswell > as the other usual suspects. i wont have time to fix these till early > next week which will delay the 15.05.1 release by a few days. if anyone > wants to dig into these before next week then feel free. Any news on 15.05.1? Or are the telephony packages still keeping the whole release hostage? Hopefully not, as the telephony stuff is used by such a small minority of Openwrt users. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Plans for CC 15.05.1 or DD 16.xx release?
The release will be delayed due to infrastructure problems. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] QMI/NCM/MBIM interfaces netifd ifup event too early
Hi!
I have a situation where I have to react to "ifup" events in OpenWRT,
and I believe that QMI/NCM/MBIM interfaces are sending the "ifup" event
too early, which is before they got an IP address. That is due to the
use of "sub-interfaces" for DHCP IPv4 and DHCP IPv6, as seen in the
/lib/netifd/proto/[ncm|qmi|mbim].sh scripts:
echo "Starting DHCP"
proto_init_update "$ifname" 1
proto_send_update "$interface"
json_init
json_add_string name "${interface}_4"
json_add_string ifname "@$interface"
json_add_string proto "dhcp"
json_close_object
ubus call network add_dynamic "$(json_dump)"
json_init
json_add_string name "${interface}_6"
json_add_string ifname "@$interface"
json_add_string proto "dhcpv6"
json_close_object
ubus call network add_dynamic "$(json_dump)"
Here the "main" interface is marked "up" before the sub-interfaces
"xyz_4" or "xyz_6" are added or got an IP address.
Normally, a WAN, WLAN or a 3G (PPP) interface is only "up" after it got
an IP and when we can start sending data thru it. Also I can not always
trigger on the "xyz_4" interface because in the 3G/PPP case the IP is
directly assigned to "xyz" and no "xyz_4" exists...
Is there any way in netifd that we could avoid the use of the
sub-interfaces here (other interfaces also may have DHCP and DHCPv6 IP
assignement without sub-interface, IMHO), or that the main interface
will only be "up" when at least one of the sub-interfaces is up?
Any pointers welcome, I'm ready to "mess" with the code as well... :)
bruno
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] LXC is broken on Caos Calmer
Hi there, I have tried to run lxc on openwrt but it looks to me that those packages are broken. root@Honeypot:/home/gnuton# lxc-create -t download -n xx Setting up the GPG keyring ERROR: Unable to fetch GPG key from keyserver. lxc_container: lxccontainer.c: create_run_template: 1102 container creation template for xx failed Hi there, I'm writing you because I would like to run lxc on my rasperry pi running Caos Calmer. Below you can see that a few errors I got. root@Honeypot:/home/gnuton# lxc-create -t debian -n xx lxc_container: lxccontainer.c: create_run_template: 1097 No such file or directory - failed to execute template /usr/share/lxc/templates/lxc-debian lxc_container: lxccontainer.c: create_run_template: 1102 container creation template for xx failed lxc_container: lxc_create.c: main: 274 Error creating container xx root@Honeypot:/home/gnuton# opkg files lxc-templates Package lxc-templates (1.1.1-1) is installed on root and has the following files: /usr/share/lxc/templates/lxc-oracle /usr/share/lxc/templates/lxc-plamo /usr/share/lxc/templates/lxc-busybox /usr/share/lxc/templates/lxc-fedora /usr/share/lxc/templates/lxc-sshd /usr/share/lxc/templates/lxc-ubuntu-cloud /usr/share/lxc/templates/lxc-openmandriva /usr/share/lxc/templates/lxc-gentoo /usr/share/lxc/templates/lxc-download /usr/share/lxc/templates/lxc-archlinux /usr/share/lxc/templates/lxc-cirros /usr/share/lxc/templates/lxc-debian /usr/share/lxc/templates/lxc-ubuntu /usr/share/lxc/templates/lxc-centos /usr/share/lxc/templates/lxc-altlinux /usr/share/lxc/templates/lxc-alpine /usr/share/lxc/templates/lxc-opensuse I have also installed LXC LuCi web GUI and it doesn't work too. The GUI would allow me to create a openwrt based conatainer, but the truth is that there is no such template available as you may see from the above list. Digging further I had a look at the source code and I noticed there some problems too for instance https://github.com/openwrt/packages/blob/master/utils/lxc/patches/030-lxc-download.patch points lxc-download to use a not working server. I would like to know what's the status of LXC, is it supposed to work or those packages are unmantained? Cheers, Antonio ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LXC is broken on Caos Calmer
Hi Antonio, On Wed, Feb 10, 2016 at 09:52:25PM +0200, Antonio Aloisio wrote: > Hi there, > I have tried to run lxc on openwrt but it looks to me that those packages > are broken. I'm actively using LXC, however, I use a custom overlayfs method to create OpenWrt containers. > > root@Honeypot:/home/gnuton# lxc-create -t download -n xx > Setting up the GPG keyring > ERROR: Unable to fetch GPG key from keyserver. > lxc_container: lxccontainer.c: create_run_template: 1102 container creation > template for xx failed I manually use debootstrap to setup Debian rootfs and throwing that at LXC works great. I once went through the Debian template and believe it would make sense to fix it up to work on OpenWrt, so LXC becomes more useable. Do you have gnupg installed? If not or if GPG stuff fails for some reason, you can try to to modify the Debian template to use debootstrap having the signature checks disabled (not ideal, obviously). > I have also installed LXC LuCi web GUI and it doesn't work too. > The GUI would allow me to create a openwrt based conatainer, but the truth > is that there is no such template available as you may see from the above > list. I never tried lxc-download nor the LuCI GUI which is afaik just a proof-of-concept and not that usable in it's current state. > Digging further I had a look at the source code and I noticed there some > problems too > for instance > https://github.com/openwrt/packages/blob/master/utils/lxc/patches/030-lxc-download.patch > points lxc-download to use a not working server. If you feel like helping, please suggest a patch via github. > I would like to know what's the status of LXC, is it supposed to work or > those packages are unmantained? Good question... @luka ? Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [lantiq] use "-gt" instead of ">" with [ in /lib/functions/lantiq_dsl.sh
Avoids inadvertent file creation when executing
`/etc/init.d/dsl_control status`.
Signed-off-by: Jonathan A. Kollasch
---
target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
b/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
index a2723f3..ece614b 100755
--- a/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
+++ b/target/linux/lantiq/base-files/lib/functions/lantiq_dsl.sh
@@ -414,13 +414,13 @@ latency_delay() {
[ -z "$idd" ] && idd=0
[ -z "$idu" ] && idu=0
- if [ "$idd" > 100 ]; then
+ if [ "$idd" -gt 100 ]; then
idd_s="Interleave"
else
idd_s="Fast"
fi
- if [ "$idu" > 100 ]; then
+ if [ "$idu" -gt 100 ]; then
idu_s="Interleave"
else
idu_s="Fast"
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LXC is broken on Caos Calmer
Hi there! Here is a few findings about LXC templates available on OpenWRT CC. Just for reference, here below you can see all the templates available on CC and what works and what does not. /usr/share/lxc/templates/lxc-oracle <-- BAD ARCHITECTURE. NO ARM /usr/share/lxc/templates/lxc-plamo <-- depends on "flock". It may work. I get Failed to download /usr/share/lxc/templates/lxc-busybox <-- creates the containers, but doesn't start (busybox no statically linked) /usr/share/lxc/templates/lxc-fedora <-- fails to download /releases/20/Fedora/armhfp/os /usr/share/lxc/templates/lxc-sshd <--- fails requires ssh-keygen. is it available on openwrt? /usr/share/lxc/templates/lxc-ubuntu-cloud <-- no idea what's broken /usr/share/lxc/templates/lxc-openmandriva /usr/share/lxc/templates/lxc-gentoo <-- requires tar. maybe works >220MB. Ran out of disk on /tmp /usr/share/lxc/templates/lxc-download <-- no idea what's wrong /usr/share/lxc/templates/lxc-archlinux <-- fails require pacman. not available /usr/share/lxc/templates/lxc-cirros <-- require tar. works? some problem still with lxc cgroups /usr/share/lxc/templates/lxc-debian <-- requires debootstrap. itäs not a openwrt package /usr/share/lxc/templates/lxc-ubuntu <-- requires debootstrap. itäs not a openwrt package /usr/share/lxc/templates/lxc-centos <-- requires yum. fails container creation /usr/share/lxc/templates/lxc-altlinux <-- requires apt-get. fails container creation /usr/share/lxc/templates/lxc-alpine <-- requires sha256sum. is it available? /usr/share/lxc/templates/lxc-opensuse <-- requires zipper. not available Cheers, Antonio On Wed, Feb 10, 2016 at 10:03 PM, Daniel Golle wrote: > Hi Antonio, > > On Wed, Feb 10, 2016 at 09:52:25PM +0200, Antonio Aloisio wrote: > > Hi there, > > I have tried to run lxc on openwrt but it looks to me that those packages > > are broken. > > I'm actively using LXC, however, I use a custom overlayfs method to > create OpenWrt containers. > > > > root@Honeypot:/home/gnuton# lxc-create -t download -n xx > > Setting up the GPG keyring > > ERROR: Unable to fetch GPG key from keyserver. > > lxc_container: lxccontainer.c: create_run_template: 1102 container > creation > > template for xx failed > > I manually use debootstrap to setup Debian rootfs and throwing that at > LXC works great. I once went through the Debian template and believe it > would make sense to fix it up to work on OpenWrt, so LXC becomes more > useable. Do you have gnupg installed? If not or if GPG stuff fails for > some reason, you can try to to modify the Debian template to use > debootstrap having the signature checks disabled (not ideal, > obviously). > > > I have also installed LXC LuCi web GUI and it doesn't work too. > > The GUI would allow me to create a openwrt based conatainer, but the > truth > > is that there is no such template available as you may see from the above > > list. > > I never tried lxc-download nor the LuCI GUI which is afaik just a > proof-of-concept and not that usable in it's current state. > > > > Digging further I had a look at the source code and I noticed there some > > problems too > > for instance > > > https://github.com/openwrt/packages/blob/master/utils/lxc/patches/030-lxc-download.patch > > points lxc-download to use a not working server. > > If you feel like helping, please suggest a patch via github. > > > I would like to know what's the status of LXC, is it supposed to work or > > those packages are unmantained? > > Good question... @luka ? > > > Cheers > > > Daniel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Native IPv6 broken in trunk
Update: It looks like some new firewall rules that are introduced in newer versions of trunk are stopping IPv6 from working. I turned off Allow-MLD, and 2 blank rules which seem to be there by factory default accept forward any esp and any udp port 500. Also disabled SYN flood protection and Drop Invalid Packets... IPv6 now works. Very weird indeed. Now the only extra thing I need to do is after the router has booted, I need to restart the firewall via /etc/init.d/firewall restart and IPv6 works just fine. Seems the b0rked IPv6 addresses was corrected during the past 1500 commits somewhere and so that is also now working fine. Boils down to firewall rules. Heh. A few less hairs on my head. On 10/02/16 16:27, Adam Kuklycz wrote: Further to this, I have compiled trunk versions 47750 and 47458 which both exhibit the same IPv6 non-routing issue, however with 47458 the IPv6 address is a bit less b0rked... inet6 addr: :::::561e:7d31:631e%3/64 Scope:Global PING ipv6.google.com(sin04s05-in-x0e.1e100.net) 56 data bytes ping: sendmsg: Network unreachable ping: sendmsg: Permission denied ping: sendmsg: Network unreachable ping: sendmsg: Network unreachable ping: sendmsg: Network unreachable ping: sendmsg: Network unreachable ^C --- ipv6.google.com ping statistics --- 6 packets transmitted, 0 received, 100% packet loss, time 5022ms Some commits which caught my eye are the following: 47514 47493 47487 47460/47459 & 47288 Could be totally wrong however and it could be a download during the compile process that causes things to break...but so far I've spent the whole day compiling and trying to narrow down what is causing IPv6 to not work. A build I did on Oct 25, 2015 for revision 47245 works fine with IPv6. Note that I am using Ubuntu 14.04.3 x64 to compile. Any help appreciated TIA Adam On 10/02/16 12:05, Adam Kuklycz wrote: Hi all, I've noticed with current trunk (Designated Driver) and revisions down to 48272 that IPv6 native does not work. Infact when checking via ifconfig -a, on the pppoe-wan interface, the IPv6 address ends up as follows: inet6 addr: ::::bd9f:ac2e:e659:67ee%2010362168/64 Scope:Global I've attached the config file to this email that I used to compile. The /etc/config/network file is as follows: root@rear-gw:~# cat /etc/config/network config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fd10:bc2e:49e1::/48' config interface 'lan' option force_link '1' option type 'bridge' option proto 'static' option netmask '255.255.255.0' option ip6assign '64' option dns '150.101.158.130' option ipaddr '172.18.18.1' option _orig_ifname 'eth0.1 wlan0 wlan0-1 wlan1' option _orig_bridge 'true' option ifname 'eth0.1' config interface 'wan' option proto 'pppoe' option username 'akukl...@dynamic.internode.on.net' option password 'gc7qvhy8v' option peerdns '0' option dns '150.101.158.130' option ifname 'eth0.2' option ipv6 'auto' config interface 'wan6' option proto 'dhcpv6' option dns '2001:44B8:41DC:FE00::3' option peerdns '0' option reqaddress 'try' option reqprefix '64' option ifname '@wan' config switch option name 'switch0' option reset '1' option enable_vlan '1' config switch_vlan option device 'switch0' option vlan '1' option ports '0t 2 3 4 5' config switch_vlan option device 'switch0' option vlan '2' option ports '0t 1' root@rear-gw:~# ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel/build: Fix SetNfsCmdline to work with new .config.set
Le 10/02/2016 03:43, Petr Štetiar a écrit :
> Florian Fainelli [2016-02-09 19:57:22]:
>
>> Le 09/02/2016 12:16, Petr Štetiar a écrit :
>>> Petr Štetiar [2016-02-09 21:04:14]:
>>>
>define Kernel/SetNfsCmdline
> rm -f $(LINUX_DIR)/.config.prev
> - mv $(LINUX_DIR)/.config $(LINUX_DIR)/.config.old
> - grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old >
> $(LINUX_DIR)/.config
> - grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed
> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs
> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config
> + mv $(LINUX_DIR)/.config.set $(LINUX_DIR)/.config.old
> + grep -v "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old >
> $(LINUX_DIR)/.config.set
> + grep "CONFIG_CMDLINE=" $(LINUX_DIR)/.config.old | cut -d\" -f2 | sed
> 's/root=\/dev\/\([a-z0-9]*\)\(.*\)/CONFIG_CMDLINE=\"root=\/dev\/nfs
> ip=dhcp\2\"/' >> $(LINUX_DIR)/.config.set
>endef
This cut/sed kung-fu needs some improvements:
* it doesn't work correctly in case of empty cmdline, CONFIG_CMDLINE=""
* how to handle custom cmdline options? For example I don't want to use
this
hardcoded cmdline options, but use instead options provided by the
bootloader
>>>
>>> Hm, now I'm wondering why is this macro needed at all. In case I'll set
>>> CONFIG_KERNEL_ROOT_NFS=y, then I can set CONFIG_CMDLINE accordingly also,
>>> right?
>>>
>>> Florian, what's your use case for this SetNfsCmdline macro, that you need to
>>> hardcode kernel cmdline options? Thanks.
>>
>> Not all platforms get their command-line from the bootloader, or Device
>> Tree, or whatever, some do actually hardcode the command-line into the
>> kernel, that's what motivated this change in the first place.
>
> I see, but I'm not sure how to handle it properly so it works for other use
> cases as well. Maybe adding something like CONFIG_CMDLINE_NFSROOT option, but
> this seems like overdesigning to me...
>
> FYI, I'm using this base-files-nfs[1] package for development over NFS for a
> few years already, currently on i.MX6 with u-boot like this:
>
> setenv nfsroot /opt/devel/openwrt-master.git/bin/imx6/rootfs
> setenv nfsargs root=/dev/nfs nfsroot=${serverip}:${nfsroot}
> ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:apalis:eth0:off nfsrootdebug
>
> I've noticed, that you've added something similar to the OpenWRT config
> directly:
>
>buildroot: add options to build the kernel for NFS boot
>
> And I've to test it yet - just wondering if we don't need to use similar
> approach to skip network initialization in case we boot over NFS as it's
> currently done in base-files-nfs[1] package.
We do need to skip network initialization yes, your commit looks good to
me, though we would want the default base-files to be nfsroot aware, not
a specific package (seems like you do this because of local
customization, that seems fine).
Grepping for "nfsroot" is not exactly failsafe AFAIR, since you can just
have "root=/dev/nfs" and that would be enough to trump the script. Even
better is probably to look at /proc/mounts.
>
>> I am fine dropping this, since obviously; if you turn on the option you
>> know what you are doing, can you re-submit the patch you think is
>> appropriate?
>
> From my point of view this macro SetNfsCmdline is not needed as you can
> specify CONFIG_CMDLINE directly in your config. If you think also, that we
> don't need this SetNfsCmdline macro, then you can just revert it yourself,
> right? :-)
I just reverted this in r48689
--
Florian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [v3] ar71xx: Support for Ubiquiti UniFi AP AC LITE
Hello,
It seems that whitespace is broken in this patch.
Can you resend it, please?
Thank you,
Vittorio G
On 20/01/2016 10:05:20 CET, p.wa...@gmx.at wrote:
From: P.Wassi
Add support for the Ubiquiti UniFi AP AC LITE
Signed-off-by: P.Wassi
---
This patch adds:
* New machine type
* Code for device setup
* Proper image configuration
* New target for the build system
* Network setup as LAN-only
* Diagnostic LED
* Sysupgrade Support
* ath10k firmware extraction
* Board detection
base-files/etc/board.d/02_network |1
base-files/etc/diag.sh |3
base-files/etc/hotplug.d/firmware/11-ath10k-caldata |3
base-files/lib/ar71xx.sh|3
base-files/lib/upgrade/platform.sh |1
config-4.1 |1
files/arch/mips/ath79/Kconfig.openwrt | 10 +
files/arch/mips/ath79/Makefile |1
files/arch/mips/ath79/mach-ubnt-unifiac.c | 109
files/arch/mips/ath79/machtypes.h |1
generic/profiles/ubnt.mk| 11 ++
image/Makefile | 11 +-
mikrotik/config-default |1
nand/config-default |1
14 files changed, 155 insertions(+), 2 deletions(-)
diff -rupN a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -359,6 +359,7 @@ tl-wa901nd-v2 |\
tl-wa901nd-v3 |\
tl-wr703n |\
tube2h |\
+unifiac |\
wndap360 |\
mynet-rext |\
wp543)
diff -rupN a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -339,7 +339,8 @@ get_status_led() {
unifi)
status_led="ubnt:green:dome"
;;
- uap-pro)
+ uap-pro | \
+ unifiac)
status_led="ubnt:white:dome"
;;
unifi-outdoor-plus)
diff -rupN
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
--- a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -75,6 +75,9 @@ case "$FIRMWARE" in
ath10kcal_extract "ART" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(cat /sys/class/net/eth0/address) +16)
;;
+ unifiac)
+ ath10kcal_extract "EEPROM" 20480 2116
+ ;;
esac
;;
"ath10k/cal-pci-:01:00.0.bin")
diff -rupN a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -905,6 +905,9 @@ ar71xx_board_detect() {
*UniFi)
name="unifi"
;;
+ *"UniFi-AC")
+ name="unifiac"
+ ;;
*"UniFi AP Pro")
name="uap-pro"
;;
diff -rupN a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -262,6 +262,7 @@ platform_check_image() {
wlae-ag300n | \
nbg460n_550n_550nh | \
unifi | \
+ unifiac | \
unifi-outdoor | \
carambola2 | \
weio )
diff -rupN a/target/linux/ar71xx/config-4.1 b/target/linux/ar71xx/config-4.1
--- a/target/linux/ar71xx/config-4.1
+++ b/target/linux/ar71xx/config-4.1
CONFIG_ATH79_MACH_TUBE2H=y
CONFIG_ATH79_MACH_UBNT=y
CONFIG_ATH79_MACH_UBNT_XM=y
+CONFIG_ATH79_MACH_UBNT_UNIFIAC=y
CONFIG_ATH79_MACH_WEIO=y
CONFIG_ATH79_MACH_WHR_HP_G300N=y
CONFIG_ATH79_MACH_WLAE_AG300N=y
diff -rupN a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -1349,6 +1349,16 @@ config ATH79_MACH_UBNT
select ATH79_DEV_M25P80
select ATH79_DEV_USB
+config ATH79_MACH_UBNT_UNIFIAC
+ bool "Ubiquiti UniFi AC (LITE) support"
+ select SOC_QCA956X
+ select ATH79_DEV_AP9X_PCI if PCI
+ select ATH79_DEV_ETH
+ select ATH79_DEV_GPIO_BUTTONS
+ select ATH79_DEV_LEDS_GPIO
+ select ATH79_DEV_M25P80
+ select ATH79_DEV_WMAC
+
config ATH79_MACH_WEIO
bool "WeIO board"
select SOC_AR933X
diff -rupN a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
--- a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
+++ b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
@@ -209,6 +209,7 @@ enum ath79_mach_type {
ATH79_MACH_UBNT_RS, /* Ubiquiti RouterStation */
ATH79_MACH_UBNT_UAP_PRO, /* Ubiquiti UniFi AP Pro */
ATH79_MACH_UBNT_UNIFI, /* Ubiquiti Unifi */
+ ATH79_MACH_UBNT_UNIFIAC, /* Ubiquiti Unifi AC */
ATH79_MACH_UBNT_UNIFI_OUTDOOR
Re: [OpenWrt-Devel] LXC is broken on Caos Calmer
Hi Antonio, thanks for trying all that and reporting back your results! On Thu, Feb 11, 2016 at 12:47:50AM +0200, Antonio Aloisio wrote: > Hi there! > Here is a few findings about LXC templates available on OpenWRT CC. > > Just for reference, here below you can see all the templates available on > CC and what works and what does not. Maybe we should split-up the templates into individual packages, each having its own set of dependencies. > > /usr/share/lxc/templates/lxc-oracle <-- BAD ARCHITECTURE. NO ARM > /usr/share/lxc/templates/lxc-plamo <-- depends on "flock". It may work. I > get Failed to download flock is available as a package, you should be able to install it. > /usr/share/lxc/templates/lxc-busybox <-- creates the containers, but > doesn't start (busybox no statically linked) Well, that's odd, but there's not much we can do. Maybe report that to LXC and let them know not everybody uses glibc... > /usr/share/lxc/templates/lxc-fedora <-- fails to > download /releases/20/Fedora/armhfp/os Also, please report that upstream (check that it wasn't already fixed in more recent versions of LXC) > /usr/share/lxc/templates/lxc-sshd <--- fails requires ssh-keygen. is it > available on openwrt? Installing openssh-keygen, openssh-client and openssh-client-utils may help... > /usr/share/lxc/templates/lxc-ubuntu-cloud <-- no idea what's broken > /usr/share/lxc/templates/lxc-openmandriva > /usr/share/lxc/templates/lxc-gentoo <-- requires tar. maybe works >220MB. > Ran out of disk on /tmp Probably temp directory for LXC should be configurable, so it can go to /mnt/tmp or somewhere with enough space on a specific system... > /usr/share/lxc/templates/lxc-download <-- no idea what's wrong > /usr/share/lxc/templates/lxc-archlinux <-- fails require pacman. not > available I agree it'd be nice to have, I remember that pacstrap was quite painful to get working, I've tried that before... > /usr/share/lxc/templates/lxc-cirros <-- require tar. works? some problem > still with lxc cgroups Did you compile OpenWrt from source? I'm asking because LXC depends on CONFIG_LXC_KERNEL_OPTIONS and CONFIG_LXC_BUSYBOX_OPTIONS to work properly, and I believe this isn't enabled in the binary release of CC. > /usr/share/lxc/templates/lxc-debian <-- requires debootstrap. itäs not a > openwrt package > /usr/share/lxc/templates/lxc-ubuntu <-- requires debootstrap. itäs not a > openwrt package You can install debootstrap, it is available, I've just updated it to the most recent release. > /usr/share/lxc/templates/lxc-centos <-- requires yum. fails container > creation Hm, nobody ever packaged all the foreign-distribution package managers for OpenWrt. It's quite a lot of work... > /usr/share/lxc/templates/lxc-altlinux <-- requires apt-get. fails container > creation Why doesn't the template just you debootstrap...? > /usr/share/lxc/templates/lxc-alpine <-- requires sha256sum. is it available? Try installing coreutils-sha256sum which provides sha256sum > /usr/share/lxc/templates/lxc-opensuse <-- requires zipper. not available Cheers Daniel > > Cheers, > Antonio > > On Wed, Feb 10, 2016 at 10:03 PM, Daniel Golle > wrote: > > > Hi Antonio, > > > > On Wed, Feb 10, 2016 at 09:52:25PM +0200, Antonio Aloisio wrote: > > > Hi there, > > > I have tried to run lxc on openwrt but it looks to me that those packages > > > are broken. > > > > I'm actively using LXC, however, I use a custom overlayfs method to > > create OpenWrt containers. > > > > > > root@Honeypot:/home/gnuton# lxc-create -t download -n xx > > > Setting up the GPG keyring > > > ERROR: Unable to fetch GPG key from keyserver. > > > lxc_container: lxccontainer.c: create_run_template: 1102 container > > creation > > > template for xx failed > > > > I manually use debootstrap to setup Debian rootfs and throwing that at > > LXC works great. I once went through the Debian template and believe it > > would make sense to fix it up to work on OpenWrt, so LXC becomes more > > useable. Do you have gnupg installed? If not or if GPG stuff fails for > > some reason, you can try to to modify the Debian template to use > > debootstrap having the signature checks disabled (not ideal, > > obviously). > > > > > I have also installed LXC LuCi web GUI and it doesn't work too. > > > The GUI would allow me to create a openwrt based conatainer, but the > > truth > > > is that there is no such template available as you may see from the above > > > list. > > > > I never tried lxc-download nor the LuCI GUI which is afaik just a > > proof-of-concept and not that usable in it's current state. > > > > > > > Digging further I had a look at the source code and I noticed there some > > > problems too > > > for instance > > > > > https://github.com/openwrt/packages/blob/master/utils/lxc/patches/030-lxc-download.patch > > > points lxc-download to use a not working server. > > > > If you feel like helping, please suggest a patch via github. > > > > > I would like to know what's the status o
