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: Erich T. <eri...@th...> - 2021-11-22 20:27:29
|
Hi KP Am 22.11.2021 um 19:38 schrieb Erich Titl: > Hi KP > ....> >> >> For rtty you may need libevdev2 on the host. >> Reading package lists... Done Building dependency tree Reading state information... Done libevdev2 is already the newest version (1.9.0+dfsg-1ubuntu0.1). mega@leafbuilder:~/leaf/devel/bering-uclibc$ sudo apt-get install libevdev-dev Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: libevdev-doc The following NEW packages will be installed: libevdev-dev 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 48.7 kB of archives. After this operation, 287 kB of additional disk space will be used. Get:1 http://ch.archive.ubuntu.com/ubuntu focal-updates/main amd64 libevdev-dev amd64 1.9.0+dfsg-1ubuntu0.1 [48.7 kB] Fetched 48.7 kB in 1s (59.2 kB/s) Selecting previously unselected package libevdev-dev:amd64. (Reading database ... 148548 files and directories currently installed.) Preparing to unpack .../libevdev-dev_1.9.0+dfsg-1ubuntu0.1_amd64.deb ... Unpacking libevdev-dev:amd64 (1.9.0+dfsg-1ubuntu0.1) ... Setting up libevdev-dev:amd64 (1.9.0+dfsg-1ubuntu0.1) ... Processing triggers for man-db (2.9.1-1) ... mega@leafbuilder:~/leaf/devel/bering-uclibc$ ./buildtool.pl build rtty make the list of required source packages: nothing to do [0.K.] make the list of required build packages: rtty [0.K.] build source/package: rtty ------------------------ calling 'make build' for rtty make build failed for /home/mega/leaf/devel/bering-uclibc/source/i486-unknown-linux-uclibc/rtty/buildtool.mk , please have a look at the logfile /home/mega/leaf/devel/bering-uclibc/log/buildtoollog at /home/mega/leaf/devel/bering-uclibc/buildtool/Make.pm line 424. make: Entering directory '/home/mega/leaf/devel/bering-uclibc/source/i486-unknown-linux-uclibc/rtty' mkdir -p /home/mega/leaf/devel/bering-uclibc/build/i486-unknown-linux-uclibc/rtty mkdir -p /home/mega/leaf/devel/bering-uclibc/build/i486-unknown-linux-uclibc/rtty/etc/init.d mkdir -p /home/mega/leaf/devel/bering-uclibc/build/i486-unknown-linux-uclibc/rtty/etc/default ( cd rtty-7.4.2; cmake . -DCMAKE_C_COMPILER=i486-unknown-linux-uclibc-gcc -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_FIND_ROOT_PATH=/home/mega/leaf/devel/bering-uclibc/build/i486-unknown-linux-uclibc/rtty ) CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message): Could NOT find Libev (missing: LIBEV_LIBRARY LIBEV_INCLUDE_DIR) Call Stack (most recent call first): /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE) cmake/Modules/FindLibev.cmake:25 (find_package_handle_standard_args) src/CMakeLists.txt:7 (find_package) cheers ET |
From: Erich T. <eri...@th...> - 2021-11-22 18:39:26
|
Hi KP Am 22.11.2021 um 17:03 schrieb KP.Kirchdoerfer: > Hi Erich > > Am Sonntag, 21. November 2021, 20:05:18 CET schrieb Erich Titl: >> Hi Folks >> >> OK I may be a bit old fashioned as I believe a build system is supposed >> to run without hickups and definitely without crashing. > > Agreed. > >> Ours is not. >> >> the following packages fail to build for i486 >> >> protobuf-c,kismet,rtty,pmacctd,ca-certificates > > for protobuf-c (and therefor kismet you need a protobuf-c compiler on the > host. So basically to compile with itself. > > like > protobuf-c-compiler 1.3.3-1build2 amd64 > Protocol Buffers C compiler (protobuf-c) > > on an ubuntu system. So much for portable code. > > For rtty you may need libevdev2 on the host. > dito. > The remaining packages listed above should compile AFAIK without prerequisites > - at least it does for me. Will have a look > > What says the logs? For protobuf-c there is something missing when the build tries to execute protoc. protoc is built but is missing something. > >> Also in the current master mimalloc fails, I fixed that in my >> environment but I feel like this should be done in a generic way, e.g. >> the standard should not crash. > > A more generic solution shall be "kernel based" - it fails with the i486/wrap > kernel, but shall build with i686 (and geode?). > It build with arm and x86_64 toolchains. Yes, basically this should be built in either the configure code which then can decide to abort cleanly or like in my case I checked for the buildtool environment and skipped the build. Of course buildpacket will barf but that is the least of my concerns. cheers ET |
From: KP.Kirchdoerfer <ka...@be...> - 2021-11-22 16:22:45
|
Hi Erich Am Sonntag, 21. November 2021, 20:05:18 CET schrieb Erich Titl: > Hi Folks > > OK I may be a bit old fashioned as I believe a build system is supposed > to run without hickups and definitely without crashing. Agreed. > Ours is not. > > the following packages fail to build for i486 > > protobuf-c,kismet,rtty,pmacctd,ca-certificates for protobuf-c (and therefor kismet you need a protobuf-c compiler on the host. like protobuf-c-compiler 1.3.3-1build2 amd64 Protocol Buffers C compiler (protobuf-c) on an ubuntu system. For rtty you may need libevdev2 on the host. The remaining packages listed above should compile AFAIK without prerequisites - at least it does for me. What says the logs? > Also in the current master mimalloc fails, I fixed that in my > environment but I feel like this should be done in a generic way, e.g. > the standard should not crash. A more generic solution shall be "kernel based" - it fails with the i486/wrap kernel, but shall build with i686 (and geode?). It build with arm and x86_64 toolchains. kp > cheers > > ET |
From: Erich T. <eri...@th...> - 2021-11-21 19:05:53
|
Hi Folks OK I may be a bit old fashioned as I believe a build system is supposed to run without hickups and definitely without crashing. Ours is not. the following packages fail to build for i486 protobuf-c,kismet,rtty,pmacctd,ca-certificates Also in the current master mimalloc fails, I fixed that in my environment but I feel like this should be done in a generic way, e.g. the standard should not crash. cheers ET |
From: Erich T. <eri...@th...> - 2021-11-20 14:35:36
|
Hi Am 20.11.2021 um 13:50 schrieb Andrew: > Hi. > It fails to build for i486 platform (i486 has no cmpxchg8b instruction, > etc). I tested it on x86_64 and it works OK. It should build and work > for i586 and newer - but of course it will not run on i486. Then it should be disabled for the i486 platform. We still appear to support it. cheers ET |
From: Andrew <ni...@se...> - 2021-11-20 13:57:11
|
Hi. It fails to build for i486 platform (i486 has no cmpxchg8b instruction, etc). I tested it on x86_64 and it works OK. It should build and work for i586 and newer - but of course it will not run on i486. 20.11.2021 01:26, Erich Titl пишет: > Hi Folks > > Looks like the integration is not that complete > > [ 91%] Linking C executable mimalloc-test-api > /home/mega/leaf/devel/bering-uclibc/toolchain/i486-unknown-linux-uclibc/lib/gcc/i486-unknown-linux-uclibc/9.4.0/../../../../i486-unknown-linux-uclibc/bin/ld: > libmimalloc.a(stats.c.o): in function `mi_stat_add.constprop.0': > > and of course it crashes there > > cheers > > ET > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Erich T. <eri...@th...> - 2021-11-19 23:27:04
|
Hi Folks Looks like the integration is not that complete [ 91%] Linking C executable mimalloc-test-api /home/mega/leaf/devel/bering-uclibc/toolchain/i486-unknown-linux-uclibc/lib/gcc/i486-unknown-linux-uclibc/9.4.0/../../../../i486-unknown-linux-uclibc/bin/ld: libmimalloc.a(stats.c.o): in function `mi_stat_add.constprop.0': and of course it crashes there cheers ET |
From: Andrew <ni...@se...> - 2021-04-12 19:38:49
|
12.04.2021 22:22, Erich Titl пишет: > Hi Andrew > > Am 12.04.2021 um 19:28 schrieb Andrew: >> hi. >> >> it isn't a good solution - it'll wait for 10 seconds each time when >> we can't umount modules (but usually fs freeing takes much less >> time), so it's good to probe if we can umount dir, and if we can - do >> umount. >> > > You have not understood the code and your blocking code breaks the > behaviour that was intended. > > If you want blocking behaviour then do it in accel-ppp and do not > change the behaviour of other tools. > > umount_modules || umount_delayed > > does what you want, except it does not block. how it will work if mount_modules will be called again before umount_modules (from umount_delayed) will be called (for ex., in other daemon, or from menu when user pressed 'find modules')? I think that "try to umount modules or just do nothing if fails" and "let's try to umount modules somewhere later - maybe nobody tried to mount modules again" isn't a good behavior because it potentially causes nondeterministic behavior (like always-mounted filesystem in tmp shich may be suddenly cleaned by usual 'rm -rf /tmp/*', etc). > > Adding a wait parameter to umount_delayed is just a sign of not > understanding what this code does. > > If you want to do it your way, and I would prefer you would not, there > are better ways than lobotomizing code > > 1) include it in accel-ppp > > 2) read the code and see what it does, e.g > umount_modules || umount_delayed > > 3) write your own mount_modules > > cheers > > ET > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Erich T. <eri...@th...> - 2021-04-12 19:23:53
|
Hi Andrew Am 12.04.2021 um 19:28 schrieb Andrew: > hi. > > it isn't a good solution - it'll wait for 10 seconds each time when we > can't umount modules (but usually fs freeing takes much less time), so > it's good to probe if we can umount dir, and if we can - do umount. > You have not understood the code and your blocking code breaks the behaviour that was intended. If you want blocking behaviour then do it in accel-ppp and do not change the behaviour of other tools. umount_modules || umount_delayed does what you want, except it does not block. Adding a wait parameter to umount_delayed is just a sign of not understanding what this code does. If you want to do it your way, and I would prefer you would not, there are better ways than lobotomizing code 1) include it in accel-ppp 2) read the code and see what it does, e.g umount_modules || umount_delayed 3) write your own mount_modules cheers ET |
From: Andrew <ni...@se...> - 2021-04-12 17:28:47
|
hi. it isn't a good solution - it'll wait for 10 seconds each time when we can't umount modules (but usually fs freeing takes much less time), so it's good to probe if we can umount dir, and if we can - do umount. 12.04.2021 12:30, Erich Titl пишет: > Hi Andrew > > may I suggest to do > > umount_modules || umount_delayed ; > > cheers > > ET > > > -------- Weitergeleitete Nachricht -------- > Betreff: [leaf:bering-uclibc] New commit [606eab] by Andrew Denisenko > Datum: Mon, 12 Apr 2021 07:45:01 -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 > > move waiting to umount_delayed > > By Andrew Denisenko on 04/12/2021 07:44 > *View Changes* > <https://sourceforge.net/p/leaf/bering-uclibc/ci/606eab59ff39c0f9781e9c6e056f47c19ffe176d/> > > ------------------------------------------------------------------------ > > Sent from sourceforge.net because you indicated interest in > https://sourceforge.net/p/leaf/bering-uclibc/ > <https://sourceforge.net/p/leaf/bering-uclibc/> > > To unsubscribe from further messages, please visit > https://sourceforge.net/auth/subscriptions/ > <https://sourceforge.net/auth/subscriptions/> > > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Erich T. <eri...@th...> - 2021-04-12 09:30:41
|
Hi Andrew may I suggest to do umount_modules || umount_delayed ; cheers ET -------- Weitergeleitete Nachricht -------- Betreff: [leaf:bering-uclibc] New commit [606eab] by Andrew Denisenko Datum: Mon, 12 Apr 2021 07:45:01 -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 move waiting to umount_delayed By Andrew Denisenko on 04/12/2021 07:44 *View Changes* <https://sourceforge.net/p/leaf/bering-uclibc/ci/606eab59ff39c0f9781e9c6e056f47c19ffe176d/> ------------------------------------------------------------------------ Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/leaf/bering-uclibc/ <https://sourceforge.net/p/leaf/bering-uclibc/> To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ <https://sourceforge.net/auth/subscriptions/> |
From: Erich T. <eri...@th...> - 2021-04-11 21:43:30
|
Hi still don't like the code, there was always a umount_delayed to cater for this problem. Please revert all your changes to mount_modules, else write your own version, call it AD_mount_modules if you want. cheers ET -------- Weitergeleitete Nachricht -------- Betreff: [leaf:bering-uclibc] 2 new commits to Bering-uClibc Datum: Sun, 11 Apr 2021 20:03:06 -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 initrd: update umount_modules logic, add 'wait' option for waiting By Andrew Denisenko on 04/11/2021 20:01 *View Changes* <https://sourceforge.net/p/leaf/bering-uclibc/ci/6659fa5a01a8c6e301b1a726a7729cee5ed96377/> ------------------------------------------------------------------------ accel-ppp: add 'wait' option for umount_modules call By Andrew Denisenko on 04/11/2021 20:02 *View Changes* <https://sourceforge.net/p/leaf/bering-uclibc/ci/fc82fe7f9b246227a42cffacfae60de2b5da63c1/> ------------------------------------------------------------------------ Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/leaf/bering-uclibc/ <https://sourceforge.net/p/leaf/bering-uclibc/> To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ <https://sourceforge.net/auth/subscriptions/> |
From: Erich T. <eri...@th...> - 2021-03-16 09:28:12
|
Hi Am 14.03.2021 um 19:57 schrieb Andrew: > Hi. > > Sorry, I still not added changes. I'll try to add check for opened files > instead of trivial umount retrying (maybe - optional wait, enabled by > cmdline key) > > Waiting is not forever, it waits max 10 seconds (makes 10 retries with > 1-second sleep and then exits) > > Asynchronous delayed umount in init script isn't good IMHO - at least it > may cause glitch with daemons that are loaded after one with delayed > umount (double mount, and possibly - umount till daemon initialization). > Synchronous delayed umount will pause boot for 10 seconds. As you said, in _your_ case. Adding a loop in init for accel-ppp is a 3-liner and is not as disruptive as your modification of mount_modules. Then again, mount and umount are non blocking. Handling return values is a non brainer. cheers ET |
From: Andrew <ni...@se...> - 2021-03-14 18:57:45
|
Hi. Sorry, I still not added changes. I'll try to add check for opened files instead of trivial umount retrying (maybe - optional wait, enabled by cmdline key) Waiting is not forever, it waits max 10 seconds (makes 10 retries with 1-second sleep and then exits) Asynchronous delayed umount in init script isn't good IMHO - at least it may cause glitch with daemons that are loaded after one with delayed umount (double mount, and possibly - umount till daemon initialization). Synchronous delayed umount will pause boot for 10 seconds. 13.03.2021 15:53, KP Kirchdoerfer via leaf-devel пишет: > Hi Andrew; > > On Mo, 2021-03-08 at 20:37 +0200, Andrew wrote: >> Hi. >> >> 07.03.2021 15:50, KP Kirchdoerfer пишет: >>> Hi Andrew; >>> >>> >>> On Mi, 2021-02-24 at 16:50 +0200, Andrew wrote: >>>> 24.02.2021 16:09, Erich Titl пишет: >>>>> Hi Andrew >>>>> >>>>> Am 24.02.2021 um 12:26 schrieb Andrew: >>>>>> Hi. >>>>>> >>>>>> Unmounting may fail if happened too early (fs still used), so >>>>>> it's >>>>>> good to retry umounting. I noticed this in accel-ppp. In that >>>>>> case >>>>>> modules remains mounted. >>>>> I have never experienced such behaviour and I _guess_ it must >>>>> be >>>>> related to accel-ppp then. I was always assuming that modprobe >>>>> returned clean. >>>> modules are loaded at daemon start/iptables rule loading. this >>>> may be >>>> happened after startup of any daemon that may load kernel modules >>>> (ppp, >>>> etc) which have mount_modules call in init script. >>>> >>>> so I think that it's good to try to unmount modules squashfs and >>>> storage >>>> till it'll be unmounted - or till it'll fail by timeout. In other >>>> case >>>> we may have persistently mounted files storage in /tmp - whicn >>>> may be >>>> suddenly cleaned by rm -rf /tmp/* >>> I've never seen that modules are still mounted after calling >>> umount. so >>> this might be a corner case as Erich said and should be solved in >>> acccel-ppp init script if it happens with accel-ppp. >>> Note there is also umount_delayed which gives some additional time >>> before trying to umount. >>> >>> About rm -rf /tmp/* should be fixed in commit >>> e6590a9954da2eb6beca32ccb29bd3fbefe6c5f5 >>> with a change to load readable-only in mount_modules. >>> >>> So can we please revert that change? >> I added a fix for extra-retry. If you think that we shouldn't retry >> if >> umount fails - I'll make it optional (for ex., switched on with >> 'wait' >> cmdline parameter). > I'm still not fine with that change. > > What exactly is your problem reasoning the change? > And why is umount_delayed not fitting your need? > > Either umount is successful or it works with a (eventually > configurable) delay or the problem is in the init of the application > (accel-ppp in your case), but waiting forever seems no solution... > > kp > > >> >> >> _______________________________________________ >> leaf-devel mailing list >> lea...@li... >> https://lists.sourceforge.net/lists/listinfo/leaf-devel > > > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: KP K. <ka...@us...> - 2021-03-13 13:53:26
|
Hi Andrew; On Mo, 2021-03-08 at 20:37 +0200, Andrew wrote: > Hi. > > 07.03.2021 15:50, KP Kirchdoerfer пишет: > > Hi Andrew; > > > > > > On Mi, 2021-02-24 at 16:50 +0200, Andrew wrote: > > > 24.02.2021 16:09, Erich Titl пишет: > > > > Hi Andrew > > > > > > > > Am 24.02.2021 um 12:26 schrieb Andrew: > > > > > Hi. > > > > > > > > > > Unmounting may fail if happened too early (fs still used), so > > > > > it's > > > > > good to retry umounting. I noticed this in accel-ppp. In that > > > > > case > > > > > modules remains mounted. > > > > I have never experienced such behaviour and I _guess_ it must > > > > be > > > > related to accel-ppp then. I was always assuming that modprobe > > > > returned clean. > > > modules are loaded at daemon start/iptables rule loading. this > > > may be > > > happened after startup of any daemon that may load kernel modules > > > (ppp, > > > etc) which have mount_modules call in init script. > > > > > > so I think that it's good to try to unmount modules squashfs and > > > storage > > > till it'll be unmounted - or till it'll fail by timeout. In other > > > case > > > we may have persistently mounted files storage in /tmp - whicn > > > may be > > > suddenly cleaned by rm -rf /tmp/* > > I've never seen that modules are still mounted after calling > > umount. so > > this might be a corner case as Erich said and should be solved in > > acccel-ppp init script if it happens with accel-ppp. > > Note there is also umount_delayed which gives some additional time > > before trying to umount. > > > > About rm -rf /tmp/* should be fixed in commit > > e6590a9954da2eb6beca32ccb29bd3fbefe6c5f5 > > with a change to load readable-only in mount_modules. > > > > So can we please revert that change? > > I added a fix for extra-retry. If you think that we shouldn't retry > if > umount fails - I'll make it optional (for ex., switched on with > 'wait' > cmdline parameter). I'm still not fine with that change. What exactly is your problem reasoning the change? And why is umount_delayed not fitting your need? Either umount is successful or it works with a (eventually configurable) delay or the problem is in the init of the application (accel-ppp in your case), but waiting forever seems no solution... kp > > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Erich T. <eri...@th...> - 2021-03-08 21:44:45
|
Hi Andrew Am 08.03.2021 um 19:37 schrieb Andrew: > Hi. > > 07.03.2021 15:50, KP Kirchdoerfer пишет: >> Hi Andrew; >> >> ....>> >> About rm -rf /tmp/* should be fixed in commit >> e6590a9954da2eb6beca32ccb29bd3fbefe6c5f5 >> with a change to load readable-only in mount_modules. >> >> So can we please revert that change? > > I added a fix for extra-retry. If you think that we shouldn't retry if > umount fails - I'll make it optional (for ex., switched on with 'wait' > cmdline parameter). > This is not a proper fix as it still will try to recurse. This can be very dangerous. It would be a lot better to do this retry logic in in the respective init routine. And then... umount_delayed might be just be as apropriate to use instead and it existed for years. I'd rather see all changes to mount_modules reverted. cheers ET |
From: Erich T. <eri...@th...> - 2021-03-08 21:26:21
|
Hi Am 08.03.2021 um 19:37 schrieb Andrew: > Hi. ... > > I added a fix for extra-retry. If you think that we shouldn't retry if > umount fails - I'll make it optional (for ex., switched on with 'wait' > cmdline parameter). > I believe the retry should not be done in umount_modules. There is no retry in umount neither. cheers ET |
From: Andrew <ni...@se...> - 2021-03-08 18:37:55
|
Hi. 07.03.2021 15:50, KP Kirchdoerfer пишет: > Hi Andrew; > > > On Mi, 2021-02-24 at 16:50 +0200, Andrew wrote: >> 24.02.2021 16:09, Erich Titl пишет: >>> Hi Andrew >>> >>> Am 24.02.2021 um 12:26 schrieb Andrew: >>>> Hi. >>>> >>>> Unmounting may fail if happened too early (fs still used), so >>>> it's >>>> good to retry umounting. I noticed this in accel-ppp. In that >>>> case >>>> modules remains mounted. >>> I have never experienced such behaviour and I _guess_ it must be >>> related to accel-ppp then. I was always assuming that modprobe >>> returned clean. >> modules are loaded at daemon start/iptables rule loading. this may be >> happened after startup of any daemon that may load kernel modules >> (ppp, >> etc) which have mount_modules call in init script. >> >> so I think that it's good to try to unmount modules squashfs and >> storage >> till it'll be unmounted - or till it'll fail by timeout. In other >> case >> we may have persistently mounted files storage in /tmp - whicn may be >> suddenly cleaned by rm -rf /tmp/* > I've never seen that modules are still mounted after calling umount. so > this might be a corner case as Erich said and should be solved in > acccel-ppp init script if it happens with accel-ppp. > Note there is also umount_delayed which gives some additional time > before trying to umount. > > About rm -rf /tmp/* should be fixed in commit > e6590a9954da2eb6beca32ccb29bd3fbefe6c5f5 > with a change to load readable-only in mount_modules. > > So can we please revert that change? I added a fix for extra-retry. If you think that we shouldn't retry if umount fails - I'll make it optional (for ex., switched on with 'wait' cmdline parameter). |
From: KP K. <ka...@us...> - 2021-03-07 14:08:44
|
Hi Andrew; On Mi, 2021-02-24 at 16:50 +0200, Andrew wrote: > 24.02.2021 16:09, Erich Titl пишет: > > Hi Andrew > > > > Am 24.02.2021 um 12:26 schrieb Andrew: > > > Hi. > > > > > > Unmounting may fail if happened too early (fs still used), so > > > it's > > > good to retry umounting. I noticed this in accel-ppp. In that > > > case > > > modules remains mounted. > > > > I have never experienced such behaviour and I _guess_ it must be > > related to accel-ppp then. I was always assuming that modprobe > > returned clean. > > modules are loaded at daemon start/iptables rule loading. this may be > happened after startup of any daemon that may load kernel modules > (ppp, > etc) which have mount_modules call in init script. > > so I think that it's good to try to unmount modules squashfs and > storage > till it'll be unmounted - or till it'll fail by timeout. In other > case > we may have persistently mounted files storage in /tmp - whicn may be > suddenly cleaned by rm -rf /tmp/* I've never seen that modules are still mounted after calling umount. so this might be a corner case as Erich said and should be solved in acccel-ppp init script if it happens with accel-ppp. Note there is also umount_delayed which gives some additional time before trying to umount. About rm -rf /tmp/* should be fixed in commit e6590a9954da2eb6beca32ccb29bd3fbefe6c5f5 with a change to load readable-only in mount_modules. So can we please revert that change? >>> P.S. It seems like in 7.1 installing to flash is broken - it > > > fails if > > > there's only one HDD storage (so it's impossible to install it > > > from > > > CD image), and when I disabled this check - but it doesn't create > > > bootable flash. > > > > This may be another problem related to 7.1. Can I suggest to raise > > this on a separate thread Of course a problem in 7.1 (confirmed myself) and may be a regressin in 7.0.2 as well. kp > > cheers > > > > ET > > > > > > _______________________________________________ > > leaf-devel mailing list > > lea...@li... > > https://lists.sourceforge.net/lists/listinfo/leaf-devel > > > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Erich T. <eri...@th...> - 2021-02-25 13:56:19
|
Hi Andrew Am 24.02.2021 um 12:26 schrieb Andrew: > Hi. > > Unmounting may fail if happened too early (fs still used), Yes that is the case with umount and with umount_modules. so it's good > to retry umounting. No, umount fails and why should umount_modules be different. I noticed this in accel-ppp. In that case modules > remains mounted. Yes unfortunately, but this needs to be resolved in accel-ppp. There are multiple ways to do this without lobotomizing umount_modules. I looked at the init script and as I expected the service is started using start-stop-daemon. As I understand start-stop-daemon just launches the respective service and returns immediately without asserting that the service is fully running. So this explains why we still may have fs access at that time. Needless to say I don't like it. In these circumstances the init script needs to verify that the service process is fully started and all modules are loaded _before_ we call umount_modules. Not knowing how to request status information from the various service processes makes it impossible for me to guess how difficult this may be. One way would be to check if a process still needs the file system. Another method is to add a loop in the init script for umount_modules, a bit alike as in the suggested init. This is closer to the original umount tool and would correspond closer to *X standards. If a timeout is used then this is non deterministic. Some fine tuning would allow to better handle fs access. The most simple way is to just insert a timeout in the init script just before unmounting the modules. Again, this is non deterministic. Both methods above would result in the same way as the proposed change to umount_modules. We should leave umount_mdule as is. It is supposed to be a one-shot attempt to unmount the modules and should not be overfraught with retry logic. It returns an error in the case of failure and provides some logging. I believe Andrew is the only one ever using accel-ppp. We should not adapt our tools to corner cases but to adapt the corner cases to our tools. cheers ET |
From: Erich T. <eri...@th...> - 2021-02-24 15:17:12
|
Am 24.02.2021 um 15:50 schrieb Andrew: > 24.02.2021 16:09, Erich Titl пишет: >> Hi Andrew >> >> Am 24.02.2021 um 12:26 schrieb Andrew: >>> Hi. >>> >>> Unmounting may fail if happened too early (fs still used), so it's >>> good to retry umounting. I noticed this in accel-ppp. In that case >>> modules remains mounted. >> >> I have never experienced such behaviour and I _guess_ it must be >> related to accel-ppp then. I was always assuming that modprobe >> returned clean. > > modules are loaded at daemon start/iptables rule loading. Yes as it is in shorewall. this may be > happened after startup of any daemon that may load kernel modules (ppp, > etc) which have mount_modules call in init script. Yes but I believe it is the responsibility of the init script to check that module loading is terminated and then call umount_modules maybe even in a loop, but outside the uount_modules proper. The way it is implemented right now in init is that umount_modules is always recursively called until it returns sucess on the _second_ run. > > so I think that it's good to try to unmount modules squashfs and storage > till it'll be unmounted - or till it'll fail by timeout. This is not really deterministic and may take quite a while. In other case > we may have persistently mounted files storage in /tmp - whicn may be > suddenly cleaned by rm -rf /tmp/* I understand this very well and if the timeout is reached we may still see this. We should check that module loading is over _before_ we call umount_modules. There must be a way to do this even in accel-ppp. cheers ET |
From: Andrew <ni...@se...> - 2021-02-24 14:51:09
|
24.02.2021 16:09, Erich Titl пишет: > Hi Andrew > > Am 24.02.2021 um 12:26 schrieb Andrew: >> Hi. >> >> Unmounting may fail if happened too early (fs still used), so it's >> good to retry umounting. I noticed this in accel-ppp. In that case >> modules remains mounted. > > I have never experienced such behaviour and I _guess_ it must be > related to accel-ppp then. I was always assuming that modprobe > returned clean. modules are loaded at daemon start/iptables rule loading. this may be happened after startup of any daemon that may load kernel modules (ppp, etc) which have mount_modules call in init script. so I think that it's good to try to unmount modules squashfs and storage till it'll be unmounted - or till it'll fail by timeout. In other case we may have persistently mounted files storage in /tmp - whicn may be suddenly cleaned by rm -rf /tmp/* > > I guess it would be better the to insert the retry loop into accel-ppp > instead of making it recursive in initrd. The recursive mode makes the > call to umount_modules always twice and evaluate a return code I have > not yet pinned out where from. > >> >> P.S. It seems like in 7.1 installing to flash is broken - it fails if >> there's only one HDD storage (so it's impossible to install it from >> CD image), and when I disabled this check - but it doesn't create >> bootable flash. > > This may be another problem related to 7.1. Can I suggest to raise > this on a separate thread. > > cheers > > ET > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Erich T. <eri...@th...> - 2021-02-24 14:10:31
|
Hi Andrew Am 24.02.2021 um 12:26 schrieb Andrew: > Hi. > > Unmounting may fail if happened too early (fs still used), so it's good > to retry umounting. I noticed this in accel-ppp. In that case modules > remains mounted. I have never experienced such behaviour and I _guess_ it must be related to accel-ppp then. I was always assuming that modprobe returned clean. I guess it would be better the to insert the retry loop into accel-ppp instead of making it recursive in initrd. The recursive mode makes the call to umount_modules always twice and evaluate a return code I have not yet pinned out where from. > > P.S. It seems like in 7.1 installing to flash is broken - it fails if > there's only one HDD storage (so it's impossible to install it from CD > image), and when I disabled this check - but it doesn't create bootable > flash. This may be another problem related to 7.1. Can I suggest to raise this on a separate thread. cheers ET |
From: Andrew <ni...@se...> - 2021-02-24 11:46:06
|
Hi. Unmounting may fail if happened too early (fs still used), so it's good to retry umounting. I noticed this in accel-ppp. In that case modules remains mounted. P.S. It seems like in 7.1 installing to flash is broken - it fails if there's only one HDD storage (so it's impossible to install it from CD image), and when I disabled this check - but it doesn't create bootable flash. 24.02.2021 11:04, Erich Titl пишет: > Hi Andrew > > Could you please explain why you think this code is necessary. > Unmounting should be an atomic operation and I don't see this here. > This feels like umount_modules should hide an unfinished operation > elsewhere. > > cheers > > ET > > -------- Weitergeleitete Nachricht -------- > Betreff: [leaf:bering-uclibc] New commit [d479db] by Andrew Denisenko > Datum: Sun, 21 Feb 2021 19:28:26 -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 > > initrd: add retry to umount_modules > > By Andrew Denisenko on 02/21/2021 19:27 > *View Changes* > <https://sourceforge.net/p/leaf/bering-uclibc/ci/d479dbc5cb7c843edeabc521727a4b915fc8cb27/> > > ------------------------------------------------------------------------ > > Sent from sourceforge.net because you indicated interest in > https://sourceforge.net/p/leaf/bering-uclibc/ > <https://sourceforge.net/p/leaf/bering-uclibc/> > > To unsubscribe from further messages, please visit > https://sourceforge.net/auth/subscriptions/ > <https://sourceforge.net/auth/subscriptions/> > > > > _______________________________________________ > leaf-devel mailing list > lea...@li... > https://lists.sourceforge.net/lists/listinfo/leaf-devel |
From: Erich T. <eri...@th...> - 2021-02-24 09:22:56
|
Hi Andrew Could you please explain why you think this code is necessary. Unmounting should be an atomic operation and I don't see this here. This feels like umount_modules should hide an unfinished operation elsewhere. cheers ET -------- Weitergeleitete Nachricht -------- Betreff: [leaf:bering-uclibc] New commit [d479db] by Andrew Denisenko Datum: Sun, 21 Feb 2021 19:28:26 -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 initrd: add retry to umount_modules By Andrew Denisenko on 02/21/2021 19:27 *View Changes* <https://sourceforge.net/p/leaf/bering-uclibc/ci/d479dbc5cb7c843edeabc521727a4b915fc8cb27/> ------------------------------------------------------------------------ Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/leaf/bering-uclibc/ <https://sourceforge.net/p/leaf/bering-uclibc/> To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/ <https://sourceforge.net/auth/subscriptions/> |