Re: Large port updates
[EMAIL PROTECTED] wrote: > Not in this case. Check /usr/ports/UPDATING 20041107: > : Do NOT use portupgrade(1) to update your GNOME 2.6 desktop to 2.8 Last time this happened, this is what caused my to deinstall gnome. THe upgrade script could take weeks to run on a reasonable spec machine because it insisted on rebuilding all sorts of stuff. You couldn't stop it, or it would start over. It seems to me that its a product of gnome being so many ports. Why not just have a few, like KDE (although it appears KDE is going the way of gnome - if this results in portupgrade not working there either, its insanity). Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Save the Demon!
[EMAIL PROTECTED] wrote: > > AFAIK, one of the main points of that logo competition is > to do away with anything that could be interpreted in an > religious way. Therefore an image of an Angel would be > completely inappropriate. (Why feminine anyway? Beastie > has no specific gender, therefore it would be best to not > bias the logo one way or the other.) I'm not seeing a problem here. Beastie is not a religious icon, not is it intended to be one. FreeBSD has no connection (afaik) with any religion. What we do have is a well recognised and accepted logo which has been around for a long time. Changing it because a couple of people have misinterpreted it strikes me as foot shooting. Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UPDATE2: ATA mkIII first official patches - please test!
[EMAIL PROTECTED] wrote: > Marcus Grando wrote: > > My problem persist... > > > > Any other patch? or idea? > > Hmm, does it work without apic ? without ACPI ? > And your cabling is correct and spec conformant ? > The 686A' I have in the lab works just dandy... Just an observation, but my Promise ATA-100 controller will drive 1 UDMA-66 and one UDMA-100 disk fine at UDMA-33 with the cable on the wrong way round (oops) using the previous update. Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB camera
[EMAIL PROTECTED] wrote: > > I'm afraid FreeBSD currently lacks support for USB video devices. There > > has been discussion of both porting V4L to BSD or creating a BSD video > > system, but I have yet to see any indication of when or if either will > > actually be available. > that would be really nice, finally a way to use my DVB-T card under FreeBSD > unfortunately I came to the same conclusion after reading -multimedia archi= > ve :( I think there would be a lot of support for this to happen, but it seems to be lacking in leadership and direction at the moment. The lack of a video capture framework for FreeBSD comes up all the time and is really hurting FreeBSD, Apps like TVTime, MythTV and Gnommeeting don't work properly on FreeBSD and this will cause people not to use it (we don't actually have a decently performing TV app on FreeBSD - mplayer is about as good as it gets and whilst that maintains a decent framerate, latency is nasty.). Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB camera
[EMAIL PROTECTED] wrote: > > I think there would be a lot of support for this to happen, but it seems > > to be lacking in leadership and direction at the moment. > > FreeBSD is not a top-down organization, it is bottom-up. In terms of > getting new functionality in, it is not concepts such as "leadership" > and "direction" that are important, it is "volunteers" and "time" and > "determination". > > Translation: this won't happen until and unless one or more volunteers > step up and put their time into it. Okay I'll rephrase. Somebody did step up, a Video4BSD spec was partially written and is probably still on the web somewhere. There a plenty of people interested in working on this (its probably quite a fun project), but nobody wants to step on anyone else's toes afaict. Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Stability
- Original Message - From: "Marcus Reid" <[EMAIL PROTECTED]> To: "Mike Hogsett" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, January 03, 2003 1:02 AM Subject: Re: FreeBSD Stability > I like to point people in the direction of: > > http://uptime.netcraft.com/up/today/top.avg.html > > The list is dominated by FreeBSD machines with > uptimes of longer than 1000 days. What is it that makes people rave about the longest uptime? To me, this is just a list of sites whose admins have neglected to perform the necessary upgrade-maintenances, seemingly for almost three years even. To me, this is just a list of potentially vulnerable sites. - Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Enabling DDB prevent kernel from panicing
All This was originally posted to hackers@ I have a good question that I cant find an answer for. I believe found a kernel bug in 7.3-RELEASE that prevents me from booting 64-bit kernels on HP's DL360 G4p . The kernel dies with "Fatal trap 12: page fault while in kernel mode " . The hardware works fine in 7.2-RELEASE amd64, 7.1-RELEASE amd64, and 6.4-RELEASE amd64 . In 7.3-RELEASE amd64 I can not boot from cd or pxe correctly using the stock 7.3-RELEASE amd64 kernel however i386 works fine. To see if this issue was some how fixed in 7.3-RELEASE-p4 amd64 I rebuilt a GENERIC kernel using patches sources and tried to boot and I got the same crash. Next I rebuilt the kernel with KDB and DDB to see if I could get a core-dump of the system. I also set loader.conf to kernel="kernel.DEBUG" kern.dumpdev="/dev/da0s1b" Next I pxebooted the box and the system does not crash on boot up, it will easily load a nfs root and work fine. So I copied my debug kernel, and loader.conf to the local disk and rebooted and it boots fine from the local disk . Rebooting the server and running off the local disks and debug kernel, I cant find any issues. Reboot the box into a GENERIC 7.3-RELEASE-p4 kernel and it crashes With this error Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x0 fault code = supervisor write data, page not present instruction pointer = 0x8:0x800070fa stack pointer= 0x10:0x8153cbe0 frame pointer= 0x10:0x8153cc50 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 = 0 (swapper) [thread pid 0 tid 10 ] Stopped at bzero+0xa: repe stosq %es:(%rdi) It was recommended to comment out the sio hints in /boot/device.hints I did this and I can properly boot a GENERIC 7.3-RELEASE kernel. I reran this same test using 7.4-RC1 the system boots with out any changes to anything. So my question, does anyone know what changed in stable/7 after the creation of 7.3-RELEASE that could have fixed this or does anyone know what could be causing this issue. The sio code does not look like its been changed in a long while . Do we still need s the hits for the sio ports anyway does omitting them from the hints file cause any major issues, I can use the serial port for a console and to connect to to other serial devices with out any issues. -- mark saad | nones...@longcount.org ___ 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: Enabling DDB prevent kernel from panicing
On Mon, Jan 10, 2011 at 6:59 PM, wrote: > Hello, Mark > > 2011/1/11 Mark Saad : >> All >> This was originally posted to hackers@ >> >> I have a good question that I cant find an answer for. I believe >> found a kernel bug in 7.3-RELEASE that prevents me from booting 64-bit >> kernels on HP's DL360 G4p . The kernel dies with "Fatal trap 12: page >> fault while in kernel mode " . The hardware works fine in 7.2-RELEASE >> amd64, 7.1-RELEASE amd64, and 6.4-RELEASE amd64 . >> >> In 7.3-RELEASE amd64 I can not boot from cd or pxe correctly using the >> stock 7.3-RELEASE amd64 kernel however i386 works fine. To see if this >> issue was some how fixed in 7.3-RELEASE-p4 amd64 I rebuilt a GENERIC >> kernel using patches sources and tried to boot and I got the same >> crash. >> >> Next I rebuilt the kernel with KDB and DDB to see if I could get a >> core-dump of the system. I also set loader.conf to >> >> kernel="kernel.DEBUG" >> kern.dumpdev="/dev/da0s1b" >> >> Next I pxebooted the box and the system does not crash on boot up, it >> will easily load a nfs root and work fine. So I copied my debug >> kernel, and loader.conf to the local disk and rebooted and it boots >> fine from the local disk . > > Looks like a race condition. > Well, you don't need to compile KDB and DDB, just add > > makeoptions DEBUG=-g > > into your kernel config file and rebuild kernel. > > Then after you got a crash dump you can easy debug it (see FreeBSD > Developers Handbok): > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html > > > wbr, > Nickolas > Sorry let me clarify the issue, When you install a generic 7.3-RELEASE amd64 on some of the HP servers I use, the kernel panics in boot up when it probes the sio driver . Here is a part of my dmesg.boot file atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio0: [FILTER] Say about here in the boot up , is where the box crashes with the above noted error. If I then boot the same box off a 7.1-RELEASE amd64 netboot server , mount the local disks of the 7.3-RELEASE install and edit the /boot/device.hints and comment out the sio hints like this hint.vga.0.at="isa" hint.sc.0.at="isa" hint.sc.0.flags="0x100" #hint.sio.0.at="isa" #hint.sio.0.port="0x3F8" #hint.sio.0.flags="0x10" #hint.sio.0.irq="4" #hint.sio.1.at="isa" #hint.sio.1.port="0x2F8" #hint.sio.1.irq="3" #hint.sio.2.at="isa" #hint.sio.2.disabled="1" #hint.sio.2.port="0x3E8" #hint.sio.2.irq="5" #hint.sio.3.at="isa" #hint.sio.3.disabled="1" #hint.sio.3.port="0x2E8" #hint.sio.3.irq="9" hint.ppc.0.at="isa" hint.ppc.0.irq="7" then boot the server off the local disks , the server boots correctly. The odd thing was, I rebuilt a debug 7.3-RELEASE amd64 kernel on another working server, and installed it on the broken server and booted it off the local disks, with out any changes to the hints file and the server booted correctly and I was able to manually break out into the debugger , but nothing looked wrong . So to sum this up there is something broken in 7.3-RELEASE but I cant figure out what. This server works with a generic install of 7.1-RELEASE 7.2-RELEASE , 6.1-RELEASE, 6.2-RELEASE and 6.4-RELEASE in both amd64 and i386 , but not 7.3-RELEASE in amd64 . It also worked in 7.4-RC1 . avg recommended I see what changed from r212964 to r212994 I am currently looking into this . Has anyone seen this before ? -- mark saad | nones...@longcount.org ___ 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: Enabling DDB prevent kernel from panicing
On Mon, Jan 10, 2011 at 9:13 PM, Jeremy Chadwick wrote: > On Mon, Jan 10, 2011 at 07:42:21PM -0500, Mark Saad wrote: >> On Mon, Jan 10, 2011 at 6:59 PM, wrote: >> > Hello, Mark >> > >> > 2011/1/11 Mark Saad : >> >> All >> >> This was originally posted to hackers@ >> >> >> >> I have a good question that I cant find an answer for. I believe >> >> found a kernel bug in 7.3-RELEASE that prevents me from booting 64-bit >> >> kernels on HP's DL360 G4p . The kernel dies with "Fatal trap 12: page >> >> fault while in kernel mode " . The hardware works fine in 7.2-RELEASE >> >> amd64, 7.1-RELEASE amd64, and 6.4-RELEASE amd64 . >> >> >> >> In 7.3-RELEASE amd64 I can not boot from cd or pxe correctly using the >> >> stock 7.3-RELEASE amd64 kernel however i386 works fine. To see if this >> >> issue was some how fixed in 7.3-RELEASE-p4 amd64 I rebuilt a GENERIC >> >> kernel using patches sources and tried to boot and I got the same >> >> crash. >> >> >> >> Next I rebuilt the kernel with KDB and DDB to see if I could get a >> >> core-dump of the system. I also set loader.conf to >> >> >> >> kernel="kernel.DEBUG" >> >> kern.dumpdev="/dev/da0s1b" >> >> >> >> Next I pxebooted the box and the system does not crash on boot up, it >> >> will easily load a nfs root and work fine. So I copied my debug >> >> kernel, and loader.conf to the local disk and rebooted and it boots >> >> fine from the local disk . >> > >> > Looks like a race condition. >> > Well, you don't need to compile KDB and DDB, just add >> > >> > makeoptions DEBUG=-g >> > >> > into your kernel config file and rebuild kernel. >> > >> > Then after you got a crash dump you can easy debug it (see FreeBSD >> > Developers Handbok): >> > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html >> > >> > >> > wbr, >> > Nickolas >> > >> >> Sorry let me clarify the issue, When you install a generic >> 7.3-RELEASE amd64 on some of the HP servers I use, the kernel panics >> in boot up >> when it probes the sio driver . Here is a part of my dmesg.boot file >> >> atkbd0: [ITHREAD] >> psm0: irq 12 on atkbdc0 >> psm0: [GIANT-LOCKED] >> psm0: [ITHREAD] >> psm0: model Generic PS/2 mouse, device ID 0 >> sio0: configured irq 4 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> sio0: configured irq 4 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> sio0: port 0x3f8-0x3ff irq 4 on acpi0 >> sio0: type 16550A >> sio0: [FILTER] >> Say about here in the boot up , is where the box crashes with the >> above noted error. >> >> If I then boot the same box off a 7.1-RELEASE amd64 netboot server , >> mount the local disks of the 7.3-RELEASE install and edit the >> /boot/device.hints and comment out the sio hints like this >> >> hint.vga.0.at="isa" >> hint.sc.0.at="isa" >> hint.sc.0.flags="0x100" >> #hint.sio.0.at="isa" >> #hint.sio.0.port="0x3F8" >> #hint.sio.0.flags="0x10" >> #hint.sio.0.irq="4" >> #hint.sio.1.at="isa" >> #hint.sio.1.port="0x2F8" >> #hint.sio.1.irq="3" >> #hint.sio.2.at="isa" >> #hint.sio.2.disabled="1" >> #hint.sio.2.port="0x3E8" >> #hint.sio.2.irq="5" >> #hint.sio.3.at="isa" >> #hint.sio.3.disabled="1" >> #hint.sio.3.port="0x2E8" >> #hint.sio.3.irq="9" >> hint.ppc.0.at="isa" >> hint.ppc.0.irq="7" >> >> then boot the server off the local disks , the server boots correctly. >> >> The odd thing was, I rebuilt a debug 7.3-RELEASE amd64 kernel on >> another working server, and installed it on the broken server and >> booted it off the local disks, with out any changes to the hints file >> and the server booted correctly and I was able to manually break out >> into the debugger , but nothing looked wrong . > > The sio(4) driver has been deprecated in RELENG_8, which uses uart(4). > uart(4) is better in a lot of regards, and should also be available for > use on RELENG_7 but you'll need to adjust /etc/ttys to refer to the new > device names (ttyuX vs. ttydX), plus add the u
Re: Enabling DDB prevent kernel from panicing
On Mon, Jan 10, 2011 at 10:29 PM, Mark Saad wrote: > On Mon, Jan 10, 2011 at 9:13 PM, Jeremy Chadwick > wrote: >> On Mon, Jan 10, 2011 at 07:42:21PM -0500, Mark Saad wrote: >>> On Mon, Jan 10, 2011 at 6:59 PM, wrote: >>> > Hello, Mark >>> > >>> > 2011/1/11 Mark Saad : >>> >> All >>> >> This was originally posted to hackers@ >>> >> >>> >> I have a good question that I cant find an answer for. I believe >>> >> found a kernel bug in 7.3-RELEASE that prevents me from booting 64-bit >>> >> kernels on HP's DL360 G4p . The kernel dies with "Fatal trap 12: page >>> >> fault while in kernel mode " . The hardware works fine in 7.2-RELEASE >>> >> amd64, 7.1-RELEASE amd64, and 6.4-RELEASE amd64 . >>> >> >>> >> In 7.3-RELEASE amd64 I can not boot from cd or pxe correctly using the >>> >> stock 7.3-RELEASE amd64 kernel however i386 works fine. To see if this >>> >> issue was some how fixed in 7.3-RELEASE-p4 amd64 I rebuilt a GENERIC >>> >> kernel using patches sources and tried to boot and I got the same >>> >> crash. >>> >> >>> >> Next I rebuilt the kernel with KDB and DDB to see if I could get a >>> >> core-dump of the system. I also set loader.conf to >>> >> >>> >> kernel="kernel.DEBUG" >>> >> kern.dumpdev="/dev/da0s1b" >>> >> >>> >> Next I pxebooted the box and the system does not crash on boot up, it >>> >> will easily load a nfs root and work fine. So I copied my debug >>> >> kernel, and loader.conf to the local disk and rebooted and it boots >>> >> fine from the local disk . >>> > >>> > Looks like a race condition. >>> > Well, you don't need to compile KDB and DDB, just add >>> > >>> > makeoptions DEBUG=-g >>> > >>> > into your kernel config file and rebuild kernel. >>> > >>> > Then after you got a crash dump you can easy debug it (see FreeBSD >>> > Developers Handbok): >>> > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-gdb.html >>> > >>> > >>> > wbr, >>> > Nickolas >>> > >>> >>> Sorry let me clarify the issue, When you install a generic >>> 7.3-RELEASE amd64 on some of the HP servers I use, the kernel panics >>> in boot up >>> when it probes the sio driver . Here is a part of my dmesg.boot file >>> >>> atkbd0: [ITHREAD] >>> psm0: irq 12 on atkbdc0 >>> psm0: [GIANT-LOCKED] >>> psm0: [ITHREAD] >>> psm0: model Generic PS/2 mouse, device ID 0 >>> sio0: configured irq 4 not in bitmap of probed irqs 0 >>> sio0: port may not be enabled >>> sio0: configured irq 4 not in bitmap of probed irqs 0 >>> sio0: port may not be enabled >>> sio0: port 0x3f8-0x3ff irq 4 on acpi0 >>> sio0: type 16550A >>> sio0: [FILTER] >>> Say about here in the boot up , is where the box crashes with the >>> above noted error. >>> >>> If I then boot the same box off a 7.1-RELEASE amd64 netboot server , >>> mount the local disks of the 7.3-RELEASE install and edit the >>> /boot/device.hints and comment out the sio hints like this >>> >>> hint.vga.0.at="isa" >>> hint.sc.0.at="isa" >>> hint.sc.0.flags="0x100" >>> #hint.sio.0.at="isa" >>> #hint.sio.0.port="0x3F8" >>> #hint.sio.0.flags="0x10" >>> #hint.sio.0.irq="4" >>> #hint.sio.1.at="isa" >>> #hint.sio.1.port="0x2F8" >>> #hint.sio.1.irq="3" >>> #hint.sio.2.at="isa" >>> #hint.sio.2.disabled="1" >>> #hint.sio.2.port="0x3E8" >>> #hint.sio.2.irq="5" >>> #hint.sio.3.at="isa" >>> #hint.sio.3.disabled="1" >>> #hint.sio.3.port="0x2E8" >>> #hint.sio.3.irq="9" >>> hint.ppc.0.at="isa" >>> hint.ppc.0.irq="7" >>> >>> then boot the server off the local disks , the server boots correctly. >>> >>> The odd thing was, I rebuilt a debug 7.3-RELEASE amd64 kernel on >>> another working server, and installed it on the broken server and >>> booted it off the local disks, with out any changes
Re: geom_label, fstab without device names & swap partition?
On Wed, Jan 12, 2011 at 1:54 PM, Freddie Cash wrote: > 2011/1/12 Lev Serebryakov : >> Now, with "newfs -L name", geom_label and /dev/ufs/* it is possible >> to not use device names for FSes in "/etc/fstab" at all. But what to >> do with swap partitions? How to say, that I want swap on >> "/dev/ada0s1b" or "/dev/ad0s1b" whatever name it has now? > > Use glabel(8) to label the device: > > # glabel label swap ada0s1b On a side note there is not a simple way to glabel mounted filesystem > > Then point to the label in /etc/fstab: > > /dev/label/swap swap sw ... > > > -- > Freddie Cash > fjwc...@gmail.com > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > glabel is also great for doing silly things like things like this glabel label leftdrive0 /dev/ad4 glabel label rightdrive0 /dev/ad5 gmirror label -v -b load raid1 leftdrive0 rightdrive0 this way when you get a gmirror status you can easily tell which drive is doing what, red rebuilding etc . -- mark saad | nones...@longcount.org ___ 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: geom_label, fstab without device names & swap partition?
On Wed, Jan 12, 2011 at 3:01 PM, Freddie Cash wrote: > On Wed, Jan 12, 2011 at 12:00 PM, Mark Saad wrote: >> On Wed, Jan 12, 2011 at 1:54 PM, Freddie Cash wrote: >>> 2011/1/12 Lev Serebryakov : >>>> Now, with "newfs -L name", geom_label and /dev/ufs/* it is possible >>>> to not use device names for FSes in "/etc/fstab" at all. But what to >>>> do with swap partitions? How to say, that I want swap on >>>> "/dev/ada0s1b" or "/dev/ad0s1b" whatever name it has now? >>> >>> Use glabel(8) to label the device: >>> >>> # glabel label swap ada0s1b >> >> On a side note there is not a simple way to glabel mounted filesystem > > True, but for a swap partition, it's easy to disable swap, label the > partition, and re-enable swap. :) > > -- > Freddie Cash > fjwc...@gmail.com > Well the thing is I like use glabel in place of a fs label as it makes my devices all names something similar /dev/label/thingie rather then have /dev/ufs/rootfs and /dev/label/swap , I'll have /dev/label/rootfs /dev/label/swap. Also I dont think you can easily change a live label either . -- mark saad | nones...@longcount.org ___ 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: sed is broken under freebsd?
On Wed, Jan 12, 2011 at 5:32 PM, Bob Willcox wrote: > On Tue, Jan 11, 2011 at 09:00:09PM -1000, Clifton Royston wrote: >> On Wed, Jan 12, 2011 at 02:32:52AM +0100, Oliver Pinter wrote: >> > hi all! >> > >> > The freebsd versions of sed contained a bug/regression, when \n char >> > can i subsitue, gsed not affected with this bug: >> >> > FreeBSD xxx 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 >> > UTC 2010 r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >> > i386 >> > a...@xxx ~> echo axa | sed s/x/\n/g >> > ana >> > a...@xxx ~> echo axa | sed s/x/'\n'/g >> > ana >> >> Different than GNU is not a bug. >> >> I have 7.3 here. It behaves as the above, which is how the man page says it >> should work. The following is how the man page specifies you can substitute >> a newline, by prefacing a quoted actual newline with a backslash: >> >> $ echo axa | sed 's/x/\ >> > /g' >> a >> a >> >> That's how I remember classic sed behaving (Unix v7 or thereabouts.) >> -- Clifton > > FWI, AIX 6.1 sed works as the FreeBSD sed does. Solaris 2.6 and OSX 10.6 , do the same thing as FreeBSD as well. -- mark saad | nones...@longcount.org ___ 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: Living on gmirror: need to reincarnate /etc/rc.early
On Wed, Jan 26, 2011 at 9:17 AM, Alfred Bartsch wrote:
> Doug Barton schrieb:
>> On 01/24/2011 23:20, Eugene Grosbein wrote:
>>> Hi!
>>>
>>> In RELENG_8, gmirror is good enough to keep whole HDD pair withing the
>>> mirror.
>>> Its performance, stability any pretty ease of maintainance allows
>>> to use it widely.
>>>
>>> With wide deployment of gmirror in production I've faced inability
>>> of RELENG_8 to store kernel crashdumps out-of-the-box.
>>> gmirror manual page documents a way to setup FreeBSD so that
>>> it would store crashdumps again but that way involves /etc/rc.early
>>> removed from RELENG_8. I've read about intentions - it was unsafe etc.
>>> But we still need working crashdump support.
>>>
>>> Easiest way is to reincarnate /etc/rc.d/early support making it better
>>> and safer
>>> and it should support gmirror's mechanics for crashdumps out-of-the-box.
>>
>> I'll tell you the same thing I told Kostik way back when I removed it.
>> This is the only thing that anyone has ever suggested a use for in
>> /etc/rc.early, and the "solution" in the man page is a hack. :)
>>
>> If this is something that is necessary to do then I'd prefer to do it
>> properly and add an /etc/rc.d/gmirror that runs in the proper (early)
>> position, and then figure out the proper location in rc.d to handle the
>> second half of the configuration.
>>
>> I'm happy to review patches. :)
>>
>>
>> Doug
>>
> Hi Doug,
> at our site we are using the following scripts in /etc/rc.d to deal with
> gmirror "specials":
>
> First part (/etc/rc.d/gmirror1):
>
> #!/bin/sh
>
> # PROVIDE: gmirror1
> # BEFORE: fsck
> # KEYWORD: nojail
>
> . /etc/rc.subr
>
> name="gmirror1"
> start_cmd="gmirror1_start"
> stop_cmd=":"
>
>
> gmirror1_start()
> {
> echo "gmirror configure -b prefer gm0"
> gmirror configure -b prefer gm0
> }
>
> load_rc_config $name
> run_rc_command "$1"
>
> # run only if provider /dev/mirror/gm0 exists
> test -r /dev/mirror/gm0 || exit 0
> -
> Second part (/etc/rc.d/gmirror2):
>
> #!/bin/sh
>
> # PROVIDE: gmirror2
> # REQUIRE: DAEMON
> # BEFORE: LOGIN
> # KEYWORD: nojail
>
> . /etc/rc.subr
>
> name="gmirror2"
> start_cmd="gmirror2_start"
> stop_cmd=":"
>
> gmirror2_start()
> {
> echo "gmirror configure -b round-robin gm0"
> gmirror configure -b round-robin gm0
> }
>
> load_rc_config $name
> run_rc_command "$1"
>
> # run only if provider /dev/mirror/gm0 exists
> test -r /dev/mirror/gm0 || exit 0
> -
>
> In our environment, the name of the gmirror provider is always
> "mirror/gm0". Variable naming of the provider should be added,
> eventually extracted from "gmirror list" command.
>
> --
> Alfred Bartsch
>
> ___
> 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"
>
On a side note without /etc/rc.early how would someone do the following tasks ?
1. On bootup relabel /dev/da2s1d to /dev/label/var where da2s1d is the
var for this box.
2. Convert /usr from gjournal to su+j
Not each task is exactly the same from server to server do to how each
installer / admin decided to layout each disk.
As you may know you cant relabel via glabel label, tunefs -J disable,
gjournal off ..
on a disk that was mounted read / write . The old /etc/rc.early
allowed users to shoot quick scripts in there to fix systems on
a reboot, which is very useful for systems you do not have direct
console access to .
So are we supposed to make a rcng script for each task, is there
another way I am missing ?
--
mark saad | nones...@longcount.org
___
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"
RELEASE_6 -> RELEASE_8
I was trying to upgrade a machine from RELEASE_6 (latest)
to RELEASE_8 (latest) via source. I was unable to get
make buildworld to complete.
There were two problems sets of problems.
libelf and sys headers were not available to some of the
solaris derived parts. include_next's failed. Adding extra
-I's to the Makefiles allowed these parts to complete. The
first missing header was sys/elf.h so that should help
locate the correct Makefile.
Linking then failed due to __stack_chk_fail_local not being
found. i386 build.
Sorry this report is not more complete as I blew away the
tree and restarted on RELEASE_7 as a stepping stone to
RELEASE_8.
RELEASE_7 latest will at least compile. However it will
only run in safe mode as it dies in ar5212Detach with a
kernel fault. I suspect this will also be a problem for
RELEASE_8.
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: RELEASE_6 -> RELEASE_8
In message <4d46119f.5060...@sentex.net>, Mike Tancsa writes: > On 1/30/2011 6:45 PM, Mark Andrews wrote: > > I was trying to upgrade a machine from RELEASE_6 (latest) > > to RELEASE_8 (latest) via source. I was unable to get > > make buildworld to complete. > > Strange, I have done a number of machines going from RELENG_6, RELENG_7 > and then RELENG_8 without too much issue. The ports can be a bit > problematic, but of the half dozen or so I have done, it hasnt been an > issue. Were you using a custom kernel, or GENERIC as defined from each > of the branches ? It's the double release jump that doesn't work. Looking at 7.x the headers needed are installed in /usr/include. Similarly 7.x's gcc has the symbol but doesn't turn on the compiler flags which use it. Basically RELENG_8 is not completely building against itself. Trying to go from 6.x to 8.x is showing some of places where the new OS doesn't build against itself. This was with GENERIC for all builds and almost no ports installed. > ---Mike -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: RELEASE_6 -> RELEASE_8
Mark Andrews writes:
>
> In message <4d46119f.5060...@sentex.net>, Mike Tancsa writes:
> > On 1/30/2011 6:45 PM, Mark Andrews wrote:
> > > I was trying to upgrade a machine from RELEASE_6 (latest)
> > > to RELEASE_8 (latest) via source. I was unable to get
> > > make buildworld to complete.
> >
> > Strange, I have done a number of machines going from RELENG_6, RELENG_7
> > and then RELENG_8 without too much issue. The ports can be a bit
> > problematic, but of the half dozen or so I have done, it hasnt been an
> > issue. Were you using a custom kernel, or GENERIC as defined from each
> > of the branches ?
>
> It's the double release jump that doesn't work. Looking at 7.x the
> headers needed are installed in /usr/include. Similarly 7.x's gcc
> has the symbol but doesn't turn on the compiler flags which use it.
> Basically RELENG_8 is not completely building against itself. Trying
> to go from 6.x to 8.x is showing some of places where the new OS
> doesn't build against itself.
>
> This was with GENERIC for all builds and almost no ports installed.
The following Makefiles needed to be modified to add
-I${.CURDIR}/../../../lib/libelf and/or -I${.CURDIR}/../../../sys.
/usr/release8/src/cddl/usr.bin/sgsmsg/Makefile lib/libelf
/usr/release8/src/cddl/lib/libctf/Makefile lib/libelf sys
/usr/release8/src/cddl/usr.bin/ctfconvert/Makefile lib/libelf sys
/usr/release8/src/cddl/usr.bin/ctfmerge/Makefile sys
e.g.
CFLAGS+=-I${.CURDIR}/../../../sys/cddl/compat/opensolaris \
-I${.CURDIR}/../../../cddl/compat/opensolaris/include \
-I${.CURDIR}/../../../lib/libelf \
-I${.CURDIR}/../../../sys \
-I${OPENSOLARIS_USR_DISTDIR} \
-I${OPENSOLARIS_SYS_DISTDIR} \
-I${OPENSOLARIS_USR_DISTDIR}/head \
-I${OPENSOLARIS_USR_DISTDIR}/tools/ctf/common \
-I${OPENSOLARIS_USR_DISTDIR}/tools/ctf/cvt \
-I${OPENSOLARIS_SYS_DISTDIR}/uts/common
"make make" is also needed for 6.x -> 8.x so that should be
added to UPDATING.
The build will then run until stopping in libexec/atrun with
/usr/release8/usr/release8/src/tmp/usr/lib/libpam.so: undefined reference to
`__stack_chk_fail_local'
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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"
Removing all ZFS support from boot process
Hi, FreeBSD 8.1 r218475. I have a raidz2 with 6x2TB devices; 3x2tb HDD and 3 stripes of 2x1TB HDD. I have ufs / on USB flash. After boot0 starts and the USB boots it displays Drive C: is disk0 etc. for each drive. Then I can hear all the drives making noises. Sounds like the devices are being tasted, with the spinning char. This goes on for sometime. Often the machine hangs solid and I have to reset. It can take 3 or 4 attempts before the OS boots. I can tell it's hung by pressing the caps lock key. If the capslock light doesn't work I hit reset and cross my fingers. It's been like this for as long as I can remember (i.e. many different source trees). How can I fix this? I thought it might be a BIOS fault and not FBSD, so I was considering a new motherboard. However, if I have ufs / can't I stop all this tasting/zfs nonsense at boot and let the kernel do it all later and therefore not susceptible to any possible BIOS faults? I tried to rebuild with: LOADER_ZFS_SUPPORT=no in make.conf, but it seems to make no difference. Any ideas? Thanks. -- Mark Powell - UNIX System Administrator - The University of Salford IT Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 6624 www.pgp.com for PGP key ___ 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: Removing all ZFS support from boot process
On Fri, 11 Feb 2011, Daniel O'Connor wrote: This is before the kernel boots, correct? Yep. Can you take a picture of where it hangs? (you will have to host it somewhere though, as the list will reject non text attachments). Here you go: http://galatea.salford.ac.uk/aix502/11022011448.jpg http://galatea.salford.ac.uk/aix502/11022011449.jpg The spinning char can seemingly be in any position when it crashes. It took 5 attempts that time to get to the beastie menu. I suspect it's in the loader and quite possibly it's your BIOS that is at fault, or at the very least there is a nasty interaction with it. Is there an update for the BIOS? Does this happen on other hardware? I suspected BIOS, that's why I was going to get a new motherboard. I've always had problems getting gptzfsboot working on this hardware and there are no more BIOS updates now. That's why I have ufs root, as it only worked intermitantly. Then I wondered what the hell was going on in the loader that took >60s and seemingly touched every drive. I assumed it was FBSD that was tasting all the drives. Cheers. -- Mark Powell - UNIX System Administrator - The University of Salford IT Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 6624 www.pgp.com for PGP key ___ 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: Removing all ZFS support from boot process
On Fri, 11 Feb 2011, Christian Walther wrote: AFAIK if you have gptzfsboot on your drives it will probe the partitions on your drives, which can take a while. So if you suspect ZFS it might really be an option to replace gptzfsboot with gptboot. I have ufs / so isn't /boot/boot (loaded from slice start) in operation during this crash? Thanks. -- Mark Powell - UNIX System Administrator - The University of Salford IT Services, Clifford Whitworth Building, Salford University, Manchester, M5 4WT, UK. Tel: +44 161 295 6843 Fax: +44 161 295 6624 www.pgp.com for PGP key ___ 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"
Panic from linux emulation (flashplugin)
I'm sending this to both stable and emulation lists, but I'm not subscribed to the emulation list so please cc: me there. Hi guys, I'm told this is known but I can't find any information. I'm running the checkout for RELENG_8_2 from Thursday and the issue I'm having on my amd64 Desktop is that every time I play a flash video (my only real use of linux emulation) it causes a kernel panic. This happens in Opera, Firefox, and Chromium. Another user in Freenode's ##freebsd said he is experiencing this too. I've seen nothing mentioned on the freebsd-emulation mailing list. Any thoughts? Thanks, Mark Relevant info: 10:56:08 skeletor:~ > uname -a FreeBSD skeletor.feld.me 8.2-RELEASE FreeBSD 8.2-RELEASE #1: Thu Feb 17 13:03:46 CST 2011 r...@mwi1.coffeenet.org:/usr/obj/usr/src/sys/GENERIC amd64 10:57:11 skeletor:~ > sudo kldstat Password: Id Refs AddressSize Name 1 53 0x8010 c9fe20 kernel 21 0x80da 24d98snd_hda.ko 34 0x80dc5000 75668sound.ko 41 0x80e3b000 13b98snd_uaudio.ko 51 0x80e4f000 f080 aio.ko 61 0x80e5f000 ffb0 ahci.ko 71 0x80e6f000 52d8 atapicam.ko 81 0x80e75000 d08de0 nvidia.ko 93 0x81b7e000 42558linux.ko 103 0x81bc1000 45ed0vboxdrv.ko 111 0x81e22000 3ee0 linprocfs.ko 122 0x81e26000 28ae vboxnetflt.ko 132 0x81e29000 8d44 netgraph.ko 141 0x81e32000 1532 ng_ether.ko 151 0x81e34000 d0c vboxnetadp.ko 161 0x81e35000 a1c pflog.ko 171 0x81e36000 2bd81pf.ko 181 0x81e62000 a8ea fuse.ko I was running linux-f10-flashplugin10 10.2r152 ___ 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: Panic from linux emulation (flashplugin)
On Mon, 21 Feb 2011 13:24:25 -0600, Juergen Lock wrote: I see you use the nvidia blob (I use radeon with xorg drivers), did you rebuild the nvidia driver port after upgrading to 8.2? Or maybe this has something to do with the vdpau support that was added to flash with the last update and that others reported as possibly not working properly on FreeBSD... Aha! This is probably it! I just upgraded my workstation at work to 8.2 (also nvidia) and I am not having the crash but I also don't have that newer flash version that includes vdpau support. I will downgrade the flash version at home and report back. It would possibly also be wise to contact the maintainer and have him mark the port as BROKEN or conflicting or something if you're running nvidia so people don't run into this issue. Thanks, Mark ___ 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: Panic from linux emulation (flashplugin)
On Mon, 21 Feb 2011 16:42:59 -0600, Mark Felder wrote: I was talking about the maintainer of the flashplugin in ports. That would be Nox. I have sent him an email. Oh dear I take that back. He was the last person to submit an update, not the maintainer. Whoops! Mark ___ 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: Panic from linux emulation (flashplugin)
On Mon, 21 Feb 2011 16:39:49 -0600, Juergen Lock wrote: So on the box that got the panic the nvidia driver port was rebuilt after the src/kernel upgrade? Correct. The maintainer is emulation@... But yes if its confirmed and can't be fixed we should probably patch the flash binary to stop it from trying to load libvdpau (like by patching the filename to something nonexisting?) I was talking about the maintainer of the flashplugin in ports. That would be Nox. I have sent him an email. Regards, Mark ___ 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: 3TB disc and block alignment
On Mon, 21 Feb 2011 10:16:37 -0600, Kurt Jaeger wrote: Hi! > Hmm, wasn't the issues with 3T drives, that they internally use > 4K blocks and emulate 512 and that therefore 8 block alignments > are an performance issue ? Hi guys, I'd just like to jump on this train real quick since I have a related question with alignment. I've been building new Virtual Machine templates lately because I recently learned that our SAN which we access over iSCSI uses 64K blocks and the default FreeBSD install starts a filesystem on sector 63 (512K sectors). This would be misaligned for most I/O transactions. As a result, I updated our internal documentation for FreeBSD standards to be 64K aligned by manually installing FreeBSD with GPT and making the FreeBSD-boot partition 64K in size: Fixit# gpart create -s gpt da0 Fixit# gpart add -t freebsd-boot -s 64K da0 Fixit# gpart add -t freebsd-swap -s 2G -b 2048 da0 Fixit# gpart add -t freebsd-ufs da0 Fixit# gpart bootcode -b /dist/boot/pmbr -p /dist/boot/gptboot -i 1 da0 At the time, the examples I found used -s 64K for the freebsd-boot partition which starts the next partition/filesystem on the next 64K block which would be aligned for our purposes. However, I have been seeing -s 1024K or larger which is also 64K aligned, but just larger. Am I shooting myself in the foot by not going ahead and aligning with -s 1024K or -s 2048K right now? Thanks for your opinions, Mark ___ 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: Panic from linux emulation (flashplugin)
Well it started happening again. Basically what I did was rebuild all of ports which downgraded my nvidia driver. I was getting consistent crashes in youtube after this happened. I upgraded my nvidia driver to 260.19.44 by modifying the port and now I can't get it to crash anymore. *HOWEVER* This may or may not be unrelated -- I'm running opera and have a youtube video hidden in another tab. I have upgraded my nvidia driver but didn't reboot, just removed the kernel module and started X again. For some reason the Youtube video in the hidden tab is able to be seen when I put my terminal over the area where it would be if it was in the active tab. http://feld.me/stuff/flash_bug.png is an example of it. I haven't yet rebooted to see what happens on a clean boot, but this is certainly interesting... perhaps bad flash/linuxulator behavior that doesn't trip a panic in the newer nvidia drivers? Weird stuff either way... Now that I have seemingly figured out the combination to a crash I'll see if I can catch one on the console and have something worthwhile to report. Regards, Mark ___ 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: bin/139146 still not right in FreeBSD 8.2 (-m32 on amd64)?
On Wed, Mar 09, 2011 at 03:15:39PM -0500, Thomas David Rivers wrote: > But, when I try to build 32-bit programs I get problems linking, > and I stumbled onto PR bin/139146. That one was closed as a duplicate of gnu/112215. I've forwarded your email to GNATS with the followup redirected there. mcl ___ 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: happy hacker lite 2 keyboard
On Thu, 10 Mar 2011 10:15:27 -0600, Zoran Kolic wrote: Quite late return to the subject. I finally ordered one for myself and have a question regarding it's usage with 64 bit system. All newer HH keuboards are usb ones. Manufacturer doesn't confirm connection to ps/2 port with usb to ps/2 adapter. Is there any reason not to do that on amd64? Hrm, strange that a nice keyboard like that comes as USB only. My Adesso comes natively as PS/2 but has a PS/2 to USB converter that works flawlessly. The idea is that PS/2 is better for keyboards because it allows you to simultaneously press more keys at once than USB can handle. Anyway, I've had really bad luck with off the shelf adapters. You are probably OK with just running it as USB. Regards, Mark ___ 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"
Dell 850 Panic on boot
Hi guys, Not sure if this is the right place to report this but we have a couple Dell 850s at work and the extra one we're trying to put FreeBSD on panics on boot. The servers are running 3.0ghz Pentium D processors (dual core) and they've got the EMT64 extension. So far it panics with the install cd for these versions: 8.1 i386 and amd64 8.2 i386 and amd64 7.4 amd64 I haven't tried any others. We needed to get this up to test something BSD specific so right now it's running OpenBSD. Here is a picture of the console from when it panics: http://feld.me/stuff/freebsd/dell_850_panic.png Some people in the ##freebsd channel on Freenode said it looked like it panics whenever it initializes the second CPU. There's no option in the BIOS (which is up to date) that offers you the ability to disable a core or hyperthreading or whatever this CPU does. Any insight would be greatly appreciated. Thanks, Mark ___ 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: Dell 850 Panic on boot
On Sat, 12 Mar 2011 12:30:14 -0600, Andriy Gapon wrote: do you get exactly the same panic message with 8.2 or a slightly more informative one? If the latter, then could please provide a screenshot of that? Yeah, the 8.x seemed to have more details. That happens to be a screenshot from the 7.4 disc. I don't have access to the machine until Monday but I'll post an update then. Regards, Mark ___ 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: Dell 850 Panic on boot
Well I'm not sure what to say. I just remembered I promised an update and so I went to try to boot the server off an 8.2 disc and see it panic again and nothing. No panic. I have no explanation for this except maybe a failing power supply that was being naughty on Friday but is OK today. I will have to reinstall this server soon so we'll see what happens. If I can reproduce it again I'll revive this thread. Thanks, Mark ___ 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: zfs, nfs and zil
Hello, I'd be curious to know how much memory you have. Also, you mention both iSCSI and NFS in the post and also say that you are using ESX with NFS. Can you reconfirm that you're definitely using NFS and not iSCSI? This is a type of setup I've been investigating myself and I hope you succeed. Regards, Mark ___ 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"
ZFS pool on FreeBSD 8.2-STABLE broken?
Hi there,
I have a small backup server (8.2-STABLE). It boots from ufs and has a zfs
pool for backups that consists of 8 drives configured as 4 mirrored devices,
totally around 2.5 TB.
Been working great, no issues, until the past few days when remote rsyncs to it
have started to get very slow (it's only at around %50 capacity). Rebooting it
helps for a while, then it gets slow again. But this isn't the problem now...
After the last reboot, it froze while booting right at the point where the file
system gets mounted. No errors, it just doesn't proceed past the ZFS version
message.
I rebooted single user and tried to access it with "zpool status", and the
command hangs in the same way. Any attempt to access it ("zfs list", for
example) does the same thing.
The disks themselves seem fine. They are all connected to a pair of Adaptec
RAID controllers (configured as individual drives, with mirroring handled by
zfs) and the controller software shows them all to be intact.
I disabled zfs in rc.conf and was able to boot, but I can't access the pool.
Any ideas on how to diagnose and hopefully repair this?
Mark
___
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: ZFS pool on FreeBSD 8.2-STABLE broken?
On Mon, 28 Mar 2011 13:38:54 -0500 Scot Hetzel wrote: On Mon, Mar 28, 2011 at
1:17 PM, Mark Morley wrote:
> Hi there,
>
> I have a small backup server (8.2-STABLE). �It boots from ufs and has azfs
> pool for backups that consists of 8 drives configured as 4 mirrored devices,
> totally around 2.5 TB.
>
> Been working great, no issues, until the past few days when remote rsyncsto
> it have started to get very slow (it's only at around %50 capacity).
> �Rebooting it helps for a while, then it gets slow again. �But this isn't the
> problem now...
>
> After the last reboot, it froze while booting right at the point where the
> file system gets mounted. �No errors, it just doesn't proceed past the ZFS
> version message.
>
> I rebooted single user and tried to access it with "zpool status", and the
> command hangs in the same way. �Any attempt to access it ("zfs list", for
> example) does the same thing.
>
> The disks themselves seem fine. �They are all connected to a pair of Adaptec
> RAID controllers (configured as individual drives, with mirroring handled by
> zfs) and the controller software shows them all to be intact.
>
> I disabled zfs in rc.conf and was able to boot, but I can't access the pool.
>
> Any ideas on how to diagnose and hopefully repair this?
>
Your going to need to download a recent -CURRENT ISO that contans zfs
v28, then you can try to recover the pool as outlined in this post
http://opensolaris.org/jive/message.jspa?messageID=445269
Well, what I did was rebuild world and kernel top 9.0-CURRENT and reboot. It
was able to see and access the zfs file system immediately without having to
import it. I did a zpool upgrade to v28 and all seems well so far.
Mark
___
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"
X-pstn-neptune: 0/0/0.00/0
X-pstn-levels: (S: 7.06799/99.9 CV:99.9000 FC:95.5390 LC:95.5390
R:95.9108 P:95.9108 M:97.0282 C:98.6951 )
X-pstn-settings: 4 (1.5000:1.5000) s cv gt3 gt2 gt1 r p m c
X-pstn-addresses: from [294/10]
Re: df -t is broken?
Here's what happens when I try to truss a df -t http://paste.feld.me/3jb4c@raw Regards, Mark ___ 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"
df -t is broken?
Ok, not sure if this really belongs on the STABLE mailing list but we'll see if you can help: - I was originally running FreeBSD 8.2-RELEASE - I patched my 8.2 source with the patches here: http://blog.vx.sk/archives/24-Backported-patches-for-FreeBSD-82-RELEASE.html - I built my system with "make buildworld && make buildkernel" and then installed both; rebooted. I know this isn't the norm, but I'm still running 8.2-RELEASE except these specific bugfixes so there really is no need for mergemaster - Now df -t doesn't work I noticed weird processes hanging and a few other things not running normally (monitoring). Turns out that anything that uses df -t just hangs (xymon, periodic, crons, find seems to hang when excluding filesystems)... doesn't matter what parameters you give it, it just hangs. Any thoughts on this? Regular df -h, etc work fine Thanks, Mark ___ 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: Hard drive detection
On 12 May 2011, at 20:34, Dillin Smith wrote: > Hi all, > > I'm having an issue getting my installation of FreeBSD to detect all > the drives in the system. It has 48 total, 46 2TB, and 2 250GB. The > system consists of six controllers, with eight drives on each. The two > 250GB hard drives are the first drives on controllers 0 and 1. > > There are two of these machines with the exact same configurations, > having the same problem. A very odd thing is that every time the > systems are rebooted, the drives that go undetected vary. Also, when > the systems were full of 250GB drives, all were detected. All drives > are detected in the BIOS of the controllers, just not by FreeBSD. > Any and all help is greatly appreciated. > (output of dmesg attached) Power problems (i.e. under-rated PSU)? Staggered spin-up means they're not all coming up quickly enough? With a rig as complex as that, I'd boot up another OS, like Linux or Windows and see if they can see all the drives. - Mark ___ 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: Hard drive detection
On 12 May 2011, at 22:03, Chuck Swiger wrote: > On May 12, 2011, at 1:25 PM, Mark Blackman wrote: >> Power problems (i.e. under-rated PSU)? Staggered spin-up means they're not >> all coming up quickly enough? > > While your suggestion would generally be a decent guess, the dmesg implies > the box is a Sun X4540; it probably has two or three 1500W PSUs: > > http://www.sun.com/servers/x64/x4540/specs.xml Ok, good point, missed that. acpi0: on motherboard > >> With a rig as complex as that, I'd boot up another OS, like Linux or Windows >> and see if they can see all the drives. > > How about Solaris? :-) Good idea, I've sort of given up on Solaris thanks to Oracle, but that's a better bet for a test if it's a Sun box. - Mark ___ 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: UFS SU+J
On Thu, Jun 16, 2011 at 9:01 AM, Bjoern A. Zeeb wrote: > On Jun 16, 2011, at 12:54 PM, nickolas...@gmail.com wrote: > >> I' like to know, if there plans to MFC journaled softupdates to 8-stable? >> If yes, when it would be done? > > it cannot be done and will therefor not happen. There used to be a branch > in user/jeff/ or somewhere in the /user or /project area in svn with an > older version of a backport but I am not sure if it was ever updated again. > > /bz > > -- > Bjoern A. Zeeb You have to have visions! > Stop bit received. Insert coin for new address family. > > ___ > 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" > The svn sources are here http://svn.freebsd.org/base/projects/suj/8/ . Why would suj not make it into 8-STABLE ? -- mark saad | nones...@longcount.org ___ 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"
disable 64-bit dma for one PCI slot only?
Dear folks, I have two LSI raid cards, one of which (SCSI 320-I) supports 64-bit DMA when 4GB+ of DDR is present and another which does not (SATA 150-D) . Consquently I've disabled 64-bit addressing for amr devices. I would like to disable 64-bit addressing for the SATA card, but permit it for the SCSI card. Is this possible? # grep amr /boot/loader.conf hw.amr.force_sg32=1 --- # grep "amr.: mem 0xff4f-0xff4f irq 27 at device 3.0 on pci2 amr0: Firmware 713S, BIOS G121, 64MB RAM amr1: mem 0xff5f-0xff5f irq 28 at device 3.0 on pci3 amr1: Firmware 1L45, BIOS G121, 128MB RAM # uname -a FreeBSD dasftp.das.local 8.2-RELEASE-p1 FreeBSD 8.2-RELEASE-p1 #0: Mon Apr 25 23:11:34 PDT 2011 r...@dasftp.das.local:/usr/obj/usr/src/sys/GENERIC amd64 # dmesg -a | grep "CPU:" CPU: AMD Opteron(tm) Processor 242 (1593.43-MHz K8-class CPU) # sysctl hw | grep mem root@dasftp Fri Jul 15 2011 hw.physmem: 8508891136 hw.usermem: 6397407232 hw.realmem: 8589934592 -- hw.pci.host_mem_start: 2147483648 # megarc -getxferrate -a0 -chall ** Transfer Rate of Adapter-0 Channel-8 is 160M ** # megarc -getxferrate -a1 -chall ** Transfer Rate of Adapter-1 Channel-8 is 320M ** # pciconf -lv | grep -A 4 "amr[01]" amr0@pci0:2:3:0:class=0x010400 card=0x05231000 chip=0x19601000 rev=0x01 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'MegaRAID' class = mass storage subclass = RAID -- amr1@pci0:3:3:0:class=0x010400 card=0x05201000 chip=0x19601000 rev=0x01 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'MegaRAID' class = mass storage subclass = RAID Many thanks in advance. Mark -- -- Mark McConnell mar...@dataabstractsolutions.com Data Abstract Solutions - Support 12209 N.E. Fourth Plain Suite DD, Vancouver WA 98682 ph: 360-573-5131 - fax: 360 573-0907 ___ 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: disable 64-bit dma for one PCI slot only?
On 18 Jul 2011 at 15:06, Scott Long wrote:
{Re: disable 64-bit dma for one PCI ...}:
> >> I would like to disable 64-bit addressing for the SATA card, but
> >> permit it for the SCSI card. Is this possible?
> >
> > You'd have to hack the driver perhaps to only disable 64-bit DMA for
> > certain
> > PCI IDs. It probably already does this?
> >
>
> The driver already had a table for determining 64bit DMA
> based on the PCI ID. I guess there's a mistake in the
> table for this particular card. I think that changing
> the following line to remove the AMR_ID_DO_SG64 flag
> will fix the problem:
>
> {0x1000, 0x1960, AMR_ID_QUARTZ | AMR_ID_DO_SG64 | AMR_ID_PROBE_SIG},
>
> Actually, what's probably going on is that the driver is
> only looking at the vendor and device id's, and is
> ignoring the subvendor and subdevice id's that would
> give it a better clue on the exact hardware in use.
> Fixing the driver to look at all 64bits of id info (and
> take into account wildcards where needed) would be a
> good project, if anyone is interested.
>
> Btw, I *HATE* the "chip" and "card" identifiers used in
> pciconf. Can we change it to emit the standard
> (sub)vendor/(sub)device terminology?
>
> Scott
Thank you for the discussion, John and Scott. I see
where this change would be made, Scott, and I want to try
it when I have an opportunity.
Mark
--
___
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: disable 64-bit dma for one PCI slot only?
On 18 Jul 2011 at 17:00, Mark McConnell wrote:
{Re: disable 64-bit dma for one PCI ...}:
> On 18 Jul 2011 at 15:06, Scott Long wrote:
> {Re: disable 64-bit dma for one PCI ...}:
>
> > >> I would like to disable 64-bit addressing for the SATA card, but
> > >> permit it for the SCSI card. Is this possible?
> > >
> > > You'd have to hack the driver perhaps to only disable 64-bit DMA for
> > > certain
> > > PCI IDs. It probably already does this?
> > >
> >
> > The driver already had a table for determining 64bit DMA
> > based on the PCI ID. I guess there's a mistake in the
> > table for this particular card. I think that changing
> > the following line to remove the AMR_ID_DO_SG64 flag
> > will fix the problem:
> >
> > {0x1000, 0x1960, AMR_ID_QUARTZ | AMR_ID_DO_SG64 | AMR_ID_PROBE_SIG},
> >
> > Actually, what's probably going on is that the driver is
> > only looking at the vendor and device id's, and is
> > ignoring the subvendor and subdevice id's that would
> > give it a better clue on the exact hardware in use.
> > Fixing the driver to look at all 64bits of id info (and
> > take into account wildcards where needed) would be a
> > good project, if anyone is interested.
> >
> > Btw, I *HATE* the "chip" and "card" identifiers used in
> > pciconf. Can we change it to emit the standard
> > (sub)vendor/(sub)device terminology?
> >
> > Scott
>
> Thank you for the discussion, John and Scott. I see
> where this change would be made, Scott, and I want to try
> it when I have an opportunity.
>
> Mark
I made this change to the amr driver, and it works
as advertised. Both cards are prevented from
using 64-bit DMA however, because the id's are
the same as far as they are examined.
Mark
--
___
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: UDP Packet reassembly
In message <4e345767.5070...@earthlink.net>, Stephen Clark writes: > Hello List, > > Didn't see this show up in the mailing list so I am resending. > > > > Could someone enlighten me as to when FreeBSD 6.3 does UDP packet reassembly? > > I am having a problem where I am getting a fragmented udp packet (2 pieces) > everthing is > fine if I get the first frag first. but if the second frag comes first then b > oth > fragments get dropped. > > I am using ipfilter and a bimap to redirect these packets to a host inside of > > the FreeBSD box, > so I suspicion it is ipfilter causing the drops. > > I know, I know 6.3 is ancient history, but any insight would be appreciated. Know issue, http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/82806 > Thank, > Steve -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: xterm - truetype fonts and missing underscore
Tony What else is in you .Xresources file . Also have you tried using xft formated font names . Ie xft:luxi mono:size=10 ? -- Mark Saad Mark.saad@longcount.orgOn Aug 24, 2011 7:08 AM, Tony Maher <tonyma...@optusnet.com.au> wrote: Hello, recently (not sure exactly when) my xterms no longer showed the underscore character. In my .Xresources I had (and have had this setting for years): XTerm*faceName: Monospace XTerm*faceSize: 10 I noticed when experimenting and modifying values that for one choice the bottom part of letters like 'g' was missing. So changed faceSize to 11 and all is good. In gnome-terminal with Monospace/10 font underscores showed up fine (and was ok in gnome font selector). So it appears to be xterm specific. Has anyone else experienced this? cheers -- Tony Maheremail: tonyma...@optusnet.com.au ___ 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" ___ 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: ZFS V28 on 8.2-RELEASE write behavior
On Thu, 01 Sep 2011 10:50:26 -0500, Dave Cundiff wrote: Any help tracking this down would be greatly appreciated. There have been numerous changes to v28 in -STABLE since June. Can you reproduce the behavior with a recent build of -STABLE instead of -RELEASE? Perhaps even on -CURRENT? Regards, Mark ___ 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: non-responding processes after truss(1)ing
On Tue, Sep 27, 2011 at 6:19 AM, Nikos Vassiliadis wrote: > On 9/27/2011 1:10 PM, Jeremy Chadwick wrote: >> >> kill -9 your truss processes; the underlying processes which you are >> truss'ing will probably resume. >> >> My experience for years has been that truss on FreeBSD is extremely >> buggy and cannot be relied upon (case in point). Such is still the case >> on RELENG_8 as of today. >> >> Use ktrace(1) instead. You'll find it to work pretty much in every >> situation. >> What about using dtruss in place of truss is the dtrace implementation of truss any better then the old libkvm ? > > Thanks, that worked. I'll use ktrace from now on. > > Nikos > ___ > 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" > -- mark saad | nones...@longcount.org ___ 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: How to update like Debian
On Thu, Sep 29, 2011 at 12:35 PM, Freddie Cash wrote: > On Thu, Sep 29, 2011 at 9:02 AM, Denny Schierz wrote: > >> I think, I do not understand, how to update (security/bugfixes) my 8.2 >> machines :-) I searched a lot and tried, what I have found in the docs, but >> I had trouble ... >> >> What I have done (one thing was working, but didn't know, if it is >> correct): >> >> > Updating FreeBSD is done is two separate processes, which can be done > independently of one another. > > There is a clear separation between "the base FreeBSD OS" and "third-party > apps installed on top". This is something that is missing in the land of > the penguin, and tends to trip people up as they switch between FreeBSD and > Linux (in either direction). > > To do a binary upgrade of the base OS, you use freebsd-update: > # freebsd-update fetch > # freebsd-update update > > See the freebsd-update man page for more details and options. > > That updates only the base OS (stuff under / and /usr; it does not touch > anything under /usr/local). > > > There are several different ways to update your installed third-party > software (stuff installed via either pkg_add or the ports tree), depending > on whether or not you want to compile software. Since you want have a > Debian-like experience, then you want to install via binary packages as much > as possible. > > See the man page for pkg_add for information on doing the initial install of > software, including remotely fetching software (this would be similar to > "apt-get install" without any upgrade support). > Two other options to keep ports up to date are portupgrade in ports-mgmt/portupgrade and portmaster in ports-mgmt/portmaster . To see some real world example of using it check the man page for each and take a look at /usr/ports/UPDATING you will see some example of how to upgrade major port changes Check out the entry from 20110517 about upgrading to perl 5.14 and removing the older version and fixing all the depends. In the debian world there is no exact comparison for this , major changes like this could/would be done by the maintainers and pushed out as debs with some warnings. portmaster and portupgrade both do the same relative tasks, the best advice would be to try both and see which you like. Also stick to using one port management tool . If you want to manually upgrade try to do that, if you want a wrapper like portupgrade use portinstall / portupgrade . Mixing and matching ports management tools for me imho a bad idea for beginners. > A nice tool for handling upgrades of binary packages, using only binary > packages, is pkg_upgrade. This is part of the bsdadminscripts package, so > you'll need to install that first. Using pkg_add and pkg_upgrade, you do > not even need to install the ports tree (and can even "rm -rf > /usr/ports/*"). > > That's about as close to a Debian-like experience as you'll get. > -- > Freddie Cash > fjwc...@gmail.com > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > -- mark saad | nones...@longcount.org ___ 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: www/Apache22 fails to build when configured for LDAP and AUTHNZ_LDAP
On Wed, Nov 30, 2011 at 11:44 AM, Shaun Meyer wrote: > Hello, > > I have already built apache22 successfully on FreeBSD 8.2-RELEASE-p3 > amd64. I realized that I wanted authnz_ldap which wasn't turned on by > default so I went into www/apache22 and did the following: > > # make clean > # make config > # make showconfig | grep LDAP > LDAP=on "Enable mod_ldap" > AUTHNZ_LDAP=on "Enable mod_authnz_ldap" > # make > > LDAP and AUTHNZ_LDAP are the only adjusted knobs from the defaults. > > The operative build error is "mod_authnz_ldap.c:41:2: error: #error > mod_authnz_ldap requires APR-util to have LDAP support built in. To > fix add --with-ldap to ./configure." > > I have also tried removing and cleaning for the apr package. I see no > other apache-related files installed and all this has been done > against the latest, greatest ports collection using `portsnap`. > > This symptoms are identical to > http://www.freebsd.org/cgi/query-pr.cgi?pr=124651 except, obviously, > they have fixed that cause. > > Any advice is greatly appreciated, > > Shaun Meyer You need to just rebuild the apr port with ldap. Confirm what version of apr you have installed and then use make config in that port to add ldap support. Remove the installed port and reinstall the new one with ldap support . They you should be able to install apache with ldap hooks. -- mark saad | nones...@longcount.org ___ 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: SCHED_ULE should not be the default
I'm not on the Release Engineering Team, and in fact don't have a src commit bit ... but this close to a major release, no, it's too late to change the default. mcl ___ 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"
status of ports and clang
I have recently been able to get the new build cluster on pointyhat-west set up to run full builds of ports with clang on amd64-9. I have documented the latest results on the wiki: http://wiki.freebsd.org/PortsAndClang If you are interested in working on ports being built via clang, this is your place to start. Please also note that now that we have up-to-date builds going, it is not as useful to us to report individual clang build failures. Patches to fix problems are, of course, highly welcome. mcl ___ 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"
accepting rtadv broken on 9-STABLE, re driver?
Hi guys, I upgraded my desktop at work just around christmas to 9-PRERELEASE builds and ipv6 has been broken since then. I've been too busy at work to fix it but today I finally had the chance to figure it out. Currently I'm running: 12:11:15 tech304:~ > uname -a FreeBSD tech304.office.supranet.net 9.0-STABLE FreeBSD 9.0-STABLE #2 r229703M: Fri Jan 6 11:01:58 CST 2012 r...@tech304.office.supranet.net:/usr/obj/tank/svn/sys/GENERIC amd64 and my ipv6 is not working. In rc.conf I have ipv6_enable_all_interfaces="YES" which sets the link local and I had net.inet6.ip6.accept_rtadv=1 in sysctl.conf. I can confirm that it was indeed activated in sysctl, but ifconfig didn't think so: re0: flags=8843 metric 0 mtu 1500 options=209b ether d0:67:e5:17:e1:32 inet6 fe80::d267:e5ff:fe17:e132%re0 prefixlen 64 scopeid 0x2 inet 192.168.93.23 netmask 0xff00 broadcast 192.168.93.255 nd6 options=23## Where's the ACCEPT_RTADV??? media: Ethernet autoselect (100baseTX ) status: active I have to manually do # ifconfig re0 inet6 accept_rtadv to get it to work. Am I missing something? Grepping /etc/rc.d/ for rtadv finds no clues. Is this broken for everyone, for the re driver, or am I just crazy? Here's pciconf for the device -- let me know if any further info would be useful: re0@pci0:4:0:0: class=0x02 card=0x04f51028 chip=0x816810ec rev=0x06 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' class = network subclass = ethernet Thanks, Mark ___ 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: accepting rtadv broken on 9-STABLE, re driver?
On Fri, 06 Jan 2012 12:49:45 -0600, Sergey Kandaurov wrote: You mean ipv6_activate_all_interfaces="YES" ? Yes... Unfortunately that's what I get for typing it manually and being distracted at the time. :-) What is in your rc.conf? Do you have "inet6 accept_rtadv" keyword in it? IIRC it should be enough to specify ifconfig_re0_ipv6="inet6 accept_rtadv" without additional tweaks. Consult with rc.conf(5). I figured I would end up putting that in rc.conf as a temporary fix, but maybe that's just the long term solution. It seems so odd to me that the sysctl change doesn't automatically cause the ACCEPT_RTADV option to show up for re0, but it does for vboxnet0. Perhaps there should be a cleaner way to do this in rc.conf like how we do ifconfig_re0="DHCP" ? Thanks, Mark ___ 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: accepting rtadv broken on 9-STABLE, re driver?
Hiroki Sato wrote: > > Is it correct that ACCEPT_RTADV option was enabled on the vboxnet0 > and not on re0, even after setting net.inet6.ip6.accept_rtadv to 1 at > boot time and ipv6_activate_all_interfaces="YES"? > >-- Hiroki Yes, that is the behavior I witnessed. ___ 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: accepting rtadv broken on 9-STABLE, re driver?
On Sat, 07 Jan 2012 14:23:46 -0600, Hiroki Sato wrote: It is an unexpected behavior and the flag should be set on all interfaces. Can you send me your /etc/rc.conf, /etc/sysctl.conf, and the result of "ifconfig -a"? Back at work so I have access to the machine again: rc.conf: hostname="tech304.office.xxx.net" ifconfig_re0="inet 192.168.93.23/24" defaultrouter="192.168.93.1" ipv6_activate_all_interfaces="YES" ipv6_ifconfig_re0="inet6 accept_rtadv" sshd_enable="YES" linux_enable="YES" ntpd_enable="YES" ntpdate_enable="YES" vboxnet_enable="YES" tcp_drop_synfin="YES" icmp_log_redirect="YES" update_motd="NO" dbus_enable="YES" hald_enable="YES" moused_enable="NO" moused_nondefault_enable="NO" oss_enable="NO" #nginx nginx_enable="YES" fcgiwrap_enable="YES" fcgiwrap_user="www" samba_enable="YES" #samba_config="/usr/local/etc/samba34/smb.conf" lpd_enable="YES" #slim_enable="YES" exim_enable="YES" sendmail_enable="NONE" nfs_client_enable="YES" smartd_enable="YES" zfs_enable="YES" sysctl.conf: # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. #security.bsd.see_other_uids=0 net.inet.tcp.drop_synfin=1 net.inet.icmp.log_redirect=1 vfs.usermount=1 net.inet6.ip6.accept_rtadv=1 # ifconfig -a 11:43:29 tech304:~ > ifconfig -a re0: flags=8943 metric 0 mtu 1500 options=209b ether d0:67:e5:17:e1:32 inet6 fe80::d267:e5ff:fe17:e132%re0 prefixlen 64 scopeid 0x2 inet 192.168.93.23 netmask 0xff00 broadcast 192.168.93.255 inet6 2607:f4e0:100:104:d267:e5ff:fe17:e132 prefixlen 64 autoconf nd6 options=23 media: Ethernet autoselect (100baseTX ) status: active lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff00 nd6 options=21 vboxnet0: flags=8802 metric 0 mtu 1500 ether 0a:00:27:00:00:00 nd6 options=23 Regards, Mark ___ 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: accepting rtadv broken on 9-STABLE, re driver?
On Mon, 09 Jan 2012 13:02:24 -0600, Hiroki Sato wrote: re0 seems to have ACCEPT_RTADV. What is the problem? That's because I haven't rebooted Let's start fresh. The normal ipv6 configuration anyone would use: -ipv6_activate_all_interfaces="YES" in rc.conf -NO mention of net.inet6.ip6.accept_rtadv in sysctl.conf I boot up, re0 *does not* have ACCEPT_RTADV. I try forcing via the sysctl: net.inet6.ip6.accept_rtadv=1 Still doesn't work! I finally have to result to: ifconfig re0 inet6 accept_rtadv Why? What makes this machine different? All the other machines I run do not require this to get ACCEPT_RTADV. Is it the re driver? My other machines have em and ath interfaces. Thanks, Mark ___ 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: accepting rtadv broken on 9-STABLE, re driver?
On Mon, 09 Jan 2012 19:56:47 -0600, Hiroki Sato wrote: This is an expected behavior. ACCEPT_RTADV is disabled by default on 9.X. Thanks for clarifying. I'll make sure I update our documentation at work regarding how exactly to get ACCEPT_RTADV working so this is clarified. Regards, Mark ___ 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: Installworld broken with an NFS /tmp
On Jan 19, 2012, at 5:25 AM, Sergey Kandaurov wrote: > On 19 January 2012 13:11, Matt Burke wrote: >> I've found the following thread from 2009 which matches what I've just come >> across while trying to install 9-RELEASE to disk on a machine with an NFS >> root. >> >> http://unix.derkeiler.com/Mailing-Lists/FreeBSD/current/2009-07/msg00084.html >> >> I've just worked around this by nullfs mounting the local disk's /tmp over >> the existing (nfs) /tmp, but is there a better way of doing this - an >> environment variable to specify an alternate to /tmp perhaps? >> > > To "solve" the sillyrename problem visible during installworld, > I just add the following to rc.conf (nfs) once and for all: > > tmpmfs="YES" > varmfs="YES" # why? probably needs for /var/tmp > I had to do the same thing, and to be honest I don't like the Nfs root setup. I like having all of the tools , but a smaller setup would work better for me . I want to see how hard it will be to do a 9 install via mfsbsd or a mfsroot akin to what was in 7 and 8 . Has anyone tried that ? > -- > wbr, > pluknet > ___ > 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" Mark Saad | mark.saad@longcount.org___ 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: Odd reboot problems with 9.0-RELEASE i386
On Fri, Jan 20, 2012 at 07:23:35PM +0200, Andriy Gapon wrote: > I think that it probably could be easier for you and for those reviewing your > kernel config if you 'include'-d GENERIC into your kernel config and then used > device/nodevice, options/nooptions, etc to make your customizations. I strongly recommend this path. It took a long period of time to factor out the crazy kernel configs that were used all over the package building nodes. The "stuff that changed" wound up only being ~15 lines, 10 of which were common to all nodes and archs. The rest were minor tweaks. But there was no way to tell that without a lot of detective work. mcl ___ 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: MFC misc/124164 (Add SHA-256/512 hash algorithm to crypt(3)) to stable/8?
Tim Bishop writes: > Are there any committers willing to merge PR misc/124164 to stable/8 > before the 8.3 release freeze? It's already in HEAD and stable/9 so it's > had some testing. > > misc/124164 adds support for SHA256/512 to crypt(3). This is something > we make use of on Linux and FreeBSD 9, and it'd be great to have the > same support on FreeBSD 8. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=124164 > > SVN Revs: 220496 220497 > > I've tried markm@ already and had no response. Apologies - I'll get to it ASAP. M -- Mark R V Murray Cert APS(Open) Dip Phys(Open) BSc Open(Open) BSc(Hons)(Open) Pi: 132511160 ___ 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: known problems with 8.x and HP DL16 G5 server?
On Fri, Feb 10, 2012 at 8:23 AM, Slawa Olhovchenkov wrote:
> On Thu, Feb 09, 2012 at 10:24:11PM -0800, Jeremy Chadwick wrote:
>
>> On Thu, Feb 09, 2012 at 04:02:12PM -0800, Julian Elischer wrote:
>> > On 2/9/12 1:56 PM, Jeremy Chadwick wrote:
>> > >On Thu, Feb 09, 2012 at 01:48:29PM -0800, Julian Elischer wrote:
>> > >>does anyone know of problems with freebsd and this system?
>> > >>
>> > >>the kernel We tried to boot seems to stop somewhere in the ahci probing.
>> > >Few things:
>> > >
>> > >1) Possible to get full console output (e.g. serial, etc.) from a verbose
>> > >boot?
>> >
>> > it's freebsd 8.2 from a TrueNAS/FreeNAS. I'm actually at ix-systems
>> > at the
>> > moment.. but I wasnhoping someone could save us some time by saying
>> > "Oh yeah, merge in change number xx"
>> >
>> > >2) Can you also provide the exact release/tag/kernel/thing you're trying
>> > >to install or upgrade to ("8.x" is a little vague; there are all sorts
>> > >of changes that happen between tags). For example 8.1 is not going to
>> > >behave the same necessarily as 8.2.
>> > >
>> > >3) When you say "ahci probing", are you booting a standard installation
>> > >CD/DVD/memstick of, say, 8.2? If so, those won't make use of the
>> > >AHCI-to-CAM translation layer (and that AHCI code is also different than
>> > >the native-ATA-AHCI code), so you might try, when booting the system,
>> > >dropping to the loader prompt and issuing "load ahci.ko" before typing
>> > >"boot". See if that helps. If it does, great, use it (ahci_load="yes"
>> > >in /boot/loader.conf) permanently (and benefit from things like NCQ
>> > >too).
>> > let me forward you an image...
>> > >4) If it's an Intel ESB2 controller, I believe there were some fixes or
>> > >identification shims put in place for this in recent RELENG_8, which
>> > >wouldn't be available in RELENG_8_2 or 8.2-RELEASE CD/DVDs. I could be
>> > >remembering the wrong controller though. Hmm...
>> > >
>> >
>> > that may be what we are looking for.
>> >
>> > I'll try get more info.
>>
>> For others: the last few lines in the kernel log are:
>>
>> acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0
>> acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route
>> 64-bit
>> Timecounter "HPET" frequency 14318180 Hz quality 900
>> acpi: wakeup code va 0xff848311d000 pa 0x4000
>> ahc_isa_probe 0: ioport 0xc00 alloc failed
>>
>> I don't see any indication of AHCI problems here (or AHCI at all).
>> ahc_isa_probe is for the ahc(4) controller -- Adaptec SCSI.
>>
>> A verbose boot might be more helpful.
>
> Can you tru hint.ahc.0.disabled="1" ?
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Is this a Dl165 G5 or a G5p . Also have you tried to change the sata
settings in the bios from AHCI to RAID or compat ? I am currently
using the G5 , G5p and G7 with 7.3 , 7.4 and 8.3 and , I have seen
this issue once or twice but I could not remember what the fix was. I
think playing with the bios options for AHCI and reseatting the cables
and backplane resolved this for me the last time.
--
mark saad | nones...@longcount.org
___
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: FreeBSD9 and the sheer number of problem reports
On Thu, 23 Feb 2012 12:25:01 -0600, Damien Fleuriot wrote: Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. Then stick with the 8.x train until it's no longer supported. Also, don't you know the rule about running .0 releases in production? :) 9.0 had LOTS of changes. They were very important. It's going to take a while for the community to fully absorb them and bugs to be worked out. We don't have enough testers of -CURRENT to prevent this. Everything seemed stable (ie, no release blockers) for the people running -CURRENT and -PRERELEASE, BETAs, and RCs, so it was released. But as always, TEST TEST TEST and please have a proper staging/test environment before you throw your production into 9.x. Only YOU can prevent forest fires^W^W unplanned outages. ___ 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: FreeBSD9 and the sheer number of problem reports
On Sun, Feb 26, 2012 at 06:32:17PM +0700, Erich Dollansky wrote: > > There's no such odd/even number policy with FreeBSD-- I think you're > > thinking of another OS ;) > > > maybe something got stuck in my head with the move from 4 to 5. Yes, 5 was the Great Leap where true SMP was introduced. In the many-year-long development cycle, so many other things (IIRC geom and suspend/resume, among others) that the change from 4 to 5 was completely disruptive. We resolved to release more often so as to never be in that situation again. (Granted, probably no architectural change will ever be that sweeping again.) There is no meaning to odd/even release numbering in FreeBSD. > How easy was the move to 6 then? An order of magnitude easier than the move to 5. Although as needs to happen with each major release, some code that had been deprecated was dropped, and some subsystems which no one stepped up to do the maintenance necessary for other re-architecting were dropped as well. Each of the subsequent moves has been much the same -- a few gotchas, but nothing like the move to 5. This has been purely intentional. mcl ___ 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: FreeBSD9 and the sheer number of problem reports
On Sun, Feb 26, 2012 at 09:27:58AM -0300, H wrote: > it is release engineering who could establish a little bit more time > between code-freeze and RELEASE As you will see from the (very) long discussion that you are about to read, there has to be a compromise. As it was, the release process was too long, not too short. Yes, we would like to get more testers pre-release, but that seems to be more easily said than done. Ideas appreciated. You will also see in the thread that: - it is not possible to release bug-free code, and in fact - it is not possible to release code with no regressions whatsoever if you are to ever release anything at all. To summarize: yes, we do care: and yes, these are classical software engineering problems that can only be dealt with, not solved completely. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ports usable or not [was: flowtable usable or not]
On Fri, Mar 02, 2012 at 03:35:24PM +0100, Nomen Nescio wrote:
> If you use [!i386] you are likely to find problems with ports and
> this gets amplified if you use nonstandard (read stuff not everybody uses)
> ports.
Fair enough.
> I have found several ports broken for many releases in a row.
These are bugs. Please report them via PRs.
> Other ports aren't supported on certain target architectures but the build
> doesn't tell you that until after it has run for a couple of hours
Those are also bugs. Please send PRs for those, as well. I am particularly
concerned about amd64 in this regard (although I am actually only myself
doing the package runs for sparc64 and powerpc). We continually try to
adjust the metadata for ports to indicate where they will and will not
run, based on the output of pointyhat runs. (OTOH pointyhat runs the
src tree from "the oldest supported minor release on each branch", so
this may be a clue .)
For those interested in investigating the metadata as seen by these
package build runs, they are available. For instance:
http://pointyhat.freebsd.org/errorlogs/amd64-9-latest/duds.verbose
Substitute {i386|sparc64|powerpc} for "amd64" and {7|8} for "9" to
look at the others.
Note that I haven't done any ia64 builds in quite a long time. Also
note that for sparc64 and powerpc, I no longer try to do 7. Finally,
we haven't done many runs on 10 yet.
You can see the overall state of the various package builds at:
http://pointyhat.freebsd.org/errorlogs/packagestats.html
whose "skipped" links will take you to the duds.verbose files.
mcl
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ports usable or not [was: flowtable usable or not]
Yeah, I've been trying to prioritize some -exps that are blocking other people right now. I know there's many more :-) mcl ___ 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: flowtable usable or not
On Sat, Mar 03, 2012 at 03:44:42AM -0300, H wrote: > nobody want to read, they want a desktop nothing else, something silly > and easy to read email and write docs and surf on the net, listen to a > CD, they need to put a cd into the drive, running install process, > reboot, using, nothing else and such a thing ... we do not have I really recommend this class of users investigate PC-BSD. It works "right out of the box" (all the type of work you are frustrated with has already been done, and is part of their release process). To my view, comparing FreeBSD to Ubuntu is apples-to-oranges. A much better point of comparison is PC-BSD to Ubuntu. I can't speak to whether or not PC-BSD will meet all your needs, but it is much more oriented to users than stock FreeBSD. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ports usable or not [was: flowtable usable or not]
On Sat, Mar 03, 2012 at 09:08:28PM +0100, Nomen Nescio wrote: > Thanks mcl. I am off on other things for now but I will file PRs next time > I come across something. In the past I have emailed the port maintainer and > the answer is usually "yeah I know". After a few of those I thought filing > PRs is a waste of time considering the maintainer doesn't seem to care. Once PRs are filed, we are able to track them and if the maintainer does not work on them after a period of time, it's fair game for other people to work on them as well. mcl ___ 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: Request for flowtable testers and actionable feedback RE: flowtable usable or not
On Mon, Mar 05, 2012 at 02:28:37AM -0300, H wrote: > because you don't care about what really matters, people, users, you > do not even know how to talk to them I've been criticized for saying this to a user before, but I'm going to repeat it here regardless of consequences. I'm sorry, you (as a user) do not have the right to flame someone in this manner and then expect them to listen to further input from you, no matter how reasonable your further contributions are. We are not paid employees, who might have to simply continue to work with you because their business requires it. I am not speaking for Kip here but I will state that I myself am happy to work with users up until I feel I am getting treated like this, at which point I feel no further obligation whatsoever to try to help them. Executive summary: you are being very rude here. mcl ___ 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: Heavy fs corruption with 9.0-RELEASE
On Mar 5, 2012, at 5:21 PM, Xin Li wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 03/05/12 14:12, Arnaud Lacombe wrote: >> Hi, >> >> I've been running a couple of system with 9.0-RELEASE since it is >> out. All the system were installed through the standard >> installation procedure. After unclean reboot, either crash or >> power-failure, I get a huge amount of really bad filesystem >> corruption (read: "silent", fs-wide, corruptions). This happens >> with either i386 or amd64 build. Systems involved use compact flash >> as their system permanent storage medium. > [...] >> I do not see this behavior when running 9.0-RELEASE on top of a >> 7.4-RELEASE userland (including FS). I've seen this behavior on >> various CF, so a single bad card is unlikely to be the culprit. > > FWIW FS is part of kernel. So technically you're running 9.0-RELEASE > UFS with 7.4-RELEASE userland. > >> Here are the currently mounted filesystem on the machine, as well >> as mount options: >> >> # mount /dev/ada0p2 on / (ufs, local, journaled soft-updates) devfs >> on /dev (devfs, local, multilabel) >> >> Any hints appreciated. > > My first step would be take out the journalling soft-updates to see if > things improves. Could you test if this happens using brand new > 9.0-RELEASE, but with journaled soft-updates disabled? > > (Hint: tunefs -j disable /; tunefs -n enable /; reboot in single user > mode). > > Note that since you say 7.4-RELEASE userland wouldn't have similar > issue, it might indicate a bug with the new journalled soft-updates's > fsck implementation. > How are you fsck'ng the 9.0 ufs ? Do you have a 9.0 fsck , tunefs , and mount ? Also was the file system created on 9.0 or 7.4 or better yet was it a 7.4 newfs or 9.0 newfs ? What options did you use ? > Cheers, > - -- > Xin LI https://www.delphij.net/ > FreeBSD - The Power to Serve!Live free or die > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.18 (FreeBSD) > > iQEcBAEBCAAGBQJPVTyCAAoJEG80Jeu8UPuzTsgIALvLdbzoNrmE/xUqDEJwGtC8 > zcfGl7tEVLU6BbE3i2ww2tUcMJmOMZwrAg1gZmFyyDhVQwEEQQ2zSTa1Uy3oiNRA > ts1X31VicEXIMam1Mt5K2G3lMbFES6TvyDrNOit6C2FeUrixHZ2C1JZmA7yzGlsg > 7ZGco+3clwSy2yfKTf0ExjIibkC0Cgz60BgjpQKowpKjUCD5AzB/2EqmZk1pFz6S > /NYOlF+YG/Y72V3GW1K5DTDFao5znzkulhc5Q/RUoD08o6hmdiaqiRHHmqjIP6Rt > Gb8Dfggnm8XUBs+AzgUmssCSCvHMHYt9SEel2sB5gSVKzd5rIAXwLxaeKBco1Ws= > =Hi9P > -----END PGP SIGNATURE- > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" --- Mark saad | mark.s...@longcount.org ___ 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"
FreeBSD 9-STABLE can not mount root from a glabled device
All I upgraded two of my 7-STABLE servers to 9-STABLE today and found two foot shooters. I believe they are bugs only when you upgrade from pre 8.0-RELEASE to 9.0-RELEASE or 9-STABLE 1. On 7.x I had been using glabel to label my root filesystem slice, swap slice , and var slice . Like this glabel label rootfs /dev/da0s1a glabel label var /dev/da0s1d glabel label SWAP /dev/da0s1b Then in fstab I would have entries like this. # DeviceMountpoint FStype Options DumpPass# /dev/label/rootfs / ufs rw 1 1 /dev/label/var /varufs rw 2 2 /dev/label/SWAP noneswapsw 0 0 This has worked for me in 6.x and 7.x however upon upgrading to 9-STABLE ( from yesterday ) or 9.0-RELEASE the boot loader could not find the labeled device. I had to manually set vfs.root.mountfrom=ufs:/dev/da0s1a" or key that in when the boot process bombed out. 2. After fixing the fstabs to use the real da names I wanted to see what the boot loader would do with ufs labels. I rebooted my box into single user mode and ran this tunefs -L rootfs /dev/da0s1a tunefs -L var /dev/da0s1d Then edited the fstab to use the labeled filesystems and rebooted, much to my surprise it failed in the same way. I compared this to a new 9.0-STABLE install i did which used gpt labels that did would # DeviceMountpoint FStype Options DumpPass# /dev/label/SWAP noneswapsw 0 0 /dev/gpt/rootfs / ufs rw 1 1 /dev/gpt/var/varufs rw 2 2 /dev/gpt/data /data ufs rw 2 2 So far as I can tell the only difference is that the fresh install uses the GPT partitioning scheme where as the upgraded boxes us the older mbr/fdisk setup. Any ideas on what I can try to get past this ? I liked using /dev/label as it made the devices sort of agnostic to what filesystem or partitioning scheme was on them. -- mark saad | nones...@longcount.org ___ 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"
ACPI Issues in 8-STABLE and on
All I was wondering if anyone has looking into this ACPI issue noted back in 2010. http://lists.freebsd.org/pipermail/freebsd-acpi/2010-February/006332.html I attempted to upgrade a 7-STABLE DL385g1 with 4G of ram to 9-STABLE and it was a disaster. The box was able to boot once and then on a normal reboot the root filesystem was corrupted beyond repair ( most likely unrelated , but some unknown issue with su+j *) and the system would not get past the point noted in the a fore mentioned thread . I tried to boot this box with 8.2-RELASE amd64 same issue, 9.0-BETA1 , same issue, 9.0-RELEASE same issue , and 9.0-STABLE as I pointed out worked intermittently. So the end result is that this box now only reliably runs 7.0-RELEASE - 7.4-RELEASE and 7-STABLE , 6.2-RELEASE - 6.4-RELEASE and 6-STABLE but nothing else. As a side test , NetBSD 6.0 beta amd64 boots with out issues on this box as well as DragonFlyBSD 3.01 amd64. So my solutions are to migrate back to 7-STABLE or use Net or Dfly. Does anyone know what the root issue is here ? * The su-j issue was most likely caused by me not properly converting the old su slice to su+j . I think I may have done a tunefs -j enable before I did a tunefs -n disable && fsck . -- mark saad | nones...@longcount.org ___ 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: Floppy disks don't work with FreeBSD 9.0
On Tue, 27 Mar 2012 16:48:26 -0500, Thomas Laus wrote: It looks like we both have confirmed that the floppy disk operation works up to FreeBSD 8.3 RC1. I will need to file a PR for FreeBSD 9.0 in the bug system. Thanks for the help. Could this be related to CAM system issues that shipped with FreeBSD 9.0 and were fixed in -STABLE? Like the CDROM issues? I'd probably test in -STABLE first. Unfortunately I don't have any floppy drives to test this with or I'd lend a hand. ___ 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"
Panic after converting Softupdates to journaled softupdates
Hell All I wanted to share this with you before sending a pr . I did not find anything that matched it and I wanted to see if I did something wrong procedurally . I upgraded a 7.4-RELEASE amd64 box to 9.0-STABLE sources from yesterday 10 Apr 2012. Every thing worked well. I was able to boot and run off 9.0-STABLE my apps worked ; So I wanted to swap out soft updates for journaed soft updates. The box used 3 UFS slices that were glabled. Note root and var had softupdates but /usr/local/mysql/data did not # DeviceMountpoint FStype Options DumpPass# /dev/label/rootfs / ufs rw 1 1 /dev/label/var /varufs rw 2 2 /dev/label/SWAP noneswapsw 0 0 /dev/label/data /usr/local/mysql/data ufs rw 2 2 Here is what I did to convert them. - # tunefs -n disable / tunefs: soft updates cleared tunefs: file system reloaded # tunefs -n disable /var tunefs: soft updates cleared # fsck -y / ** /dev/label/rootfs ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 271768 files, 4336411 used, 59997908 free (136692 frags, 7482652 blocks, 0.2% fragmentation) * FILE SYSTEM IS CLEAN * # fsck -y /var ** /dev/label/var ** Last Mounted on /var ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 24792 files, 141287 used, 3919776 free (1232 frags, 489818 blocks, 0.0% fragmentation) * FILE SYSTEM IS CLEAN * # fsck -y /usr/local/mysql/data ** /dev/label/data ** Last Mounted on /usr/local/mysql/data ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 89528 files, 18246873 used, 51166840 free (59080 frags, 6388470 blocks, 0.1% fragmentation) * FILE SYSTEM IS CLEAN * # tunefs -j enable / Using inode 7 in cg 0 for 33554432 byte journal tunefs: soft updates journaling set tunefs: file system reloaded # tunefs -j enable /var Using inode 4 in cg 0 for 33554432 byte journal tunefs: soft updates journaling set # tunefs -j enable /usr/local/mysql/data Using inode 425 in cg 0 for 33554432 byte journal tunefs: soft updates journaling set # reboot Apr 11 11:08:58 init: single user shell terminated. Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 0 0 0 0 0 0 done All buffers synced. panic: /: ffs_sync: modification on read-only filesystem cpuid = 0 KDB: stack backtrace: #0 0x808c283e at kdb_backtrace+0x5e #1 0x8088d017 at panic+0x187 #2 0x80abc51d at ffs_sync+0x50d #3 0x809303e1 at vfs_write_suspend+0x111 #4 0x80abcbd8 at ffs_unmount+0x3f8 #5 0x8091b2ce at dounmount+0x26e #6 0x80921ea2 at vfs_unmountall+0x42 #7 0x8088ce30 at kern_reboot+0x7a0 #8 0x8088d19c at sys_reboot+0x6c #9 0x80b77260 at amd64_syscall+0x500 #10 0x80b62257 at Xfast_syscall+0xf7 Uptime: 6m38s Automatic reboot in 15 seconds - press a key on the console to abort Now the box locked up hard and It would not reboot automatically. I am waiting to see if I can get a coredump after it comes back up. I have walk over an kick it over manually now. So does anyone have any insight into what happened here ? -- mark saad | nones...@longcount.org ___ 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: Panic after converting Softupdates to journaled softupdates
On Wed, Apr 11, 2012 at 11:20 AM, Mark Saad wrote: > Hell All > I wanted to share this with you before sending a pr . I did not find > anything that matched it and I wanted to see if I did something wrong > procedurally . > > I upgraded a 7.4-RELEASE amd64 box to 9.0-STABLE sources from > yesterday 10 Apr 2012. > > Every thing worked well. I was able to boot and run off 9.0-STABLE my > apps worked ; So I wanted to swap out soft updates for journaed soft > updates. > > The box used 3 UFS slices that were glabled. Note root and var had > softupdates but > /usr/local/mysql/data did not > > > # Device Mountpoint FStype Options Dump Pass# > /dev/label/rootfs / ufs rw 1 1 > /dev/label/var /var ufs rw 2 2 > /dev/label/SWAP none swap sw 0 0 > /dev/label/data /usr/local/mysql/data ufs rw > 2 2 > > > Here is what I did to convert them. > > - > > # tunefs -n disable / > tunefs: soft updates cleared > tunefs: file system reloaded > # tunefs -n disable /var > tunefs: soft updates cleared > # fsck -y / > ** /dev/label/rootfs > ** Last Mounted on / > ** Root file system > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 271768 files, 4336411 used, 59997908 free (136692 frags, 7482652 > blocks, 0.2% fragmentation) > > * FILE SYSTEM IS CLEAN * > # fsck -y /var > ** /dev/label/var > ** Last Mounted on /var > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 24792 files, 141287 used, 3919776 free (1232 frags, 489818 blocks, > 0.0% fragmentation) > > * FILE SYSTEM IS CLEAN * > > # fsck -y /usr/local/mysql/data > ** /dev/label/data > ** Last Mounted on /usr/local/mysql/data > ** Phase 1 - Check Blocks and Sizes > ** Phase 2 - Check Pathnames > ** Phase 3 - Check Connectivity > ** Phase 4 - Check Reference Counts > ** Phase 5 - Check Cyl groups > 89528 files, 18246873 used, 51166840 free (59080 frags, 6388470 > blocks, 0.1% fragmentation) > > * FILE SYSTEM IS CLEAN * > > # tunefs -j enable / > Using inode 7 in cg 0 for 33554432 byte journal > tunefs: soft updates journaling set > tunefs: file system reloaded > # tunefs -j enable /var > Using inode 4 in cg 0 for 33554432 byte journal > tunefs: soft updates journaling set > # tunefs -j enable /usr/local/mysql/data > Using inode 425 in cg 0 for 33554432 byte journal > tunefs: soft updates journaling set > # reboot > Apr 11 11:08:58 init: single user shell terminated. > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...0 0 0 0 0 0 0 0 0 0 done > All buffers synced. > panic: /: ffs_sync: modification on read-only filesystem > cpuid = 0 > KDB: stack backtrace: > #0 0x808c283e at kdb_backtrace+0x5e > #1 0x8088d017 at panic+0x187 > #2 0x80abc51d at ffs_sync+0x50d > #3 0x809303e1 at vfs_write_suspend+0x111 > #4 0x80abcbd8 at ffs_unmount+0x3f8 > #5 0x8091b2ce at dounmount+0x26e > #6 0x80921ea2 at vfs_unmountall+0x42 > #7 0x8088ce30 at kern_reboot+0x7a0 > #8 0x8088d19c at sys_reboot+0x6c > #9 0x80b77260 at amd64_syscall+0x500 > #10 0x80b62257 at Xfast_syscall+0xf7 > Uptime: 6m38s > Automatic reboot in 15 seconds - press a key on the console to abort > > > Now the box locked up hard and It would not reboot automatically. > > I am waiting to see if I can get a coredump after it comes back up. I > have walk over an kick it over manually now. > > So does anyone have any insight into what happened here ? > > -- > mark saad | nones...@longcount.org short follow up , savecore did not work no dump was saved to swap. Also there was no apparent impact from this crash other then the need to power cycle the box. So far su+j appears to be working. I will stress the disks a bit more and pull the power to see if it actually works later. -- mark saad | nones...@longcount.org ___ 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"
GEOM_PART: integrity check failed (mirror/gm0, MBR) on FreeBSD 8.3-RELEASE
I just did a source upgrade from 8.2 to 8.3. System boots but has this warning: GEOM_PART: integrity check failed (mirror/gm0, MBR) Google points to issues with FreeBSD 9 and the need to migrate to GPT but I wasn't expecting this with 8.3! Are there any quick fixes to eliminate this warning or is it safe to ignore please? sudo gpart list: Geom name: mirror/gm0 modified: false state: CORRUPT fwheads: 255 fwsectors: 63 last: 976773166 first: 63 entries: 4 scheme: MBR Providers: 1. Name: mirror/gm0s1 Mediasize: 500107829760 (465G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 32256 Mode: r2w2e3 attrib: active rawtype: 165 length: 500107829760 offset: 32256 type: freebsd index: 1 end: 976773167 start: 63 Consumers: 1. Name: mirror/gm0 Mediasize: 500107861504 (465G) Sectorsize: 512 Mode: r2w2e5 Geom name: mirror/gm0s1 modified: false state: OK fwheads: 255 fwsectors: 63 last: 976773104 first: 0 entries: 8 scheme: BSD Providers: 1. Name: mirror/gm0s1a Mediasize: 498597888000 (464G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 32256 Mode: r1w1e1 rawtype: 7 length: 498597888000 offset: 0 type: freebsd-ufs index: 1 end: 973823999 start: 0 2. Name: mirror/gm0s1b Mediasize: 1509941760 (1.4G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 381713920 Mode: r1w1e0 rawtype: 1 length: 1509941760 offset: 498597888000 type: freebsd-swap index: 2 end: 976773104 start: 973824000 Consumers: 1. Name: mirror/gm0s1 Mediasize: 500107829760 (465G) Sectorsize: 512 Stripesize: 0 Stripeoffset: 32256 Mode: r2w2e3 -- Mark A. R. Knight finger: ma...@knigma.org Tel: +44 7880 556751http://www.knigma.org/ ___ 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: FreeBSD 9.0 - BCE_JUMBO_HDRSPLIT kernel option for bce device still needed?
On Wed, 25 Apr 2012 14:41:40 -0500, Andrey Zonov wrote: Hi, There is no such option in the kernel anymore, instead there is hw.bce.hdr_split tunable which is turn on by default. I've tried the kernel option and playing with this tunable on a pair of HP DL380s and had to give up. I was building ZFS SAN heads and was going to have 2x bce and 2x igb ethernets each LACP and Jumbo Frames. The bce devices simply would not work with jumbo frames. The packets disappeared into the great ether or something. Our switches never saw any being sent, and receiving jumbo frames showed absolutely no traffic via tcpdump. After dropping in a quad Intel NIC (4x igb) everything worked as expected. The bce hardware or driver is sketchy and I'd avoid it. ___ 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: FreeBSD 9.0 - BCE_JUMBO_HDRSPLIT kernel option for bce device still needed?
Hi Andrey, Those servers are considered production now but I have access to a few more that I may be able to test your patch on. I do not have an ETA but I'm keeping this on my list of "things to do" and will gladly reply back after I produce results. Thanks!!! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9 "gptboot: invalid backup GPT header" error (boots fine though)
On Wed, May 2, 2012 at 5:03 AM, Adam Strohl wrote: > Thanks Andrey, > > I've just recompiled /boot/gptboot after updating gpt.c and installed it > via: > > gpart bootcode -p /boot/gptboot -i 1 da0 > > I still see "gptboot: invalid backup GPT header" on boot (but it does still > boot). > > > On 5/2/2012 12:58, Andrey V. Elsukov wrote: >> >> On 30.04.2012 23:14, Adam Strohl wrote: >>> >>> da0 at tws0 bus 0 scbus0 target 0 lun 0 >>> da0: Fixed Direct Access SCSI-5 device >>> da0: 6000.000MB/s transfers >>> da0: 2860992MB (5859311616 512 byte sectors: 255H 63S/T 364725C) >>> >>> >>> Let me know anyone wants to see anything else/has seen this/has any >>> theories! >> >> >> Can you try patch from the r234693, update and reinstall gptboot, does it >> help? >> http://svnweb.freebsd.org/base?view=revision&revision=234693 >> Did you try to repair the header ? I saw a similar issue on upgraded boxes that were 7-STABLE upgraded to 9-STABLE. and recovering made the warning go away . I may be way off here but just my 2 cents . % gpart recover da0 -- mark saad | nones...@longcount.org -- mark saad | nones...@longcount.org ___ 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: Reject Action For SPF
In message , "Prabhpal S. Mavi" writes: > > > Why would you want to reject mail from legitimite senders that do not > > have SPF records published? > > > > Glen > > Dear Glen. B > > Thanks for your response, We want to implement this no our backup MX > server. i trust this explains the reason. i know SPF is not spam > prevention mechanize. Can you tell me how to set reject action? Fix your backup server to have the data required to perform the filtering. Don't force the rest of the world to waste cycles and bandwidth attempting to send email to a backup MX that you have advertised. If you can't do it correctly, DO NOT DO IT. > Prabh S. Mavi > > ___ > 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" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: 9.0-RELEASE amd64: No Boot on VMWare Workstation
On Tue, May 15, 2012 at 08:12:05PM -0500, Larry Rosenman wrote: > Would it be possible for the next 9.x release to set hw.memtest.tests="0" > when we discover we're under a hypervisor to avoid doing the tests? (or > default it to 0 in the installer kernel?)? Actually, that's already been fixed, and will first appear in 9.1. I've written up what you can do to patch out the offending test in the meantime: http://wiki.freebsd.org/VMWareBootupSpeed mcl ___ 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: Why Are You Using FreeBSD?
On Wed, 30 May 2012 13:59:01 -0500, Chris Nehren wrote: 4. Everything "feels right" and "makes sense" on a very deep level for me, in a way that never happened with the other Unix and Unix "alike" OSs I've used. Bingo. For me: 1) Integration. The OS is integrated very well all around. How many utilities on Linux are required to replace the full functionality of the BSD "ifconfig" ? 2) Ports. We have customers with very different requirements; we don't have to run different Linux distros to meet their needs in a way that is supported by the package management system. This makes the job as a sysadmin and our infrastructure very consistent. 3) Features. PF is indispensable, and ZFS is a great bonus. System utilities, too: sockstat, systat, gstat, BSD's top, etc. ___ 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: Why Are You Using FreeBSD?
On Thu, 31 May 2012 09:30:31 -0500, Adam Strohl wrote: This brings up another point: Repair is always possible with FreeBSD. Quick tip for you guys -- create your own mtree file for /usr/local, /usr/home, and /var via cron nightly. With that data and the ones provided for the base system you can fix a machine that someone accidentally "chown -R /" within minutes. The fact that Linux has nothing equivalent is frightening. Mtree has saved me a lot of time when customers have broken their servers. ___ 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: Installworld and /usr/include/*.h modification times
In message , Kimmo Paasiala writes: > On Fri, Jun 1, 2012 at 8:45 PM, Lowell Gilbert > wrote: > > Kimmo Paasiala writes: > > > >> Why are /usr/include files installed with "install -C" during "make > >> installworld" =C2=A0when almost everything else is installed without the= > -C > >> flag? This makes it harder to track which files were actually > >> installed during the last "make installworld". One can easily find > >> obsolete files =C2=A0(that are not covered with make delete-old(-libs)) > >> with "find -x / -type f -mtime +suitable_time" but this doesn't work > >> for /usr/include files because the modification times are not bumped > >> on "make installworld". > > > > "make" uses timestamps to determine whether to trigger a rule. Changing > > timestamps on source files without changing the contents is a bad idea. > > Yes, I'm aware of how make uses timestamps for figuring out out of > date targets. However I would argue that after updating world with > "make installworld" (which is done in single user mode there for > requiring at least one reboot) you should start any compilations from > scratch. The ports system does this by default and cleans up any > previous work files before new compilation. I just don't see where > bumping of mtimes for those files would have that great impact, does > anyone? You obviously havn't had to deal with multi-day builds and also having to repair the OS. Preserving timestamps preserves re-startability. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Why Are You NOT Using FreeBSD ?
On Fri, Jun 01, 2012 at 05:20:39PM +0200, Nomen Nescio wrote: > Maybe FreeBSD should consider migrating to pkgsrc? I'm not arguing that your other points are invalid (in particular, I agree that the xorg change was really painful, and for a long time amd64 lagged i386 badly), but there is one very major blocker for this particular idea. If you browse the following URL: http://wiki.freebsd.org/PackageSystemsComparison You'll see that pkgsrc is around 12k packages. Although our graph is stale, per the portsmon/FreshPorts URLs, we're approaching 24k ports. So: while it's been suggested before, it's not really workable. mcl ___ 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: Why Are You NOT Using FreeBSD ?
On Sun, Jun 03, 2012 at 01:43:43AM +0200, Fritz Wuehler wrote: > So there could be lots of overlap and just looking at the two numbers > you posted doesn't really tell the whole story. No, I agree that it doesn't. I was just trying to add an aside, and point out that the task would not be trivial. Since I'm heavily invested in FreeBSD ports I think I need to step back and let other folks comment in this thread. mcl ___ 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: Why Are You NOT Using FreeBSD?
In message <2156532.vx6shro...@x220.ovitrap.com>, Erich writes: > Hi, > > On 03 June 2012 AM 9:15:14 Chris Rees wrote: > > On Jun 3, 2012 5:26 AM, "Erich" wrote: > > > > > > Hi, > > > > > > On 02 June 2012 PM 2:56:01 Chris Nehren wrote: > > > > On Sat, Jun 02, 2012 at 14:11:06 -0400 , Paul Mather wrote: > > > > > I'm not sure what the solution is for the end user. I know I get > > > > > somewhat leery of updating my ports if I see a large number of change > s > > > > > coming via portsnap (like the 4000+ that accompanied the recent libpn > g > > > > > upgrade) and there is nothing new in UPDATING (which, happily wasn't > > > > > the case with the libpng upgrade). Usually, I wait a while for the > > > > > dust to clear and an UPDATING entry potentially to appear. > > > > > > > > If you're concerned about things breaking, don't follow the bleeding > > > > edge. This seems to be common sense. > > > > > > is there a second version of the ports tree available? > > > > > > What is the response of the list if you want to install a new package > > with you old ports tree? > > > > > > > The response is "Don't ask for support if you do that", I'm afraid. > > > > No major OS I can think of allows you to mix and match like that (though I > > could be wrong). > > it is new to me that Microsoft asks for a Windows update when a new Office ve > rsion appears at the scene. No. It just silently does the OS update by installing new sets of libraries if required. When we install our software on a Windows machine we update the OS by installing the lastest C runtime libraries. We use Microsoft's installer but we do it. We also ship a private copy of the OpenSSL and libxml libraries we use. > Microsoft also does not ask to update all other applications before the lates > t Office can be installed. And you don't have to do that for FreeBSD if you don't want to. For each application you have you can put all the dependancies in its own tree. Apple does this for MacOS. The ports system defaults are to use a common build/runtime tree but at the cost of a little more disk space each major application could have its own build/runtime tree. This is a tradeoff. Most of the time having a shared set of libraries is a win, but just occasionally, it is a big pain. I've got a system where the X server is running a completely different set of libraries compared to the X applications. I just couldn't get the new server to work. I just took all the old server package and all its dependencies and installed it in a new location. This has a bit more that what is actually requires as I don't need all the header files but it works. For tools that are critical I would suggest building a seperate build / runtime tree. Disk space is relatively cheap. One thing that could help is splitting library packages into runtime / buildtime sub packages. That way you can reduce the foot print for a runtime install. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Why Are You NOT Using FreeBSD?
In message <7199276.kar7u8d...@x220.ovitrap.com>, Erich writes: > Hi, > > On 03 June 2012 PM 3:19:14 Doug Barton wrote: > > On 06/03/2012 05:43, Erich wrote: > > > it is new to me that Microsoft asks for a Windows update when a new > > > Office version appears at the scene. > > > > Actually it's very common for Windows applications to specify a minimum > > OS service pack level. To stretch the analogy a bit, you're also not > > going to find any modern Windows application that will run on Windows > > 98, for example. > > > can you still install the ports tree and its applications on a FreeBSD 4.4? The ports system was deliberately broken once support for FreeBSD 4.x was dropped. You need a more up-to-date make than that which ships with FreeBSD 4.x and some other tools to be upgraded all of which were in FreeBSD 5.x. If someone had added a compatible make to ports and a couple of other tools used by the ports sub-system itself, those that wanted to continue using FreeBSD 4.x with ports could of. Instead the whole ports framework was updated to use incompatible Makefiles and tools without providing the necessary tools. It's not like make from FreeBSD 5.x or even FreeBSD 8.x doesn't compile on FreeBSD 4.x. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Implications of pkgng, was Re: Why Are You NOT Using FreeBSD ?
On Sun, Jun 03, 2012 at 09:31:19PM +0200, Mel Flynn wrote: > Once the base system supports binary upgrades of packages through pkgng > it should solve a lot of issues that people have with production systems > now IMHO, s/solve/expose/ :-) It will then be up to use to solve them. mcl ___ 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: Why Are You NOT Using FreeBSD ?
On Sun, Jun 03, 2012 at 07:24:11PM -0700, Dave Hayes wrote: > I see features and pkgng and things being offered up as solutions... > these are all well and good, but in my opinion more comprehensive > documentation and support in these areas would do more good than pkgng. IMHO pkgng and optionsng are necessary, but not sufficient, to solve our current problems. mcl ___ 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: Why Are You NOT Using FreeBSD?
On Mon, Jun 04, 2012 at 07:49:02AM +0700, Erich wrote: > can you still install the ports tree and its applications on a FreeBSD 4.4? No. When 4.11 finally went EOL on 01/31/2007 we removed all the compatiblity code, because by that time supporting both was increasing the maintenance burden on our port maintainers (probably in the range of 25%-50%). This was due to how much that the src and ports infrastructure had changed between 4.X and 5.X: different patches had to be kept for each branch, for instance. (This has been much less the case since then; 5.X had some very disruptive changes.) FWIW, according to my research, 4.4 was released 09/19/2001 and probably went EOL sometime in 2003: http://people.freebsd.org/~linimon/schedule/milestones.html The current status is that we support 8.x and 9.x well. Ports support for 7.x is starting to fade over time as new upstream releases rely on newer APIs. 6.x went EOL 11/30/2010 and we no longer claim to support it in ports. > I only see many XP machines at the client side running the latest > Office applications. Not to disagree that this is possible, but my own experience (with Quicken) is that I was finally forced to move off 2K/XP to be able to continue running their software the way I expect to run it. Without doing any research to back up my claims, I think 2K is from the same timeframe as 4.4. Please don't take any of the above as criticism. It's clear that our model of "everyone must run the current ports tree" failed long ago. We have some things in progress (pkgng; conversion to SVN, which allows much cheaper tagging/branching) that are key pieces of being able to fix this; others are coming. In the meantime, your criticisms about this facet are absolutely on-target. However, for anyone who expects to be able to run current applications on a 10-year-old OS release, there is no realistic choice other than an OS from a commercial company where there is a revenue stream to support a paid support staff dedicated to that task and that task only. FreeBSD does not have that now and is extremely unlikely to have that in the future. For anyone who has that criterion, we're the wrong choice. mcl ___ 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: Why Are You NOT Using FreeBSD?
In message <4fcd23fe.20...@zedat.fu-berlin.de>, "O. Hartmann" writes: > Well, and repeatedly (no offense!) I will point out in this case, that I > was FORCED having the latest software by the ports system! > That it a difference in having running FreeBSD CURRENT on my own risk, > or FreeBSD-STABLE due to new hardware and new drivers only supported by > those and having a regular port update, which blows up the system > because of the newest software! You were not forced to use the latest. You can quite easily use years old ports trees if you want to. I just installed a port using a tree from October 2011. I could have upgraded the ports tree to the latest and greatest but I choose not to. > I take the burden of having not an easy life, but this, what is expected > from so many "users" of FreeBSD, is simply beyond ... There are also binary packages available. > > Either stick to releases, or put up with lots of compiling etc-- you > > should not complain because of self-inflicted problems. > > As I repeatedly have to point out in this case - the issue is not with > STABLE and CURRENT, it is also with RELEASE. And as it has been pointed > out herein so many times: FreeBSD ports lack in a version tagging. Version tagging is just a convient way to get a snapshot at a particular point in time unless you create branches that are them made stable by doing a release engineering process on the branch. This would require rules like "don't make a change unless it is to fix something that is broken". It would also require a lot of man power. If you are willing to pay salaries for people to do this then I'm sure there are people who would do the job. The ports system has to ability to set the ports tree to any point in time in its existance. You can then build all the indexes as they were at that point in time. > How would you suggest avoiding the problems we face with the ports by > being sticky on RELEASE, if the problem is spread over all branches? > > > Please remember that we do compile packages for release, or if more up > > to date packages are required you can use the stable package sets > > which are rarely over five days or so. > > If it is about the binary packages - then you're right. Stick with > RELEASE and binary packages - if available (the mentioned office > packages are often much delayed). > In such a case one is better with a binary spread version of an OS and > this would exactly hit the subject of the thread: Why NOT using ... > blablabla > > > > > Chris > > At the end, I'd like to see more care about the way ports get updated. > There is no way to avoid messes like described at this very moment. And > it is a kind of unedifying . And I'd like to be able to world hunger and to see FTL travel. One doesn't have to live at the bleeding edge with ports if one doesn't want to even when compiling. One can live a day, a week, a month behind the bleeding edge and allow other to hit problems and report them. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Why Are You NOT Using FreeBSD?
In message <3506767.fvm2kmt...@x220.ovitrap.com>, Erich writes: > Hi, > > On 05 June 2012 11:24:25 Mark Andrews wrote: > > > > > Version tagging is just a convient way to get a snapshot at a > > particular point in time unless you create branches that are them > > we do not ask for more. There should be only one difference to a snapshot. As > snapshot has a date. No matter in what state the ports tree was, it is in th > at state in the ports tree. If user - especially the one not so fit in this a > spect - want to use a snapshot, it will be difficult to impossible to figure > out which one they need. > > If version numbers would be introduced, it would be ok to use the version num > ber of the FreeBSD and have only version available which reflect the release > version of the ports tree. It's already there. If you want the ports as of FreeBSD 4.x EOL then the tag is "RELEASE_4_EOL". If you want ports as of FreeBSD 9.0 then the tag is "RELEASE_9_9_0". > People here want to make always a perfect system. People like me want to have > some small things in there available with a click. > > As the ports trees are there anyway, only the direct link to the snapshot of > that day or a version number in the ports tree would be needed to make this a > vailable for people who just want to use FreeBSD. > > Please note, I do not want any extra work spend here to make this perfect. I > only want a simple way to fall back to a big net which is not that old from w > hich the user can restart. > > You can add a huge note to the links stating the risks. This is all fine. > > There is another reason why I ask for this. I noticed a long time ago that th > e ports are in a better shape around the release date of a new version. So, I > try to get it always around the release dates. But, some times - you know ho > w life is - I miss this date. It does not kill me but it leads some times to > extra work steps I can do but I see the problems people will face who know Fr > eeBSD not that well. > > > One doesn't have to live at the bleeding edge with ports if one > > doesn't want to even when compiling. One can live a day, a week, > > a month behind the bleeding edge and allow other to hit problems > > and report them. > > How is this done with the knowledge of a beginner? One reads the documentation. > Erich -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Why Are You NOT Using FreeBSD?
> One doesn't have to live at the bleeding edge with ports if one > doesn't want to even when compiling. One can live a day, a week, > a month behind the bleeding edge and allow other to hit problems > and report them. To be pedantic, there's a lot of difference between reporting problems, and supplying fixes. Sometimes figuring out the fixes is beyond the capabilities of our maintainers, of course. People should feel free to ask for help on the mailing lists or forums in those cases. But our general problem won't be solved merely by tagging. There have to be people willing to test based only on whatever tree, or branch, or whatever, has been tagged. This is on reason why the tree at release time is _somewhat_ more stable: we are asking people to test, test, test. (The fact that we slow down the rate of major changes to the tree accounts for the rest.) mcl ___ 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: Why Are You NOT Using FreeBSD?
In message <2490439.ec638ti...@x220.ovitrap.com>, Erich writes: > Hi, > > On 05 June 2012 12:48:20 Mark Andrews wrote: > > > > In message <3506767.fvm2kmt...@x220.ovitrap.com>, Erich writes: > > > > > > On 05 June 2012 11:24:25 Mark Andrews wrote: > > > > > > > > > > > It's already there. If you want the ports as of FreeBSD 4.x EOL > > then the tag is "RELEASE_4_EOL". If you want ports as of FreeBSD > > 9.0 then the tag is "RELEASE_9_9_0". > > > I did not know this. Do you have a link for this? I never read about it. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html If you wander around in http://www.freebsd.org/cgi/cvsweb.cgi/ you can see all the possible tags. > Erich -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Why Are You NOT Using FreeBSD?
On Tue, Jun 05, 2012 at 12:18:33PM +0700, Erich wrote: > I did not know this. Do you have a link for this? I never read about it. The EOL announcements have them. I don't think the release announcements do, however. mcl ___ 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: Why Are You NOT Using FreeBSD?
On Tue, Jun 05, 2012 at 01:00:45PM +0700, Erich wrote: > All of these, with the exception of HEAD (which is always a valid tag), > only apply to the src/ tree. The ports/, doc/, and www/ trees are not > branched. If you create a branch, you must create a tag for that branch. However, you can create a tag without creating a branch. That is what is done for the ports tree. It's not particularly easy to see this on cvsweb. But let's take a look at a random Mk/bsd.*.mk file via 'cvs log': RCS file: /home/FreeBSD/pcvs/ports/Mk/bsd.apache.mk,v Working file: bsd.apache.mk head: 1.36 branch: locks: strict access list: symbolic names: RELEASE_8_3_0: 1.35 RELEASE_9_0_0: 1.33 RELEASE_7_4_0: 1.26 RELEASE_8_2_0: 1.26 RELEASE_6_EOL: 1.26 [...] RELEASE_6_1_0: 1.9 RELEASE_5_5_0: 1.9 keyword substitution: kv total revisions: 36;selected revisions: 36 description: revision 1.36 date: 2012/05/23 08:17:48; author: miwi; state: Exp; lines: +2 -2 - Remove emacs mode, -*- mode: ...; -*- [1] - Comments for BUILD_ and RUN_DEPENDS fail to mention alternate means to specify dependencie [2] - Fix make reinstall [3] - Trivial comment change for PORTDATA [4] [...] and so forth. The line "RELEASE_8_3_0: 1.35" tells you "the version of this file as of tag RELEASE_8_3_0 was r1.35." So that's what's on the 8.3R distribution media. mcl ___ 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: Why Are You NOT Using FreeBSD?
On Tue, Jun 05, 2012 at 03:23:01PM +0700, Erich wrote: > But is this true for apache only or for the whole ports tree? Entire tree. mcl ___ 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: Why Are You Using FreeBSD?
On Sun, 03 Jun 2012 20:45:59 -0500, Stephen Montgomery-Smith wrote: More recently I have had to start using Linux because FreeBSD doesn't have very good laptop support. (All I ask for is a way to configure the mouse pad so that I can switch off "tap to click.") See, this isn't very obvious to most people. It took me forever to figure it out. On every other OS you use the Xorg synaptics driver, but on FreeBSD there is synaptics support built-in with the rest of the mouse driver. man 4 psm: Tap and drag gestures can be disabled by setting hw.psm.tap_enabled to 0 at boot-time. Currently, this is only supported on Synaptics touchpads with Extended support disabled. The behaviour may be changed after boot by setting the sysctl with the same name and by restarting moused(8) using /etc/rc.d/moused. ___ 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: Why Are You NOT Using FreeBSD?
In message <1541214.zfrdxxb...@x220.ovitrap.com>, Erich writes: > Hi, > > On 05 June 2012 1:09:50 Mark Linimon wrote: > > On Tue, Jun 05, 2012 at 01:00:45PM +0700, Erich wrote: > > > All of these, with the exception of HEAD (which is always a valid tag), > > > only apply to the src/ tree. The ports/, doc/, and www/ trees are not > > > branched. > > > > If you create a branch, you must create a tag for that branch. > > > > However, you can create a tag without creating a branch. That is what > > is done for the ports tree. > > > I found now the location where this information is missing for beginners. > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html > > I simply cannot believe that beginners would expect this information to find > this in the section for updating the kernel. > > Erich Because, while you believe it is better to roll back to the release point it really isn't. The ports tree is rarely broken for long. When it is broken people will tell you to roll back to a good date and give you the date to use. I've had to roll back a couple of times in 11+ years of updating and never to a release point. What is there is good advice. Use a up-to-date ports tree. If it is broken wait a days or so and try again. If it is still broken report the problem using send-pr. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: Why Are You NOT Using FreeBSD?
In message <1805884.wjzbqif...@x220.ovitrap.com>, Erich writes: > Hi, > > On 06 June 2012 0:42:47 Mark Andrews wrote: > > > > In message <1541214.zfrdxxb...@x220.ovitrap.com>, Erich writes: > > > Hi, > > > > > > On 05 June 2012 1:09:50 Mark Linimon wrote: > > > > On Tue, Jun 05, 2012 at 01:00:45PM +0700, Erich wrote: > > > > > All of these, with the exception of HEAD (which is always a valid tag > ), > > > > > only apply to the src/ tree. The ports/, doc/, and www/ trees are not > > > > > branched. > > > > > > > > If you create a branch, you must create a tag for that branch. > > > > > > > > However, you can create a tag without creating a branch. That is what > > > > is done for the ports tree. > > > > > > > I found now the location where this information is missing for beginners. > > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.htm > l > > > > > > I simply cannot believe that beginners would expect this information to f > ind > > > this in the section for updating the kernel. > > > > > > Erich > > > > Because, while you believe it is better to roll back to the release > > point it really isn't. The ports tree is rarely broken for long. > > When it is broken people will tell you to roll back to a good date > > and give you the date to use. I've had to roll back a couple of > > times in 11+ years of updating and never to a release point. > > > > What is there is good advice. Use a up-to-date ports tree. If it > > is broken wait a days or so and try again. If it is still broken > > report the problem using send-pr. > > you will find thousands of notes that people should not run bleeding > edge when it comes to the kernel. > > But people are forced to run bleeding edge on the ports. The kernel and ports are very different things. On the bleeding edge the kernel may not even boot and if it boots it may corrupt the entire disk requiring you to reinstall and recover from backups. Ports don't normally get added unless they build and run. Occasionally there are integration issues because one cannot test the billions if not trillions of possible port combinations. Remember almost every port is already "released" software that has already gone through alpha and beta testing. Those that arn't are clearly marked as such. > The documentation than even states that there is no fall back. > > You state it as being just normal to wait for a week or more until the > problem is solved. I cannot imagine that people who come to FreeBSD and > get trapped somehow will stick to it then. If you report a bug to Oracle or Microsoft you won't get a fix within a week. It just doesn't happen unless you are paying very big dollars and might not happen even then as it can take weeks to find the cause of a bug even with a team working 7x24 to find it. > They might will ask on this list just to learn that there is no help > available. Just wait. > > People who have to make decisions what operating system should be used on > their workplaces will not like this and stick with whatever they have. Yet there are plenty of places that do run FreeBSD. They understand the limitations and accept them. > I believe that this is a very good user repellent. Remember you don't have to use the ports system. You can install software without using ports. The ports system just saves you time. > Erich -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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"
