Re: FreeBSD Installer Roadmap
On Saturday 19 February 2011 03:04:39 Devin Teske wrote: There are many reasons for this, and none of them are selfish (although it remains possible to drum-up some selfish reason, all of the reasons behind our motivation are in-fact unselfish). Truth-be-told, I welcome the replacement of sysinstall but am very wary that ANY replacement will be able to exactly replicate the hardware compatibility that sysinstall currently enjoys. I do indeed envision a great celebration as FreeBSD-9 bucks sysinstall but also at the same time have nightmares of receiving waves of calls from people having trouble (for example) installing FreeBSD-9 on their AMD K6 based system, circa long-long-ago in a universe far-far-away. (yes, we do have data centers running that very equipment with uptime in the 1,000's of days). I think bsdinstall as it currently is is simple enough that there shouldn't be any compatibility issues: it uses gpart for partitioning, runs tools like tzsetup to configure settings etc. so there's far less to go wrong than sysinstall's custom code which for example could crash on the probing devices screen. -- Bruce Cran ___ 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 Installer Roadmap
Sysinstall is fine, as I'm sure any replacement will be. So I'll just note a few things I'd like to see in any such replacement... 1 - I used install.cfg's on floppies to clone systems, a lot. Hands on the box were needed with that. Operators skills were in question, so having them use the dialog menus properly was a pain and often resulted in non-zeroed disk or half built systems. And though all else was cloned, it needed a separate host.cfg for each box due to: fqdn, gateway, ip/mask interface - sometimes changed root disk - sometimes changed Would have killed for a simple console shell script to ask those questions of the operator, per machine. 2 - Being able to skip, replace, or prefix/suffix each stage of whatever the installer would do with a shell script (ala: distSetCustom local) would be cool. 3 - Options to dd if=/dev/zero of=/dev/[x] bs=1m, where x are any boot sectors, drives, slices, partitions, labels, etc that would otherwise be blown away but not fully wiped beforehand. And a request for some remaining bugs to be fixed, implemented anew or figured out... 1 - Setting debug=yes was great[a], up until you tried to get that resultant file off the system or view it. Due to the way things were mounted with mfsroot and the alt-f4 shell being separate, I never did figure out how to do that. [a] - only when calling /stand/sysinstall from your development box to test your install.cfg, and the install process. Not when actually installing a box. 2 - mediaClose - didn't work right. I couldn't get the base distribution bits from one ftp server, and the local distribution bits from another. And in general, I'll cheer for whichever camps are doing... As opposed to mfsroot, boot a stripped kernel, on real filesystem, with init to shell to installer. and installroot things from there. Some sort of plaintext backend that can read a config. Pluggable frontends, at minimum 80x25 console shell, then dialog/web/xorg/whatever. Network boot, retrieve config via net, etc. It would be cool to have an 'installer build' config option set available during buildworld too. Much like you can configure crunchgen to customize the crunch, you could customize certain parts of how you wanted the installer to work. Particularly for things that might take up space, what it thinks are its first places to get input, boot from, display, where to find its config while blind, etc. And a stripped buildworld kernel config for use with the installer. Call it just more permutations on the liveCD concept. ___ 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: HEADS UP: Merge of binutils 2.17
On 2011-02-16 21:00, Dimitry Andric wrote: So I plan to merge the binutils-2.17 project branch to head this weekend, if there are no further objections. If you have found a showstopper bug, please let me know ASAP. :) Okay, binutils 2.17.50 has now been merged to head in r218822. If you compile kernels by hand, make sure to first run make buildworld, or at least make kernel-toolchain, to get a new ld in /usr/obj. Otherwise, linking your kernel might fail. ___ 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: HEADS UP: Merge of binutils 2.17
On 2011-02-19 15:35, Dimitry Andric wrote: Okay, binutils 2.17.50 has now been merged to head in r218822. If you compile kernels by hand, make sure to first run make buildworld, or at least make kernel-toolchain, to get a new ld in /usr/obj. Otherwise, linking your kernel might fail. Note, this also applies when you want to build a -CURRENT kernel on -STABLE. In this case, you must run a make buildworld, or minimally make kernel-toolchain, before running make buildkernel or make kernel. ___ 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
screen: Could not write /nonexistent
Hi, I did a rebuild of my system today. The last time I did this was friday, 4th of february 13:39. After I rebuilt the system, screen produces a short error-message in it's splash-screen (both when starting a new screen-session, and when attaching to an existing session), stating Could not write /nonexistent. After a few searches online, I cannot seem to find anything specific to this problem. Screen seems to running fine, though, so the only issue so far is that it's annoying. (-: I guess this could be caused by different things, but as it worked yesterday, I can only assume that this happened because I did a rebuild. I also tried to reinstall screen, but without luck. Any ideas? -- Joachim ___ 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
[RFC] Force stdio output streams to line-buffered mode
Hi,
I've been annoyed multiple time when running a command such like
iostat -x 1 | grep -v ad10 | cat -n
The problem stems from two factors:
- grep's stdio sees that its stdout is not a terminal, so stdout is
full buffered and not line-buffered;
- iostat produces output too slowly so the aforementioned buffer takes
numerous seconds to be filled and flushed to the last command.
This problems is not specific to FreeBSD, it is actually a consequence
of POSIX specification. I've checked this on Solaris and Linux.
I've attached a small patch for stdio, so if the environment variable
STDIO_IOLBF is set, the output streams will be line-oriented by default.
iostat -x 1 | env STDIO_IOLBF=1 grep -v ad10 | cat -n
Before send it as a PR, I would like to hear your comments about this,
especially:
- the variable name (no bikeshed please, I just ask this if there is a
naming convention I'm not aware of);
- the documentation: I've put a hint in stdio(3) manpage and put the
full explanation in setvbuf(3).
Thanks.
Regards,
--
Jeremie Le Hen
Humans are born free and equal. But some are more equal than others.
Coluche
diff -rup /usr/src.orig/lib/libc/stdio/makebuf.c /usr/src/lib/libc/stdio/makebuf.c
--- /usr/src.orig/lib/libc/stdio/makebuf.c 2009-08-03 10:13:06.0 +0200
+++ /usr/src/lib/libc/stdio/makebuf.c 2011-02-19 19:09:56.0 +0100
@@ -59,6 +59,7 @@ __smakebuf(fp)
FILE *fp;
{
void *p;
+ char *bmode;
int flags;
size_t size;
int couldbetty;
@@ -79,7 +80,8 @@ __smakebuf(fp)
flags |= __SMBF;
fp-_bf._base = fp-_p = p;
fp-_bf._size = size;
- if (couldbetty isatty(fp-_file))
+ if (((bmode = getenv(STDIO_IOLBF)) bmode[0] != '\0') ||
+ (couldbetty isatty(fp-_file)))
flags |= __SLBF;
fp-_flags |= flags;
}
diff -rup /usr/src.orig/lib/libc/stdio/setbuf.3 /usr/src/lib/libc/stdio/setbuf.3
--- /usr/src.orig/lib/libc/stdio/setbuf.3 2009-08-03 10:13:06.0 +0200
+++ /usr/src/lib/libc/stdio/setbuf.3 2011-02-19 19:09:13.0 +0100
@@ -79,7 +79,9 @@ and an optimally-sized buffer is obtaine
If a stream refers to a terminal
(as
.Dv stdout
-normally does) it is line buffered.
+normally does), or the environment variable
+.Ev STDIO_IOLBF
+is set, it is line buffered.
The standard error stream
.Dv stderr
is always unbuffered.
@@ -176,6 +178,12 @@ The
function returns what the equivalent
.Fn setvbuf
would have returned.
+.Sh ENVIRONMENT
+.Bl -tag -width .Ev STDIO_IOLBF
+If the environment variable
+.Ev STDIO_IOLBF
+is set, output streams will be line-buffered by default
+even when not referring to a terminal.
.Sh SEE ALSO
.Xr fclose 3 ,
.Xr fopen 3 ,
diff -rup /usr/src.orig/lib/libc/stdio/stdio.3 /usr/src/lib/libc/stdio/stdio.3
--- /usr/src.orig/lib/libc/stdio/stdio.3 2009-08-03 10:13:06.0 +0200
+++ /usr/src/lib/libc/stdio/stdio.3 2011-02-19 12:56:00.0 +0100
@@ -137,7 +137,8 @@ an interactive or
.Dq terminal
device, as determined by the
.Xr isatty 3
-function.
+function (this can be overriden with an environment variable, see
+.Xr setvbuf 3 ) .
In fact,
.Em all
freshly-opened streams that refer to terminal devices
___
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] Force stdio output streams to line-buffered mode
On Sat, Feb 19, 2011 at 07:50:43PM +0100 I heard the voice of Jeremie Le Hen, and lo! it spake thus: I've attached a small patch for stdio, so if the environment variable STDIO_IOLBF is set, the output streams will be line-oriented by default. iostat -x 1 | env STDIO_IOLBF=1 grep -v ad10 | cat -n I've no real comment on anything else (sounds like an interesting hack, whatever else), but just for this particular case, you know that grep has a --line-buffered arg, right? -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ 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 Installer Roadmap
On 19/02/2011, at 20:04, grarpamp wrote: 1 - I used install.cfg's on floppies to clone systems, a lot. Hands on the box were needed with that. Operators skills were in question, so having them use the dialog menus properly was a pain and often resulted in non-zeroed disk or half built systems. And though all else was cloned, it needed a separate host.cfg for each box due to: fqdn, gateway, ip/mask interface - sometimes changed root disk - sometimes changed Would have killed for a simple console shell script to ask those questions of the operator, per machine. Not to get into the whole wishlist for sysinstall Mk II (aka second system syndrome in full effect).. You can do this with sysinstall already (although it isn't very clean). Also, you don't need floppies, you can do the whole install off a FAT32 USB stick with the aforementioned install.cfg file and a script run from that. I do this at work to do a partition minimal install, then untar a pre-populated FS generated from a chroot. It also asks various questions afterward for final tuning. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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
