Re: how to browse svnweb source?
On 29/05/2018 02:06, Jeffrey Bouquet wrote: > > > On Mon, 28 May 2018 17:04:11 -0600, Sean Bruno wrote: > >> >> >> On 05/28/18 15:37, Jeffrey Bouquet wrote: >>> Suddenly the site www.secnetix.de/olli/FreeBSD/svnews which showed >>> sequential >>> source as for example xx1966 on april 3 xx2040 on april 4 this year, >>> is not loading >>> in the browser. It was informative to read color coded the source >>> backported to v10 >>> v11 vs new, and new drivers coming into play. I can find NOWHERE except >>> freshsource.org which has the ports updates interspersed which makes the >>> information >>> too time consuming. As an example, >>> >>> 09:36:34 - r 318137Affects: /head/usr.bin/mking/mking.1 [ mking.c] >>> on 5-10-2017 adding the -C and --capacity options... >>> >>> ... >>> What was educational to browse now is found at >>> .. >>> ___ >>> 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" >>> >> >> >> https://svnweb.freebsd.org/base/head/ >> >> ? >> >> sean > > > I tried that url every which way, sorting the headings, etc, and onscreen > would be at best, a description of the new source but not specifically which > files were changed and their complete path. Nothing like the url mentioned > above at > .de in the latter's overview. Possibly freshbsd.org? I follow the 11-STABLE branch using https://freshbsd.org/?branch=RELENG_11=freebsd Vince > ___ > 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" > ___ 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: UEFI display frozen on Retina MacBook Pro
On 09/09/2014 17:56, John Nielsen wrote: On Sep 8, 2014, at 7:21 AM, Anders Bolt Evensen andersb...@icloud.com wrote: On 05.09.14 19:37, John Nielsen wrote: On Sep 5, 2014, at 11:30 AM, Glen Barber g...@freebsd.org wrote: On Fri, Sep 05, 2014 at 11:20:21AM -0600, John Nielsen wrote: I have a MacBook Pro Retina, Mid 2012 (MacBookPro10,1) on which I'd like to be able to boot FreeBSD from an external USB drive. For testing I've been using the mini-memstick images from the -CURRENT snapshots, most recently the one from 20140903. I am able to select EFI Boot on the USB device from the Mac's boot menu, and it does _something_, but the screen never changes--the image of the boot menu is displayed indefinitely. I think it is actually booting since there is drive activity and the caps lock key indicator starts working a few seconds in, but the screen just stays the same. Thinking the resolution of the Retina display may have been an issue, I tried booting with it disabled (lid closed) and an external monitor and keyboard. The result was the same--Mac boot menu frozen on the external display. Is there anything I should try to troubleshoot or debug this issue? Anything else I should include in a PR? I can test patches if needed (probably after building an image including the patch from a VM). To be clear, which boot menu do you see? If you see the FreeBSD loader menu, escape to the loader prompt and try: set kern.vty=vt set hw.vga.textmode=1 boot I am a bit unclear under which conditions 'hw.vga.textmode=1' is required, though. No, I don't ever see the FreeBSD loader. I see the menu you get on a Mac when you hold down the option (alt) key while booting--big disk icons representing the bootable disks/partitions in the system. In my case it was the Macintosh HD volume (Mac OS Mavericks), my Windows partition, and the USB stick with the FreeBSD memstick image on it, which the Mac just called EFI Boot (and the icon was that of a USB disk). There is also a little section at the bottom that allows wifi network booting (if you've done all the black magic (not PXE) to get that to happen). It shows a circular activity animation while it scans for wireless networks. That animation stops when I select the USB EFI icon and press enter (and that is the only visual indication I get that I made a selection). To see the FreeBSD (U)EFI boot loader on the Mac, you need to install an EFI shell like rEFIt on either your hard drive or a HFS formatted memory stick: 1) Download the rEFIt installer from here: http://downloads.sourceforge.net/project/refit/rEFIt/0.14/rEFIt-0.14.dmg?r=http%3A%2F%2Frefit.sourceforge.net%2Fts=1410181876use_mirror=optimate 2) Open the downloaded file 3) Run the following command from the terminal: sudo installer -pkg /Volumes/rEFIt/rEFIt.mpkg -tgt /Volumes/memstick (in this example, I'm using an HFS formatted memory stick). 4) Run the command sudo /Volumes/memstick/efi/enable.sh 5) When you reboot your Mac, when you hold down the alt key, choose rEFIt on the startup menu. Then, choose the BOOTx64.efi from … option If everything now goes as it should, you should see the FreeBSD loader. When the Press enter to boot or any other key to go to loader in X seconds (or whatever it says), press a random key. Then try to type the commands suggested by [Glen Barber]. Thanks all, made _some_ progress. I installed rEFInd on my internal hard drive and now I can get to (and see!) the FreeBSD EFI loader. Unfortunately that's about as far as it gets. Once I tell the loader to boot it displays the EFI framebuffer information and then nothing else. This happens with 'kern.vty=vt' set and with or without 'hw.vga.textmode=1'. Screenshot here: https://blog.jnielsen.net/images/efiloader.jpg What should the next troubleshooting steps be? Just wanted to add a me too. I've finding exactly the same thing trying a usb or DVD 11-CURRENT snapshot. Hardware is MacBook Pro (15-inch, Mid 2010) Model Name:MacBook Pro Model Identifier:MacBookPro6,2 Processor Name:Intel Core i7 Processor Speed:2.66 GHz Number of Processors:1 Total Number of Cores:2 L2 Cache (per Core):256 KB L3 Cache:4 MB Memory:8 GB Processor Interconnect Speed:4.8 GT/s Boot ROM Version:MBP61.0057.B0F SMC Version (system):1.58f17 Can upload a screenshot but its more or less identical to Johns. Vince JN ___ 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 ___ 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: [rfc] removing the NDISulator
On 23/10/2013 18:35, Eitan Adler wrote: On Mon, Oct 21, 2013 at 6:29 PM, Adrian Chadd adr...@freebsd.org wrote: If there are drivers that people absolutely need fixed then they should stand up and say hey, I really would like X to work better! and then follow it up with some encouraging incentives. Right now the NDISulator lets people work _around_ this by having something that kind of works for them but it doesn't improve our general driver / stack ecosystems. I doubt most people prefer to use the ndisulator over a native driver. However, many people don't have the skills, time, or money to provide the incentives you are talking about. At this point ndisulator provides a means to an end: working wireless and it isn't causing significant strain on the project in terms of development effort. Our end users are not always developers and I think removing this feature will hurt more than it will help. As an end user, the main issue I have is that according to the manpage it supports ndis 5.1 According to http://en.wikipedia.org/wiki/Network_Driver_Interface_Specification this is the version supported by Windows XP http://en.wikipedia.org/wiki/Windows_XP, Server 2003 http://en.wikipedia.org/wiki/Windows_Server_2003, Windows CE http://en.wikipedia.org/wiki/Windows_CE 4.x, 5.0, 6.0 As you might guess most new devices wont be coming with drivers for XP, so does this mean I wont be able to use drivers for a recent windows version (my understanding is that it will but happy to learn differently) If this is the case and there is no active development on it, a gradual depreciation over the 10.x series is probably a good idea. If however its likely to support current drivers/devices it does have a place (I've used it once or twice in a pinch.) Vince ^ ___ 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: test
Please use freebsd-test for testing http://lists.freebsd.org/mailman/listinfo/freebsd-test Vince On 08/10/2013 23:00, Joe Nosay wrote: What were you testing? On Tue, Oct 8, 2013 at 5:25 PM, Joe Nosay superbisq...@gmail.com wrote: /div/td/tr/tbody/table/td/tr/tbody/table/divdiv class=utdU2e/divdiv class=tx78Ic/divdiv class=aHl/divdiv id=:2il tabindex=-1/divdiv id=:2i7 class=ii gt m1419842a752abb3c adP adOdiv id=:2i6 style=overflow: hidden;testbr__ On Tue, Oct 8, 2013 at 9:29 AM, Alexander Panyushkin vsi...@gmail.comwrote: test __**_ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**currenthttp://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscribe@** freebsd.org freebsd-current-unsubscr...@freebsd.org ___ 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 ___ 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: Panic/Freeze with IPSEC on r254532
On 10/09/2013 09:18, Gavin Atkinson wrote: On Tue, 20 Aug 2013, Vincent Hoffman wrote: I thought I'd have a play with ipsec since its been a while since I last set it up, and was setting up a transport mode connection between my poudiere/repo server (the -curent server) and another box (8.2-RELEASE) 3 pings later the -CURRENT box froze, its zfs on root so no kernel dump I'm afraid, it does have an ipmi so I repeated with a serial over lan connection to test but got nothing it just froze. Any suggestions? The only unusual thing about this machine is that i am running a bhyve vm on it. not sure how relevant that is. FWIW, I posted on what is likely to be the same issue yesterday on freebsd-net@ - http://docs.FreeBSD.org/cgi/mid.cgi?1378750330.11656.44.camel Can you test the workaround I'm currently using? Basically, just ifconfig enc0 create before using the tunnel should be sufficient. Hi Gavin, I have tried your suggestion and am not getting the freezes any more, thanks for this. Another thing I have noticed is that racoon isnt creating a control socket for racoonctl, probably not related but I thought it worth mentioning root@bsdpkgbuild:~ # racoonctl show-sa ipsec send: Bad file descriptor l I did try stating racoon under truss and using racoon -F -d -d -d but didnt see it even try to open /var/db/racoon/racoon.sock while on the other end (8.4-RELEASE) I see 2013-09-10 13:24:19: DEBUG: open /var/db/racoon/racoon.sock as racoon management. in the output from racoon -F -d -d -d Thanks for finding a work around to the crash for now. Vince Gavin Log output 1st occurance Aug 20 13:24:51 bsdpkgbuild kernel: Kernel page fault with the following non-sleepable locks held: Aug 20 13:24:51 bsdpkgbuild kernel: shared rw ipsec request (ipsec request) r = 0 (0xf80020fe2f60) locked @ /usr/src/sys/netipsec/ipsec_output.c:436 Aug 20 13:24:51 bsdpkgbuild kernel: shared rw rawinp (rawinp) r = 0 (0xf800587afda8) locked @ /usr/src/sys/netinet/raw_ip.c:446 Aug 20 13:24:51 bsdpkgbuild kernel: KDB: stack backtrace: Aug 20 13:24:51 bsdpkgbuild kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0238af91e0 Aug 20 13:24:51 bsdpkgbuild kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0238af9290 Aug 20 13:24:51 bsdpkgbuild kernel: witness_warn() at witness_warn+0x4a8/frame 0xfe0238af9350 Aug 20 13:24:51 bsdpkgbuild kernel: trap_pfault() at trap_pfault+0x5a/frame 0xfe0238af9400 Aug 20 13:24:51 bsdpkgbuild kernel: trap() at trap+0x670/frame 0xfe0238af9620 Aug 20 13:24:51 bsdpkgbuild kernel: calltrap() at calltrap+0x8/frame 0xfe0238af9620 Aug 20 13:24:51 bsdpkgbuild kernel: --- trap 0xc, rip = 0x80aa6a53, rsp = 0xfe0238af96e0, rbp = 0xfe0238af9770 --- Aug 20 13:24:51 bsdpkgbuild kernel: ipsec4_process_packet() at ipsec4_process_packet+0x73/frame 0xfe0238af9770 Aug 20 13:24:51 bsdpkgbuild kernel: ip_ipsec_output() at ip_ipsec_output+0x197/frame 0xfe0238af97b0 Aug 20 13:24:51 bsdpkgbuild kernel: ip_output() at ip_output+0x8a3/frame 0xfe0238af98a0 Aug 20 13:24:51 bsdpkgbuild kernel: rip_output() at rip_output+0x2fa/frame 0xfe0238af98f0 Aug 20 13:24:51 bsdpkgbuild kernel: sosend_generic() at sosend_generic+0x3dc/frame 0xfe0238af99a0 Aug 20 13:24:51 bsdpkgbuild kernel: kern_sendit() at kern_sendit+0x1e4/frame 0xfe0238af9a40 Aug 20 13:24:51 bsdpkgbuild kernel: sendit() at sendit+0xf8/frame 0xfe0238af9a90 Aug 20 13:24:51 bsdpkgbuild kernel: sys_sendto() at sys_sendto+0x4d/frame 0xfe0238af9ae0 Aug 20 13:24:51 bsdpkgbuild kernel: amd64_syscall() at amd64_syscall+0x265/frame 0xfe0238af9bf0 Aug 20 13:24:51 bsdpkgbuild kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0238af9bf0 Aug 20 13:24:51 bsdpkgbuild kernel: --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x800d5ccea, rsp = 0x7ffed578, rbp = 0x7ffed5b0 --- Aug 20 13:24:51 bsdpkgbuild kernel: Aug 20 13:24:51 bsdpkgbuild kernel: Aug 20 13:24:51 bsdpkgbuild kernel: Fatal trap 12: page fault while in kernel mode Aug 20 13:24:51 bsdpkgbuild kernel: cpuid = 5; apic id = 02 Aug 20 13:24:51 bsdpkgbuild kernel: fault virtual address = 0xd0 Aug 20 13:24:51 bsdpkgbuild kernel: fault code = supervisor write data, page not present Aug 20 13:24:51 bsdpkgbuild kernel: instruction pointer = 0x20:0x80aa6a53 Aug 20 13:24:51 bsdpkgbuild kernel: stack pointer = 0x28:0xfe0238af96e0 Aug 20 13:24:51 bsdpkgbuild kernel: frame pointer = 0x28:0xfe0238af9770 Aug 20 13:24:51 bsdpkgbuild kernel: code segment= base 0x0, limit 0xf, type 0x1b Aug 20 13:24:51 bsdpkgbuild kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Aug 20 13:24:51 bsdpkgbuild kernel: processor eflags= interrupt enabled, === repeated occurrence Aug 20 14:16:21 bsdpkgbuild kernel: Kernel page fault with the following non-sleepable locks held
Re: Panic/Freeze with IPSEC on r254532
On 10/09/2013 14:25, Maciej Milewski wrote: On 10.09.2013 14:33, Vincent Hoffman wrote: root@bsdpkgbuild:~ # racoonctl show-sa ipsec send: Bad file descriptor l I did try stating racoon under truss and using racoon -F -d -d -d but didnt see it even try to open /var/db/racoon/racoon.sock while on the other end (8.4-RELEASE) I see 2013-09-10 13:24:19: DEBUG: open /var/db/racoon/racoon.sock as racoon management. in the output from racoon -F -d -d -d Have you enabled admin port during installation of ipsec-tools? I have OPTIONS_FILE_UNSET+=ADMINPORT in the options file so I didnt think so. but on the working (8.4-RELEASE) box i have OPTIONS_FILE_SET+=ADMINPORT ok will change that. pebkac :) Vince ___ 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
Panic/Freeze with IPSEC on r254532
I thought I'd have a play with ipsec since its been a while since I last set it up, and was setting up a transport mode connection between my poudiere/repo server (the -curent server) and another box (8.2-RELEASE) 3 pings later the -CURRENT box froze, its zfs on root so no kernel dump I'm afraid, it does have an ipmi so I repeated with a serial over lan connection to test but got nothing it just froze. Any suggestions? The only unusual thing about this machine is that i am running a bhyve vm on it. not sure how relevant that is. Log output 1st occurance Aug 20 13:24:51 bsdpkgbuild kernel: Kernel page fault with the following non-sleepable locks held: Aug 20 13:24:51 bsdpkgbuild kernel: shared rw ipsec request (ipsec request) r = 0 (0xf80020fe2f60) locked @ /usr/src/sys/netipsec/ipsec_output.c:436 Aug 20 13:24:51 bsdpkgbuild kernel: shared rw rawinp (rawinp) r = 0 (0xf800587afda8) locked @ /usr/src/sys/netinet/raw_ip.c:446 Aug 20 13:24:51 bsdpkgbuild kernel: KDB: stack backtrace: Aug 20 13:24:51 bsdpkgbuild kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0238af91e0 Aug 20 13:24:51 bsdpkgbuild kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0238af9290 Aug 20 13:24:51 bsdpkgbuild kernel: witness_warn() at witness_warn+0x4a8/frame 0xfe0238af9350 Aug 20 13:24:51 bsdpkgbuild kernel: trap_pfault() at trap_pfault+0x5a/frame 0xfe0238af9400 Aug 20 13:24:51 bsdpkgbuild kernel: trap() at trap+0x670/frame 0xfe0238af9620 Aug 20 13:24:51 bsdpkgbuild kernel: calltrap() at calltrap+0x8/frame 0xfe0238af9620 Aug 20 13:24:51 bsdpkgbuild kernel: --- trap 0xc, rip = 0x80aa6a53, rsp = 0xfe0238af96e0, rbp = 0xfe0238af9770 --- Aug 20 13:24:51 bsdpkgbuild kernel: ipsec4_process_packet() at ipsec4_process_packet+0x73/frame 0xfe0238af9770 Aug 20 13:24:51 bsdpkgbuild kernel: ip_ipsec_output() at ip_ipsec_output+0x197/frame 0xfe0238af97b0 Aug 20 13:24:51 bsdpkgbuild kernel: ip_output() at ip_output+0x8a3/frame 0xfe0238af98a0 Aug 20 13:24:51 bsdpkgbuild kernel: rip_output() at rip_output+0x2fa/frame 0xfe0238af98f0 Aug 20 13:24:51 bsdpkgbuild kernel: sosend_generic() at sosend_generic+0x3dc/frame 0xfe0238af99a0 Aug 20 13:24:51 bsdpkgbuild kernel: kern_sendit() at kern_sendit+0x1e4/frame 0xfe0238af9a40 Aug 20 13:24:51 bsdpkgbuild kernel: sendit() at sendit+0xf8/frame 0xfe0238af9a90 Aug 20 13:24:51 bsdpkgbuild kernel: sys_sendto() at sys_sendto+0x4d/frame 0xfe0238af9ae0 Aug 20 13:24:51 bsdpkgbuild kernel: amd64_syscall() at amd64_syscall+0x265/frame 0xfe0238af9bf0 Aug 20 13:24:51 bsdpkgbuild kernel: Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0238af9bf0 Aug 20 13:24:51 bsdpkgbuild kernel: --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x800d5ccea, rsp = 0x7ffed578, rbp = 0x7ffed5b0 --- Aug 20 13:24:51 bsdpkgbuild kernel: Aug 20 13:24:51 bsdpkgbuild kernel: Aug 20 13:24:51 bsdpkgbuild kernel: Fatal trap 12: page fault while in kernel mode Aug 20 13:24:51 bsdpkgbuild kernel: cpuid = 5; apic id = 02 Aug 20 13:24:51 bsdpkgbuild kernel: fault virtual address = 0xd0 Aug 20 13:24:51 bsdpkgbuild kernel: fault code = supervisor write data, page not present Aug 20 13:24:51 bsdpkgbuild kernel: instruction pointer = 0x20:0x80aa6a53 Aug 20 13:24:51 bsdpkgbuild kernel: stack pointer = 0x28:0xfe0238af96e0 Aug 20 13:24:51 bsdpkgbuild kernel: frame pointer = 0x28:0xfe0238af9770 Aug 20 13:24:51 bsdpkgbuild kernel: code segment= base 0x0, limit 0xf, type 0x1b Aug 20 13:24:51 bsdpkgbuild kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 Aug 20 13:24:51 bsdpkgbuild kernel: processor eflags= interrupt enabled, === repeated occurrence Aug 20 14:16:21 bsdpkgbuild kernel: Kernel page fault with the following non-sleepable locks held: Aug 20 14:16:21 bsdpkgbuild kernel: shared rw ipsec request (ipsec request) r = 0 (0xf8001a9820e0) locked @ /usr/src/sys/netipsec/ipsec_output.c:436 Aug 20 14:16:21 bsdpkgbuild kernel: shared rw rawinp (rawinp) r = 0 (0xf801db519da8) locked @ /usr/src/sys/netinet/raw_ip.c:446 Aug 20 14:16:21 bsdpkgbuild kernel: KDB: stack backtrace: Aug 20 14:16:21 bsdpkgbuild kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0238b081e0 Aug 20 14:16:21 bsdpkgbuild kernel: kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0238b08290 Aug 20 14:16:21 bsdpkgbuild kernel: witness_warn() at witness_warn+0x4a8/frame 0xfe0238b08350 Aug 20 14:16:21 bsdpkgbuild kernel: trap_pfault() at trap_pfault+0x5a/frame 0xfe0238b08400 Aug 20 14:16:21 bsdpkgbuild kernel: trap() at trap+0x670/frame 0xfe0238b08620 Aug 20 14:16:21 bsdpkgbuild kernel: calltrap() at calltrap+0x8/frame 0xfe0238b08620 Aug 20 14:16:21 bsdpkgbuild kernel: --- trap 0xc, rip = 0x80aa6a53, rsp = 0xfe0238b086e0, rbp = 0xfe0238b08770 --- Aug 20 14:16:21 bsdpkgbuild kernel: ipsec4_process_packet() at
Re: daily otput: rejected mail hosts?
On 20/02/2013 11:09, Anton Shterenlikht wrote: From mexas Thu Feb 14 09:51:50 2013 To: freebsd-questi...@freebsd.org Subject: daily otput: rejected mail hosts? Reply-To: me...@bristol.ac.uk I see in the daily output: Checking for rejected mail hosts: 172 553 check_mail system.mail exist 129 553 check_mail tsvpt014.vpt.co.uk exist 43 553 check_mail unix.dedicated.com.tr exist 43 553 check_mail ubs.net exist 43 553 check_mail localhost.localdomain exist 43 553 check_mail journal-cfp.org exist 43 553 check_mail italiasito.it exist What is that about? Is this described somewhere in sendmail manuals? I got no reply from questions@, so trying my luck here. questions@ is a better place to ask really as this isnt -CURRENT related, its part of the output of the daily periodic script /etc/periodic/daily/460.status-mail-rejects which is enabled by default. the defaults are in /etc/defaults/periodic.conf feel free to overide them in /etc/periodic.conf Vince Thanks Anton ___ 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 ___ 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: [HEADSUP] current switched by default to pkgng
On 19/10/2012 15:39, Alex Keda wrote: On 10.10.2012 17:44, Baptiste Daroussin wrote: Hi all, If you are using the ports tree on a FreeBSD current setup, then you are concerned by the announce. As nvidia-drivers has been fixed and is now properly working with pkgng, the ports tree as been switch by default to use pkgng on FreeBSD Current based on version = 117 which was the version when we tested the switch code. Make sure to read UPDATING (from ports) to correctly migrate your system or find instruction to make your system still running with legacy pkg_install tools. regards, Bapt pkg command does not have key for list options - no autocompletions for example, for service command, I use complete service'n/*/`service -l`/' in .cshrc what I can use for pkg command? horrible but working example pkg help 21 | sed -e '1,/Commands supported:/d ; /For more information on the different commands/,$d; s/^ *// ; s/ .*.*$// ;/^$/d' There's bound to be better ways, I was just bored enough to knock this up. note s/^*// is a tab, while s/ .*.*$// is 2 spaces dont think our sed has any other way to express tab other than an actual tab (ctrl-v then tab on the command line) Vince ___ 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 ___ 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: [HEADSUP] current switched by default to pkgng
On 10/10/2012 20:50, Matthew Seaman wrote:
On 10/10/2012 19:35, Stefan Esser wrote:
Am 10.10.2012 19:14, schrieb Matthew Seaman:
On 10/10/2012 15:07, O. Hartmann wrote:
Is ports-mgmt/portmaster now dealing with pkgng?
Not yet. bdrewery has taken over the portmaster port and pkgng
related updates are expected in the near future.
Until then, you still need to follow the instructions here:
https://github.com/pkgng/pkgng/blob/master/FAQ.md#15
In order to get the portmaster-pkgng patch to apply,
the filename in the second line must be changed:
from ./portmaster.sh.in
to ./portmaster
That's if you were to patch an already installed copy of portmaster.
The patch is designed to be placed in
${PORTSDIR}/ports-mgmt/portmaster/files/
so it would be applied as part of the normal process of building the
portmaster port. In which case portmaster.sh.in is definitely the
correct target.
Actually not so, maybe something has changed recently?
[root@ostracod /usr/ports/ports-mgmt/portmaster]# head -4
files/patch-portmaster-pkgng
--- ./portmaster.sh.in.orig 2012-10-01 09:34:15.0 +0100
+++ ./portmaster.sh.in 2012-10-02 18:14:34.319249588 +0100
@@ -47,7 +47,7 @@
#=== Begin functions we always want to have ===
[root@ostracod /usr/ports/ports-mgmt/portmaster]# make patch
=== License BSD accepted by the user
=== Found saved configuration for portmaster-3.11
=== portmaster-3.14 depends on file: /usr/local/sbin/pkg - found
=== Extracting for portmaster-3.14
= SHA256 Checksum OK for portmaster-portmaster-3.14-31009f6.tar.gz.
=== Patching for portmaster-3.14
=== Applying FreeBSD patches for portmaster-3.14
File to patch: ^C= Patch patch-portmaster-pkgng failed to apply cleanly.
While if edited as suggested
[root@ostracod /usr/ports/ports-mgmt/portmaster]# !head
head -4 files/patch-portmaster-pkgng
--- ./portmaster.sh.in.orig 2012-10-01 09:34:15.0 +0100
+++ ./portmaster2012-10-02 18:14:34.319249588 +0100
@@ -47,7 +47,7 @@
#=== Begin functions we always want to have ===
[root@ostracod /usr/ports/ports-mgmt/portmaster]# make patch
=== License BSD accepted by the user
=== Found saved configuration for portmaster-3.11
=== portmaster-3.14 depends on file: /usr/local/sbin/pkg - found
=== Extracting for portmaster-3.14
= SHA256 Checksum OK for portmaster-portmaster-3.14-31009f6.tar.gz.
=== Patching for portmaster-3.14
=== Applying FreeBSD patches for portmaster-3.14
[root@ostracod /usr/ports/ports-mgmt/portmaster]#
Vince
___
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: ECMP/FreeBSD its a dream?
On 08/08/2012 13:39, Alisson wrote: Hi... everybody knows the stability of freebsd... but... and the protocol ECMP? its a dream? I havent tried but google says http://lists.freebsd.org/pipermail/cvs-src/2008-April/089956.html Its in since 2008 Vince to use 2 routes with diferent gateways? to load balance? ECMP its a dream? ___ 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 ___ 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: portmaster and pkgng
On 23/07/2012 09:43, Hartmann, O. wrote: Hello. I'd like to try pkgng with portmaster. I see that pkg2ng is involving the directory /var/db/pkg, so this implies that there may implications also for usage with ports-mgmt/portmaster. portmaster is supposed to be the tool completely dependend on system's toolsets, isn't it? I know that pkg is supposed to be more for binary maintainance of the system, but I'd like to be stuck with compiling my ports. Is there an issue with that? Thanks inadvance and sorry for the (naive) noise. I believe there is a patch for portmaster at https://github.com/pkgng/pkgng/tree/master/ports I havent tried this just yet, planning to today though. I'm busy trying out pkg too. I have a repo online using poudriere and like it very much, so far my only real issue has been that when I changed repo from mine back to pkgbeta.FreeBSD.org I had to force an update (pkg update -f) I imagine due to the timestamp being older on the repo I am trying to change to. Not much of a problem as I consider using custom repos a more advanced usage and it just force me to read the manual again :) moving back the other way worked fine, while trying to use multirepo didnt work at all (but does say its experimental and dont expect it to work.) A built in equivalent to portmasters -o option (replace the installed port with a port from a different origin) would be nice as currently all my perl modules are listed as having a missing dependency since I forced an upgrade from perl5.12 to perl5.14 but then that's not in our current pkg tools so using portmaster or similar for this is reasonable enough. Vince Regards, Oliver ___ 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 ___ 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: MPSAFE VFS -- List of upcoming actions
On 19/07/2012 13:36, Julian H. Stacey wrote: PS Re ext2: I'm looking for an equivalent of mkfs_ext2, any suggestions ? Ports maybe ? sounds like you want sysutils/e2fsprogs ext2/3/4 mkfs/fsck etc. I believe. ___ 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: Occassional permission denied in the middle of a large transfer over NFS
On 09/07/2012 02:08, Rick Macklem wrote: Vincent Hoffman: On 08/07/2012 00:26, Rick Macklem wrote: Vincent Hoffman wrote: Hi Rick, I'm afraid this didnt make any real difference for me. Since I couldnt test it on the live system I tried it on a test vm. on the vm (nfs server) I set a looping mount/umount while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; done and on the client I set a loop of tars of large directorys to the nfs mount running under time to see how well it survived. Then replicated the test with the patch and without. Just to confirm, you patched both the kernel and mountd and replaced both on the server? Also, I'm not sure how ZFS handles it's exports. I can't remember if you've tried an exported UFS volume. It might be something ZFS specific? rick Hi Rick, yes I patched both the kernel and mountd, rebuilt kernel and world (to be sure), added the -S flag to mountd in rc.conf and rebooted. This is a test VM running -CURRENT and is only exporting a ufs2 filesystem. (11:43:05 ~) 0 $ cat /etc/exports /usr/local/export -maproot=root -alldirs XX.XX.XX.XX Client is a 8.3-RELEASE box but I see the same with linux clients. (I can confirm that it works fine when I am not running the mount/umount loop) Oops, the patch I sent you worked for NFSv4 only. If you also apply the attached patch, it seems to work for NFSv3 as well. The patch is also at: http://people.freebsd.org/~rmacklem/atomic-export2.patch You must also run the new/experimental server. (I can't remember if I mentioned that before.) rick Hi Rick, Just wanted to report that this fixed the permission denied error for my (not terribly exhaustive) testing. I could transfer all 10G of data by tar to the nfs mount without issue. I'll try running that a couple more times to be sure but given it was bombing out in seconds before i'm happy :) Vince ___ 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: Occassional permission denied in the middle of a large transfer over NFS
On 09/07/2012 02:08, Rick Macklem wrote: Vincent Hoffman: On 08/07/2012 00:26, Rick Macklem wrote: Vincent Hoffman wrote: Hi Rick, I'm afraid this didnt make any real difference for me. Since I couldnt test it on the live system I tried it on a test vm. on the vm (nfs server) I set a looping mount/umount while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; done and on the client I set a loop of tars of large directorys to the nfs mount running under time to see how well it survived. Then replicated the test with the patch and without. Just to confirm, you patched both the kernel and mountd and replaced both on the server? Also, I'm not sure how ZFS handles it's exports. I can't remember if you've tried an exported UFS volume. It might be something ZFS specific? rick Hi Rick, yes I patched both the kernel and mountd, rebuilt kernel and world (to be sure), added the -S flag to mountd in rc.conf and rebooted. This is a test VM running -CURRENT and is only exporting a ufs2 filesystem. (11:43:05 ~) 0 $ cat /etc/exports /usr/local/export -maproot=root -alldirs XX.XX.XX.XX Client is a 8.3-RELEASE box but I see the same with linux clients. (I can confirm that it works fine when I am not running the mount/umount loop) Oops, the patch I sent you worked for NFSv4 only. If you also apply the attached patch, it seems to work for NFSv3 as well. The patch is also at: http://people.freebsd.org/~rmacklem/atomic-export2.patch You must also run the new/experimental server. (I can't remember if I mentioned that before.) rick You did mention that :) Thanks I'll give this one a go. Vince The production system has been fine since I removed the SIGHUP call in mount.c so thanks for that suggestion. Vince [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt x nopatch.txt + atomicpatch.txt +--+ | * | | * | | x* | | xx* x | | +x** xx | | xxx x | | xxx +x+ + | | +*xx +x+ x + | | +*xx + + x | | *+*xx+ +++x * x x | | x**++*x+***x+ x*+ x ++*+ + x+ +x + + +| |||___M_M_A__A___|__| | +--+ N Min Max Median Avg Stddev x 101 1.25 106.8 14.08 21.892178 22.196005 + 101 1.21 186.93 18.46 27.995842 30.523218 No difference proven at 95.0% confidence (excuse wrapped ascii art) I think I'll have a look at the nfse patch set and see how that performs. Thanks for all your work on NFS on FreeBSD. Vince Also, you could easily hack mount.c so that it doesn't send a SIGHUP to mountd (which causes the exports to be reloaded) every time a local fs is mounted. True and I may have to do that for the production NAS for the time being. Thanks for looking at this. Vince rick thanks, Vince ___ 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 ___ 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 ___ 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: Occassional permission denied in the middle of a large transfer over NFS
On 08/07/2012 00:26, Rick Macklem wrote: Vincent Hoffman wrote: Hi Rick, I'm afraid this didnt make any real difference for me. Since I couldnt test it on the live system I tried it on a test vm. on the vm (nfs server) I set a looping mount/umount while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; done and on the client I set a loop of tars of large directorys to the nfs mount running under time to see how well it survived. Then replicated the test with the patch and without. Just to confirm, you patched both the kernel and mountd and replaced both on the server? Also, I'm not sure how ZFS handles it's exports. I can't remember if you've tried an exported UFS volume. It might be something ZFS specific? rick Hi Rick, yes I patched both the kernel and mountd, rebuilt kernel and world (to be sure), added the -S flag to mountd in rc.conf and rebooted. This is a test VM running -CURRENT and is only exporting a ufs2 filesystem. (11:43:05 ~) 0 $ cat /etc/exports /usr/local/export -maproot=root -alldirs XX.XX.XX.XX Client is a 8.3-RELEASE box but I see the same with linux clients. (I can confirm that it works fine when I am not running the mount/umount loop) The production system has been fine since I removed the SIGHUP call in mount.c so thanks for that suggestion. Vince [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt x nopatch.txt + atomicpatch.txt +--+ | * | | * | | x* | | xx* x | | +x** xx | | xxx x | | xxx +x+ + | | +*xx +x+ x + | | +*xx + + x | | *+*xx+ +++x * x x | | x**++*x+***x+ x*+ x ++*+ + x+ +x + + +| |||___M_M_A__A___|__| | +--+ N Min Max Median Avg Stddev x 101 1.25 106.8 14.08 21.892178 22.196005 + 101 1.21 186.93 18.46 27.995842 30.523218 No difference proven at 95.0% confidence (excuse wrapped ascii art) I think I'll have a look at the nfse patch set and see how that performs. Thanks for all your work on NFS on FreeBSD. Vince Also, you could easily hack mount.c so that it doesn't send a SIGHUP to mountd (which causes the exports to be reloaded) every time a local fs is mounted. True and I may have to do that for the production NAS for the time being. Thanks for looking at this. Vince rick thanks, Vince ___ 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 ___ 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: Occassional permission denied in the middle of a large transfer over NFS
On 07/07/2012 13:26, Vincent Hoffman wrote: On 01/07/2012 12:18, Rick Macklem wrote: Vincent Hoffman wrote: On 01/07/2012 01:53, Rick Macklem wrote: To modify mountd to use the kernel changes is more work than I have time for, in part because mountd.c is a very ugly old piece of C code, imho. I do have a patch that suspends/resumes execution of the nfsd threads (new, experimental for FreeBSD8.n only) when mountd reloads /etc/exports. This approach has certain disadvantages vs Andrey's transactional load/commit model, but it is simple and might be sufficient for your problem. If you want to try this patch, it is at: http://people.freebsd.org/~rmacklem/atomic-export.patch (The patch affects both the kernel and mountd.c.) Happy to try it, to be certain I have understood, this is for the newnfs server (experimental in 8.x default for 8 9+) Yes, that is correct. For the old (default on 8.x) it will have no effect. I'll apply to my -CUREENT test VM for now. Will fire up a 8.3 vm when i get a minute. Also, to enable it, you must add a -S flag to mountd_flags, after you've replaced the mountd executable. The patch is pretty straightforward, but has not seen much testing. Hopefully, it might be useful for you, rick Hi Rick, I'm afraid this didnt make any real difference for me. Since I couldnt test it on the live system I tried it on a test vm. on the vm (nfs server) I set a looping mount/umount while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; done and on the client I set a loop of tars of large directorys to the nfs mount running under time to see how well it survived. Then replicated the test with the patch and without. [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt x nopatch.txt + atomicpatch.txt +--+ | * | | * | | x* | | xx* x | | +x** xx | | xxx x | | xxx +x+ + | | +*xx +x+ x + | | +*xx + + x | | *+*xx+ +++x * x x | | x**++*x+***x+ x*+ x ++*+ + x+ +x + + +| |||___M_M_A__A___|__| | +--+ N Min MaxMedian AvgStddev x 101 1.25 106.8 14.08 21.892178 22.196005 + 101 1.21186.93 18.46 27.995842 30.523218 No difference proven at 95.0% confidence (excuse wrapped ascii art) I think I'll have a look at the nfse patch set and see how that performs. Replying to myself just as a record, I have tried nfse and I didnt get the permission denied at all. The only issue I had with it is that it strictly adheres to the syntax in exports(5) while mountd is a little more flexible. I had /usr/local/export -alldirs -maproot=root 85.xx.xx.xx /usr is the root of that filesystem mountd - allowed this but actually silently exports /usr (and all dirs below) nfse - didnt allow this, it needed to be the correct /usr -alldirs -maproot=root 85.xx.xx.xx which is I guess a POLA violation but follows the documentation. this was using nfse in mountd compatibility mode. I havent played with its more advanced features. Vince Thanks for all your work on NFS on FreeBSD. Vince ___ 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: Occassional permission denied in the middle of a large transfer over NFS
On 01/07/2012 12:18, Rick Macklem wrote: Vincent Hoffman wrote: On 01/07/2012 01:53, Rick Macklem wrote: To modify mountd to use the kernel changes is more work than I have time for, in part because mountd.c is a very ugly old piece of C code, imho. I do have a patch that suspends/resumes execution of the nfsd threads (new, experimental for FreeBSD8.n only) when mountd reloads /etc/exports. This approach has certain disadvantages vs Andrey's transactional load/commit model, but it is simple and might be sufficient for your problem. If you want to try this patch, it is at: http://people.freebsd.org/~rmacklem/atomic-export.patch (The patch affects both the kernel and mountd.c.) Happy to try it, to be certain I have understood, this is for the newnfs server (experimental in 8.x default for 8 9+) Yes, that is correct. For the old (default on 8.x) it will have no effect. I'll apply to my -CUREENT test VM for now. Will fire up a 8.3 vm when i get a minute. Also, to enable it, you must add a -S flag to mountd_flags, after you've replaced the mountd executable. The patch is pretty straightforward, but has not seen much testing. Hopefully, it might be useful for you, rick Hi Rick, I'm afraid this didnt make any real difference for me. Since I couldnt test it on the live system I tried it on a test vm. on the vm (nfs server) I set a looping mount/umount while true ; do mount /dev/md0 /mnt/tmp ; sleep 1 ; umount /mnt/tmp ; done and on the client I set a loop of tars of large directorys to the nfs mount running under time to see how well it survived. Then replicated the test with the patch and without. [root@seaurchin ~]# ministat nopatch.txt atomicpatch.txt x nopatch.txt + atomicpatch.txt +--+ | * | | * | | x* | | xx* x | | +x** xx | | xxx x | | xxx +x+ + | | +*xx +x+ x + | | +*xx + + x | | *+*xx+ +++x * x x | | x**++*x+***x+ x*+ x ++*+ + x+ +x + + +| |||___M_M_A__A___|__| | +--+ N Min MaxMedian AvgStddev x 101 1.25 106.8 14.08 21.892178 22.196005 + 101 1.21186.93 18.46 27.995842 30.523218 No difference proven at 95.0% confidence (excuse wrapped ascii art) I think I'll have a look at the nfse patch set and see how that performs. Thanks for all your work on NFS on FreeBSD. Vince Also, you could easily hack mount.c so that it doesn't send a SIGHUP to mountd (which causes the exports to be reloaded) every time a local fs is mounted. True and I may have to do that for the production NAS for the time being. Thanks for looking at this. Vince rick thanks, Vince ___ 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: Occassional permission denied in the middle of a large transfer over NFS
On 02/07/2012 13:05, Andrey Simonenko wrote: On Sun, Jul 01, 2012 at 12:13:30PM +0100, Vincent Hoffman wrote: On 01/07/2012 01:53, Rick Macklem wrote: I haven't looked at Andrey's patch, but conceptually it sounds like the best approach. As I understand it, the problem with replacing mountd with nfse (at least in the FreeBSD source tree) is that nfse is not 100% backwards compatible with /etc/exports and, as such, is a POLA violation. Understood. Its far from a simple drop in replacement. List of difference between nfse -C ... (compatible mode with mountd) and mountd is given here: http://lists.freebsd.org/pipermail/freebsd-fs/2012-June/014554.html If we ignore absence of some obsolete options support and some command line options, the rest of differences visible to a user will occur only if one does not follow rules of exports(5) file format. The native mode of nfse (nfs.exports(5) file format) is different than the logic of mountd, just because using existent exports(5) file format it is impossible to specify export of not mounted file system, it is impossible to specify all export settings for one file system in one line, etc. Can you verify whether nfse compatible mode with mountd is really compatible with exports(5) files on your systems using instructions from this message (no installation or patching is required): http://lists.freebsd.org/pipermail/freebsd-fs/2010-May/008421.html Its certainly compatible for me. I only have simple requirements though. (Basic NFS exports for servers to dump their backups onto.) nfse does look very good to me and I'll certainly be trying it in a VM. Any Ideas as to what would be needed to get this imported? Vince ___ 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: Occassional permission denied in the middle of a large transfer over NFS
On 01/07/2012 01:53, Rick Macklem wrote: Vincent Hoffman wrote: Just a note to say I have tested this on -CURRENT with the new nfs server and it is still the case. On the client (FreeBSD seaurchin 8.3-RELEASE-p3 FreeBSD 8.3-RELEASE-p3 #0: Tue Jun 12 00:39:29 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64) [root@seaurchin /mnt/nfs/vm]# date ; tar -cf foo.tar /var/nfsen/profiles-data/ ; date Thu Jun 28 20:12:36 BST 2012 tar: Removing leading '/' from member names tar: Write error Thu Jun 28 20:12:38 BST 2012 [root@seaurchin /mnt/nfs/vm]# on the Server [root@fbsd /var/tmp]# uname -a ; date ; while true ; do mount /dev/md0 /mnt/tmp/ ; umount /mnt/tmp ; done FreeBSD fbsd 10.0-CURRENT FreeBSD 10.0-CURRENT #22 r237646: Wed Jun 27 19:13:26 BST 2012 t...@fbsd.bmk.namesco.net:/usr/obj/usr/src/sys/unsane-vm amd64 Thu Jun 28 20:12:38 BST 2012 ^C [root@fbsd /var/tmp]# any suggestions welcome. Vince On 27/06/2012 16:27, Vincent Hoffman wrote: Hi, After only one off-list reply from the author of kern/136865 (see below) after asking -questions, I thought it worth asking -CURRENT. Basically: I seem to have run into the problems described in this old thread. http://lists.freebsd.org/pipermail/freebsd-questions/2004-April/044927.html tl:dr mountd may give incorrect permission denied errors when it is refreshing the exports list due to non-atomic operations, /sbin/mount has code that sends SIGHUP to mountd on any mount operation, which implies that any manual mount request would cause the problem. Currently I have still only tested on 8.3-RELEASE but the svn log doesnt seem to mention a fix since then. I'm currently taking a VM up to -CURRENT to test. Looking though old PRs I see the following related. kern/131342 kern/136865 (with patch for 7.2 and links to http://nfse.sourceforge.net/ for -CURRENT ) Does anyone who is qualified (sadly not me) feel like looking at the code to see if its suitable for inclusion in part/whole as not having NFS transfers interrupted by local mount operations on the nfs server would be very handy :) I haven't looked at Andrey's patch, but conceptually it sounds like the best approach. As I understand it, the problem with replacing mountd with nfse (at least in the FreeBSD source tree) is that nfse is not 100% backwards compatible with /etc/exports and, as such, is a POLA violation. Understood. Its far from a simple drop in replacement. To modify mountd to use the kernel changes is more work than I have time for, in part because mountd.c is a very ugly old piece of C code, imho. I do have a patch that suspends/resumes execution of the nfsd threads (new, experimental for FreeBSD8.n only) when mountd reloads /etc/exports. This approach has certain disadvantages vs Andrey's transactional load/commit model, but it is simple and might be sufficient for your problem. If you want to try this patch, it is at: http://people.freebsd.org/~rmacklem/atomic-export.patch (The patch affects both the kernel and mountd.c.) Happy to try it, to be certain I have understood, this is for the newnfs server (experimental in 8.x default for 8 9+) I'll apply to my -CUREENT test VM for now. Will fire up a 8.3 vm when i get a minute. Also, you could easily hack mount.c so that it doesn't send a SIGHUP to mountd (which causes the exports to be reloaded) every time a local fs is mounted. True and I may have to do that for the production NAS for the time being. Thanks for looking at this. Vince rick thanks, Vince ___ 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 ___ 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 ___ 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 ___ 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: Occassional permission denied in the middle of a large transfer over NFS
Just a note to say I have tested this on -CURRENT with the new nfs server and it is still the case. On the client (FreeBSD seaurchin 8.3-RELEASE-p3 FreeBSD 8.3-RELEASE-p3 #0: Tue Jun 12 00:39:29 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64) [root@seaurchin /mnt/nfs/vm]# date ; tar -cf foo.tar /var/nfsen/profiles-data/ ; date Thu Jun 28 20:12:36 BST 2012 tar: Removing leading '/' from member names tar: Write error Thu Jun 28 20:12:38 BST 2012 [root@seaurchin /mnt/nfs/vm]# on the Server [root@fbsd /var/tmp]# uname -a ; date ; while true ; do mount /dev/md0 /mnt/tmp/ ; umount /mnt/tmp ; done FreeBSD fbsd 10.0-CURRENT FreeBSD 10.0-CURRENT #22 r237646: Wed Jun 27 19:13:26 BST 2012 t...@fbsd.bmk.namesco.net:/usr/obj/usr/src/sys/unsane-vm amd64 Thu Jun 28 20:12:38 BST 2012 ^C [root@fbsd /var/tmp]# any suggestions welcome. Vince On 27/06/2012 16:27, Vincent Hoffman wrote: Hi, After only one off-list reply from the author of kern/136865 (see below) after asking -questions, I thought it worth asking -CURRENT. Basically: I seem to have run into the problems described in this old thread. http://lists.freebsd.org/pipermail/freebsd-questions/2004-April/044927.html tl:dr mountd may give incorrect permission denied errors when it is refreshing the exports list due to non-atomic operations, /sbin/mount has code that sends SIGHUP to mountd on any mount operation, which implies that any manual mount request would cause the problem. Currently I have still only tested on 8.3-RELEASE but the svn log doesnt seem to mention a fix since then. I'm currently taking a VM up to -CURRENT to test. Looking though old PRs I see the following related. kern/131342 kern/136865 (with patch for 7.2 and links to http://nfse.sourceforge.net/ for -CURRENT ) Does anyone who is qualified (sadly not me) feel like looking at the code to see if its suitable for inclusion in part/whole as not having NFS transfers interrupted by local mount operations on the nfs server would be very handy :) thanks, Vince ___ 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 ___ 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: -CURRENT Panic at boot at Revision: 237264 mutex gif softc not owned at /usr/src/sys/netinet/in_gif.c:105
Hi, Just a quick ping to make sure this isnt forgotten. Would it help if I open a PR? regards, Vince On 21/06/2012 19:34, John Baldwin wrote: On Thursday, June 21, 2012 12:41:59 pm Vincent Hoffman wrote: Hi again, The 2nd patch (to if.h and if_gif.c) also fixes the panic on boot. Thanks for the quick response as ever. Great, thanks for testing! Randall, do you have any thoughts on these patches? Vince ___ 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
Occassional permission denied in the middle of a large transfer over NFS
Hi, After only one off-list reply from the author of kern/136865 (see below) after asking -questions, I thought it worth asking -CURRENT. Basically: I seem to have run into the problems described in this old thread. http://lists.freebsd.org/pipermail/freebsd-questions/2004-April/044927.html tl:dr mountd may give incorrect permission denied errors when it is refreshing the exports list due to non-atomic operations, /sbin/mount has code that sends SIGHUP to mountd on any mount operation, which implies that any manual mount request would cause the problem. Currently I have still only tested on 8.3-RELEASE but the svn log doesnt seem to mention a fix since then. I'm currently taking a VM up to -CURRENT to test. Looking though old PRs I see the following related. kern/131342 kern/136865 (with patch for 7.2 and links to http://nfse.sourceforge.net/ for -CURRENT ) Does anyone who is qualified (sadly not me) feel like looking at the code to see if its suitable for inclusion in part/whole as not having NFS transfers interrupted by local mount operations on the nfs server would be very handy :) thanks, Vince ___ 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: -CURRENT Panic at boot at Revision: 237264 mutex gif softc not owned at /usr/src/sys/netinet/in_gif.c:105
Hi again,
The 2nd patch (to if.h and if_gif.c) also fixes the
panic on boot.
Thanks for the quick response as ever.
Vince
On 20/06/2012 13:12, John Baldwin wrote:
On Tuesday, June 19, 2012 8:05:36 pm Vincent Hoffman wrote:
Full dump info at http://unsane.co.uk/crash
It seems to have popped up between r236905 (working kernel) and r237264
(this panic)
the gif config I have in rc.conf is for a HE ipv6 tunnel
Looks like this was broken in r236951 by Randall (cc'd).
I think this would fix it:
Index: if_gif.c
===
--- if_gif.c (revision 237227)
+++ if_gif.c (working copy)
@@ -366,11 +366,12 @@ gif_start(struct ifnet *ifp)
return;
}
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
- GIF_UNLOCK(sc);
keep_going:
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
+ GIF_UNLOCK(sc);
IFQ_DRV_DEQUEUE(ifp-if_snd, m);
+ GIF_LOCK(sc);
if (m == 0)
break;
@@ -424,14 +425,12 @@ keep_going:
ifp-if_oerrors++;
}
- GIF_LOCK(sc);
if (ifp-if_drv_flags IFF_GIF_WANTED) {
/* Someone did a start while
* we were unlocked and processing
* lets clear the flag and try again.
*/
ifp-if_drv_flags = ~IFF_GIF_WANTED;
- GIF_UNLOCK(sc);
goto keep_going;
}
ifp-if_drv_flags = ~IFF_DRV_OACTIVE;
However, unless there is a known LOR, I would be inclined to
just hold the lock across IFQ_DRV_DEQUEUE() and dispense with
all the 'keep_going', etc. logic. Other NIC drivers tend to
just hold their transmit lock for the entire loop in their
start routines.
That would look like this:
Index: if.h
===
--- if.h (revision 237227)
+++ if.h (working copy)
@@ -153,7 +153,6 @@
#define IFF_STATICARP 0x8 /* (n) static ARP */
#define IFF_DYING 0x20/* (n) interface is winding
down */
#define IFF_RENAMING0x40/* (n) interface is being
renamed */
-#define IFF_GIF_WANTED 0x100 /* (n) The gif tunnel is wanted
*/
/*
* Old names for driver flags so that user space tools can continue to use
* the old (portable) names.
Index: if_gif.c
===
--- if_gif.c (revision 237227)
+++ if_gif.c (working copy)
@@ -359,15 +359,7 @@
sc = ifp-if_softc;
GIF_LOCK(sc);
- if (ifp-if_drv_flags IFF_DRV_OACTIVE) {
- /* Already active */
- ifp-if_drv_flags |= IFF_GIF_WANTED;
- GIF_UNLOCK(sc);
- return;
- }
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
- GIF_UNLOCK(sc);
-keep_going:
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
IFQ_DRV_DEQUEUE(ifp-if_snd, m);
@@ -424,16 +416,6 @@
ifp-if_oerrors++;
}
- GIF_LOCK(sc);
- if (ifp-if_drv_flags IFF_GIF_WANTED) {
- /* Someone did a start while
- * we were unlocked and processing
- * lets clear the flag and try again.
- */
- ifp-if_drv_flags = ~IFF_GIF_WANTED;
- GIF_UNLOCK(sc);
- goto keep_going;
- }
ifp-if_drv_flags = ~IFF_DRV_OACTIVE;
GIF_UNLOCK(sc);
return;
I would prefer this latter patch if it is ok as it makes the code simpler.
Also, IFF_GIF_WANTED as a new iff flag seems really hackish. IFF_* flags
are supposed to be interface independent. A flag like that should be in a
private field in the gif softc, not something exposed to the entire system.
cloned_interfaces=gif0
ifconfig_gif0=tunnel 85.233.185.162 216.66.80.26
ifconfig_gif0_ipv6=inet6 2001:470:1f08:110::2 2001:470:1f08:110::1
prefixlen 128 -accept_rtadv
src.conf only has
WITHOUT_IPFILTER=true
WITHOUT_KERBEROS=true
WITHOUT_PROFILE=yes
Happy to provide any more info as needed. any suggestions welcome, I'll
see if I can track it further with a binary search tomorrow.
From dump info file (at above URL)
#0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:266
266 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:266
#1 0x80314740 in db_dump (dummy=Variable dummy is not available.
)
at /usr/src/sys/ddb/db_command.c:538
#2 0x80313d31 in db_command (last_cmdp=0x80c52b40,
cmd_table=Variable cmd_table is not available.
) at /usr/src/sys/ddb/db_command.c:449
#3 0x80313f80 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:502
#4 0x803160d9 in db_trap (type=Variable type is not available.
) at /usr/src/sys/ddb/db_main.c:231
#5 0x80590918 in kdb_trap (type
Re: -CURRENT Panic at boot at Revision: 237264 mutex gif softc not owned at /usr/src/sys/netinet/in_gif.c:105
The patch to gif.c does fix it.
I'll try the second patch later when I get a chance.
Thanks,
Vince
On 20/06/2012 13:12, John Baldwin wrote:
On Tuesday, June 19, 2012 8:05:36 pm Vincent Hoffman wrote:
Full dump info at http://unsane.co.uk/crash
It seems to have popped up between r236905 (working kernel) and r237264
(this panic)
the gif config I have in rc.conf is for a HE ipv6 tunnel
Looks like this was broken in r236951 by Randall (cc'd).
I think this would fix it:
Index: if_gif.c
===
--- if_gif.c (revision 237227)
+++ if_gif.c (working copy)
@@ -366,11 +366,12 @@ gif_start(struct ifnet *ifp)
return;
}
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
- GIF_UNLOCK(sc);
keep_going:
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
+ GIF_UNLOCK(sc);
IFQ_DRV_DEQUEUE(ifp-if_snd, m);
+ GIF_LOCK(sc);
if (m == 0)
break;
@@ -424,14 +425,12 @@ keep_going:
ifp-if_oerrors++;
}
- GIF_LOCK(sc);
if (ifp-if_drv_flags IFF_GIF_WANTED) {
/* Someone did a start while
* we were unlocked and processing
* lets clear the flag and try again.
*/
ifp-if_drv_flags = ~IFF_GIF_WANTED;
- GIF_UNLOCK(sc);
goto keep_going;
}
ifp-if_drv_flags = ~IFF_DRV_OACTIVE;
However, unless there is a known LOR, I would be inclined to
just hold the lock across IFQ_DRV_DEQUEUE() and dispense with
all the 'keep_going', etc. logic. Other NIC drivers tend to
just hold their transmit lock for the entire loop in their
start routines.
That would look like this:
Index: if.h
===
--- if.h (revision 237227)
+++ if.h (working copy)
@@ -153,7 +153,6 @@
#define IFF_STATICARP 0x8 /* (n) static ARP */
#define IFF_DYING 0x20/* (n) interface is winding
down */
#define IFF_RENAMING0x40/* (n) interface is being
renamed */
-#define IFF_GIF_WANTED 0x100 /* (n) The gif tunnel is wanted
*/
/*
* Old names for driver flags so that user space tools can continue to use
* the old (portable) names.
Index: if_gif.c
===
--- if_gif.c (revision 237227)
+++ if_gif.c (working copy)
@@ -359,15 +359,7 @@
sc = ifp-if_softc;
GIF_LOCK(sc);
- if (ifp-if_drv_flags IFF_DRV_OACTIVE) {
- /* Already active */
- ifp-if_drv_flags |= IFF_GIF_WANTED;
- GIF_UNLOCK(sc);
- return;
- }
ifp-if_drv_flags |= IFF_DRV_OACTIVE;
- GIF_UNLOCK(sc);
-keep_going:
while (!IFQ_DRV_IS_EMPTY(ifp-if_snd)) {
IFQ_DRV_DEQUEUE(ifp-if_snd, m);
@@ -424,16 +416,6 @@
ifp-if_oerrors++;
}
- GIF_LOCK(sc);
- if (ifp-if_drv_flags IFF_GIF_WANTED) {
- /* Someone did a start while
- * we were unlocked and processing
- * lets clear the flag and try again.
- */
- ifp-if_drv_flags = ~IFF_GIF_WANTED;
- GIF_UNLOCK(sc);
- goto keep_going;
- }
ifp-if_drv_flags = ~IFF_DRV_OACTIVE;
GIF_UNLOCK(sc);
return;
I would prefer this latter patch if it is ok as it makes the code simpler.
Also, IFF_GIF_WANTED as a new iff flag seems really hackish. IFF_* flags
are supposed to be interface independent. A flag like that should be in a
private field in the gif softc, not something exposed to the entire system.
cloned_interfaces=gif0
ifconfig_gif0=tunnel 85.233.185.162 216.66.80.26
ifconfig_gif0_ipv6=inet6 2001:470:1f08:110::2 2001:470:1f08:110::1
prefixlen 128 -accept_rtadv
src.conf only has
WITHOUT_IPFILTER=true
WITHOUT_KERBEROS=true
WITHOUT_PROFILE=yes
Happy to provide any more info as needed. any suggestions welcome, I'll
see if I can track it further with a binary search tomorrow.
From dump info file (at above URL)
#0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:266
266 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:266
#1 0x80314740 in db_dump (dummy=Variable dummy is not available.
)
at /usr/src/sys/ddb/db_command.c:538
#2 0x80313d31 in db_command (last_cmdp=0x80c52b40,
cmd_table=Variable cmd_table is not available.
) at /usr/src/sys/ddb/db_command.c:449
#3 0x80313f80 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:502
#4 0x803160d9 in db_trap (type=Variable type is not available.
) at /usr/src/sys/ddb/db_main.c:231
#5 0x80590918 in kdb_trap (type=3, code=0, tf=0xff80ea22ee20
-CURRENT Panic at boot at Revision: 237264 mutex gif softc not owned at /usr/src/sys/netinet/in_gif.c:105
Full dump info at http://unsane.co.uk/crash
It seems to have popped up between r236905 (working kernel) and r237264
(this panic)
the gif config I have in rc.conf is for a HE ipv6 tunnel
cloned_interfaces=gif0
ifconfig_gif0=tunnel 85.233.185.162 216.66.80.26
ifconfig_gif0_ipv6=inet6 2001:470:1f08:110::2 2001:470:1f08:110::1
prefixlen 128 -accept_rtadv
src.conf only has
WITHOUT_IPFILTER=true
WITHOUT_KERBEROS=true
WITHOUT_PROFILE=yes
Happy to provide any more info as needed. any suggestions welcome, I'll
see if I can track it further with a binary search tomorrow.
From dump info file (at above URL)
#0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:266
266 if (textdump textdump_pending) {
(kgdb) #0 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:266
#1 0x80314740 in db_dump (dummy=Variable dummy is not available.
)
at /usr/src/sys/ddb/db_command.c:538
#2 0x80313d31 in db_command (last_cmdp=0x80c52b40,
cmd_table=Variable cmd_table is not available.
) at /usr/src/sys/ddb/db_command.c:449
#3 0x80313f80 in db_command_loop ()
at /usr/src/sys/ddb/db_command.c:502
#4 0x803160d9 in db_trap (type=Variable type is not available.
) at /usr/src/sys/ddb/db_main.c:231
#5 0x80590918 in kdb_trap (type=3, code=0, tf=0xff80ea22ee20)
at /usr/src/sys/kern/subr_kdb.c:654
#6 0x80815c9d in trap (frame=0xff80ea22ee20)
at /usr/src/sys/amd64/amd64/trap.c:573
#7 0x807ffe63 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#8 0x8059039b in kdb_enter (why=0x808fac8a panic,
msg=0x80 Address 0x80 out of bounds) at cpufunc.h:63
#9 0x805581f1 in panic (fmt=Variable fmt is not available.
)
at /usr/src/sys/kern/kern_shutdown.c:628
#10 0x805454ec in _mtx_assert (m=Variable m is not available.
)
at /usr/src/sys/kern/kern_mutex.c:747
#11 0x8067bcf6 in in_gif_output (ifp=0xfe0005e28000, family=28,
m=0xfe0005ff8300) at /usr/src/sys/netinet/in_gif.c:105
#12 0x8061d6a2 in gif_start (ifp=0xfe0005e28000)
at /usr/src/sys/net/if_gif.c:411
#13 0x8061cbd4 in gif_output (ifp=0xfe0005e28000, m=Variable
m is not available.
)
at /usr/src/sys/net/if_gif.c:540
#14 0x807290c7 in nd6_output_lle (ifp=0xfe0005e28000,
origifp=0xfe0005e28000, m0=0xfe0005ff8300,
dst=0xff80ea22f56c, rt0=Variable rt0 is not available.
) at /usr/src/sys/netinet6/nd6.c:2079
#15 0x807292f8 in nd6_output (ifp=Variable ifp is not available.
)
at /usr/src/sys/netinet6/nd6.c:1824
#16 0x80723171 in ip6_output (m0=Variable m0 is not available.
)
at /usr/src/sys/netinet6/ip6_output.c:1021
#17 0x8072cf9f in nd6_ns_output (ifp=0xfe0005e28000,
daddr6=0x0,
taddr6=0xfe0005300318, ln=Variable ln is not available.
) at /usr/src/sys/netinet6/nd6_nbr.c:593
#18 0x8072d801 in nd6_dad_start (ifa=0xfe0005300200, delay=0)
at /usr/src/sys/netinet6/nd6_nbr.c:1298
#19 0x80710448 in in6_update_ifa (ifp=0xfe0005e28000,
ifra=0xfe00812c8b00, ia=0xfe0005300200, flags=Variable
flags is not available.
)
at /usr/src/sys/netinet6/in6.c:1298
#20 0x80711658 in in6_control (so=0xfe00810c5aa0,
cmd=2156423451,
data=0xfe00812c8b00 gif0, ifp=0xfe0005e28000,
td=0xfe0005009000) at /usr/src/sys/netinet6/in6.c:654
#21 0x806181f6 in ifioctl (so=0xfe00810c5aa0, cmd=2156423451,
data=0xfe00812c8b00 gif0, td=0xfe0005009000)
at /usr/src/sys/net/if.c:2540
#22 0x805aa0dd in kern_ioctl (td=Variable td is not available.
) at file.h:287
#23 0x805aa37d in sys_ioctl (td=0xfe0005009000,
uap=0xff80ea22fb70) at /usr/src/sys/kern/sys_generic.c:691
#24 0x80814a34 in amd64_syscall (td=0xfe0005009000, traced=0)
at subr_syscall.c:135
#25 0x80800147 in Xfast_syscall ()
at /usr/src/sys/amd64/amd64/exception.S:387
#26 0x000801183d0c in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb)
___
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: pf firewall and ftp
On 16/04/2012 03:31, Fbsd8 wrote: OK I have uncovered what the problem is. The pf version running on Freebsd 9.0 matches the version running on openbsd 4.5. Found it on man pf at the end. The documentation on the Openbsd website for pf is for Openbsd 5.0 and it has warning saying NOTE: This information is for OpenBSD 4.7. NAT configuration was significantly different in earlier versions. http://pf4freebsd.love2party.net/ has more info about how back dated the 9.0 Freebsd production version of pf is. The Freebsd handbook had a detailed section on pf including rules examples matching the version of pf included with 9.0 But someone allowed it to be removed in the current version of the handbook. So here we are with an outdated version of pf in the current production 9.0 version of Freebsd and there is no documentation available on nat rule syntax in the handbook or at openbsd/pf. Going to dig through the 9.0 pf man pages for the info http://ftp.nluug.nl/pub/OpenBSD/doc/pf-faq45.txt might be useful? there is a version of the faq for each version of openbsd from 3.3 - 4.7 Vince ___ 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 ___ 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: Idea for GEOM and policy based file encryption
On 21/03/2012 10:47, Andrey V. Elsukov wrote: On 21.03.2012 14:09, Victor Balada Diaz wrote: You would need to modify UFS, or maybe do something like CFS[1]. CFS works as an NFS server and you could modify it to only cipher the needed files. Also you could write a simple FS on FUSE, but last time i checked, our FUSE support had some problems. Yet another link: http://www.arg0.net/encfs or pefs FreeBSD wiki page: http://wiki.freebsd.org/PEFS blog: http://glebkurtsou.blogspot.com/search/label/pefs ___ 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: killed libc.so.7 somehow - help./ISO images of CURRENT
On 15/02/2012 10:33, O. Hartmann wrote: Hello. Accidentally, I managed to kill my libc.so.7 and didn't make a backup. Now my FreeBSD 10/amd64 box, compiled yesterday's world last time, refuses to do anything since login doesn't work. /bin/sh is missing a symbol, I forgot the name, it was late last night (and therefore I made that mistake). I thought I could start over with a snapshot emergency/live DVD/CD, but for CURRENT, I can not find any ISO images. Apart from the CTM way, is there another opportunity toget a) ISO images of a more recent CURRENT b) a working libc.so.7 that will make me rebuilding the system? Have a look at http://pub.allbsd.org/FreeBSD-snapshots/ Daily builds from all branches, the release ISO is a liveCD these days so you should be fine to use that. Vince Sorry for the noise, I'm ashamed about to ask and yes, I will bare the laugh. Oliver ___ 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: Removal of sysinstall from HEAD and lack of a post-install configuration tool
On 28/12/2011 06:30, Doug Barton wrote: On 12/27/2011 22:08, Adrian Chadd wrote: Hi, Why not just list the things that sysinstall did that people like, and extract out / reimplement those bits? That's sounds great. As soon as that's done, we can remove sysinstall from the base. Until those things exist, removing it is premature. In that case can I suggest a wiki page or other viewable/editable list of desirable features from sysinstall? I only used it for the basic disklayout and component install so I'm not in a position to start it off or I would. Vince ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 23/12/2011 02:56, Garrett Cooper wrote: On Dec 22, 2011, at 3:58 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Fri, Dec 23, 2011 at 12:44:14AM +0100, O. Hartmann wrote: On 12/21/11 19:41, Alexander Leidinger wrote: Hi, while the discussion continued here, some work started at some other place. Now... in case someone here is willing to help instead of talking, feel free to go to http://wiki.freebsd.org/BenchmarkAdvice and have a look what can be improved. The page is far from perfect and needs some additional people which are willing to improve it. This is only part of the problem. A tuning page in the wiki - which could be referenced from the benchmark page - would be great too. Any volunteers? A first step would be to take he tuning-man-page and wikify it. Other tuning sources are welcome too. Every FreeBSD dev with a wiki account can hand out write access to the wiki. The benchmark page gives contributor-access. If someone wants write access create a FirstnameLastname account and ask here for contributor-access. Don't worry if you think your english is not good enough, even some one-word notes can help (and _my_ english got already corrected by other people on the benchmark page). Bye, Alexander. Nice to see movement ;-) But there seems something unclear: man make.conf(5) says, that MALLOC_PRODUCTION is a knob set in /etc/make.conf. The WiJi says, MALLOC_PRODUCTION is to be set in /etc/src.conf. What's right and what's wrong now? I can say with certainty that this value belongs in /etc/make.conf (on RELENG_8 and earlier at least). src/share/mk/bsd.own.mk has no framework for MK_MALLOC_PRODUCTION, so, this is definitely a make.conf variable. Take the advice in tuning(7) with a grain of salt because a number of suggestions are really outdated. I know because I filed a PR last night after I saw how out of synch some of the defaults it claimed were with reality on 9.x+. And I know other suggestions in the manpage are dated as well ;/. There is a wiki page http://wiki.freebsd.org/SystemTuning which is currently more or less tuning(7) with some annotations, the idea being to sort out whats outdated/invalid with an aim of rewriting tuning(7) to be more accurate and useful. I'll grab any info in your pr thats not up there already to keep it updated if thats ok. Vince Thanks, -Garrett___ 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 ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 23/12/2011 20:23, Garrett Cooper wrote: On Fri, Dec 23, 2011 at 2:38 AM, Vincent Hoffman vi...@unsane.co.uk wrote: On 23/12/2011 02:56, Garrett Cooper wrote: snip There is a wiki page http://wiki.freebsd.org/SystemTuning which is currently more or less tuning(7) with some annotations, the idea being to sort out whats outdated/invalid with an aim of rewriting tuning(7) to be more accurate and useful. I'll grab any info in your pr thats not up there already to keep it updated if thats ok. Sure. Please take my suggestions (apart from the networking sysctls) with a grain of salt as I didn't look at the sourcecode for the filesystem ones (I was going off the top of my head and other emails I had seen passed around). I'll update the tuning 'wiki' with mention of the new networking defaults. If we want to make this manpage 'timeless', should we remove mention of defaults and go off basic guidelines (if you set this higher, you'll get better performance in scenario, X.Y.Z, etc)? Thanks! -Garrett Good point, for tuning the defaults are probably not so important as they are likely to change at some point (as the current man page will attest) so maybe its less important to document them. Happy Christmas (or holiday of your choice ;) to you all and I hope everyone has a good new year. Vince ___ 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 ___ 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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On 20/12/2011 10:39, Daniel Kalchev wrote: On 20.12.11 11:42, Garrett Cooper wrote: As long as I have reliable checksums that match the what the upstream source says is the real thing, it doesn't practically matter where I get my images from. Relying on checksums that are published on the same web site where you download the files from and given that most of these sites do not even use SSL so much about 'security'. This does remind me of one issue that while a little off topic for this thread If i wanted to get, for example the SHA265 checksums from a verified source, how would i verify this currently? There doesnt seem to be an SSL site for www.freebsd.org and its not too hard to redirect someone to a fake website. What would be a more reasonable list to request this on? Vince Daniel ___ 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 ___ 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: SCHED_ULE should not be the default
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/12/2011 13:47, O. Hartmann wrote: Not fully right, boinc defaults to run on idprio 31 so this isn't an issue. And yes, there are cases where SCHED_ULE shows much better performance then SCHED_4BSD. [...] Do we have any proof at hand for such cases where SCHED_ULE performs much better than SCHED_4BSD? Whenever the subject comes up, it is mentioned, that SCHED_ULE has better performance on boxes with a ncpu 2. But in the end I see here contradictionary statements. People complain about poor performance (especially in scientific environments), and other give contra not being the case. It all a little old now but some if the stuff in http://people.freebsd.org/~kris/scaling/ covers improvements that were seen. http://jeffr-tech.livejournal.com/5705.html shows a little too, reading though Jeffs blog is worth it as it has some interesting stuff on SHED_ULE. I thought there were some more benchmarks floating round but cant find any with a quick google. Vince Within our department, we developed a highly scalable code for planetary science purposes on imagery. It utilizes present GPUs via OpenCL if present. Otherwise it grabs as many cores as it can. By the end of this year I'll get a new desktop box based on Intels new Sandy Bridge-E architecture with plenty of memory. If the colleague who developed the code is willing performing some benchmarks on the same hardware platform, we'll benchmark bot FreeBSD 9.0/10.0 and the most recent Suse. For FreeBSD I intent also to look for performance with both different schedulers available. O. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO5hn7AAoJEF4mgOY1fXowOLAP/2EjhAFPb88NgKM0ieBb4X7R NSw/9HTiwcshkfEdvYjAzYZ0cUWetEuRfnPVnh+abwfJEmMzZkwA0KIz8UYGHHik 22Z2SWSVDiwZAluz0ca7Xc931ojbzrK/zVMbivqW3cvnz8P4oEnASiENnsoa89Jy Oskjd4QpAyIpB/AsYgc9FLT3kPX13fXC5bzw/zAPDsaupOYssRRlZu8nnqsEc1i1 IanLIPKLnIbpZTx75ehWxxRW8IjiQRvIe+7eBaDMhXO/Kvftotf0JzknrBnJezDQ ZdhiOTq7F1Pm3dxra+DNKD+Dw+xUCYPFq/kuyqrZNz44H3qwT60vDhvw0yDz6422 nNP11z2+G4M85sahBak5AmSHuyek7HWb6uIHHnfvwNKSX4ZsdS8MVBViNJjmCYtL PwuHDU3WdCes/vvKRNDopSp/s6RSLK9w3RT7jlMkaTu2Mmtw0BwGziDJ2pGaCQ14 68R5eO/SfNxoVp0g4lIzObyQR+//0OmALzElVK3VmHM9NoL3qZGCwBRLqjN5re82 dX6nsBr/DFJOpaFfdFLwPNyCNdNpg/WVegRkq2BEL/BaMISNiKzoVbM0Psh9gnb3 LW1j3LP2fOHhuN1bW3S31JmbNzvAnlRNynoNMldrwj5PWJY2HPk+mMFRjmRwdDTJ 9mhscz8++WRPvDZQXefl =XqaR -END PGP SIGNATURE- ___ 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: Upgrade from source to RC1: problems with /etc : lost users and dbus
On 27/10/2011 11:22, Thomas Mueller wrote: I just finished the upgrade from source from 9.0-BETA2 to RC1, and I find two problems. First, I lost my users; nonroot user names are not recognized, if for instance I type passwd arlene I already tried to login as arlene with old password, no good. I copied the /etc directory to a backup on another disk cp -Rp /etc /media/etcbackup-BETA2 and then copied back /media/etcbackup-BETA2/passwd (and group) to /etc but that didn't help. Other people have suggested what you have done to loose them. To get them back you need /etc/passwd /etc/master.passwd possibly /etc/group There should be a handy backup in /var/backups Also you will need to remake the db files, see man pwd_mkdb Vince Do I have to recreate nonroot users from scratch? Also, I got a warning about DBUS not starting. When I tried to startx as root, I got into X, but mouse and keyboard were nonfunctional; I did type Ctrl-Alt-F1 and Ctrl-C to get out of X. I think it was the second mergemaster part. Should I, as root and X not running, do mv /etc /etcbackup-RC1 and cp -Rp /media/etcbackup-BETA2 /etc where /media would be mount point for backup partition on USB 3.0 hard drive? The second invocation of mergemaster (after booting single-user) can wreak havoc on /etc . As I type this, I am in my older installation of FreeBSD 9.0-BETA1 but have access to RC1 partition. By the way, /etc/rc.conf remained intact, showing that hald_enable and dbus_enable are still there: hostname=amelia2 keymap=us.iso.kbd ifconfig_re0=DHCP ifconfig_re0_ipv6=inet6 accept_rtadv sshd_enable=YES moused_enable=YES ntpd_enable=YES hald_enable=YES dbus_enable=YES Tom ___ 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 ___ 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: 3 show-stopper issues with 9-BETA3
On 14/10/2011 19:58, Gavin Atkinson wrote: 3. PF doesn't expire state. The state table on my older host (pre OpenBSD-4.5) has the following stats: Status: Enabled for 0 days 00:37:17 Debug: Urgent State Table Total Rate current entries 169546 searches9438745142193.8/s inserts 4012389 1793.6/s removals 3842843 1717.9/s The 9-BETA3 host's current entries exactly match the number of inserts until it hits the hard limit of 1.5M entries and can add no more. It takes about 10 minutes to fill up and then no new flows are routed. I've seen a few reports of this, and it's quite concerning. Please, can you submit this as a PR? For tracking, this was a previous report with apparently a temporary workaround. http://lists.freebsd.org/pipermail/freebsd-pf/2011-October/006333.html I have a stable-9 virtual machine i can test on if needed but I have pf loaded as a module at the moment so dont have the issue. Vince ___ 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: issue with old linuxbase.
On 10/09/2011 18:06, Boris Samorodov wrote: On Sat, 10 Sep 2011 12:33:37 +0100 Veniamin Gvozdikov wrote: I've tried porting a few programs from Linux which's used a linuxulator. But I have the problem with old linux base system. My ports can't be run with old libstdc++.so.6 I have error with run linux apps. /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found strings /compat/linux/usr/lib/libstdc++.so.6|grep GLIBCXX GLIBCXX_3.4 GLIBCXX_3.4.1 GLIBCXX_3.4.2 GLIBCXX_3.4.3 GLIBCXX_3.4.4 GLIBCXX_3.4.5 GLIBCXX_3.4.6 GLIBCXX_3.4.7 GLIBCXX_3.4.8 GLIBCXX_3.4.9 GLIBCXX_3.4.10 GLIBCXX_FORCE_NEW GLIBCXX_DEBUG_MESSAGE_LENGTH How to fix it You may try to replace libstdc++ package from the base port by the one from Fedora 11. But the result is unknown. FreeBSD-emulation is a better place to speak about the matter. or when'll upgraded linux base system? When somebody do the actual work. http://www.leidinger.net/blog/2011/08/29/howto-create-a-new-linux_base-port/ and http://www.leidinger.net/blog/2011/09/01/howto-add-linux-infrastructure-ports-for-a-new-linux_base-port/ Look useful here. If I actually used the linuxulator I'd probably have had a stab but its not something i have used for longer than I can think. ___ 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: Where did the 9.0 BETA1 images go?
On 06/09/2011 09:44, Kurt Jaeger wrote: Hi! But sadly they seem to be gone from the FTP servers. The system has beside its harddisks only a floppy drive (no space for a CD-ROM) so I would need the memstick image Any idea where I could get FreeBSD-9.0-BETA1-amd64-memstick.img from? There is BETA2 at ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/ISO-IMAGES/9.0/FreeBSD-9.0-BETA2-amd64-memstick.img but I think this directory name (amd64/amd64) is a mishap. Is it ? I believe that its been changed due to the introduction of platforms where uname -m and uname -p arent the same. To do with the new installer I imagine. Vince ___ 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: 9.0-BETA1 installer issues
On 06/08/2011 17:05, Vincent Hoffman wrote:
On 06/08/2011 15:48, Nathan Whitehorn wrote:
On 08/05/11 10:58, Lars Engels wrote:
On Wed, Aug 03, 2011 at 09:03:22PM +0200, Marc Fonvieille wrote:
On Wed, Aug 03, 2011 at 08:28:34PM +0200, Marc Fonvieille wrote:
[...]
Hmm I think it's default PACKAGESITE env variable pointing on
non-existing
ftp://ftp.freebsd.org/pub/FreeBSD/ports/arch/packages-9-beta1/Latest/
I'm wrong, I did an install and same behavior as Bruce.
I looked in /tmp/bsdinstall_log:
Running installation step: docsintall
pkg_add: unable to fetch
'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/en-freebsd-doc.tbz'
by URL
^^
I haven't looked at bsdinstall lately, but IIRC there's no dialog that
offers a mirror selection? It would be nice to select a nearby server.
For the regular distfiles (base, kernel, etc.) you can pick a mirror,
but installing packages (e.g. documentation) relies on the behavior of
pkg_add -r.
-Nathan
So it should be doable by using the PACKAGEROOT env variable?
Had 10 minutes and did a quick POC patch to have the PACKAGEROOT env
variable set from the mirror selected at the mirrorselect stage.
I'm not claiming it will do more than work for me or that its well
written but just in case anyone is interested in improving/reimplementing.
patch is attached.
Vince
___
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
___
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
Index: scripts/docsinstall
===
--- scripts/docsinstall (revision 224732)
+++ scripts/docsinstall (working copy)
@@ -28,6 +28,7 @@
exec 31
+[ ! -z $1 ] export PACKAGEROOT=$1
DOCS=$(dialog --backtitle FreeBSD Installer \
--title FreeBSD Documentation Installation --separate-output \
--checklist This menu will allow you to install the whole documentation
set
Index: scripts/auto
===
--- scripts/auto(revision 224732)
+++ scripts/auto(working copy)
@@ -83,13 +83,16 @@
if [ -n $FETCH_DISTRIBUTIONS ]; then
exec 31
- BSDINSTALL_DISTSITE=$(`dirname $0`/mirrorselect 21 13)
+ BSDINSTALL_DISTSITES=$(`dirname $0`/mirrorselect 21 13)
MIRROR_BUTTON=$?
exec 3-
test $MIRROR_BUTTON -eq 0 || error
+ BSDINSTALL_DISTSITE=${BSDINSTALL_DISTSITES#* }
+ PKG_MIRROR=${BSDINSTALL_DISTSITES% *}
export BSDINSTALL_DISTSITE
+ export PKG_MIRROR
+
fi
-
rm $PATH_FSTAB
touch $PATH_FSTAB
@@ -197,7 +200,7 @@
finalconfig
;;
Handbook)
- bsdinstall docsinstall
+ bsdinstall docsinstall $PKG_MIRROR
finalconfig
;;
Shell)
Index: scripts/mirrorselect
===
--- scripts/mirrorselect(revision 224732)
+++ scripts/mirrorselect(working copy)
@@ -212,4 +212,4 @@
esac
export BSDINSTALL_DISTSITE
-echo $BSDINSTALL_DISTSITE 2
+echo $BSDINSTALL_DISTSITE $MIRROR2
___
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: 9.0-BETA1 installer issues
On 06/08/2011 15:48, Nathan Whitehorn wrote: On 08/05/11 10:58, Lars Engels wrote: On Wed, Aug 03, 2011 at 09:03:22PM +0200, Marc Fonvieille wrote: On Wed, Aug 03, 2011 at 08:28:34PM +0200, Marc Fonvieille wrote: On Tue, Aug 02, 2011 at 08:36:01AM -0500, Nathan Whitehorn wrote: On 08/02/11 04:41, Bruce Cran wrote: I've been trying out 9.0-BETA1: it's a lot easier to install than previous releases with bsdinstall, but I spotted a few issues: Good! Thanks for checking. Typo - Resovler Configuration. If I leave the resolver window for a while it gets corrupted with: Aug 2 10:31:23 dhclient[973]: Bogus domain search list 15: lan, . Interesting. It looks like DHCP doesn't like your local setup... In the documentation installation screen, it should say At a minimum... - the 'a' is missing. Also, there should perhaps be a semi-colon between English version and this is the original. The menu also doesn't appear to do anything once you select OK. The spelling fixes are easy to fix. The documentation issue is more confusing. It should begin running pkg_add, after you press OK, assuming you selected something. Do you have the installer log handy? It will be in /tmp. [...] Hmm I think it's default PACKAGESITE env variable pointing on non-existing ftp://ftp.freebsd.org/pub/FreeBSD/ports/arch/packages-9-beta1/Latest/ I'm wrong, I did an install and same behavior as Bruce. I looked in /tmp/bsdinstall_log: Running installation step: docsintall pkg_add: unable to fetch 'ftp://ftp.freebsd.org/pub/FreeBSD/ports/amd64/packages-9-current/Latest/en-freebsd-doc.tbz' by URL ^^ I haven't looked at bsdinstall lately, but IIRC there's no dialog that offers a mirror selection? It would be nice to select a nearby server. For the regular distfiles (base, kernel, etc.) you can pick a mirror, but installing packages (e.g. documentation) relies on the behavior of pkg_add -r. -Nathan So it should be doable by using the PACKAGEROOT env variable? ___ 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 ___ 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: Request for review/testing: switching the default installer
On 04/03/2011 20:24, Freddie Cash wrote: On Mon, Feb 28, 2011 at 6:49 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: BSDinstall has acquired at this point its final form (prior to a future merge with pc-sysinstall), and I believe is ready to replace sysinstall on the 9.0 snapshot ISOs. Barring any objections, I would like to pull this switch 2 weeks from today, on the 14th of March. A patch to the release infrastructure code can be found here (make release must be run with Makefile.bsdinstall using this patch to get non-sysinstall media): http://people.freebsd.org/~nwhitehorn/bsdinstall-release.diff Test ISOs for amd64 and i386 can be found here: http://people.freebsd.org/~nwhitehorn/bsdinstall-amd64-20110222.iso.bz2 http://people.freebsd.org/~nwhitehorn/bsdinstall-i386-20110224.iso.bz2 More recent test ISOs, as well as ones for other architectures, may be available at: http://wiki.freebsd.org/BSDInstall Any chance of a memstick.img version being made available? Or, does anyone have instructions on how to convert the ISO images into memstick images? Preferably using a Linux station, not a FreeBSD station. I have a beautiful 24-drive system here just crying out for testing 9-CURRENT and ZFSv28, but it doesn't have any bootable media except USB sticks. And the 2011-01-* memstick snapshot of 9-CURRENT fails with can't create device node in /dev errors when trying to newfs the CompactFlash disk that will be /. Its always worth having a go with the images from http://pub.allbsd.org/FreeBSD-snapshots http://pub.allbsd.org/FreeBSD-snapshots/amd64-amd64/9.0-HEAD-20110304-JPSNAP/cdrom/FreeBSD-9.0-HEAD-20110304-JPSNAP-amd64-amd64-memstick.img for example. Vince ___ 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: TTY task group scheduling
On 19/11/2010 12:42, Eric Masson wrote: Bruce Cran br...@cran.org.uk writes: Hello, Google suggests that the work was a GSoC project in 2005 on a pluggable disk scheduler. It seems that something similar has found its way in DFlyBSD, dsched. And indeed to FreeBSD, man gsched. Added sometime round April http://svn.freebsd.org/viewvc/base/head/sys/geom/sched/README?view=log Vince Éric Masson ___ 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: Fixing and importing the fusefs kernel module - any VFS-savvy takers?
On 28/10/2010 12:49, Ivan Voras wrote: Hello, snip much Basically, this is a call for help in working on fusefs. There are several developers and users willing to do testing and such but no available developers with their hands in the guts of VFS to squash the buried bugs. Fusefs might be especially relevant to desktop users and as such to PC-BSD developers, so I'm cc-ing Kris in case he has a comment. Is anyone interested? Would it not make more sense to take the work done here: http://wiki.freebsd.org/SOC2009TatsianaSeveryna forward? (not volunteering, just wondering what with the licensing and all.) Vince References: http://permalink.gmane.org/gmane.os.freebsd.architechture/13623 http://fuse.sourceforge.net/ http://fuse4bsd.creo.hu/ http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/fusefs-kmod/ http://old.nabble.com/forum/Search.jtp?forum=6572local=yquery=fusefs http://old.nabble.com/forum/Search.jtp?forum=6610local=yquery=fusefs ___ 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 ___ 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: iSCSI boot driver version 0.1.1 for iBFT
On 25/06/2010 17:32, Daisuke Aoyama wrote: Sorry, isboot-0.1.1 was broken under i386 kernel + loader. The version 0.1.2 is uploaded in my blog. Also I uploaded isboot integrated FreeBSD 7.3 disc1, 8.1-RC1 dics1 and making script. Use at your own risk. You need only iBFT supported NIC and iSCSI target. Since I dont have a supported nic, would the iscsi support in gpxe (http://etherboot.org/wiki/iscsiboot) be enough? (might give it a try if i get time after the weekend.) Vince Please see Intel's site about iBFT supported NIC. http://www.intel.com/support/network/adapter/pro100/sb/CS-028681.htm If you can connect to iSCSI target by NIC BIOS, isboot.ko shows the following log. In this case, em0 is configured automatically with NIC0 parameter in iBFT, and you can install FreeBSD to da1 directly and you can boot from da1. If you want to try to copy existing FreeBSD, then configure NIC and loading isboot.ko via loader.conf or kldload isboot.ko from shell. Then, use normal way such as dump/restore. Note: do not set IP to em0 when installation. it might be a problem. --- iSCSI boot driver version 0.1.2 IS: Initiator name: iqn.2007-09.jp.ne.peach:pluto NIC0: IP address: 192.168.3.48 NIC0: Prefix: 24 NIC0: Gateway: 0.0.0.0 NIC0: MAC address: 00:15:17:97:85:ab TGT0: Target IP address: 192.168.3.36 TGT0: Target Port: 3260 TGT0: Target LUN: 2 TGT0: Target name: iqn.2007-09.jp.ne.peach:isboot1 Boot NIC: em0 Configure IPv4 by NIC0 Attempting to login to iSCSI target and scan all LUNs. ... cut ... da0 at isboot0 bus 0 scbus0 target 0 lun 0 da0: FreeBSD iSCSI DISK 0001 Fixed Direct Access SCSI-5 device da0: 40960MB (83886080 512 byte sectors: 255H 63S/T 5221C) da1 at isboot0 bus 0 scbus0 target 0 lun 2 da1: FreeBSD iSCSI DISK 0001 Fixed Direct Access SCSI-5 device da1: 10240MB (20971520 512 byte sectors: 255H 63S/T 1305C) da2 at isboot0 bus 0 scbus0 target 0 lun 3 da2: FreeBSD iSCSI DISK 0001 Fixed Direct Access SCSI-5 device da2: 1024MB (2097152 512 byte sectors: 64H 32S/T 1024C) ... cut ... Boot device: da1 --- Download links: http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-7.3-RELEASE-amd64-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-7.3-RELEASE-i386-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-8.1-RC1-amd64-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/FreeBSD-8.1-RC1-i386-isboot-0.1.2.iso http://www.peach.ne.jp/archives/isboot/demo/unionfs-mkisboot.sh Try it you self :) Daisuke Aoyama ___ 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 ___ 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
