12.1 and 12.2 UPDATING files

[Doug Hardie]

There is something unusual about these files.  The 12.1 version shows an entry 
for the 12.1-RELEASE.  It does not exist in the 12.2 version even though 
entries go back for a number of years before that.

The 12.2 version has the entry for 20190913 appearing ahead of the entry for 
20190914.  One would think that since the 12.1-RELEASE is dated 20191104 that 
it would also appear in the 12.1 version, but it is not there.

The 12.2 version has a release date of 20201027 and there are a number of 
entries with dates very close to that.  However, in the 12.1 version, the 
release date is 20191104 and the latest update is dated 20190914.  That is 
almost a 2 month gap.  Seems a bit unusual.

-- Doug

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Laundry

[Doug Hardie]

> On 26 July 2020, at 13:31, Konstantin Belousov  wrote:
> 
> On Sun, Jul 26, 2020 at 01:11:33PM -0700, Doug Hardie wrote:
>> I have a production system (12.1-RELEASE-p6) that is showing around 1 GB of 
>> Laundry pages.  There are over 6 Gb Inact and 1 Gb free.  I can understand 
>> why the system would want to not prioritize laundering those pages as there 
>> is plenty of available pages.  However, does that mean that I have about 1 
>> GB of updated files that have not been written back to disk?  If so, then 
>> there is a significant issue with power failures and loss of data.
>> 
> Laundry keeps both file-backed (named) pages and swap-backed (anonymous)
> pages. Most likely it means that you have 1G of anonymous dirty
> mappings, for instance programs data/bss and malloced.

I don't believe there are very man anonymous pages, but there are lots of named 
pages.  If those are dirty, does that mean they have not yet been written back 
to disk?  The loss of those would be quite detrimental if not written back to 
disk.

-- Doug

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Laundry

[Doug Hardie]

I have a production system (12.1-RELEASE-p6) that is showing around 1 GB of 
Laundry pages.  There are over 6 Gb Inact and 1 Gb free.  I can understand why 
the system would want to not prioritize laundering those pages as there is 
plenty of available pages.  However, does that mean that I have about 1 GB of 
updated files that have not been written back to disk?  If so, then there is a 
significant issue with power failures and loss of data.

-- Doug

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: FCP-0101: Deprecating most 10/100 Ethernet drivers

[Doug Hardie]

I have a number of production servers that only have bge and I don't see that 
listed in either category.  None of them are running FreeBSD 12 yet as it has 
not been released.  Also there are some with rl.  Those are add-on boards so 
they could be changed, but would require extensive effort as the machines are 
about a 4 hour drive from here and would require reconfiguration (an error 
prone process when you are tired).

I also have two production machines with ue devices.  There is no provision for 
replacing them.  They are running an early version of 12 as 11 doesn't run on 
those machines.  I don't see ue listed in either category.

-- Doug

> On 3 October 2018, at 14:05, Brooks Davis  wrote:
> 
 Please direct replies to freebsd-arch <<<
> 
> FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md)
> outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12
> and remove them in FreeBSD 13 to reduce the burden of maintaining and
> improving the network stack.  We have discussed this within the
> core team and intend to move forward as proposed.  We are solictiting
> feedback on the list of drivers to be excepted from removal.
> 
> The current list of drivers slated for REMOVAL is:
> 
> ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn,
> ste, tl, tx, txp, vx, wb, xe
> 
> The current list of drivers that will STAY in the tree is:
> 
> dc, ffec, fxpl, hme, le, sis, vr, xl
> 
> The criteria for exception are:
> - Popular in applications where it is likely to be deployed beyond the
>   support lifetime of FreeBSD 12 (late 2023).
>   - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.
> - Required to make a well supported embedded or emulation platform usable.
> - Ported to use iflib (reducing future maintenance cost.)
> 
> Please reply to this message with nominations to the exception list.
> 
> The full FCP-0101 is included below.
> 
> -- Brooks
> 
> ---
> authors: Brooks Davis 
> state: feedback
> ---
> 
> # FCP 101: Deprecation and removal of 10/100 Ethernet drivers
> 
> Deprecate most 10 and 10/100Mbps Ethernet drivers and remove them before
> FreeBSD 13.
> 
> ## Problem Statement
> 
> Each network driver creates drag for the project as we attempt to
> improve the network stack or provide new features such as expanded
> 32-bit compatibility.  For example, the author has edited every single
> NIC driver more than once in the past year to update management (`ioctl`)
> interfaces.  We could improve this situation by converting drivers to
> iflib, but each additional driver takes work.
> 
> 10 and 100 megabit Ethernet drivers are largely irrelevant today
> and we have a significant number of them in the tree.  The ones that
> are no longer used and/or are not known to be working need to be
> removed due to the significant ongoing 'tax' on new development.
> 
> For at least a decade, most systems (including small embedded
> systems) have shipped with gigabit Ethernet devices and virtual
> machines commonly emulate popular gigabit devices.  We wish to
> retain support for popular physical and virtual devices while
> removing support for uncommon ones.  With a few exceptions these
> drivers are unlikely to be used by our user base by the time FreeBSD
> 12 is obsolete (approximately 2024).
> 
> ## Proposed Solution
> 
> We propose to deprecate devices which are not sufficiently popular.  This
> will entail:
> - (October 2018) Send this list to freebsd-net and freebsd-stable.
> - (Before FreeBSD 12.0-RELEASE - October 2018) Update the manpages and
>   attach routines for each device to be removed and merge those changes
>   to FreeBSD 12.
> - (One month after FreeBSD 12.0-RELEASE - January 2018) Remind
>   freebsd-net and freebsd-stable users of pending deletion.
> - (Two months after FreeBSD 12.0-RELEASE - February 2019) Delete deprecated
>   devices.
> 
> Through out this process, solicit feedback on additions to the exception
> list and update this document as required.  For a device to be placed on
> the exception list the device must meet one of the following criteria:
> - Popular in applications where it is likely to be deployed beyond the
>   support lifetime of FreeBSD 12 (late 2023).
>   - 5 reports of uses in the wild on machines running FreeBSD 12 will be
> deemed satisfy the "popular"
> requirement.
> - Required to make a well supported embedded or emulation platform usable.
> - Ported to use iflib (reducing future maintenance cost.)
> 
> ### Exceptions to removal
> 
> Device | Reason
> ---|-
> ffec   | Onboard Ethernet for Vybrid arm7 boards
> fxp| Popular device long recommended by the project.
> dc | Popular device for CardBus card.
> hme| Built in interface on many supported sparc64 platforms.
> le | Emulated by QEMU, alternatives don't yet work for mips64.
> sis| Soekris Engineering net45xx, net48xx, 

Re: 9.3 to 11.1 upgrade

[Doug Hardie]

> On 20 June 2017, at 10:31, Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> Zoran Kolic wrote on 2017/06/20 17:12:
>>> Generally (and previously) the advice is to go via the next major version so
>>> you should go:
>>> 
>>> 9.3 -> 10.x -> 11.x not 9.3 -> 11.x
>> 
>> Exactelly what I want to avoid.
>> People successfuly upgraded, without branch 10.
> 
> In the past I did 8.4 to 10.3, but not by freebsd-update. We are using make 
> installkernel + make installworld method. 9.3 to 11.1 can work similarly.
> 
> Miroslav Lachman

I did 9.3 to 11.0 using freebsd-update.  I had no choice since 10.x would not 
boot on my system.  9 and 11 boot just fine.  It worked, but I had to patch 
freebsd-update to get there.  I don't find it anymore, but it did involve 
adding a comma in a long string.  It should still be available in the archives.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: update from 9.3 to 11.0

[Doug Hardie]

> On 16 October 2016, at 08:24, Warner Losh <i...@bsdimp.com> wrote:
> 
> On Sun, Oct 16, 2016 at 8:13 AM, Zoran Kolic <zko...@sbb.rs> wrote:
>> I would like to know what experience and tips people on this list have
>> regarding this update. Doug Hardie made it successfully. To my eyes,
>> it is the mere change of one charracter in the file.
>> I'm a bit late due to lack of time to do the task.
>> Best regards all
> 
> I missed the original post. what's the one character change?


I was sent the patch  below.  However, it doesn't apply directly to 9.3.  Edit 
freebsd-update and go down about 1231 lines.  Generally the comment is found a 
few lines before that.  Add the comma, and all works.

-- Doug


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211398

