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

[Mark Millard]

Looks like there are too many ports for "poudiere bulk -a" to work on UFS:
more than 32767 directory files to go in the likes of logs/bulk/latest-per-pkg/
as an example.

Context:

# uname -apKU
you have mail
FreeBSD amd64-UFS 15.0-CURRENT FreeBSD 15.0-CURRENT #126 
main-n266130-d521abdff236-dirty: Tue Oct 24 18:17:40 PDT 2023 
root@amd64-ZFS:/usr/obj/BUILDs/main-amd64-nodbg-clang/usr/main-src/amd64.amd64/sys/GENERIC-NODBG
 amd64 amd64 152 152

=>40  2930277088  nda1  GPT  (1.4T)
  402008- free -  (1.0M)
2048  532480 1  efi  (260M)
  534528 1562624- free -  (763M)
 2097152  2919235584 2  freebsd-ufs  (1.4T)
  2921332736 8944392- free -  (4.3G)

# ~/fbsd-based-on-what-commit.sh -C /usr/ports
6ec8e3450b29 (HEAD -> main, freebsd/main, freebsd/HEAD) devel/sdts++: Mark 
DEPRECATED
Author: Muhammad Moinur Rahman 
Commit: Muhammad Moinur Rahman 
CommitDate: 2023-10-21 19:01:38 +
branch: main
merge-base: 6ec8e3450b29462a590d09fb0b07ed214d456bd5
merge-base: CommitDate: 2023-10-21 19:01:38 +
n637598 (--first-parent --count for merge-base)

# ls -a /usr/local/poudriere/data/logs/bulk/latest-per-pkg/ | wc -l
   32767

From the bulk -a output:

. . .
[30:24:09] [32] [00:00:42] Finished devel/p5-DateTime-Calendar-Hebrew | 
p5-DateTime-Calendar-Hebrew-0.05_1: Success
[30:24:10] [32] [00:00:00] Building dns/knot3 | knot3-3.3.1
mkdir: /usr/local/poudriere/data/logs/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:00:00] Building devel/pear-SebastianBergmann_PHPCPD | 
php81-pear-SebastianBergmann_PHPCPD-2.0.0
[30:24:16] [08] [00:18:43] Finished mail/cyrus-imapd36@http | 
cyrus-imapd36-http-3.6.3: Success
mkdir: /usr/local/poudriere/data/logs/bulk/latest-per-pkg/komposter: Too many 
links
[30:24:17] [08] [00:00:00] Building sysutils/p5-Samba-SIDhelper | 
p5-Samba-SIDhelper-0.0.0_3
mkdir: 
/usr/local/poudriere/data/logs/bulk/latest-per-pkg/php81-pear-SebastianBergmann_PHPCPD:
 Too many links
[30:24:18] [19] [00:00:38] Finished devel/p5-Test-WWW-Mechanize-CGIApp | 
p5-Test-WWW-Mechanize-CGIApp-0.05_1: Success
[30:24:18] [12] [00:00:24] Finished net-mgmt/p5-Mon | p5-Mon-0.11_1: Success
[30:24:19] [19] [00:00:00] Building mail/squirrelmail-plugins@php82 | 
squirrelmail-plugins-php82-1.0_2
[30:24:19] [12] [00:00:00] Building security/bsmtrace | bsmtrace-1.4_1
mkdir: /usr/local/poudriere/data/logs/bulk/latest-per-pkg/p5-Samba-SIDhelper: 
Too many links
mkdir: 
/usr/local/poudriere/data/logs/bulk/latest-per-pkg/squirrelmail-plugins-php82: 
Too many links
mkdir: /usr/local/poudriere/data/logs/bulk/latest-per-pkg/bsmtrace: Too many 
links
[30:24:24] [17] [00:00:29] Finished devel/p5-Class-Delegation | 
p5-Class-Delegation-1.9.0: Success
[30:24:24] [17] [00:00:00] Building devel/py-memory-profiler@py39 | 
py39-memory-profiler-0.61.0
[30:24:25] [13] [00:00:21] Finished converters/nomyso | nomyso-4.3: Success
[30:24:25] [13] [00:00:00] Building devel/rubygem-aws-sdk | 
rubygem-aws-sdk-3.1.0
mkdir: /usr/local/poudriere/data/logs/bulk/latest-per-pkg/py39-memory-profiler: 
Too many links
mkdir: /usr/local/poudriere/data/logs/bulk/latest-per-pkg/rubygem-aws-sdk: Too 
many links
[30:24:29] [16] [00:15:52] Finished games/sauerbraten | sauerbraten-20201221_2: 
Success
[30:24:30] [16] [00:00:00] Building lang/ccl | ccl-1.12_2
[30:24:30] [20] [00:09:58] Finished security/sssd@default | sssd-1.16.5_10: 
Success
mkdir: /usr/local/poudriere/data/logs/bulk/latest-per-pkg/ccl: Too many links
[30:24:33] [20] [00:00:00] Building games/xpired | xpired-1.22_24
[30:24:33] [18] [00:01:12] Finished irc/miau | miau-0.6.6_3: Success
[30:24:34] [18] [00:00:00] Building textproc/rubygem-nokogumbo | 
rubygem-nokogumbo-2.0.5_2
mkdir: /usr/local/poudriere/data/logs/bulk/latest-per-pkg/xpired: Too many links
mkdir: /usr/local/poudriere/data/logs/bulk/latest-per-pkg/rubygem-nokogumbo: 
Too many links
[30:24:39] [22] [00:01:12] Finished net/zsync | zsync-0.6.2_2: Success
[30:24:39] [22] [00:00:00] Building devel/distcc | distcc-3.4
mkdir: /usr/local/poudriere/data/logs/bulk/latest-per-pkg/distcc: Too many links
[30:24:49] [01] [00:05:11] Finished audio/myxer | myxer-1.2.1_26: Success
[30:24:50] [01] [00:00:00] Building security/theonionbox | theonionbox-4.3.1_2
mkdir: /usr/local/poudriere/data/logs/bulk/latest-per-pkg/theonionbox: Too many 
links
[30:24:56] [21] [00:01:41] Finished dns/knock | knockpy-5.4.0_2: Success
[30:24:57] [29] [00:01:56] Finished games/meandmyshadow | meandmyshadow-0.5a_2: 
Success
[30:24:58] [21] [00:00:00] Building biology/phyml | phyml-3.3.20220408_1,1
[30:24:58] [29] [00:00:00] Building security/globalprotect-openconnect | 
globalprotect-openconnect-1.4.9_1
m

