Re: VirtualBox, AIO and zvol's - a cautionary tale
Can you please file a PR? Having broken AIO and ZFS would be .. bad. OK: http://www.freebsd.org/cgi/query-pr.cgi?pr=168298 I thought it was most likely a bug in VirtualBox to be honest - broken AIO and ZFS would be bad, but also highly noticeable in other configurations, and this only seems to affect VBox. cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
gdb coredump on 9-STABLE
Script started on Thu May 24 19:25:44 2012 op has logged on :0 from local. root has logged on ttyv1 from local. ESC[1mopESC[m@ESC[4mopnESC[24m ~ gdb sleep ^M GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... (gdb) run 100 Starting program: /bin/sleep 100 (no debugging symbols found)...(no debugging symbols found)...^C Program received signal SIGINT, Interrupt. 0x0008012211fc in nanosleep () from /lib/libc.so.7 (gdb) q The program is running. Exit anyway? (y or n) a Please answer y or n. Segmentation fault (core dumped) ESC[1mopESC[m@ESC[4mopnESC[24m ~ exit Script done on Thu May 24 19:26:11 2012 op@opn ~ gdb gdb gdb.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... Core was generated by `gdb'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libreadline.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libreadline.so.8 Reading symbols from /lib/libncurses.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /usr/lib/libgnuregex.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgnuregex.so.5 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/lib/libthread_db.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libthread_db.so Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000800d26887 in strlen () from /lib/libc.so.7 (gdb) bt full #0 0x000800d26887 in strlen () from /lib/libc.so.7 No symbol table info available. #1 0x000800d1f662 in open () from /lib/libc.so.7 No symbol table info available. #2 0x000800cd0af4 in vasprintf () from /lib/libc.so.7 No symbol table info available. #3 0x00486fe9 in xvasprintf () No symbol table info available. #4 0x004884c3 in warning () No symbol table info available. #5 0x00488d0b in query () No symbol table info available. #6 0x004953bb in quit_confirm () No symbol table info available. #7 0x00466018 in quit_command () No symbol table info available. #8 0x004960f5 in execute_command () No symbol table info available. #9 0x00452b63 in push_prompt () No symbol table info available. #10 0x00453797 in display_gdb_prompt () No symbol table info available. #11 0x00080d26ff87 in rl_callback_read_char () from /lib/libreadline.so.8 No symbol table info available. #12 0x00452d29 in push_prompt () No symbol table info available. #13 0x00453d9f in delete_async_signal_handler () No symbol table info available. #14 0x00454686 in gdb_do_one_event () No symbol table info available. #15 0x0049665e in throw_exception () No symbol table info available. #16 0x004966b3 in catch_errors () No symbol table info available. #17 0x0052ddba in _initialize_tui_interp () No symbol table info available. #18 0x00439869 in gdb_main () No symbol table info available. #19 0x0049665e in throw_exception () No symbol table info available. #20 0x004966b3 in catch_errors () No symbol table info available. ---Type return to continue, or q return to quit--- #21 0x0043924d in gdb_main () No symbol table info available. #22 0x0049665e in throw_exception () No symbol table info available. #23 0x004966b3 in catch_errors () No symbol table info available. #24 0x00438bc4 in gdb_main () No symbol table info available. #25 0x00438b96 in main () No symbol table info available. (gdb) q -- FreeBSD opn 9.0-STABLE FreeBSD 9.0-STABLE #59 r235633+a40b20b: Sat May 19 16:23:04 CEST 2012 root@opn:/usr/obj/usr/src/sys/stable amd64 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ports devel/tkcvs
Probably doing something wrong, but when I install tkcvs to get tkdiff on my box, the only thing it does is fire up and display a wish window. Did I do it wrong? :-) sean pkg_info |grep ^tk tk-8.5.11 Graphical toolkit for Tcl tk-wrapper-1.1_1Shell wrapper for wish (Tk) tkcvs-8.2.3 Tcl/Tk frontends to CVS and Subversion tkdiff-4.2 A Tk frontend for diff(1) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Jail startup/shutdown broken on latest 9-STABLE
Hello, Latest 9-STABLE has introduced some changes that break the ezjail rc script. On bootup it fails to start, but when i log in via ssh and manually start it, it works. However i am unable to shut them down afterwards. root@jail.local:~# uname -a FreeBSD jail.local 9.0-STABLE FreeBSD 9.0-STABLE #0: Thu May 24 12:50:04 EDT 2012 root@jail.local:/usr/obj/usr/src/sys/JAIL amd64 Boot: ezJailConfiguring jails:. Starting jails: cannot start jail game: -1 cannot start jail app: -1 /var/log/messages: May 24 15:05:30 jail kernel: pid 1276 (jail), uid 0: exited on signal 11 May 24 15:05:30 jail kernel: pid 1343 (jail), uid 0: exited on signal 11 root@jail.local:~# jls JID IP Address Hostname Path root@jail.local:~# /usr/local/etc/rc.d/ezjail start ezjailConfiguring jails:. Starting jails: game.local app.local. (notice that jails start at #3) root@jail.local:~# jls JID IP Address Hostname Path 3 10.57.227.100 game.local/jails/game 4 10.57.227.99app.local /jails/app (can not stop jails now) root@jail.local:~# /usr/local/etc/rc.d/ezjail stop ezjailStopping jails: app.local game.local. root@jail.local:~# jls JID IP Address Hostname Path 3 10.57.227.100 game.local/jails/game 4 10.57.227.99app.local /jails/app root@jail.local:~# /usr/local/etc/rc.d/ezjail stop ezjailStopping jails: cannot stop jail app. No jail id in /var/run cannot stop jail game. No jail id in /var/run (same behaviour occurs when i use the base /etc/rc.d script to start/stop the jails) Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
bash 4.2 patchlevel 28
Noted that the following syntax is broken somewhere between 4.2 patchlevel 10 and 28. I'm sure its because we shouldn't be doing that over here at big purple, but we do ... and its a PITA. I'm bisecting to find out what is going on. test: VARIABLE=$(uname) bash: command substitution: line 3: syntax error near unexpected token `)' bash: command substitution: line 3: `uname)' Odd, but his works at patchlevel 10 sean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bash 4.2 patchlevel 28
On Thu, 2012-05-24 at 13:07 -0700, Sean Bruno wrote: Noted that the following syntax is broken somewhere between 4.2 patchlevel 10 and 28. I'm sure its because we shouldn't be doing that over here at big purple, but we do ... and its a PITA. I'm bisecting to find out what is going on. test: VARIABLE=$(uname) bash: command substitution: line 3: syntax error near unexpected token `)' bash: command substitution: line 3: `uname)' Odd, but his works at patchlevel 10 sean At least that was easy. It's patch level 12. Sequential sort pays dividends today. Sean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bash 4.2 patchlevel 28
On Thu, 2012-05-24 at 13:14 -0700, Sean Bruno wrote: On Thu, 2012-05-24 at 13:07 -0700, Sean Bruno wrote: Noted that the following syntax is broken somewhere between 4.2 patchlevel 10 and 28. I'm sure its because we shouldn't be doing that over here at big purple, but we do ... and its a PITA. I'm bisecting to find out what is going on. test: VARIABLE=$(uname) bash: command substitution: line 3: syntax error near unexpected token `)' bash: command substitution: line 3: `uname)' Odd, but his works at patchlevel 10 sean At least that was easy. It's patch level 12. Sequential sort pays dividends today. Sean Hrm ... and it also appears that if I use bison + m4 I don't have this issue, but if I let the configure scripts use /usr/bin/yacc alone this problem manifests itself. odd. sean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jail startup/shutdown broken on latest 9-STABLE
On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote: Hello, Latest 9-STABLE has introduced some changes that break the ezjail rc script. On bootup it fails to start, but when i log in via ssh and manually start it, it works. However i am unable to shut them down afterwards. root@jail.local:~# uname -a FreeBSD jail.local 9.0-STABLE FreeBSD 9.0-STABLE #0: Thu May 24 12:50:04 EDT 2012 root@jail.local:/usr/obj/usr/src/sys/JAIL amd64 Boot: ezJailConfiguring jails:. Starting jails: cannot start jail game: -1 cannot start jail app: -1 /var/log/messages: May 24 15:05:30 jail kernel: pid 1276 (jail), uid 0: exited on signal 11 May 24 15:05:30 jail kernel: pid 1343 (jail), uid 0: exited on signal 11 [..] root@jail.local:~# jls JID IP Address Hostname Path 3 10.57.227.100 game.local/jails/game 4 10.57.227.99app.local /jails/app (can not stop jails now) root@jail.local:~# /usr/local/etc/rc.d/ezjail stop ezjailStopping jails: app.local game.local. root@jail.local:~# jls JID IP Address Hostname Path 3 10.57.227.100 game.local/jails/game 4 10.57.227.99app.local /jails/app root@jail.local:~# /usr/local/etc/rc.d/ezjail stop ezjailStopping jails: cannot stop jail app. No jail id in /var/run cannot stop jail game. No jail id in /var/run (same behaviour occurs when i use the base /etc/rc.d script to start/stop the jails) Try this: http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch cd /usr/src patch -p1 patch cd usr.sbin/jail make make install /usr/src/etc/rc.d/jail script can be just copied over. Note that your /var/run/jail_* files have broken content (some line from /etc/rc's output instead of jail id). -- Mateusz Guzik mjguzik gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jail startup/shutdown broken on latest 9-STABLE
On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote: On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote: Hello, Latest 9-STABLE has introduced some changes that break the ezjail rc script. On bootup it fails to start, but when i log in via ssh and manually start it, it works. However i am unable to shut them down afterwards. Try this: http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch cd /usr/src patch -p1 patch cd usr.sbin/jail make make install /usr/src/etc/rc.d/jail script can be just copied over. Note that your /var/run/jail_* files have broken content (some line from /etc/rc's output instead of jail id). Mateusz, Thanks for the patch, it fixes the startup issue on boot, however shutting down the jails still does not work. The /var/run files have garbage in them as you mentioned. root@jail.local:~# cat /var/run/jail_app.id /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). Hostname is set in /etc/rc.conf. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jail startup/shutdown broken on latest 9-STABLE
On 05/24/12 15:06, Mike Jakubik wrote: On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote: root@jail.local:~# cat /var/run/jail_app.id /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). Hostname is set in /etc/rc.conf. I had this same issue - see my post on jails Rebooting the host cleared the problem for some time. I think it comes back... Tom Dean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jail startup/shutdown broken on latest 9-STABLE
On 05/24/12 15:06, Mike Jakubik wrote: Sorry, I was going too fast. uname -a FreeBSD P9X79.tddhome 9.0-STABLE FreeBSD 9.0-STABLE #2: Fri May 11 20:41:54 PDT 2012 tomdean@P9X79.tddhome:/usr/src/sys/GENERIC amd64 Tom Dean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jail startup/shutdown broken on latest 9-STABLE
On Thu, May 24, 2012 at 06:06:50PM -0400, Mike Jakubik wrote: On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote: On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote: Hello, Latest 9-STABLE has introduced some changes that break the ezjail rc script. On bootup it fails to start, but when i log in via ssh and manually start it, it works. However i am unable to shut them down afterwards. Try this: http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch cd /usr/src patch -p1 patch cd usr.sbin/jail make make install /usr/src/etc/rc.d/jail script can be just copied over. Note that your /var/run/jail_* files have broken content (some line from /etc/rc's output instead of jail id). Mateusz, Thanks for the patch, it fixes the startup issue on boot, however shutting down the jails still does not work. The /var/run files have garbage in them as you mentioned. root@jail.local:~# cat /var/run/jail_app.id /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). Hostname is set in /etc/rc.conf. This message is about rc.conf from your jail. This should be fixed by my change to etc/rc.d/jail, are you sure that you are running patched version? -- Mateusz Guzik mjguzik gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jail startup/shutdown broken on latest 9-STABLE
On Fri, 2012-05-25 at 00:13 +0200, Mateusz Guzik wrote: On Thu, May 24, 2012 at 06:06:50PM -0400, Mike Jakubik wrote: On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote: On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote: Hello, Latest 9-STABLE has introduced some changes that break the ezjail rc script. On bootup it fails to start, but when i log in via ssh and manually start it, it works. However i am unable to shut them down afterwards. Try this: http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch cd /usr/src patch -p1 patch cd usr.sbin/jail make make install /usr/src/etc/rc.d/jail script can be just copied over. Note that your /var/run/jail_* files have broken content (some line from /etc/rc's output instead of jail id). Mateusz, Thanks for the patch, it fixes the startup issue on boot, however shutting down the jails still does not work. The /var/run files have garbage in them as you mentioned. root@jail.local:~# cat /var/run/jail_app.id /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). Hostname is set in /etc/rc.conf. This message is about rc.conf from your jail. This should be fixed by my change to etc/rc.d/jail, are you sure that you are running patched version? Right, i just realized this. I set the hostname in the jailed rc.conf, now the file contains this: root@jail.local:~# cat /var/run/jail_app.id Setting hostname: app.local. I do not see a link to your jail rc.d script, just the patch. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jail startup/shutdown broken on latest 9-STABLE
On Thu, 2012-05-24 at 18:20 -0400, Mike Jakubik wrote: I do not see a link to your jail rc.d script, just the patch. Sigh, sorry, it's been a long day. I didnt look at the patch :P It works perfectly now, thanks again, hope someone can commit this soon. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jail startup/shutdown broken on latest 9-STABLE
On Thu, May 24, 2012 at 06:20:15PM -0400, Mike Jakubik wrote: On Fri, 2012-05-25 at 00:13 +0200, Mateusz Guzik wrote: On Thu, May 24, 2012 at 06:06:50PM -0400, Mike Jakubik wrote: On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote: On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote: Hello, Latest 9-STABLE has introduced some changes that break the ezjail rc script. On bootup it fails to start, but when i log in via ssh and manually start it, it works. However i am unable to shut them down afterwards. Try this: http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch cd /usr/src patch -p1 patch cd usr.sbin/jail make make install /usr/src/etc/rc.d/jail script can be just copied over. Note that your /var/run/jail_* files have broken content (some line from /etc/rc's output instead of jail id). Mateusz, Thanks for the patch, it fixes the startup issue on boot, however shutting down the jails still does not work. The /var/run files have garbage in them as you mentioned. root@jail.local:~# cat /var/run/jail_app.id /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). Hostname is set in /etc/rc.conf. This message is about rc.conf from your jail. This should be fixed by my change to etc/rc.d/jail, are you sure that you are running patched version? Right, i just realized this. I set the hostname in the jailed rc.conf, now the file contains this: root@jail.local:~# cat /var/run/jail_app.id Setting hostname: app.local. I do not see a link to your jail rc.d script, just the patch. Patch contains two fixes, for both usr/sbin/jail and etc/rc.d/jail. Assuming that the patch is still applied to your source tree, just do: cp /usr/src/etc/rc.d/jail /etc/rc.d/jail This fixes the jail script to actually store jail id instead of messages from /etc/rc. That is, you should be able to stop jails started by new etc/rc.d/jail script. -- Mateusz Guzik mjguzik gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jail startup/shutdown broken on latest 9-STABLE
On 05/24/12 16:30, Mateusz Guzik wrote: On Thu, May 24, 2012 at 06:20:15PM -0400, Mike Jakubik wrote: On Fri, 2012-05-25 at 00:13 +0200, Mateusz Guzik wrote: On Thu, May 24, 2012 at 06:06:50PM -0400, Mike Jakubik wrote: On Thu, 2012-05-24 at 23:22 +0200, Mateusz Guzik wrote: On Thu, May 24, 2012 at 03:18:54PM -0400, Mike Jakubik wrote: Hello, Latest 9-STABLE has introduced some changes that break the ezjail rc script. On bootup it fails to start, but when i log in via ssh and manually start it, it works. However i am unable to shut them down afterwards. Try this: http://student.agh.edu.pl/~mjguzik/patches/jail-startup-shutdown.patch cd /usr/src patch -p1 patch cd usr.sbin/jail make make install /usr/src/etc/rc.d/jail script can be just copied over. Note that your /var/run/jail_* files have broken content (some line from /etc/rc's output instead of jail id). Mateusz, Thanks for the patch, it fixes the startup issue on boot, however shutting down the jails still does not work. The /var/run files have garbage in them as you mentioned. root@jail.local:~# cat /var/run/jail_app.id /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). Hostname is set in /etc/rc.conf. This message is about rc.conf from your jail. This should be fixed by my change to etc/rc.d/jail, are you sure that you are running patched version? Right, i just realized this. I set the hostname in the jailed rc.conf, now the file contains this: root@jail.local:~# cat /var/run/jail_app.id Setting hostname: app.local. I do not see a link to your jail rc.d script, just the patch. Patch contains two fixes, for both usr/sbin/jail and etc/rc.d/jail. Assuming that the patch is still applied to your source tree, just do: cp /usr/src/etc/rc.d/jail /etc/rc.d/jail This fixes the jail script to actually store jail id instead of messages from /etc/rc. That is, you should be able to stop jails started by new etc/rc.d/jail script. I'll get the patch to jail(8) in - thanks for catching that. But I wonder about the patch to /etc/rc.d/jail. It looks correct, but I'm going to see if it's /etc/rc.d/jail that needs changing, or if my recent changes to jail(8) have changed the order in which things are written. - Jamie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jail startup/shutdown broken on latest 9-STABLE
On Thu, May 24, 2012 at 04:46:52PM -0600, Jamie Gritton wrote: I'll get the patch to jail(8) in - thanks for catching that. But I wonder about the patch to /etc/rc.d/jail. It looks correct, but I'm going to see if it's /etc/rc.d/jail that needs changing, or if my recent changes to jail(8) have changed the order in which things are written. Yeah, was not sure whether I should change the order or the script. :) Would not it be better to just create empty persistent jail as first step? Since in this case only one line will be generated (jid), rc.d script will be able to just take the output - this seems much less fragile than the current method. Then of course it would proceed with jexec running /etc/rc and in the end drop persist flag. It looks like rc.d script still uses old syntax so this actually may be less trivial than it sounds. That being said, if this is idea sounds okay, I can try to come up with a patch this weekend. -- Mateusz Guzik mjguzik gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ports devel/tkcvs
On Thu, 24 May 2012, Sean Bruno wrote: Probably doing something wrong, but when I install tkcvs to get tkdiff on my box, the only thing it does is fire up and display a wish window. Did I do it wrong? :-) No idea, but devel/diffuse might be alternative. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jail startup/shutdown broken on latest 9-STABLE
On 05/24/12 16:59, Mateusz Guzik wrote: On Thu, May 24, 2012 at 04:46:52PM -0600, Jamie Gritton wrote: I'll get the patch to jail(8) in - thanks for catching that. But I wonder about the patch to /etc/rc.d/jail. It looks correct, but I'm going to see if it's /etc/rc.d/jail that needs changing, or if my recent changes to jail(8) have changed the order in which things are written. Yeah, was not sure whether I should change the order or the script. :) Would not it be better to just create empty persistent jail as first step? Since in this case only one line will be generated (jid), rc.d script will be able to just take the output - this seems much less fragile than the current method. Then of course it would proceed with jexec running /etc/rc and in the end drop persist flag. It looks like rc.d script still uses old syntax so this actually may be less trivial than it sounds. That being said, if this is idea sounds okay, I can try to come up with a patch this weekend. There definitely is a difference between old and new jail behavior, not just in the order of things: glorfindel# jail -i -c name=foo command=foo 5 jail: execvp: foo: No such file or directory vs glorfindel# /usr/obj`pwd`/jail -i -c name=foo command=foo jail: exec foo: No such file or directory jail: foo: failed -1 The jail id given back used to correspond to a jail that was created but no longer exists by the time it's printed (or shortly thereafter). Now it's a -1 indicating that no jail exists. I think the -1 is more correct, but perhaps better for CURRENT but not STABLE? And the extra foo: failed is printed by jail, as a generic message when a command doesn't work out (for the case where the command itself doesn't print a message). Hmm ... I'll be pondering this one while I get a bite to eat :-). - Jamie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jail startup/shutdown broken on latest 9-STABLE
On Thu, May 24, 2012 at 06:47:30PM -0600, Jamie Gritton wrote: On 05/24/12 16:59, Mateusz Guzik wrote: On Thu, May 24, 2012 at 04:46:52PM -0600, Jamie Gritton wrote: I'll get the patch to jail(8) in - thanks for catching that. But I wonder about the patch to /etc/rc.d/jail. It looks correct, but I'm going to see if it's /etc/rc.d/jail that needs changing, or if my recent changes to jail(8) have changed the order in which things are written. Yeah, was not sure whether I should change the order or the script. :) Would not it be better to just create empty persistent jail as first step? Since in this case only one line will be generated (jid), rc.d script will be able to just take the output - this seems much less fragile than the current method. Then of course it would proceed with jexec running /etc/rc and in the end drop persist flag. It looks like rc.d script still uses old syntax so this actually may be less trivial than it sounds. That being said, if this is idea sounds okay, I can try to come up with a patch this weekend. There definitely is a difference between old and new jail behavior, not just in the order of things: glorfindel# jail -i -c name=foo command=foo 5 jail: execvp: foo: No such file or directory vs glorfindel# /usr/obj`pwd`/jail -i -c name=foo command=foo jail: exec foo: No such file or directory jail: foo: failed -1 The jail id given back used to correspond to a jail that was created but no longer exists by the time it's printed (or shortly thereafter). Now it's a -1 indicating that no jail exists. I think the -1 is more correct, but perhaps better for CURRENT but not STABLE? And the extra foo: failed is printed by jail, as a generic message when a command doesn't work out (for the case where the command itself doesn't print a message). Hmm ... I'll be pondering this one while I get a bite to eat :-). Note that my proposal with persistent jail creation as first step doesn't conflict with new behavior of jail(8) regarding jid printing. Also, I think that head - tail change for rc.d script that I proposed is broken. I think that as a short-term solution you should restore old behavior (jid printed before everything else) for -STABLE. The reason is that currently you have to take the jid from the last line, but you cannot be sure that jailed processes didn't mess with the output, so you actually cannot trust the last line, so you don't know the actual jid. That is: rc.d/jail reads the last line jail(8) just writes jid to very same file that contains output of jailed /etc/rc. So if the last line written by jailed processes doesn't end with newline character, jail(8) will just append jid to the line, so the actual content of /var/run/jail_foo.id will consist of characters written by possibly malicious script and jid. This could be used to store jid of another jail (assuming jid 2, /etc/rc consisting of echo -n 1 would result in stored jid 12 etc.) or random content that in some conditions could lead to code execution. -- Mateusz Guzik mjguzik gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Jail startup/shutdown broken on latest 9-STABLE
On 05/24/12 19:23, Mateusz Guzik wrote: On Thu, May 24, 2012 at 06:47:30PM -0600, Jamie Gritton wrote: On 05/24/12 16:59, Mateusz Guzik wrote: On Thu, May 24, 2012 at 04:46:52PM -0600, Jamie Gritton wrote: I'll get the patch to jail(8) in - thanks for catching that. But I wonder about the patch to /etc/rc.d/jail. It looks correct, but I'm going to see if it's /etc/rc.d/jail that needs changing, or if my recent changes to jail(8) have changed the order in which things are written. Yeah, was not sure whether I should change the order or the script. :) Would not it be better to just create empty persistent jail as first step? Since in this case only one line will be generated (jid), rc.d script will be able to just take the output - this seems much less fragile than the current method. Then of course it would proceed with jexec running /etc/rc and in the end drop persist flag. It looks like rc.d script still uses old syntax so this actually may be less trivial than it sounds. That being said, if this is idea sounds okay, I can try to come up with a patch this weekend. There definitely is a difference between old and new jail behavior, not just in the order of things: glorfindel# jail -i -c name=foo command=foo 5 jail: execvp: foo: No such file or directory vs glorfindel# /usr/obj`pwd`/jail -i -c name=foo command=foo jail: exec foo: No such file or directory jail: foo: failed -1 The jail id given back used to correspond to a jail that was created but no longer exists by the time it's printed (or shortly thereafter). Now it's a -1 indicating that no jail exists. I think the -1 is more correct, but perhaps better for CURRENT but not STABLE? And the extra foo: failed is printed by jail, as a generic message when a command doesn't work out (for the case where the command itself doesn't print a message). Hmm ... I'll be pondering this one while I get a bite to eat :-). Note that my proposal with persistent jail creation as first step doesn't conflict with new behavior of jail(8) regarding jid printing. Also, I think that head - tail change for rc.d script that I proposed is broken. I think that as a short-term solution you should restore old behavior (jid printed before everything else) for -STABLE. The reason is that currently you have to take the jid from the last line, but you cannot be sure that jailed processes didn't mess with the output, so you actually cannot trust the last line, so you don't know the actual jid. That is: rc.d/jail reads the last line jail(8) just writes jid to very same file that contains output of jailed /etc/rc. So if the last line written by jailed processes doesn't end with newline character, jail(8) will just append jid to the line, so the actual content of /var/run/jail_foo.id will consist of characters written by possibly malicious script and jid. This could be used to store jid of another jail (assuming jid 2, /etc/rc consisting of echo -n 1 would result in stored jid 12 etc.) or random content that in some conditions could lead to code execution. I think I should restore the old behavior for CURRENT as well. The -i option really only exists for /etc/rc.d/jail, and should behave the way it expects it to. And if anything else uses it, all the more reason not to change it. - Jamie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
STABLE/9 SMP ACPI suspend/resume - video mode not being restored
Hi, I'm toying with the SMP/i386 ACPI suspend/resume patches in -9. Thanks so much for this! I've noticed though that the video backlight stays off after resume. A common problem on -9, so I set hw.acpi.reset_video=1. That restores the backlight. However, the video mode isn't restored. I have my console set to VGA_80x60 and the resume seems to set it up wrong. I get half or so of each line displayed. A vidcontrol VGA_80x60 restores things to proper working order. Is there a shortcoming somewhere in syscons/ACPI video restore on -9 that doesn't properly restore the configured mode? Thanks again for all your hard work! Now that you've done that, I'll go off and work on fixing up ath(4) suspend/resume for PCI devices. :) Adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: STABLE/9 SMP ACPI suspend/resume - video mode not being restored
On Thu, May 24, 2012 at 08:46:03PM -0700, Adrian Chadd wrote: Hi, I'm toying with the SMP/i386 ACPI suspend/resume patches in -9. Thanks so much for this! Note that enough of those patches have been committed (at least as of r235891) that I was able to perform suspend/resume properly on my laptop (a Dell Precision M4400; video is NVIDIA GPU Quadro FX 770M (G96GL), and I use the nVidia driver (ports/x11/nvidia-driver)) without adding more patches. I've noticed though that the video backlight stays off after resume. A common problem on -9, so I set hw.acpi.reset_video=1. That restores the backlight. I do not see that behavior, and: g1-227(8.3-S)[7] sysctl hw.acpi.reset_video hw.acpi.reset_video: 0 (Yes, I'm running stable/8 on the present slice. I have stable/9 on another slice. And the experiment I did was with a slice where I had built stable/9 (i386) using clang.) However, the video mode isn't restored. I have my console set to VGA_80x60 and the resume seems to set it up wrong. I get half or so of each line displayed. That is another issue that I have not observed (in my case). ... Is there a shortcoming somewhere in syscons/ACPI video restore on -9 that doesn't properly restore the configured mode? I believe that my experience is evidence that if such a shortciming exists, it is not a general one. For me, suspend/resume in stable/9 Just Works (thanks to the hard work of others (such as iwasaki@), of course). Thanks again for all your hard work! Now that you've done that, I'll go off and work on fixing up ath(4) suspend/resume for PCI devices. :) Cool! :-) (Adrian, next BAFUG, perhaps we could compare notes/behaviors in person, if that might be of use?) Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpwfHqo1J4Os.pgp Description: PGP signature
Re: STABLE/9 SMP ACPI suspend/resume - video mode not being restored
Hi, thanks for reporting! However, the video mode isn't restored. I have my console set to VGA_80x60 and the resume seems to set it up wrong. I get half or so of each line displayed. A vidcontrol VGA_80x60 restores things to proper working order. Is there a shortcoming somewhere in syscons/ACPI video restore on -9 that doesn't properly restore the configured mode? Do you have vesa(4) in your kernel? It seems dev/fv/vesa.c:vesa_bios_post() restore the mode when resuming, but it's maybe incomplete in some cases... I think great work was done in this area, and we can improve this more. How about switching vty to other different mode vty and switching back in order to force changing video mode? I think it's better than re-run vidcontrol. Thanks again for all your hard work! Now that you've done that, I'll go off and work on fixing up ath(4) suspend/resume for PCI devices. :) This is my pleasure :) Thanks! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: VirtualBox, AIO and zvol's - a cautionary tale
Hi, On 23/05/2012, at 11:11 PM, Pete French wrote: Am posting this to stable not really as a question, but more in case anyone else hits the same problem. Last patch tuesday one of my virtual Windows machines running under VirtualBox started crashing. By which I mean that VirtualBox would quit. This had been running tsably for a long tine, so it puzzled me. First thought was it was sme patch from patch-tuesday. But rolling back to an earlier version of the disc showed it wasn't - the crashes were occurring before the patch had been applied. I'll skip the hours of puzzlement which followed - it turrned out that the indirect cause was that a few weeks ago I had installed Samba onto the same server. In doing so I had enabled AIO, as this improves Samba performance. What I didn't realise is that if VirtualBox finds AIO loaded it proceeds to use it. So by doing that I had switched on AIO inside my virtual machines as well. The disc I use for my virtual machines are all zvols (it performs better, and it seems that VirtualBox has a problem using AIO to access zvols. But this didn;t show up for weeks because in the normal scheme of things my virtual machines dont acccess the local dirve very much. It was only when they started downloading patches that the crash happened. Solution is simple - disable AIO. All then goes back to being nice and stable again. But it did take a while to find. I have seen similar behaviour, but I did not disable AIO to solve it. Instead, in the VirtualBox VM, I made sure that the storage controller was created with the --hostiocache on option. Without that, the virtual machines were unreliable on ZFS with the same behaviour you saw. Do you have the hostiocache enabled or disabled in your VM? Does it make a difference? Regards, Jan. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bash 4.2 patchlevel 28
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 24 May 2012 13:07-0700, Sean Bruno wrote: Noted that the following syntax is broken somewhere between 4.2 patchlevel 10 and 28. I'm sure its because we shouldn't be doing that over here at big purple, but we do ... and its a PITA. I'm bisecting to find out what is going on. test: VARIABLE=$(uname) bash: command substitution: line 3: syntax error near unexpected token `)' bash: command substitution: line 3: `uname)' Odd, but his works at patchlevel 10 I'm unable to reproduce this behaviour on one of my systems: trond@enterprise:~bash --version GNU bash, version 4.2.28(0)-release (amd64-portbld-freebsd9.0) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. trond@enterprise:~my_var=$(uname) trond@enterprise:~echo $my_var FreeBSD trond@enterprise:~ I'm not sure what's going on in your case. - -- +---++ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. dir. 61 14 54 39, | Office.: +47 61 14 54 39, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +---++ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk+/HEwACgkQbYWZalUoElvZYwCeLq5IHGp2dLyf+pcbzC1jk3RK us4An1AX5SelbwMEEVmooiopPmF9SAlI =9bTW -END PGP SIGNATURE-___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
