Re: how to browse svnweb source?

[Vincent Hoffman-Kazlauskas]

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&project=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

[Vincent Hoffman]

On 09/09/2014 17:56, John Nielsen wrote:
> On Sep 8, 2014, at 7:21 AM, Anders Bolt Evensen  wrote:
>
>> On 05.09.14 19:37, John Nielsen wrote:
>>> On Sep 5, 2014, at 11:30 AM, Glen Barber  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%2F&ts=1410181876&use_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@

Re: [rfc] removing the NDISulator

[Vincent Hoffman]

On 23/10/2013 18:35, Eitan Adler wrote:
> On Mon, Oct 21, 2013 at 6:29 PM, Adrian Chadd  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 , Server 2003
, 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

[Vincent Hoffman]

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  wrote:
>
>> /div>> class="utdU2e">> id=":2il" tabindex="-1">test>
>>
>>
>> On Tue, Oct 8, 2013 at 9:29 AM, Alexander Panyushkin wrote:
>>
>>> test
>>> __**_
>>> freebsd-current@freebsd.org mailing list
>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@**
>>> 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

[Vincent Hoffman]

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"

Re: Panic/Freeze with IPSEC on r254532

[Vincent Hoffman]

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 =
>> 

Panic/Freeze with IPSEC on r254532

[Vincent Hoffman]

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
ipsec4_process_packet+

Re: daily otput: rejected mail hosts?

[Vincent Hoffman]

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

[Vincent Hoffman]

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 2>&1 | 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

[Vincent Hoffman]

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?

[Vincent Hoffman]

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

[Vincent Hoffman]

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

[Vincent Hoffman]

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

[Vincent Hoffman]

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

[Vincent Hoffman]

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

[Vincent Hoffman]

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

[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)


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

[Vincent Hoffman]

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

[Vincent Hoffman]

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

[Vincent Hoffman]

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

[Vincent Hoffman]

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"

Occassional "permission denied" in the middle of a large transfer over NFS

[Vincent Hoffman]

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"

[Vincent Hoffman]

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"

Re: -CURRENT Panic at boot at Revision: 237264 "mutex gif softc not owned at /usr/src/sys/netinet/in_gif.c:105"

[Vincent Hoffman]

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

Re: -CURRENT Panic at boot at Revision: 237264 "mutex gif softc not owned at /usr/src/sys/netinet/in_gif.c:105"

[Vincent Hoffman]

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 inf

-CURRENT Panic at boot at Revision: 237264 "mutex gif softc not owned at /usr/src/sys/netinet/in_gif.c:105"

[Vincent Hoffman]

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 ) 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

[Vincent Hoffman]

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

[Vincent Hoffman]

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

[Vincent Hoffman]

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

[Vincent Hoffman]

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

[Vincent Hoffman]

On 23/12/2011 20:23, Garrett Cooper wrote:
> On Fri, Dec 23, 2011 at 2:38 AM, Vincent Hoffman  wrote:
>> On 23/12/2011 02:56, Garrett Cooper wrote:

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

[Vincent Hoffman]

On 23/12/2011 02:56, Garrett Cooper wrote:
> On Dec 22, 2011, at 3:58 PM, Jeremy Chadwick  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

[Vincent Hoffman]

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

[Vincent Hoffman]

-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

[Vincent Hoffman]

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

[Vincent Hoffman]

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.

[Vincent Hoffman]

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?

[Vincent Hoffman]

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

[Vincent Hoffman]

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//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 3>&1
+[ ! -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 3>&1
-   BSDINSTALL_DISTSITE=$(`dirname $0`/mirrorselect 2>&1 1>&3)
+   BSDINSTALL_DISTSITES=$(`dirname $0`/mirrorselect 2>&1 1>&3)
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 $MIRROR>&2
___
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

[Vincent Hoffman]

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//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

[Vincent Hoffman]

On 04/03/2011 20:24, Freddie Cash wrote:
> On Mon, Feb 28, 2011 at 6:49 AM, Nathan Whitehorn
>  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

[Vincent Hoffman]

On 19/11/2010 12:42, Eric Masson wrote:
> Bruce Cran  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?

[Vincent Hoffman]

On 28/10/2010 12:49, Ivan Voras wrote:
> Hello,
>

> 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=6572&local=y&query=fusefs
> http://old.nabble.com/forum/Search.jtp?forum=6610&local=y&query=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

[Vincent Hoffman]

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