--- Comment #5 from Xin LI <delp...@freebsd.org> ---
(In reply to bc979 from comment #4)

Can you try applying this? (r279901)

Index: head/usr.sbin/freebsd-update/freebsd-update.sh
===
--- head/usr.sbin/freebsd-update/freebsd-update.sh  (revision 279900)
+++ head/usr.sbin/freebsd-update/freebsd-update.sh  (revision 279901)
@@ -1231,7 +1231,7 @@ fetch_metadata_sanity () {
   # Some aliases to save space later: ${P} is a character which can
   # appear in a path; ${M} is the four numeric metadata fields; and
   # ${H} is a sha256 hash.
-   P="[-+./:=%@_[~[:alnum:]]"
+   P="[-+./:=,%@_[~[:alnum:]]"
   M="[0-9]+\|[0-9]+\|[0-9]+\|[0-9]+"
   H="[0-9a-f]{64}"


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Problems with em0 driver after upgrade to r303832

[Doug Hardie]

> On 9 August 2016, at 04:40, Kurt Jaeger  wrote:
> 
> Hi!
> 
>> I upgraded my local machine to the above revision a few days ago. Since then 
>> I have seen the local em0 card locking up and getting he following
>> messages in dmesg
>> 
>> em0: Watchdog timeout -- resetting
>> em0: link state changed to DOWN
>> em0: link state changed to UP
>> 
>> 
>> I thought it was the physical card, but I have swapped this out
>> for a completely different one and the problems remain.
> 
> What does pciconf -lvb display for the PCI IDs for this card ?
> 
> If you use r303832, this is CURRENT (12.x) ? Then maybe the
> question should be discussed on curr...@freebsd.org.


I am seeing this on 11.0-BETA3/4.

bge0@pci0:3:0:0:class=0x02 card=0x168614e4 chip=0x168614e4 rev=0x01 
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'NetXtreme BCM57766 Gigabit Ethernet PCIe'
class  = network
subclass   = ethernet
bar   [10] = type Prefetchable Memory, range 64, base 0xa070, size 
65536, enabled
bar   [18] = type Prefetchable Memory, range 64, base 0xa071, size 
65536, enabled

It does not occur on another machine with:

bge0@pci0:2:0:0:class=0x02 card=0x16b414e4 chip=0x16b414e4 rev=0x10 
hdr=0x00
vendor = 'Broadcom Corporation'
device = 'NetXtreme BCM57765 Gigabit Ethernet PCIe'
class  = network
subclass   = ethernet
bar   [10] = type Prefetchable Memory, range 64, base 0x9040, size 
65536, enabled
bar   [18] = type Prefetchable Memory, range 64, base 0x9041, size 
65536, enabled

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: freebsd-update from 9.3 to 11.0

[Doug Hardie]

> On 7 August 2016, at 23:05, Zoran Kolic  wrote:
> 
>> The patch (correctly applied by hand) worked fine.  The update completed and 
>> the server is running 11.0-BETA4.
> 
> I have sources on both boxen. When time comes, I will add a patch.
> Is it the same way to get a patch like " patch < something"? 
> You saved me from installing from the start, which I dislike a lot.
> Not right now. I will wait for a release. If I do it more freq, my
> nodes would stop working, since they are not new (read old).

No, you have to vi the file and go to approximately the location indicated in 
the patch file and replace the one line.  There are comments in above that line 
which will match those in the patch to help you find the right place.  I 
suspect the provided patch is for the 10.x version of that file.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: freebsd-update from 9.3 to 11.0

[Doug Hardie]

> On 7 August 2016, at 21:27, Zoran Kolic  wrote:
> 
>> However, that patch works and I am now able to upgrade to 11.0-BETA4.
> 
> Would you continue informing us with the end result of your procedure.
> Personally, I will go the same way on my home nodes. I'm sure latter
> RCs would be more friendly regarding this upgrade. Since I have desktop
> and laptop, I'm not able to play and miss.

The patch (correctly applied by hand) worked fine.  The update completed and 
the server is running 11.0-BETA4.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: freebsd-update from 9.3 to 11.0

[Doug Hardie]

> On 7 August 2016, at 13:59, Florian Ermisch 
>  wrote:
> 
> 
> 
> Am 7. August 2016 08:37:45 MESZ, schrieb Kurt Jaeger :
>> […]
>>> I have a number of production systems on 9.3 that need to be
>>> upgraded.  I can't go to 10.x as it won't boot on that hardware.
>>> However, 11.0 does boot.  I can't afford the downtime to completely
>>> rebuild them.
>> 
>> Uh, that sounds complicated.
> 
> Maybe it's worth the hassle to set up
> a freebsd-update server which provides 
> a 11.0 Kernel with a 10.x userland as
> 10.x-RELEASE? It's a hack, but only
> needed for the upgrade…
> 
> Regards, Florian


Comment #5 to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211398 has a 
patch that gets you very close to the right place for 9.3.  However, that patch 
works and I am now able to upgrade to 11.0-BETA4.  I have one server almost 
completed.  There are a couple of issues with packages, but they are being 
worked out.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: freebsd-update from 9.3 to 11.0

[Doug Hardie]

> On 6 August 2016, at 23:37, Kurt Jaeger  wrote:
> 
> Hi!
> 
>> Is there any information available on when freebsd-update might
>> be corrected to upgrade some 9.3 systems to 11.0?
> 
> Does
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211354
> 
> help ?
> 
>> I have a number of production systems on 9.3 that need to be
>> upgraded.  I can't go to 10.x as it won't boot on that hardware.
>> However, 11.0 does boot.  I can't afford the downtime to completely
>> rebuild them.
> 
> Uh, that sounds complicated.

 No that didn't fix it.  That change was in the EN which was applied and while 
the line numbers are different in 9.3, the extra character is in my copy.




___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

freebsd-update from 9.3 to 11.0

[Doug Hardie]

Is there any information available on when freebsd-update might be corrected to 
upgrade some 9.3 systems to 11.0?  I have tried all the beta's and none of them 
will do the upgrade even with the EN applied.  Bug 211398 has the details.

I have a number of production systems on 9.3 that need to be upgraded.  I can't 
go to 10.x as it won't boot on that hardware.  However, 11.0 does boot.  I 
can't afford the downtime to completely rebuild them.

— Doug

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

freebsd-update from 9.3 to 11.0

[Doug Hardie]

Is there any information available on when freebsd-update might be corrected to 
upgrade some 9.3 systems to 11.0?  I have tried all the beta's and none of them 
will do the upgrade even with the EN applied.  Bug 211398 has the details.

I have a number of production systems on 9.3 that need to be upgraded.  I can't 
go to 10.x as it won't boot on that hardware.  However, 11.0 does boot.  I 
can't afford the downtime to completely rebuild them.

— Doug

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: intr using Swap

[Doug Hardie]

> On 17 February 2016, at 17:45, Lowell Gilbert 
> <freebsd-stable-lo...@be-well.ilk.org> wrote:
> 
> Doug Hardie <bc...@lafn.org> writes:
> 
>>> On 17 February 2016, at 16:50, Lowell Gilbert 
>>> <freebsd-stable-lo...@be-well.ilk.org> wrote:
>>> 
>>> Have you measured that paging (not swapping; that's a more extreme
>>> measure where the whole process gets removed from memory) is a
>>> significant load on your system in a specific case? If not, I doubt that
>>> it's actually the case, and you're mitigating a non-existent problem
>> 
>> I believe the question here is what is using up the swap space.  From
>> what I have been able to find with a similar situation is that malloc
>> will allocate swap space to backup memory and mmap will also allocate
>> swap if there is no backing file.  procstat -v can be helpful in
>> chasing down some of those issues.  However, I ended up guessing which
>> process it was by sequentially restarting processes and watching
>> swapinfo.  I still have not been able to chase down what in that
>> process is using the space.  There are no mmaps that are not file
>> backed so it must be a malloc.  Finding the right one has been
>> elusive.
> 
> Sure, but I'm pretty sure that the other worriers in this thread don't
> actually have any problem at all. I tried to poke a (Socratically
> limited) number of questions as a start of figuring out whether that's
> really the case, but thus far, I'd bet that it is. If that turns out to
> be a losing bet, I *will* spend time on fixing the code.
> 
> Your observations are more useful, but I'm still not sure they indicate
> a problem that needs to be solved. There are clearly cases where
> significant quantities of swap can get used up storing copies of clean
> pages backing files on disk. Unless that slows down bringing in new
> pages that need to be read or written, I don't think that's a problem.


Well, the problem is quite significant for me in that eventually the system 
runs out of swap and starts killing processes.  Its not quite random, but I 
haven't spent much time trying to figure out how it selects those to kill.  The 
specific system unfortunately is remote (about a 3 hour drive) and when sshd 
gets killed, I have no option other than having someone go on site to reboot 
it.  I have had to start monitoring swap usage with nagios and having it 
notifiy me when swap is at 40% used.  So far that has given me enough time to 
find an internet connection and restart the process that is eating the swap.  
The developer of that process claims that the problem must be in one of the 
library functions it uses.  That does seem reasonable as I am using that 
process on a large number of systems and only one has the issue.  However, 
until I can track down which system call or malloc is eating up swap space, I 
don't really see any way to fix the problem.  I recently rebuilt that system 
with
  an updated system and resized swap to be 10x memory.  That does raise the 
mean time between process kills, but doesn't eliminate the problem.  About 
every other week the alarm is raised now.  Before it was pretty much every 
other day.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: intr using Swap

[Doug Hardie]

> On 17 February 2016, at 16:50, Lowell Gilbert 
>  wrote:
> 
> hiren panchasara  writes:
> 
>> On 02/17/16 at 04:44P, Efra?n D?ctor wrote:
>>> El 17/02/2016 a las 01:15 p. m., dweimer escribi?:
 
 They may not show as swapped unless the entire process is actually 
 swapped, which would be unlikely to occur. Personally I wouldn't worry 
 about it, the only thing I can think of is to restart processes one at 
 a time to see which one clears up the swap usage. Granted you may see 
 a little clear after each process.
 
 The more important task would be to determine what caused the memory 
 to run out in the first place, and decide if its going to be a 
 frequent enough occurrence to justify adding physical memory to the 
 system.
 
 There is likely some way to find out what is using it, but that is 
 beyond my knowledge.
 
 -- 
 Thanks,
   Dean E. Weimer
 http://www.dweimer.net/
>>> 
>>> The server has 64 GB of RAM, 40-45 GB are always inactive thats why I'm 
>>> wondering why are the processes being swapped out.
> 
> There are almost certainly no processes being swapped out. Some of their
> *pages* are being stored in swap, but that is a very different thing.
> 
>> Yes, I've seen this too. Inact end up accumulating a very large chunk of
>> memory leaving Free to very low. 
> 
> That's yet another, different thing.
> 
>> What VM/pagedaemon seems to care about is Free+Cache and not just Free.
> 
> Which makes sense, even without a deep understanding of the concepts,
> because those are guaranteed to be able to be re-allocated immediately.
> It is literally true that the pageout scan does nothing when free+cache
> is less than the target.
> 
>> I kind of get that Free mem is wasted mem but putting everything in Inact
>> to the point that machine has to go into swap when a sudden need arises
>> also doesn't seem right.
> 
> "Go into swap" is too vague to mean much.  I suspect that you mean the
> system will have to start swapping out rapidly, but that isn't actually
> the case. First of all, pages in "inact" aren't necessarily dirty, so
> re-using them wouldn't be as expensive as having to write them to
> backing store. Also, when a page is copied to swap, the surrounding
> pages are eligible to be copied to swap also, to take advantage of the
> bandwidth advantages of larger transfer sizes. This does not move them
> to the cache queue, although it does make that easier to do later if and
> when their "turn" comes up.
> 
>> I guess it all boils down to adjusting defaults to the system's need.
>> i.e. if you know you have a proc that may need a large chunk of mem
>> you'd need to tweak free+cache target accordingly. What I find lacking
>> is the correct/easy way to do it. If I look at available sysctls:
>> vm.v_free_min: Minimum low-free-pages threshold
>> vm.v_cache_min: Min pages on cache queue
>> vm.v_free_target: Desired free pages
>> And I cannot get them to do the right thing to have more Free around so
>> swapping doesn't happen in sudden need. And are these all runtime
>> sysctls? OR does it require reboot for them to work right? 
> 
> These take effect immediately, from what I can see.
> 
> Have you measured that paging (not swapping; that's a more extreme
> measure where the whole process gets removed from memory) is a
> significant load on your system in a specific case? If not, I doubt that
> it's actually the case, and you're mitigating a non-existent problem

I believe the question here is what is using up the swap space.  From what I 
have been able to find with a similar situation is that malloc will allocate 
swap space to backup memory and mmap will also allocate swap if there is no 
backing file.  procstat -v can be helpful in chasing down some of those issues. 
 However, I ended up guessing which process it was by sequentially restarting 
processes and watching swapinfo.  I still have not been able to chase down what 
in that process is using the space.  There are no mmaps that are not file 
backed so it must be a malloc.  Finding the right one has been elusive.  


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Segmentation fault running ntpd

[Doug Hardie]

> On 4 November 2015, at 08:15, Mark Martinec  
> wrote:
> 
> Upgrading 10.2-RELEASE-p6 to 10.2-RELEASE-p7 now solved ntpd crashes
> (apparently fixed by: FreeBSD Errata Notice FreeBSD-EN-15:20.vm).
> 
> Thanks!!!
> 
>  Mark
> 

ntpdc hangs when you do a peers command on 9.3.  Eventually it returns a no 
response from the server.  However, ntpq works just fine and nagios is able to 
get the status without problems.  Both of those did not work properly before.

— Doug

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: when the sshd hits the fan

[Doug Hardie]

> On 23 September 2015, at 03:44, Kurt Jaeger  wrote:
> 
> Hi!
> 
>>> I'm trying to understand why the sshd still starts after local daemons,
>>> out-of-the-box, and what it takes to make this extremely vital service
>>> to start before non-system (local) ones. I bet I'm not the first one to
>>> ask, so why isn't this already done ? Seems quite easy for me.
>> 
>> The fix is quite simple:  Add
>> 
>> # BEFORE: mail
>> 
>> to /etc/rc.d/sshd
>> 
>> I tried to submit a PR on that about a year ago, but it never
>> seemed to make it into the PR system.
> 
> It did enter the PR system.
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190447
> 
> I'll have a look at it, it annoys me as well 8-}

Thanks.  I never could find that PR in the database.  Guess I don’t quite 
understand how to successfully search it ;-)


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: when the sshd hits the fan

[Doug Hardie]

> On 23 September 2015, at 01:44, Eugene M. Zheganin  wrote:
> 
> Hi.
> 
> I'm trying to understand why the sshd still starts after local daemons,
> out-of-the-box, and what it takes to make this extremely vital service
> to start before non-system (local) ones. I bet I'm not the first one to
> ask, so why isn't this already done ? Seems quite easy for me.

The fix is quite simple:  Add

# BEFORE: mail

to /etc/rc.d/sshd

I tried to submit a PR on that about a year ago, but it never seemed to make it 
into the PR system.  Many of my servers are remote and if there is an issue 
with a port, I still need a way into the system other than driving for hours.  
This works.  Sshd is started early in the sequence and I can at least ssh into 
the server.  It won’t help though if there is a syntax error in /etc/rc.conf.  
Those are pretty much fatal.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Swap Usage

[Doug Hardie]

Some more testing indicates that the problem is most likely in close, not mmap. 
 I modified the program to the following:

zool# more test.c
#include stdio.h
#include fcntl.h
#include string.h
#include stdlib.h
#include errno.h
#include sys/mman.h


int main (int argc, char *argv[])
{
   int rc, pid, fd;
   char *cp;
   char cmd[1024];


   pid = getpid ();
   sprintf (cmd, procstat -v %d | grep df, pid);
   fflush (stdout);
   rc = system (cmd);
   fflush (stdout);
   printf (--\n);

   fd = open (./test.c, O_RDWR);
   fflush (stdout);
   rc = system (cmd);
   fflush (stdout);
   printf (--\n);

   close (fd);

   fflush (stdout);
   rc = system (cmd);
   fflush (stdout);
}

The output is:

zool# ./test
85860  0x8049000  0x804a000 rw-10   1   0 CN-- df 
85860 0x2805f000 0x28069000 rw-   100   1   0 C--- df 
85860 0x28186000 0x281ad000 rw-   130   1   0 CN-- df 
85860 0xbfbdf000 0xbfbff000 rwx30   1   0 C--D df 
--
85860  0x8049000  0x804a000 rw-10   1   0 CN-- df 
85860  0x804a000  0x840 rw-10   1   0 CN-- df 
85860 0x2805f000 0x28069000 rw-   100   1   0 CN-- df 
85860 0x28186000 0x281ad000 rw-   140   1   0 CN-- df 
85860 0x2840 0x2880 rw-60   1   0 CN-- df 
85860 0xbfbdf000 0xbfbff000 rwx30   1   0 C--D df 
--
85860  0x8049000  0x804a000 rw-10   1   0 CN-- df 
85860  0x804a000  0x840 rw-10   1   0 CN-- df 
85860 0x2805f000 0x28069000 rw-   100   1   0 CN-- df 
85860 0x28186000 0x281ad000 rw-   140   1   0 CN-- df 
85860 0x2840 0x2880 rw-60   1   0 CN-- df 
85860 0xbfbdf000 0xbfbff000 rwx30   1   0 C--D df 


Open creates 2 memory allocations, one in low memory and one in high.  Close 
does not remove them.  Somewhere in the source I found a note that said that 
close on files didn’t require any action.  However, those two memory 
allocations do need to get freed.  


___
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: Swap Usage

[Doug Hardie]

 On 30 July 2015, at 01:39, Doug Hardie bc...@lafn.org wrote:
 
 
 On 29 July 2015, at 23:44, Peter Jeremy pe...@rulingia.com wrote:
 
 [reformatted]
 
 On 2015-Jul-29 17:41:33 -0700, Doug Hardie bc...@lafn.org wrote:
 I have several FreeBSD 9.3 systems that are using swap and I can’t
 figure out what is doing it.  The key system has 6GB swap and
 currently it has over 2GB in use.
 
 Is the system currently paging (top(1) and systat -v will show
 this)?  If not, this just means that at some time in the past, the
 system was under memory pressure and paged some process memory out.
 Since then, that memory hasn't been touched so the system hasn't paged
 it in.
 
 ps shows only a kernel module
 [intr] with a W status.
 
 'W' means the whole process is 'swapped' out - this will only occur
 under severe RAM pressure.  Normally, the system will just page out
 inactive parts of a processes address space - and none of the ps flags
 will show this.
 
 How do I figure out what that swap space is being used for?
 
 I don't think this can be trivially done.  procstat -v will show
 the number of resident pages within each swap-backed region, any
 pages in that region that have been touched but are not resident
 are on the swap device but any pages that have never been touched
 aren't counted at all.
 
 Bingo.  procstat shows the problem.  The process that I suspected has a large 
 number of entries like:
 
  6500x834c00x83580 rw-00   1   0  sw 
  6500x835800x835c0 rw-00   1   0  sw 
  6500x835c00x837c0 rw-10   1   0  sw 
 
 I don’t know whats in those areas yet.  If I were to kill the process with 
 SIGABRT would the core dump show those areas?  I might be able to figure out 
 what they are from that.
 
 Thanks for the pointer.

I believe I have found a bug in FreeBSD 9.3 mmap.  The following test program 
(named test.c) does an mmap to itself and monitors the memory objects created 
with procstat.  After the mmap, munamp is called and the objects are checked 
again.  The objects created from the mmap do not get purged, but remain.  
Eventually, after enough have been created, they start becoming type sw and 
eventually the system runs out of swap.

The output:
zool# ./test
31459  0x8049000  0x804a000 rw-10   1   0 CN-- df 
31459 0x2805f000 0x28069000 rw-   100   1   0 C--- df 
31459 0x28186000 0x281ad000 rw-   130   1   0 CN-- df 
31459 0xbfbdf000 0xbfbff000 rwx30   1   0 C--D df 
--
31459  0x8049000  0x804a000 rw-10   1   0 CN-- df 
31459  0x804a000  0x840 rw-10   1   0 CN-- df 
31459 0x2805f000 0x28069000 rw-   100   1   0 CN-- df 
31459 0x28186000 0x281ad000 rw-   140   1   0 CN-- df 
31459 0x2840 0x2880 rw-60   1   0 CN-- df 
31459 0xbfbdf000 0xbfbff000 rwx30   1   0 C--D df 
--
31459  0x8049000  0x804a000 rw-10   1   0 CN-- df 
31459  0x804a000  0x840 rw-10   1   0 CN-- df 
31459 0x2805f000 0x28069000 rw-   100   1   0 CN-- df 
31459 0x28186000 0x281ad000 rw-   140   1   0 CN-- df 
31459 0x2840 0x2880 rw-60   1   0 CN-- df 
31459 0xbfbdf000 0xbfbff000 rwx30   1   0 C--D df 
--
31459  0x8049000  0x804a000 rw-10   1   0 CN-- df 
31459  0x804a000  0x840 rw-10   1   0 CN-- df 
31459 0x2805f000 0x28069000 rw-   100   1   0 CN-- df 
31459 0x28186000 0x281ad000 rw-   140   1   0 CN-- df 
31459 0x2840 0x2880 rw-60   1   0 CN-- df 
31459 0xbfbdf000 0xbfbff000 rwx30   1   0 C--D df 



The program:
int main (int argc, char *argv[])
{
int rc, pid, fd;
char *cp;
char cmd[1024];


pid = getpid ();
sprintf (cmd, procstat -v %d | grep df, pid);
fflush (stdout);
rc = system (cmd);
fflush (stdout);
printf (--\n);

fd = open (./test.c, O_RDWR);
cp = mmap (0, 100, PROT_READ|PROT_WRITE, MAP_FILE, fd, 0);
if (cp == MAP_FAILED)
{
printf (mmap error %s\n, strerror(errno));
exit (1);
}

fflush (stdout);
rc = system (cmd);
fflush (stdout);
printf (--\n);

rc = munmap (cp, 100);
if (rc == -1)
{
printf (munmap error %s\n, strerror(errno));
exit (1);
}


fflush (stdout);
rc = system (cmd);
fflush (stdout);
printf (--\n);

close (fd);

fflush (stdout);
rc = system (cmd);
fflush (stdout);
}

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail

Re: Swap Usage

[Doug Hardie]

 On 29 July 2015, at 23:44, Peter Jeremy pe...@rulingia.com wrote:
 
 [reformatted]
 
 On 2015-Jul-29 17:41:33 -0700, Doug Hardie bc...@lafn.org wrote:
 I have several FreeBSD 9.3 systems that are using swap and I can’t
 figure out what is doing it.  The key system has 6GB swap and
 currently it has over 2GB in use.
 
 Is the system currently paging (top(1) and systat -v will show
 this)?  If not, this just means that at some time in the past, the
 system was under memory pressure and paged some process memory out.
 Since then, that memory hasn't been touched so the system hasn't paged
 it in.
 
 ps shows only a kernel module
 [intr] with a W status.
 
 'W' means the whole process is 'swapped' out - this will only occur
 under severe RAM pressure.  Normally, the system will just page out
 inactive parts of a processes address space - and none of the ps flags
 will show this.
 
 How do I figure out what that swap space is being used for?
 
 I don't think this can be trivially done.  procstat -v will show
 the number of resident pages within each swap-backed region, any
 pages in that region that have been touched but are not resident
 are on the swap device but any pages that have never been touched
 aren't counted at all.

Bingo.  procstat shows the problem.  The process that I suspected has a large 
number of entries like:

  6500x834c00x83580 rw-00   1   0  sw 
  6500x835800x835c0 rw-00   1   0  sw 
  6500x835c00x837c0 rw-10   1   0  sw 

I don’t know whats in those areas yet.  If I were to kill the process with 
SIGABRT would the core dump show those areas?  I might be able to figure out 
what they are from that.

Thanks for the pointer.


___
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: Swap Usage

[Doug Hardie]

 On 29 July 2015, at 17:41, Doug Hardie bc...@lafn.org wrote:
 
 I have several FreeBSD 9.3 systems that are using swap and I can’t figure out 
 what is doing it.  The key system has 6GB swap and currently it has over 2GB 
 in use.  ps shows only a kernel module [intr] with a W status.  Obviously 
 that isn’t using the space.  No other process shows a W in its status.  I 
 suspect this is somewhat related to the use of mmap in one application.  
 However, all of the mmaps in that application are file backed and thus 
 shouldn’t use swap.  How do I figure out what that swap space is being used 
 for?

UFS although that shouldn’t matter.  Swap does not use a file system.  If it 
did, it would be easy to figure out.

Top doesn’t show much.  
___
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

Swap Usage

[Doug Hardie]

I have several FreeBSD 9.3 systems that are using swap and I can’t figure out 
what is doing it.  The key system has 6GB swap and currently it has over 2GB in 
use.  ps shows only a kernel module [intr] with a W status.  Obviously that 
isn’t using the space.  No other process shows a W in its status.  I suspect 
this is somewhat related to the use of mmap in one application.  However, all 
of the mmaps in that application are file backed and thus shouldn’t use swap.  
How do I figure out what that swap space is being used for?


___
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: Swap Usage

[Doug Hardie]

 On 29 July 2015, at 18:57, Chris H bsd-li...@bsdforge.com wrote:
 
 On Wed, 29 Jul 2015 17:41:33 -0700 Doug Hardie bc...@lafn.org wrote
 
 I have several FreeBSD 9.3 systems that are using swap and I can’t figure
 out what is doing it.  The key system has 6GB swap and currently it has over
 2GB in use.  ps shows only a kernel module [intr] with a W status.  Obviously
 that isn’t using the space.  No other process shows a W in its status.  I
 suspect this is somewhat related to the use of mmap in one application. 
 However, all of the mmaps in that application are file backed and thus
 shouldn’t use swap.  How do I figure out what that swap space is being used
 for? 
 Maybe top(1)?
 top -P
 for example. At least you could see who's chewing all your memory. Which
 should be a good clue as to who's responsible for swap usage.

UFS although I don’t see how that could make a difference.  Swap doesn’t use a 
regular file system.  However, the kernel must track the actual usage using 
something like a simple file system.  There must be a way to investigate it.

Top doesn’t show anything unusual.  The most VM used is by the process that 
uses a lot of mmap space that is all file backed.  If it was another process 
that was partially swapped then the ps status should show a W.  Only the one 
does.
___
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: Significant memory leak in 9.3p10?

[Doug Hardie]

 On 26 March 2015, at 18:02, Chris H bsd-li...@bsdforge.com wrote:
 
 On Thu, 26 Mar 2015 20:28:15 -0400 J David j.david.li...@gmail.com wrote
 
 On Thu, Mar 26, 2015 at 8:25 PM, Chris H bsd-li...@bsdforge.com wrote:
 As Kevin already noted; stopping firefox, and starting it again,
 seems the only solution.
 
 The machines in questions are servers, they do not run Firefox or any
 GUI.  And whatever is using the memory does not show up on ps or top.
 Fair enough. I'm still getting caught up, on the thread.
 
 Maybe another shot in the dark. But speaking of Servers. We
 ran into trouble with a web server generating *enormous* error
 logs -- a runaway script. The result was, even tho there was
 far more than adequate space for the swelling log(s). Memory,
 and eventually Swap usage, began to climb quite steadily.
 
 Like I said; maybe a shot in the dark. But just thought I'd
 mention it.

I just encountered the same problem on a FreeBSD 8.2-RELEASE-p3 server today.  
Swap was at 100% and processes were being killed.  I used ps ax and killed all 
the processes with W status that I could.  Swap usage went down to 99%.  This 
was a production server so was forced to reboot.  After the reboot, the system 
came back up with the same process set and zero swap used.  Shortly after that 
a core image appeared and the root filesystem was full.  The core file was 
about 1 GB.  However, none of my processes are anywhere near that.  The 
specific process that was dumped is only about 140 lines of C code and doesn’t 
have any dynamic storage used, just a couple of short character strings and one 
integer.  The binary file is 23KB.  I couldn’t take time to run gdb on it as it 
was affecting production.


___
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-Update + Sendmail

[Doug Hardie]

On 6 August 2013, at 09:18, Ted Hatfield t...@io-tx.com wrote:

 I too have been updating my systems by updating and building from source. To 
 recompile and install sendmail from the /usr/src tree you can run these 
 commands.
 
 cd /usr/src/lib/libsm; make clean; make obj; make depend; make
 cd /usr/src/lib/libsmutil; make clean; make obj; make depend; make
 cd /usr/src/usr.sbin/sendmail; make clean; make obj; make depend; make; make 
 install
 
 This procedure will follow all the /etc/make.conf arguments.

FreeBSD zool.lafn.org 9.1-RELEASE-p1 FreeBSD 9.1-RELEASE-p1 #4: Wed Feb 20 
22:34:04 PST 2013 d...@zool.lafn.org:/usr/obj/usr/src/sys/LAFN  i386


make of sendmail yields:

cc -O2 -pipe  -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src 
-I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB -DNIS 
-DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TLS_1 
-I/usr/local/include/sasl -DSASL -std=gnu99 -fstack-protector -Wsystem-headers 
-Werror -Wno-pointer-sign -c 
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sasl.c
cc1: warnings being treated as errors
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sasl.c: In function 
'sm_sasl_init':
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sasl.c:141: warning: 
passing argument 1 of 'sasl_set_alloc' from incompatible pointer type
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sasl.c:141: warning: 
passing argument 2 of 'sasl_set_alloc' from incompatible pointer type
/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/sasl.c:141: warning: 
passing argument 3 of 'sasl_set_alloc' from incompatible pointer type
*** [sasl.o] Error code 1


/etc/make.conf:

SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL
SENDMAIL_LDFLAGS=-L/usr/local/lib
SENDMAIL_LDADD=-lsasl2
WITHOUT_X11=yes

# added by use.perl 2013-05-22 13:05:04
PERL_VERSION=5.12.4


I can't figure out where cc1 has been configured to treat warnings as errors.  
This has not happened before to me.
___
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: Sanity Check on Mac Mini

[Doug Hardie]

As I previously indicated, I have tested a couple more Minis and updated the 
instructions with what I learned.  Here is the revised version:

2.12Installing FreeBSD on an Apple Mac Mini

The Mac Mini is an attractive server platform.  Its small, runs cool, low 
powered, and reasonably cheap.  There a variety of configurations available.  
However, the bottom of the line seems to be a powerful server.

There are a few issues with installing FreeBSD on the mini.  Mostly they derive 
from the newer hardware it uses and that it uses EFI rather than a BIOS for 
booting.  There is not a simple install that will get the unit working, but the 
additional steps required are quite simple.  The goal of these instructions is 
to get FreeBSD 9.1-Release running as a headless server on a Late 2012 Mini, 
Model No A1347.  Its probably possible to setup the mini as a workstation, but 
that would require some additional effort to test the display and mouse 
interfaces and find fixes for any issues with those.

The original intent was to have the server without system source so that it 
could be maintained using freebsd-update.  However, that will probably have to 
wait until 9.2-Release is available.  In the meantime, freebsd-update has to be 
used with care since I believe it will replace the modified bge files.


2.12.1  Preparing for the Install

2.12.1.1Automatic Startup after Power is Restored

Generally servers need to be automatically restarted after a power failure.  
Start up the Mini in OS-X.  If this is a new unit, I go through the 
registration so that Apple has it on record for use with AppleCare.  Go to 
System Preferences and select Energy Saver.  I set Put hard disk to sleep when 
possible, Wake for network access, Allow power button to put the computer to 
sleep, and most importantly - Start up automatically after a power failure.  
Note, shutting down the computer at this time will not permit it to come back 
on when power is applied.  You have to pull the power plug.  Apparently this 
setting is a bit mislabeled.  Its more like Return the Power to the last status.

These settings work properly with Mac OS-X.  I have not found a way to set the 
startup settings while running FreeBSD yet.  These settings do carry over to 
the FreeBSD install.  However, you may need to lock the energy saver 
preferences for that to happen.

Shutdown the Mini.


2.12.1.2Preparing FreeBSD for the installation

You can select either the i386 or the amd64 distributions.  Both have been 
tested with these procedures and yield a working server.  The bottom of the 
line mini comes with 4 GB of memory installed.  The i386 distribution will only 
use 2 GB.  The remainder will not be used.  The amd64 distribution builds 
larger binary modules, but it will use all the memory.

Download the 9.1 Release distribution Memstick Image.  You will need to copy 
that to a memstick.  There are instructions in section 2.3.5 for copying the 
image to the memstick.  Obtain a display and USB keyboard and connect them to 
the mini.

With a browser go to svnweb.freebsd.org/base/head/sys/dev.  Click on the bge 
folder.  Click on the name if_bge.c.  Find Revision 245931.  Click on the 
download link and save the file.

Go back to the bge page and click on if_bgereg.h.  Find Revision 243686. Click 
on the download link and save the file.  Edit the saved if_bgereg.h file and 
add the following to the end:

#define PCIER_DEVICE_CAP0x4
#define PCIER_DEVICE_CTL0x8
#define PCIEM_CAP_MAX_PAYLOAD   0x0007
#define PCIEM_CTL_RELAXED_ORD_ENABLE0x0010
#define PCIEM_CTL_NOSNOOP_ENABLE0x0800
#define PCIER_DEVICE_STA0xa
#define PCIEM_STA_CORRECTABLE_ERROR 0x0001
#define PCIEM_STA_NON_FATAL_ERROR   0x0002
#define PCIEM_STA_FATAL_ERROR   0x0004
#define PCIEM_STA_UNSUPPORTED_REQ   0x0008

There was a change to some of the names in if_bgereg.h after the 9.1 Release 
was created, but before the corrections to the bge driver were included.  It 
would be possible to grab the appropriate earlier verion of if_bgereg.h, 
however, when rebuilding the kernel, there are other drivers that use the new 
names.  This seems to be the easiest approach.  Also, it worked.

Go back to the dev page and click on the mii folder.  Click on brgphy.c.  Find 
revision 244482.  Click on the download link and save the file.

Copy the saved files to another memstick.


2.12.2  Installing the 9.1 Release

Boot the mini using the memstick.  Hold down the Option key on the keyboard and 
power up the mini.  You will hear the hardware check beep and shortly 
thereafter the screen will show one or more boot icons.  Double click on the 
one named Windows.  It will have a USB icon.

Continue through the normal installation procedure as detailed earlier in this 
chapter.  If you are building a FreeBSD only server, use the entire disk.  
Also, be sure to install the system source.  You will need it later.

You will 

Re: Sanity Check on Mac Mini

[Doug Hardie]

I have documented what I have completed and what remains to be done for the 
install of 9.1 on a Mini.  I wrote this as a section of the Handbook, although 
its not in the right format as I don't know what that format is.  I believe 
this needs to be retained in the documentation somewhere easily found for those 
who need it in the future.




2.12Installing FreeBSD on an Apple Mac Mini

The Mac Mini is an attractive server platform.  Its small, runs cool, low 
powered, and reasonably cheap.  There a variety of configurations available.  
However, the bottom of the line seems to be a powerful server.

There are a few issues with installing FreeBSD on the mini.  Mostly they derive 
from the newer hardware it uses and that it uses EFI rather than a BIOS for 
booting.  There is not a simple install that will get the unit working, but the 
additional steps required are quite simple.  The goal of these instructions is 
to get FreeBSD 9.1-Release running as a headless server on a Late 2012 Mini.  
Its probably possible to setup the mini as a workstation, but that would 
require some additional effort to test the display and mouse interfaces and 
find fixes for any issues with those.

The original intent was to have the server without system source so that it 
could be maintained using freebsd-update.  However, that will probably have to 
wait until 9.2-Release is available.  In the meantime, freebsd-update has to be 
used with care since I believe it will replace the modified bge files.


2.12.1  Preparing for the Install

You can select either the i386 or the amd64 distributions.  Both have been 
tested with these procedures and yield a working server.  The bottom of the 
line mini comes with 4 GB of memory installed.  The i386 distribution will only 
use 2 GB.  The remainder will not be used.  The amd64 distribution builds 
larger binary modules, but it will use all the memory.

Download the 9.1 Release distribution Memstick Image.  You will need to copy 
that to a memstick.  There are instructions in section 2.3.5 for copying the 
image to the memstick.  Obtain a display and USB keyboard and connect them to 
the mini.

With a browser go to svnweb.freebsd.org/base/head/sys/dev.  Click on the bge 
folder.  Click on the name if_bge.c.  Find Revision 245931.  Click on the 
download link and save the file.

Go back to the bge page and click on if_bgereg.h.  Find Revision 243686. Click 
on the download link and save the file.  Edit the saved if_bgereg.h file and 
add the following to the end:

#define PCIER_DEVICE_CAP0x4
#define PCIER_DEVICE_CTL0x8
#define PCIEM_CAP_MAX_PAYLOAD   0x0007
#define PCIEM_CTL_RELAXED_ORD_ENABLE0x0010
#define PCIEM_CTL_NOSNOOP_ENABLE0x0800
#define PCIER_DEVICE_STA0xa
#define PCIEM_STA_CORRECTABLE_ERROR 0x0001
#define PCIEM_STA_NON_FATAL_ERROR   0x0002
#define PCIEM_STA_FATAL_ERROR   0x0004
#define PCIEM_STA_UNSUPPORTED_REQ   0x0008

There was a change to some of the names in if_bgereg.h after the 9.1 Release 
was created, but before the corrections to the bge driver were included.  It 
would be possible to grab the appropriate earlier verion of if_bgereg.h, 
however, when rebuilding the kernel, there are other drivers that use the new 
names.  This seems to be the easiest approach.  Also, it worked.

Go back to the dev page and click on the mii folder.  Click on brgphy.c.  Find 
revision 244482.  Click on the download link and save the file.

Copy the saved files to another memstick.


2.12.2  Installing the 9.1 Release

Boot the mini using the memstick.  Hold down the Option key on the keyboard and 
power up the mini.  You will hear the hardware check beep and shortly 
thereafter the screen will show one or more boot icons.  Double click on the 
one named Windows.  It will have a USB icon.

Continue through the normal installation procedure as detailed earlier in this 
chapter.  If you are building a FreeBSD only server, use the entire disk.  
Also, be sure to install the system source.  You will need it later.

At the end of the install you will be asked to reboot the mini.  Here is where 
the first problem occurs.  If you pop out the memstick and let the system 
reboot, it will hang with an empty folder icon in the center of the display.

The problem is that the EFI boot loader can't find anything to boot.  There are 
several approaches that may work.  The Mac bless utility has been used to bless 
the boot disk so the boot loader can find it.  There are currently no 
instructions available for this approach.  The one way that has been shown to 
work is to make sure the memstick is removed when you boot the mini.  Once you 
get the empty folder icon, plug the memstick back in.  The system will shortly 
boot from the internal disk.  There is no known explanation for this phenomena 
other than it just works.


2.12.3  Rebuilding the kernel to support the Ethernet Interface

Once the system has been rebooted, you 

Re: Sanity Check on Mac Mini

[Doug Hardie]

On 7 March 2013, at 17:00, John Mehr j...@visi.com wrote:

 
 
 
 On Thu, 7 Mar 2013 14:18:23 -0800
  Doug Hardie bc...@lafn.org wrote:
 On 7 March 2013, at 11:57, Kevin Oberman rkober...@gmail.com wrote:
 On Thu, Mar 7, 2013 at 11:10 AM, Doug Hardie bc...@lafn.org wrote:
 On 7 March 2013, at 06:42, Richard Kuhns r...@wintek.com wrote:
  On 03/07/13 01:59, Doug Hardie wrote:
  I have a new Mac Mini and have encountered the same problem reported 
  last year by Richard Kuhns.  YongHyeon PYUN provided some patches to the 
  kernel that resolved the problem.  However, without an internet 
  connection its a bit tricky to get them into the system.  Here is the 
  approach I believe will work, but wanted to check first before I really 
  mess things up.
 
  1.  Downloaded from current today via svnweb.freebsd.org:
   sys/dev/bge/if_bgereg.h
   sys/dev/bge/if_bge.c
   sys/dev/mii/brgphy.c
 
 I believe the patches are incorporated in today's versions.  The 
  comments indicate such.  Thus I don't need to apply the original 
  supplied patch.
 
  2.  Put those on a flash drive.
 
  3.  Install 9.1 release from flash drive onto the Mini disk.  Have to 
  include the system source.
 
  4.  Copy the files from 1 above from flash over the files on the disk.
 
  5.  Rebuild the kernel and install it.
 
  Thanks,
 
  -- Doug
 
  That's worked for me 3 times now.
 Thanks.  Well, I got 9.1 Release installed, but it won't boot from the 
 internal disk.  It doesn't see the disk as bootable.  I installed using the 
 entire disk for FreeBSD. I used the i386 release.  Perhaps I need to switch 
 to the amd64 release?
 I would generally recommend using the amd64 release, but it may not get 
 your system to boot. How is your disk partitioned? GPT? Some BIOSes are 
 broken and assume that a GPT formatted disk is UEFI and will not recognize 
 them if they lack the UEFI boot partition. UEFI boot is a current project 
 that seems likely to reach head in the fairly near future, but it's not 
 possible now.
 No idea what the default partitioning is for BSDInstall. However the Mini is 
 only EFI or UFEI with some fallbacks although the comments I find in the web 
 indicate that different models have different fallbacks.
 One comment indicates that an older unit will boot if its MBR partitioning.  
 I don't know if the new installer supports that or not.
 You may be able to tweak your BIOS to get it to work or you may have to 
 install using the traditional partitioning system. The installer defaults 
 to GPT, but can create either.
 I have such a system (ThinkPad T520) and I have two disks... one that came 
 with the system and containing Windows, and my GPT formatted FreeBSD disk. 
 I wrote a FreeBSD BootEasy boot into the MBR of the Windows disk and it CAN 
 boot the GPT disk just fine. Not ideal for most, but it works well for me
 Based on a comment I say, waiting till the empty folder icon appears and 
 then plugging in the install memstick causes the mini to boot from disk.  
 That just downright weird, but it works.  I could live with that, but this 
 is an unattended server and would experience some down time if I am not 
 there when there is a power failure.
 I just found some instructions for using MBR with bsdinstall, but given 
 there is an effort to create a UEFI boot which I suspect would expect to 
 find the GPT boot partition, perhaps I should just go with the memstick 
 approach?
 
 Hello,
 
 If you still have a drive with OS X on it, you may have some luck with OS X's 
 bless command:
 
 https://developer.apple.com/library/mac/#documentation/Darwin/Reference/Manpages/man8/bless.8.html
 
 I got a late 2012 mac mini to boot FreeBSD 9.1 (AMD64) from a hard drive 
 using 'bless' (unfortunately I don't remember the exact command line 
 parameters I used).  If you're looking to dual boot, the only luck I had 
 (without resorting to using third party software like rEFIt) was to put the 
 OS's on different drives and install FreeBSD using MBR on the second drive.

I have investigated the bless command and nothing I find on google gives me any 
good ideal on what folder/file to bless.  I am wondering if just using the 
volume command and ignoring folder and file would work?

___
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: Sanity Check on Mac Mini

[Doug Hardie]

On 7 March 2013, at 06:42, Richard Kuhns r...@wintek.com wrote:

 On 03/07/13 01:59, Doug Hardie wrote:
 I have a new Mac Mini and have encountered the same problem reported last 
 year by Richard Kuhns.  YongHyeon PYUN provided some patches to the kernel 
 that resolved the problem.  However, without an internet connection its a 
 bit tricky to get them into the system.  Here is the approach I believe will 
 work, but wanted to check first before I really mess things up.
 
 1.  Downloaded from current today via svnweb.freebsd.org:
  sys/dev/bge/if_bgereg.h
  sys/dev/bge/if_bge.c
  sys/dev/mii/brgphy.c
 
I believe the patches are incorporated in today's versions.  The comments 
 indicate such.  Thus I don't need to apply the original supplied patch.
 
 2.  Put those on a flash drive.
 
 3.  Install 9.1 release from flash drive onto the Mini disk.  Have to 
 include the system source.
 
 4.  Copy the files from 1 above from flash over the files on the disk.
 
 5.  Rebuild the kernel and install it.
 
 Thanks,
 
 -- Doug
 
 That's worked for me 3 times now.

Thanks.  Well, I got 9.1 Release installed, but it won't boot from the internal 
disk.  It doesn't see the disk as bootable.  I installed using the entire disk 
for FreeBSD.  I used the i386 release.  Perhaps I need to switch to the amd64 
release?

-- Doug

___
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: Sanity Check on Mac Mini

[Doug Hardie]

On 7 March 2013, at 11:57, Kevin Oberman rkober...@gmail.com wrote:

 On Thu, Mar 7, 2013 at 11:10 AM, Doug Hardie bc...@lafn.org wrote:
 
 On 7 March 2013, at 06:42, Richard Kuhns r...@wintek.com wrote:
 
  On 03/07/13 01:59, Doug Hardie wrote:
  I have a new Mac Mini and have encountered the same problem reported last 
  year by Richard Kuhns.  YongHyeon PYUN provided some patches to the kernel 
  that resolved the problem.  However, without an internet connection its a 
  bit tricky to get them into the system.  Here is the approach I believe 
  will work, but wanted to check first before I really mess things up.
 
  1.  Downloaded from current today via svnweb.freebsd.org:
   sys/dev/bge/if_bgereg.h
   sys/dev/bge/if_bge.c
   sys/dev/mii/brgphy.c
 
 I believe the patches are incorporated in today's versions.  The 
  comments indicate such.  Thus I don't need to apply the original supplied 
  patch.
 
  2.  Put those on a flash drive.
 
  3.  Install 9.1 release from flash drive onto the Mini disk.  Have to 
  include the system source.
 
  4.  Copy the files from 1 above from flash over the files on the disk.
 
  5.  Rebuild the kernel and install it.
 
  Thanks,
 
  -- Doug
 
  That's worked for me 3 times now.
 
 Thanks.  Well, I got 9.1 Release installed, but it won't boot from the 
 internal disk.  It doesn't see the disk as bootable.  I installed using the 
 entire disk for FreeBSD.  I used the i386 release.  Perhaps I need to switch 
 to the amd64 release?
 
 I would generally recommend using the amd64 release, but it may not get your 
 system to boot. 
 
 How is your disk partitioned? GPT? Some BIOSes are broken and assume that a 
 GPT formatted disk is UEFI and will not recognize them if they lack the UEFI 
 boot partition. UEFI boot is a current project that seems likely to reach 
 head in the fairly near future, but it's not possible now.

No idea what the default partitioning is for BSDInstall.  However the Mini is 
only EFI or UFEI with some fallbacks although the comments I find in the web 
indicate that different models have different fallbacks.

One comment indicates that an older unit will boot if its MBR partitioning.  I 
don't know if the new installer supports that or not.

 
 You may be able to tweak your BIOS to get it to work or you may have to 
 install using the traditional partitioning system. The installer defaults to 
 GPT, but can create either.
 
 I have such a system (ThinkPad T520) and I have two disks... one that came 
 with the system and containing Windows, and my GPT formatted FreeBSD disk. I 
 wrote a FreeBSD BootEasy boot into the MBR of the Windows disk and it CAN 
 boot the GPT disk just fine. Not ideal for most, but it works well for me

Based on a comment I say, waiting till the empty folder icon appears and then 
plugging in the install memstick causes the mini to boot from disk.  That just 
downright weird, but it works.  I could live with that, but this is an 
unattended server and would experience some down time if I am not there when 
there is a power failure.

I just found some instructions for using MBR with bsdinstall, but given there 
is an effort to create a UEFI boot which I suspect would expect to find the GPT 
boot partition, perhaps I should just go with the memstick approach?

-- Doug

___
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

Sanity Check on Mac Mini

[Doug Hardie]

I have a new Mac Mini and have encountered the same problem reported last year 
by Richard Kuhns.  YongHyeon PYUN provided some patches to the kernel that 
resolved the problem.  However, without an internet connection its a bit tricky 
to get them into the system.  Here is the approach I believe will work, but 
wanted to check first before I really mess things up.

1.  Downloaded from current today via svnweb.freebsd.org:
sys/dev/bge/if_bgereg.h
sys/dev/bge/if_bge.c
sys/dev/mii/brgphy.c

I believe the patches are incorporated in today's versions.  The comments 
indicate such.  Thus I don't need to apply the original supplied patch.

2.  Put those on a flash drive.

3.  Install 9.1 release from flash drive onto the Mini disk.  Have to include 
the system source.

4.  Copy the files from 1 above from flash over the files on the disk.

5.  Rebuild the kernel and install it.

Thanks,

-- Doug
___
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

Unusual TCP/IP Packet Size

[Doug Hardie]

Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the 
following interface:

msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500

options=c011bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE
ether 00:11:2f:2a:c7:03
inet 10.0.1.199 netmask 0xff00 broadcast 10.0.1.255
inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 
nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
media: Ethernet autoselect (100baseTX 
full-duplex,flowcontrol,rxpause,txpause)
status: active


It sent the following packet:  (data content abbreviated)

02:14:42.081617 IP 10.0.1.199.443  10.0.1.2.61258: Flags [P.], seq 930:4876, 
ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 920110183], length 3946
0x:  4500 0f9e ea89 4000 4006 2a08 0a00 01c7  E.@.@.*.
0x0010:  0a00 0102 01bb ef4a ece1 680b ae37 1bbc  ...J..h..7..
0x0020:  8018 0410 3407  0101 080a 17f3 8ff8  4...…….