Updated stream links

[Pat McEvoy]

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/


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Links

[Pat McEvoy]

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@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Cy Schubert]

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 browsers:
>>
>> - Firefox
>> - SeaMonkey
>> - Waterfox.
>>
>> Not affected:
>>
>> - New Moon (Pale Moon) – the waiting period is a split-second
>> - Chromium – split-second
>> - Falkon – less than two seconds.
>>
>> Any ideas?
>>
>>  shows the waiting period with
>
>> Konsole as the starting point, Firefox as the default web browser.
>>
>> I can't say exactly when the problem began, but it was long before 
>> Firefox 66.
>>
>> 
>>
>> $ date ; uname -v
>> Sun 24 Mar 2019 16:23:22 GMT
>> FreeBSD 13.0-CURRENT r345330 GENERIC-NODEBUG
>> $ pkg query '%o %v %R' firefox seamonkey waterfox
>> www/firefox 66.0_3,1 poudriere
>> www/seamonkey 2.49.4_24 FreeBSD
>> www/waterfox 56.2.7.2 poudriere
>> $
>
>I have seen this as well. But not right now so can't investigate.
>Could it be a dbus problem?
>
>I also have a vague and incomplete memory of fixing a similar
>problem a long time ago by filling out my /etc/hosts.
>Though that seems a bit weird.
>
>
>
>___
>freebsd-current@freebsd.org mailing list
>https://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to
>"freebsd-current-unsubscr...@freebsd.org"

The way to attack this problem is to run tcpdump on the interface while running 
DTrace against firefox or under truss -d. Simply running tcpdump without the 
other might give you enough information to at least make an educated guess.

Also, ff & friends are especially sensitive to load. If you're doing buildworld 
-j while using ff, don't or give ff a higher priority. I've seen it use 
multiple threads within multiple processes.

Make sure you have lots of RAM. ff doesn't like to have any of it's working set 
paged out.


-- 
Pardon the typos and autocorrect, small keyboard in use.
Cheers,
Cy Schubert 
FreeBSD UNIX:  Web: http://www.FreeBSD.org

The need of the many outweighs the greed of the few.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Kjell Tore Ullavik]

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) – the waiting period is a split-second
- Chromium – split-second
- Falkon – less than two seconds.

Any ideas?

 shows the waiting period with 
Konsole as the starting point, Firefox as the default web browser.


I can't say exactly when the problem began, but it was long before 
Firefox 66.




$ date ; uname -v
Sun 24 Mar 2019 16:23:22 GMT
FreeBSD 13.0-CURRENT r345330 GENERIC-NODEBUG
$ pkg query '%o %v %R' firefox seamonkey waterfox
www/firefox 66.0_3,1 poudriere
www/seamonkey 2.49.4_24 FreeBSD
www/waterfox 56.2.7.2 poudriere
$


I have seen this as well. But not right now so can't investigate.
Could it be a dbus problem?

I also have a vague and incomplete memory of fixing a similar
problem a long time ago by filling out my /etc/hosts.
Though that seems a bit weird.



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Graham Perrin]

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.

Affected browsers:

- Firefox
- SeaMonkey
- Waterfox.

Not affected:

- New Moon (Pale Moon) – the waiting period is a split-second
- Chromium – split-second
- Falkon – less than two seconds.

Any ideas?


Start thunderbird from a terminal so you can see an messages.

No message during the waiting period.

Sounds like a tcp or dns timeout, so perhaps some addon.


Reproducible with Firefox in safe mode.

Also reproducible with a user account that I rarely touch (it was this 
account that I used for the screen recording).


