[Bug 191151] New: Relative module path in PAM service description file does not work well
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191151 Bug ID: 191151 Summary: Relative module path in PAM service description file does not work well Product: Base System Version: 10.0-RELEASE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: re...@tekkirk.org PAM.CONF(5) claims: The module-path field specifies the name or full path of the module to call. If only the name is specified, the PAM library will search for it in the following locations: 1. /usr/lib 2. /usr/local/lib When I use authrequiredpam_ldap.so.1no_warn try_first_pass instead of authrequired/usr/local/lib/pam_ldap.so.1no_warn try_first_pass I get following errors when system starts. Jun 18 10:24:17 lien login: in openpam_load_module(): no pam_ldap.so.1 found Jun 18 10:24:17 lien login: pam_start(): system error Jun 18 10:24:17 lien login: in openpam_load_module(): no pam_ldap.so.1 found Jun 18 10:24:17 lien login: pam_start(): system error Jun 18 10:24:17 lien login: in openpam_load_module(): no pam_ldap.so.1 found Jun 18 10:24:17 lien login: pam_start(): system error Jun 18 10:24:17 lien login: in openpam_load_module(): no pam_ldap.so.1 found Jun 18 10:24:17 lien login: pam_start(): system error Jun 18 10:24:17 lien init: getty repeating too quickly on port /dev/ttyv1, sleeping 30 secs This issue disallows me to log into as root. getent proved that LDAP itself works fine. /etc/nsswitch.conf: mrehak@lien:~$ cat /etc/nsswitch.conf group: files ldap hosts: files dns networks: files passwd: files ldap shells: files services: files protocols: files rpc: files I did freebsd-update fetch and install on June 4 and forgot to restart. Today I have found the machine in this state after reboot. As there was a PAM related change in 10.0-RELEASE-p4 I would guess there is the cause. In the evening I will confirm that the issue is really there. I will try the same on the second machine. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 189053] [patch] Add -b flag to lpd(8)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189053 a...@ayan.net changed: What|Removed |Added Severity|Affects Only Me |Affects Many People -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 189053] [patch] Add -b flag to lpd(8) - Currently, lpd listens on all interfaces
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189053 a...@ayan.net changed: What|Removed |Added Summary|[patch] Add -b flag to |[patch] Add -b flag to |lpd(8) |lpd(8) - Currently, lpd ||listens on all interfaces -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 125613] [ufs] [patch] ACL problems with special files
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=125613 Edward Tomasz Napierala changed: What|Removed |Added Assignee|tr...@freebsd.org |freebsd-bugs@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 139718] [reboot] all mounted fs don't get synced during reboot/shutdown with >= 1 mounted inaccessible device
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=139718 Edward Tomasz Napierala changed: What|Removed |Added Assignee|tr...@freebsd.org |freebsd-bugs@FreeBSD.org --- Comment #11 from Edward Tomasz Napierala --- Reset the owner; I'm not working on this in any way. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 155163] [patch] Add Recursive Functionality to setfacl(1)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=155163 Edward Tomasz Napierala changed: What|Removed |Added Assignee|tr...@freebsd.org |freebsd-bugs@FreeBSD.org --- Comment #3 from Edward Tomasz Napierala --- Disown. I don't even remember how that code works anymore. One potential problem with this code that it used fts to build a list of all paths in the tree, instead of using fts to iterate over the tree, and that could fail due to out of memory condition. That said, it doesn't look critical, and that's also how setfacl works right now. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 191155] New: Fix USB operation after second suspend/resume
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191155 Bug ID: 191155 Summary: Fix USB operation after second suspend/resume Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: tr...@freebsd.org Attached patch fixes a problem where USB would no longer work after second suspend/resume cycle, which happens on several ThinkPad models. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 191155] Fix USB operation after second suspend/resume
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191155 --- Comment #1 from Edward Tomasz Napierala --- Created attachment 143900 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=143900&action=edit fix -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 191158] New: dialog4ports only shows empty terminal for most ports
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191158 Bug ID: 191158 Summary: dialog4ports only shows empty terminal for most ports Product: Base System Version: 10.0-STABLE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Only Me Priority: Normal Component: misc Assignee: freebsd-bugs@FreeBSD.org Reporter: t...@vr-web.de dialog4ports only displays an empty terminal window for various ports: cd /usr/ports/lang/clang33 make config -> empty xterm or console. Environment: FreeBSD fbsd10-64.bfs.de 10.0-STABLE FreeBSD 10.0-STABLE #26 r266805: Wed May 28 20:40:18 CEST 2014 r...@fbsd10-64.bfs.de:/usr/obj/usr/src/sys/FBSD10-64 amd64 How-To-Repeat: cd /usr/ports/lang/clang33 make config -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 191158] dialog4ports only shows empty terminal for most ports
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191158 Arnaud Bergeron changed: What|Removed |Added CC||aberge...@gmail.com --- Comment #1 from Arnaud Bergeron --- I am encountering the exact same problem (with the devel/nasm port and several others, in fact I can't find a port where dialog4ports is working). I am having this problem through an SSH connection from Terminal on OS X as well as the native console. I should note that if you press the arrow down key you see the message: ===> Options unchanged and dialog4ports exits. Here are the steps I've tried to resolve the problem: - Change TERM to: xterm, cons25, xterm-color, vt220, vt100 xterm-256color, xterm-old - Rebuild dialog4ports from the newest sources available. Also, I remember this working on 10.0-RELEASE. I personally encountered the problem with 10.0-p5. I can't say if any of the intervening patch releases have the same problem. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 191163] New: svnlite name in help text inconsistent
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191163 Bug ID: 191163 Summary: svnlite name in help text inconsistent Product: Base System Version: 10.0-STABLE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: wbl...@freebsd.org svnlite refers to itself as "svn" in help messages: % svnlite Type 'svn help' for usage. This is contradictory and of course does not work for users without the Subversion port installed. And could be a problem if the port is installed, if 'svn help' shows features that do not exist in svnlite. svnlite should be consistent, being built with static "svn" strings replaced with "svnlite". (grep -r \'svn contrib/subversion/subversion/*) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 191173] New: Poor file write performance on xen blockfront
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191173 Bug ID: 191173 Summary: Poor file write performance on xen blockfront Product: Base System Version: 10.0-RELEASE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: nets...@gmail.com This bug report merely confirms the thorough benchmark done by Sydney Meyer summarized in his conversation with Roger Pau Monne here: http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-January/001951.html In my case the dom0 is NetBSD 6.1.4 with Xen 4.2. I noticed a few things that seems to be consistent with Sydney's observations: - With FBSD 10, dd-ing from /dev/zero into a file is at least 50% slower than dd-ing into a disk. In my case dd to file was ~25MB/sec at best, while dd to disk was ~60MB/sec. - With NetBSD domU run under HVM, dd-ing into a file was ~58MB/sec, dd-ing unto a partition was ~35MB/sec. Under NetBSD domU PV, it was 125+MB/sec - In the NetBSD dom0, dd-ing into a file was ~100MB/sec. In all case, each of the domU disks were backed by an LVM logical volume. NetBSD has/had some issue with poor domU disk write performance and basically, AFAIU, it's due to improper reordering of write requests. This email contains a patch that solved the problem (for NetBSD domU only, obviously), but you can read the whole thread. The NetBSD domU kernel that I use has this patch. I'm not a kernel programmer, so most of this stuff goes beyond my head, however, maybe the FreeBSD blockfront is suffering the same issue? Building an FBSD 10 kernel without PVHVM may give more data points, especially if the disk performs faster with the standard ide/sata/scsi driver (as is also shown in Sydney's email with FBSD 9.2). I just don't have the time ATM. Btw, the quickest way to repro the problem is to just use the installation cd, as you can get into the shell and mess around. DETAILS: * How the domU disk was setup: # gpart create ada0 # # Now boot part is created at offset 128k with size 128k. I suppose you can # # skip this for testing purposes, but it's here for illustration. # # In my case it is important because the domO disk is a raidframe # # (software raid) raid5 with 32k blocks, so it's best to start partition # # at multiple of 32k to avoid excessive read-modify-write. # gpart add -b 128k -s 128k -t freebsd-boot ada0 # gpart bootcode -p /boot/gptboot -i 1 ada0 # # Below is creation of ada0p2 # gpart add -b 1M -s 2047M -t freebsd-ufs ada0 # newfs -b 32k /dev/ada0p2 * How the dd into file was done # mount /dev/ada0p2 /mnt # cd /mnt # # Now write 1GB # dd if=/dev/zero of=big.img bs=32k count=$((1024*32)) * How the dd into disk was done # # Btw, I have a second disk /dev/ada1. I haven't tried this, but creating # # another partition might show the performance difference as well. # dd if=/dev/zero of=/dev/ada1 bs=32k count=$((1024*32)) Toby -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 190472] FreeBSD 10 native iscsi - UNIT_ATTENTION
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190472 Edward Tomasz Napierala changed: What|Removed |Added CC||tr...@freebsd.org Assignee|freebsd-bugs@FreeBSD.org|tr...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 161481] [libc] mount(2) fails with ENAMETOOLONG with path shorter than 255 // 1023 characters
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=161481
Nick Hibma changed:
What|Removed |Added
CC||n_hi...@freebsd.org
--- Comment #3 from Nick Hibma ---
In our NanoBSD builds we use nullfs to provide a dir with packages to install.
I changed the MAKEOBJDIR to include the full path to working directory to
provide a means to separate multiple images and versions of images.
nullfs couldn't handle the length of that path. I am -very- surprised that
nullfs is not able to handle MAX_PATH length paths.
Our workaround is the use the MD5 of the full path instead of the path itself:
# XXX Take the MD5 of the path as mount_nullfs (for packages) does not handle
long paths. See
# FreeBSD PR kern/161481.
p="$(echo "$PWD" | sed -Ee 's#^/((usr)?/home|Users)/##' | md5)"
NANO_OBJ=${NANO_OBJ:-"/usr/obj/nanobsd/$p"}
I do understand that this is actually a rather complex little bug, as it goes
across a number of APIs.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