The indicated packet length is 3946 and the load of data shown is that size.  
The MTU on both interfaces is 1500.  The receiving system received 3 packets.  
There is a router and switch between them.  One of them fragmented that packet. 
This is part of a SSL/TLS exchange and one side or the other is hanging on this 
and just dropping the connection.  I suspect the packet size is the issue. 
ssldump complains about the packet too and stops monitoring.  Could this 
possibly be related to the hardware checksums?

___
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: Unusual TCP/IP Packet Size

[Doug Hardie]

On 13 February 2013, at 02:29, Eugene Grosbein egrosb...@rdtc.ru wrote:

 13.02.2013 17:25, Doug Hardie пишет:
 Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the 
 following interface:
 
 msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
  
 options=c011bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE
  ether 00:11:2f:2a:c7:03
  inet 10.0.1.199 netmask 0xff00 broadcast 10.0.1.255
  inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1 
  nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
  media: Ethernet autoselect (100baseTX 
 full-duplex,flowcontrol,rxpause,txpause)
  status: active
 
 
 It sent the following packet:  (data content abbreviated)
 
 02:14:42.081617 IP 10.0.1.199.443  10.0.1.2.61258: Flags [P.], seq 
 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 
 920110183], length 3946
  0x:  4500 0f9e ea89 4000 4006 2a08 0a00 01c7  E.@.@.*.
  0x0010:  0a00 0102 01bb ef4a ece1 680b ae37 1bbc  ...J..h..7..
  0x0020:  8018 0410 3407  0101 080a 17f3 8ff8  4...…….
 
 
 The indicated packet length is 3946 and the load of data shown is that size. 
  The MTU on both interfaces is 1500.  The receiving system received 3 
 packets.  There is a router and switch between them.  One of them fragmented 
 that packet. This is part of a SSL/TLS exchange and one side or the other is 
 hanging on this and just dropping the connection.  I suspect the packet size 
 is the issue. ssldump complains about the packet too and stops monitoring.  
 Could this possibly be related to the hardware checksums?
 
 You have TSO enabled on the interface, so large outgoing TCP packet is pretty 
 normal.
 It will be split by the NIC. Disable TSO with ifconfig if it interferes with 
 your ssldump.

