poudriere bulk -a fails on UFS: "Too many links" under logs/bulk/latest-per-pkg/ and then "Failed: starting"

/bulk/latest-per-pkg/knot3: Too many links [30:24:13] [23] [00:00:22] Finished sysutils/ttyload | ttyload-0.5.3_1: Success [30:24:14] [05] [00:01:44] Finished deskutils/mytetra | mytetra-1.43.27: Success [30:24:15] [23] [00:00:01] Building audio/komposter | komposter-g20201211_1 [30:24:16] [05] [00

Updated stream links

FreeBSD Developer Summit Links: Room 1160: https://papers.freebsd.org/2019/bsdcan/streaming_dms1160/ Room 1140: https://papers.freebsd.org/2019/bsdcan/streaming_dms1140/ Room 1130: https://papers.freebsd.org/2019/bsdcan/streaming_dms1130

Links

FreeBSD Developer Summit Links: https://papers.freebsd.org/2019/bsdcan/streaming_dms1160/ https://papers.freebsd.org/2019/bsdcan/streaming_dms1140/ http://fengler.ca/test.html ( 1130 link will be added to papers shortly) ___ freebsd-current

Re: Long waits for Firefox and SeaMonkey to respond to links from other applications

On March 25, 2019 6:41:18 AM PDT, Kjell Tore Ullavik wrote: > > >On 24.03.2019 17.25, Graham Perrin wrote: >> When I open a web address in (for example) Thunderbird, there's a >wait >> of around fifteen seconds before the web browser, already open, >> handles the address. >> >> Affected browser

Re: Long waits for Firefox and SeaMonkey to respond to links from other applications

On 24.03.2019 17.25, Graham Perrin wrote: When I open a web address in (for example) Thunderbird, there's a wait of around fifteen seconds before the web browser, already open, handles the address. Affected browsers: - Firefox - SeaMonkey - Waterfox. Not affected: - New Moon (Pale Moon) –

Re: Long waits for Firefox and SeaMonkey to respond to links from other applications

On 24/03/2019 18:51, Adam wrote: On Sun, Mar 24, 2019 at 6:22 PM Graham Perrin > wrote: When I open a web address in (for example) Thunderbird, there's a wait of around fifteen seconds before the web browser, already open, handles the address.

Re: Long waits for Firefox and SeaMonkey to respond to links from other applications

On Sun, Mar 24, 2019 at 6:22 PM Graham Perrin wrote: > When I open a web address in (for example) Thunderbird, there's a wait > of around fifteen seconds before the web browser, already open, handles > the address. > > Affected browsers: > > - Firefox > - SeaMonkey > - Waterfox. > > Not affected:

Long waits for Firefox and SeaMonkey to respond to links from other applications

When I open a web address in (for example) Thunderbird, there's a wait of around fifteen seconds before the web browser, already open, handles the address. Affected browsers: - Firefox - SeaMonkey - Waterfox. Not affected: - New Moon (Pale Moon) – the waiting period is a split-second - Chrom

Re: network performance over 1GBps links degraded

On Sun, 18 Mar 2018 12:21:54 +0100 Gary Jennejohn wrote: > On Sun, 18 Mar 2018 11:48:32 +0100 > Alex Dupre wrote: > > > Gary Jennejohn wrote: > > > I have two computers, both with 1Gbps interfaces plugged into a > > > 1Gb switch. One computer is running FreeBSD HEAD and the other > > > some

Re: network performance over 1GBps links degraded

On Sun, 18 Mar 2018 11:48:32 +0100 Alex Dupre wrote: > Gary Jennejohn wrote: > > I have two computers, both with 1Gbps interfaces plugged into a > > 1Gb switch. One computer is running FreeBSD HEAD and the other > > some version of Linux. Under FreeBSD I have re0 and under Linux > > I don't kno

Re: network performance over 1GBps links degraded

Gary Jennejohn wrote: > I have two computers, both with 1Gbps interfaces plugged into a > 1Gb switch. One computer is running FreeBSD HEAD and the other > some version of Linux. Under FreeBSD I have re0 and under Linux > I don't know what the hardware is. > > I noticed that the transfer speed ha

network performance over 1GBps links degraded

I have two computers, both with 1Gbps interfaces plugged into a 1Gb switch. One computer is running FreeBSD HEAD and the other some version of Linux. Under FreeBSD I have re0 and under Linux I don't know what the hardware is. Both interfaces are using a MTU of 4088 because that's the maximum my

Re: "broken" symbolic links in /usr/lib

On Tue, 2015-07-28 at 22:17 +0200, Ian FREISLICH wrote: > David Wolfskill wrote: > > My experience with SU+J is limited (and negative -- in large part, > > because I tend heavily on "dump | restore" pipelines to copy file > > systems, some of which are "live" at the time (danger mitigated by -L > >

Re: "broken" symbolic links in /usr/lib

Glen Barber wrote: > On Tue, Jul 28, 2015 at 10:17:38PM +0200, Ian FREISLICH wrote: > > I found the actual problem. The mount point for /usr was mode 700 > > even though the root of the mounted filesystem on /usr was mode 755. > > Did I explain that clearly (quite difficult because two things are

Re: "broken" symbolic links in /usr/lib

On 29/07/2015 05:48, Jamie Landeg-Jones wrote: > Gary Palmer wrote: > >> As best that I can recall, the permissions of the directory underneath >> the mount point has been causing problems like this for as long as I've been >> using FreeBSD, which is over 20 years at this point. It's certainly >

Re: "broken" symbolic links in /usr/lib

Gary Palmer wrote: > As best that I can recall, the permissions of the directory underneath > the mount point has been causing problems like this for as long as I've been > using FreeBSD, which is over 20 years at this point. It's certainly > bit me in the distant past. I concur. I always make

Re: "broken" symbolic links in /usr/lib

On Tue, Jul 28, 2015 at 10:17:38PM +0200, Ian FREISLICH wrote: [trim] > So, a couple of fscks found some problems, but none causing this. > > I found the actual problem. The mount point for /usr was mode 700 > even though the root of the mounted filesystem on /usr was mode 755. > Did I explain th

Re: "broken" symbolic links in /usr/lib

On Tue, Jul 28, 2015 at 10:17:38PM +0200, Ian FREISLICH wrote: > I found the actual problem. The mount point for /usr was mode 700 > even though the root of the mounted filesystem on /usr was mode 755. > Did I explain that clearly (quite difficult because two things are > the same thing, although

Re: "broken" symbolic links in /usr/lib

David Wolfskill wrote: > My experience with SU+J is limited (and negative -- in large part, > because I tend heavily on "dump | restore" pipelines to copy file > systems, some of which are "live" at the time (danger mitigated by -L > flag for dump). As an aside, mine has been pretty positive, exce

Re: "broken" symbolic links in /usr/lib

Glen Barber wrote: > On Tue, Jul 28, 2015 at 07:31:56PM +, Glen Barber wrote: > > On Tue, Jul 28, 2015 at 08:16:16PM +0200, Ian FREISLICH wrote: > > > Hi > > >=20 > > > I cannot for the life of me figure out why this is so: > > >=20 > > > As non-root: > > > [zen] /usr/lib $ file libgcc_s.so > >

Re: "broken" symbolic links in /usr/lib

On Tue, Jul 28, 2015 at 07:31:56PM +, Glen Barber wrote: > On Tue, Jul 28, 2015 at 08:16:16PM +0200, Ian FREISLICH wrote: > > Hi > > > > I cannot for the life of me figure out why this is so: > > > > As non-root: > > [zen] /usr/lib $ file libgcc_s.so > > libgcc_s.so: broken symbolic link to .

Re: "broken" symbolic links in /usr/lib

On Tue, Jul 28, 2015 at 08:16:16PM +0200, Ian FREISLICH wrote: > Hi > > I cannot for the life of me figure out why this is so: > > As non-root: > [zen] /usr/lib $ file libgcc_s.so > libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1 > > As root: > [zen] /usr/lib # file libgcc_s.so > l

"broken" symbolic links in /usr/lib

Hi I cannot for the life of me figure out why this is so: As non-root: [zen] /usr/lib $ file libgcc_s.so libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1 As root: [zen] /usr/lib # file libgcc_s.so libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1 Only on one of my machines, all

Re: systat -ifstat on high-speed links

On Mon, Nov 03, 2014 at 11:58:56AM -0500, Ryan Stone wrote: > http://svnweb.freebsd.org/changeset/base/272284 Date: Mon Sep 29 17:38:50 2014 UTC (4 weeks, 6 days ago) MFC after: 1 week MFC stoped? ___ freebsd-current@freebsd.org mailing list http://

Re: systat -ifstat on high-speed links

http://svnweb.freebsd.org/changeset/base/272284 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

systat -ifstat on high-speed links

I am try to use 'systat -ifstat 1' when traffic over network intrface about 35Gbit. systat show about 2.5Gbit. Where is problem? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send an

Re: installworld failure due to cross-device links

stribution] Error code 1 > > Is there any real advantage of hard links over symlinks nowadays? Yes. In fact, hard links are essential for some purposes. Key advantage of hard links is that you can create and use them as long as needed and then just delete them. Any remaining hard links a

Re: installworld failure due to cross-device links

/root; install -o root -g wheel -m 644 dot.profile /tmproot/root/.profile; rm -f /tmproot/.profile; ln /tmproot/root/.profile /tmproot/.profile ln: /tmproot/.profile: Cross-device link *** [distribution] Error code 1 Is there any real advantage of hard links over symlinks nowadays? -- Sorry

Re: installworld failure due to cross-device links

Am 02.01.2013 14:26, schrieb Nathan Whitehorn: > On 01/02/13 07:04, Stefan Esser wrote: >> I'd be interested in the general policy on LINKS vs. SYMLINKS >> between directories that might end up on different file systems. >> >> There seems to be an assumption that sy

Re: installworld failure due to cross-device links

On 01/02/13 07:04, Stefan Esser wrote: > I'd be interested in the general policy on LINKS vs. SYMLINKS > between directories that might end up on different file systems. > > There seems to be an assumption that system directories in /usr > (e.g. /usr/bin, /usr/sbin, /usr/libe

installworld failure due to cross-device links

I'd be interested in the general policy on LINKS vs. SYMLINKS between directories that might end up on different file systems. There seems to be an assumption that system directories in /usr (e.g. /usr/bin, /usr/sbin, /usr/libexec) are on the same file system, but I do not think that

Re: Broken symbolic links in /usr/lib after compiling and installing -CURRENT

On Tue, May 22, 2012 2:27 pm, Jeremie Le Hen wrote: > This is expected I think, as "make buildenv" defines $_SHLIBDIRPREFIX > which is used to make the toolchain use libraries built during stage 4.2 > of buildworld. > > Just run "make installworld" with the correct DESTDIR and your chroot > will be

Re: Broken symbolic links in /usr/lib after compiling and installing -CURRENT

Ilya, On Mon, May 21, 2012 at 01:43:39PM +0200, Ilya Bakulin wrote: > On Mon, May 21, 2012 12:36 pm, Jeremie Le Hen wrote: > > Can you provide the exact commands you have used to create your chroot? > > > Sure! > > 1. The build host is FreeBSD 8.2-RELEASE-p3 amd64 > 2. Directory where project res

Re: Broken symbolic links in /usr/lib after compiling and installing -CURRENT

On Mon, May 21, 2012 12:36 pm, Jeremie Le Hen wrote: > Can you provide the exact commands you have used to create your chroot? > Sure! 1. The build host is FreeBSD 8.2-RELEASE-p3 amd64 2. Directory where project resides ($PROJROOT): /home/kibab/repos/freebsd-cap-git 2. FreeBSD-CURRENT sources are

Re: Broken symbolic links in /usr/lib after compiling and installing -CURRENT

> lrwxr-xr-x 1 0 0 73 20 ?? 09:54 libbegemot.so -> > /usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib/libbegemot.so.4 > ... > lrwxr-xr-x 1 root wheel 71 20 ?????? 21:31 libgcc_s.so -> > /usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib/libgcc_s.so.1 > >

Broken symbolic links in /usr/lib after compiling and installing -CURRENT

git/freebsd/tmp/lib/libgcc_s.so.1 Links to libalias, libbegemot, libgcc_s point to respective libraries under /usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib. But this path doesn't exist even on build system! In my setup, FreeBSD source tree is under /home/kibab/repos/freebsd-cap-git/f

Making hastd working over WAN links (was: Randomization in hastd(8) synchronization thread)

On 5/17/2011 1:28 PM, Maxim Sobolev wrote: The next thing to make it usable is to make "async" mode working. I think simple support for that mode can be easily implemented by not sending write request to the remote note at all, but instead just doing it locally and kicking the synchronization thr

Re: devfs rules and symbolik links

In message <[EMAIL PROTECTED]>, Dima Dorfman writes: >Taavi Talvik <[EMAIL PROTECTED]> wrote: >> >> I'i try to set up jail with following script, however >> as result, urandom/stdin/stdout/stderr will not appear. >> >> They exist before applying devfs rules, but I cannot find >> rules how to unhi

Re: devfs rules and symbolik links

Taavi Talvik <[EMAIL PROTECTED]> wrote: > > I'i try to set up jail with following script, however > as result, urandom/stdin/stdout/stderr will not appear. > > They exist before applying devfs rules, but I cannot find > rules how to unhide those. Any ideas!? Please try the attached patch, which

devfs rules and symbolik links

I'i try to set up jail with following script, however as result, urandom/stdin/stdout/stderr will not appear. They exist before applying devfs rules, but I cannot find rules how to unhide those. Any ideas!? best regards, taavi PS. sshd "PRNG not seeded" seems to be related to "urandom" existanc