You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(340) |
Dec
(162) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(456) |
Feb
(319) |
Mar
(493) |
Apr
(555) |
May
(47) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(114) |
Nov
(216) |
Dec
(198) |
2002 |
Jan
(284) |
Feb
(410) |
Mar
(243) |
Apr
(118) |
May
(65) |
Jun
(163) |
Jul
(300) |
Aug
(156) |
Sep
(201) |
Oct
(161) |
Nov
(62) |
Dec
(40) |
2003 |
Jan
(141) |
Feb
(320) |
Mar
(96) |
Apr
(55) |
May
(37) |
Jun
(113) |
Jul
(82) |
Aug
(35) |
Sep
(34) |
Oct
(37) |
Nov
(15) |
Dec
(77) |
2004 |
Jan
(31) |
Feb
(77) |
Mar
(106) |
Apr
(80) |
May
(59) |
Jun
(54) |
Jul
(127) |
Aug
(18) |
Sep
(27) |
Oct
(54) |
Nov
(36) |
Dec
(59) |
2005 |
Jan
(33) |
Feb
(20) |
Mar
(65) |
Apr
(68) |
May
(54) |
Jun
(26) |
Jul
(28) |
Aug
(85) |
Sep
(7) |
Oct
(16) |
Nov
(11) |
Dec
(13) |
2006 |
Jan
(14) |
Feb
(21) |
Mar
(259) |
Apr
(91) |
May
(65) |
Jun
(125) |
Jul
(71) |
Aug
(44) |
Sep
(35) |
Oct
(13) |
Nov
(74) |
Dec
(15) |
2007 |
Jan
(23) |
Feb
(32) |
Mar
(57) |
Apr
(43) |
May
(15) |
Jun
(4) |
Jul
(7) |
Aug
(16) |
Sep
|
Oct
(21) |
Nov
(7) |
Dec
(1) |
2008 |
Jan
(38) |
Feb
(24) |
Mar
(57) |
Apr
(9) |
May
(1) |
Jun
(3) |
Jul
(5) |
Aug
(6) |
Sep
(2) |
Oct
(5) |
Nov
(3) |
Dec
(2) |
2009 |
Jan
(1) |
Feb
(9) |
Mar
(16) |
Apr
(2) |
May
(4) |
Jun
(2) |
Jul
(6) |
Aug
(22) |
Sep
(1) |
Oct
(6) |
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
(5) |
Apr
(40) |
May
(28) |
Jun
(85) |
Jul
(26) |
Aug
(32) |
Sep
(128) |
Oct
(170) |
Nov
(219) |
Dec
(78) |
2011 |
Jan
(58) |
Feb
(95) |
Mar
(36) |
Apr
(14) |
May
(57) |
Jun
(164) |
Jul
(59) |
Aug
(23) |
Sep
(34) |
Oct
(29) |
Nov
(44) |
Dec
(8) |
2012 |
Jan
(33) |
Feb
(67) |
Mar
(79) |
Apr
(37) |
May
(30) |
Jun
(31) |
Jul
(36) |
Aug
(88) |
Sep
(62) |
Oct
(120) |
Nov
(12) |
Dec
(84) |
2013 |
Jan
(31) |
Feb
(9) |
Mar
(13) |
Apr
(30) |
May
(17) |
Jun
(18) |
Jul
(24) |
Aug
(5) |
Sep
(4) |
Oct
(39) |
Nov
(6) |
Dec
(2) |
2014 |
Jan
(56) |
Feb
(34) |
Mar
(6) |
Apr
(9) |
May
(1) |
Jun
(16) |
Jul
(83) |
Aug
(39) |
Sep
(10) |
Oct
(50) |
Nov
(42) |
Dec
(31) |
2015 |
Jan
(40) |
Feb
(18) |
Mar
(116) |
Apr
(95) |
May
(14) |
Jun
(10) |
Jul
(60) |
Aug
(46) |
Sep
(47) |
Oct
(34) |
Nov
(24) |
Dec
(58) |
2016 |
Jan
(39) |
Feb
(18) |
Mar
(98) |
Apr
(13) |
May
(5) |
Jun
(1) |
Jul
(7) |
Aug
|
Sep
(1) |
Oct
(14) |
Nov
(1) |
Dec
(2) |
2017 |
Jan
(32) |
Feb
|
Mar
|
Apr
(3) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
(7) |
Oct
(15) |
Nov
(2) |
Dec
(1) |
2018 |
Jan
(1) |
Feb
(24) |
Mar
(4) |
Apr
(8) |
May
|
Jun
(6) |
Jul
(2) |
Aug
(6) |
Sep
|
Oct
(2) |
Nov
(6) |
Dec
|
2019 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
2020 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(5) |
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
(1) |
2021 |
Jan
(1) |
Feb
(6) |
Mar
(7) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(9) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
(15) |
May
(4) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: KP K. <ka...@us...> - 2019-02-12 16:41:55
|
On Fr, 2019-01-25 at 15:53 +0100, KP Kirchdoerfer via leaf-devel wrote: > Hi Andrew; > > On Do, 2019-01-24 at 17:41 +0200, Andrew wrote: > > Hi all. > > > > I upgraded one of BRASes to fresh LEAF 6.2 - and I saw that a lot > > of > > CPU > > time is wasted by spectre v2 protection: > > > > PerfTop: 12411 irqs/sec kernel:97.7% exact: 0.0% [4000Hz > > cycles], (all, 4 CPUs) > > ------------------------------------------------------------------- > > ------------------------------------------------------------------- > > --------------------------------- > > > > 6.63% [kernel] [k] __indirect_thunk_start > > 3.29% [kernel] [k] igb_alloc_rx_buffers > > 2.82% [kernel] [k] memcpy > > 2.69% [kernel] [k] ipt_do_table > > 2.03% [kernel] [k] fib_table_lookup > > 1.89% [kernel] [k] __netif_receive_skb_core > > 1.66% [kernel] [k] htb_dequeue > > 1.62% [kernel] [k] __skb_flow_dissect > > 1.56% [kernel] [k] igb_xmit_frame_ring > > 1.45% bird [.] 0x0000000000006a5c > > 1.41% [kernel] [k] __dev_queue_xmit > > 1.39% [kernel] [k] fib_table_flush > > 1.29% [kernel] [k] leaf_walk_rcu > > 1.25% [kernel] [k] irq_entries_start > > 1.22% [kernel] [k] tcp_packet > > > > Meltdown/spectre vulnerabilities are 1) exploitable mostly by > > local-running untrusted code, and 2) just can grant read access to > > some > > protected memory pages (for ex., FS cache which can contain > > passwords). > > > > I think that this isn't a cases which are suitable for LEAF box > > (which > > runs only trusted code, and which has no or almost no valuable > > plaintext > > data). > > You may be right, but better safe than sorry. > > > I disabled it via kernel options, but maybe it'll be good to > > disable > > these protections in kernel at build time? > > > > Or as option, these protections may be disabled by default in > > kernel > > command line, with mention in documentation about this. > > > > Any thoughts? > > Yes, I prefer The last one - "disabled by default on the kernel > command > line, but included in the kernel, and document how to enable > protection > by changing the kernel command line. > > Eventually the other way round - document how to disable the > protection > and gain some more CPU time with disabling in kernel command line, as > you did? > > Either of these would be fine with me. > What ever you choose, let me know what I should add to the wiki et > el. I've looked into again and we need to make a decision. First: it's the Spectre_2 fix wasting CPU cycles, it can be disavbled during boot with "spectre_v2=off" on the command line in syslinux.cfg. Spectre_v2 (CVE-2017-5715: variant 2 - branch target injection) is described as "Local attackers could use mis-predicted branches to speculatively execute code patterns that in turn could be made to leak otherwise non-readable content in the same address space,..." Andrew made the point that we do not have "local attackers" so let's turn it off by default and save CPU cycles/performance On the other hand "local attackers" might not be users, but malicious software delivered with an update of something we build but do not fully understand the implications - I agree this is a very theoritical example. Anyway a decision has to be made: Should the default be - be as secure as possible (probably without reason) and avoiding the perfomance penalty is up to the user by changing the kernel commandline in syslinux.cfg versus - disable Spectre V2 on the kernel commandline and it's up to the user to decide wether he want's to change back to maximum theoretical security even it has a performace issue. Opinions are welcome. kp |
From: KP K. <ka...@us...> - 2019-01-25 15:12:54
|
Hi Andrew; On Do, 2019-01-24 at 17:41 +0200, Andrew wrote: > Hi all. > > I upgraded one of BRASes to fresh LEAF 6.2 - and I saw that a lot of > CPU > time is wasted by spectre v2 protection: > > PerfTop: 12411 irqs/sec kernel:97.7% exact: 0.0% [4000Hz > cycles], (all, 4 CPUs) > ------------------------------------------------------------------- > ------------------------------------------------------------------- > --------------------------------- > > 6.63% [kernel] [k] __indirect_thunk_start > 3.29% [kernel] [k] igb_alloc_rx_buffers > 2.82% [kernel] [k] memcpy > 2.69% [kernel] [k] ipt_do_table > 2.03% [kernel] [k] fib_table_lookup > 1.89% [kernel] [k] __netif_receive_skb_core > 1.66% [kernel] [k] htb_dequeue > 1.62% [kernel] [k] __skb_flow_dissect > 1.56% [kernel] [k] igb_xmit_frame_ring > 1.45% bird [.] 0x0000000000006a5c > 1.41% [kernel] [k] __dev_queue_xmit > 1.39% [kernel] [k] fib_table_flush > 1.29% [kernel] [k] leaf_walk_rcu > 1.25% [kernel] [k] irq_entries_start > 1.22% [kernel] [k] tcp_packet > > Meltdown/spectre vulnerabilities are 1) exploitable mostly by > local-running untrusted code, and 2) just can grant read access to > some > protected memory pages (for ex., FS cache which can contain > passwords). > > I think that this isn't a cases which are suitable for LEAF box > (which > runs only trusted code, and which has no or almost no valuable > plaintext > data). You may be right, but better safe than sorry. > I disabled it via kernel options, but maybe it'll be good to disable > these protections in kernel at build time? > > Or as option, these protections may be disabled by default in kernel > command line, with mention in documentation about this. > > Any thoughts? Yes, I prefer The last one - "disabled by default on the kernel command line, but included in the kernel, and document how to enable protection by changing the kernel command line. Eventually the other way round - document how to disable the protection and gain some more CPU time with disabling in kernel command line, as you did? Either of these would be fine with me. What ever you choose, let me know what I should add to the wiki et el. kp > > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Andrew <ni...@se...> - 2019-01-24 16:15:11
|
Hi all. I upgraded one of BRASes to fresh LEAF 6.2 - and I saw that a lot of CPU time is wasted by spectre v2 protection: PerfTop: 12411 irqs/sec kernel:97.7% exact: 0.0% [4000Hz cycles], (all, 4 CPUs) ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- 6.63% [kernel] [k] __indirect_thunk_start 3.29% [kernel] [k] igb_alloc_rx_buffers 2.82% [kernel] [k] memcpy 2.69% [kernel] [k] ipt_do_table 2.03% [kernel] [k] fib_table_lookup 1.89% [kernel] [k] __netif_receive_skb_core 1.66% [kernel] [k] htb_dequeue 1.62% [kernel] [k] __skb_flow_dissect 1.56% [kernel] [k] igb_xmit_frame_ring 1.45% bird [.] 0x0000000000006a5c 1.41% [kernel] [k] __dev_queue_xmit 1.39% [kernel] [k] fib_table_flush 1.29% [kernel] [k] leaf_walk_rcu 1.25% [kernel] [k] irq_entries_start 1.22% [kernel] [k] tcp_packet Meltdown/spectre vulnerabilities are 1) exploitable mostly by local-running untrusted code, and 2) just can grant read access to some protected memory pages (for ex., FS cache which can contain passwords). I think that this isn't a cases which are suitable for LEAF box (which runs only trusted code, and which has no or almost no valuable plaintext data). I disabled it via kernel options, but maybe it'll be good to disable these protections in kernel at build time? Or as option, these protections may be disabled by default in kernel command line, with mention in documentation about this. Any thoughts? |
From: Erich T. <eri...@th...> - 2019-01-17 13:43:19
|
Hi Am 17.01.2019 um 06:03 schrieb Andrew: > I didn't work earlier with PGP, can you pls write quick cheatsheet how > to add key to keyring and how to sign packets on build? Just to hide > annoying warnings at boot of custom image. > Off the top of my head..... The steps are actually quite straightforward, I had to look them up as I don't have access to my development system. First be reminded that the gpg installation on your development system will probably be gpg2 with quite an extended command set. The gpg version used in initerd is gpg1, but for our purposes they are compatible. 1) generate a gpg keypair, it will probably be placed somewhere in ~yourname/.gnupg. https://www.gnupg.org/gph/en/manual/c14.html#AEN25 2) use the generated key to inline sign the affected or all packages, be careful just to sign unsigned packages. https://www.gnupg.org/gph/en/manual/x135.html 3) export the public key from your keyring and add it to the keyring which is used to build initrd, you may need to use gpg1 for this purpose. https://www.gnupg.org/gph/en/manual/x56.html I sent the details to KP some time ago. 4) use the newly built initrd to boot your system with the packages signed with your new key. 5) if you want to make this permanent, save the extended keyring to git. I guess we will have to define a policy who will add keys to our git repository but I guess KP is the key person. regards ET |
From: KP K. <ka...@us...> - 2018-11-04 12:37:55
|
On So, 2018-11-04 at 13:53 +0200, Andrew wrote: > On 04.11.2018 12:25, KP Kirchdoerfer via leaf-devel wrote: > > Hi Andrew; > > > > On Sa, 2018-11-03 at 20:43 +0200, Andrew wrote: > > > On 03.11.2018 20:20, KP Kirchdoerfer via leaf-devel wrote: > > > > Hi Andrew; > > > > > > > > did a rebuild from a scratch > > > > > > > > On Sa, 2018-11-03 at 18:56 +0200, Andrew wrote: > > > > > Hi all. > > > > > > > > > > I have a troubles with packets building: > > > > > > > > > > 1. squid - it can't find some symbols (__atomic_store_8 and > > > > > so > > > > > on) > > > > > on > > > > > linking > > > > I confirm, I see this too; just wondering -I've build and > > > > rebuild > > > > several times before. > > It works for x86_64 toolchain, but fails for i386, I believe I've > > found > > the issue and test. > > It also fails for other reasons on armv6 (armv8?) - needs more > > work. > Yes. > Also, I tried to build x86_64 toolchain - and I've got a lot of > errors. > And it seems like a lot of libs are linked with system libs, not > with > target libs. It's quite strange. Indeed it is, I build the complete toolchain without errors and run the resulting kernel/packages on my router. kp > > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Andrew <ni...@se...> - 2018-11-04 11:53:32
|
On 04.11.2018 12:25, KP Kirchdoerfer via leaf-devel wrote: > Hi Andrew; > > On Sa, 2018-11-03 at 20:43 +0200, Andrew wrote: >> On 03.11.2018 20:20, KP Kirchdoerfer via leaf-devel wrote: >>> Hi Andrew; >>> >>> did a rebuild from a scratch >>> >>> On Sa, 2018-11-03 at 18:56 +0200, Andrew wrote: >>>> Hi all. >>>> >>>> I have a troubles with packets building: >>>> >>>> 1. squid - it can't find some symbols (__atomic_store_8 and so >>>> on) >>>> on >>>> linking >>> I confirm, I see this too; just wondering -I've build and rebuild >>> several times before. > It works for x86_64 toolchain, but fails for i386, I believe I've found > the issue and test. > It also fails for other reasons on armv6 (armv8?) - needs more work. Yes. Also, I tried to build x86_64 toolchain - and I've got a lot of errors. And it seems like a lot of libs are linked with system libs, not with target libs. It's quite strange. |
From: KP K. <ka...@us...> - 2018-11-04 10:26:24
|
Hi Andrew; On Sa, 2018-11-03 at 20:43 +0200, Andrew wrote: > On 03.11.2018 20:20, KP Kirchdoerfer via leaf-devel wrote: > > Hi Andrew; > > > > did a rebuild from a scratch > > > > On Sa, 2018-11-03 at 18:56 +0200, Andrew wrote: > > > Hi all. > > > > > > I have a troubles with packets building: > > > > > > 1. squid - it can't find some symbols (__atomic_store_8 and so > > > on) > > > on > > > linking > > I confirm, I see this too; just wondering -I've build and rebuild > > several times before. It works for x86_64 toolchain, but fails for i386, I believe I've found the issue and test. It also fails for other reasons on armv6 (armv8?) - needs more work. > > > 2. vnstat - I have error with packaging (it can't resolve user > > > 'www-data' that is specified in buildtool.cfg); but on next retry > > > it > > > is > > > packaged successfully > > Works for me. > > > > kp > maybe you have 'www-data' user/group in your host passwd? > > I'm not sure that buildpacket uses staging passwd instead of system > one. As you pointed out previously for webconf, we should use the number of staging /etc/passwd /etc/group. So 33:33 should be the correct entry in buildtool.cfg for vnstat for owner and group. kp > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Andrew <ni...@se...> - 2018-11-03 18:43:47
|
On 03.11.2018 20:20, KP Kirchdoerfer via leaf-devel wrote: > Hi Andrew; > > did a rebuild from a scratch > > On Sa, 2018-11-03 at 18:56 +0200, Andrew wrote: >> Hi all. >> >> I have a troubles with packets building: >> >> 1. squid - it can't find some symbols (__atomic_store_8 and so on) >> on >> linking > I confirm, I see this too; just wondering -I've build and rebuild > several times before. > >> 2. vnstat - I have error with packaging (it can't resolve user >> 'www-data' that is specified in buildtool.cfg); but on next retry it >> is >> packaged successfully > Works for me. > > kp maybe you have 'www-data' user/group in your host passwd? I'm not sure that buildpacket uses staging passwd instead of system one. |
From: KP K. <ka...@us...> - 2018-11-03 18:21:33
|
Hi Andrew; did a rebuild from a scratch On Sa, 2018-11-03 at 18:56 +0200, Andrew wrote: > Hi all. > > I have a troubles with packets building: > > 1. squid - it can't find some symbols (__atomic_store_8 and so on) > on > linking I confirm, I see this too; just wondering -I've build and rebuild several times before. > 2. vnstat - I have error with packaging (it can't resolve user > 'www-data' that is specified in buildtool.cfg); but on next retry it > is > packaged successfully Works for me. kp > Anybody has such troubles? > > > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Andrew <ni...@se...> - 2018-11-03 17:31:58
|
Hi all. I have a troubles with packets building: 1. squid - it can't find some symbols (__atomic_store_8 and so on) on linking 2. vnstat - I have error with packaging (it can't resolve user 'www-data' that is specified in buildtool.cfg); but on next retry it is packaged successfully Anybody has such troubles? |
From: KP K. <ka...@us...> - 2018-10-28 10:02:28
|
Hi Erich; On Fr, 2018-10-26 at 13:42 +0200, Erich Titl wrote: > Hi > > I believe we could drop the X86-MCE from the WRAP configuration. It > feels like it is not supported > > kerberos# dmesg | grep mce > [ 3.255370] mce: Unable to init device /dev/mcelog (rc: -5) Which kernel version do you run? Note: Kernel 4.14 don't install the deprecated /dev/mcelog device. kp > cheers > > ET > > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Erich T. <eri...@th...> - 2018-10-26 11:42:46
|
Hi I believe we could drop the X86-MCE from the WRAP configuration. It feels like it is not supported kerberos# dmesg | grep mce [ 3.255370] mce: Unable to init device /dev/mcelog (rc: -5) cheers ET |
From: Erich T. <eri...@th...> - 2018-08-25 15:08:38
|
Hi John Am 25.08.2018 um 12:43 schrieb John Sager: > I do use bash anyway for something else on my firewall, and so I've just > used it on the VPN server as well. wireguard/buildtool.cfg has a package > dependency on bash. > > I have build environments for both 6.0.6 and 6.1.4 and I have built > wireguard on both together with kernel (to build the module) and kmodules > and initrd as they both change. I'll talk to KP about getting on git so I > can commit the wireguard stuff. Good, you may want to branch off the git branch apkg-using-gpg as it has all the latest initrd stuff which has not been merged to master yet. I typically leave the task to merge to master to KP. Be aware, the latest initrd looks for gpg signed packages and root.linuxrc will barf for unsigned ones, although still accept it. cheers ET |
From: John S. <jo...@sa...> - 2018-08-25 08:06:06
|
Erich, This /dev/fd thing is a bit more nuanced than I thought. The configure script for bash tests for its presence, and will try other ways of doing the subprocess pipes if not (e.g using /proc/self/fd on Linux), but the test runs for the system that the toolchain is hosted on, and there are no specific --enable options that could influence this feature for the target system. So inevitably a build of Bering-uClibc on more or less any modern flavour of Linux will require /dev/fd to be present on the target to support bash (and maybe other programs). John On 24/08/18 19:19, Erich Titl wrote: > Hi John > > Am 24.08.2018 um 12:11 schrieb John Sager: >> Reading around the subject it seems that /dev/fd -> /proc/self/fd has been >> around since at least Linux 2.6, and there should also be soft links for >> /dev/stdin, /dev/stdout /dev/stderr: >> >> ln -s /dev/self/fd/0 /dev/stdin >> ln -s /dev/self/fd/1 /dev/stdout >> ln -s /dev/self/fd/2 /dev/stderr >> >> Perhaps these should also be added to the root.linuxrc script to avoid any >> issues with code that depends on them. > > Should not hurt, we could include this for the next release, which may > have the new initrd. > > cheers > > ET > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel > |
From: Erich T. <eri...@th...> - 2018-08-24 18:19:21
|
Hi John Am 24.08.2018 um 12:11 schrieb John Sager: > Reading around the subject it seems that /dev/fd -> /proc/self/fd has been > around since at least Linux 2.6, and there should also be soft links for > /dev/stdin, /dev/stdout /dev/stderr: > > ln -s /dev/self/fd/0 /dev/stdin > ln -s /dev/self/fd/1 /dev/stdout > ln -s /dev/self/fd/2 /dev/stderr > > Perhaps these should also be added to the root.linuxrc script to avoid any > issues with code that depends on them. Should not hurt, we could include this for the next release, which may have the new initrd. cheers ET |
From: John S. <jo...@sa...> - 2018-08-24 10:11:33
|
Reading around the subject it seems that /dev/fd -> /proc/self/fd has been around since at least Linux 2.6, and there should also be soft links for /dev/stdin, /dev/stdout /dev/stderr: ln -s /dev/self/fd/0 /dev/stdin ln -s /dev/self/fd/1 /dev/stdout ln -s /dev/self/fd/2 /dev/stderr Perhaps these should also be added to the root.linuxrc script to avoid any issues with code that depends on them. John On 23/08/18 22:41, John Sager wrote: > Erich, > > > On 23/08/18 21:31, Erich Titl wrote: >> Hi John > > ... > >> The change to root.linuxrc >>> is to generate a link from /dev/fd to /proc/self/fd. >> >> Is proc/self/fd provided by the kernel module? Can this link be >> generated by the startup script? >> > > /proc/self is a standard feature of the kernel and it is a soft link to > /proc/<N> where N is the PID of this process. I guess most modern Linux > distributions, and also *BSD apparently, have /dev/fd as a link to > /proc/self/fd if bash assumes it will be there. > > >> >> I believe the easiest way would be to discuss this on leaf-devel and I >> hope you can be tricked into integrating it yourself in the repository. >> Should you not be susbscribed to leaf-devel then please do so. I am sure >> KP would be very keen to welcome a new contributor. > > I have just joined leaf-devel so I'll follow up on there. > > > John > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel > |
From: John S. <jo...@sa...> - 2018-08-23 22:10:13
|
Erich, On 23/08/18 21:31, Erich Titl wrote: > Hi John ... > The change to root.linuxrc >> is to generate a link from /dev/fd to /proc/self/fd. > > Is proc/self/fd provided by the kernel module? Can this link be > generated by the startup script? > /proc/self is a standard feature of the kernel and it is a soft link to /proc/<N> where N is the PID of this process. I guess most modern Linux distributions, and also *BSD apparently, have /dev/fd as a link to /proc/self/fd if bash assumes it will be there. > > I believe the easiest way would be to discuss this on leaf-devel and I > hope you can be tricked into integrating it yourself in the repository. > Should you not be susbscribed to leaf-devel then please do so. I am sure > KP would be very keen to welcome a new contributor. I have just joined leaf-devel so I'll follow up on there. John |
From: Erich T. <eri...@th...> - 2018-08-23 20:31:34
|
Hi John HI everybody and sorry for cross posting Am 23.08.2018 um 20:20 schrieb John Sager: > Erich, > > I have used Bering-uClibc for many years as a router/firewall and recently I > have become interested in a new VPN server - wireguard: > https://www.wireguard.com. This is a lightweight VPN server - much more so > than IPSec or OpenVPN. It runs in a kernel module and has a control > application to set it up. I now have a build environment for Bering-uClibc > v6.1.4, in the attached archive wireguard_bering6.tgz. I haven't included > the source but the latest version can be downloaded from > https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20180809.tar.xz > > The build environment builds the kernel module, puts it in kernel/extra & > then runs depmod. It then builds the control application and the lrp package > contains this, a startup script, an init.d script that calls it, and a dummy > VPN server config. > > However to integrate with Bering-uClibc it needs a couple of changes, one to > busybox.config and one to root.linuxrc in initrd. The startup script, > wg-quick, requires bash, I guess this can be easily integrated using a dependency. and it needs 'readlink -f' hence the change to > busybox.config to include this readlink option. OK The change to root.linuxrc > is to generate a link from /dev/fd to /proc/self/fd. Is proc/self/fd provided by the kernel module? Can this link be generated by the startup script? The startup script uses > the construct: > 'wg setconf "$INTERFACE" <(echo "$WG_CONFIG")' to set up the VPN > configuration from an environment variable. When piping the output of the > echo command in the subprocess into wg, bash uses /dev/fd/N to refer to the > pipe, where N is the fd number of the script end of the pipe. > > Wireguard is currently very much in beta with fairly regular snapshots so > you may not want to include it in a mainline distribution of Bering yet but > it's there to play with. Very interesting work. I heard about wireguard some time ago but did not pay much attention. I believe the easiest way would be to discuss this on leaf-devel and I hope you can be tricked into integrating it yourself in the repository. Should you not be susbscribed to leaf-devel then please do so. I am sure KP would be very keen to welcome a new contributor. About the beta stage, as long as this is packed in a .lrp file, everybody is free to use it or not. Being just a small group forces us to rely heavily on the work done uplink. > > Also, I found an issue with ntpd.lrp. Currently it doesn't save the drift > file /var/lib/ntp/ntp.drift, which stores the frequency error of the system > clock to allow ntp to synchronise quickly on reboot. The file ntpd.local > should also have the line 'var/lib/ntp' to save that directory. This can be done easily. I am working right now on a rather big overhaul of initrd and signed packages, so I might be a bit distracted. Thank you anyway for the heads up and hope to see you on leaf-devel cheers ET |
From: Andrew <ni...@se...> - 2018-07-04 16:51:32
|
Hi. I'll try to look on it at this weekend. On 04.07.2018 19:28, KP Kirchdoerfer via leaf-devel wrote: > Hi Andrew; > > On So, 2018-06-24 at 21:32 +0300, Andrew wrote: >> Hm... Maybe it'll be a good solution. Except cases when somebody >> will >> need fresh/non-default firmware (is it really needed?) > Do you plan to change/fix this for 6.1.4? > > kp > >> On 24.06.2018 19:26, Erich Titl wrote: >>> Hi Andrew >>> >>> Am 24.06.2018 um 10:32 schrieb Andrew: >>>> Ok, initrd may be better place for it. >>> I was trying to find firmware within out packages and I failed in >>> my set >>> up. There is a firmware.tgz which we are distributing, so >>> installing >>> firmware appears to be a manual process. >>> >>> We could include it into the modules squashfs unpacked and then >>> build a >>> symbolic link from /lib/firmware to it, so it becomes available to >>> the >>> driver when this squashfs is mounted. >>> >>> Then it would not be necessary to save it to configdb and we would >>> always have the latest firmware. >>> >>> cheers >>> >>> ET >>> >> >> ------------------------------------------------------------------- >> ----------- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> >> _______________________________________________ >> leaf-devel mailing list >> lea...@li... >> https://lists.sourceforge.net/lists/listinfo/leaf-devel > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: KP K. <ka...@us...> - 2018-07-04 16:28:04
|
Hi Andrew; On So, 2018-06-24 at 21:32 +0300, Andrew wrote: > Hm... Maybe it'll be a good solution. Except cases when somebody > will > need fresh/non-default firmware (is it really needed?) Do you plan to change/fix this for 6.1.4? kp > On 24.06.2018 19:26, Erich Titl wrote: > > Hi Andrew > > > > Am 24.06.2018 um 10:32 schrieb Andrew: > > > Ok, initrd may be better place for it. > > > > I was trying to find firmware within out packages and I failed in > > my set > > up. There is a firmware.tgz which we are distributing, so > > installing > > firmware appears to be a manual process. > > > > We could include it into the modules squashfs unpacked and then > > build a > > symbolic link from /lib/firmware to it, so it becomes available to > > the > > driver when this squashfs is mounted. > > > > Then it would not be necessary to save it to configdb and we would > > always have the latest firmware. > > > > cheers > > > > ET > > > > > ------------------------------------------------------------------- > ----------- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Andrew <ni...@se...> - 2018-06-24 18:32:20
|
Hm... Maybe it'll be a good solution. Except cases when somebody will need fresh/non-default firmware (is it really needed?) On 24.06.2018 19:26, Erich Titl wrote: > Hi Andrew > > Am 24.06.2018 um 10:32 schrieb Andrew: >> Ok, initrd may be better place for it. > I was trying to find firmware within out packages and I failed in my set > up. There is a firmware.tgz which we are distributing, so installing > firmware appears to be a manual process. > > We could include it into the modules squashfs unpacked and then build a > symbolic link from /lib/firmware to it, so it becomes available to the > driver when this squashfs is mounted. > > Then it would not be necessary to save it to configdb and we would > always have the latest firmware. > > cheers > > ET > |
From: Erich T. <eri...@th...> - 2018-06-24 16:27:16
|
Hi Andrew Am 24.06.2018 um 10:32 schrieb Andrew: > Ok, initrd may be better place for it. I was trying to find firmware within out packages and I failed in my set up. There is a firmware.tgz which we are distributing, so installing firmware appears to be a manual process. We could include it into the modules squashfs unpacked and then build a symbolic link from /lib/firmware to it, so it becomes available to the driver when this squashfs is mounted. Then it would not be necessary to save it to configdb and we would always have the latest firmware. cheers ET |
From: Andrew <ni...@se...> - 2018-06-24 08:33:11
|
Ok, initrd may be better place for it. On 24.06.2018 07:17, Erich Titl wrote: > Hi Andrew > > Am 23.06.2018 um 19:41 schrieb Andrew: >> On 23.06.2018 17:56, Erich Titl wrote: >>> Hi Andrew >>> > ...>> >>> ET >> Some NIC drivers (for ex., broadcom) requires firmware in /lib/firmware. >> And currently we have no way to place firmware at /lib/firmware during >> boot (except making record in local.local - which isn't clean for users). > I see. I assume the firmware gets loaded when the module is initialized, > so why not place this in init where the modules are loaded. IMHO that > would be the place to choose. > > ET > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Erich T. <eri...@th...> - 2018-06-24 04:18:45
|
Hi Andrew Am 23.06.2018 um 19:41 schrieb Andrew: > On 23.06.2018 17:56, Erich Titl wrote: >> Hi Andrew >> ...>> >> ET > Some NIC drivers (for ex., broadcom) requires firmware in /lib/firmware. > And currently we have no way to place firmware at /lib/firmware during > boot (except making record in local.local - which isn't clean for users). I see. I assume the firmware gets loaded when the module is initialized, so why not place this in init where the modules are loaded. IMHO that would be the place to choose. ET |
From: Andrew <ni...@se...> - 2018-06-23 18:13:31
|
On 23.06.2018 17:56, Erich Titl wrote: > Hi Andrew > >> -------- Weitergeleitete Nachricht -------- >> Betreff: [leaf:bering-uclibc] New commit [90bb32] by Andrew Denisenko >> Datum: Sat, 23 Jun 2018 14:18:02 -0000 >> Von: LEAF Linux Embedded Appliance Framework Git repository >> <no...@be...> >> Antwort an: LEAF Linux Embedded Appliance Framework Git repository >> <no...@be...> >> An: LEAF Linux Embedded Appliance Framework Git repository >> <no...@be...> >> >> >> >> Branch: master >> >> etc: mark /lib/firmware as local (to store in configdb) >> >> it stored earlier to moddb, but we dropped out moddb support >> > Why do you need to store firmware? Unless you are using your own > firmware which is not part of the distribution there is no need for this. > > If you have your own firmware then either make it part of the distro or > build your own package with it. > > cheers > > ET Some NIC drivers (for ex., broadcom) requires firmware in /lib/firmware. And currently we have no way to place firmware at /lib/firmware during boot (except making record in local.local - which isn't clean for users). |