Thanks.  Now all the packets are 1500 or under.  They all are received with a 
SSL header.

___
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: Unusual TCP/IP Packet Size

[Doug Hardie]

On 13 February 2013, at 22:45, YongHyeon PYUN pyu...@gmail.com wrote:

 On Wed, Feb 13, 2013 at 09:10:36PM -0800, Kevin Oberman wrote:
 On Wed, Feb 13, 2013 at 5:37 PM, YongHyeon PYUN pyu...@gmail.com wrote:
 On Wed, Feb 13, 2013 at 05:00:59AM -0800, Jeremy Chadwick wrote:
 On Wed, Feb 13, 2013 at 05:29:53PM +0700, Eugene Grosbein wrote:
 13.02.2013 17:25, Doug Hardie ??:
 Monitoring a tcpdump between two systems, a FreeBSD 9.1 system has the 
 following interface:
 
 msk0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 
 1500
  
 options=c011bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4,VLAN_HWTSO,LINKSTATE
  ether 00:11:2f:2a:c7:03
  inet 10.0.1.199 netmask 0xff00 broadcast 10.0.1.255
  inet6 fe80::211:2fff:fe2a:c703%msk0 prefixlen 64 scopeid 0x1
  nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
  media: Ethernet autoselect (100baseTX 
 full-duplex,flowcontrol,rxpause,txpause)
  status: active
 
 
 It sent the following packet:  (data content abbreviated)
 
 02:14:42.081617 IP 10.0.1.199.443  10.0.1.2.61258: Flags [P.], seq 
 930:4876, ack 846, win 1040, options [nop,nop,TS val 401838072 ecr 
 920110183], length 3946
  0x:  4500 0f9e ea89 4000 4006 2a08 0a00 01c7  E.@.@.*.
  0x0010:  0a00 0102 01bb ef4a ece1 680b ae37 1bbc  ...J..h..7..
  0x0020:  8018 0410 3407  0101 080a 17f3 8ff8  4...??.
 
 
 The indicated packet length is 3946 and the load of data shown is that 
 size.  The MTU on both interfaces is 1500.  The receiving system 
 received 3 packets.  There is a router and switch between them.  One of 
 them fragmented that packet. This is part of a SSL/TLS exchange and one 
 side or the other is hanging on this and just dropping the connection.  
 I suspect the packet size is the issue. ssldump complains about the 
 packet too and stops monitoring.  Could this possibly be related to the 
 hardware checksums?
 
 You have TSO enabled on the interface, so large outgoing TCP packet is 
 pretty normal.
 It will be split by the NIC. Disable TSO with ifconfig if it interferes 
 with your ssldump.
 
 This is not the behaviour I see with em(4) on a 82573E with all defaults
 used (which includes TSO4).  Note that Doug is using msk(4).
 
 I can provide packet captures on both ends of a LAN segment using both
 tcpdump (on the FreeBSD side) and Wireshark (on the Windows side) that
 show a difference in behaviour compared to what Doug sees.
 
 This is strange. tcpdump sees a (big) TCP segment right before
 controller actually transmits it. So if TSO is active for the TCP
 segment, you should see a series of small TCP packets on receiver
 side(i.e. 3 TCP packets in Doug's case). If you don't see a big TCP
 segment with tcpdump on TX path, probably TSO was not used for the
 TCP segment.
 It's possible for controller to corrupt the TCP segment during
 segmentation but Doug's tcpdump looks completely normal to me since
 tcpdump sees the segment before TCP segmentation.
 
 
 What I see on the FreeBSD side with tcpdump is repeated bad-len 0
 messages for payloads which are chunked or segmented as a result of TSO.
 I do not see a 1:1 ratio of bad-len entries to chunked payloads; I
 only see one bad-len entry for all chunks (up until the next ACK or
 PSH+ACK of course).
 
 
 I vaguely recall that some users reported similar TSO issues on
 various drivers. The root cause of the issue was not identified
 though. Personally I couldn't reproduce the issue at that time.
 It could be a driver or network stack bug.
 
 Beware TSO. It can significantly improve throughput on high speed
 networks, but it really has issues.
 
 TSO segments the data and transmits all of them back-to-back with no
 delay beyond IFG (the 802.3 mandated space between frames)  TSO does
 not understand congestion control. If there is congestion and TSO
 sends several frames in a row, it is entirely possible that a queue is
 full or getting close enough to full to start dropping packets and
 these segmented frames are excellent candidates.
 
 I'm not saying the drawback of TSO.  Sometimes segmented packets
 have malformed IP header length under certain circumstances such
 that these packets were dropped on receiver side.

How do I configure the msk0 interface in rc.conf to disable tso4?  I can easily 
do it with ifconfig, but don't see how to make sure its disabled after a boot.

___
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: Does / Is anyone maintaining CVS for FreeBSD?

[Doug Hardie]

On 1 January 2013, at 21:16, Chris H wrote:

 On 1 January 2013 15:17, Alfred Perlstein bri...@mu.org wrote:
 On 1/1/13 6:55 AM, Eitan Adler wrote:
 
 On 1 January 2013 02:54, Derek Kulinski tak...@takeda.tk wrote:
 
 That said I would totally understand you being upset if FreeBSD would
 decide to switch to git, since despite its benefits that is a huge
 change, and would definitely be hard for people to adjust.
 
 Just In Case:
 
 FreeBSD has no plans to switch to get in either the short or long
 term.  We will however offer git repositories and first-class cousins
 via git.freebsd.org and github.
 
 
 Are you sure?  Most of the diffs developers have been handing me lately are
 of the form a/path b/path so I think they are mostly using git behind the
 scenes.
 
 Yes.  I use git behind the scenes as well.  However, so far as I am
 aware, there are no plans in either the short or long terms to
 *convert upstream* to git.
 
 Thank God! I'd hate to think that after unwinding years accumulated
 CVS process, to rewind it for SVN, only to have to do it again for GIT,
 just seems a bit masochistic.

Is the cvs code going away?  I ask because I maintain a number of local CVS 
repositories of code for which I am the only developer/maintainer.  I also use 
grep on the repositories to find sections of code previously created and 
removed for future use.  I can't bill my clients for conversion to SVN so that 
cost I would have to eat.  I am not particularly thrilled about having to do 
so.  I don't need most of the CVS features.  About all I do is check in.  
Occasionally I botch up a module enough that I delete it and recover it from 
CVS.  I don't use branches or tags.


___
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: Library Problem

[Doug Hardie]

On 29 November 2012, at 06:01, Gary Palmer wrote:

 On Wed, Nov 28, 2012 at 10:46:51PM -0800, Doug Hardie wrote:
 
 On 28 November 2012, at 20:01, Devin Teske wrote:
 
 
 On Nov 28, 2012, at 7:36 PM, Doug Hardie wrote:
 
 I have installed 4 systems from the same FreeBSD 9.1-RC3 disk.  Three of 
 them worked just fine.  The last one is causing a problem.  It will not 
 look in /usr/local/lib/ for shared libraries.  I did the standard install, 
 moved in some source, compiled it and tried to run it.  The library is 
 there.  On the working systems ktrace shows:
 
 2259 introCALL  access(0x28066000,0F_OK)
 2259 introNAMI  /lib/libsermons.so
 2259 introRET   access -1 errno 2 No such file or directory
 2259 introCALL  access(0x28066000,0F_OK)
 2259 introNAMI  /usr/lib/libsermons.so
 2259 introRET   access -1 errno 2 No such file or directory
 2259 introCALL  access(0x28066000,0F_OK)
 2259 introNAMI  /usr/lib/compat/libsermons.so
 2259 introRET   access -1 errno 2 No such file or directory
 2259 introCALL  access(0x28066000,0F_OK)
 2259 introNAMI  /usr/local/lib/libsermons.so
 2259 introRET   access 0
 
 
 On the failing system ktrace shows:
 
 6746 introNAMI  /lib/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  access(0x28066000,0F_OK)
 6746 introNAMI  /usr/lib/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  access(0x28066000,0F_OK)
 6746 introNAMI  /usr/lib/compat/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  access(0x28066000,0F_OK)
 6746 introNAMI  /lib/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  access(0x28066000,0F_OK)
 6746 introNAMI  /usr/lib/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  write(0x2,0x28060080,0x3c)
 6746 introGIO   fd 2 wrote 60 bytes
 Shared object libsermons.so not found, required by intro
 
 
 It never attempts to check /usr/local/lib.  I can't find any configuration 
 item that affects that.  How can this be fixed?
 
 
 What's the value of ldconfig_paths in rc.conf(5)?
 
 That includes:
 /etc/rc.conf
 /etc/rc.conf.local (if it exists)
 /etc/defaults/rc.conf
 
 Here on my 9.0-R system it has the following in /etc/defaults/rc.conf:
 /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg
 
 
 /etc/defaults/rc.conf has:
 
 ldconfig_paths=/usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg
 
 
 /etc/rc.conf has nothing for ldconfig_paths.
 
 Check that /usr/local/lib doesn't have group or other write perms.
 ldconfig ignores directories that are group/world writable.
 
 To fix:
 
 chmod go-w /usr/local/lib
 sh /etc/rc.d/ldconfig start

sermons# ll -d /usr/local/lib
drwxr-xr-x  4 root  wheel  512 Nov 28 19:07 /usr/local/lib


I think I found the cause of the problem.  A reboot corrected the issue.  
Apparently when ldconfig was run /usr/local/lib didn't exist.  Apparently it 
doesn't check for that except for in ldconfig.  I was not aware of ldconfig 
before.  That explains why the reboot worked.  Thanks to all who provided 
information.

___
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: Library Problem

[Doug Hardie]

On 29 November 2012, at 13:44, Ian Lepore wrote:

 On Thu, 2012-11-29 at 13:33 -0800, Doug Hardie wrote:
 On 29 November 2012, at 06:01, Gary Palmer wrote:
 
 On Wed, Nov 28, 2012 at 10:46:51PM -0800, Doug Hardie wrote:
 
 On 28 November 2012, at 20:01, Devin Teske wrote:
 
 
 On Nov 28, 2012, at 7:36 PM, Doug Hardie wrote:
 
 I have installed 4 systems from the same FreeBSD 9.1-RC3 disk.  Three of 
 them worked just fine.  The last one is causing a problem.  It will not 
 look in /usr/local/lib/ for shared libraries.  I did the standard 
 install, moved in some source, compiled it and tried to run it.  The 
 library is there.  On the working systems ktrace shows:
 
 2259 introCALL  access(0x28066000,0F_OK)
 2259 introNAMI  /lib/libsermons.so
 2259 introRET   access -1 errno 2 No such file or directory
 2259 introCALL  access(0x28066000,0F_OK)
 2259 introNAMI  /usr/lib/libsermons.so
 2259 introRET   access -1 errno 2 No such file or directory
 2259 introCALL  access(0x28066000,0F_OK)
 2259 introNAMI  /usr/lib/compat/libsermons.so
 2259 introRET   access -1 errno 2 No such file or directory
 2259 introCALL  access(0x28066000,0F_OK)
 2259 introNAMI  /usr/local/lib/libsermons.so
 2259 introRET   access 0
 
 
 On the failing system ktrace shows:
 
 6746 introNAMI  /lib/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  access(0x28066000,0F_OK)
 6746 introNAMI  /usr/lib/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  access(0x28066000,0F_OK)
 6746 introNAMI  /usr/lib/compat/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  access(0x28066000,0F_OK)
 6746 introNAMI  /lib/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  access(0x28066000,0F_OK)
 6746 introNAMI  /usr/lib/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  write(0x2,0x28060080,0x3c)
 6746 introGIO   fd 2 wrote 60 bytes
Shared object libsermons.so not found, required by intro
 
 
 It never attempts to check /usr/local/lib.  I can't find any 
 configuration item that affects that.  How can this be fixed?
 
 
 What's the value of ldconfig_paths in rc.conf(5)?
 
 That includes:
 /etc/rc.conf
 /etc/rc.conf.local (if it exists)
 /etc/defaults/rc.conf
 
 Here on my 9.0-R system it has the following in /etc/defaults/rc.conf:
 /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg
 
 
 /etc/defaults/rc.conf has:
 
 ldconfig_paths=/usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg
 
 
 /etc/rc.conf has nothing for ldconfig_paths.
 
 Check that /usr/local/lib doesn't have group or other write perms.
 ldconfig ignores directories that are group/world writable.
 
 To fix:
 
 chmod go-w /usr/local/lib
 sh /etc/rc.d/ldconfig start
 
 sermons# ll -d /usr/local/lib
 drwxr-xr-x  4 root  wheel  512 Nov 28 19:07 /usr/local/lib
 
 
 I think I found the cause of the problem.  A reboot corrected the issue.  
 Apparently when ldconfig was run /usr/local/lib didn't exist.  Apparently it 
 doesn't check for that except for in ldconfig.  I was not aware of ldconfig 
 before.  That explains why the reboot worked.  Thanks to all who provided 
 information.
 
 Oh.  Hmm, in that case, service ldconfig restart probably would have
 fixed it.  (Seems sorta strange to restart a service that just
 builds a table and exits.)

I am sure it would have.  I suspect there are more unexpected services like 
that.  There are too many services to remember, let alone understand.  A Google 
search turned up nothing usable for me.  If I could have hit on ldconfig, then 
the man page would have been perfectly clear… 

___
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

Library Problem

[Doug Hardie]

I have installed 4 systems from the same FreeBSD 9.1-RC3 disk.  Three of them 
worked just fine.  The last one is causing a problem.  It will not look in 
/usr/local/lib/ for shared libraries.  I did the standard install, moved in 
some source, compiled it and tried to run it.  The library is there.  On the 
working systems ktrace shows:

  2259 introCALL  access(0x28066000,0F_OK)
  2259 introNAMI  /lib/libsermons.so
  2259 introRET   access -1 errno 2 No such file or directory
  2259 introCALL  access(0x28066000,0F_OK)
  2259 introNAMI  /usr/lib/libsermons.so
  2259 introRET   access -1 errno 2 No such file or directory
  2259 introCALL  access(0x28066000,0F_OK)
  2259 introNAMI  /usr/lib/compat/libsermons.so
  2259 introRET   access -1 errno 2 No such file or directory
  2259 introCALL  access(0x28066000,0F_OK)
  2259 introNAMI  /usr/local/lib/libsermons.so
  2259 introRET   access 0


On the failing system ktrace shows:

  6746 introNAMI  /lib/libsermons.so
  6746 introRET   access -1 errno 2 No such file or directory
  6746 introCALL  access(0x28066000,0F_OK)
  6746 introNAMI  /usr/lib/libsermons.so
  6746 introRET   access -1 errno 2 No such file or directory
  6746 introCALL  access(0x28066000,0F_OK)
  6746 introNAMI  /usr/lib/compat/libsermons.so
  6746 introRET   access -1 errno 2 No such file or directory
  6746 introCALL  access(0x28066000,0F_OK)
  6746 introNAMI  /lib/libsermons.so
  6746 introRET   access -1 errno 2 No such file or directory
  6746 introCALL  access(0x28066000,0F_OK)
  6746 introNAMI  /usr/lib/libsermons.so
  6746 introRET   access -1 errno 2 No such file or directory
  6746 introCALL  write(0x2,0x28060080,0x3c)
  6746 introGIO   fd 2 wrote 60 bytes
   Shared object libsermons.so not found, required by intro


It never attempts to check /usr/local/lib.  I can't find any configuration item 
that affects that.  How can this be fixed?

___
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: Library Problem

[Doug Hardie]

On 28 November 2012, at 20:01, Devin Teske wrote:

 
 On Nov 28, 2012, at 7:36 PM, Doug Hardie wrote:
 
 I have installed 4 systems from the same FreeBSD 9.1-RC3 disk.  Three of 
 them worked just fine.  The last one is causing a problem.  It will not look 
 in /usr/local/lib/ for shared libraries.  I did the standard install, moved 
 in some source, compiled it and tried to run it.  The library is there.  On 
 the working systems ktrace shows:
 
 2259 introCALL  access(0x28066000,0F_OK)
 2259 introNAMI  /lib/libsermons.so
 2259 introRET   access -1 errno 2 No such file or directory
 2259 introCALL  access(0x28066000,0F_OK)
 2259 introNAMI  /usr/lib/libsermons.so
 2259 introRET   access -1 errno 2 No such file or directory
 2259 introCALL  access(0x28066000,0F_OK)
 2259 introNAMI  /usr/lib/compat/libsermons.so
 2259 introRET   access -1 errno 2 No such file or directory
 2259 introCALL  access(0x28066000,0F_OK)
 2259 introNAMI  /usr/local/lib/libsermons.so
 2259 introRET   access 0
 
 
 On the failing system ktrace shows:
 
 6746 introNAMI  /lib/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  access(0x28066000,0F_OK)
 6746 introNAMI  /usr/lib/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  access(0x28066000,0F_OK)
 6746 introNAMI  /usr/lib/compat/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  access(0x28066000,0F_OK)
 6746 introNAMI  /lib/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  access(0x28066000,0F_OK)
 6746 introNAMI  /usr/lib/libsermons.so
 6746 introRET   access -1 errno 2 No such file or directory
 6746 introCALL  write(0x2,0x28060080,0x3c)
 6746 introGIO   fd 2 wrote 60 bytes
  Shared object libsermons.so not found, required by intro
 
 
 It never attempts to check /usr/local/lib.  I can't find any configuration 
 item that affects that.  How can this be fixed?
 
 
 What's the value of ldconfig_paths in rc.conf(5)?
 
 That includes:
 /etc/rc.conf
 /etc/rc.conf.local (if it exists)
 /etc/defaults/rc.conf
 
 Here on my 9.0-R system it has the following in /etc/defaults/rc.conf:
 /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg


/etc/defaults/rc.conf has:

ldconfig_paths=/usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg


/etc/rc.conf has nothing for ldconfig_paths.


___
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: Help review the FAQ

[Doug Hardie]

On 26 November 2012, at 12:53, Bas Smeelen wrote:

 On 11/26/12 21:27, Bas Smeelen wrote:
 On 11/26/12 17:25, Jakub Lach wrote:
 Thanks!
 
 Regarding FAQ, some info about journalling should  be added to
 Chapter 9 Disks, File Systems, and Boot Loaders, especially now,
 when SU+J is default.
 
 Please also add:
 SU+J does not work (yet) with dump on a live filesystem i.e. use snapshot.
 If you want to use snapshot (dump -L) then disable the soft updates journal 
 for that filesystem

It would be helpful to include information on how to do that during install 
(still trying to figure that out myself), and using the recover CD for when you 
forget to do it during install.
___
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.1 stability/robustness?

[Doug Hardie]

On 1 November 2012, at 19:14, Brett Glass wrote:

 I need to build up a few servers and routers, and am wondering how
 FreeBSD 9.1 is shaping up. Will it be likely to be more stable and
 robust than 9.0-RELEASE?

It appears to be for me.  I had problems with 9.0 not reading CDs and rebooting 
with no error messages frequently.  I have upgraded to 9.1-RC2 and it now reads 
CDs just fine, and has not rebooted.  However, the uptimes with 9.0 ranged from 
about 2 hours to 30 days.  I have only had 9.1-RC2 running for a couple weeks 
so have not declared victory yet.  I has been running for more than most of the 
uptimes already.


 Are there issues that will have to wait
 until 9.2-RELEASE to be fixed? Opinions welcome.

I have no information on this.

___
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

IPv6 Link Local Addresses

[Doug Hardie]

With FreeBSD 9.1-RC2 you can assign the same link local address manually to two 
different hosts on the same network.  The Neighbor Solicitations are not 
responded to and you end up with non-working addresses.  The simple way to 
reproduce this is to boot two systems on the same network and get the link 
local for system 1.  Shut it off and manually assign that address to system 2.  
Then boot system 1.  System 1 will send the Neighbor Solicitation but system 2 
will not respond to show that address is in use so system 1 uses the duplicate 
address.

Even more interesting, I have another system, 9.1-RC2, that when it comes up 
never sends the Neighbor Solication.  It just starts using the link local 
address.  I can't find any significant differences between those two systems 
other that the first was a direct install from the CD and the second was a 
freebsd-update from 9.1-RC1.

Should I send a PR or is this a known issue?
___
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

Wireless Card Driver

[Doug Hardie]

I just completed the update to 8.1 Beta 1 in hopes that there would be a driver 
for the wireless card. No luck.  The update went just fine.  No problems 
observed so far.

pciconf shows:

no...@pci0:3:0:0:   class=0x028000 card=0x27901814 chip=0x07811814 rev=0x00 
hdr=0x00
vendor = 'Ralink Technology, Corp.'
device = 'Wireless (RT2860/RT2890)'
class  = network


Is there a driver not installed by default that works for this 
unit?___
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: Results of BIND RFC

[Doug Hardie]

On 2 April 2010, at 04:27, Denny Lin wrote:

 On Fri, Apr 02, 2010 at 10:11:50AM +0400, Andrey V. Elsukov wrote:
 On 02.04.2010 9:24, Stanislav Sedov wrote:
 While it certainly might make sense to drop BIND out of the base, I'm not
 sure dropping bind tools as well from it is the best decision.  How hard
 it will be to continue maintaining bind tools inside the base (so the
 critical ones like dig and nslookup still will be available), while moving
 the rest of it (the server itself and supporting tools) to the port?
 
 Hi, All.
 
 I'm agree with Stas. If it is not so hard to maintain bind-tools in the 
 base,
 It is very useful to still having them in base system.
 
 +1 here. Dig and some of the other tools are extremely useful and
 important, so it would be nice if they were in the base system instead
 of a separate port.

The reason dig and nslookup are used is because you have a problem with the 
internet connection.  Thats a bit late to say you need to install the DNS 
tools.  If you could, you wouldn't need them.  Not everyone will create a 
ports CD.  ___
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 8.0 SCSI Boot

[Doug Hardie]

On 27 March 2010, at 13:37, Peter Jeremy wrote:

 On 2010-Mar-26 17:18:30 -0700, Doug Hardie bc...@lafn.org wrote:
 I tried to upgrade a 7.2 system to 8.0.  It uses a SCSI drive.  It
 works fine on 7.2.
 
 We will need some more details before we can help you.
 
 However, it would appear that during the upgrade
 process when running make delete-old (?) there is a note about make
 delete-old-libs (?).  Don't do that at that point.  End of system.
 Make installworld fails miserably.
 
 You shouldn't run either make delete-old or make delete-old-libs
 until you have successfully run make installworld - the upgrade
 procedure shows delete-old after installworld.  Whilst delete-old will
 just make it harder to revert from a failed upgrade, running
 delete-old-libs will prevent you running installworld.  When you run
 delete-old-libs, it warns you Please be sure no application still
 uses those libraries, else you can not start such an application.
 One application that needs the old libraries is installworld.

I know that now.  Probably should have before, but didn't figure it out.  Not 
having access to UPDATING made writing the original message a bit difficult.  
make delete-old was run after make installworld.  When it completes it says you 
can run make delete-old-libs.  That is where I made the first mistake.  I 
believe that message is quite misleading and should be removed.  The first 
failure occurred on mergemaster not make installworld.  It died on the second 
install file.  The error was something to the effect that rw on /etc/fstab was 
invalid and gave the sysctl settings to use in boot to get around it.  There 
was nothing other than a reboot possible at that point.  There was no other 
option.

 
 Unfortunately rebooting caused numerous problems.
 
 Given that your installworld had failed - presumably leaving various
 FreeBSD-7.2 files lying around, whilst you deleted the libraries
 required by some of them, this is not surprising.
 
 First the /etc/fstab was listed as corrupt.
 
 This is surprising.  Assuming you cleanly rebooted your system, it
 is very unlikely that your /etc/fstab was corrupted and is more likely
 a problem with one of the mount programs.
 
 Can you provide the exact error message and what you then did.

that information is long gone.

 
 Then it quit booting altogether.
 
 If it rebooted once, there's no reason why it shouldn't reboot a
 second time.  What actions did you take between the two reboots and
 what exactly do you mean by quit booting?

It dies in the boot laoder with F1 followed by numeous #s.

 
 A complete reload from the disc 1 goes
 nowhere either.  It installs just fine but when it goes to reboot,
 All I get is F1 followed by a bunch of increasing #s.  Any key just
 adds more to the list.  I have tried with both the standard and
 FreeBSD boot managers with the same result.
 
 At that point, FreeBSD is using the BIOS drivers to access the SCSI
 disk.  If you get the 'F1' prompt then the BIOS is correctly loading
 the boot sector (so it can access the disk) so there is no obvious
 reason why it isn't booting.
 
 Do you have a copy of the dmesg from 7.2?  If not, can you give us
 some details about your motherboard (vendor/model), what SCSI
 controller you are using, what targets are attached and what other
 disks (if any) you have.  Are you using a PS/2 or USB keyboard?

The 7.2 stuff is long gone.  The disk has been wiped several times.  Until I 
can get past the F1 issue I don't have access to the hardware information.  It 
uses a PS/2 keyboard and is i386 32 bit.  Its an AMD processor thats quite old.

 
 Can you expand on what you mean by a complete reload - did you do a
 full install of FreeBSD 8.0, including partitioning and creating disk
 slices or did you re-use the existing slices?  Are you using a
 dangerously dedicated disk?  Were any disk geometry errors reported?

Complete reload means with the live filesystem:

dd if=/dev/zero of=/dev/da0 bs=10240 count=100
Boot from Disc 1
Follow the Standard Install option is sysinstall

I have done that 4 times now.  There was a semi-dead ad0 disk in the unit.  
That has been removed and going through the above one more time at this moment.

There were no errors reportd for disk geometry and its not dangerously 
dedicated.  I gave up with that on version 2.7.


This time it worked.  I used the first boot manager entry, not the FreeBSD Boot 
manager and there is no F1 line.  It just boots into FreeBSD.  Thats fine since 
there is only FreeBSD on the machine.  I guess something from the ad0 drive was 
interfering with the boot.  The disk was reporting numerous write errors 
although it could be read fine and was only holding archive'd data.  Its loss 
is insignificant.

I believe the big issue where was the message about make delete-old-libs that 
make delete-old outputs. I had never tried that before and never had problems.  
This time I decided to try it.  I think that message should be removed

FreeBSD 8.0 SCSI Boot

[Doug Hardie]

I tried to upgrade a 7.2 system to 8.0.  It uses a SCSI drive.  It works fine 
on 7.2.  However, it would appear that during the upgrade process when running 
make delete-old (?) there is a note about make delete-old-libs (?).  Don't do 
that at that point.  End of system.  Make installworld fails miserably.  
Unfortunately rebooting caused numerous problems.  First the /etc/fstab was 
listed as corrupt.  Then it quit booting altogether.  A complete reload from 
the disc 1 goes nowhere either.  It installs just fine but when it goes to 
reboot, All I get is F1 followed by a bunch of increasing #s.  Any key just 
adds more to the list.  I have tried with both the standard and FreeBSD boot 
managers with the same result.  Is there anyway to get it to boot off the SCSI 
drive?  I couldn't find anything related to this in the forums 
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: Survey results very helpful, thanks! (was: Re: net.inet.tcp.timer_race: does anyone have a non-zero value?)

[Doug Hardie]

On 8 March 2010, at 12:33, Robert Watson wrote:

 
 On Mon, 8 Mar 2010, Doug Hardie wrote:
 
 I run a number of 4 core systems with em interfaces.  These are production 
 systems that are unmanned and located a long way from me.  Under unusual 
 conditions it can take up to 6 hours to get there.  I have been waiting to 
 switch to 8.0 because of the discussions on the em device and now it sounds 
 like I had better just skip 8.x and wait for 9.  7.2 is working just fine.
 
 Not sure that any information in this survey thread should be relevant to 
 that decision.  This race has existed since before FreeBSD, having appeared 
 in the original BSD network stack, and is just as present in FreeBSD 7.x as 
 8.x or 9.x.  When I learned about the race during the early 7.x development 
 cycle, I added a counter/statistic to measure how much it happened in 
 practice, but was not able to exercise it in my testing, and so left the 
 counter in to appear in 7.0 and later so that we could perform this survey as 
 core counts/etc increase.
 
 The two likely outcomes were it is never exercised and it is exercised but 
 only very infrequently, neither really justifying the quite complex change 
 to correct it given requirements at the time.  On-going development work on 
 the virtual network stack is what justifies correcting the bug at this point, 
 moving from detecting and handling the race to preventing it from occuring as 
 an invariant.  The motivation here, BTW, is that we'd like to eliminate the 
 type-stable storage requirement for connection state (which ensures that 
 memory once used for a connection block is only ever used for connection 
 blocks in the future), allowing memory to be fully freed when a virtual 
 network stack is destroyed.  Using type-stable storage helped address this 
 bug, but was primarily present to reduce the overhead of monitoring using 
 netstat(1).  We'll now need to use a slightly more expensive solution (true 
 reference counts) in that context, although in practice it will almost 
 certainly be an unmeasurable cost.
 
 Which is to say that while there might be something in the em/altq/... thread 
 to reasonably lead you to avoid 8.0, nothing in the TCP timer race thread 
 should do so, since it affects 7.2 just as much as 8.0.  Even if you do see a 
 non-zero counter, that's not a matter for operational concern, just useful 
 from the perspective of a network stack developer to understanding timing and 
 behaviors in the stack.  :-)


