upgrade issue 8.x to 9.0-RC2: libz.so.5 not found
. In the past, I've been able to install FreeBSD using PXE and a TFTP service on my firewall (mostly using em0 network cards). I use the PXE facility so rarely, it's a small struggle to recall the magic each time. Note that after my ports recompiled (flags -af), there were roughly 40 packages out of 470 in /var/db/pkg that still had the old date stamp. These could be unimportant remnants for all I know. The list includes xorg-7.5, apache-2.0.63_15, a bunch of qt4 and xfree stuff, and xz-4.999.9 which I don't think pertains to libz, but I could be wrong. Finally, I also have some comments about ZFS as pertaining to idiots running on commodity DRAM (I can't be the only one). Which is the right mailing list? Basically my sentiment is that if you don't have hardware ECC (not even available so far as I know for the SB-E platform ideal to the EGTB computation and the Xeon equivalents are pricey), some software memory scrubbing could be valuable, and obvious to implement for the in-memory ARC cache (where cached data can sit exposed to cosmic rays for an indefinite time period on a lightly loaded network)--if ZFS doesn't incorporate that trick already. Any suggestions are appreciated. Allan ___ 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
5.1-RELEASE: Random lockups; ACPI issues; minor annoyances
I've encountered some suspicious random lock-ups under 5.1-RELEASE while
running KDE 3.1.2. They occur on a monthly basis. The machine doesn't
panic and I haven't been able to drop to the debugger yet.
Severity of the lock-ups has ranged from the odd time being able to
partially continue using shells and other programs (presumably those
that are already resident and if there isn't any disk access), to the
usual and resultant total lock-up which causes all programs to stop
responding to user input. So far as I can tell, this wasn't occurring
under 4.7 on the system.
Usually, the machine stops responding to all input on the console with
X11 and the keyboard freezing and also stops moused input. However the
network is still functional: Although the host continues responding to
pings and allows connections to open ports, there is no response on the
other end.
This has occurred under normal load with no resource shortage when it
occurs, and under heavy loads. Usually it is preceded by fam exiting
on error 6 or general KDE instability.
Hardware: Athlon 2400 XP+, ECS Elitegroup L7VTA w/ onboard Promise 20265
ATA RAID ~(FastTrack BIOS Version 2.00.0.23), nVidia 4xAGP MX400/GeForce2
Additionally, I've been testing ACPI on this hardware. ACPI would be
highly desirable for this desktop dev. workstation.
ACPI support: Suspend is currently buggy:
- S1(POS): partially supported, tested to work in single user mode only.
- S3(STR): doesn't work most of the time. When it did work, the
machine came back up with the array on Promise RAID controller in
an inconsistent state although sh still responded it spewed garbage
and couldn't use any external commands.
- S4: ?? XX Unsupported..
- ACPI requires that a keyboard be connected directly to the PC.
Some KVM-switches prevent ACPI from waking up when the keyboard
controller fails to reset.
- Panic when suspending with a serial console.
- CPU thermal zone, buttons: work fine.
- ACPI related panic when vr0 isn't already down and shutdown -p
[Work Around: add to /etc/rc.shutdown:]
echo -n 'Taking down interfaces:'
for iface in `/sbin/ifconfig -l`; do
/sbin/ifconfig ${iface} down; echo -n ${iface}
done; echo '.'
Other annoyance w/ this hardware:
- Switching between X and console mode on sc0 is really slow
under FreeBSD 5.1-RELEASE.
- The video once went blank when switching between X and console
on sc0. Also when using a serial console xdm strangeness.
- USB related panic when detaching umass device w/ mounted
filesystem (for instance batteries run out).
Is this potentially a hardware issue?
I have setup a serial console and remote debugger to investigate these issues further.
I'm also going to try an up to date kernel w/ ACPI disabled. dmesg and ACPI dump
found at:
http://afields.ca/afields.ca-5.1-release-dmesg.txt
http://afields.ca/l7vta_acpi_dump.aml .
-- Allan Fields
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
ftream errors under g++ 3.2.2
I recently updated one of my machines to -current to adapt some code to
build under the new version of gcc (3.2.2). However, file IO using fstream
gives error messages about implicit typenames being deprecated, and I can't
for the life of me figure out what to do my code to make the compiler happy.
Has anyone encountered this?
Below is a small example illustrating the problem. The source below should
compile fine on a previous version of g++, as in -stable. However, it will
not compile on -current using g++ 3.3.2. Does anyone know what to do to the
simple source below to get it to compile happily under -current?
(yes, I have checked gnu gcc's mailing list and FAQ/docs. I can't find an
adequate explanation for it. I suspect it has something to do with stricter
conformance to the finalized C++ standard, but since I am still a novice any
explanation by gcc developers would probably have slipped by me)
-
#include fstream
int main()
{
std::ofstream afile(test.txt);
afile some data;
}
--
gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.2.2 [FreeBSD] 20030205 (release)
-
g++ test.cc
In file included from test.cc:1:
/usr/include/g++/fstream:304: warning: `typename std::basic_filebuf_CharT,
_Traits::int_type' is implicitly a typename
/usr/include/g++/fstream:304: warning: implicit typename is deprecated,
please
see the documentation for details
/usr/include/g++/fstream:309: warning: `typename std::basic_filebuf_CharT,
_Traits::int_type' is implicitly a typename
/usr/include/g++/fstream:309: warning: implicit typename is deprecated,
please
see the documentation for details
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ftream errors under g++ 3.2.2
When you upgraded to -current, did you read /usr/src/UPDATING? You might find the following entry interesting: 20020831: gcc has been upgraded to 3.2. It is not all binary compatible with earlier versions of gcc for c++ programs. All c++ programs and libraries need to be recompiled. Also, if you encounter g++ issues, rm /usr/include/g++/* before doing an installworld to make sure that stale files are removed. Yes, Steve, I did read UPDATING, rm -rf /usr/include/g++ and rebuilt world. Still had the problem afterwards. --Allan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ftream errors under g++ 3.2.2
I do a lot of C++ development on -current, and I have been seeing these exact warnings. The problem is in the fstream header, however, so there is nothing you can do to your code to prevent the warnings. You could modify /usr/include/g++/fstream to silence the warnings, but it would get overwritten if you upgrade your system. Oh good :) I was thinking there was something I needed to add to make the code compliant. From your output, I don't see compile failures, I see warnings. Do you have -Werror turned on somewhere that wouldn't show up during normal usage--like some environment variable or something? I was able to compile and run your code without issue here. Honestly, I am surprised that a GCC header would have an implicit typename since the compiler clearly complains loudly about them. At any rate, I think the update to GCC 3.3 in -current is going to happen quite soon, and presumably, the updated GCC C++ headers will have warnings such as these fully eliminated. You're right. These are warnings, and it does compile. I guess I got a bit stuck on trying to determine why the messages were occuring. Thanks for your comments. --Allan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[CFT] Patch to bsdinstall to support root-on-ZFS and GELI
Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-07 16:43, Warren Block wrote: On Mon, 7 Oct 2013, Allan Jude wrote: Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 . ___ 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 That is a good idea, I'll add that I've also hit this: http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html and plan to throw in a fix for that. Which makes more sense, blindly 'killall dhclient' before we try to acquire a new lease, or detect that dhclient is running and try to use the IP that has already been assigned? -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-07 17:00, Outback Dingo wrote:
On Mon, Oct 7, 2013 at 4:54 PM, Allan Jude free...@allanjude.com wrote:
On 2013-10-07 16:43, Warren Block wrote:
On Mon, 7 Oct 2013, Allan Jude wrote:
Additional, it includes some other changes to bsdinstall:
1. Change the default to the 'non-standard keyboard mapping' prompt
to no
Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 .
___
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
That is a good idea, I'll add that
I've also hit this:
http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html
and plan to throw in a fix for that.
Which makes more sense, blindly 'killall dhclient' before we try to
acquire a new lease, or detect that dhclient is running and try to use
the IP that has already been assigned?
jeez after i just updated and patched my source tree to do a build, you
go and fix things :P
anyway you can just generate a master diff against the tree that we can
apply, seems not ive to
revert the patches and reapply all the newest ones.
--
Allan Jude
___
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
Attached find the patch from last night against a fresh HEAD
I am working on incorporating Warren's patch now
--
Allan Jude
Index: usr.sbin/bsdconfig/share/device.subr
===
--- usr.sbin/bsdconfig/share/device.subr(revision 256125)
+++ usr.sbin/bsdconfig/share/device.subr(working copy)
@@ -208,6 +208,10 @@ f_device_get_all()
n=$(( $n + 1 ))
# Get the desc, type, and max (with debugging disabled)
# NOTE: Bypassing f_device_name_get() for efficiency
+ # ASIDE: This would be equivalent to the following:
+ # debug= f_device_name_get $dev desc
+ # debug= f_device_name_get $dev type
+ # debug= f_device_name_get $dev max
debug= f_getvar _device_desc$n desc
debug= f_getvar _device_type$n type
debug= f_getvar _device_max$n max
@@ -313,7 +317,10 @@ f_device_get_all()
continue
fi
- f_device_register $diskname \
+ # Try and find its description
+ f_device_desc $diskname $DEVICE_TYPE_DISK desc
+
+ f_device_register $diskname $desc \
/dev/$diskname $DEVICE_TYPE_DISK 0
f_dprintf Found a disk device named %s $diskname
@@ -379,10 +386,27 @@ f_device_name_get()
case $__prop in type|desc|max) : good ;;
*) return $FAILURE; esac
+ #
+ # Attempt to create an alternate-form of $__name that contains the
+ # first contiguous string of numbers replaced with `%d' for comparison
+ # against stored pattern names (see MAIN).
+ #
+ local __left=${__name%%[0-9]*} __right=${__name#*[0-9]} __dname=
+ if [ $__left != $__name ]; then
+ # Chop leading digits from right 'til we hit first non-digit
+ while :; do
+ case $__right in
+ [0-9]*) __right=${__right#[0-9]} ;;
+*) break
+ esac
+ done
+ __dname=${__left}%d$__right
+ fi
+
[ $__type = $DEVICE_TYPE_ANY ] __type=
for __dev in $DEVICE_NAMES; do
__n=$(( $__n + 1 ))
- [ $__dev = $__name ] || continue
+ [ $__dev = $__name -o $__dev = $__dname ] || continue
f_getvar _device_type$__n __devtype
[ ${__type:-$__devtype} = $__devtype ] || continue
f_getvar _device_$__prop$__n $__var_to_set
@@ -463,6 +487,39 @@ f_device_desc()
fi
fi
+ #
+ # For disks, attempt to return camcontrol(8) descriptions.
+ # Otherwise fall through to below static list.
+ #
+ f_have camcontrol
+ [ ${__type:-$DEVICE_TYPE_DISK} = $DEVICE_TYPE_DISK ]
+ __cp=$( camcontrol devlist 2 /dev/null | awk -v disk=$__name '
+ $0~(\\(|,)disk(,|\\)) {
+ if (!match($0, [^]+)) next
+ print substr($0, RSTART+1, RLENGTH-2)
+ found = 1
+ exit
+ }
+ END { exit
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-07 18:25, Teske, Devin wrote: On Oct 7, 2013, at 3:21 PM, Outback Dingo wrote: On Mon, Oct 7, 2013 at 5:49 PM, Teske, Devin devin.te...@fisglobal.com wrote: On Oct 7, 2013, at 2:47 PM, Allan Jude wrote: On 2013-10-07 17:00, Outback Dingo wrote: On Mon, Oct 7, 2013 at 4:54 PM, Allan Jude free...@allanjude.com wrote: On 2013-10-07 16:43, Warren Block wrote: On Mon, 7 Oct 2013, Allan Jude wrote: Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 . ___ 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 That is a good idea, I'll add that I've also hit this: http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html and plan to throw in a fix for that. Which makes more sense, blindly 'killall dhclient' before we try to acquire a new lease, or detect that dhclient is running and try to use the IP that has already been assigned? jeez after i just updated and patched my source tree to do a build, you go and fix things :P anyway you can just generate a master diff against the tree that we can apply, seems not ive to revert the patches and reapply all the newest ones. -- Allan Jude ___ 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 Attached find the patch from last night against a fresh HEAD I am working on incorporating Warren's patch now ... and I'm working to review and validate what Allan is writing ;D A couple of big patches to incorporate within the hour (next 15 minutes). okies dokies guess ill revert it all and wait till you guys give the green light to try again Thanks... you know... Allan is giving me a work-out. He's running like the wind and I'm trying to catch my breath as he I trail behind him. Go Allan Go! ;D I make it work, Devin makes it pretty. Then he makes it so it is useful to other people. Then he makes an API out of it, with C style structs in SH. Then he does some other wizardry. It is quite impressive. -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-07 20:21, Teske, Devin wrote: On Oct 7, 2013, at 5:18 PM, Warren Block wrote: On Mon, 7 Oct 2013, Allan Jude wrote: On 2013-10-07 16:43, Warren Block wrote: On Mon, 7 Oct 2013, Allan Jude wrote: Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 . That is a good idea, I'll add that I've also hit this: http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html and plan to throw in a fix for that. Which makes more sense, blindly 'killall dhclient' before we try to acquire a new lease, or detect that dhclient is running and try to use the IP that has already been assigned? killall seems all right. In fact, internally, it's going to do that check. If nothing named dhclient is running, it will return immediately. Although on 10.0, dhclient does not want to die sometimes. Here's another PR for usability: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/161547 Hope you guys aren't rewriting bsdconfig's network.subr These changes are in usr.sbin/bsdinstall/scripts/network and usr.sbin/bsdinstall/scripts/network_ipv4 I've not touched bsdconfig's network stuff -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-07 15:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback I've generated a new version of the ISO incorporating all of todays changes and moving up to 10.0-ALPHA5 It includes 2 patches from Warren Block, improving the keymap menu and indicating which network interfaces are wireless http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-08 01:11, Teske, Devin wrote: On Oct 7, 2013, at 10:07 PM, Allan Jude wrote: On 2013-10-07 15:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback I've generated a new version of the ISO incorporating all of todays changes and moving up to 10.0-ALPHA5 It includes 2 patches from Warren Block, improving the keymap menu and indicating which network interfaces are wireless Excellent. However, I have to say... you opened a can of worms by touching keymap. Eventually I plan to rewrite all of the scripts to the same format that zfsboot is using. I've already started rewriting keymap to the new format. Of course, this opened up another can of worms... the simple things like: DIALOG_OK DIALOG_CANCEL DIALOG_ESC Yeah, after having them, I felt a bit naked not having all of those 'constants' defined. Originally, all I had done was add --defaultno to the dialog command, but Warren's patch makes a lot of sense, allow the user to 'try' the new keymap before trying to do the rest of the install based on it. I feel would be much better off in the `dialog.subr' module. So,... I've started peppering their usage everywhere in bsdconfig to make them proper. That means they will just be transparent from including `dialog.subr'. This is definately something that I think is a good idea, but my focus is on improving the usability and functionality of the installer in time for 10.0. Unifying everything to the bsdconfig style is slightly lower priority. Admittedly, the `bsdconfig networking` stuff is quite nice http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso Excellent, thanks! -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-08 16:17, Nathan Whitehorn wrote: On 10/07/13 21:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback Thanks for doing this! I had a few comments: 1. ZFS is not bootable on all architectures. Could you adjust that menu item to only display for i386, amd64, and (I think?) sparc64. Use uname -m, not -p, for this. I had not considered that, I'll make that change 1a. The script is broken on sparc64 in any case, which uses VTOC8 instead of GPT. I'll disable sparc64 as well 2. Why are you using camcontrol? That is guaranteed not to work on non-CAM systems. You should use the GEOM ident string if you need an ID. The GEOM ident string doesn't do enough to help the user identify which drive is which. More data is not exposed anywhere that I could find What we really need, is dev.ada.0.desc% like we have for network interfaces and a slew of other devices. GEOM data is great, but it is not exposed in a shell friendly way any place that I could find, other than the sysctl with DOT and XML data. 3. Any plans to integrate this into the regular partition editor? ZFS support is important enough that I will definitely not get in the way, even as a bolt-on, but it would be a shame for it to stay that way. The editor is also designed for ZFS to be added. I am a sysadmin, not a programmer. I can't write C. Most people deploying servers can't write C. I agree with Devin Teske, if everything was in shell it would be a lot more usable for non-developers, who probably make up the majority of people who deploy FreeBSD. 4. What is this gnop stuff for? yeah, we align the partitions and the blocks to ensure optimal performance on 'advanced format' drives, there is no real downside for older drives, and it saves you from headaches in the future. 5. I think some substantial part of the MBR code will blow up if you are reinitalizing a previously formatted disk (the bsdlabel will be retasted and come back from the dead). We try to do what we can here, including creating a fresh GPT and MBR and blowing them away to ensure that anything left over is really dead. We also use zpool labelclear, which doesn't check if there ever was a ZFS label, it just blindly overwrites the spots where the label would go. I'll add some additional napalm to ensure there are no zombie partitions. -Nathan ___ 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 -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-09 03:22, Matthias Gamsjager wrote: Hi, tried 10-8 iso in Virtualbox but after reboot I was looking at a bootloader with a nice '-' but nothing more. post setup 'gpart list' showed no entries at all. On Wed, Oct 9, 2013 at 5:49 AM, Allan Jude free...@allanjude.com mailto:free...@allanjude.com wrote: On 2013-10-07 15:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback We've made more improvements, including corporating most all of the feedback we've gotten so far Outstanding items: 1. Apply the changes to ipv6 config the way we did ipv4 2. improve disk identification (model info and serial # instead of one or the other) 3. Include a helpful message before the GELI step where you have to enter your password many times, the user will be less confused if it is explained why they have to enter their password 3 * number of disks times 4. Validate vdev type choice inside the vdev type menu, and warn the user if they have made an invalid selection, so they can add more disks or chance their selection, without having to try to start the installation first 5. Whatever else you guys find wrong tonight I generated new test images, and attached the patch (which got REALLY big when Devin Teske decided to fix all of the things: http://www.allanjude.com/bsd/zfsbootonly.2013-10-08.iso.xz http://www.allanjude.com/bsd/zfsbootonly.2013-10-08.iso -- Allan Jude ___ freebsd-current@freebsd.org mailto: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 mailto:freebsd-current-unsubscr...@freebsd.org This was a variable scoping error made by Devin when he refactored some of the code into a subroutine. I have fixed it -- Allan Jude ___ 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: rcs
On 2013-10-09 12:23, Freddie Cash wrote: On Wed, Oct 9, 2013 at 9:12 AM, Freddie Cash fjwc...@gmail.com wrote: On Wed, Oct 9, 2013 at 6:41 AM, Julian Elischer jul...@freebsd.orgwrote: On 10/9/13 2:35 AM, Freddie Cash wrote: On Tue, Oct 8, 2013 at 9:09 AM, Alfred Perlstein bri...@mu.org wrote: You're right on the money, to be honest this is one of the reasons why I've switched to using OSX as my desktop OS. zsh, vim, screen by default. and upgrades work. At the end of the day I'm spending time doing work, not mucking about my workspace to make it usable for development. I think this was brought up at BSDCan in the discussion about making FreeBSD a more featured development platform. Speaking of... has anyone tried PCBSD? PC-BSD isn't much different from FreeBSD. The installer is GUI and support ZFS, there are some GUI setup tools on first boot for X, there are some GUI tools to select binary drivers for X, and there are working pkgng repos available. I had a lot of issues with PC-BSD 9.0 and 9.1 as I was trying to do things the FreeBSD way which broke a lot of things that were done the PC-BSD way (aka don't manually edit config files used for booting). Switching to the rolling-release (aka PC-BSD 9-STABLE) and moving all my config file edits into filename.conf.local fixed my issues. Things have been running smooth, and I finally understand the beauty and simplicity of freebsd-update + pkg. OS gets updated once per month, packages get updated twice per month, no more compiling things from source. It's like using Ubuntu/Debian but with the power and features of FreeBSD. :) When they went to a ZFS-only system, using GRUB, with no alternative, then I'm afraid they lost me. I want a root filesystem on UFS for reliabailty and simpleness. I can debug it's media if needed. Before then I really liked it (though ther eis not enough information on how it works interneally if you want to use it. hopefully that will come.. and I LIKE PBIs FreeBSD should adopt PBIs for sure. With PBIs you could make even quite base items separately installable. versioning problems go away. There's no GRUB in a default install of PC-BSD 9.0, 9.1, or 9.2. Even on a ZFS-only setup (which is what I run). It's using the FreeBSD loader, with custom artwork and menus. Hrm, it seems they've changed things with the 9.2 installer. It does use GRUB2 (e!) for the boot loader, and integrates support for ZFS boot environments (via beadm) into it. :( Shame they didn't use the BE support in the FreeBSD loader for this. Wonder if my 9-STABLE-based PC-BSD install will get upgraded to GRUB? The reason they went to grub2, is that the way the freebsd loader menus work, it loads the kernel before it draws the menu. This means if there is a problem with your kernel (probably the most valuable time to have boot environments) then the menu never comes up, and you cannot select which BE to boot from. Grub doesn't rely on a FreeBSD kernel until after you select which BE to boot from. Kris and I discussed it at length with Devin Teske, and while he has demonstrated being able to populate a lower menu with the ZFS datasets, I am not sure if the other issue can be resolved. -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-09 13:21, Teske, Devin wrote: On Oct 8, 2013, at 8:49 PM, Allan Jude wrote: On 2013-10-07 15:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback We've made more improvements, including corporating most all of the feedback we've gotten so far Outstanding items: 1. Apply the changes to ipv6 config the way we did ipv4 2. improve disk identification (model info and serial # instead of one or the other) 3. Include a helpful message before the GELI step where you have to enter your password many times, the user will be less confused if it is explained why they have to enter their password 3 * number of disks times I'm hopeful that we can script the application of a password that we first prompt for. What tool is prompting for a password? Can we not just provide an answer on stdin? (e.g., echo $pass | tool_that_needs_pass) It is 'geli create' and 'geli attach'. I am not sure if we want to have the password show up in the process list (obviously in the installer this is less of an issue, but) 4. Validate vdev type choice inside the vdev type menu, and warn the user if they have made an invalid selection, so they can add more disks or chance their selection, without having to try to start the installation first This will be done with fanciness ;D (read: ... --and-widget --infobox ... and sundry smartness; retaining as much as possible the ability to do things out of order but never arise at a point of astonishment). I don't think we need --and-widget, just in the function where we apply the results of the menu selection, we can add a regular --msgbox telling them that their config won't work, and they need to either select more drives or a different vdev type 5. Whatever else you guys find wrong tonight I generated new test images, and attached the patch (which got REALLY big when Devin Teske decided to fix all of the things: And then I merged all of the things into HEAD, so the patch-set shrunk back to its normal size. Now we have global exit codes which will make merging of code that is based off of Thomas Dickey's samples easier. I am glad to see all of the good ideas, and plans to make everything wonderful, but my biggest concern is getting this over to re@ so it can get in to 10.0-BETA1, the deadline for which is looming (like, tomorrow I think). As such, I have rolled back the patches to netconfig and netconfig_ipv4 (my stuff to reduce the number of dialogs to configure ipv4, it posed some problems with the possible usage of xdialog, and didn't actually offer an option to 'cancel'). I kept Warren's netconfig wireless patch This leaves the only real outstanding problem the keymap thing. I propose changing it from a yes/no/other to a --menu, and hopefully we can find the bug with the display name, or just make it show the keymap name instead. -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-09 14:14, Teske, Devin wrote: On Oct 9, 2013, at 10:47 AM, Allan Jude wrote: On 2013-10-09 13:21, Teske, Devin wrote: On Oct 8, 2013, at 8:49 PM, Allan Jude wrote: On 2013-10-07 15:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0Am=oPEdrpFUFqEutq%2B7DHGyBIA0gTt5%2BZ6FWvbN6q4bjm4%3D%0As=32f69a33d9c98c63ecf3962b89eea0af631f5a2fd6e82b55afb6ec139f3f803d I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): https://urldefense.proofpoint.com/v1/url?u=http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xzk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0Am=oPEdrpFUFqEutq%2B7DHGyBIA0gTt5%2BZ6FWvbN6q4bjm4%3D%0As=fd0f3ed623f12c8cb5eee607cf82122523a0800ab9f5624cb3f77ae2646e1b1b https://urldefense.proofpoint.com/v1/url?u=http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.isok=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=LTzUWWrRnz2iN3PtHDubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0Am=oPEdrpFUFqEutq%2B7DHGyBIA0gTt5%2BZ6FWvbN6q4bjm4%3D%0As=fa49aaa528513a591ac40a2f0c5666abae2d7269bd66ac70d7100475a9574300 We look forward to your feedback We've made more improvements, including corporating most all of the feedback we've gotten so far Outstanding items: 1. Apply the changes to ipv6 config the way we did ipv4 2. improve disk identification (model info and serial # instead of one or the other) 3. Include a helpful message before the GELI step where you have to enter your password many times, the user will be less confused if it is explained why they have to enter their password 3 * number of disks times I'm hopeful that we can script the application of a password that we first prompt for. What tool is prompting for a password? Can we not just provide an answer on stdin? (e.g., echo $pass | tool_that_needs_pass) It is 'geli create' and 'geli attach'. I am not sure if we want to have the password show up in the process list (obviously in the installer this is less of an issue, but) It won't. echo is a shell built-in. If we're uber paranoid... we prefix the word builtin; e.g.,... builtin echo $pass | tool_that_needs_pass You'll see the tool in ps, but you won't see the echo (that's part of the shell invocation -- all you see in ps is an instance of sh). I have implemented this, 'geli init' takes the -J file flag, which can be set to - to mean stdin. 'geli attach' is the same except the flag is -j I first prompt for the password with a dialog --passwordbox, so the user only has to enter it once Do we think it makes sense to prompt the user twice, and confirm the two entered passphrases are the same? 4. Validate vdev type choice inside the vdev type menu, and warn the user if they have made an invalid selection, so they can add more disks or chance their selection, without having to try to start the installation first This will be done with fanciness ;D (read: ... --and-widget --infobox ... and sundry smartness; retaining as much as possible the ability to do things out of order but never arise at a point of astonishment). I don't think we need --and-widget, just in the function where we apply the results of the menu selection, The purpose of --and-widget with an --infobox is to let the user know that validation is occurring each/every time they make a selection. Seeing the infobox before being returned to the previous menu (in the case of selecting a valid vdev_type) is to cement in the mind of the user that their selection was validated. Of course, in the case of an invalid selection, they get a message box. What the message box says
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-10 03:00, Nathan Whitehorn wrote: On 10/09/13 18:55, Teske, Devin wrote: On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote: On 10/09/13 01:13, Allan Jude wrote: On 2013-10-08 16:17, Nathan Whitehorn wrote: On 10/07/13 21:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback Thanks for doing this! I had a few comments: 1. ZFS is not bootable on all architectures. Could you adjust that menu item to only display for i386, amd64, and (I think?) sparc64. Use uname -m, not -p, for this. I had not considered that, I'll make that change 1a. The script is broken on sparc64 in any case, which uses VTOC8 instead of GPT. I'll disable sparc64 as well 2. Why are you using camcontrol? That is guaranteed not to work on non-CAM systems. You should use the GEOM ident string if you need an ID. The GEOM ident string doesn't do enough to help the user identify which drive is which. More data is not exposed anywhere that I could find What we really need, is dev.ada.0.desc% like we have for network interfaces and a slew of other devices. GEOM data is great, but it is not exposed in a shell friendly way any place that I could find, other than the sysctl with DOT and XML data. This is one of the reasons the partition editor is written in C. There are a few other odd corner-cases where C is much more powerful than the command-line for the GEOM operations that partedit needs to do. I'm not sure how to usefully get it just from the shell. You can see how to do it in C in the boot_disk() routine of partedit/auto_part.c. 3. Any plans to integrate this into the regular partition editor? ZFS support is important enough that I will definitely not get in the way, even as a bolt-on, but it would be a shame for it to stay that way. The editor is also designed for ZFS to be added. I am a sysadmin, not a programmer. I can't write C. Most people deploying servers can't write C. I agree with Devin Teske, if everything was in shell it would be a lot more usable for non-developers, who probably make up the majority of people who deploy FreeBSD. There are some cases the other way too. Devin is probably the most shell-proficient FreeBSD committer. Well, there's jilles ;D (he writes/maintains the sh(1) implementation itself). I certainly can't write shell scripts at that level, which means that for me bsdconfig, for example, is effectively read-only (and quite hard to read as well). In the past few days of working on the bsdinstall_zfs patch-set with Allan Jude, I learned something new actually. It seems that sh(1) doesn't suffer so much from this read only concept. Imagine you're starting a new C project on an operating system that has all new syscalls and all new APIs that you've never seen. Would be pretty hard, no doubt. Now imagine that you're thrown a life-line called POSIX and hey, now you're slinging code in MinGW on Windows when you don't know a lick of M$ syscalls or APIs. In a similar manner, I've witnessed functionality be added that is truly functional *without* using any of the API calls. Then I come in and do a round of optimizations to leverage the existing API. Shell is kinda like that... I'm noticing Allan Jude doesn't know all the API calls yet (who could? other than me of course -- and even I have trouble remembering them _all_) yet this doesn't phase him (or others) from jumping in and lending a hand. No different than C, but the read-only aspect is lessened significantly I believe
Re: ZFS L2ARC - incorrect size and abnormal system load on r255173
On 2013-10-10 05:22, Vitalij Satanivskij wrote: Same situation hapend yesterday again :( What's confuse me while trying to understend where I'm wrong Firt some info. We have zfs pool POOL and one more zfs on it POOL/zfs POOL - have only primarycache enabled ALL POOL/zfs - have both primay and secondary for ALL POOL have compression=lz4 POOL/zfs have none POOL - have around 9TB data POOL/zfs - have 1TB Secondary cache have configuration - cache gpt/cache0ONLINE 0 0 0 gpt/cache1ONLINE 0 0 0 gpt/cache2ONLINE 0 0 0 gpt/cache0-2 it's intel sdd SSDSC2BW180A4 180gb So full real size for l2 is 540GB (realy 489gb) First question - data on l2arc will be compressed on not? Second in stats we see L2 ARC Size: (Adaptive) 2.08TiB eary it was 1.1 1.4 ... So a) how cache can be biger than zfs it self b) in case it's not compressed (answer for first question) how it an be biger than real ssd size? one more coment if l2 arc size grove above phisical sizes I se next stats kstat.zfs.misc.arcstats.l2_cksum_bad: 50907344 kstat.zfs.misc.arcstats.l2_io_error: 4547377 and growing. System is r255173 with patch from rr255173 At last maybe somebody have any ideas what's realy hapend... Vitalij Satanivskij wrote: VS VS One more question - VS VS we have two counter - VS VS kstat.zfs.misc.arcstats.l2_size: 1256609410560 VS kstat.zfs.misc.arcstats.l2_asize: 1149007667712 VS VS can anybody explain how to understand them i.e. l2_asize - real used space on l2arc an l2_size - uncompressed size, VS VS or maybe something else ? VS VS VS VS Vitalij Satanivskij wrote: VS VS VS VS Data on pool have compressratio around 1.4 VS VS VS VS On diferent servers with same data type and load L2 ARC Size: (Adaptive) can be diferent VS VS VS VS for example 1.04TiB vs 1.45TiB VS VS VS VS But it's all have same porblem - grow in time. VS VS VS VS VS VS More stange for us - VS VS VS VS ARC: 80G Total, 4412M MFU, 5040M MRU, 76M Anon, 78G Header, 2195M Other VS VS VS VS 78G header size and ubnormal - VS VS VS VS kstat.zfs.misc.arcstats.l2_cksum_bad: 210920592 VS VS kstat.zfs.misc.arcstats.l2_io_error: 7362414 VS VS VS VS sysctl's growing avery second. VS VS VS VS All part's of server (as hardware part's) in in normal state. VS VS VS VS After reboot no problem's for some period untile cache size grow to some limit. VS VS VS VS VS VS VS VS Mark Felder wrote: VS VS MF On Mon, Oct 7, 2013, at 13:09, Dmitriy Makarov wrote: VS VS MF VS VS MF How can L2 ARC Size: (Adaptive) be 1.44 TiB (up) with total physical size VS VS MF of L2ARC devices 490GB? VS VS MF VS VS MF VS VS MF http://svnweb.freebsd.org/base?view=revisionrevision=251478 VS VS MF VS VS MF L2ARC compression perhaps? VS VS MF ___ VS VS MF freebsd-current@freebsd.org mailing list VS VS MF http://lists.freebsd.org/mailman/listinfo/freebsd-current VS VS MF To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org VS VS ___ VS VS freebsd-current@freebsd.org mailing list VS VS http://lists.freebsd.org/mailman/listinfo/freebsd-current VS VS To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org VS ___ VS freebsd-current@freebsd.org mailing list VS http://lists.freebsd.org/mailman/listinfo/freebsd-current VS 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 Some background on L2ARC compression for you: http://wiki.illumos.org/display/illumos/L2ARC+Compression http://svnweb.freebsd.org/base?view=revisionrevision=251478 Are you sure that compression on pool/zfs is off? it would normally inherit from the parent, so double check with: zfs get compression pool/zfs Is the data on pool/zfs related to the data on the root pool? if pool/zfs were a clone, and the data is actually used in both places, the newer 'single copy ARC' feature may come in to play: https://www.illumos.org/issues/3145 -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-10 11:30, Teske, Devin wrote: On Oct 10, 2013, at 4:55 AM, Nathan Whitehorn wrote: On 10/10/13 09:20, Allan Jude wrote: On 2013-10-10 03:00, Nathan Whitehorn wrote: On 10/09/13 18:55, Teske, Devin wrote: On Oct 8, 2013, at 11:19 PM, Nathan Whitehorn wrote: On 10/09/13 01:13, Allan Jude wrote: On 2013-10-08 16:17, Nathan Whitehorn wrote: On 10/07/13 21:59, Allan Jude wrote: Devin Teske and I have been working on a big patch to bsdinstall to implement installing on a ZFS pool. It supports both GPT and MBR, the 4k sector gnop trick, and optional GELI encryption. We would like to commit this in time for 10.0-BETA1 so it needs some testing to work out any obvious bugs before we send it off to re@ to get it committed. It includes a single configuration menu that allows you to select all of the required details, including which drives to use (gets details from camcontrol, also includes an inspection utility that presents the detailed output of camcontrol inquiry/identify, and gpart show), what ZFS RAID level to use (taking in to consideration the selected number of drives), GPT/mbr, 4k YES/no, GELI yes/NO, pool name, etc. Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no 2. Replace the 3 separate dialogs to configure an ipv4 address with just 1 3. Remove the dialog asking if you wish to enable crash dumps, this feature has been combined into the regular 'services to enable' dialog and enabled by default You can browse the patches here: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ I've built a bootonly.iso (10.0-ALPHA4) to make testing easier, available compressed (48 MB) or uncompressed (211 MB): http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso.xz http://www.allanjude.com/bsd/zfsbootonly_2013-10-06.iso We look forward to your feedback Thanks for doing this! I had a few comments: 1. ZFS is not bootable on all architectures. Could you adjust that menu item to only display for i386, amd64, and (I think?) sparc64. Use uname -m, not -p, for this. I had not considered that, I'll make that change 1a. The script is broken on sparc64 in any case, which uses VTOC8 instead of GPT. I'll disable sparc64 as well 2. Why are you using camcontrol? That is guaranteed not to work on non-CAM systems. You should use the GEOM ident string if you need an ID. The GEOM ident string doesn't do enough to help the user identify which drive is which. More data is not exposed anywhere that I could find What we really need, is dev.ada.0.desc% like we have for network interfaces and a slew of other devices. GEOM data is great, but it is not exposed in a shell friendly way any place that I could find, other than the sysctl with DOT and XML data. This is one of the reasons the partition editor is written in C. There are a few other odd corner-cases where C is much more powerful than the command-line for the GEOM operations that partedit needs to do. I'm not sure how to usefully get it just from the shell. You can see how to do it in C in the boot_disk() routine of partedit/auto_part.c. 3. Any plans to integrate this into the regular partition editor? ZFS support is important enough that I will definitely not get in the way, even as a bolt-on, but it would be a shame for it to stay that way. The editor is also designed for ZFS to be added. I am a sysadmin, not a programmer. I can't write C. Most people deploying servers can't write C. I agree with Devin Teske, if everything was in shell it would be a lot more usable for non-developers, who probably make up the majority of people who deploy FreeBSD. There are some cases the other way too. Devin is probably the most shell-proficient FreeBSD committer. Well, there's jilles ;D (he writes/maintains the sh(1) implementation itself). I certainly can't write shell scripts at that level, which means that for me bsdconfig, for example, is effectively read-only (and quite hard to read as well). In the past few days of working on the bsdinstall_zfs patch-set with Allan Jude, I learned something new actually. It seems that sh(1) doesn't suffer so much from this read only concept. Imagine you're starting a new C project on an operating system that has all new syscalls and all new APIs that you've never seen. Would be pretty hard, no doubt. Now imagine that you're thrown a life-line called POSIX and hey, now you're slinging code in MinGW on Windows when you don't know a lick of M$ syscalls or APIs. In a similar manner, I've witnessed functionality be added that is truly functional *without* using any of the API calls. Then I come in and do a round of optimizations to leverage the existing API. Shell is kinda like that... I'm noticing Allan Jude doesn't know all the API calls yet (who could? other than me of course -- and even I have trouble remembering them _all_) yet
Re: FreeBSD 10 and zfsd
On 2013-10-10 12:13, Mark Felder wrote: On Thu, Oct 10, 2013, at 10:24, Alan Somers wrote: On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks joh.hendr...@gmail.com wrote: When i started using ZFS on FreeBSD I quickly found out that hot spares are not possible on FreeBSD. I was told that with zfsd it should be possible and that it would be included in FreeBSD 10. Is there some info about the zfsd function and how it could be used? zfsd is currently not in FreeBSD/head and won't make it into 10, but you can still get the source code from its project branch. It's being used in production by at least two companies. So FreeBSD is going to have inferior ZFS management compared to Solaris/Illumos/etc for another 2+ years? Why are things like this allowed to miss releases? ___ 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 ZFSd was a big topic of discussion at the EuroBSDCon 2013 dev summit (3 weeks ago). There is a lot of collaboration going on, to bring in some work done by vendors like SpectraLogics. This is the type of feature that can be assed in 10.1, it won't have to wait for 11. You can see Robert Watsons talk How FreeBSD Works to see why releases are based on date, rather than on feature completion (because things are never finished) -- Allan Jude ___ 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: FreeBSD 10 and zfsd
On 2013-10-10 13:26, Alan Somers wrote: On Thu, Oct 10, 2013 at 11:24 AM, Allan Jude free...@allanjude.com wrote: On 2013-10-10 12:13, Mark Felder wrote: On Thu, Oct 10, 2013, at 10:24, Alan Somers wrote: On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks joh.hendr...@gmail.com wrote: When i started using ZFS on FreeBSD I quickly found out that hot spares are not possible on FreeBSD. I was told that with zfsd it should be possible and that it would be included in FreeBSD 10. Is there some info about the zfsd function and how it could be used? zfsd is currently not in FreeBSD/head and won't make it into 10, but you can still get the source code from its project branch. It's being used in production by at least two companies. So FreeBSD is going to have inferior ZFS management compared to Solaris/Illumos/etc for another 2+ years? Why are things like this allowed to miss releases? ___ 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 ZFSd was a big topic of discussion at the EuroBSDCon 2013 dev summit (3 weeks ago). There is a lot of collaboration going on, to bring in some work done by vendors like SpectraLogics. This is the type of feature that can be assed in 10.1, it won't have to wait for 11. You can see Robert Watsons talk How FreeBSD Works to see why releases are based on date, rather than on feature completion (because things are never finished) -- Allan Jude ___ 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 Due to popular demand, I have located a round toit. I'm currently working on rebasing the zfsd project branch to head, after which I'll push SpectraLogic's recent changes. See, all you have to do is complain loudly enough :p -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-10 13:21, Warren Block wrote: [off-list reply] I have not tested the new version yet. Is there any chance it supports setting up a gmirror? Something I've been meaning to discuss with Devin is the concept of presets. The user would be able to choose from a list of presets: Filesystem Layout - Merged / filesystem Split /, /var, /tmp, /usr filesystems then Filesystem Type --- UFS ZFS then Disk Layout --- Plain disk Mirror RAID Those choices might change depending on earlier ones, like if they had chosen ZFS earlier they would get a choice of Mirror, RAID-Z1, RAID-Z2, and so on. All this would build up a configuration, and at the end the user can edit it (filesystem sizes, for instance), then pick Go and walk away. All of the UFS stuff is in C, so is read-only for me. It is something I'd like to do, but it is really iffy if that can be done in time for 10.0 In general, gmirror support could be added to the ZFS section (renamed to something else). So in our current 'zfs' menu, would become the 'new partition manager' menu. Add an extra option for ZFS or UFS, and then the vdev menu would context switch between zfs vdevs and ufs options like gmirror and gstripe or something Adding an extra option for / or / /var /tmp /usr is not a bad idea either, maybe even for ZFS, offering a simpler set of datasets that might be some people's preference (especially if I can't do the following in time:) In a future revision of the zfsboot stuff, I'd like to offer a dialog where users can actually adjust the ZFS datasets. provide a menu listing the created dataset, with option to add more, and when you select a dataset, you can adjust its options or delete it (some really scary validation needs to happen here so you can't delete /usr if you have /usr/local) If the UFS stuff took the form of the current ZFS stuff (give me the entire disk, and i'll run with it), it would be fairly easy to implement, and could probably be done between 10.0-BETA1 and 10.0-BETA2 The more powerful features of the current partedit code, where it actually shows what is on your disk already, and allows you to just adjust it, and in general manage dual booting etc, that is a lot more complicated. -- Allan Jude ___ 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: Prompt Live-CD/DVD with support for ZFS v.5000
On 2013-10-10 17:12, Vladislav V. Prodan wrote: 04.10.2013 16:56, Ollivier Robert wrote: According to Vladislav V. Prodan on Fri, Oct 04, 2013 at 01:48:16AM +0300: You want to add such a liveCD for automatic loading on PXE. MfsBSD built with ZFS v.28 :( mfsbsd will be updated soon I guess but in the meantime it is very easy to generate your own. Just get the code from github, modify a few config files if needed and make. Thanks. In the latest build no libiconv.so.3 root@mfsbsd:/tmp/oldpool/var/db/mysql # rsync -a /tmp/oldpool/var/db/mysql/ /tmp/newpool/var/db/mysql/ Shared object libiconv.so.3 not found, required by rsync First time seeing this thread, but Devin Teske and I have just finished integrated support for root-on-zfs installs in bsdinstall, should land in head today -- Allan Jude ___ 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: Can't start iscsid - kldload: can't load iscsi: Exec format error - FreeBSD 10 Alpha 2
On 2013-10-10 17:41, Mike C. wrote: Hi, I'm running Alpha-2 and wanted to test with iscsi but it seems I can't start iscsid. $ sudo service iscsid onerestart kldload: can't load iscsi: Exec format error /etc/rc.d/iscsid: WARNING: Unable to load kernel module iscsi /etc/rc.d/iscsid: WARNING: failed precmd routine for iscsid dmesg shows: interface icl.1 already present in the KLD 'kernel'! linker_load_file: Unsupported file type And also it seems that iscsi is actually already loaded: sudo kldstat -v | grep isci 470 pci/isci Any help is appreciated. isci is the intel SAS driver, not iscsi (confusing name) The problem appears to be that the iscsi module you have is not the same version as your kernel, try updating to ALPHA5 -- Allan Jude ___ 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: FreeBSD 10 and zfsd
On 2013-10-10 15:59, O. Hartmann wrote: On Thu, 10 Oct 2013 13:41:06 -0500 Mark Felder f...@freebsd.org wrote: On Thu, Oct 10, 2013, at 12:40, Allan Jude wrote: On 2013-10-10 13:26, Alan Somers wrote: On Thu, Oct 10, 2013 at 11:24 AM, Allan Jude free...@allanjude.com wrote: On 2013-10-10 12:13, Mark Felder wrote: On Thu, Oct 10, 2013, at 10:24, Alan Somers wrote: On Thu, Oct 10, 2013 at 8:19 AM, Johan Hendriks joh.hendr...@gmail.com wrote: When i started using ZFS on FreeBSD I quickly found out that hot spares are not possible on FreeBSD. I was told that with zfsd it should be possible and that it would be included in FreeBSD 10. Is there some info about the zfsd function and how it could be used? zfsd is currently not in FreeBSD/head and won't make it into 10, but you can still get the source code from its project branch. It's being used in production by at least two companies. So FreeBSD is going to have inferior ZFS management compared to Solaris/Illumos/etc for another 2+ years? Why are things like this allowed to miss releases? ___ 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 ZFSd was a big topic of discussion at the EuroBSDCon 2013 dev summit (3 weeks ago). There is a lot of collaboration going on, to bring in some work done by vendors like SpectraLogics. This is the type of feature that can be assed in 10.1, it won't have to wait for 11. You can see Robert Watsons talk How FreeBSD Works to see why releases are based on date, rather than on feature completion (because things are never finished) -- Allan Jude ___ 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 Due to popular demand, I have located a round toit. I'm currently working on rebasing the zfsd project branch to head, after which I'll push SpectraLogic's recent changes. See, all you have to do is complain loudly enough :p I was sad more than anything. I'd been waiting for zfsd since the project was announced. :-) I'm glad to know we won't have to wait until 11.0. ___ 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 Ha! Very funny. I created a RAIDZ1 pool and by reading the man page for zpool, which states precisely how to create a hot spare for a given pool. I wasn't aware until now that this action was useless, and even dangerous. Well, bravo, I must admit, the man page does not give any kind of warning that one can not rely on a hot spare. oh The ZFS spare functinality basically just marks the drive as a spare, so you as the admin know what drive to use when replacement time comes I've been working on the handbook section on ZFS and made certain to mention that, I'll have to look at improving the man page as well, but as far as I know, the man page is imported from IllumOS, where spares do work. ZFSd is important and I hope to see more movement on it soon. -- Allan Jude ___ 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: FreeBSD 10 and zfsd.
On 2013-10-11 03:02, Johan Hendriks wrote: Johan Hendriks wrote: When i started using ZFS on FreeBSD I quickly found out that hot spares are not possible on FreeBSD. I was told that with zfsd it should be possible and that it would be included in FreeBSD 10. Is there some info about the zfsd function and how it could be used? regards Johan Hendriks Thanks all for the explanation and your time A notice in the handbook may be a good thing to let new FreeBSD users know that you can add spares, but that it is not a hot spare. So human action is required to activate the spare. regards Johan Hendriks ___ 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 That bit is in the zfs handbook project branch, it just isn't published yet -- Allan Jude ___ 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: FreeBSD 10 and zfsd.
On 2013-10-11 04:27, O. Hartmann wrote: On Fri, 11 Oct 2013 03:24:51 -0400 Allan Jude free...@allanjude.com wrote: On 2013-10-11 03:02, Johan Hendriks wrote: Johan Hendriks wrote: When i started using ZFS on FreeBSD I quickly found out that hot spares are not possible on FreeBSD. I was told that with zfsd it should be possible and that it would be included in FreeBSD 10. Is there some info about the zfsd function and how it could be used? regards Johan Hendriks Thanks all for the explanation and your time A notice in the handbook may be a good thing to let new FreeBSD users know that you can add spares, but that it is not a hot spare. So human action is required to activate the spare. regards Johan Hendriks ___ 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 That bit is in the zfs handbook project branch, it just isn't published yet ... so it isn't visible to the normal users. I would also appreciate a hint in the man page of zpool(8). Like Be aware: A spare declared vdev is not (yet) automatically replacing a faulty rendered drive. Human action is still required. It could save some trouble in prevention. Oliver Lyndon Nerenberg attached a patch for the man page earlier in the thread, and I have forwarded that to the docs team -- Allan Jude ___ 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: May you please add alias for nslookup?
On 2013-10-12 12:34, Julian H. Stacey wrote: RW wrote: On Sat, 12 Oct 2013 10:44:56 +0200 Ivan Voras wrote: explaning the user what has happened and optionally invoking host or dig. Actually dig has gone Rather cryptic for me so I looked: dig has gone from current src/usr.bin/dig nslookup dig host are all installed by either of current ports/dns/bind99 or ports/dns/bind-tools and has been replaced by the unbound utility drill. src/usr.bin/drill/ I agree with O.P. Zhifeng Hu's this is a very basic tools. Removing src/contrib/bind9 from FreeBSD-10 will get criticised as: Calls itself a server OS, but no name server out of the box! Please resist periodic urges to strip src/ towards just a tool set capable of rebuilding itself. Tossing expected tools (even if a port is more up to date secure) will annoy users, potential immigrants from other Unixes may try then toss FreeBSD. Cheers, Julian It is easier to keep bind up to date from ports. If you want DNSSEC support in 9, you have to replace the bind in base anyway bind is replaced with unbound, which providers most of the functionality required in most instances. I forget the exact numbers, but when I looked about 20 of the security advisories over the last 10 years have been because of bind. That is over 12% of all vulnerabilities. -- -- Allan Jude ___ 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: May you please add alias for nslookup?
On 2013-10-12 14:18, Allan Jude wrote: On 2013-10-12 12:34, Julian H. Stacey wrote: RW wrote: On Sat, 12 Oct 2013 10:44:56 +0200 Ivan Voras wrote: explaning the user what has happened and optionally invoking host or dig. Actually dig has gone Rather cryptic for me so I looked: dig has gone from current src/usr.bin/dig nslookup dig host are all installed by either of current ports/dns/bind99 or ports/dns/bind-tools and has been replaced by the unbound utility drill. src/usr.bin/drill/ I agree with O.P. Zhifeng Hu's this is a very basic tools. Removing src/contrib/bind9 from FreeBSD-10 will get criticised as: Calls itself a server OS, but no name server out of the box! Please resist periodic urges to strip src/ towards just a tool set capable of rebuilding itself. Tossing expected tools (even if a port is more up to date secure) will annoy users, potential immigrants from other Unixes may try then toss FreeBSD. Cheers, Julian It is easier to keep bind up to date from ports. If you want DNSSEC support in 9, you have to replace the bind in base anyway bind is replaced with unbound, which providers most of the functionality required in most instances. I forget the exact numbers, but when I looked about 20 of the security advisories over the last 10 years have been because of bind. That is over 12% of all vulnerabilities. des@'s blog adds another important point, bind10 required python. FreeBSD doesn't want to ship with python in base, so keeping bind wasn't really an option ___ 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: /usr/src/lib/msun errors
On 2013-10-12 21:23, Joe Nosay wrote: I am not top posting. Do not accuse me of this. I am upset and depressed and I do not need you to accuse me of something I am not doing. My system is shitting out on me. I have already told you what is happening. Stop accusing me of something I am not doing. On Sat, Oct 12, 2013 at 5:57 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: Please, do not top post. It loses context. On Sat, Oct 12, 2013 at 04:05:27PM -0400, Joe Nosay wrote: On Fri, Oct 11, 2013 at 11:22 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Fri, Oct 11, 2013 at 10:05:56PM -0400, Joe Nosay wrote: Is the ALPHA base stable enough to do porting of applications? Huh? What do you mean? People have been running freebsd-current for years and porting applications to FreeBSD. Alpha is simply a point in time for freebsd-current. I was rebuilding world using an older CURRENT base and the src from 10/07/13. The build kept breaking with libiconv, msun, and a few others. The problem you had with msun was caused by you adding additional options to CFLAGS in make.conf without actually understand what those options may do. This affected both the base and 3rd party. The system is still usable but it isn't stable enough for building a 3rd party application. Yes, it is stable enough. Remove your custom CFLAG options. If I reinstall the base with CURRENT from 10/07/13 to present, will it be stable enough for building 3rd party? Of course. But, you need to read src/UPDATING and ports/UPDATING. -- Steve ___ 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 Sorry, do you not know what 'top posting' is? The list just asks that you put your reply after the quoted text that you are replying to, instead of at the top of the email (above the quote) ___ 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: /usr/src/lib/msun errors
On 2013-10-13 00:06, Scot Hetzel wrote: On Sat, Oct 12, 2013 at 10:21 PM, Allan Jude free...@allanjude.com wrote: On 2013-10-12 21:23, Joe Nosay wrote: I am not top posting. Do not accuse me of this. I am upset and depressed and I do not need you to accuse me of something I am not doing. My system is shitting out on me. I have already told you what is happening. Stop accusing me of something I am not doing. : : : Sorry, do you not know what 'top posting' is? The list just asks that you put your reply after the quoted text that you are replying to, instead of at the top of the email (above the quote) Joe might not have realized it, but for us gmail users we have top posting by default. We have to hit the 3 dots (...) to expand the quoted text, delete the first line and then scroll down to the text we want to quote. It's a bit annoying. Luckily, in ThunderBird it is a setting per account, so I can have this account bottom post, and my business one for customers top post. I always love to get the complains from customers that my message shows up as an attachment because it was signed. ___ 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: Process stuck in D+ state
On 2013-10-13 15:10, Olivier Cochard-Labbé wrote: I've got a frequent problem on my desktop (FreeBSD 10.0-ALPHA5 #8 r256200): After few hours I can't acces to one of my folder: A simple ls in this folder stucks, and all filesystem information started after (df, fstat) stuck too in D+. SIGINFO report this usage for these processes: load: 0.15 cmd: ls 15716 [rpcrecon] 217.89r 0.00u 0.00s 0% 2440k load: 0.34 cmd: ls 15716 [connec] 2376.60r 0.00u 0.00s 0% 0k load: 0.40 cmd: ls 15716 [connec] 2379.80r 0.00u 0.00s 0% 0k load: 0.40 cmd: ls 15716 [connec] 2379.92r 0.00u 0.00s 0% 0k load: 0.37 cmd: ls 15716 [rpcrecon] 2850.26r 0.00u 0.00s 0% 0k load: 0.37 cmd: ls 15716 [rpcrecon] 2850.39r 0.00u 0.00s 0% 0k load: 0.40 cmd: fstat 15781 [rpcrecon] 2842.08r 0.00u 0.01s 0% 0k load: 0.21 cmd: fstat 15781 [rpcrecon] 2879.35r 0.00u 0.01s 0% 0k load: 0.21 cmd: fstat 15781 [rpcrecon] 2879.48r 0.00u 0.01s 0% 0k load: 0.21 cmd: fstat 15781 [rpcrecon] 2879.63r 0.00u 0.01s 0% 0k load: 0.24 cmd: df 15919 [connec] 1047.98r 0.00u 0.00s 0% 0k load: 0.22 cmd: df 15919 [connec] 1054.22r 0.00u 0.00s 0% 0k and the PS status: olivier15919 0.0 0.0 14400 16 7 D+7:06PM 0:00.01 df -h olivier15781 0.0 0.0 20708 16 6 D+6:26PM 0:00.02 fstat olivier15651 0.0 0.0 16784 16 4 D+6:25PM 0:00.00 ls My desktop use a geli system and JSU, nothing special, here are the mount point: /dev/ada1p3.eli on / (ufs, local, noatime, journaled soft-updates) devfs on /dev (devfs, local, multilabel) /dev/gpt/boot on /boot2 (ufs, local, noatime, soft-updates) What kind of commands can I use for getting more troubleshooting( information next time ? Thanks ___ 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 Looking at the process states, connect and rpcreconnect, seem to suggest something involving yp/nis or NFS or some such. try: ls -n (skip uid to symbolic name lookup) and see if it behaves any differently ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: support for first boot rc.d scripts
On 2013-10-13 18:58, Colin Percival wrote: Hi all, I've attached a very simple patch which makes /etc/rc: 1. Skip any rc.d scripts with the firstboot keyword if /var/db/firstboot does not exist, 2. If /var/db/firstboot and /var/db/firstboot-reboot exist after running rc.d scripts, reboot. 3. Delete /var/db/firstboot (and firstboot-reboot) after the first boot. The purpose of this is to support run on first boot rc.d scripts. These can be useful for both virtual machines and embedded systems; unlike conventional desktops and servers, these may have a lengthy gap between installing and turning on the system. As examples of what such scripts could do: * In Amazon EC2, I use a first boot script to download an SSH public key from EC2 so that users can log in to newly provisioned EC2 instances. * Now that (starting from 10.0-BETA1) it is possible to use FreeBSD Update to update everything on EC2 instances, I'm planning on writing a script which runs 'freebsd-update fetch install' when the system first boots, and then reboots if there were updates installed. (I imagine this would be useful to other embedded / VM providers too.) * Once packages are provided (properly) for 10.0 I'd like to allow people to specify a list of packages they want installed onto an EC2 instance and have them downloaded and installed when the EC2 instance launches. I'd like to get this into HEAD in the near future in the hope that I can convince re@ that this is a simple enough (and safe enough) change to merge before 10.0-RELEASE. Comments? ___ 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 This looks extremely useful. Thank you. ___ 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: Process stuck in D+ state
On 2013-10-14 16:53, Olivier Cochard-Labbé wrote: On Mon, Oct 14, 2013 at 1:14 AM, Allan Jude free...@allanjude.com wrote: Looking at the process states, connect and rpcreconnect, seem to suggest something involving yp/nis or NFS or some such. Oops, yes you've right, I've got an sub-folder on my homedir that was NFS mounted and the NFS server was poweroff without unmounting this sub-folder first. I need to check the NFS mount option for avoiding to stuck all the disk-related process once the NFS server disapear. Thanks for pointing this. Olivier my fstab nfs options: rw,bg,intr,soft,noatime -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
For those of you not aware, the latest version of the root-on-ZFS+GELI in bsdinstall patch shipped as part of FreeBSD 10.0-BETA1 today. Please test it and report any issues you have. There is one known issue (already patched in our repo), where if you do a GELI pool, the unencrypted /boot pool is not mounted properly once the system is up (a case where the /boot/zfs/zpool.cache is still useful) -- Allan Jude ___ 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: vmstat -z: zfs related failures on r255173
On 2013-10-15 07:53, Dmitriy Makarov wrote: Please, any idea, thougth, help! Maybe what information can be useful for diggin - anything... System what I'm talkin about has a huge problem: performance degradation in short time period (day-two). Don't know can we somehow relate this vmstat fails with degradation. Hi all On CURRENT r255173 we have some interesting values from vmstat -z : REQ = FAIL [server]# vmstat -z ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP ... skipped NCLNODE:528, 0, 0, 0, 0, 0, 0 space_seg_cache: 64, 0, 289198, 299554,25932081,25932081, 0 zio_cache: 944, 0, 37512, 50124,1638254119,1638254119, 0 zio_link_cache: 48, 0, 50955, 38104,1306418638,1306418638, 0 sa_cache:80, 0, 63694, 56, 198643,198643, 0 dnode_t:864, 0, 128813, 3, 184863,184863, 0 dmu_buf_impl_t: 224, 0, 1610024, 314631,157119686,157119686,0 arc_buf_hdr_t: 216, 0,82949975, 56107,156352659,156352659,0 arc_buf_t: 72, 0, 1586866, 314374,158076670,158076670,0 zil_lwb_cache: 192, 0,6354,7526, 2486242,2486242, 0 zfs_znode_cache:368, 0, 63694, 16, 198643,198643, 0 . skipped .. Can anybody explain this strange failures in zfs related parameters in vmstat, can we do something with this and is this really bad signal? Thanks! ___ 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 I am guessing those 'failures' are failures to allocate memory. I'd recommend you install sysutils/zfs-stats and send the list the output of 'zfs-stats -a' -- Allan Jude ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: support for first boot rc.d scripts
On 2013-10-15 15:33, Tim Kientzle wrote: Wonderful! This capability is long overdue. On Oct 13, 2013, at 3:58 PM, Colin Percival cperc...@freebsd.org wrote: As examples of what such scripts could do: More examples: I've been experimenting with putting gpart resize and growfs into rc.d scripts to construct images that can be dd'ed onto some medium and then automatically grow to fill the medium. I didn't think of that, that is a 'killer app' for rpi and other such devices, or any kind of 'embedded' image really When cross-installing ports, there are certain operations (e.g., updating 'info' database) that can really only be done after the system next boots. I'd like to get this into HEAD in the near future in the hope that I can convince re@ that this is a simple enough (and safe enough) change to merge before 10.0-RELEASE. Please. Tim ___ 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 -- Allan Jude ___ 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: Please shorten ZFS disk names.
On 2013-10-15 19:07, Glen Barber wrote:
On Tue, Oct 15, 2013 at 05:49:06PM -0500, James R. Van Artsdalen wrote:
BLACKIE:/root# uname -a
FreeBSD BLACKIE.housenet.jrv 10.0-BETA1 FreeBSD 10.0-BETA1 #0 r256428M:
Sun Oct 13 23:46:54 CDT 2013
r...@clank.housenet.jrv:/usr/obj/usr/src/sys/GENERIC amd64
This pool is on da{0,1,2,3,4,5,6,7} - I think, only da4 is sure
NAME
STATE READ WRITE CKSUM
z03
ONLINE 0 0 0
raidz2-0
ONLINE 0 0 0
diskid/DISK-%20%20%20%20%20%20%20%20%20%20%20%20Z300HSTK
[...]
Based on the hardware config that's either ada0p3 or ada1p3. Whichever
it is I want to mirror it onto the other but I don't the names to use
for src and dst.
You can set kern.geom.label.gptid.enable=0 in loader.conf(5), which will
use the gptid.
Glen
In this case, it is the disk_ident that is being used, not the GPT
label, so you want to set: kern.geom.label.disk_ident.enable=0 in
/boot/loader.conf and then zfs won't see that device alias, and will
show the expected device name
--
Allan Jude
___
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: What happened to nslookup?
On 2013-10-16 05:44, Daniel Kalchev wrote: On 16.10.13 08:42, Kevin Oberman wrote: nslookup(1) was deprecated about a decade ago because it often provides misleading results when used for DNS troubleshooting. It generally works fine for simply turning a name to an address or vice-versa. People should really use host(1) for simple lookups. It provides the same information and does it in a manner that will not cause misdirection when things are broken. Of course, host(1) is not a replacement for nslookup(1). nslookup is interactive, while host is not. This makes for a big difference in many usage scenarios. The decision to remove bind from base was poor, and not well communicated. Let's hope it will be reverted. 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 Bind 10 requires python. There is a good reason it was removed from base. -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-19 10:56, Johan Broman wrote: Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ 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 Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-19 11:31, Johan Broman wrote: On 19/10/13 17:23, Allan Jude wrote: On 2013-10-19 10:56, Johan Broman wrote: Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ 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 Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. Ah ok. A msgbox did appear but the drives that had the problem (ada2 and ada3) wasn't visible in the output. (not sure if the box itself has a size limit or maybe I was just unable to scroll down and see the errors?). The only visible output was that it was able to create labels on ada0 and ada1. /Johan ___ 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 Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to add a scrollbar but turns out that is not possible. The only indication that there is more message to read, is a small 'xx%' in the bottom right. We might have to look at breaking that output up or something. -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-19 11:55, Teske, Devin wrote: On Oct 19, 2013, at 8:43 AM, Teske, Devin wrote: On Oct 19, 2013, at 8:34 AM, Allan Jude wrote: On 2013-10-19 11:31, Johan Broman wrote: On 19/10/13 17:23, Allan Jude wrote: On 2013-10-19 10:56, Johan Broman wrote: Hi! Just tested the root-on-ZFS install option using FreeBSD 10 beta 1. I have 4 SATA drives in my server. I select all four of them in a RAIDZ1 setup. I hit enter to continue the installation and the zpool is created, but I'm then returned to the zpool selection screen again. It turned out that two of the drives had previously been used in a (Linux) software mirror setup and because of this they got activated in /dev/raid/r0. Because of this I ended up in an endless bsdinstall loop. Removing the raid device using the graid command resolved the situation. Now maybe this is working as designed, but there was no warning/alert to the fact that the devices couldn't be used. Perhaps a warning should be rasied in this situation? Thanks for all the great work on the new installer, really looking forward to FreeBSD 10! Cheers Johan ___ 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 Errors like that normally generate a msgbox dialog with the error output from whichever command failed. I'll have to dig into it and see where that problem is. I've seen other people have problems creating ZFS arrays after graid, but in that case it was an incomplete graid label causing a device to be locked but not appear in the graid status output. Ah ok. A msgbox did appear but the drives that had the problem (ada2 and ada3) wasn't visible in the output. (not sure if the box itself has a size limit or maybe I was just unable to scroll down and see the errors?). The only visible output was that it was able to create labels on ada0 and ada1. /Johan ___ 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 Ahh yes, you have to press 'page-down' to scroll the msgbox. I tried to add a scrollbar but turns out that is not possible. The only indication that there is more message to read, is a small 'xx%' in the bottom right. We might have to look at breaking that output up or something. The only reason for a msgbox widget to scroll is if it is displayed at maximum height or width of the screen and it *still* has more data to display than can be presented at-once. I should clarify... The zfsboot script doesn't use dialog(1) directly. It uses the bsdconfig API. That being said, msgbox widgets automatically scale their size to fit the content being displayed. So whenever a msgbox is thrown up using this API... the widget will never scroll unless the box can't be made big enough to hold the entire content (either the screen resolution or terminal size is too small; we maxed out the size of the widget; and there's still hidden content). But... While all of bsdconfig uses this API, hardly any of bsdinstall uses this API. If... however... the msgbox widget is *not* full-height or full-width yet... it is requiring you to scroll -- then we've found a bug. Can we get a screen shot? So we really need to nail down precisely which error box this is so that we can address whether the issue is in-fact an instance of using the old error-box handling instead of the auto-sizing API. So... With this described API, you should never have to scroll a box unless it can't fit all the data *and* you should be able to immediately identify when that becomes the case... 1. The widget spans the entire width of the screen. 2. The widget spans the entire height of the screen. 3. Both 1 and 2. It's in *those* cases that you should then *EXPECT* to find that the region can scroll with cursor keys and page up/down (look for the scroll percentage in the widget as Allan suggested. I don't want to see the scroll percentage doohickey *unless* the widget is auto-sized to full-width or full-height. Meaning, there's either a bug in the API or someone fell into a trap (there are a couple). the error output msgbox is huge, probably 100+ lines (the screen is what, 24 lines high, and with the ok button, top and bottom reserved space etc, can display maybe 18 lines at once) It contains all the shell output from everything we do, creating the gparts, setting up gnop, all of the redundant destroys etc. I don't think the TINY little % in the bottom right is really enough of an indicator to the user that they CAN scroll, let alone HOW to scroll (IIRC the arrow keys do not work, must use page down) -- Allan Jude ___ freebsd-current@freebsd.org mailing list
Re: Zpool not recognized after disk moved to different name
On 2013-10-20 13:07, Justin Hibbits wrote: Hi, I'm migrating a system exhibiting the click of death to a new hard drive, on PowerPC, and in the process migrating to zfs. I set up the system, then pulled the old drive out. Now, the spool that was on ada1s5 is now on ada0s5, and zfs won't recognize this pool. I can't recreate the pool, it says it is too dangerous. Is there any way to reactivate this pool after the disk name change? Thanks, Justin ___ 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 ZFS puts (5 copies of) a label on each disk, and will track them when they move device names. Your problem must be something else -- Allan Jude ___ 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: Zpool not recognized after disk moved to different name
On 2013-10-20 13:07, Justin Hibbits wrote: Hi, I'm migrating a system exhibiting the click of death to a new hard drive, on PowerPC, and in the process migrating to zfs. I set up the system, then pulled the old drive out. Now, the spool that was on ada1s5 is now on ada0s5, and zfs won't recognize this pool. I can't recreate the pool, it says it is too dangerous. Is there any way to reactivate this pool after the disk name change? Thanks, Justin ___ 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 Please provide the output of the following commands: gpart show zpool import zdb -l /dev/each device/slice you think might be the ZFS -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-21 11:45, Johan Broman wrote: Hi! Sorry for the delayed answer. I've patched zfsboot and rebuilt the release. I now get an error message that ada2 can't be used, which is correct. Good stuff! :) ( I've recreated the test environment using a KVM guest with four SATA drives instead of the server I was using. I makes it easier to test stuff. ) Here's the screenshot: http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.png Maybe one should be unable to select drives that are part of a graid in the first place? Or is that out-of-scope for bsdinstall at this point? (As I guess that requires too many changes/new lines) Cheers Johan On 19/10/13 22:20, Teske, Devin wrote: On Oct 19, 2013, at 10:07 AM, Johan Broman wrote: I recreated the graid mirror on ada2 and ada3 and reran the installation. I'm unable to scroll the msgbox using PgDn or arrow keys. There is no indication that the action failed and I'm returned to the ZFS setup screen if I hit OK. I have screen shots (taken with my phone) of the msgbox and ps auxwww output. Let me know what kind of debug info you would like. I've put the screen shots here: http://212.181.212.146/bsdinstall I've added a patch to fix debugging in the zfsboot script... http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ Feedback welcome. Johan,... Can you see if the patch sheds some better light as to what's failing? The patch won't fix the problem, but it should give us an accurate error message so that we can learn what precisely is returning an error status. Thanks in advance. I do notice that Devin's manually prefixing the error message with the tool name, is partially redundancy when the tool does it it self, but we can't always be sure it will do that. the graid thing is rather hard to detect, especially when it is a faulted array that doesn't even appear in graid status etc. -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-21 12:04, Teske, Devin wrote: On Oct 21, 2013, at 8:50 AM, Allan Jude wrote: On 2013-10-21 11:45, Johan Broman wrote: Hi! Sorry for the delayed answer. I've patched zfsboot and rebuilt the release. I now get an error message that ada2 can't be used, which is correct. Good stuff! :) ( I've recreated the test environment using a KVM guest with four SATA drives instead of the server I was using. I makes it easier to test stuff. ) Here's the screenshot: https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.pngk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0As=f6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dcf6c66ad91564a8ce99 Maybe one should be unable to select drives that are part of a graid in the first place? Or is that out-of-scope for bsdinstall at this point? (As I guess that requires too many changes/new lines) Cheers Johan On 19/10/13 22:20, Teske, Devin wrote: On Oct 19, 2013, at 10:07 AM, Johan Broman wrote: I recreated the graid mirror on ada2 and ada3 and reran the installation. I'm unable to scroll the msgbox using PgDn or arrow keys. There is no indication that the action failed and I'm returned to the ZFS setup screen if I hit OK. I have screen shots (taken with my phone) of the msgbox and ps auxwww output. Let me know what kind of debug info you would like. I've put the screen shots here: https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstallk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0As=6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1 I've added a patch to fix debugging in the zfsboot script... https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0As=1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aabe170bb80e31bca6d9 Feedback welcome. Johan,... Can you see if the patch sheds some better light as to what's failing? The patch won't fix the problem, but it should give us an accurate error message so that we can learn what precisely is returning an error status. Thanks in advance. I do notice that Devin's manually prefixing the error message with the tool name, is partially redundancy when the tool does it it self, but we can't always be sure it will do that. The next patchset will fix that. I'm dropping the tool name from the msgbox contents and putting it in the title (e.g., 'Error: gpart) that way... even if the tool spits out its own name (or not), we'll know what exactly what was going on by looking at the title. the graid thing is rather hard to detect, especially when it is a faulted array that doesn't even appear in graid status etc. I believe the idea behind the script is that whatever you tell it to use will be destroyed. Allan, maybe perhaps we could add some code that attempts to dis- assemble a graid to make the disk usable? Johan, what would you be more apt to expect? That it killed your graid or that it gave an error? (/me thinks what the recourse to the error might entail -- going to partedit?) Your recourse would be switching to the shell (control+alt+f4) and destroying the graid. I am a little hesitant to go destroying graids unprompted. If we had the geom.confxml parsing, we might be able to detect it and ask the user what to do -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-21 12:19, Teske, Devin wrote: On Oct 21, 2013, at 9:06 AM, Allan Jude wrote: On 2013-10-21 12:04, Teske, Devin wrote: On Oct 21, 2013, at 8:50 AM, Allan Jude wrote: On 2013-10-21 11:45, Johan Broman wrote: Hi! Sorry for the delayed answer. I've patched zfsboot and rebuilt the release. I now get an error message that ada2 can't be used, which is correct. Good stuff! :) ( I've recreated the test environment using a KVM guest with four SATA drives instead of the server I was using. I makes it easier to test stuff. ) Here's the screenshot: https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.pngk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0As=f6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dcf6c66ad91564a8ce99 Maybe one should be unable to select drives that are part of a graid in the first place? Or is that out-of-scope for bsdinstall at this point? (As I guess that requires too many changes/new lines) Cheers Johan On 19/10/13 22:20, Teske, Devin wrote: On Oct 19, 2013, at 10:07 AM, Johan Broman wrote: I recreated the graid mirror on ada2 and ada3 and reran the installation. I'm unable to scroll the msgbox using PgDn or arrow keys. There is no indication that the action failed and I'm returned to the ZFS setup screen if I hit OK. I have screen shots (taken with my phone) of the msgbox and ps auxwww output. Let me know what kind of debug info you would like. I've put the screen shots here: https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstallk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0As=6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1 I've added a patch to fix debugging in the zfsboot script... https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0As=1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aabe170bb80e31bca6d9 Feedback welcome. Johan,... Can you see if the patch sheds some better light as to what's failing? The patch won't fix the problem, but it should give us an accurate error message so that we can learn what precisely is returning an error status. Thanks in advance. I do notice that Devin's manually prefixing the error message with the tool name, is partially redundancy when the tool does it it self, but we can't always be sure it will do that. The next patchset will fix that. I'm dropping the tool name from the msgbox contents and putting it in the title (e.g., 'Error: gpart) that way... even if the tool spits out its own name (or not), we'll know what exactly what was going on by looking at the title. the graid thing is rather hard to detect, especially when it is a faulted array that doesn't even appear in graid status etc. I believe the idea behind the script is that whatever you tell it to use will be destroyed. Allan, maybe perhaps we could add some code that attempts to dis- assemble a graid to make the disk usable? Johan, what would you be more apt to expect? That it killed your graid or that it gave an error? (/me thinks what the recourse to the error might entail -- going to partedit?) Your recourse would be switching to the shell (control+alt+f4) and destroying the graid. I am a little hesitant to go destroying graids unprompted. If we had the geom.confxml parsing, we might be able to detect it and ask the user what to do Well, my concern with going and asking about each/every configuration before we clear it... Hasn't the user already answered a Last Chance! dialog giving the go- ahead to nuke any/all data *and* configurations on a drive? I guess that makes sense, We offer the dialog to allow the user to investigate their disk in detail so they can be sure they picked the correct ones. the graid thing is the biggest gotcha because it picks up metadata written by the motherboard raid system, so you can have a graid configuration even if you have never booted freebsd before. #destroyallofthethings -- Allan Jude ___ 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: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On 2013-10-21 13:14, Teske, Devin wrote: On Oct 21, 2013, at 10:12 AM, Allan Jude wrote: On 2013-10-21 12:19, Teske, Devin wrote: On Oct 21, 2013, at 9:06 AM, Allan Jude wrote: On 2013-10-21 12:04, Teske, Devin wrote: On Oct 21, 2013, at 8:50 AM, Allan Jude wrote: On 2013-10-21 11:45, Johan Broman wrote: Hi! Sorry for the delayed answer. I've patched zfsboot and rebuilt the release. I now get an error message that ada2 can't be used, which is correct. Good stuff! :) ( I've recreated the test environment using a KVM guest with four SATA drives instead of the server I was using. I makes it easier to test stuff. ) Here's the screenshot: https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstall/Screenshot_2013-10-21.pngk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0As=f6fc4ec7c9d8b9486e897156dac5af7c3f64e3fae746dcf6c66ad91564a8ce99 Maybe one should be unable to select drives that are part of a graid in the first place? Or is that out-of-scope for bsdinstall at this point? (As I guess that requires too many changes/new lines) Cheers Johan On 19/10/13 22:20, Teske, Devin wrote: On Oct 19, 2013, at 10:07 AM, Johan Broman wrote: I recreated the graid mirror on ada2 and ada3 and reran the installation. I'm unable to scroll the msgbox using PgDn or arrow keys. There is no indication that the action failed and I'm returned to the ZFS setup screen if I hit OK. I have screen shots (taken with my phone) of the msgbox and ps auxwww output. Let me know what kind of debug info you would like. I've put the screen shots here: https://urldefense.proofpoint.com/v1/url?u=http://212.181.212.146/bsdinstallk=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0As=6322000e13ed155bda748698c4a0d54c9de7c29f5566affe202d7c5a29917cd1 I've added a patch to fix debugging in the zfsboot script... https://urldefense.proofpoint.com/v1/url?u=http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0Ar=Mrjs6vR4%2Faj2Ns9%2FssHJjg%3D%3D%0Am=B6jLX5vSxIfvyks3HH55lYWtfhRBpGZ3nVA65M%2FgmXM%3D%0As=1dc96a8b5450d27fe8210b361c9ed736ccd448f78df6aabe170bb80e31bca6d9 Feedback welcome. Johan,... Can you see if the patch sheds some better light as to what's failing? The patch won't fix the problem, but it should give us an accurate error message so that we can learn what precisely is returning an error status. Thanks in advance. I do notice that Devin's manually prefixing the error message with the tool name, is partially redundancy when the tool does it it self, but we can't always be sure it will do that. The next patchset will fix that. I'm dropping the tool name from the msgbox contents and putting it in the title (e.g., 'Error: gpart) that way... even if the tool spits out its own name (or not), we'll know what exactly what was going on by looking at the title. the graid thing is rather hard to detect, especially when it is a faulted array that doesn't even appear in graid status etc. I believe the idea behind the script is that whatever you tell it to use will be destroyed. Allan, maybe perhaps we could add some code that attempts to dis- assemble a graid to make the disk usable? Johan, what would you be more apt to expect? That it killed your graid or that it gave an error? (/me thinks what the recourse to the error might entail -- going to partedit?) Your recourse would be switching to the shell (control+alt+f4) and destroying the graid. I am a little hesitant to go destroying graids unprompted. If we had the geom.confxml parsing, we might be able to detect it and ask the user what to do Well, my concern with going and asking about each/every configuration before we clear it... Hasn't the user already answered a Last Chance! dialog giving the go- ahead to nuke any/all data *and* configurations on a drive? I guess that makes sense, We offer the dialog to allow the user to investigate their disk in detail so they can be sure they picked the correct ones. the graid thing is the biggest gotcha because it picks up metadata written by the motherboard raid system, so you can have a graid configuration even if you have never booted freebsd before. Hmmm... so what does one do in *that* situation? Go into the motherboard BIOS and disable on-board RAID features for the controller providing the disks-in-question? You can destroy the metadata with the graid delete command. I've only encountered once instance where 'graid status' didn't show any devices, but graid was blocking zfs from using the device until the graid was destroyed (the graid part was only discovered after generating an image out of the geom.confdot sysctl) -- Allan Jude ___ freebsd-current@freebsd.org mailing list http
Re: 10.0-BETA1 ZFS install -- /var/empty read-only
On 2013-10-23 09:38, Eric van Gyzen wrote: On 10/23/2013 08:30, Kimmo Paasiala wrote: On Wed, Oct 23, 2013 at 4:29 PM, Kimmo Paasiala kpaas...@gmail.com wrote: On Wed, Oct 23, 2013 at 4:25 PM, Eric van Gyzen e...@vangyzen.net wrote: I just installed 10.0-BETA1 using the [very cool] new automatic ZFS option. I noticed that /var/empty is not mounted read-only. I suspect it could be. I made it so, and sshd still seemed to work. Eric I don't think there's a standard for how to break down the ZFS pool to individual datasets. If the install made only a single dataset for /var you would then effectively get a read-write /var/empty. The *The same applies* applies if you install on UFS and don't assign a separate filesystem for /var/empty like the default install does in fact. There might not be a standard, but the installer does have a default set, which includes a separate filesystem for /var/empty. I imagine this was done specifically to make it read-only. Since that was not done, it seems like an oversight. Eric ___ 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 You have to be careful with marking the /var/empty read only, if you do it too soon the extract of base.txz fails. This might be a good use of Colin Percival's 'firstboot' script -- Allan Jude ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [rfc] removing the NDISulator
On 2013-10-23 13:35, Eitan Adler wrote: On Mon, Oct 21, 2013 at 6:29 PM, Adrian Chadd adr...@freebsd.org wrote: If there are drivers that people absolutely need fixed then they should stand up and say hey, I really would like X to work better! and then follow it up with some encouraging incentives. Right now the NDISulator lets people work _around_ this by having something that kind of works for them but it doesn't improve our general driver / stack ecosystems. I doubt most people prefer to use the ndisulator over a native driver. However, many people don't have the skills, time, or money to provide the incentives you are talking about. At this point ndisulator provides a means to an end: working wireless and it isn't causing significant strain on the project in terms of development effort. Our end users are not always developers and I think removing this feature will hurt more than it will help. I think the point Adrian is trying to make, is that the NDISulator needs a maintainer, and rather than someone working on that hack, that person should spend their time on native drivers. As someone earlier in the thread pointed out, it doesn't seem that many drivers are NDISulatable anymore. The proposal is to remove it from 11 (2 years away). I am all for keeping it, if it works, but if it is unmaintained, what state will it be in 2 years from now? -- Allan Jude ___ 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: FreeBSD 10 and zfsd
On 2013-10-28 03:35, Johan Hendriks wrote: Johan Hendriks schreef: When i started using ZFS on FreeBSD I quickly found out that hot spares are not possible on FreeBSD. I was told that with zfsd it should be possible and that it would be included in FreeBSD 10. Is there some info about the zfsd function and how it could be used? regards Johan Hendriks On the wiki page Whats new for FreeBSD 10 https://wiki.freebsd.org/WhatsNew/FreeBSD10 under Other changes zfsd is mentioned as beeing part of 10.0 ZFS fault monitoring and management daemon, http://svn.freebsd.org/changeset/base/222836 Maybe it should be removed from that page. regards Johan ___ 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 There has been quite a bit of activity in zfsd recently: http://freshbsd.org/search?branch=PROJECT_ZFSDamp;project=freebsd But, I don't think it will make it into 10.0-RELEASE. It was discussed quite a bit during the ZFS BOF at vBSDCon, and there is active work to upstream stuff from SpectraLogic The wiki is not really meant to be definitive, we'll have to see. -- Allan Jude ___ 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: ZFS txg implementation flaw
On 2013-10-28 14:16, Slawa Olhovchenkov wrote: On Mon, Oct 28, 2013 at 10:45:02AM -0700, aurfalien wrote: On Oct 28, 2013, at 2:28 AM, Slawa Olhovchenkov wrote: I can be wrong. As I see ZFS cretate seperate thread for earch txg writing. Also for writing to L2ARC. As result -- up to several thousands threads created and destoyed per second. And hundreds thousands page allocations, zeroing, maping unmaping and freeing per seconds. Very high overhead. In systat -vmstat I see totfr up to 60, prcfr up to 20. Estimated overhead -- 30% of system time. Can anybody implement thread and page pool for txg? Would lowering vfs.zfs.txg.timeout be a way to tame or mitigate this? vfs.zfs.txg.timeout: 5 Only x5 lowering (less in real case with burst writing). And more fragmentation on writing and etc. ___ 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 From my understanding, increasing the timeout so you are doing fewer transaction groups, would actually be the way to increase performance, at the cost of 'bursty' writing and the associated uneven latency. -- Allan Jude ___ 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: ZFS txg implementation flaw
On 2013-10-28 14:25, aurfalien wrote: On Oct 28, 2013, at 11:16 AM, Slawa Olhovchenkov wrote: On Mon, Oct 28, 2013 at 10:45:02AM -0700, aurfalien wrote: On Oct 28, 2013, at 2:28 AM, Slawa Olhovchenkov wrote: I can be wrong. As I see ZFS cretate seperate thread for earch txg writing. Also for writing to L2ARC. As result -- up to several thousands threads created and destoyed per second. And hundreds thousands page allocations, zeroing, maping unmaping and freeing per seconds. Very high overhead. In systat -vmstat I see totfr up to 60, prcfr up to 20. Estimated overhead -- 30% of system time. Can anybody implement thread and page pool for txg? Would lowering vfs.zfs.txg.timeout be a way to tame or mitigate this? vfs.zfs.txg.timeout: 5 Only x5 lowering (less in real case with burst writing). And more fragmentation on writing and etc. So leave it default in other words. Good to know. - aurf ___ 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 The default is the default for a reason, although the original default was 30 -- Allan Jude ___ 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: ZFS txg implementation flaw
On 2013-10-28 16:48, Slawa Olhovchenkov wrote: On Mon, Oct 28, 2013 at 02:28:04PM -0400, Allan Jude wrote: On 2013-10-28 14:16, Slawa Olhovchenkov wrote: On Mon, Oct 28, 2013 at 10:45:02AM -0700, aurfalien wrote: On Oct 28, 2013, at 2:28 AM, Slawa Olhovchenkov wrote: I can be wrong. As I see ZFS cretate seperate thread for earch txg writing. Also for writing to L2ARC. As result -- up to several thousands threads created and destoyed per second. And hundreds thousands page allocations, zeroing, maping unmaping and freeing per seconds. Very high overhead. In systat -vmstat I see totfr up to 60, prcfr up to 20. Estimated overhead -- 30% of system time. Can anybody implement thread and page pool for txg? Would lowering vfs.zfs.txg.timeout be a way to tame or mitigate this? vfs.zfs.txg.timeout: 5 Only x5 lowering (less in real case with burst writing). And more fragmentation on writing and etc. ___ 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 From my understanding, increasing the timeout so you are doing fewer transaction groups, would actually be the way to increase performance, at the cost of 'bursty' writing and the associated uneven latency. This (increasing the timeout) is dramaticaly decreasing read performance by very high IO burst. It shouldn't affect read performance, except during the flush operations (every txg.timeout seconds) If you watch with 'gstat' or 'gstat -f ada.$' you should see the cycle reading quickly, then every txg.timeout seconds (and for maybe longer), it flushes the entire transaction group (may be 100s of MBs) to the disk, this high write load may make reads slow until it is finished. Over the course of a full 60 seconds, this should result in a higher total read performance, although it will be uneven, slower during the write cycle. -- Allan Jude ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] libdispatch (aka Grand Central Dispatch) in base
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-10-29 22:29, Freddie Cash wrote: On Oct 29, 2013 7:21 PM, Teske, Devin devin.te...@fisglobal.com wrote: On Oct 29, 2013, at 7:17 PM, Freddie Cash wrote: On Oct 29, 2013 7:07 PM, Teske, Devin devin.te...@fisglobal.com wrote: Hi all, I'd like to bring up the discussion for topic.. Importing libdispatch (aka Apple's Grand Central Dispatch) into base (contrib?). Hasn't this been done already? There's mention of it in the archives from 2009/2010. There was a port by Robert Watson et al to 8.1 mentioned in the quarterly status reports, and indications it would be imported after 8.1-release. I knew about the port, and I had heard about previous efforts, but when I go scrounging around HEAD, I can't find it. Let alone older branches. Hrm, maybe it hasn't been imported yet (Google search of svnweb.FreeBSD.orgonly shows the ports branch). And looks like the port hasn't been touched in 2 years. I just remembered reading about it and found the quarterly report in my mail archive. ___ 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 There is a wiki page that provides a bit of information: https://wiki.freebsd.org/GCD But it seeps the last time the port was touched was over 2 years ago - -- Allan Jude -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJScHAWAAoJEJrBFpNRJZKf+wUP/3GiwHEu0B6Pjpu5bMvRnUfr lUzRPhU7WNyrIGWhtgSsWFaDAtXXzSCC9shQXJlEyifSroMHH2Xx0DJcqwwBfNsY yeyaYIygxhHw7ULjEY/E+z0uzU2YSe1MzLCehY/ZeT02+oGEtB3cnHHDXaBffuf1 lM8EOyu7n3j/eLmA1LfPhhpjjfg36JD++nJaoJLYt1CkoJqiAMDTAV5YFonOiNzw jgNrNOvmC0YhD0Civ2maztzDz427ScALgNqibyjq7bLQa8hSkZXfTZW4rqCvsypl pNb6W1RtMEje56tUtGFmLDljs93NrczevRs0LXalrnFRoqGaprdPqVqGU6A9bT00 hPaefEiFRPOwsyXcHAXMmyfX4TAhyyyhM35Vsb+7QLcfarV/cOyzvw98jJhtkS9N CKL2I7hV7snbGqk60F7C28bBtnkv4DuIM+ULcLy4LXZaqXuT/VkDQidQkwvc+34m cab9K69fuxW4AuFitJrqbrU3hxM8OUian67KCTXbb4JwHlICFwHnPgrOoUElzjEd y8WkSIMUjLbge5vTBHu/IPS0UwXSFyo07upF7OorfP74kxslSJjd9Mbh2B3k34Yv dtmGwgQ0UYwXW+gSxuNSw87CZRHQvNsabU9jeJCMej9XsZTz2bGR3f4K+k8+reY9 uHlzTFKiLqgF7TGlq1qJ =jnbq -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: Official FreeBSD Binary Packages now available for pkgng
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-10-31 16:47, Eric Camachat wrote:
It doesn't work with our (microsoft) proxy server, see below.
root@basay:/usr/local/etc/pkg/repos # pkg update -f
Updating repository catalogue
pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/digests.txz: Service
Unavailable
pkg: No digest falling back on legacy catalog format
pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/repo.txz: Service
Unavailable
root@basay:/usr/local/etc/pkg/repos #
Eric
On Wed, Oct 30, 2013 at 7:10 PM, Bryan Drewery bdrew...@freebsd.org
wrote:
We are pleased to announce that official binary packages are now
available for pkg, the next generation package management tool for
FreeBSD.
Pkg allows you to either use ports with portmaster/portupgrade or to
have binary remote packages without ports.
We have binary packages available for i386 and amd64 on
8.3,8.4,9.1,9.2,10.0 and 11 (head).
Pkg will be the default starting in FreeBSD 10.
The pkg_install suite of tools pkg_create(1), pkg_add(1), and
pkg_info(1) (which ports also use), are deprecated and will be
discontinued in roughly 6 months. A communication regarding the
deprecation of the pkg_install suite of tools will be sent separately in
the future.
If you are currently not using pkg and wish to, run the following as
root. Be sure not to add WITH_PKGNG=yes to your make.conf until after
pkg is installed.
# cd /usr/ports/ports-mgmt/pkg make install clean
# echo WITH_PKGNG=yes /etc/make.conf
# pkg2ng
You can now either continue to use ports with portmaster/portupgrade, as
before or switch to using binary packages only.
To use binary packages:
1. Ensure your pkg(8) is up-to-date. 'pkg -v' should say at least
1.1.4_8. If it does not, first upgrade from ports.
2. Remove any repository-specific configuration from
/usr/local/etc/pkg.conf, such as PACKAGESITE, MIRROR_TYPE, PUBKEY.
If this leaves your pkg.conf empty, just remove it.
3. mkdir -p /usr/local/etc/pkg/repos
4. Create the file /usr/local/etc/pkg/repos/FreeBSD.conf with:
FreeBSD: {
url: http://pkg.FreeBSD.org/${ABI}/latest;,
mirror_type: srv,
enabled: yes
}
* Note that pkg.FreeBSD.org does not have a browsable web page on it and
does not have a DNS A record. This is intended as it is an SRV host.
pkg(8) knows how to properly use it. You can use 'pkg search' to browse
the available packages in the repository.
Mirrors you may use instead of the global pkg.FreeBSD.org:
pkg.eu.FreeBSD.org
pkg.us-east.FreeBSD.org
pkg.us-west.FreeBSD.org
Your system is now ready to use packages!
Refer to the handbook section on pkgng for usage at
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pkgng-intro.html
.
Also see 'man pkg' for examples or 'pkg help'.
Packages are built weekly from a snapshot of the Ports Collection every
Wednesday morning 01:00 UTC. They typically will be available in the
repository after a few days.
Pkg 1.2 will be released in the coming month which will bring many
improvements including officially signed packages. FreeBSD 10's pkg
bootstrap now also supports signed pkg(8) installation.
Regards,
Bryan Drewery
on behalf of portmgr@
___
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
I am guessing the proxy passes the full HTTP request, without doing the
SRV lookup, and then can't find the A record.
I wonder if the http+pkg:// protocol can solve this, likely will require
a patch to fetch to implement the logic to do the dns lookup and make
the proxies request for the real hostname
- --
Allan Jude
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJScsXlAAoJEJrBFpNRJZKfvGUP/juCxjR30BPycq1wsPg/p1X9
oVorgOaFYYEo5Wg13J2UNj0vkOcFjl9hIdjKh3NmzTP9VOEbJPX4/WSFJOLdxsO+
FFmmYoPywQUnfyAgIJiWbFokL4JptDduvAO98oRm+DHUtTS1yMm4bnGt+Rkt4uuH
km6doAh79QuOEduTCA7Q2NLQxU2j1BFQ8dcGxMjtFbGm+o3QJX5/eToQdtCH6p/S
tQ2JnfCdV34gl1S8S7RrxxPqU9P5iKy65/w3B2L/DPd4NCJTJmge9C2uUIHMG/oE
+OK2ti/ya6u4WBxAJaPckCmSa72hOSp9aqTjztrhD7S2b9K3kdkMUKj9kTNViiAe
D6XW+glcu/H9W2ruWzQLAJMpjfPF1I+4anufbVvKhu++ENEpV5LUEgx+Iyp5thuY
ifNptmUXeoQiDHNUfrqlaT31yejY0nhlY2nGqmlnPNjLCMLo99RY5H9nPWUu/J4d
5Z0zuhT+WDjFR8t+WhXWGdIBlPvuk1Uqk+yGXKN5qIdp/J3Cs9U5Lgo4biXZP7nR
7iTNsRt4GpCTBB5fAzqSanezZGA2ekD/D9lDVwGnudXhVArKlPrCadiCbQQSkhgY
CZYQ96Tp39YV9i2J98/HhEtxWZQt9ibC/zSOHu142d89V1n0Ud/vLVc7eE256pW1
Ce3QQJRlg6rUVQuSWtf/
=cv2E
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org
Re: Overriding sector size on disks?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-11-01 22:45, Adrian Chadd wrote: Hi! I have an odd problem. That, honestly, can't be that odd. I have a bunch of SATA disks that when plugged into the laptop directly, show up as 512 byte sectors. But if I plug it in via this iomega USB caddy, they show up as 4k sector devices. Because of this, partitions just plainly don't work. Has anyone faced this? Is there some trick to do to get these things to go back to being 512 byte sector devices so one can use them? Similarly, because they show up as 512 byte sector devices on macosx/linux, they can read/write NTFS/MSDOS partitions on the thing. But if I plug it into freebsd, it shows up as a 4k sector device and things plainly don't work. Thanks! -adrian ___ 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 I use gnop -S 4096 to force 4k sectors when creating ZFS pools I imagine you might be able to do gnop -S 512 to go the other way, although I am not sure how to handle that for constant use. - -- Allan Jude -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSdG2VAAoJEJrBFpNRJZKfGn0QAKcMLkJnLO9p+F8X0a443EaW jWTZAMgkP8Uo/VwLCCqHBBtZxk5pyviEdqcTJvzVYv2x6FE/WE8HlyIXjbyzZNoa zCU50plfSsxnk/G02TAuFRNmKPWvSw0oZVwvHC6+jwo0G9WIoVwupwNYdWLnfGCw MuwysQi7MqlSqnDmx2naEPbbiNyPW0pWDnjHHy5bf01Jqao9uPtdGgG48/fGhYxb +ViWGCVS+A5isMqDjVuW1QUetazu/1Kd1uycdWDGqTXfuzQ9/XBpubw7itYV9fn2 HL8ksQoEIye4516jEP/VLCGyElI9BJxW6QOxPGibpxZkyHV0DiMlR1yfLdV5rChb 1jTXwGYqfOtORKVCWOOUhoXeOvdZFnOLt8Lb7ckhoyNh2lh0v/pbuVAXC3KE0vSt BwpgHYqATdlZrF2G5RmIWykxUgEVt4KJ2Fn0/Q6ZMB9nTMhnEGafhMOYd2xgi474 Z82y79c95wb07dchrWCNeBQydw/paNqR4BjN6toS7OvFRipf4IcjuaFeLGWAY0GW jN6gTZXRLzpnYxgSqKVaNcaPces8tdestfzrfKn3E4+iuurrs/aerdsv6YsagV36 Poi2dPv4bWd7s26uK2YvBVTtGADydDHHSDd1J2BGJPooY2i2blfWsZ8gNDIzp1KV WXPfz6tWcHifrUl/SGfZ =lHXF -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: (r257598) panic: Assertion tmp-tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316
On 2013-11-04 09:35, Bryan Drewery wrote: 11.0-CURRENT #87 r257598 During a poudriere build. It creates a tmpfs, builds a port in a jail using that tmpfs and then removes the tmpfs and recreate the tmpfs before building the next port. panic: Assertion tmp-tm_pages_used == 0 failed at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 cpuid = 9 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1247ee57a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1247ee5850 vpanic() at vpanic+0x126/frame 0xfe1247ee5890 kassert_panic() at kassert_panic+0x136/frame 0xfe1247ee5900 tmpfs_unmount() at tmpfs_unmount+0x163/frame 0xfe1247ee5930 dounmount() at dounmount+0x41f/frame 0xfe1247ee59b0 sys_unmount() at sys_unmount+0x356/frame 0xfe1247ee5ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe1247ee5bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1247ee5bf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8008a02fa, rsp = 0x7fffd198, rbp = 0x7fffd2b0 --- Uptime: 44m40s (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x808bcf87 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:447 #2 0x808bd495 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:754 #3 0x808bd326 in kassert_panic (fmt=value optimized out) at /usr/src/sys/kern/kern_shutdown.c:642 #4 0x81e159d3 in tmpfs_unmount (mp=0xf810502cd660, mntflags=value optimized out) at /usr/src/sys/modules/tmpfs/../../fs/tmpfs/tmpfs_vfsops.c:316 #5 0x8095e1af in dounmount (mp=0xf810502cd660, flags=134742016, td=0xf8013d57a490) at /usr/src/sys/kern/vfs_mount.c:1324 #6 0x8095dd66 in sys_unmount (td=0xf8013d57a490, uap=0xfe1247ee5b80) at /usr/src/sys/kern/vfs_mount.c:1212 #7 0x80cb7d75 in amd64_syscall (td=0xf8013d57a490, traced=0) at subr_syscall.c:134 #8 0x80c9c90b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #9 0x0008008a02fa in ?? () Not sure if it is related, but I had a similar looking panic on a 10.0-BETA1 machine after doing a zfs receive: Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0x378 fault code= supervisor read data, page not present instruction pointer = 0x20:0x8089bf51 stack pointer = 0x28:0xfe1835d715d0 frame pointer = 0x28:0xfe1835d71650 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 44435 (zfs) trap number = 12 panic: page fault cpuid = 5 KDB: stack backtrace: #0 0x808e7580 at kdb_backtrace+0x60 #1 0x808af065 at panic+0x155 #2 0x80c8e292 at trap_fatal+0x3a2 #3 0x80c8e569 at trap_pfault+0x2c9 #4 0x80c8dcf6 at trap+0x5e6 #5 0x80c75022 at calltrap+0x8 #6 0x8094a32b at vflush+0x48b #7 0x8189e682 at zfs_umount+0x112 #8 0x809434f5 at dounmount+0x4b5 #9 0x80943004 at sys_unmount+0x3d4 #10 0x80c8eb87 at amd64_syscall+0x357 #11 0x80c7530b at Xfast_syscall+0xfb -- Allan Jude signature.asc Description: OpenPGP digital signature
cron(8) improvement
This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 2013-11-05 13:21, Mark Felder wrote: On Tue, Nov 5, 2013, at 11:37, Nikolai Lifanov wrote: On 11/05/13 12:31, Allan Jude wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. Shouldn't we encourage packages to use periodic(8) when possible? Yes but our default periodic configuration in /etc/crontab is only configured to be as granular as daily. If this is something that should run hourly or at very strange intervals then cron is a better choice. If the application is installing its own user they could install their own crontab file in /var/cron/tabs. I'm certain I've seen a couple ports do this. ___ 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 I don't have a specific example off the top of my head, but I am sure there are some daemons that needs to do something at some interval as root. Personally I am not so sure about having a package create a crontab automatically. It seems like a POLA violation, but it is also something that seems to be expected by some modern applications. I assume it is mostly handled by pkg-message currently, and maybe it is best to continue that way, but having the additional flexibility may be very useful. If for nothing else, it would be a lot prettier than the way I currently manage crontabs using puppet. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: [Review] bsdconfig pkgng integration
On 2013-11-06 13:32, Teske, Devin wrote: Subject says it all. I need a review on the attached patch. Come on, you know you want to... I think you missed something, you attached a 1 line diff -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: [Review] bsdconfig pkgng integration
On 2013-11-06 18:15, Teske, Devin wrote: On Nov 6, 2013, at 3:02 PM, Allan Jude wrote: On 2013-11-06 13:32, Teske, Devin wrote: Subject says it all. I need a review on the attached patch. Come on, you know you want to... I think you missed something, you attached a 1 line diff Oh I see... too much to review. Hey, don't all review it at once now... Seriously... come on... I'm asking for some feedback on the most important part of the patchset... The user-facing element. The least everyone can do is chime in with their favorite mirrors. So... please... Tell me if the mirror list is incomplete (I *know* there are more mirrors than that, and I *know* we want pkg.eu and pkg.us-* ... but I don't actually know what people want to see ... so please... feedback!) pkg.freebsd.org is a SVR record that lists the mirrors, and pkg automatically picks the correct one, so it is best to list only that 1 mirror. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 2013-11-06 20:49, Mark Felder wrote: On Wed, Nov 6, 2013, at 18:21, Tim Kientzle wrote: On Nov 5, 2013, at 9:31 AM, Allan Jude free...@allanjude.com wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. This is a good idea. We should do it. How and if this facility gets used is a separate question. Tools, not policy. Support for a cron.d directory is a tool that can be used in many ways. The policy of how it should be used is a separate discussion. (For example, whether or not ports or packages should install crontab files into /usr/local/etc/cron.d/ can be richly debated after that directory exists.) Ok, so we create that directory. Now nobody can use it in a port until FreeBSD 8.4 is EoL -- approximately June 30, 2015. We should be using the existing cron tabs directory *now*. We can't easily force older versions of FreeBSD to update their cron software or configuration to support that new directory. I'm not saying we shouldn't create it, just that we can't effectively use it for 2 years. ___ 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 My use case is less about packages, and more about puppet, ansible etc. Puppet relies on these hideously large markers in the crontab files to programmatically add/remove crons, whereas a cron.d directory could be done nice and clean And in that case, the fact that it is not supported on 8.x does not bother me. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 2013-11-06 22:49, Kimmo Paasiala wrote: On Thu, Nov 7, 2013 at 4:27 AM, Allan Jude free...@allanjude.com wrote: On 2013-11-06 20:49, Mark Felder wrote: On Wed, Nov 6, 2013, at 18:21, Tim Kientzle wrote: On Nov 5, 2013, at 9:31 AM, Allan Jude free...@allanjude.com wrote: This came up in discussion on IRC and I thought I should throw it at the list so I don't forget. A user was asking how to do what linux cron does, where there is a directory /etc/cron.d/ that packages and add files to to create crontabs. Making FreeBSD's cron (Vixie Cron) include /etc/cron.d/ and /usr/local/etc/cron.d/ in the /etc/crontab format seems like a very useful feature, especially for pkg(8) as it makes it easy and safe to programatically add and remove crontabs as part of a package. This is a good idea. We should do it. How and if this facility gets used is a separate question. Tools, not policy. Support for a cron.d directory is a tool that can be used in many ways. The policy of how it should be used is a separate discussion. (For example, whether or not ports or packages should install crontab files into /usr/local/etc/cron.d/ can be richly debated after that directory exists.) Ok, so we create that directory. Now nobody can use it in a port until FreeBSD 8.4 is EoL -- approximately June 30, 2015. We should be using the existing cron tabs directory *now*. We can't easily force older versions of FreeBSD to update their cron software or configuration to support that new directory. I'm not saying we shouldn't create it, just that we can't effectively use it for 2 years. ___ 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 My use case is less about packages, and more about puppet, ansible etc. Puppet relies on these hideously large markers in the crontab files to programmatically add/remove crons, whereas a cron.d directory could be done nice and clean And in that case, the fact that it is not supported on 8.x does not bother me. -- Allan Jude What's wrong with using the existing tools for achieving the same effect? Periodic can be adapted to do exactly what you're describing as noted above by adding an hourly (even minutely? :D ) periodic run. Also periodic already has support for ports installing their own jobs under /usr/local/etc/periodic.d that can be enabled/disabled in periodic.conf. -Kimmo Programmatically installing a cron that runs at odd intervals (our use case, on minutes 9,24,39,54 of each hour, manually staggered across groups of hosts). To enable a new periodic run, you have to edit the /etc/crontab file. I could add my cronjobs there directly, or via the crontab command (how puppet does it now), but i'd rather drop files in a directory, so they can be more easily removed or updated. From a management perspective, when dealing with 100s of machines, it is just a much nicer way to do it. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 2013-11-07 07:11, Kimmo Paasiala wrote:
On Thu, Nov 7, 2013 at 6:43 AM, Lyndon Nerenberg lyn...@orthanc.ca wrote:
On Nov 6, 2013, at 7:49 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
What's wrong with using the existing tools for achieving the same
effect? Periodic can be adapted to do exactly what you're describing
as noted above by adding an hourly (even minutely? :D ) periodic run.
Periodic is geared towards periodic system maintenance tasks. Once per day,
once per week, once per month. It doesn't deal with tasks that need to be
fired off at arbitrary intervals.
As you say, it could be adapted to run things with per-minute granularity,
but it wouldn't scale well. For per-minute granularity you would have to
fire off a periodic run every minute. That's five times the rate that
atrun(8) kicks off at. That's a lot of overhead for small, embedded, or
power constrained systems. And to get the time-granularity cron has, you
would have to re-implement cron(8)s dispatch control as a set of shell
functions. That's just silly.
--lyndon
Well ok, I get your point. I guess there's no other option than to add
support for a cron.d directory for crontab -snippets. I'd however like
to emphasize one thing that has been noted already:
- Snippets installed by ports should be disabled by default and
enabled only selectively by variables in rc.conf(5) or some other
configuration file to mirror what periodic(8) is doing now. This is
an absolute must because having them enabled by default is a recipe
for disaster. Compare this to services installed by ports, none of
them are enabled by default.
-Kimmo
___
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
Right. The best way to handle this is likely to have the ports install
the example cron to ${PREFIX}/share/portname/ or wherever else they
normally put examples, with instructions in the pkg-message on how to
enable the cron. The same way that ports that add something to apache
don't install to the apache etc/apache22/Includes/ directory, but
instead tell you to add the lines to a file there.
--
Allan Jude
signature.asc
Description: OpenPGP digital signature
Re: cron(8) improvement
On 2013-11-07 22:39, Lyndon Nerenberg wrote:
On Nov 7, 2013, at 9:13, Allan Jude free...@allanjude.com wrote:
Right. The best way to handle this is likely to have the ports install
the example cron to ${PREFIX}/share/portname/ or wherever else they
normally put examples, with instructions in the pkg-message on how to
enable the cron. The same way that ports that add something to apache
don't install to the apache etc/apache22/Includes/ directory, but
instead tell you to add the lines to a file there.
It’s probably better to have the port’s rc.d script verify the crontab is in
place, and install it if it’s not.
That might make sense, it really depends on the port and what the cron
is doing.
--
Allan Jude
signature.asc
Description: OpenPGP digital signature
Re: cron(8) improvement
On 2013-11-07 22:46, Kimmo Paasiala wrote: On Fri, Nov 8, 2013 at 5:42 AM, Lyndon Nerenberg lyn...@orthanc.ca wrote: On Nov 7, 2013, at 19:41, Allan Jude free...@allanjude.com wrote: it really depends on the port and what the cron is doing. Why? Can you give some specific examples? I don't like the idea of having untracked files installed by the rc(8) script. Why not install the cron.d snippet by default but leave everything in it commented out with instructions at the beginning to uncomment the contents to enable it? -Kimmo That seems logical, and that modification will also keep the file from being removed by the port if you did enable it (so upgrades won't silently delete the cron) -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 2013-11-07 23:48, Lyndon Nerenberg wrote: On Nov 7, 2013, at 19:46, Kimmo Paasiala kpaas...@gmail.com wrote: I don't like the idea of having untracked files installed by the rc(8) script. Why not install the cron.d snippet by default but leave everything in it commented out with instructions at the beginning to uncomment the contents to enable it? It’s un-necessarily complicated. The package manifest can specify both locations for the crontab file. If the copy isn’t made, at package removal the worst that will happen is a warning diagnostic will be printed about the missing file. —lyndon ___ 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 My use case is puppet etc, not ports/packages, so I'll leave the policy about packages up to portsmgr@, I just want a less sloppy way to manage crontabs with my orchestration system (and feature parity with Linux) -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 2013-11-09 19:18, Adrian Chadd wrote: On 9 November 2013 16:05, Daniel O'Connor docon...@gsoft.com.au wrote: On 10 Nov 2013, at 24:24, Matthew Seaman matt...@freebsd.org wrote: 2) Should ports / packages populate these cron.d directories? This is a much more interesting question. Effectively its asking if a port / package should provide some level of automatic configuration -- a thing that has previously been a no-no for FreeBSD. I think it would be OK if they installed entries in a disabled state. ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. I want the opposite. I'm kinda fed up installing packages that don't enable themselves. 'pkg install xorg' is not enough to get a working xorg. You have to enable hal and dbus and then restart (so things come up in the right order; manually starting them doesn't work) in order to get X working. If people are really worried about this, then I suggest a couple of package options for this stuff: * whether to default enable the package or not; * whether to default enable the cron scripts or not. Please install the cron scripts by default. Please then write up a simple rc.conf style setup where the cron scripts can check a config file to see if they should run. I don't want to have to freaking delete, rename, etc cron.d files. I just want the package files to be almost-untouched and have an option of working out of the box. Please, please allow an option to make this crap work out of the box already. -adrian ___ 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 Well, what about making these extra directories optional then? packages install the crontab entries, but crond ignores them unless you add: cron_flags=--scandir /etc/cron.d --scandir /usr/local/etc/cron.d or something to that effect As for packages enabling things, this seems like a good use of the /etc/rc.conf.d/ infrastructure, although it has a kind of odd structure, where the individual files are only included if the name of the service being started patches. So for example, /etc/rc.conf.d/sshd wouldn't be read when starting crond -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 2013-11-09 20:05, Adrian Chadd wrote: On 9 November 2013 16:28, Allan Jude free...@allanjude.com wrote: Well, what about making these extra directories optional then? packages install the crontab entries, but crond ignores them unless you add: cron_flags=--scandir /etc/cron.d --scandir /usr/local/etc/cron.d or something to that effect As for packages enabling things, this seems like a good use of the /etc/rc.conf.d/ infrastructure, although it has a kind of odd structure, where the individual files are only included if the name of the service being started patches. So for example, /etc/rc.conf.d/sshd wouldn't be read when starting crond Right. I'd rather it read in everything, but I realise that scales poorly. The other alternative is to have a config file populated with the contents of /etc/rc.conf.d/*, so to modify it you'd edit the individual config file(s), then do a commit operation to push it into the cache. If the cache file doesn't exist, it simply goes through and reads * if someone wanted to speed up the rcvar set, they could just replace it with a read from an sqlite table or an individual config file (as said above); the rcvar thing is -supposed- to just be attribute=value, so it can be stored anywhere. Note to previous poster: i think the existing policy sucks. :-) -adrian I suppose you could easily do something like: cat /etc/rc.conf.d/* /etc/rc.conf.cat and add rc.conf.cat to rc_conf_files -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 2013-11-09 20:55, Adrian Chadd wrote: On 9 November 2013 17:40, Allan Jude free...@allanjude.com wrote: On 2013-11-09 20:05, Adrian Chadd wrote: On 9 November 2013 16:28, Allan Jude free...@allanjude.com wrote: Well, what about making these extra directories optional then? packages install the crontab entries, but crond ignores them unless you add: cron_flags=--scandir /etc/cron.d --scandir /usr/local/etc/cron.d or something to that effect As for packages enabling things, this seems like a good use of the /etc/rc.conf.d/ infrastructure, although it has a kind of odd structure, where the individual files are only included if the name of the service being started patches. So for example, /etc/rc.conf.d/sshd wouldn't be read when starting crond Right. I'd rather it read in everything, but I realise that scales poorly. The other alternative is to have a config file populated with the contents of /etc/rc.conf.d/*, so to modify it you'd edit the individual config file(s), then do a commit operation to push it into the cache. If the cache file doesn't exist, it simply goes through and reads * if someone wanted to speed up the rcvar set, they could just replace it with a read from an sqlite table or an individual config file (as said above); the rcvar thing is -supposed- to just be attribute=value, so it can be stored anywhere. Note to previous poster: i think the existing policy sucks. :-) -adrian I suppose you could easily do something like: cat /etc/rc.conf.d/* /etc/rc.conf.cat and add rc.conf.cat to rc_conf_files Right. But what this scheme specifically needs is some semantics for thing I do to push new config changes into the rc.conf system and thing I do to force a commit of these changes. For the rc.conf.cat version, it would do the above. It may just wrap it in a lock file. For the sqlite hack version, it would grab a lock and dump everything into an sqlite table. The point is that it shouldn't be adhoc. there should be some tools in base for things to add/remove cron configs, add/remove rc.conf configs, and do a rebuild of them. -adrian Well, if the rc.conf config is specific to the daemon being installed by the package, then the existing /etc/rc.conf.d/ system works fine, it just falls down a little on xorg configuring hald, unless you just make the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus I like the simplicity of rc.conf, and I would much rather not involve an sqlite database, I am not sure how that could possibly be faster then sourcing an extra shell script. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 2013-11-09 21:13, Adrian Chadd wrote: On 9 November 2013 17:58, Allan Jude free...@allanjude.com wrote: Well, if the rc.conf config is specific to the daemon being installed by the package, then the existing /etc/rc.conf.d/ system works fine, it just falls down a little on xorg configuring hald, unless you just make the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus If I install hal/dbus, why wouldn't they themselves populate /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus ? If there are hal/dbus options that need configuring by other packages, then sure, you'll need to add some other things too. ahh, right, why didn't I think of that I like the simplicity of rc.conf, and I would much rather not involve an sqlite database, I am not sure how that could possibly be faster then sourcing an extra shell script. Don't focus on that. The sqlite example is just that - an example - showing what kind of operations you would want to implement to _allow_ you to do that. I'm not advocating for doing it in freebsd-base. The point I'm making is this: * when populating rc.conf.d/, don't just do 'cp' in a post-install script * when populating the cron daemon entries in rc.cron.d, don't just 'cp' in a post-install script. -adrian If the cron daemon is just scanning /etc/cron.d/* and treating it as if those lines had been appended to /etc/crontab I don't see why you couldn't just cp in the post-install. I think it would be better if you didn't have to 'register' a change. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 2013-11-10 09:04, George Mitchell wrote: On 11/09/13 21:23, Allan Jude wrote: On 2013-11-09 21:13, Adrian Chadd wrote: On 9 November 2013 17:58, Allan Jude free...@allanjude.com wrote: Well, if the rc.conf config is specific to the daemon being installed by the package, then the existing /etc/rc.conf.d/ system works fine, it just falls down a little on xorg configuring hald, unless you just make the xorg package create /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus If I install hal/dbus, why wouldn't they themselves populate /etc/rc.conf.d/hald and /etc/rc.conf.d/dbus ? If there are hal/dbus options that need configuring by other packages, then sure, you'll need to add some other things too. ahh, right, why didn't I think of that I like the simplicity of rc.conf, and I would much rather not involve an sqlite database, I am not sure how that could possibly be faster then sourcing an extra shell script. Don't focus on that. The sqlite example is just that - an example - showing what kind of operations you would want to implement to _allow_ you to do that. I'm not advocating for doing it in freebsd-base. The point I'm making is this: * when populating rc.conf.d/, don't just do 'cp' in a post-install script * when populating the cron daemon entries in rc.cron.d, don't just 'cp' in a post-install script. -adrian If the cron daemon is just scanning /etc/cron.d/* and treating it as if those lines had been appended to /etc/crontab I don't see why you couldn't just cp in the post-install. I think it would be better if you didn't have to 'register' a change. For this whole thread, please s,/etc/rc.d,/usr/local/etc/rc.d,g -- George ___ 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 We have never once mentioned /etc/rc.d rc.conf.d is an entirely different system (extending rc.conf) and I proposed both /etc/cron.d/ (stuff you'd normally add to /etc/crontab) and /usr/local/etc/cron.d/ (packages) -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: cron(8) improvement
On 2013-11-10 11:21, Warren Block wrote: On Sun, 10 Nov 2013, Daniel O'Connor wrote: On 10 Nov 2013, at 24:24, Matthew Seaman matt...@freebsd.org wrote: 2) Should ports / packages populate these cron.d directories? This is a much more interesting question. Effectively its asking if a port / package should provide some level of automatic configuration -- a thing that has previously been a no-no for FreeBSD. I think it would be OK if they installed entries in a disabled state. That would be my preference also. ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. Why not just use an additional entry in rc.conf? rsnapshot_cron=YES (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on start/restart.) I envisioned crond just scanning the directory for added/removed files, rather than some 'add it to cron' system, and cron doesn't read/parse the rc.conf system. maybe it makes most sense to make it scan /usr/local/etc/cron.d/*.cron So ports can install rsnapshot.cron.sample that the user must manually enable (like we do with config files) This brings up another problem. When a port is removed, what is done with ports cron entries that have been user modified? Normally, modified files would not be removed, but a cron entry for a removed port definitely should not be running any more, even if the admin forgot to remove the entry in rc.conf. But just removing the modified file is bad also, because maybe the port was just removed as part of an upgrade. ___ 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 -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: [CFT] bsdinstall and zfsboot enhancements
On 2013-11-11 15:54, Nathan Whitehorn wrote: On 11/11/13 14:30, Nathan Whitehorn wrote: On 11/11/13 14:18, Teske, Devin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Nov 11, 2013, at 11:46 AM, Michael Dexter wrote: Hello all, I have been experimenting with various BSD and GNU/Linux boot media under bhyve and noticed that we may want to accommodate the LiveCD mode of the installer, which in turn requires the correct console. Currently, one is prompted for VT100 for installation but this does not appear to work/stick for LiveCD mode. Can anyone verify this? While I developed this patch... http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/usr.sbin%3A%3Absdinstall%3A%3Ascripts%3A%3Aconfig.patch?revision=1.10view=markup Reasons exist to search for a better solution, see here: http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046148.html (and messages that follow it) Is modifying init(8) still the way to go? What modification do we want to make? I'll do the work if we can come to consensus. Or should we touch up the patch in some way to address the original concerns? I think modifying init is the way to go -- it keeps the install system from interfering with the installed one, as well as fixing this kind of issue with moved hard drives or PXE booting or what have you. If we can provide a guarantee that any system that displays text has a working console (unless explicitly configured not to), useability is improved. I would propose one of the following (and volunteer to write the code): Option A 1. init checks if there is an entry in /etc/ttys for the terminal[s] corresponding to the value[s] in kern.console 2. If an entry for each console terminal exists in /etc/ttys, enable it 3. If not, invent one with a terminal type of ansi The one issue here is that someone may want to force a particular entry to off and still have it be the kernel console. This is tricky. We could invent a new status field that is not on or off (auto, maybe, or ifconsole?). Which brings us to: One easy way to accomplish this is just to only implement (1) and (3), then comment out the ttyu0 entry in /etc/ttys on x86 instead of marking it off. Then the behavior is just that a tty marked off stays off, one marked on stays on, and one not present spawns login with a terminal type corresponding to console (by default unknown) if it happens to be the console. I will implement this over the next few days and then send patches unless anyone has an objection. -Nathan ___ 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 These seems the best approach to me. The ttyu's are off by default, so changing that to commented out has no effect on anyone, and it allows you to do the right magic in init. Thank you for the offer to write this up, look forward to testing the patches -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Default MBR boot manager
On 2013-11-11 16:19, Teske, Devin wrote: Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... Should we do the quick patch to change the default from /boot/boot0 to /boot/mbr: Index: zfsboot === --- zfsboot (revision 258016) +++ zfsboot (working copy) @@ -764,7 +764,7 @@ zfs_create_diskpart() # f_eval_catch $funcname gpart $GPART_CREATE mbr \$disk || return $FAILURE - f_eval_catch $funcname gpart $GPART_BOOTCODE /boot/boot0 \ + f_eval_catch $funcname gpart $GPART_BOOTCODE /boot/mbr \ \$disk || return $FAILURE # That would fix things for Lenovo laptops for the next release until I finish up the bootcode selection menu. I'd like to take my time in making sure Allan and I design a worthy bootcode selection menu. These seems like the best approach for now, based on the feedback I have gotten from people with BIOSs that won't boot GPT and often choke on the boot0 boot manager. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Default MBR boot manager
On 2013-11-11 16:32, Nathan Whitehorn wrote: On 11/11/13 15:19, Teske, Devin wrote: Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... Should we do the quick patch to change the default from /boot/boot0 to /boot/mbr: Index: zfsboot === --- zfsboot (revision 258016) +++ zfsboot (working copy) @@ -764,7 +764,7 @@ zfs_create_diskpart() # f_eval_catch $funcname gpart $GPART_CREATE mbr \$disk || return $FAILURE - f_eval_catch $funcname gpart $GPART_BOOTCODE /boot/boot0 \ + f_eval_catch $funcname gpart $GPART_BOOTCODE /boot/mbr \ \$disk || return $FAILURE # That would fix things for Lenovo laptops for the next release until I finish up the bootcode selection menu. I'd like to take my time in making sure Allan and I design a worthy bootcode selection menu. This patch looks good (I don't remember why it was boot0 in the first place). I think gpart automatically installs something like /boot/mbr by default, so I'd be interested to know if making the diff purely negative still works. On another note, I think we should move away from a selector. Right now, we have three kinds of boot code: 1. ZFS boot code 2. UFS boot code 3. boot0 Unifying 1 and 2 would help a lot -- I don't know of any reason we need both except for tradition. #3 is probably best done as a post-install config step (Install FreeBSD boot manager or something), which also means it works for UFS systems. -Nathan ___ 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 You have to do down right evil things to boot ZFS on MBR. dd'ing the 'remainder' of the boot loader into a reserved space at the head of the ZFS partition. The GPT boot code is 14k, and the code to boot ZFS is 40k, whereas the UFS stuff is 512 bytes and fits in the intended slot. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Default MBR boot manager
On 2013-11-11 16:36, Nathan Whitehorn wrote: On 11/11/13 15:35, Allan Jude wrote: On 2013-11-11 16:32, Nathan Whitehorn wrote: On 11/11/13 15:19, Teske, Devin wrote: Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... Should we do the quick patch to change the default from /boot/boot0 to /boot/mbr: Index: zfsboot === --- zfsboot (revision 258016) +++ zfsboot (working copy) @@ -764,7 +764,7 @@ zfs_create_diskpart() # f_eval_catch $funcname gpart $GPART_CREATE mbr \$disk || return $FAILURE - f_eval_catch $funcname gpart $GPART_BOOTCODE /boot/boot0 \ + f_eval_catch $funcname gpart $GPART_BOOTCODE /boot/mbr \ \$disk || return $FAILURE # That would fix things for Lenovo laptops for the next release until I finish up the bootcode selection menu. I'd like to take my time in making sure Allan and I design a worthy bootcode selection menu. This patch looks good (I don't remember why it was boot0 in the first place). I think gpart automatically installs something like /boot/mbr by default, so I'd be interested to know if making the diff purely negative still works. On another note, I think we should move away from a selector. Right now, we have three kinds of boot code: 1. ZFS boot code 2. UFS boot code 3. boot0 Unifying 1 and 2 would help a lot -- I don't know of any reason we need both except for tradition. #3 is probably best done as a post-install config step (Install FreeBSD boot manager or something), which also means it works for UFS systems. -Nathan ___ 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 You have to do down right evil things to boot ZFS on MBR. dd'ing the 'remainder' of the boot loader into a reserved space at the head of the ZFS partition. The GPT boot code is 14k, and the code to boot ZFS is 40k, whereas the UFS stuff is 512 bytes and fits in the intended slot. We could just decide we won't support booting from ZFS on MBR. For GPT, there is no size limit, which simplifies everything. -Nathan ___ 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 With GPT you just make a partition to put the boot code in, so, there can be a size limit, but the zfsboot script uses a generous 512kb (and aligns the first partition to 1mb) I had originally thought to just use GPT all the time, but there was significant demand for ZFS on MBR. Seems people don't want to replace their laptops just to get ZFS -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Default MBR boot manager
On 2013-11-11 16:39, Teske, Devin wrote: On Nov 11, 2013, at 1:32 PM, Nathan Whitehorn wrote: On 11/11/13 15:19, Teske, Devin wrote: Topic: Lenovo Laptops and bsdinstall zfsboot with MBR layout... Should we do the quick patch to change the default from /boot/boot0 to /boot/mbr: Index: zfsboot === --- zfsboot (revision 258016) +++ zfsboot (working copy) @@ -764,7 +764,7 @@ zfs_create_diskpart() # f_eval_catch $funcname gpart $GPART_CREATE mbr \$disk || return $FAILURE - f_eval_catch $funcname gpart $GPART_BOOTCODE /boot/boot0 \ + f_eval_catch $funcname gpart $GPART_BOOTCODE /boot/mbr \ \$disk || return $FAILURE # That would fix things for Lenovo laptops for the next release until I finish up the bootcode selection menu. I'd like to take my time in making sure Allan and I design a worthy bootcode selection menu. This patch looks good (I don't remember why it was boot0 in the first place). I think gpart automatically installs something like /boot/mbr by default, so I'd be interested to know if making the diff purely negative still works. On another note, I think we should move away from a selector. Right now, we have three kinds of boot code: 1. ZFS boot code 2. UFS boot code 3. boot0 Unifying 1 and 2 would help a lot -- I don't know of any reason we need both except for tradition. #3 is probably best done as a post-install config step (Install FreeBSD boot manager or something), which also means it works for UFS systems. Well, I'm sensitive to the fact that sysinstall offered none and even explained why in an F1 dialog that brought up drives.hlp to explain that you might want to keep whatever (alternate) boot manager you may be using already. In a proposed selector, the full breadth of options that I was envisioning was: GPT + gptboot GPT + none (use your existing boot manager... syslinux?) MBR + mbr MBR + boot0 MBR + none (again, BYOBM) Hadn't got around to zfsboot yet. Where would that go? at the top? GPT + zfsboot ? (and of course, this is x86 specific... I was gleaning from sysinstall that for systems like pc98, they call it an IPL and there's only two options... a standard IPL or bring your own boot manager, aka none). I imagine that there would be architectures that are like the ol' pc98, wherein they don't have all these options (is, for example? sparc64 GPT only?) for ZFS on GPT It would be /boot/gptzfsboot /boot/zfsboot is the bits for MBR that get's DDd into the ZFS partition -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Issues in compiling apache server on one machine and transfer to second
On 2013-11-12 03:24, swapnil vaidya wrote: Hi All, I have 2 linux machine. I have compiled apache 2.4.6 on one of the linux machine with following commands: ./configure --prefix=/usr/apache--with-ssl=/usr/local/ssl --enable-ssl --enable-modules=all --enable-mods-shared=most make make install This has installed apache on this machine and it works fine. However when i copy this apache (where it got installed) folder on other linux machine. I am getting following error while starting httpd with following commad: command: httpd -k start error: /httpd: symbol lookup error: /usr/papache/lib/libapr-1.so.0: undefined symbol: dlopen Can you please help me to understand what is going wrong. ___ 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 Firstly, you are mailing a FreeBSD list about a Linux question Secondly, apache depends on libapr (apache runtime), there are other files you need than just the ones in your apache directory. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: [CFT] bsdinstall and zfsboot enhancements
On 2013-11-12 14:11, Teske, Devin wrote: On Nov 12, 2013, at 4:02 AM, Johan Hendriks wrote: Teske, Devin schreef: Hi all, Another Call For Testing... This one is for bsdinstall. Two patchsets are required for this CFT: http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_debug/ http://druidbsd.cvs.sf.net/viewvc/druidbsd/bsdinstall_zfs/ The enhancements are: + Add a `-D FILE command-line option for overriding the path to the bsdinstall log file (BSDINSTALL_LOG env var). + Document new `-D FILE' in the man page for bsdinstall. + If FILE in `-D FILE' begins with a +, debug output goes to stdout (interleaved between dialog(1) invocations/output) as well as to FILE (minus the leading + of course). + If BSDINSTALL_LOG cannot be written, then debugging is disabled (except in the case of a leading + in the pathname, wherein debug will still be printed to stdout). + Update source code format to approximate a future shstyle(9) + Fix a dangling participle (Begun ... - Began ...) + Rewrite the docsinstall script (was necessary to abate direct dependency on BSDINSTALL_LOG (instead, use fault-tolerant bsdconfig framework which displays appropriate errors for package management). + Add additional debug output for dhclient/rtsol/wpa_cliscan + Display script errors in a textbox rather than just on stdout + Update many coments. + Add new f_show_err() API call (like f_show_msg but changes the dialog title to Error)(see bsdconfig's `common.subr'). + Add new f_eval_catch() API call for executing a command via eval but not before logging the command to debug. Several example cases documented in API header for function in bsdconfig's `common.subr'. + Fix dialog auto-sizing when launched as an rvalue to a pipe for indirected scripts (previously would default to 80x24 sizing in this case, now it can autosize to full size even when in a pipe chain). + Fix a bug in f_snprintf wherein if the $format argument began with a - or -- it would be misinterpreted as a flag to printf. (this is in bsdcofig's strings.subr) + Add accompanying f_sprintf() and f_vsprintf() to go along with already existing f_snprintf() and f_vsnprintf() (see bsdconfig's strings.subr). + Update bsdinstall's config script to adjust ttyu* entries in /etc/ttys when it is determined that we are in-fact doing an install over serial (e.g. bhyve). + Remove some unnecessary default ZFS datasets from the automatic zfsboot script. Such as: /usr/ports/distfiles /usr/ports/packages /usr/obj /var/db /var/empty /var/mail and /var/run (these can all be created as-needed once the system is installed). + Remove setuid=off for /usr/home (as discussed with others from last round of CFT). + Fix some i18n string violations in zfsboot + Bolster debugging output in zfsboot + Fix some string quoting issues in zfsboot + Fix some variable scope issues in zfsboot + Only display the ZFS vdev type selection menu when running interactively (duh). + Change Create to Install in zfsboot main menu + Increase pedantic error checking in zfsboot (type-check arguments and such). + Add a call to graid destroy to kill automatic metadata (part of the series of pedantic destructions we do when bootstrapping a new/naked disk). + Make judicious use of new f_eval_catch() in zfsboot + More comments (zfsboot). + Fixup some variable names for consistency (zfsboot). I did not try this installer myself, but one question, can i seperate the swap space from the pool? I have seen to many strange hangs on a server where i use swap on zfs! If I understand correctly, it does this by default. Yes, the zfsboot script in bsdinstall creates a raw swap partition, it does not use swap-on-zfs -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: ZSF and installkernel 10.0-BETA1
On 2013-11-14 12:48, Phillip Kinsley wrote: I installed Beta1 using the ZFS option, all default settings. I sync the source the other day and did a buildworld and buildkernel. When I do installkernel I get mkdir -p /boot/kernel mkdir: /boot: No such file or directory and the install stops. With another box that used a standard UFS installation I have no problem. I'm sure the ZFS installkernel is know issue, but I can't seem to find if there is a solution or not. Is there a work around or not? Thanks Phillip ___ 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 What do you mean 'the zfs option'? You mean you used the ZFS installation option in bsdinstall? That is a known issue that was fixed in later versions, here are the instructions to fix it: http://lists.freebsd.org/pipermail/freebsd-stable/2013-October/075504.html o Updates to bsdinstall(8). Please note the following: - 10.0-BETA1 introduces a number of updates to bsdinstall(8), notably the ability to install to a full ZFS filesystem. Please keep in mind that this is an experimental feature. - If using the ZFS installation option in *and* have enabled full-disk encryption is enabled, a few entries will need to be manually added to loader.conf(5) before the 'bootpool' zpool will be available after the system boots. This manual step is expected to be fixed in 10.0-BETA2. The entries that need to be added are: zpool_cache_load=YES zpool_cache_type=/boot/zfs/zpool.cache zpool_cache_name=/boot/zfs/zpool.cache This can be done at the final menu of bsdinstall(8), when prompted to boot into the newly-installed system; alternatively, this can be done post-install, in which case, the following must be run before appending loader.conf(5): # zpool import -f bootpool -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Slow boot with 256GB of RAM?
On 2013-11-15 23:37, James R. Van Artsdalen wrote: Asus Z9PA-U8 motherboard, 256GB of RAM, 2.4 GHz Xeon E5-2695 v2, FreeBSD 11.0-CURRENT r258092 There is a two minute pause when booting, after the loader's SMAP display and the initial kernel output, Does anyone know what's going on here? Even that much RAM shouldn't take that much time to clear. ___ 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 It is a known issue (I have a few E5-2620s with 96 and 144gb of ram) There was talk at MeetBSD last year about making at least output a dot for each 1 or 8gb of something so you knew it was at least doing something, not sure whatever happened to that. It would be nice if it didn't that that long -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Slow boot with 256GB of RAM?
On 2013-11-16 00:48, Matthias Petermann wrote: Hello James, Am 16.11.2013 05:37, schrieb James R. Van Artsdalen: Asus Z9PA-U8 motherboard, 256GB of RAM, 2.4 GHz Xeon E5-2695 v2, FreeBSD 11.0-CURRENT r258092 There is a two minute pause when booting, after the loader's SMAP display and the initial kernel output, Does anyone know what's going on here? Even that much RAM shouldn't take that much time to clear. in an earlier discussion at FreeBSD Forums[1] it looks like this is related to some early stage memory test which is performed. It can be disabled by adding hw.memtest.tests=0 to /boot/loader.conf. For my 32GB machine this helped. Best regards, Matthias [1] http://forums.freebsd.org/showthread.php?t=12705 I see this was in the release notes for 9.0 and 8.3, but other than that, I don't see how anyone was supposed to find out about this Maybe it would make sense to print 'Starting memory test, set hw.memtest.test=0 to disable' before that starts, so anyone stuck waiting will have a hint about what to do. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Slow boot with 256GB of RAM?
On 2013-11-16 13:36, James R. Van Artsdalen wrote: On 11/16/2013 8:52 AM, Allan Jude wrote: I see this was in the release notes for 9.0 and 8.3, but other than that, I don't see how anyone was supposed to find out about this. Maybe it would make sense to print 'Starting memory test, set hw.memtest.test=0 to disable' before that starts, so anyone stuck waiting will have a hint about what to do. A patch for the FAQ to add an entry about the hw.memtest.test=0 to speed up boot on machines with a lot of ram -- Allan Jude Index: en_US.ISO8859-1/books/faq/book.xml === --- en_US.ISO8859-1/books/faq/book.xml (revision 43198) +++ en_US.ISO8859-1/books/faq/book.xml (working copy) @@ -3669,6 +3669,26 @@ in man.tunefs.8;./para /answer /qandaentry + + qandaentry + question xml:id=slow-boot-memtest + paraWhy does os; pause for a long time at boot when the + system has large amounts of ram?/para + /question + + answer + paraos; does a short memory test early in the boot + process. This test usually only takes several seconds, + however if the system has many 10s or 100s of gigabytes + of memory it can take up to a few minutes. This test + can be disabled by setting the + literalhw.memtest.tests/literal to + literal0/literal in + filename/boot/loader.conf/filename/para + + paraFor more details, see man.loader.conf.5;./para + /answer + /qandaentry /qandaset sect1 xml:id=all-about-zfs signature.asc Description: OpenPGP digital signature
Re: zpool requires re-import on reboot
On 2013-11-18 03:51, Beeblebrox wrote: Is there anything non-standard about your configuration? All pools that are present in /boot/zfs/zpool.cache on a root filesystem of a root pool should be automatically imported. Yes I know that, hence the reason I posted. ll /boot/zfs shows recently updated zpool.cache = -rw-r--r-- 1 root wheel 3736 Nov 18 10:03 zpool.cache * No special setting on pool or datasets of the pool * /etc/src.conf even has LOADER_ZFS_SUPPORT= yes * custom kernel has label disabled (#optionsGEOM_LABEL ). However, generic kernel shows same behavior. ___ 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 In /boot/loader.conf try adding: zpool_cache_load=YES zpool_cache_type=/boot/zfs/zpool.cache zpool_cache_name=/boot/zfs/zpool.cache This should make it read the zpool.cache file and mount all of the pools, instead of only the one which contains your root file system -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: zpool requires re-import on reboot
On 2013-11-20 02:49, Beeblebrox wrote: Alan: This corrects the zpool import problem (thanks for that): zpool_cache_type=/boot/zfs/zpool.cache zpool_cache_name=/boot/zfs/zpool.cache But boot still drops to single user and needs zfs mount -a to locate the fstab entries. Some datasets have canmount=noauto (but have a corresponding fstab entry). However, the primary dataset of the zpool (where dataset name = zpoll name) for both pools has canmount=on. One other non-standard property I have is that the dataset name is different than mountpoint (zfs set mountpoint=/some other folder) Nothing else out of the ordinary that I can think of. Regards. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/zpool-requires-re-import-on-reboot-tp5861930p5862442.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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 having zfs_enable=YES in /etc/rc.conf should automatically run 'zfs mount -a' during boot, and you shouldn't have this problem What does the output of this command look like: zfs get -r -t filesystem canmount,mountpoint $poolname in the zfsboot script, some datasets have canmount=off on purpose, /usr has it so that /usr/bin goes in the root dataset, but the dataset is required to create a separate /usr/local dataset -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: ZFS: sharenfs and zdb no such file errors
On 2013-11-26 15:07, Beeblebrox wrote: I had a previously discussed zpool related error on my susytem: (http://freebsd.1045724.n5.nabble.com/zpool-requires-re-import-on-reboot-td5861930.html#a5862468). This may be related. Now a different but equally odd error: On one of the pools with the import problem (poolname=da), I had: zfs set sharenfs=-network=192.168.2.0/24 da/data/amd64 When I start nfsd + mountd, TTY0 shows this error: bad exports list line: /mnt/data/amd64 bad exports list line: /mnt/amd64 I can only assume that I had the da zpool mounted as altroot=/mnt at some point in its history. After I zfs set sharenfs=off da/data/amd64 for debugging, the error persisted for some time then was gone when I first tried; now it persists even after a pool scrub. ZDB shows nothing odd with the -Cl /dev/ada1p2 flag, but, zdb -d da/data/amd64 zdb: can't open 'da/data/amd64': No such file or directory I have same error for all pool-type commands. # zdb -C da for example. Regards - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/ZFS-sharenfs-and-zdb-no-such-file-errors-tp5864187.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ 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 NFS related config for ZFS is stored in /etc/zfs/exports and mountd just reads that in addition to the usual /etc/exports you might want to check there -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: 10-RC2 current wireless link aggregation not working correctly
On 2013-12-17 10:54, Adrian Chadd wrote: Hi, The MAC of the lagg needs to be the same as the wireless interface. I'm going to just state right now that using lagg as the failover method for doing wireless/wired integration isn't supported by me. If someone wants to make it supported then they need to claim it. :) -a On 17 December 2013 05:06, dan_partelly dan_parte...@rdsor.ro wrote: Hi all, I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop. What happens is: If I boot the system with the Ethernet cable attached, I correctly get lagg0 active port on master- bg0- and the network is working correctly. (I mainly test pinging my gateway). When I pull the cable out, lagg0 device correctly switches to wlan0 as shown by ifconfig (wlan0 is created from wpi0), but at the same time I get no more ping replies from my gateway. I can leave the system in this state for several minutes as an example and no replies are coming through. A simple list of interfaces with ifconfig with no parameters brigs the network back to life, and I start to get back the due ping replyes, this time thrugh wireless link. Please, if possible en-light me on tis problem. I sat at your disposition with any info you may deem necessary to get this fixed (if it needs a fix). Dan ___ 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 If I am am understanding correctly, Dan and Nikolai say that just running 'ifconfig' brings the lagg back to life. Why would that make a difference at all? Running ifconfig with no parameters shouldn't be changing anything. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: [rfc] [patch] do not stop watchdog on shutdown
On 2013-12-17 16:28, Aleksandr Rybalko wrote:
On Tue, 17 Dec 2013 10:53:02 -0800
Maksim Yevmenkin maksim.yevmen...@gmail.com wrote:
hello,
Hi Maksim!
would anyone object to this patch?
It is good idea, but sometimes shutdown sequence longer than some H/W
watchdogs even support.
I have one board which can do only 20sec maximum time.
max
Index: src/etc/rc.d/watchdogd
===
--- src/etc/rc.d/watchdogd (revision 2999)
+++ src/etc/rc.d/watchdogd (working copy)
@@ -39,4 +39,7 @@
pidfile=/var/run/${name}.pid
load_rc_config $name
+
+sig_stop=${watchdogd_sig_stop:-TERM}
+
run_rc_command $1
___
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
I've been seeing an issue where sometimes my system seems to hang after
the shutdown. where not stopping the watchdog might help. I wonder if it
would be best to make some kind of rc.conf variable to allow the user to
opt for one or the other, keeping the current behaviour for POLA.
--
Allan Jude
signature.asc
Description: OpenPGP digital signature
ZFS Boot patch
An issue we thought we had fixed, was not actually fixed. When doing a GELI based Root-on-ZFS install, the 'bootpool' is not always properly mounted in the installed system. The lines added to loader.conf to make it use the zpool.cache file and learn of the existence of the 2nd pool are required, and have the desired effect. However, it seems that the 2nd pool is not always listed in the cache file. The attached patch should fix this issue. Hopefully this can get MFCd in time for the next RC -- Allan Jude Index: usr.sbin/bsdinstall/scripts/zfsboot === --- usr.sbin/bsdinstall/scripts/zfsboot (revision 259561) +++ usr.sbin/bsdinstall/scripts/zfsboot (working copy) @@ -1156,6 +1156,11 @@ f_eval_catch $funcname zpool $ZPOOL_SET \ cachefile=\$BSDINSTALL_CHROOT/boot/zfs/zpool.cache\ \ $zroot_name || return $FAILURE + if [ $ZFSBOOT_BOOT_POOL ]; then + f_eval_catch $funcname zpool $ZPOOL_SET \ + cachefile=\$BSDINSTALL_CHROOT/boot/zfs/zpool.cache\ \ +$bootpool_name || return $FAILURE + fi # Last, but not least... required lines for rc.conf(5)/loader.conf(5) # NOTE: We later concatenate these into their destination signature.asc Description: OpenPGP digital signature
root-on-zfs /var/empty
I've seen a number of comments about the /var/empty dataset The reason this is not set readonly=on during the installation is that this causes the installation to fail (when the installer tries to create/set flags). This can be set during the post install, or it might be worth considering Colin Percival's firstboot script as a way to set this after the fact. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: ZFS Boot patch
On 2013-12-18 12:27, Allan Jude wrote: An issue we thought we had fixed, was not actually fixed. When doing a GELI based Root-on-ZFS install, the 'bootpool' is not always properly mounted in the installed system. The lines added to loader.conf to make it use the zpool.cache file and learn of the existence of the 2nd pool are required, and have the desired effect. However, it seems that the 2nd pool is not always listed in the cache file. The attached patch should fix this issue. Hopefully this can get MFCd in time for the next RC A note for the release notes. If you have an existing install, it can be 'repaired' easily: zpool import -f bootpool zpool set cachefile=/boot/zfs/zpool.cache bootpool This will add the bootpool to the existing zpool.cache (which contains the data for your main pool) This only applies to users who opted to encrypt their zpool. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: ZFS/zpool command blocks ... locking up all terminals
On 2013-12-20 05:55, O. Hartmann wrote: I have a faulty pool with an ambiguous label and I tried to resolve that problem. ZFS is at the moment highly active copying data from several volumes to another. Operating system: 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r259522: Tue Dec 17 19:02:10 CET 2013 amd64 In one terminal I exported the pool in question and tried to list it via zpool import. But the this command sequence locks up the terminal for an hour up! In another terminal I tried to issue to command zpool status to watch the status of the pools (I have several). But this terminal ist alos locked up right now! What is wrong here? I had such an issue in 10.0-CURRENT as well. It seems ZFS is locking everything up and can only be brought back by a hard reset! What is going on? Why is zpool locking up in trying to display a label-scrambled pool while the zpool status is then also locked up, but latter is supposed to show the status of the other, healthy pools? This reminds me of single-threaded tools which looks up every operation consecutively issued after the blocking command. How is this to be solved? Oliver Can you input 'control + t' or otherwise send siginfo to see what run 'state' zpool is in? This usually consists of the ZFS function name and is often very revealing and gives a starting point for investigation -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: ZFS command can block the whole ZFS subsystem!
On 2014-01-03 11:14, O. Hartmann wrote: On Fri, 3 Jan 2014 14:38:03 - Steven Hartland kill...@multiplay.co.uk wrote: - Original Message - From: O. Hartmann ohart...@zedat.fu-berlin.de For some security reasons, I dumped via dd a large file onto a 3TB disk. The systems is 11.0-CURRENT #1 r259667: Fri Dec 20 22:43:56 CET 2013 amd64. Filesystem in question is a single ZFS pool. Issuing the command rm dumpfile.txt and then hitting Ctrl-Z to bring the rm command into background via fg (I use FreeBSD's csh in that console) locks up the entire command and even worse - it seems to wind up the pool in question for being exported! I cant think of any reason why backgrounding a shell would export a pool. I sent the job rm into background and I didn't say that implies an export of the pool! I said that the pool can not be exported once the bg-command has been issued. I expect to get the command into the background as every other UNIX command does when sending Ctrl-Z in the console. Obviously, ZFS related stuff in FreeBSD doesn't comply. The file has been removed from the pool but the console is still stuck with ^Z fg (as I typed this in). Process list tells me: top 17790 root 1 200 8228K 1788K STOP 10 0:05 0.00% rm for the particular rm command issued. Thats not backgrounded yet otherwise it wouldnt be in the state STOP. As I said - the job never backgrounded, locked up the terminal and makes the whole pool inresponsive. Now, having the file deleted, I'd like to export the pool for further maintainance Are you sure the delete is complete? Also don't forget ZFS has TRIM by default, so depending on support of the underlying devices you could be seeing deletes occuring. Quite sure it didn't! It takes hours (~ 8 now) and the drive is still working, although I tried to stop. You can check that gstat -d command report 100% acticity on the drive. I exported the pool in question in single user mode and now try to import it back while in miltiuser mode. Shortly after issuing the command zpool import POOL00 the terminal is stuck again, the drive is working at 100% for two hours now and it seems the great ZFS is deleting every block per pedes. Is this supposed to last days or a week? but that doesn't work with zpool export -f poolname This command is now also stuck blocking the terminal and the pool from further actions. If the delete hasnt completed and is stuck in the kernel this is to be expected. At this moment I will not imagine myself what will happen if I have to delete several deka terabytes. If the weird behaviour of the current system can be extrapolated, then this is a no-go. This is painful. Last time I faced the problem, I had to reboot prior to take any action regarding any pool in the system, since one single ZFS command could obviously block the whole subsystem (I tried to export and import). What is up here? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. Regards, Oliver Deleting large amounts of data with 'rm' is slow. When destroying a dataset, ZFS grew a feature flag, async_destroy that lets this happen in the background, and avoids a lot of these issues. An async_delete might be something to consider some day. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Supermicro X10SLH-F motherboard kernel panics with 9.2 Release and 10.0 RC4
On 2014-01-07 15:05, Dan Sency wrote: Hello Everyone, I need help resolving kernel panics on a Supermicro X10SLH-F motherboard in a Supermicro SC-825 chassis. I originally installed FreeBSD 9.2 Release/amd64 but kept having kernel panics after varying amounts of uptime and while running the following command against some or all of the SATA hard drives in the system: dd if=/dev/zero of=/dev/ada/n/ bs=100m A sample vmcore file is here: http://codepad.org/FIjqh2Nt While canvassing the FreeBSD Forums I followed a suggestion to try 10.0 RC4/amd64. The machine still panicked under the same conditions at around 27 hours uptime. The vmcore file is here: http://codepad.org/svtRfRT1 System memory has run Memtest for 62 hours and 47 passes without error and the chassis has dual 740W PSU's so I think I have memory and PSU possibilities eliminated. Apologies if I've sent my plea to the wrong place. Tell me where to go and I'll bother someone else. Thanks, Dan. How is your swap configured on this machine? -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: freebsd-update
On 2014-01-21 15:42, Kevin Oberman wrote: On Tue, Jan 21, 2014 at 8:49 AM, John Baldwin j...@freebsd.org wrote: On Tuesday, January 21, 2014 10:46:37 am David Chisnall wrote: On 21 Jan 2014, at 07:13, Antonio Olivares olivares14...@gmail.com wrote: On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras ivo...@freebsd.org wrote: Hi, Is there any way I can avoid manually resolving hundreds of merge conflicts of the following type while using freebsd-update ? 1 current version 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 3 === 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 5 10.0-RELEASE ? I can't be the only one seeing those...? Yes, One has to manually go one by one to fix these :( I tried at one point a sed command like sed -i '' to fix these, but it did not work correctly. I see errrors when booting when I don't correct these :( I thought this was fixed already (I didn't see these in the 9.2-10-RC3 upgrade). Doesn't freebsd-update pass -F (If the files differ only by VCS Id ($FreeBSD) install the new file) to mergemaster? AFAIK it doesn't use mergemaster? I thought it used its own tool? I really want to figure out a way to let it use etcupdate instead since it handles this case even for locally modified files cleanly. Having just gone through this on a 10.0-rc5 to 10.0-RELEASE run, I can assure you that it is not completely fixed. One huge part is fixed... every file's ID line is no longer is changed on every release. OTOH, for files that are modified, thy still show up. It hit many of the sendmail .cf files. Annoying as I don't even use sendmail. Not sure if there was a good reason Colin re-invented the wheel on this. It does not use mergemaster or even a reasonable differences editor such as the one mergemaster uses. Just going to the mergemaster code for handling diffs would be a HUGE win. I am getting really tired of /CR3dddwnddn. I discussed this a bit with Colin on Wednesday during our interview with him for BSDNow.tv He had some problems with mergemaster so wrote his own tool. In 10 it ignores the $Id tags, but there are still other changes that have to either be merged or the file replaced with the new one. I am all for further improvement here. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT
On 2014-02-06 22:18, Julian H. Stacey wrote: Hi, Reference: From:David Chisnall thera...@freebsd.org Date:Thu, 6 Feb 2014 18:52:43 + David Chisnall wrote: On 6 Feb 2014, at 18:34, Julian H. Stacey j...@berklix.com wrote: Best avoid the obscure word `Deprecated' in manuals: It's not common/ plain English. Maybe a geek import, or USA dialect ? It's not easily internationaly understood English. Best make manuals easier for non native English speakers ( native English too ;-). I am British born bred, whether in English speaking circles in UK or Germany I never hear or read 'deprecated' unless its in BSD context. Few native English speakers I know will be immediately sure of the meaning, it's too obscure. I'd strongly disagree with this. Deprecated is, perhaps, only in common use as jargon, but it's very widespread within the tech field. I don't think I've ever read an API reference that doesn't include the word, for example, and it's even a keyword in many code documentation tools. For example, JavaDoc supports @deprecated and gcc / clang include an __attribute__((deprecated)) that generates a compile-time warning whenever anyone tries to call a deprecated function. I've not come across the word outside of tech uses, but I've also not come across the term network interface outside of tech circles. Deprecated, in this use, may be jargon, but it's very widespread jargon, and requesting it not be used sounds like asking for words like driver or processor also be avoided. David (Also a native English speaker, although familiar with the unofficial fork from Leftpondia) Uh Huh ;-) http://en.wiktionary.org/wiki/Leftpondia American 1620 fork of English deduced. 1620: When a Mayflower butter maid Deprecated a milk maid giving 20 ounces to a pint, confused USA liquids down to 16 ounces. (Beware man units). Amerian is not always best international English. It's a big early variant of English, but other native English speakers round the globe well outnumber American I believe. (Start with a map of the Commonwealth), many 2nd language people too will help define international English, (as José Manuel Barroso, EU commission president, said), not just natives, eg British or Americans etc, will get to shape international English. Americans often seem to find it harder to grasp what's internationaly portable English, as opposed to American, perhaps because a large country makes a higher percentage of language experience internal national usage. FreeBSD's manual writers, especially non native English manual writers, should not copy Americanisms /or bad nomenclature from one manual to another, but ask themselves if they know better words, to make it easier also for other non native English to read. eg Deprecated is not common English. PS Light relief: http://www.bbc.com/future/story/20140206-can-drones-be-hacked Cheers, Julian ___ 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 The problem with 'deprecated' is that it often means 'this is no longer the suggested way to do it', not necessarily 'this method of doing it will soon cease working'. For example, in /etc/rc.conf ifconfig_em0_aliasX is deprecated But it still works, and as far as I am aware, there are no plans to stop supporting it, it is just 'recommended', that you use ipv4_addrs_em0 I think the word deprecated is fine, but it should also be made clear that nve is going away and that you should switch to nfe immediately. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: ezjails, systat -ifstat, and multiple network cards
On 2014-02-13 13:59, Preston Hagar wrote: I have a server setup with FreeBSD-10.0-RELEASE. It has 3 Intel gigabit network cards in it, em0, em1, and em2. I have multiple ezjails setup that run various things. One jail, called db, runs a postgresql database. It was my intention to give it em0 all to itself. The other jails and host machine should be going through em2. em1 currently isn't being used. If I do an ifconfig, I see that em0 has the alias IP for my db jail and em2 has the alias IP for all other jails. All the jails respond to network traffic as expected and seemingly work fine. The weird thing is when I do a systat -ifstat from the host, it should essentially all traffic going through em0. Some of the jails that run off of em2 (as defined in their jail config files and seen in ifconfig) have large data transfers and/or are web servers with lots of photos. I have even tried to manually scp a large file out of a jail setup through em2 and the numbers don't seem to budge. If I do netstat -i -b -n -I and check em0 and em2, it seems to support the numbers shown by systat -ifstat. However, if I use trafshow or iftop (both of which require choosing one interface at a time), they both seem to indicate the traffic flowing through the interfaces as I would expect. So I was curious if anyone had seen something like this before or had any ideas of what is going on. I have net.fibs=2 set in /boot/loader.conf, but in all the jails I current have jail_name_fib= as I haven't got around to fullying setting up fibs. Is that perhaps the issue? Is there any way to determine with certainty which jail is using which interface short of physically pulling a network cable and seeing what stops working? Here are the relevant lines from my db (the one that should be on em0) config: export jail_db_hostname=db export jail_db_ip=em0|10.1.10.2 From another jail on em2 called www: export jail_www_hostname=www export jail_www_ip=em2|10.1.10.7 from ifconfig em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=4219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO ether 08:60:6e:13:94:06 inet 10.1.1.4 netmask 0x broadcast 10.1.255.255 inet6 fe80::a60:6eff:fe13:9406%em0 prefixlen 64 scopeid 0x1 inet 10.1.10.2 netmask 0x broadcast 10.1.10.2 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active em2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=4219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO ether 68:05:ca:13:74:2a inet 10.1.1.2 netmask 0x broadcast 10.1.255.255 inet6 fe80::6a05:caff:fe13:742a%em2 prefixlen 64 scopeid 0x3 inet 10.1.10.3 netmask 0x broadcast 10.1.10.3 inet 10.1.10.1 netmask 0x broadcast 10.1.10.1 inet 10.1.10.8 netmask 0x broadcast 10.1.10.8 inet 10.1.10.10 netmask 0x broadcast 10.1.10.10 inet 10.1.10.4 netmask 0x broadcast 10.1.10.4 inet 10.1.10.9 netmask 0x broadcast 10.1.10.9 inet 10.1.10.7 netmask 0x broadcast 10.1.10.7 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active Let me know if any more detail would be helpful or if you have any ideas of things to check. Thanks, Preston ___ 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 All traffic going out from the jails will using the routing table from the host system. The routing table will use the network card that is in the same subnet as your default gateway to route the traffic to the internet. In your case, I would imagine this is 10.1.1.4/16 (and 10.1.1.2/16). 'netstat -rn' will tell the tale, but I imagine it is whichever was added first. If you want to have separate routing tables per jail, you'd have to either use FIBs, and set the jails to use the different FIBs, or use VNET jails and have a routing table in each jail. -- Allan Jude signature.asc Description: OpenPGP digital signature
