Re: Deprecating base system ftpd
On Fri, 09 Apr 2021 07:32:12 +0900 aventa...@fastmail.fm wrote:
>It makes me think that there should be an offering for two completely
>different audiences:
>(1) FreeBSD core (a very minimal offering for folks that want to build things,
>like a Desktop, etc.)
>(2) FreeBSD server (an offering for folks that want a server build)
>
>Perhaps that idea is just unreasonably crazy as well.
>
LOL! You have what is called a very big ask. I would like
something far smaller, namely, a choice of schedulers during/just
after installation of a -RELEASE without having to a) download the
entire source tree, b) make buildworld, and c) make buildkernel.
The kernel developers in their wisdom--ahem--have burdened all new
installations with the abysmal performance of the ULE scheduler.
The installation images for -STABLE versions are much the same.
The 4BSD scheduler has been far from optimal, and the ULE scheduler
looked like a nice idea on paper for newer CPUs, but in fact, the
ULE scheduler's performance is awful, even when compared with the
4BSD scheduler, which generally gives acceptable, though not optimal,
performance.
If the owner of a new installation wants to get passably usable
performance from his new system, he must first perform the tasks
noted above. The second and third tasks will take *a lot* of extra
time because they must be done under the ULE scheduler. Then one
must install the new kernel, reboot, do the mergemaster or /etc/update
steps, install the new world, more mergemaster or /etc/update, and
reboot again.
Two ways of allowing a choice of scheduler are 1) to provide two
GENERIC kernels, e.g., GENERIC.ULE and GENERIC.4BSD, from which one
could choose at boot time, and 2) to compile both schedulers into the
GENERIC kernel, which could be selected from by a loader tunable at
boot time.
The current system is yet another discouragement to upgrading to
a new -RELEASE via a new installation. Further, this fix to bad
performance by default is not documented anywhere. How is a user who
is new to FreeBSD to know about it?
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
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: Vinum deprecation for FreeBSD 14 - are there any remaining Vinum users?
Eugene Grosbein wrote: > 07.04.2021 12:49, Scott Bennett via freebsd-stable wrote: > > > At least w.r.t. gvinum's raid5, I can attest that the kernel panics > > are real. Before settling on ZFS raidz2 for my largest storage pool, I > > experimented with gstripe(8), gmirror(8), graid3(8), and graid5(8) (from > > sysutils/graid5). All worked reasonably well, except for one operation, > > namely, "stop". Most/all such devices cannot actually be stopped because > > a stopped device does not *stay* stopped. As soon as the GEOM device > > node is destroyed, all disks are retasted, their labels, if any, are > > recognized, and their corresponding device nodes are recreated and placed > > back on line. :-( All of this happens too quickly for even a series of > > commands entered on one line to be able to unload the kernel module for > > the device node type in question, so there is no practical way to stop > > such a device once it has been started. > > In fact, you can disable re-tasting with sysctl kern.geom.notaste=1, > stop an GEOM, clear its lables and re-enable tasting setting > kern.geom.notaste=0 back. Thank you for this valuable, but undocumented, workaround! However, it serves to demonstrate the bugs in gstripe(8), gmirror(8), graid3(8), and graid5(8), and perhaps a few others, either in the commands themselves, which do not behave as advertised in their respective man pages or in their man pages for not correctly documenting the commands' actual behavior. > > > A special note is needed here regarding gcache(8) and graid3(8). The > > documentation of gcache parameters for sector size for physical devices > > and gcache logical devices is very unclear, such that a user must have the > > device nodes and space on them available to create test cases and do so, > > whereas a properly documented gcache(8) would obviate the need to set up > > such experiments. There is similar lack of clarity in various size > > specifications for blocks, sectors, records, etc. in many of the man pages > > for native GEOM commands. > > I found gcache(8) very nice at first, it really boosts UFS performance > provided > you have extra RAM to dedicate to its cache. gcache can be stacked with > gmirror etc. > but I found it guilty to some obscure UFS-related panics. It seems there were > races or something. > No data loss, though as it is intended to be transparent for writing. There are other, also undocumented, problems. For example, I played with gcache(8) for a short time as a method of dividing a ZFS pool into two extents on a drive in order to place a frequently accessed partition between them. It worked nicely for a while, but the first time that gcache(8) choked it made a real mess of the ZFS pool's copy on that drive. As a result I immediately abandoned that use of gcache(8). gcache(8) usses two poorly defined sysctl values, kern.geom.cache.used_hi and kern.geom.cache.used_lo. Its man page shows them with default values, but neglects to mention whether they are enforced limits or merely sysctl variables that report current or high and low watermark usages. > > I was forced to stop using gcache for sake of stability and it's a shame. > For example, dump(8) speed-up due to gcache was 2x at least with big cache > comparing to dump -C32 without gcache. > I used it to make all accesses to a graid3(8) set of partitions work with 64 KB and 32 KB block sizes for UFS2 efficiency on a graid3(8) device. That use worked very nicely, but it took some experimentation to figure out how to do it because the man page is so ambiguous about the gcache command's options and arguments. A similar complaint could be leveled at the man pages for gstripe(8), graid3(8), and graid5(8) w.r.t. their undocumented definitions of stripe size, sector size, and block size. At present, without reading the command and kernel source code for each or experimenting extensively, it is difficult to understand what the commands' options and arguments will do and which combinations of their numerical values can be valid and accepted. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: Vinum deprecation for FreeBSD 14 - are there any remaining Vinum users?
otentially large number of situations for some users, especially for data recovery, but that is a different purpose from that for which the other GEOM RAID commands were written to serve. Again, IMO, gstripe(8), gmirror(8), graid3(8), and graid5(8) from sysutils/graid5 should be improved, not eliminated. Anything gvinum(8) is *supposed* to be able to do, but often cannot do without violating other system functions, can be done well by these other GEOM commands. A special note is needed here regarding gcache(8) and graid3(8). The documentation of gcache parameters for sector size for physical devices and gcache logical devices is very unclear, such that a user must have the device nodes and space on them available to create test cases and do so, whereas a properly documented gcache(8) would obviate the need to set up such experiments. There is similar lack of clarity in various size specifications for blocks, sectors, records, etc. in many of the man pages for native GEOM commands. While you are looking into this situation, please also consider that deprecation and elimination of the veritably ancient ccd and ccdconfig are long overdue. Even the man pages state that these device nodes are *not* robust and data can be easily lost. The fact that NetBSD separately maintains some version of ccd and ccdconfig should be considered irrelevant in deciding to deprecate and/or eliminate the supporting code from the source tree. > >I plan to add a deprecation notice after a short discussion period, >assuming no reasonable justification is made to retain it. The notice >would suggest graid and ZFS as alternatives, and would be merged in >advance of FreeBSD 13.1. Then, gvinum would be removed in advance of >FreeBSD 14.0. > >Please follow up if you have experience or input on vinum in FreeBSD, >including past use but especially if you are still using it today and >expect to continue doing so. Given the panics and other problems with gvinum(8), I cannot recommend that anyone use it. After experimenting with it, I ended up using ZFS, gmirror(8), graid5(8), and gconcat(8) to meet my needs. In sum, I recommend maintaining and enhancing to some degree the native GEOM support and letting unfinished and/or unmaintained support for gvinum(8), ccd(8) (and ccd(4)), and ccdconfig(8) be abandoned. Please reverse the deprecation for sysutils/graid5, which actually works as specified, and complete its man page. Please also add a scrub function to it. RAID5, whether by hardware or by software, has known limitations, but for some purposes it is not only adequate, but is a better choice than ZFS. GEOM-based RAID support is also much for versatile and flexible than hardware RAID, so let's keep it available as an option. At the same time, the poorly supported, obsolete, and incompatible-with- other-system-components stuff should rightly be eliminated from the source tree. The few known bugs with the native GEOM commands can and should be fixed. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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 space issues
Don Wilde wrote: > > On 7/11/20 11:28 PM, Scott Bennett via freebsd-stable wrote: > > I have read this entire thread to date with growing dismay, and I > > thank Donald Wilde for reporting his ongoing troubles, although they > > spoil my hopes that the kernel's memory management bugs that first became > > apparent in 11.2-RELEASE (and -STABLE around the same time) were not > > propagated into 12.x. A recent update to stable/12 source tree made it > > finally possible for me to build 12.1-STABLE under 11.4-PRERELEASE, and I > > was just about to install the upgrade when this thread appeared. > Spoiler alert. Since I gave up on Synth, I haven't had a single swap > issue. It does appear to be one particular port that drove it nuts > (apparently, one of the 'Google performance' bits, with a > mismatched-brackets problem). I have rebuilt the machine several times, > but that's more for my sense of tidiness than anything. > > I've got a little Crystal script that walks the installed packages and > ports and updates them with system() calls. > The machine is very slow, but it's not swapping at all. That's good. I use portmaster, but not often at present because a "portmaster -a" run can only be done two or three times per boot before real memory is locked down to the extent that the system is no longer functional (i.e., even a scrub of ZFS pools comes to a halt in mid scrub due to lack of a sufficient supply of free page frames). The build procedures of certain ports consistently get killed by the OOM killer, along with much collateral damage. I've noticed that lang/golang and lang/rust are prime examples now, although both used to build without problems. > > It is quite usable now with 12-STABLE. I don't see any good reason to go through the hassle and lost time of an upgrade across a major release boundary if I still won't have a production OS afterward. I'm already dealing with a graphics stack rendered unsafe to use by the ongoing churn in X11 code. (See PR #247441, kindly filed for me by Pau Amma.) > > > > On Fri, 26 Jun 2020 03:55:04 -0700 : Donald Wilde > > wrote: > > > >> On 6/26/20, Peter Jeremy wrote: > >>> > [snip] > >>> I strongly suggest you don't have more than one swap device on spinning > >>> rust - the VM system will stripe I/O across the available devices and > >>> that will give particularly poor results when it has to seek between the > >>> partitions. > > True. The only reason I can think of to use more than one swapping/ > > paging area on the same device for the same OS instance is for emergencies > > or highly unusual, temporary situations in which more space is needed until > > those situations conclude. and even in such situations, if the space can be > > found on another device, it should be placed there. Interleaving of swap > > space across multiple devices is intended as a performance enhancement > > akin to striping (a.k.a. RAID0), although the virtual memory isn't > > necessarily always actually striped across those devices. Adding a paging > > area on the same device as an existing one is an abhorrent situation, as > > Peter Jeremy noted, and it should be eliminated via swapoff(8) as soon as > > the extraordinary situation has passed. N.B. the GENERIC kernel sets a > > limit of four swap devices, although it can be rebuilt with a different > > limit. > That's good data, Scott, thanks! The only reason I got into that > situation of trying to add another swap device was that it was crashing > with OO swap messages. I don't recall you posting those messages, but it sounds like exactly the *temporary* situation in which adding an inappropriately placed paging area can be used long enough to get you out of a bind without a reboot, even though performance will probably suffer until you have removed it again. Poor performance is usually preferable to no performance if it is only temporary. One cautionary note in such situations, though, applies to remote paging areas. Sparse files allocated on the remote system should not be used as paging areas. For example, I discovered the hard way (i.e., the problem was not documented) that SunOS would crash if a sparse file via NFS were added as a paging area and the SunOS system tried to write a page out to an unallocated region of the file, which was essentially all of the file at first. > >> My intent is to make this machine function -- getting the bear > >> dancing. How deftly she dances is less important than that she dances > >> at all. My for-real boxen will have real HP and real cores and RAM. > >> > >>> Also, you can't actually use 64GB swap with 4GB RAM.
Re: swap space issues
t ~410 MB of page frames on it. Setting the vm.pageout_wakeup_thresh to at least 410 MB *seems* to help reduce the number of times a process that has been marked as swapped out when the system has been under some form of memory pressure, but it doesn't stop it from happening when the kernel has pagefixed far too many page frames and hasn't pagefreed them when no longer really requiring them to remain in real memory. I don't know whether the bug is one of illegitimately pagefixing or failure to pagefree, but eventually the number of page frames tied up becomes so high that too few frames remain available for the kernel to be willing to page processes back in to resume them. Increasing vm.pageout_wakeup_thresh drastically from its default value is the primary way I have found to extend the time that my system remains usable before I am forced to reboot. As mentioned previously, I am dismayed that 12.1 appears to contain at least some of 11.2+'s bugs. Given that 11.1 went EOL a long time ago, that means that there is presently *NO PRODUCTION RELEASE OF FREEBSD AVAILABLE* since 11.1-RELEASE, the FreeBSD project web site's erroneous claims notwithstanding. This is an awful situation and probably calls for some corrective action by the FreeBSD core team. A production release does not force a reboot every few days or even every month or two in order to remain usable. That's one of the reasons Windows through XP and VISTA were never production systems, even though Mico$lop gave its users no production alternatives. FreeBSD used to do better and it should be doing better now. It is worth noting that a few years ago, FreeBSD project staff realized that an elderly Pentium II(?) machine running FreeBSD 2.something and still doing some simple, but necessary, task for the project had an uptime in excess of 19 *years*. That is a reliability record for any OS to strive for. It is a shame that FreeBSD's quality control no longer results in anything close to that. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: possible problem with pkg in FreeBSD11.4-BETA2
Mike Karels wrote: > > On Date: Sat, 16 May 2020 16:05:09 +0200 Kurt Jaeger > > wrote: > > [Mike Karels wrote:] > > > > > This might be due to cockpit error, but I don't remember the exact > > > > history > > > > of this machine. I have a test machine that was running 11.3-RELEASE, > > > > and > > > > had been upgraded with freebsd-update. I upgraded it to 11.4-BETA1 last > > > > week, and BETA2 this weekend. Then I tried "pkg upgrade" and got an > > > > error: > > > > > > Use > > > > > > pkg bootstrap -f > > > > > > There's some hickup in the upgrade path between your version > > > and the most current, so... > > > > > He switched from -RELEASE packages to -STABLE packages. > > Are BETA releases treated as -STABLE? If so, would this problem be > expected? If so, it should be handled much more gracefully. If not, > I don't think that's the problem; I'm reasonably sure this machine > has only been upgraded with freebsd-update; it was running an 11.3 > patch version. > Now that you ask, that's a good question. I haven't run "make buildworld" and "make buildkernel" since 28 April because I'm trying to minimize being forced to reboot by the kernel's memory management bugs, so my stable/11 system still says "11.4-PRERELEASE". It has been long enough since 11.3 happened that I don't recall whether it went through a transition period of BETAx and RCx changes as it changed from 11.2 to 11.3. Of course, those memory management bugs first caused big problems starting when 11.2 happened, so I may have missed some of the transition due to infrequent system updates. I only remember that it won't say it's 11.4-STABLE until the release happens and I've updated /usr/src and built and installed a new system. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: Slow zfs destroy
Eugene Grosbein wrote: > 30.11.2019 0:57, Scott Bennett wrote: > > > On Thu, 28 Nov 2019 23:18:37 +0700 Eugene Grosbein > > wrote: > > > >> 28.11.2019 20:34, Steven Hartland wrote: > >> > >>> It may well depend on the extent of the deletes occurring. > >>> > >>> Have you tried disabling TRIM to see if it eliminates the delay? > >> > >> This system used mfi(4) first and mfi(4) does not support TRIM at all. > >> Performance was abysmal. > >> Now it uses mrsas(4) and after switch I ran trim(8) for all SSDs > >> one-by-one then re-added them to RAID1. > >> Disabling TRIM is not an option. > >> > >> Almost a year has passed since then and I suspect SSDs have no or a few > >> spare trimmed cells for some reason. > >> Is there documented way to check this out? Maybe some SMART attribute? > >> > > You neglected to state whether you used "zfs destroy datasetname" or > > "zfs destroy -d datasetname". If you used the former, then ZFS did what > > you told it to do. If you want the data set destroyed in the background, > > you will need to include the "-d" option in the command. (See the zfs(1) > > man page at defer_destroy under "Native Properties".) > > The manual says "zfs destroy -d" is not for "background" but for "deferred". > The "zfs destroy" without -d would return EBUSY for a snapshot on hold (zfs > hold) > or bound with a clone, but "zfs destroy -d" would mark the snapshot for later > destruction > in a moment the clone is deleted or user lock (hold) is lifted. > Until then the snapshot still usable and destruction does not happen. > > All my snapshots are free from holds or clones and can be deleted, > so "zfs destroy -d" is equal to "zfs destroy" for them. > What you say is true, and I have seen it accept a "zfs destroy -d" for a held snapshot but do nothing until the hold is released, whereupon the "destroy" begins. However, that cannot be the whole story because... The vast majority of my "destroy" operations are for snapshots, but what I have seen is that, without the "-d", the command does not return until the disk activity of the "destroy" finishes, but with the "-d", it returns within a couple of seconds,--i.e., just long enough to get the operation going--and the disk I/Os continue until the work is done and free space in the pool increases until the I/Os stop. Perhaps the man pages for zfs(8) and zpool-features(7) need some modification/ clarification on this matter. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: Slow zfs destroy
On Thu, 28 Nov 2019 23:18:37 +0700 Eugene Grosbein wrote: >28.11.2019 20:34, Steven Hartland wrote: > >> It may well depend on the extent of the deletes occurring. >> >> Have you tried disabling TRIM to see if it eliminates the delay? > >This system used mfi(4) first and mfi(4) does not support TRIM at all. >Performance was abysmal. >Now it uses mrsas(4) and after switch I ran trim(8) for all SSDs one-by-one >then re-added them to RAID1. >Disabling TRIM is not an option. > >Almost a year has passed since then and I suspect SSDs have no or a few spare >trimmed cells for some reason. >Is there documented way to check this out? Maybe some SMART attribute? > You neglected to state whether you used "zfs destroy datasetname" or "zfs destroy -d datasetname". If you used the former, then ZFS did what you told it to do. If you want the data set destroyed in the background, you will need to include the "-d" option in the command. (See the zfs(1) man page at defer_destroy under "Native Properties".) Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: kernel bug in 11.3-STABLE causes frequent crashes
Eugene, Thank you very much for the fast reply! Eugene Grosbein wrote: > 09.11.2019 19:45, Scott Bennett ?: > > The rest of this message was posted a little while ago to the > > freebsd-questions list by mistake. It was intended for freebsd-stable, > > so I am posting it here now after posting a brief apology on the other > > list. > > I have had to waste a great deal of time lately in recovering my > > system from crashes due to a kernel bug. At present, my system is > > > > FreeBSD hellas 11.3-STABLE FreeBSD 11.3-STABLE #12 r352571: Sat Sep 21 > > 11:39:52 CDT 2019 bennett@hellas:/usr/obj/usr/src/sys/hellas amd64 > > > > There are actually at least two problems, but this particular one has been > > causing a large portion of my forced reboots. It usually fails to produce > > a dump and freezes right after the panic and backtrace messages, as it did > > earlier tonight, but Wednesday night it did create a dump, which I am > > keeping in case it should prove helpful in getting the bug identified and > > solved. I copied the console messages to paper painstakingly by hand. > > They appear to be identical each time, except, of course, for the messages > > that a dump is produced when, indeed, it does produce one. I am omitting > > those fairly standard messages. > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 2; apic id = 02 > > fault virtual address = 0x3b8 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0x80a4b14c > > stack pointer = 0x0:0xfe012a60ea50 > > frame pointer = 0x0:0xfe012a60eae0 > > code segment= base 0x0, limit 0xf, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags= interrupt enabled, resume, IOPL = 0 > > current process = 28 (flowcleaner) > > trap number = 12 > > panic: page fault > > cpuid = 2 > > KDB: stack backtrace: > > #0 0x80a94707 at kdb_backtrace+0x67 > > #1 0x80a4fa2e at vpanic+0x17e > > #2 0x80a4f8a3 at panic+0x43 > > #3 0x80f3a4d0 at trap_pfault+0 > > #4 0x80f3a519 at trap_pfault+0x49 > > #5 0x80f39bad at trap+0x29 > > #6 0x80f19f33 at calltrap+0x8 > > #7 0x80b3bb8d at flowtable_clean_vnet+0x43d > > #8 0x80b3c758 at flowtable_cleaner+0xc8 > > #9 0x80a12ea2 at fork_exit+0x82 > > #10 0x80flaf4e at fork_trampoline+0xe > > > > The machine is ancient. The CPU is a QX9650 (last group of Core 2 > > Quads) with 8 GB of DDR3 memory. > > If this can be identified as a known bug and a clue provided to a > > patch or a safer version to upgrade to, I would be grateful. I am getting > > very, very tired of these crashes. > > The other forced reboots I will describe in a separate message, but > > that problem has existed since the time of 11.2-RELEASE and apparently was > > never investigated, much less fixed, although people began complaining on > > this list and possibly -questions within the first few days after the > > release date. > > Thanks in advance for any help with this problem! > > It seems you have custom kernel with options FLOWTABLE. The code it includes > is known to be buggy, this options was removed from GENERIC many releases ago. > Remove it from your kernel configuration, rebuild kernel and you will be fine. > Wonderful. I have a comment on that line, saying I added it for 8.x, so I probably found it in 8.1's GENERIC configuration file when I was preparing to upgrade from 7.3. It is interesting that it only started hitting me (hard enough to make me notice it, at least) in 11.3 and maybe a bit earlier in 11.2. Anyway, that will be easy enough to fix, but will require rolling /usr/src back to the revision I am running, which is probably also no big deal. I don't seem to be able to build it at the current source revision because 11-STABLE's buildworld began failing during the libc build two or three weeks ago. I just tried "svn update /usr/src" again, followed by "make -j6 buildworld", and it still fails with this ending. --- libc_pic.a --- ranlib -D libc_pic.a --- libc.a --- ranlib -D libc.a --- libc.so.7.full --- cc: error: unable to execute command: posix_spawn failed: Permission denied cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [libc.so.7.full] Error code 1 make[4]: stopped in /usr/src/lib/libc 1 error make[4]: stopped in /usr/src/lib/libc *** [lib/libc__L] Error code 2 make[3]: stopped
kernel bug in 11.3-STABLE causes frequent crashes
The rest of this message was posted a little while ago to the freebsd-questions list by mistake. It was intended for freebsd-stable, so I am posting it here now after posting a brief apology on the other list. I have had to waste a great deal of time lately in recovering my system from crashes due to a kernel bug. At present, my system is FreeBSD hellas 11.3-STABLE FreeBSD 11.3-STABLE #12 r352571: Sat Sep 21 11:39:52 CDT 2019 bennett@hellas:/usr/obj/usr/src/sys/hellas amd64 There are actually at least two problems, but this particular one has been causing a large portion of my forced reboots. It usually fails to produce a dump and freezes right after the panic and backtrace messages, as it did earlier tonight, but Wednesday night it did create a dump, which I am keeping in case it should prove helpful in getting the bug identified and solved. I copied the console messages to paper painstakingly by hand. They appear to be identical each time, except, of course, for the messages that a dump is produced when, indeed, it does produce one. I am omitting those fairly standard messages. Fatal trap 12: page fault while in kernel mode cpuid = 2; apic id = 02 fault virtual address = 0x3b8 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80a4b14c stack pointer = 0x0:0xfe012a60ea50 frame pointer = 0x0:0xfe012a60eae0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 28 (flowcleaner) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: #0 0x80a94707 at kdb_backtrace+0x67 #1 0x80a4fa2e at vpanic+0x17e #2 0x80a4f8a3 at panic+0x43 #3 0x80f3a4d0 at trap_pfault+0 #4 0x80f3a519 at trap_pfault+0x49 #5 0x80f39bad at trap+0x29 #6 0x80f19f33 at calltrap+0x8 #7 0x80b3bb8d at flowtable_clean_vnet+0x43d #8 0x80b3c758 at flowtable_cleaner+0xc8 #9 0x80a12ea2 at fork_exit+0x82 #10 0x80flaf4e at fork_trampoline+0xe The machine is ancient. The CPU is a QX9650 (last group of Core 2 Quads) with 8 GB of DDR3 memory. If this can be identified as a known bug and a clue provided to a patch or a safer version to upgrade to, I would be grateful. I am getting very, very tired of these crashes. The other forced reboots I will describe in a separate message, but that problem has existed since the time of 11.2-RELEASE and apparently was never investigated, much less fixed, although people began complaining on this list and possibly -questions within the first few days after the release date. Thanks in advance for any help with this problem! Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: 11-STABLE system unbootable after update
Cyrus Rahman wrote: > When you upgrade the kernel you need to upgrade any loadable kernel > modules at the same time. Yes. For a time, listing them in /etc/src.conf would get them rebuilt automatically as a sort of epilogue to building a kernel, but then something changed quite a while back, and I had to comment that line out and return to doing them manually. Often they still work without being rebuilt, and I got careless this time. Sigh. > > Recompile any kmods from ports and you should be ok. Done, but the next reboot will be into the previous boot environment, and it now seems unlikely that I will use this one again rather than making a new one from a more up-to-date revision. > > STABLE doesn't always work. It's good for adventurous people to try > it so the bugs get found out, but occasionally it is painful. Upgrade > again right after the release in a few weeks. Usually caution is in > order just before things get to the BETA stage. I upgraded just now > do help test things and discovered your bug, which I posted about a > few posts before yours on the list. Ah. I suppose I will see that while catching up on my latest email backlog caused by six days or so with no working system. Thanks again for your reply to my call for help. > > If the description I posted is similar to yours, go ahead and reply to > my message on the list, and perhaps go to bugs.freebsd.org and search > out 'loader', and add any information you might have (or at least > document the fact that you were affected). Will do. > > You can quote me on the list, I simply wanted to have you try things > out before putting my suggestions on it. Over the years I have grown > weary of unnecessary noise. > Okay. I've cc'ed the list this time. FWIW, once of the things I have been wishing for in trying new revisions of 11-STABLE is a fix for the failure of the kernel to honor the vm.max_wired sysctl variable. The crash that gave me an opportunity to try the broken revision was another case of the kernel having pagefixed so much real memory that it was not only causing paging/swapping when it should have, but I think the kernel itself couldn't get page frames it needed fast enough in some situation. I don't know whether this bug has been found and fixed yet, though, so I have temporarily returned to setting vm.kmem_size_max, which does seem to be honored. Anyway, thanks for bailing me out yesterday. The system is now somewhat usable while I satisfy my curiousity and should be fully usable upon reversion, which will probably happen tomorrow (Monday) night. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: 11-STABLE system unbootable after update
Matt Garber wrote: > On Sun, May 19, 2019 at 9:00 AM Scott Bennett wrote: > > > > > Many, many thanks to the person who responded with the solution to > > get past the > > loader crash!! My system is now getting work done again, and the rest of > > the new > > problems can be dealt with on a running system. > > > Out of curiosity, you mentioned in your previous email you created a new > boot environment for this upgrade? since additional issues remain beyond > the loader, have you considered rolling back to the known-good BE and > attempting the entire process again (with another, separate BE) in a week > or so? Especially since that would hopefully allow you to continue your > other work without any additional issues or oddities to sort through in the > meantime? > Yes, and I will likely do so, but not tonight. I am still exploring what is new/changed in this revision (besides a broken zfsloader), and I do have mprime back to work for the time being, so reverting can wait another day. I have reverted a few times in the past, but was always able to start that from the boot menu. This time really threw me until I received a reply to my plea for help telling me how to use the previous loader to get to the boot menu. I had already successfully run the r347183 kernel in single-user mode, so I figured I could do so again. What broke the zfsloader was the installworld step. After reverting to r345498 I will try bringing my source tree up to date, which would be quite a bit later than this broken r347183, and then run a fresh buildworld and buildkernel anyway. If all that fails, then I'll just go back to r345498 again and sit it out until 11.3-RELEASE happens before trying again. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: 11-STABLE system unbootable after update
On Sat, 18 May 2019 08:02:20 -0500 Scott Bennett wrote: > I have been running 11.2-STABLE for a while at r345498. Last weekend it > crashed, >so I took the opportunity to install the most recent build I had lying around, >r347182. >I created a new boot environment and installed the r347182 kernel into it, >shut the >system down, and rebooted. The new kernel came up and appeared to be working >okay, so >I continued with the mergemaster -p -F, make installworld, and mergemaster -F, >then >shut it down again, and rebooted. It asked for the GELI key for the boot >pool, which >I then entered. The spinning slash cursor appeared and may have changed for >one frame >or so, and then I got a message beginning with "BTX" and followed by several >lines of >hexadecimal, and then it stopped. I tried it again just to be sure, and the >result was >exactly the same. > Does anyone know whether the PMBR boot block or the loader in the > freebsd-boot >partition changed between r345498 and r347182? I found no warning in >/usr/src/UPDATING ^ I wrote the revision down wrong in my notes. It was really r347183. >about installworld potentially leaving a wasted system, so I don't have a >clear idea >of what went wrong, much less whether I missed some instruction somewhere >about source >updates. If anyone can lend me a clue here, I would greatlyappreciate it. I >only had >one working machine, and now it is only working in a "rescue" mode by booting >from a >DVD. (Probably needless to say, but I will burn new DVDs with up-to-date >stuff as soon >as my system is working the way it is supposed to again.) > This motherboard is nearly 11 years old and does not boot from USB (in > spite of >the BIOS menus say), so at the moment I am logged into SDF by running a long >out-of-date >TrueOS installer DVD, which happens to be a pain to get to boot all the way, >but I've >figured how to make it do it rather than get stuck with a logo on the screen >that never >goes away. Unfortunately, it includes no software to burn a CD or DVD, so I >cannot >make a new bootable disk for the time being. I will check email much later >today or >this evening. So far I've received one reply, which was not copied to this list, yet the person responding suggested something to try and also adked that I post the result to the list. I would have done both anyway, but the respondent may have desired anonymity on the list, so I am not quoting the message I received. The suggestion was to wait about a second after entering the GELI passphrase and then hit the space bar on my keyboard. At the resulting prompt, I should enter the path given in the prompt, but with ".old" appended. I did that, and YES!!! It worked and proceeded until I had a boot menu. I opted for single-user mode and then responded to further requests for GELI passphrases until eventually I had a root shell. Being unable to reach the boot menu was a problem hadn't previously even crossed my mind. I certainly hope that doing updates from source in the future will not cause this same booby trap again. At that point I renamed /boot/zfsloader to /boot/zfsloader.bad.r347183 and /boot/zfsloader.old to /boot/zfsloader. I also added a hard link to the latter as /boot/zfsloader.good.r345498. All is still not well, however. In multi-user mode, startx turns the screen black and switches its power setting to standby. After that it remains unresponsive until I log in via a different vt and send SIGHUP to xorg. After a rather lengthy delay (30-60 seconds, at a guess) it returns to the login session on the console vt. I have now commented out the "kld_list="/boot/modules/radeonkms.ko" line in /etc/rc.conf.local in hopes that the next boot will get the scfb driver to take it instead of the radeonkms driver from graphics/drm-next-kmod. If someone knows, is this a case where rebuilding and reinstalling graphics/drm-next-kmod? If so, then I will do that, but I see that the Makefile still appears to use the same distribution file. Many, many thanks to the person who responded with the solution to get past the loader crash!! My system is now getting work done again, and the rest of the new problems can be dealt with on a running system. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection
11-STABLE system unbootable after update
I have been running 11.2-STABLE for a while at r345498. Last weekend it
crashed,
so I took the opportunity to install the most recent build I had lying around,
r347182.
I created a new boot environment and installed the r347182 kernel into it, shut
the
system down, and rebooted. The new kernel came up and appeared to be working
okay, so
I continued with the mergemaster -p -F, make installworld, and mergemaster -F,
then
shut it down again, and rebooted. It asked for the GELI key for the boot pool,
which
I then entered. The spinning slash cursor appeared and may have changed for
one frame
or so, and then I got a message beginning with "BTX" and followed by several
lines of
hexadecimal, and then it stopped. I tried it again just to be sure, and the
result was
exactly the same.
Does anyone know whether the PMBR boot block or the loader in the
freebsd-boot
partition changed between r345498 and r347182? I found no warning in
/usr/src/UPDATING
about installworld potentially leaving a wasted system, so I don't have a clear
idea
of what went wrong, much less whether I missed some instruction somewhere about
source
updates. If anyone can lend me a clue here, I would greatlyappreciate it. I
only had
one working machine, and now it is only working in a "rescue" mode by booting
from a
DVD. (Probably needless to say, but I will burn new DVDs with up-to-date stuff
as soon
as my system is working the way it is supposed to again.)
This motherboard is nearly 11 years old and does not boot from USB (in
spite of
the BIOS menus say), so at the moment I am logged into SDF by running a long
out-of-date
TrueOS installer DVD, which happens to be a pain to get to boot all the way,
but I've
figured how to make it do it rather than get stuck with a logo on the screen
that never
goes away. Unfortunately, it includes no software to burn a CD or DVD, so I
cannot
make a new bootable disk for the time being. I will check email much later
today or
this evening.
Thanks in advance for any helpful ideas!
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
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: why does buildworld fail on stable/11 ?
Ian Lepore <i...@freebsd.org> wrote:
> On Fri, 2018-01-26 at 09:52 +, Holger Kipp wrote:
> > Dear Scott,
> >
> > Am 26.01.2018 um 09:07 schrieb Scott Bennett
> > <bennett@sdf.orgbenn...@sdf.org>>:
> >
> > cd /usr/src; PATH=/sbin:/bin:/usr/sbin:/usr/bin MAKE_CMD=make
> > /usr/obj/usr/src/make.amd64/bmake -m /usr/src/share/mk -f Makefile.inc1
> > TARGET=amd64 TARGET_ARCH=amd64 MK_META_MODE=no cleandir
> > bmake: illegal argument to d option -- p
> > usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable]
> > [-d flags] [-E variable] [-f makefile] [-I directory]
> > [-j max_jobs] [-m directory] [-V variable]
> > [variable=value] [target ...]
> > *** Error code 2
> >
> > Stop.
> > make: stopped in /usr/src
> > hellas# exit
> > exit
> >
> > Script done on Fri Jan 26 01:33:18 2018
> >
> >
> > ?Scott Bennett, Comm. ASMELG, CFIAG
> >
> > This sound similar to an issue with make in 2013:
> >
> > 20130613:
> > Some people report the following error after the switch to bmake:
> >
> > make: illegal option -- J
> > usage: make [-BPSXeiknpqrstv] [-C directory] [-D variable]
> > ...
> > *** [buildworld] Error code 2
> >
> > this likely due to an old instance of make in
> > ${MAKEPATH} (${MAKEOBJDIRPREFIX}${.CURDIR}/make.${MACHINE})
> > which src/Makefile will use that blindly, if it exists, so if
> > you see the above error:
> >
> > rm -rf `make -V MAKEPATH`
> >
> > should resolve it.
> >
> > Can you check if you have an older version of make in your makepath and
> > delete / rename it?
> >
>
> Yep, it's definitely running a bad old version of make, and the thought
> that it's using /usr/obj/usr/src/make.amd64/bmake even though it's not
Aack!! "make buildworld" doesn't kill that?? Wow. Why does it get
missed by buildworld (or cleanworld, if that's what buildworld uses)? Should
that get a PR? That program must have been sitting there for several *years*.
The irony here is that I have long treated /usr/obj as disposable
(i.e., I don't normally bother to back it up anywhere) because a) a "make
buildworld buildkernel" will recreate all of it, and b) both of those targets
include huge sequences of deletions that wipe out all existing versions of
stuff that they will create. Or so I have thought until now. Apparently,
the handbook needs to be updated to reflect the need to
/bin/rm -rf /usr/obj/usr
(or use newfs) before each buildworld just for safety's sake.
> up to date fits the symptoms. ?I'm a bit confused by the "rm -rf"
Yes, it certainly does. A quick newfs of the device where I keep
/usr/obj, and it seems to work perfectly now. I'm almost certain that this
same obsolete binary was what put a sudden halt to my updates of 10.3-STABLE
back in early October 2016, as well.
> command at the end... when I do make -V MAKEPATH I get nothing, so the
> rm command would just be an error -- since that's from UPDATING in
> 2013, I'm thinking it may be out of date advice now.
>
> I think the right fix here is probably "rm -rf /usr/obj/*" followed by
> a make buildworld.
>
Well, in this case, /usr/obj is a mount point for a UFS2 file system,
so it's less messy and much faster just to newfs it and mount it again.
Anyway, thanks ever so much to Holger Kipp and Ian Lepore for finding
the problem, and thanks also to everyone else who tried. The buildworld
(complete with ccache) has completed, and right now a kernel (GENERIC except
for SCHED_4BSD instead of the wretched SCHED_ULE) is busily being built.
Then I will try a much more customized kernel, but I no longer expect any
serious obstacles, thanks entirely to the help I got here on this list.
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
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: why does buildworld fail on stable/11 ?
Ian Lepore <i...@freebsd.org> wrote:
> On Thu, 2018-01-25 at 00:25 -0600, Scott Bennett wrote:
> > Ian Lepore <i...@freebsd.org> wrote:
> >
> > >
> > > On Wed, 2018-01-24 at 12:39 +0100, Dimitry Andric wrote:
> > > >
> > > > On 24 Jan 2018, at 09:51, Scott Bennett <benn...@sdf.org> wrote:
> > > > >
> > > > >
> > > > >
> > > > > Subject: Re: why does buildworld fail on stable/11 ?
> > > > >
> > > > > ????I wrote:
> > > > > >
> > > > > >
> > > > > > ???On Mon, 22 Jan 2018 12:42:58 + lists wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 22/01/2018 09:17, Scott Bennett wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > ???Anyway, I'm stuck.??Can someone please tell me what is going
> > > > > > > > wrong and
> > > > > > > > how to fix it???I'd really like to be able to update my system,
> > > > > > > > not only to
> > > > > > > > keep it reasonably current, but also to be able to customize a
> > > > > > > > kernel.??Thanks
> > > > > > > > in advance for any suggestions/solutions.
> > > > > [much deleted??--SB]
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > then
> > > > > > >
> > > > > > > [/usr/src #] make cleandir && make clean && make buildworld &&
> > > > > > > make
> > > > > > > buildkernel && make installkernel && mergemaster -p
> > > > > > ???At this point, that looks very optimistic, to say the least.
> > > > > > :-)??I've
> > > > > > tried "make cleanworld" (with /etc/make.conf still in place), and
> > > > > > it failed
> > > > > > exactly like the buildworld example I posted before.
> > > > > Okay.??Here's what happened.
> > > > >
> > > > > Script started on Wed Jan 24 02:17:30 2018
> > > > > hellas# mv /etc/make.conf{,.save}
> > > > > hellas# mv /etc/src.conf{,.save}
> > > > > hellas# cd /usr/src
> > > > > hellas# make cleandir
> > > > > "/usr/src/share/mk/local.sys.mk", line 51: Malformed conditional
> > > > > (${.MAKE.MODE:Mmeta*} != "")
> > > > > "/usr/src/share/mk/local.sys.mk", line 58: Malformed conditional
> > > > > (${.MAKE.MODE:Mnofilemon} == "")
> > > > > "/usr/src/share/mk/local.sys.mk", line 76: if-less else
> > > > > "/usr/src/share/mk/local.sys.mk", line 79: if-less endif
> > > > > "/usr/src/share/mk/sys.mk", line 476: if-less endif
> > > > > bmake: fatal errors encountered -- cannot continue
> > > > Looks like your make is broken.??What is the output of "which make"?
> > > >
> > > > -Dimitry
> > > >
> > > And also the output of "make -V MAKE_VERSION". ?To me, this looks a lot
> > > like what happens when you try to use old fmake from freebsd 8 to build
> > > modern freebsd source.
> > >
> > hellas# make -V MAKE_VERSION
> > 20170720
> > hellas#
>
> Well, that kills the wrong-version theory. ?The thing I would try next
> is setting some make debug flags, but it'll generate a ton of output.
>
> I'd start with "make -dlp cleandir" that should list everything it's
> doing while reading makefiles, and list any commands it executes.
> ?Capture that output (stdout and stderr), then a good first-look at the
> file might be something like "grep -v?ParseReadLine make.log", that
> should show us what files it's reading from which directories. ?My
> theory is maybe it's picking up a wrong include file somehow which
> leads it astray. ?If that's not it, we may need to also examine all the
> ParseReadLine stuff, or add some other debug flags.
>
Okay. If you really want all of it, let me know, and I'll email it
to you directly. Here are the last 50 lines or so of it.
# .MAIN, flags 0, type 1, made 0
# _guard, flags 0, type 0, made 0
ParseDoDependency(_guard: .PHONY)
ParseDoDependency(world: .PHONY)
ParseDoDepe
Re: why does buildworld fail on stable/11 ?
Ian Lepore <i...@freebsd.org> wrote:
> On Wed, 2018-01-24 at 12:39 +0100, Dimitry Andric wrote:
> > On 24 Jan 2018, at 09:51, Scott Bennett <benn...@sdf.org> wrote:
> > >
> > >
> > > Subject: Re: why does buildworld fail on stable/11 ?
> > >
> > > I wrote:
> > > >
> > > > ???On Mon, 22 Jan 2018 12:42:58 +0000 lists <tech-li...@zyxst.net>
> > > > wrote:
> > > > >
> > > > > On 22/01/2018 09:17, Scott Bennett wrote:
> > > > > >
> > > > > > ???Anyway, I'm stuck.??Can someone please tell me what is going
> > > > > > wrong and
> > > > > > how to fix it???I'd really like to be able to update my system, not
> > > > > > only to
> > > > > > keep it reasonably current, but also to be able to customize a
> > > > > > kernel.??Thanks
> > > > > > in advance for any suggestions/solutions.
> > > [much deleted??--SB]
> > > >
> > > > >
> > > > > then
> > > > >
> > > > > [/usr/src #] make cleandir && make clean && make buildworld && make
> > > > > buildkernel && make installkernel && mergemaster -p
> > > > ???At this point, that looks very optimistic, to say the least.
> > > > :-)??I've
> > > > tried "make cleanworld" (with /etc/make.conf still in place), and it
> > > > failed
> > > > exactly like the buildworld example I posted before.
> > > Okay.??Here's what happened.
> > >
> > > Script started on Wed Jan 24 02:17:30 2018
> > > hellas# mv /etc/make.conf{,.save}
> > > hellas# mv /etc/src.conf{,.save}
> > > hellas# cd /usr/src
> > > hellas# make cleandir
> > > "/usr/src/share/mk/local.sys.mk", line 51: Malformed conditional
> > > (${.MAKE.MODE:Mmeta*} != "")
> > > "/usr/src/share/mk/local.sys.mk", line 58: Malformed conditional
> > > (${.MAKE.MODE:Mnofilemon} == "")
> > > "/usr/src/share/mk/local.sys.mk", line 76: if-less else
> > > "/usr/src/share/mk/local.sys.mk", line 79: if-less endif
> > > "/usr/src/share/mk/sys.mk", line 476: if-less endif
> > > bmake: fatal errors encountered -- cannot continue
> > Looks like your make is broken.??What is the output of "which make"?
> >
> > -Dimitry
> >
>
> And also the output of "make -V MAKE_VERSION". ?To me, this looks a lot
> like what happens when you try to use old fmake from freebsd 8 to build
> modern freebsd source.
>
hellas# make -V MAKE_VERSION
20170720
hellas#
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
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: why does buildworld fail on stable/11 ?
tech-lists <tech-li...@zyxst.net> wrote:
> On 24/01/2018 08:51, Scott Bennett wrote:
> > hellas# mv /etc/make.conf{,.save}
> > hellas# mv /etc/src.conf{,.save}
> > hellas# cd /usr/src
> > hellas# make cleandir
> > "/usr/src/share/mk/local.sys.mk", line 51: Malformed conditional
> > (${.MAKE.MODE:Mmeta*} != "")
> > "/usr/src/share/mk/local.sys.mk", line 58: Malformed conditional
> > (${.MAKE.MODE:Mnofilemon} == "")
> > "/usr/src/share/mk/local.sys.mk", line 76: if-less else
> > "/usr/src/share/mk/local.sys.mk", line 79: if-less endif
> > "/usr/src/share/mk/sys.mk", line 476: if-less endif
> > bmake: fatal errors encountered -- cannot continue
> > *** Error code 1
>
> Move the /usr/src somewhere else, make a new /usr/src dir and then
>
> svnlite co https://svn.FreeBSD.org/base/stable/11 /usr/src
>
> make sure it completes normally
>
> then cd into it and make cleandir. What happens?
Before I do that, please answer my earlier question regarding svnlite
vs. svn. The make is failing on a clean checkout of /usr/src, as I stated
before. The only difference is that I used svn to do the checkout, not
svnlite. If they give identical checkout output, then repeating that rather
lengthy download would give an identical result and thus would serve no
purpose.
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
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: why does buildworld fail on stable/11 ?
Dimitry Andric <d...@freebsd.org> wrote:
> On 24 Jan 2018, at 09:51, Scott Bennett <benn...@sdf.org> wrote:
> >
> > Subject: Re: why does buildworld fail on stable/11 ?
> >
> > I wrote:
> >>On Mon, 22 Jan 2018 12:42:58 + lists <tech-li...@zyxst.net> wrote:
> >>> On 22/01/2018 09:17, Scott Bennett wrote:
> >>>>Anyway, I'm stuck. Can someone please tell me what is going wrong and
> >>>> how to fix it? I'd really like to be able to update my system, not only
> >>>> to
> >>>> keep it reasonably current, but also to be able to customize a kernel.
> >>>> Thanks
> >>>> in advance for any suggestions/solutions.
> >>>
> > [much deleted --SB]
> >>> then
> >>>
> >>> [/usr/src #] make cleandir && make clean && make buildworld && make
> >>> buildkernel && make installkernel && mergemaster -p
> >>
> >>At this point, that looks very optimistic, to say the least. :-) I've
> >> tried "make cleanworld" (with /etc/make.conf still in place), and it failed
> >> exactly like the buildworld example I posted before.
> >
> > Okay. Here's what happened.
> >
> > Script started on Wed Jan 24 02:17:30 2018
> > hellas# mv /etc/make.conf{,.save}
> > hellas# mv /etc/src.conf{,.save}
> > hellas# cd /usr/src
> > hellas# make cleandir
> > "/usr/src/share/mk/local.sys.mk", line 51: Malformed conditional
> > (${.MAKE.MODE:Mmeta*} != "")
> > "/usr/src/share/mk/local.sys.mk", line 58: Malformed conditional
> > (${.MAKE.MODE:Mnofilemon} == "")
> > "/usr/src/share/mk/local.sys.mk", line 76: if-less else
> > "/usr/src/share/mk/local.sys.mk", line 79: if-less endif
> > "/usr/src/share/mk/sys.mk", line 476: if-less endif
> > bmake: fatal errors encountered -- cannot continue
>
> Looks like your make is broken. What is the output of "which make"?
>
hellas# echo $PATH
/usr/local/libexec/ccache:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/root/bin
hellas# which make
/usr/bin/make
hellas# file /usr/bin/make
/usr/bin/make: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD),
statically linked, for FreeBSD 11.1 (1101506), FreeBSD-style, stripped
hellas#
Thanks, both of you, for something to try. With enough ideas, maybe
the problem can be uncovered.
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
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: why does buildworld fail on stable/11 ?
Subject: Re: why does buildworld fail on stable/11 ?
I wrote:
> On Mon, 22 Jan 2018 12:42:58 + lists <tech-li...@zyxst.net> wrote:
>>On 22/01/2018 09:17, Scott Bennett wrote:
>>> Anyway, I'm stuck. Can someone please tell me what is going wrong and
>>> how to fix it? I'd really like to be able to update my system, not only to
>>> keep it reasonably current, but also to be able to customize a kernel.
>>> Thanks
>>> in advance for any suggestions/solutions.
>>
[much deleted --SB]
>>then
>>
>>[/usr/src #] make cleandir && make clean && make buildworld && make
>>buildkernel && make installkernel && mergemaster -p
>
> At this point, that looks very optimistic, to say the least. :-) I've
>tried "make cleanworld" (with /etc/make.conf still in place), and it failed
>exactly like the buildworld example I posted before.
Okay. Here's what happened.
Script started on Wed Jan 24 02:17:30 2018
hellas# mv /etc/make.conf{,.save}
hellas# mv /etc/src.conf{,.save}
hellas# cd /usr/src
hellas# make cleandir
"/usr/src/share/mk/local.sys.mk", line 51: Malformed conditional
(${.MAKE.MODE:Mmeta*} != "")
"/usr/src/share/mk/local.sys.mk", line 58: Malformed conditional
(${.MAKE.MODE:Mnofilemon} == "")
"/usr/src/share/mk/local.sys.mk", line 76: if-less else
"/usr/src/share/mk/local.sys.mk", line 79: if-less endif
"/usr/src/share/mk/sys.mk", line 476: if-less endif
bmake: fatal errors encountered -- cannot continue
*** Error code 1
Stop.
make: stopped in /usr/src
hellas# exit
exit
Script done on Wed Jan 24 02:19:04 2018
Does anyone have any idea what is so horribly broken in 11.1-STABLE?
FWIW, this is on a ZFS installation done by the utterly braindead bsdinstall
provided in stable/11 ISO images.
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
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: why does buildworld fail on stable/11 ?
Subject: Re: why does buildworld fail on stable/11 ?
On Mon, 22 Jan 2018 12:42:58 + lists <tech-li...@zyxst.net> wrote:
>On 22/01/2018 09:17, Scott Bennett wrote:
>> Anyway, I'm stuck. Can someone please tell me what is going wrong and
>> how to fix it? I'd really like to be able to update my system, not only to
>> keep it reasonably current, but also to be able to customize a kernel.
>> Thanks
>> in advance for any suggestions/solutions.
>
>Hi,
Thank you for responding with your thoughts on this.
>
>What I'd do is firstly to make things as simple as possible. First do
>the upgrade simply. Either delete or call make.conf & src.conf something
Okay.
>else. Then get a fresh src and ports tree via svnlite. Then do
/usr/src has not been altered since I ran the checkout. Is there some reason
to use svnlite rather than svn, which is how I did the checkout?
>
>rm -rf /buildwork/ccache.freebsd
>mkdir /buildwork/ccache.freebsd
I'm not following your thinking here. If I've eliminated /etc/make.conf
from the picture, then ccache is not involved at all, so why should I wipe out
the cache contents?
>
>then
>
>[/usr/src #] make cleandir && make clean && make buildworld && make
>buildkernel && make installkernel && mergemaster -p
At this point, that looks very optimistic, to say the least. :-) I've
tried "make cleanworld" (with /etc/make.conf still in place), and it failed
exactly like the buildworld example I posted before.
>
>[make changes if needed]
>
>[/usr/src #] make installworld && mergemaster
>
>[make more changes if needed]
>
>reboot
>
>then cd into /usr/src as root, then do
>
>yes | make delete-old
>yes | make delete-old-libs
What do you expect the above to accomplish on a freshly installed system
on which no obsolete directories or libraries from a previous release should
exist?
>
>reboot again
>
>then re-enable your extra lines in make.conf and src.conf, if you need them.
>
>It may be down to something in the ccache dir, I guess.
>
I will try it with no /etc/{make,src}.conf then just to find out what
will happen, but I will still need a way to build from source with ccache
involved in the process for normal use because it typically cuts the build
times by 50% - 75% from the usual five or six hours elapsed time.
Thanks again for your suggestions. I will try it without
/etc/{make,src}.conf and report back.
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
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"
why does buildworld fail on stable/11 ?
I tried asking for help on this several days ago on freebsd-questions@, but got no responses. I'm trying freebsd-stable@ next because it involves trying to build world on a 11.1-STABLE system from a freshly checked out, unaltered source tree at r328251. The system currently installed is from a 11.1-STABLE installer image: FreeBSD hellas 11.1-STABLE FreeBSD 11.1-STABLE #0 r326620: Wed Dec 6 15:08:03 UTC 2017 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 I would like to keep it reasonably up to date, but I am stumped. I did a fresh svn checkout into a completely empty /usr/src, but when I tried to run a "make buildworld", it failed like this. Script started on Mon Jan 22 02:11:21 2018 hellas# setenv CCACHE_DIR /buildwork/ccache.freebsd hellas# cd /usr/src hellas# date && \ ? time nice +11 make buildworld && date Mon Jan 22 02:13:05 CST 2018 Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' Unknown modifier 'U' "/usr/src/share/mk/src.sys.mk", line 28: Option DIRDEPS_BUILD may only be defined in , environment, or make argument, not /etc/src.conf. *** Error code 1 Stop. make: stopped in /usr/src 0.035u 0.047s 0:01.65 4.2% 15254+422k 88+21io 31pf+0w hellas# exit exit Script done on Mon Jan 22 02:13:19 2018 Note that 'U' has not always been the letter complained of in the "Unknown modifier" messages. The content of /etc/src.conf is as follows. PORTS_MODULES=multimedia/cuse4bsd-kmod sysutils/pefs-kmod emulators/virtualbox-ose-kmod net/ndproxy WITH_LLDB=yes #WITH_FAST_DEPEND=yes WITH_CCACHE_BUILD=yes As you can see, there is no DIRDEPS_BUILD in /etc/src.conf. I don't even know what DIRDEPS_BUILD is. Anyway, I'm stuck. Can someone please tell me what is going wrong and how to fix it? I'd really like to be able to update my system, not only to keep it reasonably current, but also to be able to customize a kernel. Thanks in advance for any suggestions/solutions. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: automount usb msdosfs no partition table
Tomasz CEDRO <to...@cedro.info> wrote:
> i cannot format that device, as its the "firmware feature" that it has no
> partition table.. i would have to fix the firmware.. but it would be nice
> to automount it anyway as macos, linux and windoze can :-)
>
Well, put a partition table onto it, then. You can use either gpart(8)
or fdisk(8) to do that and to create a slice, and then use newfs_msdos(8) to
create the file system.
I understood from your previous message that you wanted to create a FAT32
file system on /dev/da0 rather than on /dev/da0s1, which meant on the bare
device rather than on a slice. Otherwise, create the partition table, create
a slice, and proceed.
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
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"
automount usb msdosfs no partition table
On Date: Mon, 9 Oct 2017 01:10:19 +0200 Tomasz CEDRO <to...@cedro.info> wrote: > I need to configure automount for a testing machine. It seems to work > fine, except for two issues: I've never used the automounter, so I can't help you with that. > > 1. Mount point does not disappear after device disappears, what makes > things harder to script when device is gone. automount -c does not > remove the mountpoint, only restarting the service does. It is a bug > or feature? > > 2. Automounter does not mount USB Pendrive / MSDOSFS devices that does > not have a parition table. Some USB Drives does not have valid > partition table, they appear as /dev/da0 and can be mounted with > mount_msdosfs /dev/da0 /mnt, but they are not recognised by > automounter.. how can I make it work with such devices? > Try newfs_msdos(8). Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: panic: Solaris(panic): blkptr invalid CHECKSUM1
te a zfs_fsck(8) soon ;-) > >Does it make sense to dump the disks for further analysis? >I need to recreate the pool because I need the machine's resources... :-( >Any help highly appreciated! > First, if it's not too late already, make a copy of the pool's cache file, and save it somewhere in case you need it unchanged again. Can zdb(8) see it without causing a panic, i.e., without importing the pool? You might be able to track down more information if zdb can get you in. Another thing you could try with an admittedly very low probability of working would be to try importing the pool with one drive of one mirror missing, then try it with a different drive of one mirror, and so on the minor chance that the critical error is limited to one drive. If you find a case where that works, then you could try to rebuild the missing drive and then run a scrub. Or vice versa. This one is time-consuming, I would imagine, given that each failure means a reboot. :-( Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: arm64 fork/swap data corruptions: A ~110 line C program demonstrating an example (Pine64+ 2GB context) [Corrected subject: arm64!]
Mark Millard wrote: > [Something strange happened to the automatic CC: fill-in for my original > reply. Also I should have mentioned that for my test program if a > variant is made that does not fork the swapping works fine.] > > On 2017-Mar-15, at 9:37 AM, Mark Millard wrote: > > > On 2017-Mar-15, at 6:15 AM, Scott Bennett wrote: > > > >>On Tue, 14 Mar 2017 18:18:56 -0700 Mark Millard > >> wrote: > >>> On 2017-Mar-14, at 4:44 PM, Bernd Walter <ti...@cicely7.cicely.de> wrote: > >>> > >>>> On Tue, Mar 14, 2017 at 03:28:53PM -0700, Mark Millard wrote: > >>>>> [test_check() between the fork and the wait/sleep prevents the > >>>>> failure from occurring. Even a small access to the memory at > >>>>> that stage prevents the failure. Details follow.] > >>>> > >>>> Maybe a stupid question, since you might have written it somewhere. > >>>> What medium do you swap to? > >>>> I've seen broken firmware on microSD cards doing silent data > >>>> corruption for some access patterns. > >>> > >>> The root filesystem is on a USB SSD on a powered hub. > >>> > >>> Only the kernel is from the microSD card. > >>> > >>> I have several examples of the USB SSD model and have > >>> never observed such problems in any other context. > >>> > >>> [remainder of irrelevant material deleted --SB] > >> > >>You gave a very long-winded non-answer to Bernd's question, so I'll > >> repeat it here. What medium do you swap to? > > > > My wording of: > > > > The root filesystem is on a USB SSD on a powered hub. > > > > was definitely poor. It should have explicitly mentioned the > > swap partition too: > > > > The root filesystem and swap partition are both on the same > > USB SSD on a powered hub. > > > > More detail from dmesg -a for usb: > > > > usbus0: 12Mbps Full Speed USB v1.0 > > usbus1: 480Mbps High Speed USB v2.0 > > usbus2: 12Mbps Full Speed USB v1.0 > > usbus3: 480Mbps High Speed USB v2.0 > > ugen0.1: at usbus0 > > uhub0: on usbus0 > > ugen1.1: at usbus1 > > uhub1: on usbus1 > > ugen2.1: at usbus2 > > uhub2: on usbus2 > > ugen3.1: at usbus3 > > uhub3: on usbus3 > > . . . > > uhub0: 1 port with 1 removable, self powered > > uhub2: 1 port with 1 removable, self powered > > uhub1: 1 port with 1 removable, self powered > > uhub3: 1 port with 1 removable, self powered > > ugen3.2: at usbus3 > > uhub4 on uhub3 > > uhub4: on > > usbus3 > > uhub4: MTT enabled > > uhub4: 4 ports with 4 removable, self powered > > ugen3.3: at usbus3 > > umass0 on uhub4 > > umass0: on usbus3 > > umass0: SCSI over Bulk-Only; quirks = 0x0100 > > umass0:0:0: Attached to scbus0 > > . . . > > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > > da0: Fixed Direct Access SPC-4 SCSI device > > da0: Serial Number > > da0: 40.000MB/s transfers > > > > (Edited a bit because there is other material interlaced, even > > internal to some lines. Also: I removed the serial number of the > > specific example device.) Thank you. That presents a much clearer picture. > > > >>I will further note that any kind of USB device cannot automatically > >> be trusted to behave properly. USB devices are notorious, for example, > >> > >> [reasons why deleted --SB] > >> > >>You should identify where you page/swap to and then try substituting > >> a different device for that function as a test to eliminate the possibility > >> of a bad storage device/controller. If the problem still occurs, that > >> means there still remains the possibility that another controller or its > >> firmware is defective instead. It could be a kernel bug, it is true, but > >> making sure there is no hardware or firmware error occurring is important, > >> and as I say, USB devices should always be considered suspect unless and > >> until proven innocent. > > > > [FYI: This is a ufs context, not a zfs one.] Right. It's only a Pi, after all. :-) > > > > I'm aware of such things. There is no evidence that has resulted in > > suggesting the USB devices that I can replace are a problem. Otherwise > > I'd not be going down this path. I only have access to the one arm64 > > device (a Pine64+ 2GB) so I've no ability to substitution-test what
Swapping from a zvol results in a deadman panic
On Sat, 4 Feb 2017 08:18:28 -0500 "Matthew X. Economou" <xenop...@irtnog.org> wrote: >My FreeBSD 10.3-RELEASE-p16 server crashes in the middle of a Poudriere >bulk run (see below). This crash happens even if I lower >vfs.zfs.arc_max or tweak vm.v_free_min/target/reserved/severe. I'm >looking for configuration advice in case I missed something obvious, >since this seems to work on Illumos- and Linux-derived O/Ses, but >failing that, I'd like to get some advice as to how to go about >debugging this. I doubt the deadman timer causes the system to stop >responding. It's more likely a race condition elsewhere. > Those who try to create deadlocks should not complain when they succeed. Sigh. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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"
make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf
On Sun, 11 Dec 2016 12:34:58 + tech-lists <tech-li...@zyxst.net> wrote: >I have found that make buildkernel/installkernel does not respect >KERNCONF= variables. It also doesn't respect MAKE_JOBS_NUMBER. It *DOES* >however respect WITH_CCACHE_BUILD. It's hard to say when the behaviour >changed to what it is, but it was sometime around the time that >11-CURRENT became 11-STABLE. > >Sources are 11-STABLE r309795 > >Here is my /etc/make.conf, which used to work: > >MALLOC_PRODUCTION=yes >WITH_CCACHE_BUILD=yes >MAKE_JOBS_NUMBER=32 >KERNCONF=PUMPKIN GENERIC >WITH_MANCOMPRESS=YES >WITHOUT_DEBUG=YES >DEFAULT_VERSIONS+= ssl=libressl >OPTIMIZED_CFLAGS=YES >BUILD_OPTIMIZED=YES > >I used to be able to buildworld and kernel like this: > >root@localhost:/usr/src# make cleandir && make clean && make buildworld >&& make buildkernel && make installkernel && mergemaster -p > >and I'd get two installed kernels, PUMPKIN and GENERIC > >now I have to specify on the line: > >root@localhost:/usr/src# make cleandir && make clean && make -j32 >buildworld && make -j32 buildkernel KERNCONF=PUMPKIN > >Also, I have to specify jobs # for both buildworld and buildkernel >otherwise it just uses one, two or four cores. > >How can I get it to work like it did previously? > You may have misremembered how you did it previously. Try adding BUILDKERNELS=PUMPKIN GENERIC to your /etc/src.conf and removing the KERNCONF line from /etc/make.conf before you run it again. KERNCONF goes on the "make buildkernel" command, not into /etc/make.conf, but should not be necessary at all if /etc/src.conf contains the list of kernels to be built. (See src.conf(5).) Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: huge nanosleep variance on 11-stable
On Wed, 2 Nov 2016 10:23:24 -0400 George Mitchell <george+free...@m5p.com> wrote: >On 11/01/16 23:45, Kevin Oberman wrote: >> On Tue, Nov 1, 2016 at 2:36 PM, Jason Harmening <jason.harmen...@gmail.com> >> wrote: >> >>> Sorry, that should be ~*30ms* to get 30fps, though the variance is still >>> up to 500ms for me either way. >>> >>> On 11/01/16 14:29, Jason Harmening wrote: >>>> repro code is at http://pastebin.com/B68N4AFY if anyone's interested. >>>> >>>> On 11/01/16 13:58, Jason Harmening wrote: >>>>> Hi everyone, >>>>> >>>>> I recently upgraded my main amd64 server from 10.3-stable (r302011) to >>>>> 11.0-stable (r308099). It went smoothly except for one big issue: >>>>> certain applications (but not the system as a whole) respond very >>>>> sluggishly, and video playback of any kind is extremely choppy. >>>>> >>>>> [...] >> I eliminated the annoyance by change scheduler from ULE to 4BSD. That was >> it, but I have not seen the issue since. I'd be very interested in whether >> the scheduler is somehow impacting timing functions or it's s different >> issue. I've felt that there was something off in ULE for some time, but it >> was not until these annoying hiccups convinced me to try going back to >> 4BSD. >> >> Tip o' the hat to Doug B. for his suggestions that ULE may have issues that >> impacted interactivity. >> [...] > >Not to beat a dead horse, but I've been a non-fan of SCHED_ULE since >it was first introduced, and I don't like it even today. I run the >distributed.net client on my machines, but even without that, ULE >screws interactive behavior. With distributed.net running and ULE, >a make buildworld/make buildkernel takes 10 2/3 hours on 10.3-RELEASE >on a 6-CPU machine versus 2 1/2 hours on the same machine with 4BSD >and distributed.net running. I'm told that SCHED_ULE is the greatest >thing since sliced bread for some compute load or other (details are >scarce), but I (fortunately) don't often have to run heavy server >type loads; and for everyday use (even without distributed.net >running), SCHED_4BSD is my choice by far. It's too bad I can't run >freebsd_update with it, though. > I gave up on ULE during 8-STABLE. I had tried tinkering with kern.sched.preempt_thresh as recommended, as well as some more extreme values, but I couldn't see any improvement. Some values may have made performance even worse. The last straw for me, however, was when I discovered that ULE happily scheduled *idle* priority processes at times when both CPU threads on a P4 Prescott were tied up by 100% CPU-bound (mprime) threads at normal priority niced to 20. Idle priority tasks should *only* run when no higher priority tasks are available to run for all CPU threads. The 4BSD scheduler handles this situation properly. Now I'm running 10.3-STABLE on a QX9650, and I haven't tested ULE on it to see whether it's still as flawed. If and when I get a machine with a multi-cored, hyperthreaded CPU or perhaps a board with multiple CPU chips, then I may worry about the multi-level affinity stuff that ULE was supposedly designed for enough to bother testing it. But for now, I can't see any advantage in it for my current machine. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: zfs, a directory that used to hold lot of files and listing pause
On Fri, 21 Oct 2016 16:51:36 +0500 "Eugene M. Zheganin" <e...@norma.perm.ru> wrote: >On 21.10.2016 15:20, Slawa Olhovchenkov wrote: >> >> ZFS prefetch affect performance dpeneds of workload (independed of RAM >> size): for some workloads wins, for some workloads lose (for my >> workload prefetch is lose and manualy disabled with 128GB RAM). >> >> Anyway, this system have only 24MB in ARC by 2.3GB free, this is may >> be too low for this workload. >You mean - "for getting a list of a directory with 20 subdirectories" ? >Why then does only this directory have this issue with pause, not >/usr/ports/..., which has more directories in it ? > >(and yes, /usr/ports/www isn't empty and holds 2410 entities) > >/usr/bin/time -h ls -1 /usr/ports/www >[...] >0.14s real 0.00s user 0.00s sys > Oh, my goodness, how far afield nonsense has gotten! Have all the good folks posting in this thread forgotten how directory blocks are allocated in UNIX? This isn't even a BSD-specific thing; it's really ancient. What Eugene has complained of is exactly what is to be expected-- on really old hardware. The only eyebrow-raiser is that he has created a use case so extreme that a live human can actually notice the delays on modern hardware. I quote from his original posting: "I also have one directory that used to have a lot of (tens of thousands) files." and "But now I have 2 files and a couple of dozens directories in it". A directory with tens of thousands of files in it at one point in time most likely has somewhere well over one thousand blocks allocated. Directories don't shrink. Directory entries do not get moved around within directories when files are added or deleted. Directories can remain the same length or they can grow in length. If a directory once had many tens of thousands of filenames and links to their primary inodes, then the directory is still that big, even if it now only contains two [+ 20 to 30 directory], probably widely separated, entries. To read a file's entry, all blocks must be searched until the desired filename is found. Likewise, to list the contents of a directory, all blocks must be read until the number of files found matches the link count for the directory. IOW, if you want the performance to go back to what it was when the directory was fresh (and still small), you have to create a new directory and then move the remaining entries from the old directory into the new (small) directory. The only real difference here between UFS (or even the early AT filesystem) and ZFS is that the two remaining entries in a formerly huge directory are likely to be in different directory blocks that could be at effectively random locations scattered around the space of a partition for one filesystem in UFS or over an entire pool of potentially many filesystems and much more space in ZFS. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: buildworld errors at outset on fresh svn checkout
I wrote:
>"Matthew D. Fuller" <fulle...@over-yonder.net> wrote:
>
>> On Fri, Oct 07, 2016 at 10:13:02PM -0700 I heard the voice of
>> Kevin Oberman, and lo! it spake thus:
>> > On Thu, Oct 6, 2016 at 10:16 PM, Scott Bennett <benn...@sdf.org> wrote:
>> >
>> > > "/usr/src/Makefile.inc1", line 1113: Malformed conditional
>> > > (${BUILDKERNELS:[)
>> > > Unknown modifier '['
>> >
>> > '[' needs to be a hard link to test.
>>
>> This is make, not sh.
>>
>> That would be the line
>>
>> .if ${BUILDKERNELS:[#]} > 1 && ${NO_INSTALLEXTRAKERNELS} != "yes"
>>
>> in current stable/10, and it's horking on the [...] modifier. That's
>
> What is currently installed is
>
>FreeBSD hellas 10.3-STABLE FreeBSD 10.3-STABLE #284 r304657: Tue Aug 23
>01:48:12 CDT 2016 bennett@hellas:/usr/obj/usr/src/sys/hellas amd64
>
>> listed in the make manpage on a stable/10 system from last October, so
>> it's not terribly new. Maybe an ancient make? Or your 'make' isn't
>> the make it's expecting?
>>
>Here are the ones I have currently installed.
>
>[hellas] 26 % ls -ilgF /usr/{,local/}bin/{,?}make
> 102327 -r-xr-xr-x 1 root wheel 466396 May 3 2014 /usr/bin/bmake*
> 82321 -r-xr-xr-x 1 root wheel 715152 Aug 23 05:17 /usr/bin/make*
>7391987 -r-xr-xr-x 1 root wheel 187600 Aug 23 16:24 /usr/local/bin/bmake*
>7391732 -rwxr-xr-x 1 root wheel 3805840 Sep 18 13:36 /usr/local/bin/cmake*
>7386658 -r-xr-xr-x 1 root wheel 112976 Sep 6 2015 /usr/local/bin/dmake*
>7384146 -r-xr-xr-x 1 root wheel 224520 Jul 10 18:45 /usr/local/bin/gmake*
>7384478 -r-xr-xr-x 1 root wheel24664 May 18 2015 /usr/local/bin/imake*
>7386767 -r-xr-xr-x 1 root wheel 2541440 Dec 14 2014 /usr/local/bin/qmake*
>7392225 -rwxr-xr-x 1 root wheel 123256 Aug 31 11:03 /usr/local/bin/smake*
>7384593 -r-xr-xr-x 1 root wheel32941 May 19 2015 /usr/local/bin/tmake*
>
> So the worrisome one looks like the /usr/bin/bmake, which pershaps should
>have been removed by "make delete-old" during an upgrade somewhere along the
>way. Let me try renaming it to see what happens. I'll report back.
>
Okay. I tried renaming /usr/bin/bmake to /usr/bin/bmake.old and then
ran "make buildworld". That failed the same way as before. :-( So I guess
that wasn't the problem.
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
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: buildworld errors at outset on fresh svn checkout
"Matthew D. Fuller" <fulle...@over-yonder.net> wrote:
> On Fri, Oct 07, 2016 at 10:13:02PM -0700 I heard the voice of
> Kevin Oberman, and lo! it spake thus:
> > On Thu, Oct 6, 2016 at 10:16 PM, Scott Bennett <benn...@sdf.org> wrote:
> >
> > > "/usr/src/Makefile.inc1", line 1113: Malformed conditional
> > > (${BUILDKERNELS:[)
> > > Unknown modifier '['
> >
> > '[' needs to be a hard link to test.
>
> This is make, not sh.
>
> That would be the line
>
> .if ${BUILDKERNELS:[#]} > 1 && ${NO_INSTALLEXTRAKERNELS} != "yes"
>
> in current stable/10, and it's horking on the [...] modifier. That's
What is currently installed is
FreeBSD hellas 10.3-STABLE FreeBSD 10.3-STABLE #284 r304657: Tue Aug 23
01:48:12 CDT 2016 bennett@hellas:/usr/obj/usr/src/sys/hellas amd64
> listed in the make manpage on a stable/10 system from last October, so
> it's not terribly new. Maybe an ancient make? Or your 'make' isn't
> the make it's expecting?
>
Here are the ones I have currently installed.
[hellas] 26 % ls -ilgF /usr/{,local/}bin/{,?}make
102327 -r-xr-xr-x 1 root wheel 466396 May 3 2014 /usr/bin/bmake*
82321 -r-xr-xr-x 1 root wheel 715152 Aug 23 05:17 /usr/bin/make*
7391987 -r-xr-xr-x 1 root wheel 187600 Aug 23 16:24 /usr/local/bin/bmake*
7391732 -rwxr-xr-x 1 root wheel 3805840 Sep 18 13:36 /usr/local/bin/cmake*
7386658 -r-xr-xr-x 1 root wheel 112976 Sep 6 2015 /usr/local/bin/dmake*
7384146 -r-xr-xr-x 1 root wheel 224520 Jul 10 18:45 /usr/local/bin/gmake*
7384478 -r-xr-xr-x 1 root wheel24664 May 18 2015 /usr/local/bin/imake*
7386767 -r-xr-xr-x 1 root wheel 2541440 Dec 14 2014 /usr/local/bin/qmake*
7392225 -rwxr-xr-x 1 root wheel 123256 Aug 31 11:03 /usr/local/bin/smake*
7384593 -r-xr-xr-x 1 root wheel32941 May 19 2015 /usr/local/bin/tmake*
So the worrisome one looks like the /usr/bin/bmake, which pershaps should
have been removed by "make delete-old" during an upgrade somewhere along the
way. Let me try renaming it to see what happens. I'll report back.
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
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: buildworld errors at outset on fresh svn checkout
Kevin Oberman <rkober...@gmail.com> wrote:
Thanks much for replying!
> On Thu, Oct 6, 2016 at 10:16 PM, Scott Bennett <benn...@sdf.org> wrote:
>
> > I'm running into a problem in updating my 10-STABLE system from
> > source.
> > A "make buildworld" quits immediately. I tried a fresh svn checkout for
> > base/stable/10 and then tried to run buildworld again, but got the same
> > error.
> > I've been scratching my head over this for hours, but must be missing
> > something
> > simple.
> > I have ccache installed and have been using it for a fairly long time
> > now.
> > My /etc/src.conf contains just two lines:
> >
> > PORTS_MODULES=multimedia/cuse4bsd-kmod sysutils/pefs-kmod #
> > emulators/virtualbox-ose-kmod
> > WITH_LLDB=yes
> >
> > My /etc/make.conf is rather longer, so I'll append it following .sig below.
> >
> > Here's what happens.
> >
> > Script started on Thu Oct 6 23:31:47 2016
> > hellas# cd /usr/src
> > hellas# nice make buildworld
> > Unknown modifier '['
> >
> > "/usr/src/Makefile.inc1", line 1113: Malformed conditional
> > (${BUILDKERNELS:[)
> > Unknown modifier '['
> >
> > "/usr/src/Makefile.inc1", line 1122: if-less endif
> > Unknown modifier '['
> >
> > "/usr/src/Makefile.inc1", line 1144: Malformed conditional
> > (${BUILDKERNELS:[)
> > Unknown modifier '['
> >
> > "/usr/src/Makefile.inc1", line 1161: if-less endif
> > Unknown modifier '['
> >
> > "/usr/src/Makefile.inc1", line 1183: Malformed conditional
> > (${BUILDKERNELS:[)
> > Unknown modifier '['
> >
> > "/usr/src/Makefile.inc1", line 1190: if-less endif
> > bmake: fatal errors encountered -- cannot continue
> > *** Error code 1
> >
> > Stop.
> > make: stopped in /usr/src
> > hellas# exit
> > exit
> >
> > Script done on Thu Oct 6 23:37:00 2016
> >
> > This just started happening after my machine had been down for a
> > couple
> > of days after a hang that damaged stuff in /usr/home. I had already
> > restored
> > /usr/local from backups before narrowing down the weird behavior I was
> > seeing
> > in wmaker to /usr/home corruption. So /usr/home has now been restored to
> > good condition, too, but perhaps I need to restore something else as well.
> > This mess was part of my justification to myself for the fresh checkout of
> > /usr/src, but that doesn't seem to have made any difference in the
> > buildworld
> > failure.
> > If anyone else can see what's wrong and clue me in, I'd be grateful.
> > I'm subscribed to the digest for this list, so please Cc: me directly, so
> > I'll get replies right away.
> > Thanks in advance!
> >
> > [stuff deleted --SB]
>
> Could something else have gotten corrupted?
>
> > ls -i /bin/[
> 65795 /bin/[
> > ls -i /bin/test
> 65795 /bin/test
>
> The values (inode) will not match these, but must be identical.
[hellas] 23 % ls -lgiF /bin/\[ /bin/test
131557 -r-xr-xr-x 2 root wheel 11664 Aug 23 05:16 /bin/[*
131557 -r-xr-xr-x 2 root wheel 11664 Aug 23 05:16 /bin/test*
So no, that's not the problem.
>
> '[' needs to be a hard link to test. I'm suspicious that something happened
> to this link. If this is the case, other corruption may have occurred, but,
> if you can re-create the hardlink (ln /bin/test /bin/[) and successfully
> make buildworld and make buildkernel, it's likely that you can reinstall
> the system and the system will be fine. Of course, things could be damaged
> in the installed ports, too.
Unfortunately, no, I can't re-install, or at least not without restoring
/usr (and probably / and /usr/obj) to before the damage, assuming I can figure
out exactly between which backups the damage occurred, which may not have been
at the time of the hang. I already had a recently built /usr/obj and tried to
install its contents. The failure of installkernel was how I discovered the
problem.
So I'm still stuck.
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
___
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"
buildworld errors at outset on fresh svn checkout
I'm running into a problem in updating my 10-STABLE system from source.
A "make buildworld" quits immediately. I tried a fresh svn checkout for
base/stable/10 and then tried to run buildworld again, but got the same error.
I've been scratching my head over this for hours, but must be missing something
simple.
I have ccache installed and have been using it for a fairly long time now.
My /etc/src.conf contains just two lines:
PORTS_MODULES=multimedia/cuse4bsd-kmod sysutils/pefs-kmod #
emulators/virtualbox-ose-kmod
WITH_LLDB=yes
My /etc/make.conf is rather longer, so I'll append it following .sig below.
Here's what happens.
Script started on Thu Oct 6 23:31:47 2016
hellas# cd /usr/src
hellas# nice make buildworld
Unknown modifier '['
"/usr/src/Makefile.inc1", line 1113: Malformed conditional (${BUILDKERNELS:[)
Unknown modifier '['
"/usr/src/Makefile.inc1", line 1122: if-less endif
Unknown modifier '['
"/usr/src/Makefile.inc1", line 1144: Malformed conditional (${BUILDKERNELS:[)
Unknown modifier '['
"/usr/src/Makefile.inc1", line 1161: if-less endif
Unknown modifier '['
"/usr/src/Makefile.inc1", line 1183: Malformed conditional (${BUILDKERNELS:[)
Unknown modifier '['
"/usr/src/Makefile.inc1", line 1190: if-less endif
bmake: fatal errors encountered -- cannot continue
*** Error code 1
Stop.
make: stopped in /usr/src
hellas# exit
exit
Script done on Thu Oct 6 23:37:00 2016
This just started happening after my machine had been down for a couple
of days after a hang that damaged stuff in /usr/home. I had already restored
/usr/local from backups before narrowing down the weird behavior I was seeing
in wmaker to /usr/home corruption. So /usr/home has now been restored to
good condition, too, but perhaps I need to restore something else as well.
This mess was part of my justification to myself for the fresh checkout of
/usr/src, but that doesn't seem to have made any difference in the buildworld
failure.
If anyone else can see what's wrong and clue me in, I'd be grateful.
I'm subscribed to the digest for this list, so please Cc: me directly, so
I'll get replies right away.
Thanks in advance!
Scott Bennett, Comm. ASMELG, CFIAG
**
* Internet: bennett at sdf.org *xor* bennett at freeshell.org *
**
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
*-- Gov. John Hancock, New York Journal, 28 January 1790 *
**
/etc/make.conf contains:
CPUTYPE?=core2
CFLAGS+="-mtune=core2"
SVNFLAGS?="-r RELENG_10"
# build ports with clang stack protector
WITH_SSP=yes
SSP_CFLAGS=-fstack-protector-all
# added for ports system use to avoid dialogs by SJB 4 May 2007
BATCH=YES
# added for new pkg system --SJB 10 December 2014
WITH_PKGNG=yes
# build ports using ccache --SJB 19 January 2015
WITH_CCACHE_BUILD=yes
## buildworld and buildkernel using ccache --SJB 26 January 2015
.if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*))
.if !defined(NOCCACHE) && exists(/usr/local/libexec/ccache/world/cc)
CC:=${CC:C,^cc,/usr/local/libexec/ccache/world/cc,1}
CXX:=${CXX:C,^c\+\+,/usr/local/libexec/ccache/world/c++,1}
CCACHE_COMPILERCHECK=content
CCACHE_DIR=/buildwork/ccache.freebsd
.endif
.else
CFLAGS+="-mssse3"
#CFLAGS+="-mssse3 -msse4.1"
.endif
# added to deal with ccache bug 8460 --SJB 2 November 2013
# bug has been reported fixed, so try without this workaround
#CCACHE_CPP2=1
# added as a better specification of -j by SJB 17 November 2009
MAKE_JOBS_NUMBER=4
# put build tree where there is plenty of temporary workspace
WRKDIRPREFIX=/buildwork/ports
DEFAULT_VERSIONS+= ssl=openssl
# Allow updating of Mesa3D from 7.4.4 to 7.6.1 and libdrm from 2.4.12 to 2.4.17
WITHOUT_NOUVEAU=yes
# Use ATLAS libraries in ports that use BLAS libraries
OPTIONS_SET=ATLAS
# Tell gnustep-related ports to use base system's compiler
GNUSTEP_WITH_BASE_GCC=yes
GNUSTEP_WITHOUT_LIBOBJC=yes
QT4_OPTIONS= CUPS NAS QGTKSTYLE
# Begin portconf settings
# Do not touch these lines
.if !empty(.CURDIR:M/usr/ports*) && exists(/usr/local/libexec/portconf)
_PORTCONF!=/usr/local/libexec/portconf
.if ${_PORTCONF} != "|"
.for i in ${_PORTCONF:S/^|//:S/|/ /g}
${i:C/^([^=]*)=.*/\1/}=${i:C/^[^=]*=//:S/%/ /g}
.endfor
.endif
.endif
# End portconf settings
___
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"
random problem with 8.3 from yesterday
On Wed, 22 Feb 2012 13:34:36 +0700 Erich Dollansky er...@alogreentechnologies.com wrote: I got a new thumb drive which was FAT formatted. I use this script to change this: !/bin/tcsh # # This script format a thumb drive connected to USB as da0. # printf You have to run this script as 'root' to succeed.\n printf Warning this script will delete all your data from /dev/da0. Continue? set Eingabe = $ if ($Eingabe == y) then printf \nDeleting the device dd if=/dev/zero of=/dev/da0 bs=1k count=1 printf \nWriting the BSD label bsdlabel -Bw da0 auto Hmmm...so no MBR and no GPT either? Just the bare device? I guess I haven't tried that, so I don't know what that would do. printf \nEditing the BSD label bsdlabel -e da0 newfs /dev/da0a printf \nThe device /dev/da0 was formated to be used with FreeBSD.\n else printf \nScript aborted!\n endif I then call manually tunefs -L NewDeviceName /dev/da0a Just out of curiosity, I'd like to know why you run tunefs manually, rather than using -L NewDeviceName on the newfs command, given that your script is clearing the physical device and then creating an empty file system. Either this call or the mount command does not work randomly. When I then try to mount the device on /dev/da0a it does not work always. What do you mean when you write mount the device on /dev/da0a? Normally one mounts a filesystem onto a device, e.g., mount /dev/ad0s1d /var or some similar thing. Also, why do you refer to /dev/da0a at all if you labeled the file system? The whole point of labeling the file system is supposed to be so that you can mount it independently of the physical device name, e.g., mount /dev/ufs/NewDeviceName /thumbfs which allows you to have an entry in /etc/fstab for mounting the file system that doesn't need to be edited every time you reboot the system or move devices around. I do not know what this causes, I am only randomly able to reproduce it. It might be affected by removing the device or keeping it plugged in. Well, yes, that's what you label partitions/devices to avoid having to deal with manually, right? uname says: FreeBSD AMD620.ovitrap.com 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #28: Tue Feb 21 17:15:07 WIT 2012 er...@amd620.ovitrap.com:/usr/obj/usr/src/sys/AsusAMD620 amd64 dmesg says: ugen1.2: vendor 0x1005 at usbus1 umass0: vendor 0x1005 USB FLASH DRIVE, class 0/0, rev 2.00/1.00, addr 2 on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x4001 umass0:2:0:-1: Attached to scbus2 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: USB FLASH DRIVE PMAP Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 15272MB (31277056 512 byte sectors: 255H 63S/T 1946C) It is not an urgent problem. It most likely is not a problem at all. See http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/geom-glabel.html#AEN27470 With best regards, Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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: random problem with 8.3 from yesterday
On Sat, 25 Feb 2012 08:56:24 -0800 Kevin Oberman kob6...@gmail.com wrote: On Sat, Feb 25, 2012 at 2:27 AM, Scott Bennett benn...@cs.niu.edu wrote: =A0 =A0 On Wed, 22 Feb 2012 13:34:36 +0700 Erich Dollansky er...@alogreentechnologies.com wrote: I got a new thumb drive which was FAT formatted. I use this script to cha= nge this: !/bin/tcsh # # This script format a thumb drive connected to USB as da0. # printf You have to run this script as 'root' to succeed.\n printf Warning this script will delete all your data from /dev/da0. Cont= inue? set Eingabe =3D $ if ($Eingabe =3D=3D y) then =A0 printf \nDeleting the device =A0 dd if=3D/dev/zero of=3D/dev/da0 bs=3D1k count=3D1 =A0 printf \nWriting the BSD label =A0 bsdlabel -Bw da0 auto =A0 =A0 Hmmm...so no MBR and no GPT either? =A0Just the bare device? =A0I= guess I haven't tried that, so I don't know what that would do. Call me a bit confused, but I thought -B did write an MBR. It always has seemed to do so for me, at any rate. From man bsdlabel: Installing Bootstraps If the -B option is specified, bootstrap code will be read from the fi= le /boot/boot and written to the disk. Or am I not understanding something? I guess I understand the part that you quoted above as meaning that the bootstrap code would be copied to the bootstrap sectors. However, as I interpret it, the bsdlabel command does not write a MBR, which would include the slice map for the device. Further, Erich's later commands did not specify a slice number. In short, it looks to me as though he may have ended up with the initial boot code where it belonged at the start of the device, but the boot code looks for the slice map, which isn't there, so it should not be possible to boot a kernel because the bootstrap code would not be able to find it. But as far as simply mounting a file system, I really don't know whether it should work to have a BSD label written to a bare device with neither a MBR nor a GPT to find that label. IOW, would the device node to be used in the mount operation have been created? Note to Erich: did you look in /dev and /dev/ufs to see whether all of the device files that you expected to be there were, in fact, present before you attempted the mount? Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ 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