Thanks for the complete explanation.  I don't believe the ALTQ issue will 
affect me.  I am not currently using it and do not expect to in the near 
future.  In addition, there was a posting that a fix for at least part of that 
will be added in a week or so.  Given all that it appears its time to start the 
planning/testing process for 8.


___
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: Survey results very helpful, thanks! (was: Re: net.inet.tcp.timer_race: does anyone have a non-zero value?)

[Doug Hardie]

On 8 March 2010, at 06:53, Robert Watson wrote:

 
 On Sun, 7 Mar 2010, Robert Watson wrote:
 
 If your system shows a non-zero value, please send me a *private e-mail* 
 with the output of that command, plus also the output of sysctl kern.smp, 
 uptime, and a brief description of the workload and network interface 
 configuration.  For example: it's a busy 8-core web server with roughly X 
 connections/second, and that has three em network interfaces used to load 
 balance from an upstream source.  IPSEC is used for management purposes (but 
 not bulk traffic), and there's a local MySQL database.
 
 I've now received a number of reports that confirm our suspicion that the 
 race does occur, albeit very rarely, and particularly on systems with many 
 cores or multiple network interfaces.  Fixing it is definitely on the TODO 
 for 9.0, both to improve our ability to do multiple virtual network stacks, 
 but with an appropriately scalable fix in mind given our improved TCP 
 scalability for 9.0 as well.

I run a number of 4 core systems with em interfaces.  These are production 
systems that are unmanned and located a long way from me.  Under unusual 
conditions it can take up to 6 hours to get there.  I have been waiting to 
switch to 8.0 because of the discussions on the em device and now it sounds 
like I had better just skip 8.x and wait for 9.  7.2 is working just 
fine.___
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