Bugging multiple desktop environments, if I recall correctly I 
reproduced the issue with MATE and Xfce.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Adam]

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:
>
> - New Moon (Pale Moon) – the waiting period is a split-second
> - Chromium – split-second
> - Falkon – less than two seconds.
>
> Any ideas?
>
>
Start thunderbird from a terminal so you can see an messages.  Sounds like
a tcp or dns timeout, so perhaps some addon.

-- 
Adam
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Graham Perrin]

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
- Chromium – split-second
- Falkon – less than two seconds.

Any ideas?

 shows the waiting period with 
Konsole as the starting point, Firefox as the default web browser.


I can't say exactly when the problem began, but it was long before 
Firefox 66.




$ date ; uname -v
Sun 24 Mar 2019 16:23:22 GMT
FreeBSD 13.0-CURRENT r345330 GENERIC-NODEBUG
$ pkg query '%o %v %R' firefox seamonkey waterfox
www/firefox 66.0_3,1 poudriere
www/seamonkey 2.49.4_24 FreeBSD
www/waterfox 56.2.7.2 poudriere
$
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: network performance over 1GBps links degraded

[Gary Jennejohn]

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 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 has dropped to only about
> > > 12MBps.  I'm used to seeing about 27MBps during the ftp
> > > transfers.
> > 
> > Do you see "re0: watchdog timeout" errors?
> > 
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724
> >   
> 
> Thanks, but I just copied some 30GB between the FreeBSD and Windows
> 10 computer and didn't see a single error message.
> 
> I tried r330300, but the behavior didn't change.  Maybe I should go even
> further back in time.
> 
> One possibilty is the new BIOS I installed on my Ryzen (FreeBSD) box.
> I checked that the settings are all optimized, but who knows what Asus
> changed?
> 

So, Stefan Esser (se@) hit me with a clue bat and asked what
ifconfig shows for the speed.

Well, it's 100baseTX.  Not too surprising that it maxes out at
12MBps.

Up until recently the speed was always automatically set to
1000baseTX.  AFAIK nothing has changed in regards to the hardware
(contollers, switches, etc.).

Anyway, I'll try setting mediaopts in rc.conf and see what happens.

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: network performance over 1GBps links degraded

[Gary Jennejohn]

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 know what the hardware is.
> > 
> > I noticed that the transfer speed has dropped to only about
> > 12MBps.  I'm used to seeing about 27MBps during the ftp
> > transfers.  
> 
> Do you see "re0: watchdog timeout" errors?
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724
> 

Thanks, but I just copied some 30GB between the FreeBSD and Windows
10 computer and didn't see a single error message.

I tried r330300, but the behavior didn't change.  Maybe I should go even
further back in time.

One possibilty is the new BIOS I installed on my Ryzen (FreeBSD) box.
I checked that the settings are all optimized, but who knows what Asus
changed?

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: network performance over 1GBps links degraded

[Alex Dupre]

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 has dropped to only about
> 12MBps.  I'm used to seeing about 27MBps during the ftp
> transfers.

Do you see "re0: watchdog timeout" errors?

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=166724

-- 
Alex Dupre
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

network performance over 1GBps links degraded

[Gary Jennejohn]

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 re0 supports.

I tend to copy files from one to the other using ftp fairly
frequently.

I noticed that the transfer speed has dropped to only about
12MBps.  I'm used to seeing about 27MBps during the ftp
transfers.

I also observed the drop in transfer speed between FreeBSD and
a Windows 10 computer.  Formerly, I was seeing about 30MBps.
Windows 10 also has MTU 4088 set.

I tested with a FreeBSD kernel from March 7 and one from March
17, but both show the miserable performance.  Unfortunately, I
don't have any older kernels backed up.

I can't say exactly when the performance degraded, but possibly
there was some change to the kernel on or before March 7 which
caused it.

Has anyone else seen this?

There were several changes to the networking stack lately.

I wonder whether anyone has an idea what could be the cause of the
performance degredation, and what sysctls I could set to get the
old performance back.

