[Bug 198648] resolvconf does not modify pdnsd.conf correctly
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198648
Bug ID: 198648
Summary: resolvconf does not modify pdnsd.conf correctly
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: conf
Assignee: freebsd-bugs@FreeBSD.org
Reporter: henry.hu...@gmail.com
Currently, when setting pdnsd_conf in resolvconf.conf, resolvconf does not
change pdnsd.conf correctly. The result looks like this:
...
# Generated by resolvconf
server {\n\tlabel=resolvconf;\n\tip=192.168.1.1;\n}\nserver
{\n\tinclude=.lan.;\n\tpolicy=excluded;\n\tip=192.168.1.1;\n}\n# End of
resolvconf
In other words, newline should be inserted, but \n was inserted instead.
pdnsd refuses to start with this configuration.
In /usr/src/contrib/openresolv/pdnsd.in, it uses
printf %s $newconf $cf
In the old versions of openresolv, %s was not present, and it works correctly.
In the latest version of openresolv (3.6.2), \n is not used, but $NL is used,
so it should also work. But current version in our repo was 3.4.4, which has
this problem.
Please import new version of openresolv to fix the 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 193740] [PATCH] fetch(3) HTTP netrc support
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193740 TEUBEL György tgyu...@gmail.com changed: What|Removed |Added Summary|fetch(3) HTTP netrc support |[PATCH] fetch(3) HTTP netrc ||support -- 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 198463] [mfi] COMMAND 0x... TIMEOUT AFTER ## SECONDS (LSI MegaRAID 9361-8i)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198463 --- Comment #2 from sird...@gmail.com --- Ah. That's definitely worth a try. In case it doesn't work or is still unstable, how do I turn off FreeBSD's mfi/mrsas driver so I can use the driver from LSI? -- 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 198463] [mfi] COMMAND 0x... TIMEOUT AFTER ## SECONDS (LSI MegaRAID 9361-8i)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198463 --- Comment #3 from sird...@gmail.com --- I still seem to get timeouts on FreeBSD 9.3-RELEASE with hw.mfi.mrsas_enable=1. How can I tell if the mrsas(4) driver is being loaded instead of the 'old' mfi(4) one? I understand how to build a custom kernel but I would prefer to use the stock GENERIC kernel so I can use freebsd-update(8) more easily. -- 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
RE: [Bug 198463] [mfi] COMMAND 0x... TIMEOUT AFTER ## SECONDS (LSI MegaRAID 9361-8i)
You have to comment the device mfi option in the /usr/src/sys/amd64/conf/GENERIC file. And also comment all the mfi relates object files in the following file: /usr/src/sys/conf/files After these modifications, just re-compile and install the new kernel and you are done. To use the mrsas.ko permanently you have to update the /boot/loader.conf file accordingly and put the mrsas.ko in the /boot/kernel/ directory. Thanks, Sibananda Sahu -Original Message- From: owner-freebsd-b...@freebsd.org [mailto:owner-freebsd-b...@freebsd.org] On Behalf Of bugzilla-nore...@freebsd.org Sent: Monday, March 16, 2015 3:02 PM To: freebsd-bugs@FreeBSD.org Subject: [Bug 198463] [mfi] COMMAND 0x... TIMEOUT AFTER ## SECONDS (LSI MegaRAID 9361-8i) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198463 --- Comment #2 from sird...@gmail.com --- Ah. That's definitely worth a try. In case it doesn't work or is still unstable, how do I turn off FreeBSD's mfi/mrsas driver so I can use the driver from LSI? -- 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 ___ 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
RE: [Bug 198463] [mfi] COMMAND 0x... TIMEOUT AFTER ## SECONDS (LSI MegaRAID 9361-8i)
-Original Message- From: owner-freebsd-b...@freebsd.org [mailto:owner-freebsd-b...@freebsd.org] On Behalf Of bugzilla-nore...@freebsd.org Sent: Monday, March 16, 2015 5:55 PM To: freebsd-bugs@FreeBSD.org Subject: [Bug 198463] [mfi] COMMAND 0x... TIMEOUT AFTER ## SECONDS (LSI MegaRAID 9361-8i) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198463 --- Comment #4 from sird...@gmail.com --- I had a conversation with Sibananda Sahu, I'm not sure if it made it to here. Quick recap: hw.mfi.mrsas_enable=1 only works on 10.1-RELEASE, it does nothing on 9.3-RELEASE. Siba: Yes true. To use mrsas(4) on 9.3 one must have to remove the mfi(4) completely from kernel and install the mrsas(4) separately. With hw.mfi.mrsas_enable=1 I was able to install 10.1-RELEASE without any timeouts or other errors. I'm currently running a bonnie++ test to see how stable things are but it's looking very good so far. The difference is easy to tell, with the mfi(4) driver a virtual disk shows up as mfid0, with the mrsas(4) driver it's detected as da0. Siba: Yes that is also true because mrsas(4) uses CAM layer and mfi(4) uses the block layer for the drive exposure. If time permits today I'll see if I can create a custom 9.3-RELEASE install with the mfi(4)/mrsas(4) driver removed, to test the driver from LSI (an mrsas driver can be downloaded for 7.4, 8.2, 8.3, 8.4, 9.0, 9.1, 9.2, 9.3 and 10.0). The driver from LSI should be newer than the one that came with FreeBSD. Siba: The driver available in the LSI website will have the most recent code changes than the FreeBSD-xx.x inbox code (May not true always but most of the times). As the downloaded package does not contain the binaries for 10.1, you can download the source code, compile and install yourself on your 10.1 machine to witness the truth. Thanks, Siba -- 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 ___ 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 198463] [mfi] COMMAND 0x... TIMEOUT AFTER ## SECONDS (LSI MegaRAID 9361-8i)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198463 --- Comment #4 from sird...@gmail.com --- I had a conversation with Sibananda Sahu, I'm not sure if it made it to here. Quick recap: hw.mfi.mrsas_enable=1 only works on 10.1-RELEASE, it does nothing on 9.3-RELEASE. With hw.mfi.mrsas_enable=1 I was able to install 10.1-RELEASE without any timeouts or other errors. I'm currently running a bonnie++ test to see how stable things are but it's looking very good so far. The difference is easy to tell, with the mfi(4) driver a virtual disk shows up as mfid0, with the mrsas(4) driver it's detected as da0. If time permits today I'll see if I can create a custom 9.3-RELEASE install with the mfi(4)/mrsas(4) driver removed, to test the driver from LSI (an mrsas driver can be downloaded for 7.4, 8.2, 8.3, 8.4, 9.0, 9.1, 9.2, 9.3 and 10.0). The driver from LSI should be newer than the one that came with FreeBSD. -- 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 198626] Mounted USB key with FAT32 file-system, inserted 2nd key, mounted file-system went blank
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198626 Bug ID: 198626 Summary: Mounted USB key with FAT32 file-system, inserted 2nd key, mounted file-system went blank Product: Base System Version: 10.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: donaldcal...@gmail.com I inserted a USB key with a FAT32 file-system on its one and only partition and mounted it on a newly created directory in /tmp. After mounting, I did an ls to verify that what I expected to be there was there, and it was. Among the contents was a .iso file that needed to be copied to another USB key. I inserted that key and began typing the dd command to do the copy, while cd-ed to the directory where I'd mounted the first key. When I hit 'tab' to complete the name of the .iso file, it would not complete. So I backed out, did another ls and got nothing! No files! But the file-system was still mounted, confirmed with df. I suspect that the insertion of the second USB key confused the system somehow and it lost track of the first. -- 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 198626] Mounted USB key with FAT32 file-system, inserted 2nd key, mounted file-system went blank
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198626 --- Comment #2 from donaldcal...@gmail.com --- The second key, the key to which I wanted to do the copy, was a Kingston DTSE9, 8GB. -- 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 198629] Segmentation fault in ssh connecting to host in /etc/hosts with missing /etc/resolv.conf on i386 arch
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198629 Bug ID: 198629 Summary: Segmentation fault in ssh connecting to host in /etc/hosts with missing /etc/resolv.conf on i386 arch Product: Base System Version: 10.1-RELEASE Hardware: i386 OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: w...@canodus.be Using ssh to connect to a host defined in /etc/hosts on a FreeBSD 10.1-RELEASE i386 machine with a missing /etc/resolv.conf file results in a segmentation fault. Simply creating (an empty) resolv.conf file fixes the problem. On a amd64 machine, ssh works as expected with or without the resolv.conf file. -- 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 198626] Mounted USB key with FAT32 file-system, inserted 2nd key, mounted file-system went blank
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198626 --- Comment #1 from donaldcal...@gmail.com --- I should mention that I did try to reproduce this and have not been successful thus far. The key in question is a Sandisk Cruzer Facet, 8GB -- 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
Schroedingers files. Both there and not there.
I’ve been having some issues over the past few months that I’m finally getting around to troubleshooting. I’m running FreeBSD 10.1-p5 with ZFS. My nightly emails have been giving me output like: Checking setuid files and devices: find: /usr/include/dev/an_bak/if_aironet_ieee.h: No such file or directory Checking negative group permissions: find: /usr/include/dev/an_bak/if_aironet_ieee.h: No such file or directory The reason for it being called an_bak is that the original file used to have the same errors, so I moved that directory and extracted a known good version of if_aironet_ieee.h. However now I’d just like to clean out the bad file. If I do an rm -rf on the file, it kicks me back to the command prompt like everything worked successfully, however if I ls that directory, it still shows up: $ ls /usr/include/dev/an_bak/ if_aironet_ieee.h $ sudo rm -rf /usr/include/dev/an_bak/if_aironet_ieee.h $ ls /usr/include/dev/an_bak/ if_aironet_ieee.h However, ls -al shows a different output: $ ls -al /usr/include/dev/an_bak/ ls: if_aironet_ieee.h: No such file or directory total 17 drwxr-xr-x 2 root wheel 3 Dec 21 20:32 . drwxr-xr-x 31 root wheel 31 Mar 16 15:26 .. I can move the an_bak folder to a different name within the same pool. However I cannot move that folder to a different zfs pool. I can not move just the file, either within the same pool or to a different pool. This is only one of the files that is giving me the problem, the daily output also lists a few others, but they all exhibit the same behavior. I tried sending the zfs dataset to another pool, and it exhibited the same problem. A scrub has not revealed any issues. Thanks, Mattias ___ 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 198642] EFI boot yields various error messages
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198642 cipher...@hotmail.com changed: What|Removed |Added Status|New |Closed Resolution|--- |FIXED --- Comment #4 from cipher...@hotmail.com --- Just tried with recent HEAD and it works perfectly without any problems, using a gzipped kernel and gzipped mfsroot. Now two issues i still want to investigate: 1) i compiled the HEAD with EFI_STAGING_SIZE=64 to increase the staging area to 64MiB instead of the 32MiB default. Maybe this increase is not necessary. 2) using the /boot/efiboot.fat file from HEAD on other branches like STABLE/10. This would allow booting 9.x and 10.x as well, if it works. Thanks for the help John Baldwin! -- 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 198645] krb5-config in 8.x and 9.x don't include krb5_gssapi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198645 Bug ID: 198645 Summary: krb5-config in 8.x and 9.x don't include krb5_gssapi Product: Base System Version: 8.4-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: freebsdb...@gushi.org Basic problem that can be easily seen in a cleanly installed 8.x: pkg install ap24-mod_auth_kerb2, service apache24 start. It'll fail to start. That has bug 198559 open to correct the *port*. However, it's a bug in base 8.x (and probably 9.x) triggering it that I wanted to get a PR open on. Anyway, the one-line patch that needs to be done is here: https://lists.freebsd.org/pipermail/freebsd-apache/2011-April/002207.html But that is a patch against the *generated* krb5-config, not the source code that creates it, via some kind of automatic process, I guess? Since there's not likely to be another 8.x release (and probably not another 9.x release?), if it doesn't make sense to fix these, please close this bug -- however, doing so means that the bug on the port will need to be acted on with some kind of conditional in the makefile. -Dan -- 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 198642] EFI boot yields various error messages
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198642 --- Comment #2 from cipher...@hotmail.com --- I indeed used a gzipped kernel (kernel.gz) but i also tried with an unzipped kernel. I guess the mfsroot itself may also not be gzipped? Is it possible to update the wiki UEFI page (wiki.freebsd.org/UEFI) to reflect that GZIP-compressed kernel/mfsroot is not supported at this time? -- 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 198642] EFI boot yields various error messages
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198642 --- Comment #1 from John Baldwin j...@freebsd.org --- gzipfs is not going to work without the changes in 279949 (the inflate messages are errors from gzipfs). You can try unzipping the kernel to see if that allows the kernel to work, but in general I'd recommend grabbing both 279949 and 279929 (the latter will at least report errors if your mfsroot is too large). -- 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 198642] EFI boot yields various error messages
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198642 Bug ID: 198642 Summary: EFI boot yields various error messages Product: Base System Version: 10.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: freebsd-bugs@FreeBSD.org Reporter: cipher...@hotmail.com I'm trying to get EFI boot working by following the document: https://wiki.freebsd.org/UEFI It roughly says: gpart create -s gpt da0 gpart add -t efi -s 800K da0 gpart add -t freebsd-ufs da0 dd if=/boot/boot1.efifat of=/dev/da0p1 newfs /dev/da0p2 I created a USB Stick roughly using the guideline above, but use a MFSroot on the UFS partition instead, and have partitions aligned to 1024K-boundaries. Then, i used RaWrite to create the USB stick. When trying to boot my USB stick on two real hardware systems (J1900) however, it first yields an error message that it cannot load /boot/loader.conf, and when it tries to load /boot/kernel/kernel, i get random error messages from the the following list: --- inflate: invalid code lengths set invalid distance too far back invalid distance code inflate: invalid stored block lengths readin failed. elf64_loadimage: read failed inflate: invalid block type --- The strange thing is that trying to boot (OK loader prompt) will yield a different error. I would expect getting the same error from the same input. It appears the error is randomly chosen from the above list. Maybe this is a clue? I am using a preloaded mfsroot. I saw some recent commits to HEAD (r279929) about addressing some issues with EFI staging area. But i'm not sure this is the problem, since the loader cannot load /boot/loader.conf or even the kernel itself. So loading the mfsroot of about 10MB would probably not be the issue? Having a working EFI boot is important, since some motherboards will not boot from MBR bootsector when GPT partitions are detected, or do not support MBR-style boot at all and insist on EFI boot. -- 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 198642] EFI boot yields various error messages
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198642 --- Comment #3 from John Baldwin j...@freebsd.org --- It's supported now. :) Either try unzipping both the kernel and mfsroot, or build an updated loader.efi from HEAD. -- 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 153426] [patch] fsck_msdosfs(8) only works with sector size 512
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=153426 --- Comment #3 from Pedro F. Giffuni p...@freebsd.org --- (In reply to Pedro F. Giffuni from comment #2) FWIW, I tested the patch with a 32K cluster size, which according to Microsoft is the maximum default cluster size for fat32: https://support.microsoft.com/en-us/kb/192322?wa=wsignin1.0 Partition size Cluster size - 512 MB to 8,191 MB 4 KB 8,192 MB to 16,383 MB 8 KB 16,384 MB to 32,767 MB 16 KB Larger than 32,768 MB 32 KB (Of course FAT16 accepts bigger values). I am able to run fsck on the filesystem before and after the patch, however, the filesystem is OK so fsck is actually doing nothing on both cases. -- 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