Problems with 8.0 Beta 4

[Doug Hardie]

I have switched to working hardware.  Sure makes a difference ;-)

Now I am down to a couple issues:

1.  When booting I first get the following:

F1: FreeBSD
F5: Drive 0

F6: PXE
Boot: F1

At that point it just sits and starts adding #s at the end of the Boot  
statement.  If I press F5 (none of the other F keys do anything), then  
I get another Boot:  F1 line and its sits for a moment and then boots  
from the disk.  I used the standard install with the FreeBSD Boot  
Loader.


After that the system comes up and runs fine.  I am only using it for  
network testing so haven't placed any great load on it but everything  
I have tried works fine - until I try and shut it down.  Then I get a  
panic at the very end.  It also does not shut off the power.  I have a  
console log of the entire boot/shutdown process.  The only user  
command I entered was shutdown -p now.


/boot.config: -Dh
Consoles: internal video/keyboard  serial port
BIOS drive A: is disk0
BIOS drive C: is disk1
BIOS 638kB/64512kB available memory

FreeBSD/i386 bootstrap loader, Revision 1.1
(r...@almeida.cse.buffalo.edu, Sun Sep  6 03:42:03 UTC 2009)
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0x8b2774 data=0xde874+0x1feb04 syms= 
[0x4+0x9c300+0

x4+0xd55bb]
|


 ZD?
 3 3
 3 3  __
 3 3 |  | __ ___  ___
 3  Welcome to FreeBSD!3 | |__ | '__/ _ \/ _ \
 3 3 |  __|| | |  __/  __/
 3 3 | |   | | |||
 3  1. Boot FreeBSD [default]  3 |_|   |_|  \___|\___|
 3  2. Boot FreeBSD with ACPI enabled  3     _ _
 3  3. Boot FreeBSD in Safe Mode   3 |  _ \ / |  __ \
 3  4. Boot FreeBSD in single user mode3 | |_) | (___ | |  | |
 3  5. Boot FreeBSD with verbose logging   3 |  _  \___ \| |  | |
 3  6. Escape to loader prompt 3 | |_) |) | |__| |
 3  7. Reboot  3 | |  |  |
 3 3 |/|_/|_/
 3 3
 3 3
 3 3
 3  Select option, [Enter] for default 3
 3  or [Space] to pause timer  7   3
 @DY


GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights  
reserved.

FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-BETA4 #0: Sun Sep  6 05:51:03 UTC 2009
r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
WARNING: WITNESS option enabled, expect reduced performance.
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Pentium II/Pentium II Xeon/Celeron (233.29-MHz 686-class CPU)
  Origin = GenuineIntel  Id = 0x634  Stepping = 4
   
Features 
=0x80f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMO

V,MMX
real memory  = 67108864 (64 MB)
avail memory = 46567424 (44 MB)
kbd1 at kbdmux0
ACPI Error: A valid RSDP was not found 20090521 tbxfroot-309
ACPI: Table initialisation failed: AE_NOT_FOUND
ACPI: Try disabling either ACPI or apic support.
pcib0: Intel 82443LX (440 LX) host to PCI bridge pcibus 0 on  
motherboard

pir0: PCI Interrupt Routing Table: 7 Entries on motherboard
pci0: PCI bus on pcib0
agp0: Intel 82443LX (440 LX) host to PCI bridge on hostb0
pcib1: PCI-PCI bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
$PIR: ROUTE_INTERRUPT failed.
vgapci0: VGA-compatible display mem 0xfedc-0xfedd, 
0xfd80-0xfd

ff,0xfe00-0xfe7f irq 9 at device 0.0 on pci1
isab0: PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX4 UDMA33 controller port  
0x1f0-0x1f7,0x3f6,0x170-0x177

,0x376,0xfcf0-0xfcff at device 7.1 on pci0
ata0: ATA channel 0 on atapci0
ata0: [ITHREAD]
ata1: ATA channel 1 on atapci0
ata1: [ITHREAD]
uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xfcc0-0xfcdf  
irq 11

at device 7.2 on pci0
uhci0: [ITHREAD]
usbus0: Intel 82371AB/EB (PIIX4) USB controller on uhci0
piix0: PIIX Timecounter port 0x7000-0x700f at device 7.3 on pci0
Timecounter PIIX frequency 3579545 Hz quality 0
xl0: 3Com 3c905-TX Fast Etherlink XL port 0xfc40-0xfc7f irq 10 at  
device

13.0 on pci0
miibus0: MII bus on xl0
nsphy0: DP83840 10/100 media interface PHY 24 on miibus0
nsphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
xl0: Ethernet address: 00:10:4b:2c:bb:09
xl0: [ITHREAD]
cpu0 on motherboard
pmtimer0 on isa0
unknown: PNP0c02 can't assign resources (port)
unknown: PNP0c02 can't assign resources (memory)
unknown: System Memory can't 

8.0 Install Failure

[Doug Hardie]

Installing 8.0 Beta 4 on an i386 machine from disc 1.  IN the  
Extracting ports:


Panic: initiate_write_inodeblock_ufs2: already started
cpuid=0
KDB: enter: panic
[thread pid 19 tid 100045 ]
Stopped at kdb_enter+0x3a: movl  $0,kdb_why

I did a where but its way too much to type accurately by hand.  This  
is an older system, but it does boot disc 1 where some of the previous  
releases it would not boot disk 1 but had to use the live file system.


I'll try it again without adding the ports.

___
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: 8.0 Install Failure

[Doug Hardie]

On 15 September 2009, at 01:52, Doug Hardie wrote:

Installing 8.0 Beta 4 on an i386 machine from disc 1.  IN the  
Extracting ports:


Panic: initiate_write_inodeblock_ufs2: already started
cpuid=0
KDB: enter: panic
[thread pid 19 tid 100045 ]
Stopped at kdb_enter+0x3a: movl  $0,kdb_why

I did a where but its way too much to type accurately by hand.  This  
is an older system, but it does boot disc 1 where some of the  
previous releases it would not boot disk 1 but had to use the live  
file system.


I'll try it again without adding the ports.


Well, now it no longer boots disc 1 but does boot the live fs.   
Reinstalled, but now I am getting a bunch of disk errors (SCSI) so I  
suspect the problem is hardware.



___
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

Mergemaster

[Doug Hardie]

I have been following the discussion on mergemaster and one item is a  
bit annoying.  You can use -U in the command args which sets  
AUTO_UPGRADE=yes.  That flag is not in mergemaster.rc.  It could be  
easily added to the rc file, but I suspect it would conflict with -p.   
Hence it seems like if unset AUTO_UPGRADE were added to the -p  
section then it would work.  It would be helpful to be able to include  
it in the rc file so I don't have to remember the options each time.

___
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 7.2-RC boot problem

[Doug Hardie]

On 29 April 2009, at 08:01, Ken Smith wrote:


On Wed, 2009-04-29 at 11:33 -0300, Paulo Fragoso wrote:

Hardware:
MB: Gigabyte GA-M61PME-S2
acd0: DVDR HL-DT-STDVD-RAM GH22NS30/1.01 at ata3-master SATA150

ISO  MEDIA   BOOT
7.2-RC2-i386-dvd1.isoDVD-RW   OK
7.2-RC2-i386-livefs.iso  CD-RWOK!
7.2-RC2-amd64-disc1.iso  CD-RWOK
7.2-RC2-i386-disc1.iso   CD-RW,CD-R  FAILS


Thanks, greatly appreciate all the testing.

As part of looking into this I went looking for another Gigabyte
motherboard and through the past 2 days was able to test the same  
set of

things with the same results.  So far I haven't been able to reproduce
this on anything but Gigabyte.  This is such a bizarre problem I  
really
needed someone else to confirm so thank you very much.  Since there  
is a

workaround I don't think I'll hold the release for this problem but we
will need to mention this in the Errata (and possibly the announcement
itself).


I have a number of different test PCs available.  7.2-RC2 Live FS  
boots just fine on all.  Disk 1 is not recognized as bootable on any  
of them.  I can provide any specs that might help.  They are all quite  
different.  Mostly older units.  Newest is probably about 5 years old.

___
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 7.2-rc1

[Doug Hardie]

On Apr 18, 2009, at 14:05, Doug Hardie wrote:

I have encountered a rather interesting issue trying to install  
rc1.  The system boots and then says there is no disk in the CD  
drive.  The rc1 disk1 downloaded fine and the checksums matched.   
The CD will mount fine in other systems and can easily be read.  I  
then let 7.0 boot on the test system and mounted the 7.2 cd.  It  
mounts fine and I can read all the files ( well a few that I  
tested).  Looking through the 7.0 dmesg I find some rather  
unexpected entries for the CD drive.


...

Since I can't boot the CD, I did a source update.  Unfortunately I  
seem to have downloaded one of the kernel modules while it was being  
updated since it would not compile.  Since it was for hardware I don't  
have, I just commented it out and everything then built just fine.


#device ath # Atheros pci/cardbus NIC's
#device ath_hal # Atheros HAL (Hardware Access Layer)
#device ath_rate_sample # SampleRate tx rate control for ath

I usually run a stress test on new releases.  Basically I open a ftp  
to a server (local LAN) and download gigs of data - more than the  
available free space on the drive.  With 7.1, the download would hang  
about 50% of the time.  There was free space remaining on the drive.   
The NIC was basically useless at that point.  The only way to restore  
it was to reboot.  The particular machine I am using right now only  
has an old decrepit rl NIC:


rl0: RealTek 8139 10/100BaseTX port 0xe000-0xe0ff mem  
0xdd104000-0xdd1040ff irq 12 at device 13.0 on pci0

rlphy0: RealTek internal media interface PHY 0 on miibus0
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rl0: Ethernet address: 00:d0:09:d8:8f:ff
rl0: [ITHREAD]

When running this test with 7.2-rc1 it always managed to make it to  
disk full and then terminate gracefully.  Looks like the rl NICs are  
going to be usable.  I had eliminated them from my production servers  
a long time ago.


The only real issue I encountered was that the number of files you  
have to respond to in mergemaster continues to grow (perhaps  
exponentially).  For my machine I maintain the source on thats no big  
issue.  However, it does cause a lot of additional down time for the  
servers.  I am going to have to dig through mergemaster to see if  
there is some way to tell it to automatically install the updates to  
specific directories (e.g., periodic, security, rc.d etc.).  I never  
touch them and they contribute the majority of manual entries.


___
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 7.2-rc1

[Doug Hardie]

I have encountered a rather interesting issue trying to install rc1.   
The system boots and then says there is no disk in the CD drive.  The  
rc1 disk1 downloaded fine and the checksums matched.  The CD will  
mount fine in other systems and can easily be read.  I then let 7.0  
boot on the test system and mounted the 7.2 cd.  It mounts fine and I  
can read all the files ( well a few that I tested).  Looking through  
the 7.0 dmesg I find some rather unexpected entries for the CD drive.


acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00
acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00
cd0 at ata0 bus 0 target 1 lun 0
cd0: ATAPI CD ROM 1.5 Removable CD-ROM SCSI-0 device
cd0: 3.300MB/s transfers
cd0: cd present [287216 x 2048 byte records]

...

acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00
(cd0:ata0:0:1:0): READ(10). CDB: 28 0 0 4 61 ef 0 0 1 0
(cd0:ata0:0:1:0): CAM Status: SCSI Status Error
(cd0:ata0:0:1:0): SCSI Status: Check Condition
(cd0:ata0:0:1:0): MEDIUM ERROR asc:2,0
(cd0:ata0:0:1:0): No seek complete
(cd0:ata0:0:1:0): Retrying Command (per Sense Data)
acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00
(cd0:ata0:0:1:0): READ(10). CDB: 28 0 0 4 61 ef 0 0 1 0
(cd0:ata0:0:1:0): CAM Status: SCSI Status Error
(cd0:ata0:0:1:0): SCSI Status: Check Condition
(cd0:ata0:0:1:0): MEDIUM ERROR asc:2,0
(cd0:ata0:0:1:0): No seek complete
(cd0:ata0:0:1:0): Retrying Command (per Sense Data)
acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00
(cd0:ata0:0:1:0): READ(10). CDB: 28 0 0 4 61 ef 0 0 1 0
(cd0:ata0:0:1:0): CAM Status: SCSI Status Error
(cd0:ata0:0:1:0): SCSI Status: Check Condition
(cd0:ata0:0:1:0): MEDIUM ERROR asc:2,0
(cd0:ata0:0:1:0): No seek complete
(cd0:ata0:0:1:0): Retrying Command (per Sense Data)
acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00
(cd0:ata0:0:1:0): READ(10). CDB: 28 0 0 4 61 ef 0 0 1 0
(cd0:ata0:0:1:0): CAM Status: SCSI Status Error
(cd0:ata0:0:1:0): SCSI Status: Check Condition
(cd0:ata0:0:1:0): MEDIUM ERROR asc:2,0
(cd0:ata0:0:1:0): No seek complete
(cd0:ata0:0:1:0): Retrying Command (per Sense Data)
acd0: FAILURE - READ_BIG MEDIUM ERROR asc=0x02 ascq=0x00
(cd0:ata0:0:1:0): READ(10). CDB: 28 0 0 4 61 ef 0 0 1 0
(cd0:ata0:0:1:0): CAM Status: SCSI Status Error
(cd0:ata0:0:1:0): SCSI Status: Check Condition
(cd0:ata0:0:1:0): MEDIUM ERROR asc:2,0
(cd0:ata0:0:1:0): No seek complete
(cd0:ata0:0:1:0): Retries Exhausted
(cd0:ata0:0:1:0): cddone: got error 0x5 back


The drive works under 7.0, although with error messages.  I also am  
hearing some rather unusual clicks and whines occasionally from the  
computer.  I can't tell if they are from the CD drive but I suspect  
so.  Many of them stop temporarily when I read a file from the CD.   
Taking the CD out seems to have stopped the noise.  It would appear  
that I have some kind of CD drive failure.  I don't understand why 7.0  
can read the drive and 7.2 doesn't even see the disk in 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: SSH problem

[Doug Hardie]

On Jan 26, 2009, at 12:54, Julian Stacey wrote:


Hi,
Reference:

From:   Xian Chen hoganx...@gmail.com
Date:   Mon, 26 Jan 2009 13:45:56 -0500
Message-id:	a2dd20fc0901261045m57230e5cr8d22d905517c8...@mail.gmail.com 



Xian Chen wrote:

Hi All,

I can use scp to move files from a linux to my Freebsd machine.

But, when I try to use WinSCP under windows, it always failed. WinSCP
errors: Network error: Connection refused. Both scp  sftp fail  
if using

WinSCP.

Any clues for this?


on FreeBSD:
man sftp says -v option exists
man ssh also offers -v
so try both those from Win/Lose/Mickesoft (*),
Also ref.
man sshd
try
 kill -9 `cat /var/run/sshd.pid`
or hash out sshd line in /etc/inetd.conf  then
kill -HUP `cat /var/run/inetd.pid`
 then run  as root
/usr/sbin/sshd -D -d

more /var/run/auth.log

(*) PS I hate MS  dont use it, but doesnt invalidate debug stuff  
above

though, except you might need to start ssh from a command line to
add a parameter, rather than just clicking.


Here is how I have setup secure ftp for our users:

LAFN now provides a ftp server that handles the ftp-ssl and ftp-tls  
protocols (RFC-2228).  These protocols will encrypt the user id and  
password and can also be configured to encrypt the file contents if  
desired.  The standard ftp port, 21, is used for both encrypted and  
non-encrypted ftp sessions.  The older sftp, scp, and implicit ftp-ssl  
protocols are not supported.  Obviously transfer times are longer if  
encryption is used.  There are several Windows and Unix clients that  
support these protocols.  The following clients are believed to work  
properly:


CuteFTP Pro 2.0 Windows
FileZilla 2.0.0 beta 5  Windows (GPL)
SmartFTP 1.0 build 969  Windows
WinSSLWrap 1.17 Windows
WS_FTP Pro 7.5  Windows
FTP Voyager Secure 9.1.0.1  Windows
Lftp 2.5.2  Unix

In addition there is a client available at http://bsdftpd-ssl.sc.ru  
that will work with Windows 9x, NT, 2000, and some Linux  
distributions.  The only known client for Macintosh is available in  
the LAFN FAQ.  It only works with OS-X and is the command line client  
from the fstftpd-ssl distribution.



The client info above is a bit old, but is probably still accurate.   
There may be additional clients available now.  On the server I use  
the bsdftpd-ssl port.  It replaces the base ftpd.  Several of the  
above clients are in regular use.

___
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

7.1 Live Filesystem CD

[Doug Hardie]

Is the Live Filesystem CD supposed to be bootable?  7.0's was but I  
can't get the 7.1 disc to boot.  It works fine if I boot from CD 1 and  
then switch.

___
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

System update

[Doug Hardie]

I installed 7.0 release when it first came out.  However, because of  
the TCP problems with users on cable modems I had to switch to Stable  
to get the fix.  I haven't updated the source since then and now there  
are some updates on the verge of being released that need to be  
included.  However, I can't tell if the fixes for the networking issue  
have been included in the security releases or not.  Since these are  
production servers I don't want to just grab some random version of  
stable unless thats the only way to get all the required fixes.  How  
do I find out which version I should upgrade to?  If I can go back to  
a security release I suspect I will need to delete all of /usr/src, / 
usr/obj, and then reinstall the original source from the 7.0 release  
cd and then upgrade vi csup.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: System update

[Doug Hardie]

On Jul 12, 2008, at 15:33, Jeremy Chadwick wrote:


On Sat, Jul 12, 2008 at 02:37:21PM -0700, Doug Hardie wrote:
I installed 7.0 release when it first came out.  However, because  
of the
TCP problems with users on cable modems I had to switch to Stable  
to get
the fix.  I haven't updated the source since then and now there are  
some

updates on the verge of being released that need to be included.
However, I can't tell if the fixes for the networking issue have been
included in the security releases or not.  Since these are production
servers I don't want to just grab some random version of stable  
unless

thats the only way to get all the required fixes.  How do I find out
which version I should upgrade to?  If I can go back to a security
release I suspect I will need to delete all of /usr/src, /usr/obj,  
and

then reinstall the original source from the 7.0 release cd and then
upgrade vi csup.


You're covering a multitude of topics in the above.  It's hard to make
out exactly what it is you're trying to say.

