Re: Two problems still present in RC3
On 12/11/11, Brett Glass wrote: > At 11:36 AM 12/11/2011, Ben Kaduk wrote: > >>Did you take the change to /etc/ttys going from cons25 to xterm 'type'? > > I didn't have to change it; it was that way when the OS was installed. > You were sending to -stable, so I wasn't sure. Thanks for confirming. > Problem seems to be that the behavior (specifically, reverse video on the > 25th line) doesn't quite match the xterm termcap entry. If I remember correctly, your original message mentioned seeing this issue in emacs; have you tried reproducing it in a simpler test case? Maybe something like: (for i in $(jot 25); do echo; tput mr; echo -n "reverse"; tput me; echo -n " regular"; done) && sleep 1 That would presumably help narrow down the issue. -Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Two problems still present in RC3
On Fri, Dec 9, 2011 at 4:13 AM, Brett Glass wrote: > Secondly, there's still some strangeness in the sc terminal emulation. When > I run jove, the status line at the bottom of the screen isn't entirely in > reverse video as it should be. Only parts of it are, and the highlighting > changes -- seemingly at random -- as I work. Did you take the change to /etc/ttys going from cons25 to xterm 'type'? -Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Old /etc files back, or cvs error?
On Tue, Feb 24, 2009 at 5:53 PM, Warren Block wrote: > > I guess I just don't understand. Why did that file and so many others in > /etc go backwards: > > 7.1-RELEASE had 1.3.6.1 2008/11/25 > > Three months later: > > RELENG_7 (7.1-STABLE) has 1.3 2006/05/18 > > Were those later versions (maybe just version strings) included in > 7.1-RELEASE by mistake? Were they tagged by mistake and this latest change > is just fixing that error? I think the 2008/11/25 date is from when RELENG_7_1 was branched --- the branch took place after the file was created, so it looks newer, even though the content is the same. -Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: lenovo t400 does not start 7.1
On Tue, Jan 13, 2009 at 1:57 PM, Harald Servat wrote: > Hello, > > I downloaded FreeBSD 7.1 (DVD iso image) for amd64 architecture (with > correct SHA256 checksum), but I'm unable to start the system (Lenovo T400). > > The boot process starts fine, the BTX messages appear, the 7-option menu > also appears, but when I hit enter (or when I choose start without ACPI or > start in safe mode) the \ symbols starts spinning for a while and then > freezes. Have you tried an ISO for FreeBSD-CURRENT? I also have a T400, and definitely had FreeBSD running on it for a while, but I don't remember if it was 7 or current. -Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Problems installing FreeBSD 7.0
On Tue, Dec 23, 2008 at 1:30 PM, Jack Raats wrote: > Hi, > > At this moment I have problems installing FreeBSD 6.4 and FreeBSD 7.0. > After booting from CD the system I get the menu. I have tried all possible > options. > The system starts checking all hardware but freezes after finding the CD-ROM > drives printing the GEOM_LABLE (on FB 7.0, not 6.4) > (acd0) > > The hardware is a Targa Visonary 2700XP, AMD 2700+ CPU, mem 1 GB > > Can anyone help me. I never had this problems before on other systems. > Have you tried booting in verbose mode? If so, does it give any further output after printing the GEOM_LABEL for the other drives? -Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upcoming Releases Schedule...
On Sat, Sep 20, 2008 at 9:52 PM, Aristedes Maniatis <[EMAIL PROTECTED]> wrote: > > On 21/09/2008, at 10:34 AM, netgeek wrote: > >> Perhaps there is a middle ground here? What about a statement that each >> major branch (6.x, 7.x) will be supported for at least 24+ months from its >> last production release? Smaller periods of support could be given to minor >> releases along the way (7.2, for example), but at least companies would know >> that if they installed a 6.x version, they'd have support for a couple of >> years, even if that might mean upgrading to a newer minor version if there >> was a problem. > > This is already the case [1]. From each major branch one or more releases > are designated as 'extended' and supported for 24 months. All you have to do > is pick one of those and you've got support for 24 months. For example 6.3 > has extended support in this way. > > RELENG_6 itself will be supported 24 months after the last release. Given > roughly 18 months between major releases and about 12 months of ongoing > releases from the previous branch after that, 4.5 years is roughly how long > each major branch is supported for. That is already clear as could be. I > can't quite understand what Jo Rhett is offering to the community that he is > upset isn't being taken up. I think he wants some other arbitrary point > release to be given extended support, either because in his case 24 months > is not enough, or because he wants every release to have 24 months of > support, or something else, I'm not sure. I think mostly, he just wants to know in advance which releases will have 24 months of support. Also, it would be very nice if those releases overlapped, so that one can jump from one long-tem-support release to the next. > > Jo, you say that he have had to maintain your own patched build of old > FreeBSD releases because you need to keep them in production for longer than > EoL period. Can I suggest that the first step is for you to publish those > patches somewhere public and allow others to have access to them. Then I'll second that. -Ben Kaduk > you'll have a chance of convincing others to contribute to your patch sets > and eventually of convincing FreeBSD to officially sanction them. Go and > create a new sourceforge project or convince your boss to set aside some > space on his web site/svn server/etc for this project. Tell him that if it > goes well, you'll be creating a whole lot of good will for the company in > addition to the prospect of getting other people to contribute and share the > work. > > > Ari Maniatis > > > > [1] http://security.freebsd.org/ > > > > --> > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming Releases Schedule...
On Fri, Sep 19, 2008 at 10:38 PM, Jo Rhett <[EMAIL PROTECTED]> wrote: > > On Sep 19, 2008, at 7:07 PM, Aragon Gouveia wrote: >>> >>> To get a business to commit resources to a project there must be an >>> actual goal. >> >> [1] The FreeBSD project would have to commit resources too. Its community > > Of course. This is what the requirements analysis is ;-) > >> For (a), (b), and (z), this is where you come in. Define the goal. Make >> a >> plan to get there. Assess the effort involved. Convince your employer >> that >> (a), (b) and (z) is worth it to him/her and that the result of (z) will >> convince the FreeBSD project to commit the resources needed to integrate >> it. >> If they're happy, start working on (z) and bring it to the FreeBSD project >> when you think it's ready. > > > Of course. If this was something that could be done without working with > the freebsd developers, do you think I would put up with this kind of abuse? > I'd much rather have something I could just go and do ;-) > > The issue is that nobody is willing to answer the question: "what resources > are too limited to provide longer support? How can we help?" > Jo, I think this is the clearest way you have stated your point yet, and it is quite definitely the crux of the issue: What resources does re@ not have, that releases are supported for these short times? I have never run a release, so I can't be much more specific that ``man-hours'' -- someone else should chime in and say what those hours would be spent on, if they were there. I think this is a great opportunity for the project, and a few pointers for how one could maintain an independent support of older releases would give the rest of us a great resource. -Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming Releases Schedule...
On Thu, Sep 4, 2008 at 2:40 PM, Jo Rhett <[EMAIL PROTECTED]> wrote: >>>> Where can one find the expected EoL for these releases? > >> On Wed, Sep 03, 2008 at 09:24:04PM -0700, Nathan Way wrote: >>> >>> http://www.freebsd.org/security/security.html#supported-branches >>> To quote from the above web site: (snip) > > On Sep 4, 2008, at 6:36 AM, Wesley Shields wrote: >> >> These are the existing releases. I believe Jo was looking for EoL for >> 7.1 and 6.4 once they are released. > > Yes, thank you. > To quote from the same website: Early adopter Releases which are published from the -CURRENT branch will be supported by the Security Officer for a minimum of 6 months after the release. Normal Releases which are published from a -STABLE branch will be supported by the Security Officer for a minimum of 12 months after the release. Extended Selected releases will be supported by the Security Officer for a minimum of 24 months after the release. I don't remember seeing any speculation about 6.4 being an extended release, so, EoL is 12 months after release, whenever that actually happens. I thought this was mentioned in the previous thread you started about EoL, but I didn't see it in a quick search. >> The answer to that is not clear - >> nor do I know if it should be clear yet. I don't know when the type of >> support decision is made, but I suspect it's not this early in the >> process. > > > The release date for 6.4 is ~30 days away, isn't it? > > Also given that we've previously seen overlaps such that a newer version is > only supported to the same EoL as the older version, that would pretty much > dictate that spending resources on testing 6.4-REL and/or upgrading would be > futile. > That's the difference between a long-term-support branch and a regular branch; many OSes do that. If you want to run the same machines for a long time and not have to do a huge battery of tests (at the expense of getting new features and better performance in the interim), you use long-term branches. The regular branches that get released later, will then become unsupported at the same time as the (older) long-term branch. Yes, it's poor when a long-term branch goes EoL before there's another one ready to take its place, but if the new one isn't ready, then you just use whichever regular release is current and then snag a long-term release when it becomes available. Yes, it's more work, but that's life. -Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Very large kernel
On Fri, Aug 15, 2008 at 7:55 PM, <[EMAIL PROTECTED]> wrote: > Quoting "Kris Kennaway" <[EMAIL PROTECTED]>: > >> Alex de Kruijff wrote: >>> >>> I noticed that the kernel directory was very large compaired to 6.1. Is >>> this for debugging and can I safely remove the symbols files I want to >>> save some space? >> >> Yes but if you encounter a panic and need to submit a bug report then you >> will need at least the kernel.debug and whatever modules you are using. > > Two questions for this ... > > a. can I move these to a larger partition temporarily, and if I have a > crash, move them back to do debugging? Yes. > > b. is there some setting I can use in make.conf to have it auto-install the > symbols files to a seperate directory on 'installkernel'? > I don't know of one, but that sounds like it could be useful. -Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how to get more logging from GEOM?
On Thu, Jul 17, 2008 at 7:11 AM, <[EMAIL PROTECTED]> wrote: > > -- Original message -- > From: "Ben Kaduk" <[EMAIL PROTECTED]> >> >> You don't need to compile the kernel on the same machine that you use it >> on -- you can copy the compiled kernel into /boot/kernel.new >> > But how do you handle the issue of differences in contents on the board where > you don't have exact identical hardwares? > The kernel configuration file specifies which device drivers will be included in the compiled kernel; if those devices aren't present in the system, the relevant code is present but doesn't get used. For example, the GENERIC kernel has the majority of device drivers included, so that most devices will be recognized out-of-the-box. A more difficult problem to solve is when you want to compile a kernel for a different architecture; say, to compile a kernel for x86 on an amd64 build machine. This can still be done, but it requires a fair amount more work. -Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: how to get more logging from GEOM?
On Wed, Jul 16, 2008 at 5:40 PM, Jo Rhett <[EMAIL PROTECTED]> wrote: > On Jul 11, 2008, at 4:48 AM, Ronald Klop wrote: >> >> You can try going into the kernel debugger to see where it is hanging. >> Debugging via a serial cable is also very easy. >> I don't know the details, but there is a lot of info in the Freebsd >> handbook. Put this in google 'freebsd handbook kernel debug'. > > > Thanks for the reply. I'm familiar with these options, but as the system is > currently running GENERIC and trying to compile a kernel would guarantee to > cause the problem to occur... I could probably keep hacking at it until I > finally get everything compiled, but... > > Ugh. I guess this option doesn't appeal very much. Are there any other > options available? > You don't need to compile the kernel on the same machine that you use it on -- you can copy the compiled kernel into /boot/kernel.new -Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0 issues fixed? upgrade timing?
On 5/13/08, Pyun YongHyeon <[EMAIL PROTECTED]> wrote: > > > There had been large changes to enhance re(4) stablility and many > users reported positive results. But it still seems to have issues > for certain models. See kern/123202, kern/123563. > If you encounter issues on latest re(4), please try patch in > kern/123563 and let me know how it goes. > > > > -Ben Kaduk > > Pyun, Thanks for the reminder -- I saw the changes go in, but forgot that this box was using re(4). Attempting to csup while running the March 25 driver made me sad, but a kernel.old from February worked well. I'm now running with if_re.c v 1.95.2.18 and I'm not seeing any packet loss or terminated ssh sessions. Thanks for all the good work! -Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 7.0 issues fixed? upgrade timing?
Hi all, I only just now subscribed, so my apologies if this has been covered and my cursory search missed it. I am seeing a similar issue to the one described in the email below (pasted from a web listing of this list). That is, my ssh connection will occasionally be dropped with the message Disconnecting: Bad packet length 3190815048. (the number is not always the same). I can reliably reproduce this with `cat < /dev/urandom | od -c` from a FreeBSD-current box (a few weeks old, actually, since the build was broken when I last tried to update) as well as from a mac running OS X 10.4 . The system that is killing my connections is: FreeBSD periphrasis.mit.edu 7.0-STABLE FreeBSD 7.0-STABLE #3: Tue Mar 25 14:53:51 EDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PERIPHRASIS amd64 Any thoughts would be appreciated. -Ben Kaduk -- random message from this thread, for some context - * From: Jeremy Chadwick <[EMAIL PROTECTED]> * Date: Mon, 12 May 2008 05:32:07 -0700 On Mon, May 12, 2008 at 01:44:22PM +0200, Torfinn Ingolfsen wrote: On Mon, 12 May 2008 11:37:53 +0200 Torfinn Ingolfsen <[EMAIL PROTECTED]> wrote: FWIW, I had major troubles with re(4) around 7.0-release, and a while later (I had to use patches). After upgrading to 7-stable on 2008-04-12, re(4) is working for me without patches. (sigh).. it seems that I spoke to soon. Murphy just showed up. I still get ssh disconnects (see below) on connections _to_ the machine when transferring largish amounts of data (like when upgrading a port). Here is one example (portupgrading the jdk port): /usr/bin/gcc -fno-strict-aliasing -fPIC -W -Wall -Wno-unused -Wno-parentheses -pipe -Damd64 -DARCH='"amd64"' -DRELEASE='"1.6.0_03-p4"' -DFULL_VERSION='"1.6.0_03-p4-root_12_may_2008_13_25-b00"' -D_GNU_SOURCE -D_REENTRANT -D_THREAD_SAFE -D_ALLBSD_SOURCE -D_LP64=1 -I. -I/usr/ports/java/jdk16/work/control/build/bsd-amd64/tmp/java/java.lang.management/management/CClassHeaders -I../../../src/solaris/javavm/export -I../../../src/share/javavm/export -I../../../src/share/javavm/include -I../../../src/solaris/javavm/include -I../../../src/share/native/sun/management -I../../../src/solaris/hpi/include -I../../../src/share/native/common -I../../../src/solaris/native/common -I../../../src/share/native/java/lang/management -I../../../src/solaris/native/java/lang/management -c -o /usr/ports/java/jdk16/work/control/build/bsd-amd64/tmp/java/java.lang.management/management/obj64/ClassLoadingImpl.o ../../../src/share/native/sun/management/ClassLoadingImpl.c Disconnecting: Bad packet length 3601161525. The machine is running: [EMAIL PROTECTED] uname -a FreeBSD kg-vm.kg4.no 7.0-STABLE FreeBSD 7.0-STABLE #10: Sat Apr 12 21:42:55 CEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC amd64 and has been up for about 14 days: [EMAIL PROTECTED] uptime 1:36PM up 14 days, 17:42, 7 users, load averages: 2.15, 1.85, 1.34 I see that if_re.c for RELENG_7 has been updated on April 22nd, so I'll upgrade the machine to latest -stable and see if that works better. Is this machine using pf(4) at all? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "Save as page..." freezes firefox for 15 minutes
On 7/24/05, manfred <[EMAIL PROTECTED]> wrote: > When the first time after loading firefox I choose File/Save Page as... > firefox freezes for 15 minutes. Then the "Save as" window opens and all > works fine. > > After newly choosing File/Save Page as... the "Save as" windows opens up > instantaneously. > > The problem doesn't disappear even after deleting ~/.mozilla before > starting firefox. > > > I'm running firefox 1.0.6 under FreeBSD 5.4. The problem occured also with > firefox 1.04. There is no CPU usage. It is simply a waiting situation. > However, I have not the faintest idea what firefox is waiting for. > > > Any ideas, how to track it down? > > -- > Manfred > > > > > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > I can't say that I'll be able to help you, but whoever can will want to see the output of 'ps -axl' for the firefox process, and perhaps what 'top' has to say as well. Can you send this information to the list? Ben Kaduk ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
