PUBLICIDAD - Bienvenido a Hosting Web DDPyP
Bienvenido a Hosting Web DDPyP Visite nuestra nueva web, con el mismo nivel de atencion de siempre!!! Para darse de baja envienos un mail aqui Staff DDPyP Hosting www.ddpyp.com.ar i...@ddpyp.com.ar
Antimalware for server mail and filesystems protect
Hi all I'm searching one soluce for protected my data ... . I'm look Clamav ( it's a good idea ?), ESET is good antimalware for BSD. You soluce and hack, help please. Cordialy
Re: chromium can't start since two snapshots
On Sat, May 19, 2012 at 12:12:32PM -0400, Mike Erdely wrote: > On Sat, May 19, 2012 at 6:58 AM, Peter N. M. Hansteen > wrote: > > Here, on amd64, removing only the .config/chromium/SingletonLock did the > > trick. It would have taken me a while to infer that from the error > > message, though ;) > > Hopefully this will fix it: > http://marc.info/?l=openbsd-ports-cvs&m=133727364220056&w=2 Unfortunately no. This is just a temporary workaround. -- Antoine
Re: disable password check using /etc/login.conf file
On 2012-05-18, Wesley MOUEDINE ASSABY wrote: > i'm trying to disable password check. I have to ask... why? I hope a machine with such weak passwords is not running network- accessible login services (pop3, imap, smtp auth, ftp, ssh, ...)
Re: unbound
On 2012-05-19, Chris Smith wrote: > As unbound is now in base but not yet built by default how is it built > in order to test it (is it a simple 'make install' or is more > involved)? $ make -f Makefile.bsd-wrapper obj $ make -f Makefile.bsd-wrapper $ sudo make -f Makefile.bsd-wrapper install $ sudo unbound-control start > How to add it to the list the gets built with a "make > build" of userland (or is this even safe)? Or is it simply best to use > packages or ports at this time? I'll try and find time to properly review the diff to add it to the system infrastructure (/etc/rc and /etc/rc.d parts etc) in the next week or so. I am pretty confident in unbound itself but the system integration is less well-tested so it needs a more careful look.
Re: unbound
> As unbound is now in base but not yet built by default how is it built > in order to test it (is it a simple 'make install' or is more > involved)? How to add it to the list the gets built with a "make > build" of userland (or is this even safe)? Or is it simply best to use > packages or ports at this time? It should be enabled real soon by whoever is bringing it in
unbound
As unbound is now in base but not yet built by default how is it built in order to test it (is it a simple 'make install' or is more involved)? How to add it to the list the gets built with a "make build" of userland (or is this even safe)? Or is it simply best to use packages or ports at this time? Thank you, Chris
Re: disable password check using /etc/login.conf file
passwd(1) The quality of the password can be enforced by specifying an external checking program via the ``passwordcheck'' variable in login.conf(5). Finally all passwords typed by the user (insane class) are controlled by passwd(1) and then controlled this time with passwordcheck program It is only possible to do it using through a script (combining pw_mkdb and master.passwd). Sorry for this useless post. cheers, -- Wesley. Le 19 mai 2012 ` 23:38, Wesley MOUEDINE ASSABY a icrit : > Sorry 'tc=default' was missing at the end : > > insane:\ > :minpasswordlen=4:\ > :passwordcheck=/usr/bin/true:\ > :passwordtries=0:\ > :tc=default: > > It doesn't work, still need a more complicated password. > > I read login.conf (5) : > passwordcheck program An external program that > checks the quality of the > password. The password is > passed to the program on > stdin. An exit code of 0 > indicates that the quality > of > the password is sufficient, > an exit code of 1 signals > that the password failed the > check. > > and > > passwordtries number 3 The number of times the > passwd(1) utility enforces a > check on the password. If > 0, > the new password will only > be > accepted if it passes the > password quality check. > > Any idea ? > > Thank you very much. > > Cheers, > > Wesley. > > > > Le 18 mai 2012 ` 23:20, Wesley MOUEDINE ASSABY a icrit : > >> Hi, >> >> i'm trying to disable password check. I already read man page of login.conf >> (5) and passwd (1). >> What i have done : >> >> - add a new class "insane" in /etc/login.conf : >> >> insane:\ >> :minpasswordlen=1:\ >> :passwordcheck=/usr/bin/true:\ >> :passwordtries=1: >> >> - add a new user with this class >> >> The length control is ok, tries is also ok, but the password check is still >> here. >> Any idea to disable it ? >> >> Cheers, >> >> Wesley.
Re: disable password check using /etc/login.conf file
Sorry 'tc=default' was missing at the end : insane:\ :minpasswordlen=4:\ :passwordcheck=/usr/bin/true:\ :passwordtries=0:\ :tc=default: It doesn't work, still need a more complicated password. I read login.conf (5) : passwordcheck program An external program that checks the quality of the password. The password is passed to the program on stdin. An exit code of 0 indicates that the quality of the password is sufficient, an exit code of 1 signals that the password failed the check. and passwordtries number 3 The number of times the passwd(1) utility enforces a check on the password. If 0, the new password will only be accepted if it passes the password quality check. Any idea ? Thank you very much. Cheers, Wesley. Le 18 mai 2012 ` 23:20, Wesley MOUEDINE ASSABY a icrit : > Hi, > > i'm trying to disable password check. I already read man page of login.conf > (5) and passwd (1). > What i have done : > > - add a new class "insane" in /etc/login.conf : > > insane:\ > :minpasswordlen=1:\ > :passwordcheck=/usr/bin/true:\ > :passwordtries=1: > > - add a new user with this class > > The length control is ok, tries is also ok, but the password check is still > here. > Any idea to disable it ? > > Cheers, > > Wesley.
Re: Watchdog timeout reset in 5.1 on intel nic:s
On 19 maj 2012, at 17:58, Garry Dolley wrote: > On Sat, May 19, 2012 at 04:40:08PM +0200, Per-Olov SjC6holm wrote: >> >> >> On 19 maj 2012, at 08:11, Garry Dolley wrote: >> >>> On Sat, May 19, 2012 at 01:54:54AM +0200, Per-Olov Sjvholm wrote: On 17 maj 2012, at 12:53, Garry Dolley wrote: > On Thu, May 17, 2012 at 03:19:07AM -0700, Garry Dolley wrote: >> On Fri, May 11, 2012 at 09:13:30AM -0400, Simon Perreault wrote: >>> On 2012-05-11 04:15, Garry Dolley wrote: I now have an amd64 test VM set up, where I installed stock 5.0. I ran a lot of traffic over em0 without any timeouts. >>> >>> That's expected. 5.0 has been running without issue for me for a long time. >>> I also have been trying several -current kernels. As of: OpenBSD 5.1-current (GENERIC) #205: Wed Mar 28 21:40:45 MDT 2012 I don't see any em0 timeouts. I will continue to try newer ones and report back here... >>> >>> Why not just test 5.1? Problems have been reported against 5.1, not >>> -current. >> >> I now have a stock 5.1 test VM set up. >> >> OpenBSD 5.1 (GENERIC) #181: Sun Feb 12 09:35:53 MST 2012 >>dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC >> >> I don't see any timeouts. I grabbed the ports tree via curl several >> times and have been slaving away at it over SSH. I don't notice >> anything wrong. >> >> So, perhaps this issue does not appear in stock 5.1, but in a newer >> kernel. I'll try something newer soon... > > I have tried the following newer kernels: > > bsd.20120330 > bsd.20120419 > bsd.20120427 > bsd.20120516 > > I still can't reproduce the problem. > > I have disabled mpbios on all these kernels, forgot to mention that. > > I will leave this be for now; will pick it up again if any new > information should arise. > > -- > Garry Dolley > ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 > Data center, VPS, and IP Transit solutions > Member Los Angeles County REACT, Unit 336 | WQGK336 > Blog http://scie.nti.st > I have a running 4.9 release + patches ( i.e 4.9 stable) working perfect. When Updated to 5.1 release + patches I have real problems with watchdog timeout resets on my intel nic:s. Same hardware, but just different OpenBSD version. I have tried a bunch of kernels from Stuart Henderson (Broken after 4.9.). I have also recompiled the 5.1 stable kernel with most versions of the if_em.c driver. I have compiled and tried the following... (note that the userland was 5.1 stable with all kernel tests) bsd-5.1-stable bsd-5.1-stable_plus_if_em.c-1.249 bsd-5.1-stable_plus_if_em.c-1.250 bsd-5.1-stable_plus_if_em.c-1.251 bsd-5.1-stable_plus_if_em.c-1.252 bsd-5.1-stable_plus_if_em.c-1.253 bsd-5.1-stable_plus_if_em.c-1.254 bsd-5.1-stable_plus_if_em.c-1.263 Watchdog timeout resets on all versions. NOTE that the Watchdog timeout reset appears in version 1.249 of if_em.c as well. And that version is default in 4.9 stable which works fantastic. So if I haven't done anything totally wrong it must be related to something else in the kernel. So my nic hardware and the kvm bios is the same. And an if_em.c version that works in 4.9 is tried. I can see above that you got rid of the problem by testing the same version as me.. But you use AMD and I use i386. Also... I have a firewall with 2 nic:s. Often ONE nic works but the other gives watchdog timeout resets and wont work. Any clues? >>> >>> I don't have any clues. I wasn't able to reproduce the problem, >>> even though one customer I have who also upgraded experienced this >>> behavior. They did not do a fresh install (that I'm aware), but >>> upgraded (similar to you). I'm not sure what the previous version >>> was. They have one NIC and I believe run amd64. >>> >>> The only difference that I can see is that on a fresh 5.1 install, >>> there is no issue. But if you upgrade from a previous release, then >>> the issue *might* appear. >>> >>> -- >>> Garry Dolley >>> ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 >>> Data center, VPS, and IP Transit solutions >>> Member Los Angeles County REACT, Unit 336 | WQGK336 >>> Blog http://scie.nti.st >>> >> >> I have a fresh 5.1 rel plus stable patches. No upgrade... > > What happened before you applied the stable patches? On the fresh > 5.1 release without any changes, that is... > > -- > Garry Dolley > ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 > Data center, VPS, and IP Transit solutions > Member Los Angeles County REACT, Unit 336 | WQGK336 > Blog http://scie.nti.st That i have
PF : prio keyword sticky on match rules ?
Hi, It's not mentioned in pf.conf manual page but I'm wondering if the 'prio' keyword is sticky on match rules, like for exemple the 'queue' keyword. Is it possible to write : match on $ext_if proto tcp prio (2, 5) In order to priorize TCP ACK packets on all flows ? Mattieu Baptiste "/earth is 102% full ... please delete anyone you can."
Re: chromium can't start since two snapshots
On Sat, May 19, 2012 at 6:58 AM, Peter N. M. Hansteen wrote: > Here, on amd64, removing only the .config/chromium/SingletonLock did the > trick. It would have taken me a while to infer that from the error > message, though ;) Hopefully this will fix it: http://marc.info/?l=openbsd-ports-cvs&m=133727364220056&w=2 -ME
Re: Watchdog timeout reset in 5.1 on intel nic:s
On Sat, May 19, 2012 at 04:40:08PM +0200, Per-Olov Sjvholm wrote: > > > On 19 maj 2012, at 08:11, Garry Dolley wrote: > > > On Sat, May 19, 2012 at 01:54:54AM +0200, Per-Olov Sjvholm wrote: > >> On 17 maj 2012, at 12:53, Garry Dolley wrote: > >> > >>> On Thu, May 17, 2012 at 03:19:07AM -0700, Garry Dolley wrote: > On Fri, May 11, 2012 at 09:13:30AM -0400, Simon Perreault wrote: > > On 2012-05-11 04:15, Garry Dolley wrote: > >> I now have an amd64 test VM set up, where I installed stock 5.0. > >> > >> I ran a lot of traffic over em0 without any timeouts. > > > > That's expected. 5.0 has been running without issue for me for a long > >> time. > > > >> I also have been trying several -current kernels. > >> > >> As of: > >> > >> OpenBSD 5.1-current (GENERIC) #205: Wed Mar 28 21:40:45 MDT 2012 > >> > >> I don't see any em0 timeouts. > >> > >> I will continue to try newer ones and report back here... > > > > Why not just test 5.1? Problems have been reported against 5.1, not > > -current. > > I now have a stock 5.1 test VM set up. > > OpenBSD 5.1 (GENERIC) #181: Sun Feb 12 09:35:53 MST 2012 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > > I don't see any timeouts. I grabbed the ports tree via curl several > times and have been slaving away at it over SSH. I don't notice > anything wrong. > > So, perhaps this issue does not appear in stock 5.1, but in a newer > kernel. I'll try something newer soon... > >>> > >>> I have tried the following newer kernels: > >>> > >>> bsd.20120330 > >>> bsd.20120419 > >>> bsd.20120427 > >>> bsd.20120516 > >>> > >>> I still can't reproduce the problem. > >>> > >>> I have disabled mpbios on all these kernels, forgot to mention that. > >>> > >>> I will leave this be for now; will pick it up again if any new > >>> information should arise. > >>> > >>> -- > >>> Garry Dolley > >>> ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 > >>> Data center, VPS, and IP Transit solutions > >>> Member Los Angeles County REACT, Unit 336 | WQGK336 > >>> Blog http://scie.nti.st > >>> > >> > >> > >> I have a running 4.9 release + patches ( i.e 4.9 stable) working perfect. > >> When > >> Updated to 5.1 release + patches I have real problems with watchdog timeout > >> resets on my intel nic:s. Same hardware, but just different OpenBSD > >> version. > >> > >> I have tried a bunch of kernels from Stuart Henderson (Broken after > >> 4.9.). > >> I have also recompiled the 5.1 stable kernel with most versions of the > >> if_em.c driver. I have compiled and tried the following... > >> (note that the userland was 5.1 stable with all kernel tests) > >> > >> bsd-5.1-stable > >> bsd-5.1-stable_plus_if_em.c-1.249 > >> bsd-5.1-stable_plus_if_em.c-1.250 > >> bsd-5.1-stable_plus_if_em.c-1.251 > >> bsd-5.1-stable_plus_if_em.c-1.252 > >> bsd-5.1-stable_plus_if_em.c-1.253 > >> bsd-5.1-stable_plus_if_em.c-1.254 > >> bsd-5.1-stable_plus_if_em.c-1.263 > >> > >> Watchdog timeout resets on all versions. > >> > >> NOTE that the Watchdog timeout reset appears in version 1.249 of if_em.c as > >> well. And that version is default in 4.9 stable which works fantastic. So > >> if I > >> haven't done anything totally wrong it must be related to something else in > >> the kernel. So my nic hardware and the kvm bios is the same. And an > >> if_em.c version that works in 4.9 is tried. > >> > >> > >> I can see above that you got rid of the problem by testing the same > >> version as > >> me.. But you use AMD and I use i386. > >> Also... I have a firewall with 2 nic:s. Often ONE nic works but the other > >> gives watchdog timeout resets and wont work. > >> > >> Any clues? > > > > I don't have any clues. I wasn't able to reproduce the problem, > > even though one customer I have who also upgraded experienced this > > behavior. They did not do a fresh install (that I'm aware), but > > upgraded (similar to you). I'm not sure what the previous version > > was. They have one NIC and I believe run amd64. > > > > The only difference that I can see is that on a fresh 5.1 install, > > there is no issue. But if you upgrade from a previous release, then > > the issue *might* appear. > > > > -- > > Garry Dolley > > ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 > > Data center, VPS, and IP Transit solutions > > Member Los Angeles County REACT, Unit 336 | WQGK336 > > Blog http://scie.nti.st > > > > I have a fresh 5.1 rel plus stable patches. No upgrade... What happened before you applied the stable patches? On the fresh 5.1 release without any changes, that is... -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st
Re: Watchdog timeout reset in 5.1 on intel nic:s
On 19 maj 2012, at 08:11, Garry Dolley wrote: > On Sat, May 19, 2012 at 01:54:54AM +0200, Per-Olov Sjvholm wrote: >> On 17 maj 2012, at 12:53, Garry Dolley wrote: >> >>> On Thu, May 17, 2012 at 03:19:07AM -0700, Garry Dolley wrote: On Fri, May 11, 2012 at 09:13:30AM -0400, Simon Perreault wrote: > On 2012-05-11 04:15, Garry Dolley wrote: >> I now have an amd64 test VM set up, where I installed stock 5.0. >> >> I ran a lot of traffic over em0 without any timeouts. > > That's expected. 5.0 has been running without issue for me for a long >> time. > >> I also have been trying several -current kernels. >> >> As of: >> >> OpenBSD 5.1-current (GENERIC) #205: Wed Mar 28 21:40:45 MDT 2012 >> >> I don't see any em0 timeouts. >> >> I will continue to try newer ones and report back here... > > Why not just test 5.1? Problems have been reported against 5.1, not > -current. I now have a stock 5.1 test VM set up. OpenBSD 5.1 (GENERIC) #181: Sun Feb 12 09:35:53 MST 2012 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC I don't see any timeouts. I grabbed the ports tree via curl several times and have been slaving away at it over SSH. I don't notice anything wrong. So, perhaps this issue does not appear in stock 5.1, but in a newer kernel. I'll try something newer soon... >>> >>> I have tried the following newer kernels: >>> >>> bsd.20120330 >>> bsd.20120419 >>> bsd.20120427 >>> bsd.20120516 >>> >>> I still can't reproduce the problem. >>> >>> I have disabled mpbios on all these kernels, forgot to mention that. >>> >>> I will leave this be for now; will pick it up again if any new >>> information should arise. >>> >>> -- >>> Garry Dolley >>> ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 >>> Data center, VPS, and IP Transit solutions >>> Member Los Angeles County REACT, Unit 336 | WQGK336 >>> Blog http://scie.nti.st >>> >> >> >> I have a running 4.9 release + patches ( i.e 4.9 stable) working perfect. When >> Updated to 5.1 release + patches I have real problems with watchdog timeout >> resets on my intel nic:s. Same hardware, but just different OpenBSD version. >> >> I have tried a bunch of kernels from Stuart Henderson (Broken after 4.9.). >> I have also recompiled the 5.1 stable kernel with most versions of the >> if_em.c driver. I have compiled and tried the following... >> (note that the userland was 5.1 stable with all kernel tests) >> >> bsd-5.1-stable >> bsd-5.1-stable_plus_if_em.c-1.249 >> bsd-5.1-stable_plus_if_em.c-1.250 >> bsd-5.1-stable_plus_if_em.c-1.251 >> bsd-5.1-stable_plus_if_em.c-1.252 >> bsd-5.1-stable_plus_if_em.c-1.253 >> bsd-5.1-stable_plus_if_em.c-1.254 >> bsd-5.1-stable_plus_if_em.c-1.263 >> >> Watchdog timeout resets on all versions. >> >> NOTE that the Watchdog timeout reset appears in version 1.249 of if_em.c as >> well. And that version is default in 4.9 stable which works fantastic. So if I >> haven't done anything totally wrong it must be related to something else in >> the kernel. So my nic hardware and the kvm bios is the same. And an >> if_em.c version that works in 4.9 is tried. >> >> >> I can see above that you got rid of the problem by testing the same version as >> me.. But you use AMD and I use i386. >> Also... I have a firewall with 2 nic:s. Often ONE nic works but the other >> gives watchdog timeout resets and wont work. >> >> Any clues? > > I don't have any clues. I wasn't able to reproduce the problem, > even though one customer I have who also upgraded experienced this > behavior. They did not do a fresh install (that I'm aware), but > upgraded (similar to you). I'm not sure what the previous version > was. They have one NIC and I believe run amd64. > > The only difference that I can see is that on a fresh 5.1 install, > there is no issue. But if you upgrade from a previous release, then > the issue *might* appear. > > -- > Garry Dolley > ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 > Data center, VPS, and IP Transit solutions > Member Los Angeles County REACT, Unit 336 | WQGK336 > Blog http://scie.nti.st > I have a fresh 5.1 rel plus stable patches. No upgrade... Per-Olov
Re: Watchdog timeout reset in 5.1 on intel nic:s
On 19 maj 2012, at 16:31, Kenneth R Westerback wrote: > On Fri, May 18, 2012 at 11:11:07PM -0700, Garry Dolley wrote: >> On Sat, May 19, 2012 at 01:54:54AM +0200, Per-Olov Sjvholm wrote: >> >> I don't have any clues. I wasn't able to reproduce the problem, >> even though one customer I have who also upgraded experienced this >> behavior. They did not do a fresh install (that I'm aware), but >> upgraded (similar to you). I'm not sure what the previous version >> was. They have one NIC and I believe run amd64. >> >> The only difference that I can see is that on a fresh 5.1 install, >> there is no issue. But if you upgrade from a previous release, then >> the issue *might* appear. >> >> -- >> Garry Dolley >> ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 >> Data center, VPS, and IP Transit solutions >> Member Los Angeles County REACT, Unit 336 | WQGK336 >> Blog http://scie.nti.st >> > > I find it very hard to credit that the network card would behave > differently in the upgrade and install cases. Both install the > exact same new kernel, wherein the drivers reside. > > Ken > +1 Per-Olov
Re: Watchdog timeout reset in 5.1 on intel nic:s
On Fri, May 18, 2012 at 11:11:07PM -0700, Garry Dolley wrote: > On Sat, May 19, 2012 at 01:54:54AM +0200, Per-Olov Sjvholm wrote: > > I don't have any clues. I wasn't able to reproduce the problem, > even though one customer I have who also upgraded experienced this > behavior. They did not do a fresh install (that I'm aware), but > upgraded (similar to you). I'm not sure what the previous version > was. They have one NIC and I believe run amd64. > > The only difference that I can see is that on a fresh 5.1 install, > there is no issue. But if you upgrade from a previous release, then > the issue *might* appear. > > -- > Garry Dolley > ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 > Data center, VPS, and IP Transit solutions > Member Los Angeles County REACT, Unit 336 | WQGK336 > Blog http://scie.nti.st > I find it very hard to credit that the network card would behave differently in the upgrade and install cases. Both install the exact same new kernel, wherein the drivers reside. Ken
A totally meaningless statistics that may serve to cheer you up
It seems that with a boost from the recent http://undeadly.org mention,
the online version of my PF tutorial sped past 120,000 unique visitors
total, with
peter@nerdhaven:~$ grep peter/pf /var/log/httpd/home.nuug.no_log | awk '{print
$1}' | sort | uniq |wc -l
121150
(total # of unique ip addresses/host names hitting somewhere under
http://home.nuug.no/~peter/pf/, with http://home.nuug.no/~peter/pf/newest/
the likely main contributor recently)
and just to produce a meaningless statistic,
peter@nerdhaven:~$ grep -c peter/pf /var/log/httpd/home.nuug.no_log
1916849
for raw # of hits to somewhere in that tree. Here's hoping this produced
at least some CD sales and perhaps the odd book sale.
- Peter
PS Do get your EuroBSDCon submission in, tomorrow's the deadline
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: chromium can't start since two snapshots
Mihai Popescu writes: > I confirm this is happening on i386 too, but I removed the entire > chromium folder and cache. OK, it needs to reconfigure the options ... Here, on amd64, removing only the .config/chromium/SingletonLock did the trick. It would have taken me a while to infer that from the error message, though ;) - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: chromium can't start since two snapshots
I confirm this is happening on i386 too, but I removed the entire chromium folder and cache. OK, it needs to reconfigure the options ...
Re: chromium can't start since two snapshots
On Sat, May 19, 2012 at 4:01 AM, Antoine Jacoutot wrote: > On Sat, May 19, 2012 at 10:53:39AM +0200, cbrisseau wrote: >> Hi, >> >> Since two packages snapshots, I can't start chromium anymore. I have >> installed latest amd64 snapshot from May 17, and latest packages >> snapshot from May 16. >> >> When starting chromium I have: >> $ chrome >> /usr/local/chrome/chrome:/usr/lib/libstdc++.so.54.0: >> /usr/local/lib/libestdc++.so.14.0 : WARNING: >> symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink >> your program >> terminate called after throwing an instance of 'std::logic_error' >> B what(): B basic_string::_S_construct null not valid >> zsh: abort (core dumped) B chrome >> >> >> Is it a known problem or my mistake? > > rm ~/.config/chromium/SingletonLock > > -- > Antoine > voodoo, it works...
Re: chromium can't start since two snapshots
On Sat, May 19, 2012 at 10:53:39AM +0200, cbrisseau wrote: > Hi, > > Since two packages snapshots, I can't start chromium anymore. I have > installed latest amd64 snapshot from May 17, and latest packages > snapshot from May 16. > > When starting chromium I have: > $ chrome > /usr/local/chrome/chrome:/usr/lib/libstdc++.so.54.0: > /usr/local/lib/libestdc++.so.14.0 : WARNING: > symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink > your program > terminate called after throwing an instance of 'std::logic_error' > what(): basic_string::_S_construct null not valid > zsh: abort (core dumped) chrome > > > Is it a known problem or my mistake? rm ~/.config/chromium/SingletonLock -- Antoine
chromium can't start since two snapshots
Hi, Since two packages snapshots, I can't start chromium anymore. I have installed latest amd64 snapshot from May 17, and latest packages snapshot from May 16. When starting chromium I have: $ chrome /usr/local/chrome/chrome:/usr/lib/libstdc++.so.54.0: /usr/local/lib/libestdc++.so.14.0 : WARNING: symbol(_ZN11__gnu_debug17_S_debug_messagesE) size mismatch, relink your program terminate called after throwing an instance of 'std::logic_error' what(): basic_string::_S_construct null not valid zsh: abort (core dumped) chrome Is it a known problem or my mistake? Regards, Cedric