First off, I'd like more information on this TCP problems with  
users on
cable modems issue.  I believe you may be referring to TCP  
extensions,

a.k.a. RFC1323 extensions, but I'm not sure.  If so, you can disable
that feature in real-time via a sysctl.  Can you shed some light on  
what

the issue you're referring to is?


From Bjoern A. Zeeb:

You want to update to 7-STABLE which has the TCP fixes or you want to
apply the following changes:

1.141.2.4  +10 -2 src/sys/netinet/tcp_output.c
1.157.2.2  +5 -2 src/sys/netinet/tcp_var.h

In case you are not using MD5 that should be enough. Else see
freebsd-net from the last 3 days for another patch.

There is no sysctl for that.  As I recall it had to do with the order  
that options appeared in a IP SYN packet.  There was a bunch of  
discussion on that in this forum around 3 Apr.







Secondly, 7.0-RELEASE is simply named that way to announce this OS is
now out and available.  Think of it as FreeBSD 7.0 released to the
world for the first time.  Most of the 7.0 changes that are made
*after* 7.0-RELEASE are committed to a CVS branch called RELENG_7.
Shortly after (usually a few days) 7.0-RELEASE is made available to  
the

public, the suffix changes from RELEASE to STABLE.  There is no real
difference between the two, other than STABLE being an even more
up-to-date version of RELEASE, and is regularly updated/maintained.


Unfortunately Stable is not always stable.  It is to some extent  
still being tested.  There used to be a tag to which security and  
stability patches were applied but no major system changes.  My  
recollection is it was RELENG_7.0 but I am not sure about that anymore.





Thirdly, I don't know what you mean by security releases, and what
security issue you're referring to.  Any time there is a security  
hole,

mail is sent to a couple FreeBSD lists, articulating what the hole is,
and what CVS branches the fix has been committed to.  In the case of
7.0, it's going to be committed to RELENG_7, and possibly to  
RELENG_7_0

and other branches.  The main branch people focus on is RELENG_7,
aside from CURRENT which is called HEAD (or . in cvs/supfiles).


Well, there are the security patches for bind 9 that come immediately  
to mind.  I seem to recall reading about others but didn't really keep  
track of them.





Fourthly, what is not made very clear to FreeBSD users is that if they
install src and ports off the CD, that they are missing necessary  
files

in /var/db/sup (or /usr/sup if they choose to use cvsup (not needed
since csup exists in the base system)).  To create the proper
information so the version information matches, you have to do what's
called adopting your existing src-all and ports-all tree:

http://www.cvsup.org/faq.html#adopt

This is one reason why I do not advocate installing src and ports off
the installation media.  Instead, I just leave src and ports unchecked
and install everything else as normal -- then once the OS is  
installed,

use csup to populate /usr/src and /usr/ports, which will also populate
/var/db/sup.  I've never had any versioning mismatches or wild stuff
happen since doing that.


Thats really neat if you have bandwidth to spare.  These are heavily  
used production systems and we don't obtain any extra bandwidth to  
just sit around idle.  Downloading all the source would be a killer  
for our users.  Updates are bad enough.





In your case, the simple solution is (assuming you use csup):

 rm -fr /usr/src /usr/ports /var/db/sup
 csup -h cvsup_server -L2 /usr/share/examples/cvsup/stable-supfile
 csup -h cvsup_server -L2 /usr/share/examples/cvsup/ports-supfile

/usr/share/examples/cvsup/stable-supfile uses the CVS tag RELENG_7,
and ports-supfile uses the CVS tag . (which means HEAD); there is no
RELENG_xxx for ports.

And do not forget to rm -fr /usr/obj before doing a buildworld and
buildkernel, too.

Fifthly, and possibly the ultimate question: what CVS branch are
you

Re: getenv in FreeBSD 7

[Doug Hardie]

On Apr 6, 2008, at 22:38, Jeremy Chadwick wrote:

On Sun, Apr 06, 2008 at 08:18:20PM -0700, Doug Hardie wrote:

On Apr 6, 2008, at 17:54, Jeremy Chadwick wrote:

On Sun, Apr 06, 2008 at 03:05:18PM -0700, Doug Hardie wrote:


On Apr 6, 2008, at 14:52, Jeremy Chadwick wrote:

On Sun, Apr 06, 2008 at 02:45:24PM -0700, Jeremy Chadwick wrote:

On Sun, Apr 06, 2008 at 02:37:06PM -0700, Doug Hardie wrote:

Somewhere between FreeBSD 6.2 and 7.0 getenv has been changed to
return
a
null if an environment variable is set but has no value.  I  
don't find

anything anywhere in the documentation/man pages on this.  As a
result,
you
cannot distinguish between a variable that is not set and one  
that is

set
to a value of .  Is this a bug or a feature change?


I'd begin peeking here:

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/ 
getenv.c


Follow-up: the manpages between 6.3-PRERELEASE and 7.0-STABLE do
document said change:

http://www.freebsd.org/cgi/man.cgi?query=getenvapropos=0sektion=3manpath=FreeBSD+6.3-RELEASEformat=html


Says that if the environment variable is NOT IN THE ENVIRONMENT  
then null
is returned.  Setting the variable to  does put it in the  
environment.

env returns it properly.




http://www.freebsd.org/cgi/man.cgi?query=getenvapropos=0sektion=3manpath=FreeBSD+7.0-stableformat=html


Same thing.  I find nothing documented about this change.


I'm not sure where you're going with this.  I see it clearly in the
ERRORS section.


I didn't think that having a defined variable with the value   
would be an
error.  getenv does not return EINVAL but returns a zero.  I would  
have

expected some notification in the description of getenv.


My apologies: I misread the manpage.  The ERRORS section applies to
setenv(), putenv(), and unsetenv() -- not getenv().  So ignore my
earlier claims about EINVAL being relevant to getenv().

getenv() will either return a pointer to what the environment variable
contains (and if empty (e.g. ), it should stil return a pointer to a
buffer that consists of nothing but NULL), or if getenv() returns NULL
then it means the variable isn't set.


earlier today I definitely saw 0x0 returned for several hours.  Broke  
a bunch of my code.  One was in a core dump, the others were in gdb.   
Now its not doing that.





But besides that, just like Bakul Shah, I cannot reproduce this  
problem:


$ uname -mr
7.0-STABLE amd64
$ gcc -o z z.c
$ ./z
getenv(FOO) = (null)
$ export FOO=yep
$ ./z
getenv(FOO) = yep
export FOO=
$ ./z
getenv(FOO) =
$ cat z.c
#include stdio.h
#include stdlib.h

int main(void)
{
char *e = getenv(FOO);

printf(getenv(FOO) = %s\n, e);
return 0;
}


At this time, it does return a pointer to .  However, earlier  
today it
did not.  It returned a zero.  It was quite consistent for several  
hours.
I wonder if this is another issue with gdb.  It seems to be quite  
flakey on

7.0.


I'd expect there to be an immense amount of random breakage in all
sorts of scripts on a system, ditto with Apache spawning CGIs which  
rely

on environment variables (REMOTE_ADDR comes to mind), if getenv() was
unreliable.  The ports system, for example, relies heavily upon
environment variables.


I have been relying on environment variables since 2.5.  Never had an  
issue till now.  While I do have heavily loaded servers that heavily  
use them, this paticular server is very lightly loaded and rarely uses  
them.





As I was writing this, I was thinking if a local resource starvation
issue could cause this (libc being unable to malloc some memory  
without

a proper failure check, or stack space running out), but after looking
at getenv() and related functions, I don't see how this could be
possible.

The next time it happens, post here with some more details.   
Definitely

a mysterious one...


I agree.  I suspect though that it might be related to gdb.  I can't  
explain the first core dump, but I have encountered enough bugs with  
gdb that I have no problems with it being the cause.


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

getenv in FreeBSD 7

[Doug Hardie]

Somewhere between FreeBSD 6.2 and 7.0 getenv has been changed to  
return a null if an environment variable is set but has no value.  I  
don't find anything anywhere in the documentation/man pages on this.   
As a result, you cannot distinguish between a variable that is not set  
and one that is set to a value of .  Is this a bug or a feature  
change?

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: getenv in FreeBSD 7

[Doug Hardie]

On Apr 6, 2008, at 14:45, Jeremy Chadwick wrote:

On Sun, Apr 06, 2008 at 02:37:06PM -0700, Doug Hardie wrote:
Somewhere between FreeBSD 6.2 and 7.0 getenv has been changed to  
return a
null if an environment variable is set but has no value.  I don't  
find
anything anywhere in the documentation/man pages on this.  As a  
result, you
cannot distinguish between a variable that is not set and one that  
is set

to a value of .  Is this a bug or a feature change?


I'd begin peeking here:

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/getenv.c


Did that prior to my original posting.  I find nothing there on it.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: getenv in FreeBSD 7

[Doug Hardie]

On Apr 6, 2008, at 17:54, Jeremy Chadwick wrote:

On Sun, Apr 06, 2008 at 03:05:18PM -0700, Doug Hardie wrote:


On Apr 6, 2008, at 14:52, Jeremy Chadwick wrote:

On Sun, Apr 06, 2008 at 02:45:24PM -0700, Jeremy Chadwick wrote:

On Sun, Apr 06, 2008 at 02:37:06PM -0700, Doug Hardie wrote:
Somewhere between FreeBSD 6.2 and 7.0 getenv has been changed to  
return

a
null if an environment variable is set but has no value.  I  
don't find
anything anywhere in the documentation/man pages on this.  As a  
result,

you
cannot distinguish between a variable that is not set and one  
that is

set
to a value of .  Is this a bug or a feature change?


I'd begin peeking here:

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdlib/getenv.c


Follow-up: the manpages between 6.3-PRERELEASE and 7.0-STABLE do
document said change:

http://www.freebsd.org/cgi/man.cgi?query=getenvapropos=0sektion=3manpath=FreeBSD+6.3-RELEASEformat=html


Says that if the environment variable is NOT IN THE ENVIRONMENT  
then null
is returned.  Setting the variable to  does put it in the  
environment.

env returns it properly.




http://www.freebsd.org/cgi/man.cgi?query=getenvapropos=0sektion=3manpath=FreeBSD+7.0-stableformat=html


Same thing.  I find nothing documented about this change.


I'm not sure where you're going with this.  I see it clearly in the
ERRORS section.


I didn't think that having a defined variable with the value  would  
be an error.  getenv does not return EINVAL but returns a zero.  I  
would have expected some notification in the description of getenv.





But besides that, just like Bakul Shah, I cannot reproduce this  
problem:


$ uname -mr
7.0-STABLE amd64
$ gcc -o z z.c
$ ./z
getenv(FOO) = (null)
$ export FOO=yep
$ ./z
getenv(FOO) = yep
export FOO=
$ ./z
getenv(FOO) =
$ cat z.c
#include stdio.h
#include stdlib.h

int main(void)
{
 char *e = getenv(FOO);

 printf(getenv(FOO) = %s\n, e);
 return 0;
}


At this time, it does return a pointer to .  However, earlier today  
it did not.  It returned a zero.  It was quite consistent for several  
hours.  I wonder if this is another issue with gdb.  It seems to be  
quite flakey on 7.0.





Finally, why did you take freebsd-stable off this mail  
conversation?  If

others have the same question in the future, they're not going to be
able to read what partook here.  I'm re-adding the list.


Thought I did include it.  Must have used reply instead of reply all.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Access Problems with 7.0

[Doug Hardie]

I recently upgraded 3 of my 5 servers to 7.0.  Two of them are on new  
hardware and one is on hardware that used to run 6.2.  Since then, 2  
of my thousands of users are unable to access the servers running  
7.0.  They can access the server running 6.2 just fine.  What happens  
is the server receives the SYN packet from the client properly and  
then responds with the SYN packet.  Nothing more is heard from the  
client.  The server sends a few duplicates of the SYN and then drops  
the connection.


At this point I am not able to verify that the client receives the  
SYN.  Neither of them has a clue about tcpdump.  The packets look fine  
on this end (included later).  Both are using Windows, including XP  
and Vista.  I suspect they are receiving it and not accepting it for  
some reason.  However, I don't really see anything that would cause  
that behavior in the packets.  I can't reproduce the problem here.   
Every computer I can try works just fine.


Here is one of the packet traces:

11:59:00.630414 00:00:0c:38:6f:e1 (oui Cisco)  00:a0:cc:3e:87:9e (oui  
Unknown), ethertype IPv4 (0x0800), length 66:  
cpe-76-169-78-119.socal.res.rr.com.59025  zool.lafn.org.8000: S  
2779920420:2779920420(0) win 8192 mss 1460,nop,wscale 2,nop,nop,sackOK


11:59:00.630634 00:a0:cc:3e:87:9e (oui Unknown)  00:00:0c:38:6f:e1  
(oui Cisco), ethertype IPv4 (0x0800), length 66: zool.lafn.org.8000   
cpe-76-169-78-119.socal.res.rr.com.59025: S
2480373222:2480373222(0) ack 2779920421 win 65535 mss 1460,nop,wscale  
3,sackOK,eol


11:59:03.613011 00:00:0c:38:6f:e1 (oui Cisco)  00:a0:cc:3e:87:9e (oui  
Unknown), ethertype IPv4 (0x0800), length 66:  
cpe-76-169-78-119.socal.res.rr.com.59025  zool.lafn.org.8000: S  
2779920420:2779920420(0) win 8192 mss 1460,nop,wscale 2,nop,nop,sackOK


11:59:03.613194 00:a0:cc:3e:87:9e (oui Unknown)  00:00:0c:38:6f:e1  
(oui Cisco), ethertype IPv4 (0x0800), length 66: zool.lafn.org.8000   
cpe-76-169-78-119.socal.res.rr.com.59025: S 2480373222:2480373222(0)  
ack 2779920421 win 65535 mss 1460,nop,wscale 3,sackOK,eol


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Access Problems with 7.0

[Doug Hardie]

I recently upgraded 3 of my 5 servers to 7.0.  Two of them are on  
new hardware and one is on hardware that used to run 6.2.  Since  
then, 2 of my thousands of users are unable to access the servers  
running 7.0.  They can access the server running 6.2 just fine.   
What happens is the server receives the SYN packet from the client  
properly and then responds with the SYN packet.  Nothing more is  
heard from the client.  The server sends a few duplicates of the SYN  
and then drops the connection.


At this point I am not able to verify that the client receives the  
SYN.  Neither of them has a clue about tcpdump.  The packets look  
fine on this end (included later).  Both are using Windows,  
including XP and Vista.  I suspect they are receiving it and not  
accepting it for some reason.  However, I don't really see anything  
that would cause that behavior in the packets.  I can't reproduce  
the problem here.  Every computer I can try works just fine.


Here is one of the packet traces:

11:59:00.630414 00:00:0c:38:6f:e1 (oui Cisco)  00:a0:cc:3e:87:9e  
(oui Unknown), ethertype IPv4 (0x0800), length 66:  
cpe-76-169-78-119.socal.res.rr.com.59025  zool.lafn.org.8000: S  
2779920420:2779920420(0) win 8192 mss 1460,nop,wscale  
2,nop,nop,sackOK


11:59:00.630634 00:a0:cc:3e:87:9e (oui Unknown)  00:00:0c:38:6f:e1  
(oui Cisco), ethertype IPv4 (0x0800), length 66: zool.lafn.org.8000  
 cpe-76-169-78-119.socal.res.rr.com.59025: S
2480373222:2480373222(0) ack 2779920421 win 65535 mss  
1460,nop,wscale 3,sackOK,eol


11:59:03.613011 00:00:0c:38:6f:e1 (oui Cisco)  00:a0:cc:3e:87:9e  
(oui Unknown), ethertype IPv4 (0x0800), length 66:  
cpe-76-169-78-119.socal.res.rr.com.59025  zool.lafn.org.8000: S  
2779920420:2779920420(0) win 8192 mss 1460,nop,wscale  
2,nop,nop,sackOK


11:59:03.613194 00:a0:cc:3e:87:9e (oui Unknown)  00:00:0c:38:6f:e1  
(oui Cisco), ethertype IPv4 (0x0800), length 66: zool.lafn.org.8000  
 cpe-76-169-78-119.socal.res.rr.com.59025: S  
2480373222:2480373222(0) ack 2779920421 win 65535 mss  
1460,nop,wscale 3,sackOK,eol




Checking with the 6.2 server I see there are some differences in the  
TCP options.  7.0 includes wscale 3 where 6.2 does not.  Is there a  
way to disable that feature using sysctl to see if thats the issue?

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

FreeBSD 7.0 Questions

[Doug Hardie]

I have just installed 7.0 on some new hardware.  Have never tried  
earlier versions.  There are a couple of unexpected items that I do  
not understand.


1.  When booting there are a few messages like:
acd0: TIMEOUT - READ_BIG retrying

When the system is booted off CD (like installation disk), it  
takes about 10 minutes
after these messages first appear and then it finally starts up  
sysinstall properly.


After the system is installed on disk, it reboots and just  
continues on past those
messages with no delays.  Sometimes those messages do not appear  
in dmesg.boot.


Why are there long delays when booting from CD?

2.  I have 2 SATA drives in the system.  The first is recognized as  
ad10 and the second as
ad12.  I expected to see ad0 and ad1. 
 
___

freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: /boot size in 7.0 beta3

[Doug Hardie]

On Dec 7, 2007, at 02:25, Andrey V. Elsukov wrote:


Doug Hardie wrote:
Between 6.2 and 7 /boot has grown from 45 MB to 114 MB.  That poses  
a significant issue for those of us who have been running  
production systems for many years.  I have the root partition set  
to 200 MB which has been more than enough.  Its no longer usable.   
7.0 beta will not install properly as it runs out of space.   
Basically this forces you to repartition the drive.  That requires  
an extensive down time for servers.  Far beyond what I can justify  
to users.


src/UPDATING:
20060118:
  This actually occured some time ago, but installing the kernel
  now also installs a bunch of symbol files for the kernel modules.
  This increases the size of /boot/kernel to about 67Mbytes. You
  will need twice this if you will eventually back this up to
  kernel.old on your next install.
  If you have a shortage of room in your root partition, you
  should add -DINSTALL_NODEBUG to your make arguments or add
  INSTALL_NODEBUG=yes to your /etc/make.conf.