-- 
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Ian Lepore]

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
> > flag for dump).
> 
> As an aside, mine has been pretty positive, except for once having
> / moved entirely to /lost+found and encoded as inode numbers.  That
> might be enough for some.
> 
> > If you can take that system down, I suggest:
> > 
> > * Reboot to single-user mode.
> > 
> > * Disable SU journaling ("tunefs -j disable $special")
> > 
> > * fsck -p / (at least; possibly elide the "-p")
> > 
> > * If you want SU+J, re-enable it ("tunefs -j enable $special")
> > 
> > * While theory says "exit" at this point should just continue the
> >   transition to multi-user mode, I'd be inclined to just reboot & watch it
> >   to make sure nothing "weird" happens that you don't know about.
> > 
> > * Re-test.
> 
> 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 that clearly (quite difficult because two things are
> the same thing, although they're apparently not)?
> 
> Seems that for some reason, some but not all actions involving the
> transition between . and .. on the mount point use either the
> permissions of the mount point or the permissions of the directory
> mounted on that mount point.  In the past, the permissions in the
> mounted filesystem have always trumped the mount point, but I have
> no idea what the spec says.  Is this a bug?
> 
> Ian
> 

I suspect that a combination of symlinks (which often use multiple
levels of ../ to traverse filesystems) and this caveat from the mount(8)
manpage explain what you see...

CAVEATS
 After a successful mount, the permissions on the original mount point
 determine if .. is accessible from the mounted file system. The minimum
 permissions for the mount point for traversal across the mount point in
 both directions to be possible for all users is 0111 (execute for all).

It makes a kind of sense when you think about it.  To access ../ from
the root of a mounted filesystem you have to read the underlying mount
point directory to see what its parent is, and that requires access to
that directory.

-- Ian


___
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"

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

[Ian FREISLICH]

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
> > the same thing, although they're apparently not)?
> 
> Your explanation makes sense to me.  The cause of this, however is
> unclear - was this something done locally?  This is why I asked about
> the permissions of '/lib', but based on what you've explained, even
> asking for the permissions of '/usr' would not have led to a clear
> answer.

I think the cause was when I moved to an SSD in this laptop and
created the filesystems on the new disk by hand.

> So we're clear, '/usr' (unmounted) is 700, but '/usr' (mounted) is 755?
> Or is this not the case?

This is exactly the case.  What's confusing is the inconsistent use
of the '/usr' (unmounted) and '/usr' (mounted) modes depending on
circumstance.  ie, non-root can cd and ls to '/usr' (mounted), but
not '/usr' (unmounted), but can't resolve a relative symlink in
that path.

Ian

-- 
Ian Freislich
___
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"

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

[Matthew Seaman]

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
>> bit me in the distant past.
> 
> I concur. I always make mount point directories 0111,noschg,nodump - it makes
> them stand out when not mounted, and also stops accidental directory deletion
> potentially stopping a reboot from working.
> 
> But yeah, for 20+ years. I've also experienced problems if a mount-point
> directory doesn't have +x access.

A long time ago -- before the millenium -- NeXT machines did away with
the need for a mount-point directory to exist.  So, if you wanted to
mount /foo/bar, only the /foo directory needed to exist prior to the
mount.  Since NeXT was subsumed by Apple, and NeXTStep reborn as MacOSX,
the same is presumably true today all Macs.  (Although I haven't tested
this personally.)

I do wonder why the rest of the world didn't do likewise.  It would make
this sort of problem a non-event.

Cheers,

Matthew





signature.asc
Description: OpenPGP digital signature

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

[Jamie Landeg-Jones]

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 mount point directories 0111,noschg,nodump - it makes
them stand out when not mounted, and also stops accidental directory deletion
potentially stopping a reboot from working.

But yeah, for 20+ years. I've also experienced problems if a mount-point
directory doesn't have +x access.

Cheers, Jamie
___
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"

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

[Gary Palmer]

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 that clearly (quite difficult because two things are
> the same thing, although they're apparently not)?
> 
> Seems that for some reason, some but not all actions involving the
> transition between . and .. on the mount point use either the
> permissions of the mount point or the permissions of the directory
> mounted on that mount point.  In the past, the permissions in the
> mounted filesystem have always trumped the mount point, but I have
> no idea what the spec says.  Is this a bug?

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.

Regards,

Gary
___
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"

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

[Glen Barber]

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 they're apparently not)?
> 

Your explanation makes sense to me.  The cause of this, however is
unclear - was this something done locally?  This is why I asked about
the permissions of '/lib', but based on what you've explained, even
asking for the permissions of '/usr' would not have led to a clear
answer.

So we're clear, '/usr' (unmounted) is 700, but '/usr' (mounted) is 755?
Or is this not the case?

Glen



pgpiIBFxPtvK1.pgp
Description: PGP signature

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

[Ian FREISLICH]

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, except for once having
/ moved entirely to /lost+found and encoded as inode numbers.  That
might be enough for some.

> If you can take that system down, I suggest:
> 
> * Reboot to single-user mode.
> 
> * Disable SU journaling ("tunefs -j disable $special")
> 
> * fsck -p / (at least; possibly elide the "-p")
> 
> * If you want SU+J, re-enable it ("tunefs -j enable $special")
> 
> * While theory says "exit" at this point should just continue the
>   transition to multi-user mode, I'd be inclined to just reboot & watch it
>   to make sure nothing "weird" happens that you don't know about.
> 
> * Re-test.

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 that clearly (quite difficult because two things are
the same thing, although they're apparently not)?

Seems that for some reason, some but not all actions involving the
transition between . and .. on the mount point use either the
permissions of the mount point or the permissions of the directory
mounted on that mount point.  In the past, the permissions in the
mounted filesystem have always trumped the mount point, but I have
no idea what the spec says.  Is this a bug?

Ian

-- 
Ian Freislich
___
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"

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

[Ian FREISLICH]

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
> > > libgcc_s.so: broken symbolic link to ../../lib/libgcc_s.so.1
> > >=20
> > > As root:
> > > [zen] /usr/lib # file libgcc_s.so=20
> > > libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1
> > >=20
> > > Only on one of my machines, all running CURRENT from within a day.
> > > The upshot is that I have to be root in order to link code.
> > >=20
> > > Any ideas greatly appreciated.
> > >=20
> >=20
> > What are the permissions on /lib/libgcc_s.so.1 ?
> >=20
> 
> Probably a better question:  What are the permissions on /lib ?

Answering both:

[zen] /usr/lib # ls -ld /lib
drwxr-xr-x  3 root  wheel  1536 Jul 28 19:07 /lib
[zen] /usr/lib # ls -l /lib/libgcc_s.so.1
-r--r--r--  1 root  wheel  57792 Jul 28 19:07 /lib/libgcc_s.so.1

Ian
-- 
Ian Freislich
___
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"

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

[Glen Barber]

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 ../../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 running CURRENT from within a day.
> > The upshot is that I have to be root in order to link code.
> > 
> > Any ideas greatly appreciated.
> > 
> 
> What are the permissions on /lib/libgcc_s.so.1 ?
> 

Probably a better question:  What are the permissions on /lib ?

Glen



pgpSXc3KQXxR0.pgp
Description: PGP signature

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

[Glen Barber]

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 
> libgcc_s.so: symbolic link to ../../lib/libgcc_s.so.1
> 
> Only on one of my machines, all running CURRENT from within a day.
> The upshot is that I have to be root in order to link code.
> 
> Any ideas greatly appreciated.
> 

What are the permissions on /lib/libgcc_s.so.1 ?

Glen



pgpGfBlmv_TIa.pgp
Description: PGP signature

"broken" symbolic links in /usr/lib

[Ian FREISLICH]

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 running CURRENT from within a day.
The upshot is that I have to be root in order to link code.

Any ideas greatly appreciated.

Ian

-- 
Ian Freislich
___
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"

Re: systat -ifstat on high-speed links

[Slawa Olhovchenkov]

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://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: systat -ifstat on high-speed links

[Ryan Stone]

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

[Slawa Olhovchenkov]

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 any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: installworld failure due to cross-device links

[Kevin Oberman]

On Fri, Jan 11, 2013 at 6:18 AM, Matt Burke  wrote:
> On 01/02/13 13:26, Nathan Whitehorn wrote:
>> Thanks for the patch! I've committed it (slightly modified) as r244958.
>> I haven't taken any action on the chgrp/chown issue, though.
>
> Similarly, 'make distribution' fails when /root is a separate filesystem:
>
> cd /usr/src/etc/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?

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 are
unaffected. When the last hard link is deleted, so is the file.

Symlinks, on the other hand are simply pointer to a real file and if
the file is deleted, the symlink remains, but is broken. Of course,
symlinks can cross file systems when hard links can't.

Both are likely to remain useful and neither is appropriate for all
applications.
-- 
R. Kevin Oberman, Network Engineer
E-mail: kob6...@gmail.com
___
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"

Re: installworld failure due to cross-device links

[Matt Burke]

On 01/02/13 13:26, Nathan Whitehorn wrote:
> Thanks for the patch! I've committed it (slightly modified) as r244958.
> I haven't taken any action on the chgrp/chown issue, though.

Similarly, 'make distribution' fails when /root is a separate filesystem:

cd /usr/src/etc/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 for the following...


The information contained in this message is confidential and intended for the 
addressee only. If you have received this message in error, or there are any 
problems with its content, please contact the sender. 

iCritical is a trading name of Critical Software Ltd. Registered in England: 
04909220.
Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH.

This message has been scanned for security threats by iCritical. 
www.icritical.com

___
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"

Re: installworld failure due to cross-device links

[Stefan Esser]

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 system directories in /usr
>> (e.g. /usr/bin, /usr/sbin, /usr/libexec) are on the same file
>> system, but I do not think that this assumption is documented.
>>
>> I'm using a ZFS only installation of -CURRENT and have separate file
>> systems for several of the directories in / and /usr, that usually
>> share a file system (e.g. /bin, /sbin, but also /usr/bin/, /usr/sbin
>> and /usr/libexec are independent file systems).
>>
>> An older case is the link from /usr/bin/chgrp to /usr/sbin/chown
>> (see usr.sbin/chown/Makefile), which is easily fixed by using a
>> SMYLINK instead of a LINK.
>>
>> And now there is usr.sbin/bsdinstall/partedit/Makefile, which as of
>> r244859 creates a link from /usr/libexec/bsdinstall to /usr/sbin/sade.
>>
>> This breaks with /usr/bin and /usr/sbin on different file systems,
>> while it should not according to the commit message:
>>
> 
> Thanks for the patch! I've committed it (slightly modified) as r244958.
> I haven't taken any action on the chgrp/chown issue, though.

Thanks for the fix. Seems I had a wrong idea of the semantics of the
(SYM)LINKS macro, as I had assumed that the build target would be
linked to the list of names (instead of pairs of source/dest).

I did not expect you to do anything with chown/chgrp, but I still
think there should be a policy on whether hard links may be used to
connect files in different directories (which might be in different
file systems).

Regards, STefan
___
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"

Re: installworld failure due to cross-device links

[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 system directories in /usr
> (e.g. /usr/bin, /usr/sbin, /usr/libexec) are on the same file
> system, but I do not think that this assumption is documented.
>
> I'm using a ZFS only installation of -CURRENT and have separate file
> systems for several of the directories in / and /usr, that usually
> share a file system (e.g. /bin, /sbin, but also /usr/bin/, /usr/sbin
> and /usr/libexec are independent file systems).
>
> An older case is the link from /usr/bin/chgrp to /usr/sbin/chown
> (see usr.sbin/chown/Makefile), which is easily fixed by using a
> SMYLINK instead of a LINK.
>
> And now there is usr.sbin/bsdinstall/partedit/Makefile, which as of
> r244859 creates a link from /usr/libexec/bsdinstall to /usr/sbin/sade.
>
> This breaks with /usr/bin and /usr/sbin on different file systems,
> while it should not according to the commit message:
>

Thanks for the patch! I've committed it (slightly modified) as r244958.
I haven't taken any action on the chgrp/chown issue, though.
-Nathan
___
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"

installworld failure due to cross-device links

[Stefan Esser]

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 this assumption is documented.

I'm using a ZFS only installation of -CURRENT and have separate file
systems for several of the directories in / and /usr, that usually
share a file system (e.g. /bin, /sbin, but also /usr/bin/, /usr/sbin
and /usr/libexec are independent file systems).

An older case is the link from /usr/bin/chgrp to /usr/sbin/chown
(see usr.sbin/chown/Makefile), which is easily fixed by using a
SMYLINK instead of a LINK.

And now there is usr.sbin/bsdinstall/partedit/Makefile, which as of
r244859 creates a link from /usr/libexec/bsdinstall to /usr/sbin/sade.

This breaks with /usr/bin and /usr/sbin on different file systems,
while it should not according to the commit message:

--
r244859 | nwhitehorn | 2012-12-30 15:35:00 +0100 (Sun, 30 Dec 2012) | 7
lines

Replace sade the extracted piece of sysinstall with sade the extracted
piece of bsdinstall (although this time with a symlink instead of
duplicated source code).

Discussed on:   freebsd-geom
MFC after:  3 months
--

The SYMLINK mentioned in the commit message is a LINK to a different
directory, which might be on a different file system, actually.

This should be fixed by the attached patch, to remove the implied
assumption and to make the Makefile match the commit message.

Regards, STefan
Index: Makefile
===
--- Makefile(revision 244957)
+++ Makefile(working copy)
@@ -2,7 +2,8 @@
 
 BINDIR= /usr/libexec/bsdinstall
 PROG=  partedit
-LINKS= ${BINDIR}/partedit ${BINDIR}/autopart ${BINDIR}/partedit /usr/sbin/sade
+LINKS= ${BINDIR}/partedit ${BINDIR}/autopart ${BINDIR}/partedit
+SYMLINKS= /usr/sbin/sade
 LDADD= -lgeom -lncursesw -lutil -ldialog -lm
 
 PARTEDIT_ARCH= ${MACHINE}
___
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"

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

[Ilya Bakulin]

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 fine.
>
It helped!
Thank you very much!
--
Regards,
Ilya Bakulin
http://kibab.com
xmpp://kibab...@jabber.ru

___
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"

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

[Jeremie Le Hen]

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 resides ($PROJROOT):
> /home/kibab/repos/freebsd-cap-git
> 2. FreeBSD-CURRENT sources are in $PROJROOT/freebsd
> 3. Object directory is $PROJROOT/obj
> 4. Installation directory is $PROJROOT/inst
> 
> 5. Building world: while in $PROJROOT/freebsd, I type:
>   make __MAKE_CONF=$PROJROOT/make.conf SRCCONF=$PROJROOT/src.conf -j16
> buildworld
> ...After a while, build ends...
> 6. while in $PROJROOT/freebsd, type `sudo make buildenv`, after entering
> build environment I set nessesary env variables:
> PROJROOT=/home/kibab/repos/freebsd-cap-git
> MAKEOBJDIRPREFIX=/home/kibab/repos/freebsd-cap-git/obj
> DISTDIR=/home/kibab/repos/freebsd-cap-git/inst
> DESTDIR=/home/kibab/repos/freebsd-cap-git/inst
> 
> 7. After that, type:
> make __MAKE_CONF=$PROJROOT/make.conf SRCCONF=$PROJROOT/src.conf -j16
> installworld

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 fine.

-- 
Jeremie Le Hen

Men are born free and equal.  Later on, they're on their own.
Jean Yanne
___
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"

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

[Ilya Bakulin]

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 in $PROJROOT/freebsd
3. Object directory is $PROJROOT/obj
4. Installation directory is $PROJROOT/inst

5. Building world: while in $PROJROOT/freebsd, I type:
  make __MAKE_CONF=$PROJROOT/make.conf SRCCONF=$PROJROOT/src.conf -j16
buildworld
...After a while, build ends...
6. while in $PROJROOT/freebsd, type `sudo make buildenv`, after entering
build environment I set nessesary env variables:
PROJROOT=/home/kibab/repos/freebsd-cap-git
MAKEOBJDIRPREFIX=/home/kibab/repos/freebsd-cap-git/obj
DISTDIR=/home/kibab/repos/freebsd-cap-git/inst
DESTDIR=/home/kibab/repos/freebsd-cap-git/inst

7. After that, type:
make __MAKE_CONF=$PROJROOT/make.conf SRCCONF=$PROJROOT/src.conf -j16
installworld

Now I can chroot to newly installed system. FreeBSD 8.2 still allows
running 10-CURRENT binaries, so that's not a problem:
kibab@ssh%pwd
/home/kibab/repos/freebsd-cap-git/inst

kibab@ssh%sudo chroot `pwd` /bin/csh

# ls -l /usr/lib | grep libgcc_s
lrwxr-xr-x  1 0  0   71 May 20 17:31 libgcc_s.so ->
/usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib/libgcc_s.so.1

So the path to shared library is invalid!

This setup was functional for about a year, and it was broken by recent
update. I tried with clean object directory as well, this doesn't change
anything.

-- 
Regards,
Ilya Bakulin
http://kibab.com
xmpp://kibab...@jabber.ru

___
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"

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

[Jeremie Le Hen]

Hi,

On Sun, May 20, 2012 at 07:54:22PM +0200, Ilya Bakulin wrote:
> Hi all,
> I have compiled FreeBSD-CURRENT amd64 (fresh checkout from today, git
> revision 46b12ff6d8ab4f736d155646ae32133083e1da05 -- from official
> FreeBSD github mirror) and installed it in custom location (DESTDIR=
> make installworld).
> 
> After chrooting to installed system and trying to compile any program I
> get the message:
> 
> # gcc -o hello hello.c
> /usr/bin/ld: cannot find -lgcc_s
> 
> Here is an output of 'ls -l' after chrooting to installed system:
> 
> total 89076
> -rwxr-xr-x 1 0 0 3352 19 ?? 21:27 Scrt1.o
> drwxr-xr-x 2 0 0 512 20 ?? 08:39 aout
> drwxr-xr-x 3 0 0 512 20 ?? 08:39 compat
> -rwxr-xr-x 1 0 0 3296 19 ?? 21:27 crt1.o
> -rwxr-xr-x 1 0 0 2408 19 ?? 21:27 crtbegin.o
> ...
> -rwxr-xr-x 1 0 0 56354 20 ?? 09:31 libalias.a
> lrwxr-xr-x 1 0 0 71 20 ?? 09:54 libalias.so ->
> /usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib/libalias.so.7
> -rwxr-xr-x 1 0 0 3200 20 ?? 09:31 libalias_cuseeme.a
> ...
> -rwxr-xr-x 1 0 0 17108 20 ?? 09:31 libbegemot.a
> 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
> 
> 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/freebsd, object directory is
> /home/kibab/repos/freebsd-cap-git/freebsd/obj, installation directory is
> /home/kibab/repos/freebsd-cap-git/freebsd/inst.
> As I understand, this problem will arise only if using non-standard
> object directory (not under /usr/obj), because symbolic links will
> otherwise point to some files under /usr/obj and required files will be
> actually there. This is still incorrect, but at least would seem to work...
> 
> I'm using custom src.conf with these options:
> WITHOUT_CLANG=yes
> WITHOUT_GAMES=yes
> WITHOUT_KERNEL_SYMBOLS=yes
> WITHOUT_EXAMPLES=yes
> WITHOUT_HTML=yes
> WITHOUT_NCP=yes
> WITHOUT_PROFILE=yes
> WITHOUT_SENDMAIL=yes
> WITHOUT_SYSINSTALL=yes
> WITHOUT_VINUM=yes
> WITHOUT_LIB32=yes
> 
> I tried a fresh build with clean object directory.
> Could anyone tell what may have gone wrong?

Can you provide the exact commands you have used to create your chroot?
 
-- 
Jeremie Le Hen

Men are born free and equal.  Later on, they're on their own.
Jean Yanne
___
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"

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

[Ilya Bakulin]

Hi all,
I have compiled FreeBSD-CURRENT amd64 (fresh checkout from today, git
revision 46b12ff6d8ab4f736d155646ae32133083e1da05 -- from official
FreeBSD github mirror) and installed it in custom location (DESTDIR=
make installworld).

After chrooting to installed system and trying to compile any program I
get the message:

# gcc -o hello hello.c
/usr/bin/ld: cannot find -lgcc_s

Here is an output of 'ls -l' after chrooting to installed system:

total 89076
-rwxr-xr-x 1 0 0 3352 19 май 21:27 Scrt1.o
drwxr-xr-x 2 0 0 512 20 май 08:39 aout
drwxr-xr-x 3 0 0 512 20 май 08:39 compat
-rwxr-xr-x 1 0 0 3296 19 май 21:27 crt1.o
-rwxr-xr-x 1 0 0 2408 19 май 21:27 crtbegin.o
...
-rwxr-xr-x 1 0 0 56354 20 май 09:31 libalias.a
lrwxr-xr-x 1 0 0 71 20 май 09:54 libalias.so ->
/usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib/libalias.so.7
-rwxr-xr-x 1 0 0 3200 20 май 09:31 libalias_cuseeme.a
...
-rwxr-xr-x 1 0 0 17108 20 май 09:31 libbegemot.a
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

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/freebsd, object directory is
/home/kibab/repos/freebsd-cap-git/freebsd/obj, installation directory is
/home/kibab/repos/freebsd-cap-git/freebsd/inst.
As I understand, this problem will arise only if using non-standard
object directory (not under /usr/obj), because symbolic links will
otherwise point to some files under /usr/obj and required files will be
actually there. This is still incorrect, but at least would seem to work...

I'm using custom src.conf with these options:
WITHOUT_CLANG=yes
WITHOUT_GAMES=yes
WITHOUT_KERNEL_SYMBOLS=yes
WITHOUT_EXAMPLES=yes
WITHOUT_HTML=yes
WITHOUT_NCP=yes
WITHOUT_PROFILE=yes
WITHOUT_SENDMAIL=yes
WITHOUT_SYSINSTALL=yes
WITHOUT_VINUM=yes
WITHOUT_LIB32=yes

I tried a fresh build with clean object directory.
Could anyone tell what may have gone wrong?

-- 
Regards,
Ilya Bakulin
http://kibab.com
xmpp://kibab...@jabber.ru




signature.asc
Description: OpenPGP digital signature

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

[Maxim Sobolev]

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 thread to do it's magic in
the background. I hope to follow up with the patch soon.


Here is a proof of concept path, which simply fails any 
non-synchronization requests in the send thread when in the async mode. 
This is non-optimal, as it would cause additional latency in the write 
path when the send thread is busy with synchronization requests. But it 
works for me, making it possible to use my virtual machine while 
synchronizing the disk image.


http://sobomax.sippysoft.com/primary.c.diff

-Maxim
___
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"

Re: devfs rules and symbolik links

[Poul-Henning Kamp]

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 unhide those. Any ideas!?
>
>Please try the attached patch, which should be able to match symlinks
>based on pathname in order to unhide them.  This is only lightly
>tested, and I'm not entirely sure why I didn't do this before (ISTR
>having trouble getting it to work, but this seems absurdly logical and
>simple), but it seems to work.
>
>phk, does this look okay to you?

If it works I'm ok with it.

>Dima.
>
>Index: devfs_rule.c
>===
>RCS file: /a/ncvs/src/sys/fs/devfs/devfs_rule.c,v
>retrieving revision 1.3
>diff -u -r1.3 devfs_rule.c
>--- devfs_rule.c   8 Oct 2002 04:21:54 -   1.3
>+++ devfs_rule.c   2 Dec 2002 21:20:04 -
>@@ -634,7 +634,8 @@
>   dev = devfs_rule_getdev(de);
>   if (dev != NULL)
>   pname = dev->si_name;
>-  /* XXX: Support symlinks (check d_type == DT_LNK here). */
>+  else if (de->de_dirent->d_type == DT_LNK)
>+  pname = de->de_dirent->d_name;
>   else
>   return (0);
>   KASSERT(pname != NULL, ("devfs_rule_matchpath: NULL pname"));
>

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: devfs rules and symbolik links

[Dima Dorfman]

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 should be able to match symlinks
based on pathname in order to unhide them.  This is only lightly
tested, and I'm not entirely sure why I didn't do this before (ISTR
having trouble getting it to work, but this seems absurdly logical and
simple), but it seems to work.

phk, does this look okay to you?

Dima.

Index: devfs_rule.c
===
RCS file: /a/ncvs/src/sys/fs/devfs/devfs_rule.c,v
retrieving revision 1.3
diff -u -r1.3 devfs_rule.c
--- devfs_rule.c8 Oct 2002 04:21:54 -   1.3
+++ devfs_rule.c2 Dec 2002 21:20:04 -
@@ -634,7 +634,8 @@
dev = devfs_rule_getdev(de);
if (dev != NULL)
pname = dev->si_name;
-   /* XXX: Support symlinks (check d_type == DT_LNK here). */
+   else if (de->de_dirent->d_type == DT_LNK)
+   pname = de->de_dirent->d_name;
else
return (0);
KASSERT(pname != NULL, ("devfs_rule_matchpath: NULL pname"));

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

devfs rules and symbolik links

[Taavi Talvik]

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" existance.

# start up jail
D=/home/taavi/work/jail
umount -f $D/dev

devfs rule -s 10 delset
devfs rule -s 10 add 100 hide
devfs rule -s 10 add 200 path ptyp* unhide
devfs rule -s 10 add 300 path ttyp* unhide
devfs rule -s 10 add 400 path null unhide
devfs rule -s 10 add 500 path zero unhide
devfs rule -s 10 add 600 path random unhide
devfs rule -s 10 add 610 path urandom unhide
devfs rule -s 10 add 700 path fd unhide
devfs rule -s 10 add 800 path fd/* unhide
devfs rule -s 10 add 900 path stdin unhide
devfs rule -s 10 add 910 path stdout unhide
devfs rule -s 10 add 920 path stderr unhide
mount -t devfs dev $D/dev
devfs -m $D/dev ruleset 10
mount -t procfs proc $D/proc
ifconfig fxp0 inet alias 1.2.3.4/32

jail $D tt-test 1.2.3.4 /bin/csh

umount -f $D/proc
umount -f $D/dev


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message