Menu
▾
▴
devil-linux-develop — developer discussions
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(55) |
Oct
(44) |
Nov
(156) |
Dec
(123) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(130) |
Feb
(156) |
Mar
(162) |
Apr
(171) |
May
(97) |
Jun
(127) |
Jul
(58) |
Aug
(81) |
Sep
(86) |
Oct
(45) |
Nov
(41) |
Dec
(84) |
| 2003 |
Jan
(71) |
Feb
(87) |
Mar
(133) |
Apr
(152) |
May
(151) |
Jun
(232) |
Jul
(320) |
Aug
(237) |
Sep
(271) |
Oct
(536) |
Nov
(301) |
Dec
(393) |
| 2004 |
Jan
(393) |
Feb
(184) |
Mar
(314) |
Apr
(225) |
May
(139) |
Jun
(77) |
Jul
(87) |
Aug
(75) |
Sep
(139) |
Oct
(50) |
Nov
(8) |
Dec
(28) |
| 2005 |
Jan
(66) |
Feb
(63) |
Mar
(14) |
Apr
(14) |
May
(8) |
Jun
(23) |
Jul
(21) |
Aug
(6) |
Sep
(29) |
Oct
(55) |
Nov
(38) |
Dec
(8) |
| 2006 |
Jan
(5) |
Feb
(10) |
Mar
(1) |
Apr
(15) |
May
(32) |
Jun
(44) |
Jul
(11) |
Aug
(8) |
Sep
(9) |
Oct
(14) |
Nov
(4) |
Dec
(3) |
| 2007 |
Jan
(3) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(35) |
Aug
(49) |
Sep
(8) |
Oct
(42) |
Nov
(44) |
Dec
(7) |
| 2008 |
Jan
(2) |
Feb
(7) |
Mar
(8) |
Apr
(80) |
May
(74) |
Jun
(29) |
Jul
(5) |
Aug
(7) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
| 2009 |
Jan
(8) |
Feb
(19) |
Mar
(3) |
Apr
(24) |
May
(22) |
Jun
(23) |
Jul
(8) |
Aug
(23) |
Sep
(8) |
Oct
(27) |
Nov
(52) |
Dec
(27) |
| 2010 |
Jan
(36) |
Feb
(29) |
Mar
(17) |
Apr
(28) |
May
(21) |
Jun
(4) |
Jul
|
Aug
(28) |
Sep
(18) |
Oct
(6) |
Nov
(34) |
Dec
(16) |
| 2011 |
Jan
(18) |
Feb
(12) |
Mar
|
Apr
|
May
(9) |
Jun
(1) |
Jul
(5) |
Aug
(5) |
Sep
(7) |
Oct
(16) |
Nov
(26) |
Dec
(17) |
| 2012 |
Jan
(6) |
Feb
(34) |
Mar
(52) |
Apr
(10) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(4) |
Nov
(1) |
Dec
(4) |
| 2013 |
Jan
(5) |
Feb
|
Mar
|
Apr
(5) |
May
(4) |
Jun
|
Jul
|
Aug
(14) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(2) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(11) |
| 2015 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andrzej O. <an...@ma...> - 2012-03-06 19:14:46
|
Heiko, I wrote: > For this I need some days, because many interfaces I have only on one, > central router. To test, I need free night. So be patient. Fortunately, today I has possibility to change software on a newly compiled. And as I can see, all the processes go correctly, routing and BGP also, but the mess in the interface has not changed and probably will not change. Look yourself: > root@Gibraltar:~ # uname -a > Linux Gibraltar 3.2.9-grsec #1 SMP Tue Mar 6 05:32:21 CET 2012 i686 GNU/Linux > root@Gibraltar:~ # cat /proc/net/dev > Inter-| Receive | Transmit > face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed > eth3: 10701200 13641 0 0 0 0 0 0 5722494 18283 0 0 0 0 0 0 > tap0: 73358 590 0 0 0 0 0 0 960615 804 0 0 0 0 0 0 > ifb0: 15583424 29796 0 1 0 0 0 0 15583354 29795 0 0 0 0 0 0 > tun12: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > tun3: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > tun7: 1404 14 0 0 0 0 0 0 1407 12 0 0 0 0 0 0 > lo: 57903 683 0 0 0 0 0 0 57903 683 0 0 0 0 0 0 > eth2: 15777556 30017 0 0 0 0 0 0 4850630 22943 71 0 0 229 71 0 > tun11: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > tun2: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > tun15: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > tun6: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > eth1: 9430144 26153 0 0 0 0 0 0 4481901 23709 0 0 0 0 0 0 > tun10: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > tun1: 39392 368 0 0 0 0 0 0 396915 465 0 0 0 0 0 0 > tun5: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > eth0: 3507489 11278 0 2 0 0 0 71 8123938 11235 0 0 0 0 0 0 > tun9: 203 3 0 0 0 0 0 0 219 3 0 0 0 0 0 0 > eth4: 69124 169 0 0 0 0 0 168 250 3 0 0 0 0 0 0 > tap1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > ifb1: 10495061 12867 0 1 0 0 0 0 10494991 12866 0 0 0 0 0 0 > tun13: 4362 26 0 0 0 0 0 0 2902 21 0 0 0 0 0 0 > tun4: 2808 35 0 0 0 0 0 0 3138 28 0 0 0 0 0 0 > tun8: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 So my patch, sorting this list is very useful to me, look: > root@Gibraltar:~ # iptraf -g > IPTraf > ┌ Iface ───────────────── Total ──────── IP ────── NonIP ────── BadIP ───── Activity ─────────────┐ > │ eth0 (LAN) 7546 7369 177 0 856.40 kbits/sec │ > │ eth1 (DMZ) 16240 16224 16 0 450.80 kbits/sec │ > │ eth2 (CDP) 19799 19787 12 0 1100.00 kbits/sec │ > │ eth3 (NASK) 7485 7484 1 0 162.20 kbits/sec │ > │ eth4 (WiFi) 120 120 0 0 6.60 kbits/sec │ > │ tap0 (OVPNudp) 158 124 34 0 3.60 kbits/sec │ > │ tap1 (OVPNtcp) 0 0 0 0 0.00 kbits/sec │ > │ tun1 (Chroscickiego) 219 219 0 0 2.00 kbits/sec │ > │ tun2 (Bialystok) 0 0 0 0 0.00 kbits/sec │ > │ tun3 (Bydgoszcz) 0 0 0 0 0.00 kbits/sec │ > │ tun4 (Czestochowa) 69 69 0 0 0.00 kbits/sec │ > │ tun5 (Gdansk) 0 0 0 0 0.00 kbits/sec │ > │ tun6 (Kalisz) 0 0 0 0 0.00 kbits/sec │ > │ tun7 (Katowice) 4 4 0 0 0.00 kbits/sec │ > │ tun8 (Krakow) 0 0 0 0 0.00 kbits/sec │ > │ tun9 (Lodz) 0 0 0 0 0.00 kbits/sec │ > │ tun10 (Poznan) 0 0 0 0 0.00 kbits/sec │ > │ tun11 (Szczecin) 0 0 0 0 0.00 kbits/sec │ > │ tun12 (Wroclaw) 0 0 0 0 0.00 kbits/sec │ > │ tun13 (Zamosc) 31 31 0 0 0.00 kbits/sec │ > │ tun15 (Slupsk) 0 0 0 0 0.00 kbits/sec │ > │ lo 258 258 0 0 2.00 kbits/sec │ > │ │ > │ │ > └ Elapsed time: 0:01 ──────────────── Total, IP, NonIP, and BadIP are packet counts ────────────┘ > Up/Down/PgUp/PgDn-scroll window X-exit > ┌ Select Interface ────┐──────────────┐ > │ All interfaces │ │ > │ eth0 │statistics │ > │ eth1 │ statistics │ > │ eth2 │owns... │ > │ eth3 │r │ > │ eth4 │──────────────│ > │ tap0 │ │ > │ tap1 │──────────────│ > │ tun1 │ │ > │ tun2 │──────────────│ > │ tun3 │ │ > │ tun4 │──────────────┘ > └──────────────────────┘ Best regards -- Andrzej Odyniec |
|
From: Andrzej O. <an...@ma...> - 2012-03-06 17:23:08
|
Heiko Zuerker wrote:
> Any issues with this patch being present in the 32 bit version?
Generally strcpy() function should not to be used in this manner as in ltrim()
in ifaces.c of iptraf package, because standard specification of strcpy says:
> char * strcpy ( char * destination, const char * source );
>
> Copies the C string pointed by source into the array
> pointed by destination, including the terminating null character.
>
> To avoid overflows, the size of the array pointed by destination
> shall be long enough to contain the same C string as source
> (including the terminating null character),
> and should not overlap in memory with source.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
But effects depends on implementation of strcpy (maybe of glibc version).
Quite simple task of copying string in our glibc is now the following:
> /* Copy SRC to DEST. */
> char *
> strcpy (dest, src)
> char *dest;
> const char *src;
> {
> reg_char c;
> char *__unbounded s = (char *__unbounded) CHECK_BOUNDS_LOW (src);
> const ptrdiff_t off = CHECK_BOUNDS_LOW (dest) - s - 1;
> size_t n;
>
> do
> {
> c = *s++;
> s[off] = c;
> }
> while (c != '\0');
>
> n = s - src;
> (void) CHECK_BOUNDS_HIGH (src + n);
> (void) CHECK_BOUNDS_HIGH (dest + n);
>
> return dest;
> }
so is not simple (but maybe fast) and I'm not sure, what is doing for above
program our compiler and it's code generator. How long is reg_char type, how
is copied to memory etc.? For this knowledge, there is need to read many
sources. But if I will even analyse generated code, this can change with new
version of glibc or compiler. All, because standard says: "destination string
should not overlap in memory with source" and this does not depends on 32/64 bits.
I find this problem testing my sorting patch, when string | eth0| grabbed
from /proc/net/dev after ltrim became |e0h0| and this interface name is in
interface list in iptraf. As for now 32-bit compiled strcpy is not doing this
strange things. At least in my tests. But the 64-bit strcpy does so.
Interface list in iptraf is used to construct menu of interfaces and for
general statistics, but each interface on list is checked for operativity and
removed from list, if is not operative, so affected interface "e0h0" is
removed as non-operative. When we select general statistics, network packets
are catched and increments counter on this list, but if interface pointed by
packet is not found on this list (i.e. because name was broken), interface is
added to list from packet at list end. So this error is near invisible. But as
effect, starting interface menu can be without affected interface name.
Ofcourse there can be many other side effects.
But in ltrim() we not need to shift this string. Is sufficient to return
address pointing to start of interface name in original string.
I think: it is better to apply always this patch, as side effects of this bug
are unpredictable.
Regards
--
Andrzej Odyniec
|
|
From: Heiko Z. <he...@zu...> - 2012-03-06 16:49:22
|
Hey, udev-181 is working now and I have uploaded my changes. The only thing left complaining is the aoe6 udev script. -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Heiko Z. <he...@zu...> - 2012-03-06 16:22:25
|
Seems like most of the problems with the new udev are caused by our build script. I'm making significant progress on 181. -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Heiko Z. <he...@zu...> - 2012-03-06 14:53:56
|
Quoting Andrzej Odyniec <an...@ma...>: > Heiko, > > I wrote: >> I will check this problem. Maybe unsorted list of interfaces in >> /proc/net/dev is by error, not by design. Or maybe not. > > For this I need some days, because many interfaces I have only on > one, central router. To test, I need free night. So be patient. Okay. >> I will test my patch in both 32-bit and 64-bit compilation, >> because, as for now I only tested it on 32-bit compilation on my >> router. >> >> Iptraf code is old and raw, so there can be surprises with >> completly succesfull patching. > > So... as for now, I prophesied. Testing my patch (still looks to be > a valid) I found bug in iptraf, which manifests itself in the 64-bit > compilation. In trimming interface name read from /proc/net/dev is > used strcpy in improper manner to overlaping strings. Here is patch > correcting this error. This patch is independent from previous > patch, sorting interfaces. Any issues with this patch being present in the 32 bit version? -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Andrzej O. <an...@ma...> - 2012-03-06 14:46:56
|
Heiko, I wrote: > I will check this problem. Maybe unsorted list of interfaces in /proc/net/dev > is by error, not by design. Or maybe not. For this I need some days, because many interfaces I have only on one, central router. To test, I need free night. So be patient. > I will test my patch in both 32-bit and 64-bit compilation, because, as for > now I only tested it on 32-bit compilation on my router. > > Iptraf code is old and raw, so there can be surprises with completly > succesfull patching. So... as for now, I prophesied. Testing my patch (still looks to be a valid) I found bug in iptraf, which manifests itself in the 64-bit compilation. In trimming interface name read from /proc/net/dev is used strcpy in improper manner to overlaping strings. Here is patch correcting this error. This patch is independent from previous patch, sorting interfaces. Best regards -- Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2012-03-06 13:53:37
|
All, while I was looking over the udev stuff, I saw that we actually still support linuxrc and some other variations for initrd. Should we only support initramfs and remove the rest? This should make things a bit cleaner. -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Heiko Z. <he...@zu...> - 2012-03-06 13:42:10
|
*Moved to develop mailinglist* Quoting Serge Leschinsky <ser...@gm...>: > Sure. Disable it for now - I'll try to adapt the rules and re-enable it then. > > Serge > > On 03/05/2012 05:19 PM, Heiko Zuerker wrote: >> I now have a working version with the new udev. >> Unfortunately it doesn't like our aoe rule set and even complains about some >> of its own. >> I don't think this is worth potentially delaying the final 1.6... Thoughts? Sorry I wasn't clear. I actually meant sticking with 173 (if we can get the compile error resolved) and not going with 181. I don't know how much effort it will be to clean things up. I assume fixing the aoe rule should be fairly easy, but the failed out-of-the-box rules worry me a bit. Of course if the "deprecated oom_adj" error still shows up in 173, then we'll probably don't have much of a choice.... -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Heiko Z. <he...@zu...> - 2012-03-06 13:22:09
|
*Moved email to developer mailinglist* Serge, Quoting Serge Leschinsky <ser...@gm...>: > I have a working udev-173. It seems to be the last "old" udev (no mandatory > /run, do devfs, no kmod etc) - if you don't mind I'll update DL to > this version. The udev compile is failing with: CC extras/gudev/extras_gudev_libgudev_1_0_la-gudevclient.lo CC extras/gudev/extras_gudev_libgudev_1_0_la-gudevdevice.lo libudev/libudev-enumerate.c: In function 'udev_enumerate_scan_subsystems': libudev/libudev-enumerate.c:924: internal compiler error: in partition_view_bitmap, at tree-ssa-live.c:369 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [libudev/libudev-enumerate.lo] Error 1 Happens on x86_64 and on i686 (this one with a fresh lfssystem). -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Andrzej O. <an...@ma...> - 2012-03-05 16:46:44
|
Heiko Zuerker wrote: > I upgraded the kernel in CVS to 3.2.9 over the weekend. Could you > verify that this problem still exists in the newer version? > If yes, then I don't see an issue with adding the patch. Heiko, I will check this problem. Maybe unsorted list of interfaces in /proc/net/dev is by error, not by design. Or maybe not. I will test my patch in both 32-bit and 64-bit compilation, because, as for now I only tested it on 32-bit compilation on my router. Iptraf code is old and raw, so there can be surprises with completly succesfull patching. As you now, there is try of reneval of iptraf, named iptraf-ng, but without serious changes. I was not sure, what I should patch: iptraf or iptraf-ng? So my changes was very delicate, possible to adopting on iptraf-ng too. So this patch is as for now, rather for testing, not for final application. But iptraf is still a very handy tool, so is worth adopting to current kernels. Regards Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2012-03-05 14:53:44
|
Andrzej, I upgraded the kernel in CVS to 3.2.9 over the weekend. Could you verify that this problem still exists in the newer version? If yes, then I don't see an issue with adding the patch. Heiko Quoting Andrzej Odyniec <an...@ma...>: > Heiko, > > Linux kernel (now 3.2.6) shows network interfaces in file > /proc/net/dev not sorted, so far, but in some strange, random order. > Network interfaces and tunnel pseudointerfaces are mixed. Meanwhile > IPtraf builds an interface menu as well as the list of interfaces to > the general statistics based on this file. If the router has a > several interfaces, finding the appropriate becomes very difficult. > > I wrote the following patch to solve this problem, because I have on > my central router several OpenVPN tunnels to office branches. So > after building a list of interfaces, this list is also sorted > lexicographically by name. > > In addition, in file /var/iptraf/iface.desc we can assign aliases > and sorting keys for interfaces, in this way easily managing list. > File is described in intro to patch. > > Regards > > Andrzej Odyniec -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Andrzej O. <an...@ma...> - 2012-03-05 14:30:18
|
Heiko, Linux kernel (now 3.2.6) shows network interfaces in file /proc/net/dev not sorted, so far, but in some strange, random order. Network interfaces and tunnel pseudointerfaces are mixed. Meanwhile IPtraf builds an interface menu as well as the list of interfaces to the general statistics based on this file. If the router has a several interfaces, finding the appropriate becomes very difficult. I wrote the following patch to solve this problem, because I have on my central router several OpenVPN tunnels to office branches. So after building a list of interfaces, this list is also sorted lexicographically by name. In addition, in file /var/iptraf/iface.desc we can assign aliases and sorting keys for interfaces, in this way easily managing list. File is described in intro to patch. Regards Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2012-02-27 18:00:12
|
Quoting Andrzej Odyniec <an...@ma...>: > Heiko Zuerker wrote: >> I wrote this script for a much older version of Notes a long time ago. >> Did you try without chroot first? > > Yes, Heiko. I did it. For reduce battle of libraries. > I switched off jail and corrected path (now is little different). > I added libraries directory form /opt/... using ldconfig. > > But if after start the server behaves a little strangely, so I decided to ask > if there is no something ready. I thought, maybe You or Serge might have > written this script again for new version. But if not, then I will myself > struggled a little bit. No unfortunately I didn't touch this in a very long time. But I'll gladly add any updates you may have to DL. ;-) -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Andrzej O. <an...@ma...> - 2012-02-27 17:55:27
|
Heiko Zuerker wrote: > I wrote this script for a much older version of Notes a long time ago. > Did you try without chroot first? Yes, Heiko. I did it. For reduce battle of libraries. I switched off jail and corrected path (now is little different). I added libraries directory form /opt/... using ldconfig. But if after start the server behaves a little strangely, so I decided to ask if there is no something ready. I thought, maybe You or Serge might have written this script again for new version. But if not, then I will myself struggled a little bit. Thanks for answer -- Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2012-02-27 16:42:34
|
Quoting Andrzej Odyniec <an...@ma...>: > Dears, > > Do any of you have a script starting Lotus Notes Domino server? Say: 8.5.3? > This in distribution is a little outdated. > > Thanks in advance for your answer I wrote this script for a much older version of Notes a long time ago. Did you try without chroot first? -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Andrzej O. <an...@ma...> - 2012-02-27 15:41:16
|
Dears, Do any of you have a script starting Lotus Notes Domino server? Say: 8.5.3? This in distribution is a little outdated. Thanks in advance for your answer -- Andrzej Odyniec |
|
From: Dominic R. <dl...@ed...> - 2012-02-24 09:02:52
|
On 22/02/2012 13:49, Heiko Zuerker wrote: > Quoting Dominic Raferd<dl...@ed...>: > >> On 21/02/2012 21:57, Heiko Zuerker wrote: >>> Quoting Andrzej Odyniec<an...@ma...>: >>>> Hi, >>>> >>>> Heiko Zuerker wrote: >>>>> That would explain why it works on the 64 bit version, since libsafe >>>>> is disabled there. >>>>> >>>>> You can easily test this. Delete the file /etc/ld.so.preload. >>>>> Not sure if you have to bounce or not. >>>> Yes, I found it here: >>>> http://www.mail-archive.com/deb...@li.../msg310487.html >>>> so, Dominic was right... >>>> >>>>> I would be open to completely removing libsafe from DL. It hasn't been >>>>> updated in a decade... >>>> As soon as I discovered that libsafe captures access to realpath, I >>>> turned off >>>> the libsafe from ld.so.preload and the problem disappeared. I started to >>>> wonder how to patch libsafe, but if you propose to remove, it may >>>> not worth to >>>> think about... >>> I removed libsafe from CVS and added code to upgrade-config to remove >>> the specific line from /etc/ld.so.preload >>> The changes are untested, please let me know if they work (especially >>> the upgrade-config) >>> >> Please see my suggestion in Mantis. The good news is that with this line >> taken out of /etc/ld.so.preload and samba restarted, the problem >> requiring 'wide links=yes' is gone in 1.6.0-RC2 32 bit. > Nice! > > I changed the code as proposed. > It's good to have got this bug. Great catch Andrzej :-) |
|
From: Heiko Z. <he...@zu...> - 2012-02-22 13:49:36
|
Quoting Dominic Raferd <dl...@ed...>: > On 21/02/2012 21:57, Heiko Zuerker wrote: >> Quoting Andrzej Odyniec<an...@ma...>: >>> Hi, >>> >>> Heiko Zuerker wrote: >>>> That would explain why it works on the 64 bit version, since libsafe >>>> is disabled there. >>>> >>>> You can easily test this. Delete the file /etc/ld.so.preload. >>>> Not sure if you have to bounce or not. >>> Yes, I found it here: >>> http://www.mail-archive.com/deb...@li.../msg310487.html >>> so, Dominic was right... >>> >>>> I would be open to completely removing libsafe from DL. It hasn't been >>>> updated in a decade... >>> As soon as I discovered that libsafe captures access to realpath, I >>> turned off >>> the libsafe from ld.so.preload and the problem disappeared. I started to >>> wonder how to patch libsafe, but if you propose to remove, it may >>> not worth to >>> think about... >> I removed libsafe from CVS and added code to upgrade-config to remove >> the specific line from /etc/ld.so.preload >> The changes are untested, please let me know if they work (especially >> the upgrade-config) >> > > Please see my suggestion in Mantis. The good news is that with this line > taken out of /etc/ld.so.preload and samba restarted, the problem > requiring 'wide links=yes' is gone in 1.6.0-RC2 32 bit. Nice! I changed the code as proposed. -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Dominic R. <dl...@ed...> - 2012-02-22 10:17:44
|
On 21/02/2012 21:57, Heiko Zuerker wrote: > Quoting Andrzej Odyniec<an...@ma...>: >> Hi, >> >> Heiko Zuerker wrote: >>> That would explain why it works on the 64 bit version, since libsafe >>> is disabled there. >>> >>> You can easily test this. Delete the file /etc/ld.so.preload. >>> Not sure if you have to bounce or not. >> Yes, I found it here: >> http://www.mail-archive.com/deb...@li.../msg310487.html >> so, Dominic was right... >> >>> I would be open to completely removing libsafe from DL. It hasn't been >>> updated in a decade... >> As soon as I discovered that libsafe captures access to realpath, I >> turned off >> the libsafe from ld.so.preload and the problem disappeared. I started to >> wonder how to patch libsafe, but if you propose to remove, it may >> not worth to >> think about... > I removed libsafe from CVS and added code to upgrade-config to remove > the specific line from /etc/ld.so.preload > The changes are untested, please let me know if they work (especially > the upgrade-config) > Please see my suggestion in Mantis. The good news is that with this line taken out of /etc/ld.so.preload and samba restarted, the problem requiring 'wide links=yes' is gone in 1.6.0-RC2 32 bit. |
|
From: Heiko Z. <he...@zu...> - 2012-02-21 21:58:06
|
Quoting Andrzej Odyniec <an...@ma...>: > Hi, > > Heiko Zuerker wrote: >> That would explain why it works on the 64 bit version, since libsafe >> is disabled there. >> >> You can easily test this. Delete the file /etc/ld.so.preload. >> Not sure if you have to bounce or not. > > Yes, I found it here: > http://www.mail-archive.com/deb...@li.../msg310487.html > so, Dominic was right... > >> I would be open to completely removing libsafe from DL. It hasn't been >> updated in a decade... > > As soon as I discovered that libsafe captures access to realpath, I > turned off > the libsafe from ld.so.preload and the problem disappeared. I started to > wonder how to patch libsafe, but if you propose to remove, it may > not worth to > think about... I removed libsafe from CVS and added code to upgrade-config to remove the specific line from /etc/ld.so.preload The changes are untested, please let me know if they work (especially the upgrade-config) -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Andrzej O. <an...@ma...> - 2012-02-21 17:04:35
|
Hi, Heiko Zuerker wrote: > That would explain why it works on the 64 bit version, since libsafe > is disabled there. > > You can easily test this. Delete the file /etc/ld.so.preload. > Not sure if you have to bounce or not. Yes, I found it here: http://www.mail-archive.com/deb...@li.../msg310487.html so, Dominic was right... > I would be open to completely removing libsafe from DL. It hasn't been > updated in a decade... As soon as I discovered that libsafe captures access to realpath, I turned off the libsafe from ld.so.preload and the problem disappeared. I started to wonder how to patch libsafe, but if you propose to remove, it may not worth to think about... Best regards -- Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2012-02-21 16:42:20
|
Hey, Quoting Andrzej Odyniec <an...@ma...>: > As You can see, mount.cifs found realpath not in glibc but in libsafe (!). > >> root@DesignerVM32:/var # objdump -t /lib/libsafe.so.2|grep realpath >> 0000501c l O .bss 00000004 real_realpath.4419 >> 00001ec0 g F .text 00000154 realpath > > Indeed, in libsafe library realpath function is present, perhaps > safer because > of protecting second argument from overflow, but probably not accepting (at > least 32-bit) as the second argument of NULL or has some other defect. > > So, probably problem is with libsafe, not in glibc. That would explain why it works on the 64 bit version, since libsafe is disabled there. You can easily test this. Delete the file /etc/ld.so.preload. Not sure if you have to bounce or not. I would be open to completely removing libsafe from DL. It hasn't been updated in a decade... -- Regards Heiko Zuerker http://www.devil-linux.org |
|
From: Andrzej O. <an...@ma...> - 2012-02-21 15:51:47
|
Heiko Zuerker wrote: > I just had another thought, maybe one of the glibc patches we're using is > causing the issue. > > You could try building with an empty glibc-patches directory. > After the "make unpack", simply empty the directory before you do the "make > all". Hi Heiko, Yes... I will try this too. But today I had some free time and added to the DL binutils and gdb. In this way I could see make.cifs inside . Well ... See for yourself: > root@DesignerVM32:/var # gdb --args /sbin/mount.cifs //172.27.32.83/RAID /mnt > GNU gdb (GDB) 7.4 > Copyright (C) 2012 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i686-pc-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /sbin/mount.cifs...(no debugging symbols found)...done. > (gdb) b realpath > Breakpoint 1 at 0x17b8 > (gdb) run > Starting program: /sbin/mount.cifs //172.27.32.83/RAID /mnt > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/libthread_db.so.1". > > Breakpoint 1, 0xb7fdaec9 in realpath () from /lib/libsafe.so.2 > (gdb) q As You can see, mount.cifs found realpath not in glibc but in libsafe (!). > root@DesignerVM32:/var # objdump -t /lib/libsafe.so.2|grep realpath > 0000501c l O .bss 00000004 real_realpath.4419 > 00001ec0 g F .text 00000154 realpath Indeed, in libsafe library realpath function is present, perhaps safer because of protecting second argument from overflow, but probably not accepting (at least 32-bit) as the second argument of NULL or has some other defect. So, probably problem is with libsafe, not in glibc. Best regards -- Andrzej Odyniec |
|
From: Heiko Z. <he...@zu...> - 2012-02-19 18:29:28
|
Hey, I removed the 32 bit libstdc++ from the 64 bit build. -- Regards Heiko Zuerker http://www.devil-linux.org > -----Original Message----- > From: Serge Leschinsky [mailto:ser...@gm...] > Sent: Friday, February 17, 2012 2:13 PM > To: dev...@li... > Subject: Re: [Devil-linux-develop] Problem with mount.cifs > > Hi, > > There is a list of 32-bit apps in devil-linux-1.6.0-RC2-x86_64: > > > /bin/vconfig: ELF 32-bit LSB executable > /lib/firmware/mixart/miXart8.elf: ELF 32-bit MSB executable > /usr/lib/libg++.so.2.7.2: ELF 32-bit LSB shared object > /usr/lib/libg++-3-libc6.2-2-2.8.1.3.so: ELF 32-bit LSB shared object > /usr/lib/libstdc++.so.2.7.2.8: ELF 32-bit LSB shared object > /usr/lib/libstdc++.so.2.8: ELF 32-bit LSB shared object > /usr/lib/libstdc++.so.2.9.0: ELF 32-bit LSB shared object > /usr/lib/libstdc++-3-libc6.1-2-2.10.0.so: ELF 32-bit LSB shared object > /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so: ELF 32-bit LSB shared object > /usr/lib/libstdc++-libc6.1-1.so.2: ELF 32-bit LSB shared object > /usr/libexec/webmin/mount/freebsd-mounts-3: ELF 32-bit LSB executable > /usr/libexec/webmin/mount/freebsd-mounts-4: ELF 32-bit LSB executable > /usr/libexec/webmin/mount/freebsd-mounts-5: ELF 32-bit LSB executable > > I excluded grub related files which is obviously can be only 32-bit (grub- > 0.9.x). > > PS. I paid special attention in my DL_64 build system to prevent mixed lib (32 > & > 64) environment - it leads really weird side-effect. > > PPS. I'm working on network scrips, ad it should eliminate the problem with > vconfig, IP aliases etc. No ETA yet, but there is only one problem remain - > realization of sorted graph algorithm on bash - I'm added dependencies into > the network scripts. > > > Serge > > ---------------------------------------------------------------------------- -- > Virtualization & Cloud Management Using Capacity Planning Cloud computing > makes use of virtualization - but cloud computing also focuses on allowing > computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop |
|
From: Heiko Z. <he...@zu...> - 2012-02-19 18:23:44
|
I just had another thought, maybe one of the glibc patches we're using is causing the issue. You could try building with an empty glibc-patches directory. After the "make unpack", simply empty the directory before you do the "make all". -- Regards Heiko Zuerker http://www.devil-linux.org > -----Original Message----- > From: Heiko Zuerker [mailto:he...@zu...] > Sent: Sunday, February 19, 2012 12:19 PM > To: dev...@li... > Subject: Re: [Devil-linux-develop] Problem with mount.cifs > > Hey, > > I did a quick test about going to glibc 2.14.1. > Unfortunately a lot of things are breaking, so this is not really an option since > I don't want to delay the 1.6 release any further. > > Hopefully you'll find a better solution to the issue. > > -- > > Regards > Heiko Zuerker > http://www.devil-linux.org > > > -----Original Message----- > > From: Andrzej Odyniec [mailto:an...@ma...] > > Sent: Friday, February 17, 2012 9:41 AM > > To: dev...@li... > > Subject: Re: [Devil-linux-develop] Problem with mount.cifs > > > > Heiko, > > > > > I don't see a reason why the 32bit version should differ from the > > > 64bit, but of course there could always be a problem with a > > > configure script. > > > > I don't see, too. > > > > > Do you think the problem is in the glibc? We could try building with > > > 2.14.1 and see if that fixes the issue. > > > > Yes, I think, but I'm don shure yet. This need some tests or debug. > > > > There is no doubt: mount.cifs before any mounting is making the following: > > -- cd to mountpoint directory and after > > -- realpath of directory "." > > > > And this error message is preset only in one place: after unsuccesfull > > realpath. > > > > mount.cifs has no his own realpath (as many packages have), but is > > using > one > > from libc linked dynamically: > > > > > root:/build/tmp# objdump -t cifs-utils-5.3/mount.cifs |grep realpath > > > 00000000 F *UND* 00000000 realpath@@GLIBC_2.3 > > > > and this version of realpath is needed by mount.cifs. > > > root:/build/tmp# objdump -t /lib/libc-2.12.2.so |grep realpath > > > 00000000 l df *ABS* 00000000 realpath_chk.c > > > 00037960 l F .text 00000512 __realpath > > > 00108080 l F .text 00000041 __old_realpath > > > 00108080 g F .text 00000041 realpath@GLIBC_2.0 > > > 00037960 g F .text 00000512 realpath@@GLIBC_2.3 > > > 000e3030 g F .text 00000038 __realpath_chk > > > > As You remebmer, standardizers changed last argument of realpath, > > disallowing/allowing null pointer. old-realpath disallows this but > realpath > > allows. mount.cifs uses null pointer in this place. So > > realpath@@GLIBC_2.3 used by mount.cifs in libc points to __realpath. This > is correct. > > > > libc-*.so is the only library in system, which has .text for *UND* > > named realpath@@GLIBC_2.3, so problem must be in dynamic linking of > > this entry or in the libc. As for now I'm not sure, where is problem. > > Error can be in broken __realpath binaries (not in __old_realpath), > > assuming compiler code generator error, or in dynamic linker too. > > > > Anyway, in source code, (look at glibc-*/stdlib/canonicalize.c) this > > error > > (EINVAL) is returned in two places only: in __realpath, when first > parameter > > is null and in __old_realpath, when the second parameter is null (this > > is > our > > situation). __old_realpath is cover for __realpath. > > > > If this same binaries of mount.cifs in build system work but in main > system -- > > does not --- problem is probably with linked library. > > > > But as you know, there is no certainty. > > > > Best regards > > > > -- > > Andrzej Odyniec > > > > > ---------------------------------------------------------------------------- > -- > > Virtualization & Cloud Management Using Capacity Planning Cloud > > computing makes use of virtualization - but cloud computing also > > focuses on allowing computing to be delivered as a service. > > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > > _______________________________________________ > > Devil-linux-develop mailing list > > Dev...@li... > > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > > > ---------------------------------------------------------------------------- -- > Virtualization & Cloud Management Using Capacity Planning Cloud computing > makes use of virtualization - but cloud computing also focuses on allowing > computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop |
35 messages has been excluded from this view by a project administrator.