Thanks.  That must have been after 6.2 came out as I never had that  
occur with it.  Anyway, since I am installing from CD I discovered  
that during the install, VT4 has a working shell that lets you cd to / 
boot/GENERIC and delete the symbol files before the disk overflows.  I  
will have to add the line above to make.conf though as I do minor  
updates from the source.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

/boot size in 7.0 beta3

[Doug Hardie]

Between 6.2 and 7 /boot has grown from 45 MB to 114 MB.  That poses a  
significant issue for those of us who have been running production  
systems for many years.  I have the root partition set to 200 MB which  
has been more than enough.  Its no longer usable.  7.0 beta will not  
install properly as it runs out of space.  Basically this forces you  
to repartition the drive.  That requires an extensive down time for  
servers.  Far beyond what I can justify to users.


Also, 7.0 beta3 has login compiled with libutil.so.5 and libc.so.6  
neither of which are on the distribution cd.  I had to point those to  
the existing libs to get login to work.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ntpd just sits there and does nothing

[Doug Hardie]

On Jul 19, 2007, at 10:08, [LoN]Kamikaze wrote:

As the subject says, on my 6-stable systems ntpd just sits there  
and does
nothing. The logs only mention when the daemon gets started or shut  
down. It
complains when servers are not reachable, but does nothing when  
they are available.


The drift file always contains 0.00.

ntpdate and openntpd both successfully manage to set the time, so I  
suppose

it's a problem with ntpd.


Are you on a static IP address?  If not, ntpd obtains its IP address  
when it starts up and uses it forever.  If your IP address changes  
then it will not be able to communicate with the upstream ntp  
servers.  It has to be restarted everytime your IP address changes.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

installworld in 6.2

[Doug Hardie]

I have found what I believe is a bug in installworld for FreeBSD  
6.2.  I do not believe this was in 6.1 as I would have encountered  
the same problem there.  I run a number of production servers.  I  
maintain the source on one development machine where it is built and  
tested.  To upgrade a production server I NIS mount /usr/src and /usr/ 
obj then run the commands per UPDATING.  The problem occurs now  
because my development machine has /usr on a slice on the same disk  
as /.  However, /usr/obj is a soft link to /usr2 which is a separate  
drive.  There was not enough space on the primary drive for  
everything and I really don't need to backup /usr/obj as it can  
easily be rebuilt.


During make installworld when it gets to the /boot section I get an  
error that it cannot make a library in /usr2/obj/src.  Everything  
quits at that point.  My production machines do not have a /usr2  
filesystem.  In order to get installworld to work I had to add a soft  
link on the production server of /usr2 pointing to /usr.  Then  
installworld completed properly.  I don't believe that link should be  
needed. 
 
___

freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD Security Survey

[Doug Hardie]

On May 21, 2006, at 22:41, David Nugent wrote:


A good failover strategy comes into play here.

If you have one, then taking a single production machine off-line  
for a short period should be no big deal, even routine, and should  
not even be noticed by users if done correctly.  This should be  
planned for and part of the network/system design. Yes, it  
definitely requires more resources to support, but I'll rephrase  
the same problem: what happens when (and I mean *when* and not  
*if*) a motherboard or network card fries or you suffer a hard disk  
crash (even 2+ drives failing at the same time on a raid array is  
not particularly unusual considering that drives are quite often  
from the same manufactured batch)?


Lack of a failover on mission critical systems that *can't* be  
offline is like playing russian roulette.


Failover sounds good in theory but has significant issues in practice  
that make it sometimes worse than the alternative.  Take mail  
spools.  If you failover, mail the user saw before has disappeared.   
Then when you fail back it reappears and newer messages disappear.   
This is hardly unnoticable.  My users do not find that at all  
acceptable.  Putting the mail spools on a different machine just  
moves that problem to the different machine.  Trying to keep multiple  
spools consistent has problems also.  I have watched raid system lose  
their data too.  A nice power spike - 1.5Kv from a lightning strike  
in the local area will do it.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD Security Survey

[Doug Hardie]

On May 21, 2006, at 20:55, Colin Percival wrote:

If you administrate system(s) running FreeBSD (in the broad sense  
of are
responsible for keeping system(s) secure and up to date), please  
visit

  http://people.freebsd.org/~cperciva/survey.html
and complete the survey below before May 31st, 2006.



What doesn't fit into the survey very well is that all my servers are  
production ones and it causes a lot of grief for users when I bring  
them down.  I try to hold updates to once per year because of that.   
I am currently in the middle of upgrading from 5.3 to 6.0.  The easy  
machines are done but there are still a few that will take  
considerable on-site time which is not easy to come by.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: RELENG_4 - 5 - 6: significant performance regression

[Doug Hardie]

On Apr 27, 2006, at 11:12, Kris Kennaway wrote:


On Thu, Apr 27, 2006 at 05:08:11PM +0300, Dmitry Pryanishnikov wrote:


options QUOTA


This definitely effects performance on 6.x since it makes your
filesystem giant-locked, which may also interfere with your network
processing.


Any indications when this will be fixed?  I need quota for user's files.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: cron jobs running 6 times

[Doug Hardie]

On Apr 5, 2006, at 16:28, jason wrote:



On Wed, 5 Apr 2006, Chris wrote:


Some possible clarity? Are there other user crontabs running?


Nope.  It's basically a single-user system.


You might want to check the start times for those processes with the  
cron log.  That may give some clues.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: FreeBSD 2.2.9 Released

[Doug Hardie]

On Apr 2, 2006, at 12:22, Holger Kipp wrote:


On Sat, Apr 01, 2006 at 01:25:59PM -0700, Scott Long wrote:

It is my great pleasure and privilege to announce the availability of
FreeBSD 2.2.9-RELEASE.  This release is the culmination of SEVENTY- 
SEVEN
months of tireless work by the FreeBSD developers, users, their  
children,

and their pets.  Significant features in this release:


Ah, at last I can upgrade my old 2.2.8 without hassle. A minor note  
(maybe
I am getting this wrong): my 2.2.8 is from January 1999, so  
shouldn't this

be 87 months instead of 77?


The developers were afraid that 2.2.8 might not be solid, so they  
decided to wait 10 months before updating any of the development or  
test machines until those using it in production had time to find all  
the bugs.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Inode Usage

[Doug Hardie]

I am building a tool to identify the file that has a specific LBA.   
The approach I am using is to search through each inode from number 2  
up.  This approach works well with UFS1 file systems as then  
preinitialize all the inodes.  However, UFS2 does lazy inode  
initialization so there are always some that are basically garbage.   
I have not found any relaiable way to determine from the inode  
contents if it is in use or not.  I suspect that information is in  
the inode bit map.  However, I haven't found any way to access that.   
Nothing in ffs.h seems to fit the need.  Is there a way to tell if  
inode x is initialized or in use?

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Failed disk sectors

[Doug Hardie]

I have a large disk that has several failed sectors.  The drive  
basically is the article storage for news so it has lots of files.   
Basically the error messages I get during the inn expire operation is  
there are a couple failed sectors where the drive cannot successfully  
read the sectors.  The LBA is given.  The problem is finding out what  
those LBA's are used for.


The drive SMART status show plenty of available spare sectors, but  
since it can't read those sectors it won't remap them to a spare  
sector till the next write of that sector.  expire basically gives up  
when it reaches that error.  So my first attempt was to run a cksum  
of all the files on the disk.  That actually cought one of the  
sectors and gave me the file name.  I deleted the file and since it  
was an overview file for one group, I just rebuilt it.  There are  
still more to go though.  That process took many hours.


I have not found anything in the archives or man pages or ports that  
addresses identifying the object/file that has that LBA.  So I have  
started looking into the ufs structures to see how that could be  
done.  fdisk source shows how to access the partition data.  For the  
specific disk, fdisk reports a media sector size of 512 and the block  
count matches that.  So I assume I would have to subtract the start  
of that partition from the LBA.  However, that assumes that the LBA  
is in the same 512 byte block numbering system.  I am not convinced  
that would always be correct.


Next has to address the bsdlabel.  I am now presuming that the LBA  
value of 0 is the start of the drive, not the start of the  
partition.  I am not sure if this is correct either.  If so, then  
bsdlabel type code would be required to identify the partition.  Then  
the start of the partition would need to be subtracted from the LBA.   
At that point I think I have the values that would be found in the  
block tables in the inodes.


Before digging into the inode structures I though it would be a good  
idea to check my understanding to this point.  Am I on the right path?

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [HEADS UP] perl symlinks in /usr/bin will be gone

[Doug Hardie]

On Jan 30, 2005, at 12:17, Kris Kennaway wrote:
On Sun, Jan 30, 2005 at 02:47:08PM +0100, Matthias Andree wrote:
Kris Kennaway [EMAIL PROTECTED] writes:
In other words, it's an impossible dream to hope that all scripts 
will
conform to this or any of the other possible choices (remember the
perl motto).  Even making everything perl in the ports collection use
a uniform style is probably an infeasible task (recall 840 ports use
/usr/bin/perl, and that's not counting the others that use another
hardcoded variant of /usr/local/bin/perl).
Well, broken ports are marked broken and removed after some months.
How would broken Perl ports justify special treatment?
As I mention above, it's a rule that would be impossible to enforce on
third party scripts, so it would be wasted effort to try.
Many years ago in a far off version, perl was a port and all my loyal 
subjects worked in peace and harmony.  However, someone changed perl to 
be part of the base system.  My subjects rebelled and refused to work 
saying the the perl of great price could no longer be found.  After 
many hours of chasing this perl and correcting its location my subjects 
returned to work, and peace and harmony reigned again.  Now I see perl 
going back towards being a port.  This realm is not looking forward to 
another strike by its subjects.  The grocery store strike here was more 
than enough.  Don't need any more of them.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: NIC acting promiscuously -- how to fix?

[Doug Hardie]

On Tue, Jan 25, 2005 at 10:43:01AM -0800, Rich Wales wrote:
I'm running 5.3-RELEASE-p5 on a system that is functioning as a
NAT router/firewall using pf.  It works just fine, but . . . .
The external (Internet) network connection is giving me incoming
traffic addressed to other users all over my neighborhood (not
just the packets intended for me).  The external NIC (an Accton
MPX 5030/5038, handled via the rl driver) appears to be running
promiscuously; it's accepting all these incoming packets, whether
addressed to me or not.
How are you determining that?  If you are using tcpdump without the -p 
then keep in mind it will put the interface into promiscous mode and 
you will see everything on the network regardless of who its addressed 
to.  To verify what your interface is accepting use:

tcpdump -pei rl0
That will show the packets that it accepts including the ethernet 
headers.  Those headers should all have your MAC address in them (send 
or receive).

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]

VM errors

[Doug Hardie]

I am getting a rash of vm errors that started a couple days ago - 
FreeBSD 4.6:

 vm_page_cache: attempting to cache busy page


I don't seem to find anything obviously wrong in the system.  How do I 
tell which process is causing the problem?  It looks like something is 
hung, but I don't see any obvious candidates.  Everything is working
file and there are no obviously hung processes.  The vm_page_cache 
module shows that the indicated condition is occuring, but no 
additional info.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message

Re: NIS server status

[Doug Hardie]

At 15:10 +0200 6/12/02, Thomas Quinot wrote:
Le 2002-06-12, Doug Hardie écrivait :

  ypbind, to not create a pid file.  I have a process that periodically
  checks the important server pid files and makes sure the process is
  still allive.  It then pages me if the process has died.  That would
  be really helpful for ypserv and ypbind if they would create a pid
  file once they are up and running correctly.

Why not use something along the line of:
   ps ax|grep ypserv|grep -v grep  /dev/null || ypserv
from a crontab entry?

Most servers create a pid file.  It would be nice for there to be
consistency in this.
--
-- Doug

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message

Re: NIS server status

[Doug Hardie]

I don't know if this is the best place to send this, but I just 
encountered a problem that took a long time to diagnose.  I believe 
the cause was ypserv terminating.  It was definitely gone and when I 
restarted it, things worked properly again.  However, ypserv, and 
ypbind, to not create a pid file.  I have a process that periodically 
checks the important server pid files and makes sure the process is 
still allive.  It then pages me if the process has died.  That would 
be really helpful for ypserv and ypbind if they would create a pid 
file once they are up and running correctly.
-- 
-- Doug

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message

Re: serial console

[Doug Hardie]

At 9:24 +1000 10/18/01, Gregory Bond wrote:
If this is an old machine that was installed with an old version and
has been upgraded, then you will probably be running the original boot blocks.
Try installing the latest boot blocks with disklabel.

I see in the source that boot2 reads the /boot.config file.  Since it 
basically prints a line immediately after reading a command and I am 
not seeing that line, I suspect boot2 is not being used.  Here is 
what I see during the boot.

BIOS stuff  ends with:

Verifying DMI Pool Data ...

F1FreeBSD
F5 Drive 1

Default:  F1

-


It then sits there for a minute or so.  If I type a key then I get

  FreeBSD/i386 BOOT
Default: 0:ad(0,a)/boot/loader
boot:

entering a -h there causes the serial console to work.

If I don't type a key then I get:

BTX loader 1.00 BTX version is 1.01
Console:  internal video/keyboard
etc.

-- 
-- Doug

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message

Building Ports

[Doug Hardie]

I just heard a most interest tale of woe.  A new user installing 
4.3-Release wanted some ports.  I gave him specific instructions, in 
writing, on how to build those ports.  For some reason he ignored the 
step to cd to the specific port and did essentially:

cd /usr/ports
make

The system dutifully started making all the ports in alphabetical 
order for quite a few hours until he finally ran out of disk space. 
Is this feature really useful or something that is a byproduct of 
useful features?  I ask to be sure that there was a delebriate 
decision for this to happen.
-- 
-- Doug

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message

Re: tcpdump problem with 4.3-Release

[Doug Hardie]

At 22:56 -0700 5/14/01, Christopher Shumway wrote:
On Mon, 14 May 2001, Doug Hardie wrote:

  Thats the mode it seems to be in without that argument.  Packets go
  through the system for some time, then you get a bunch listed.  It
  used to output a line when the packet occurred.

Perhaps tcpdump is spending extra time doing DNS resolution on the packets?
You might try tcpdump with the -n option.

---
Christopher Shumway   [EMAIL PROTECTED]
   [EMAIL PROTECTED]

Right on.  That is the problem.  Thanks, now I got to chase that problem
-- 
-- Doug

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message

Re: serial console

[Doug Hardie]

How are you preventing unauthorized access via the PM2?  I haven't 
found any way to prevent it.

At 16:04 -0700 5/14/01, Jason DiCioccio wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've found the Portmaster 2E to be quite good at this too :)..

- - Original Message -
From: Nick Barnes [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, May 14, 2001 12:40 PM
Subject: serial console


  I have received several individual replies to this message, asking
  for more details of setting up a serial console.  I haven't
  actually done this myself since 2.2.5 (or maybe 2.2.8), and the
  procedure has
  changed a little since then.  I refer people to the relevant
  section of the handbook:

  URL:
  http://www.freebsd.org/doc/en_US.ISO_8859-1/books/handbook/serialcon
  sole-setup.html 

  It's easy, and I strongly recommend it for remote FreeBSD machines,
  assuming you can get at least _some_ other hardware colocated.  For
  instance, you can get a terminal server: a little black box which
  converts a number of serial lines into TCP/IP connections.  That
  lets you drive serial console for a number of boxes at once,
  without having to remember that console on foo is cuaa0 on bar,
  etc. I have used a 16-port Digiboard Portserver (now gathering
  dust) for this purpose in the past.

  It goes without saying that you should choose good-quality kit for
  remote located machines.  For instance, don't use anything which
  doesn't come up reliably first time from a power cycle.

  Nick B

   From: Nick Barnes [EMAIL PROTECTED]
   To: [EMAIL PROTECTED] [EMAIL PROTECTED]
   Subject: Re: Running Stable on remote production server
   Date: Mon, 14 May 2001 09:48:46 +0100
   Message-ID: [EMAIL PROTECTED]
  
   If you have more than one machine at the same remote site, then I
   recommend setting up each as the serial console for the other.
   That way you can go single-user, drive fsck, etc etc.
  
   Nick B
  
   At 2001-05-13 20:36:40+, Juha Saarinen writes:
On Sun, 13 May 2001, Mike Smith wrote:
   
 It's entirely unnecessary to go single-user when updating a
 machine; just rebuild the world, optionally run mergemaster,
 and reboot.

 Exceptions to this rule do occur, but they're *extremely*
 rare.
   
Having rebuilt a number of machines remotely in the last couple
of weeks, I have to concur...
   
The most important thing is to pay attention to mergemaster,
PLUS doing a final check of vital rc and other conf files in
/etc BEFORE rebooting. 
   
On one site I had the local admin unplug the network cable
after the box was shifted into the server room -- I was trying
to figure out what I had done wrong until it occured to me to
ask if the system was connected to the LAN. His answer was
priceless... why do you have to have a network connection?
Can't you get at the box remotely? ;-D
   
--
Regards,
   
   
Juha
   
PGP fingerprint:
B7E1 CC52 5FCA 9756 B502  10C8 4CD8 B066 12F3 9544
   
   
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
   
   
  
   To Unsubscribe: send mail to [EMAIL PROTECTED]
   with unsubscribe freebsd-stable in the body of the message

  To Unsubscribe: send mail to [EMAIL PROTECTED]
  with unsubscribe freebsd-stable in the body of the message


-BEGIN PGP SIGNATURE-
Version: PGPfreeware 7.0.3 for non-commercial use http://www.pgp.com

iQA/AwUBOwBkY1CmU62pemyaEQJimwCg3xJi5Mk207txA7nuMMgMy7mympYAn3WX
w4hmaGMSfVhbyxdg1N85L3Uh
=9zZQ
-END PGP SIGNATURE-



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message

-- 
-- Doug

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message

tcpdump problem with 4.3-Release

[Doug Hardie]

Is there a problem with tcpdump on 4.3-Release?  On a system with 
very low packet rates, tcpdump never displays any packets.  Its as if 
its in buffered mode.  Eventually it will show traffic, but it 
appears that some of the packets are not actually displayed.  On a 
system with lots of traffic, you see packets much faster, but they 
still look a bit sparce.  ntop never sees anything on the low traffic 
system.
-- 
-- Doug

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message