Re: Skylake/HD graphics support
On Sun, 13 Nov 2016, Daniel Campos do Nascimento wrote: Hello, First time posting on a mailing list... I currently have 11.0-STABLE installed on my laptop which has a Core i7-6500U. I can't get Xorg-server to work neither with xf86-driver-intel, nor with i915kms driver; I'm falling back on the scfb driver. I would like to know how the situation is with 12.0-CURRENT regarding graphics? TrueOS.org is FreeBSD-current (yes, a rolling release) plus the latest video driver work that is not in -current plus some other things like LibreSSL. It worked on a Core M Broadwell tablet, but I have not really tested it thoroughly. It is supports Skylake, but my only Skylake machine has a Radeon board and is running plain -current. This was formerly called PC-BSD, but it has changed name and design lately. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Destroy GPT partition scheme absolutely, how?
On Mon, 26 Sep 2016, John Baldwin wrote: On Tuesday, September 27, 2016 12:36:22 AM Ngie Cooper wrote: On Sep 26, 2016, at 22:48, Ernie Luzar wrote: ... This little script has been posted before. Maybe it will be what your looking for. Called gpart.nuke #! /bin/sh echo "What disk do you want" echo "to wipe? For example - da1 :" read disk echo "OK, in 10 seconds I will destroy all data on $disk!" echo "Press CTRL+C to abort!" sleep 10 diskinfo ${disk} | while read disk sectorsize size sectors other do # Delete MBR and partition table. dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} count=1 # Delete GEOM metadata. dd if=/dev/zero of=/dev/${disk} bs=${sectorsize} oseek=`expr $sectors - 2` count=2 done Why not just use "gpart destroy -F provider"? That doesn't always work. In particular, if a disk was partitioned with GPT and then you use normal MBR on it afterwards, the 'gpart destroy -F' of the MBR will leave most of the GPT intact and the disk will come up with the old GPT partitions, not as a raw disk. Right. So do a gpart destroy -F of whatever is on there, ignoring errors, then a gpart create -s gpt. Now there is definitely a secondary GPT, and a final gpart destroy -F removes it cleanly. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r300951: mountroot: waiting for device /dev/ad4s1a...
On Sat, 4 Jun 2016, Matthias Apitz wrote: El día Saturday, June 04, 2016 a las 02:41:48PM +0200, Michael Gmelin escribió: It's also covered in UPDATING: 20151011: Compatibility shims for legacy ATA device names have been removed. It includes ATA_STATIC_ID kernel option, kern.cam.ada.legacy_aliases and kern.geom.raid.legacy_aliases loader tunables, kern.devalias.* environment variables, /dev/ad* and /dev/ar* symbolic links. Next time I will do read UPDATING. Thanks for your help. Use labels so there are no static device names at all. With MBR, the options are limited, but UFS labels work and have no metadata problems: http://www.wonkity.com/~wblock/docs/html/labels.html GPT has very nice partition labels that can be set with gpart -l. It works with i386 and BIOS booting. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: UEFI dual boot zfs root
On Sun, 15 May 2016, Andreas Nilsson wrote: Hello, I'm trying to install current on my lenovo x1 yoga ( and keeping it dual boot for now). I have a fair amount of disk free after resizing. I can't seem to workout how to do the partitioning. Do I only need the freebsd-zfs partition ( assuming no/zvol-swap? I would think, but have not tested ZFS with UEFI. Do I manually copy boot1.efi to the existing EFI partition? Yes. Mount the EFI partition with msdosfs, then copy boot1.efi to /EFI/BOOT/. Then comes the tricky part, getting the UEFI firmware to add that as a boot option. In a Dell UEFI system, it could be added to the boot options, and the firmware has the user select the file from the EFI partition for that option. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
CAM I/O Scheduler (was Re: FreeBSD Quarterly Status Report - First Quarter 2016 (fwd))
On Tue, 3 May 2016, Johan Hendriks wrote: Op 02/05/16 om 02:49 schreef Warren Block: CAM I/O Scheduler Links I/O Scheduling in FreeBSD's CAM Subsystem (PDF) URL: https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf The BSDCan 2015 Talk URL: https://www.youtube.com/watch?v=3WqOLolj5EU Contact: Warner Losh An enhanced CAM I/O scheduler has been committed to the tree. By default, this scheduler implements the old behavior. In addition, an advanced adaptive scheduler is available. Along with the scheduler, SATA disks can now use Queued Trims with devices that support them. Details about the new scheduler are available in the I/O Scheduling in FreeBSD's CAM Subsystem article (PDF) or from the BSDCan 2015 talk. I updated my source today, but CAM_ADAPTIVE_IOSCHED yields an error about an unknown option. If I use CAM_NETFLIX_IOSCHED the kernel compiles. Is the name CAM_NETFLIX_IOSCHED changing to CAM_ADAPTIVE_IOSCHED? That is my understanding, yes. Warner can certainly explain it better than I can, so CCed. Thanks! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD Quarterly Status Report - First Quarter 2016 (fwd)
Introduction The first quarter of 2016 showed that FreeBSD retains a strong sense of ipseity. Improvements were pervasive, lending credence to the concept of meliorism. Panegyrics are relatively scarce, but not for lack of need. Perhaps this missive might serve that function in some infinitesimal way. There was propagation, reformation, randomization, accumulation, emulation, transmogrification, debuggenation, and metaphrasal during this quarter. In the financioartistic arena, pork snout futures narrowly edged out pointilism, while parietal art remained fixed. In all, a discomfiture of abundance. View the rubrics below, and marvel at their profusion and magnitude! Marvel! --Warren Block __ Please submit status reports for the second quarter of 2016 by July 7. A thesaurus will be provided for submitters who do not have one of their own. We will need them back afterwards, preferably with no new teeth marks on the covers. Thank you! __ FreeBSD Team Reports * Cluster Admin * The FreeBSD Core Team Projects * Address Space Layout Randomization * Ceph on FreeBSD * Process-Shared Locks for libthr * RCTL Disk IO Limits * The Graphics Stack on FreeBSD Kernel * ARM Allwinner SoC Support * CAM I/O Scheduler * FDT Overlay Support in UBLDR * Filemon Performance/Stability Improvements * FreeBSD Integration Services (BIS) * Infiniband * MMC Stack Under CAM Framework * NFS Server * Static Analysis of the FreeBSD Kernel with PVS Studio Architectures * AmigaOne X5000 Support * FreeBSD on Cavium ThunderX (arm64) * powerpcspe Target Userland Programs * ELF Tool Chain Tools * Native PCI-express HotPlug * Updates to GDB * Using lld, the LLVM Linker, to Link FreeBSD Ports * GitLab Port * GNOME on FreeBSD * KDE on FreeBSD * Obsoleting Rails 3 * Ports Collection Documentation * New FreeBSD Mastery Books * Spanish FAQ and Chinese Porter's Handbook Translations Miscellaneous * FreeBSD Build * Qt 5.6 on Raspberry Pi * The FreeBSD Foundation __ FreeBSD Team Reports Cluster Admin Contact: This quarter, we: * migrated services out of the hosting space in ISC (peter, sbruno) * began migration of services into the RootBSD hosting space (peter, sbruno) * collaborated with the phabricator admin team to migrate to a new and improved host in NYI. (allanjude, peter, sbruno) * installed a new and beefier Jenkins machine (gnn, lwshu, sbruno) * are still looking for more Asian mirrors for pkg, svn, and ftp (Japan, India). (sbruno) * completed the migration of the Taiwanese mirror to its new location. (lwshu) * started hosting a clang/llvm buildbbot in the FreeBSD cluster at NYI (sbruno, emaste) * resolved a UK mirror outage with Bytemark (gavin, peter) __ The FreeBSD Core Team Contact: FreeBSD Core Team During the first quarter of 2016, the most important business of the FreeBSD Core Team has been to respond to the harassment incident last year. Core's actions were to assemble a timeline of the events and in the light of that to review Core's actions at the time; and to make recommendations about how better to handle such cases in future. During this process, draft reports were reviewed by people concerned in the case and in addition a number of interested members of the FreeBSD community. Core would like to thank everyone involved for their contributions. The report was published to the FreeBSD developer community in mid-February, and contained six recommendations for the community to consider. Core is also coordinating with the committee headed by Anne Dickison who are reviewing the Code of Conduct. A corpus of case studies is being assembled, which will be re-examined to see what impact changes to the Code of Conduct would have had. Core, together with John Baldwin, are working on a plan to create a separate repository containing GPLv3 toolchain components. This will allow modernization of code within base beyond what the existing GPLv2 toolchain can handle, and permit support of certain new architectures where a copyfree licensed alternative (i.e., LLVM) is not yet available. A position paper will soon be circulated to developers for comment. During this quarter three new commit bits were issued, and one was returned for safekeeping. Please welcome Wojciech Macek, Jared McNeil and Stanislav Galabov, and bid farewell to Davide Italiano, who altho
Re: qsort() documentation
On Tue, 19 Apr 2016, Aleksander Alekseev wrote: Why Wikipedia, specifically? There are a lot of places that describe quicksort. How about just Note: This implementation of qsort() is designed to avoid the worst-case complexity of N**2 that is often seen with standard versions. I would say that this statement is just false. Worst-case complexity is still N**2. How about something like: """ This implementation of qsort() has worst case complexity of N**2. However measures were taken that make it very unlikely that for some random input N**2 swaps will be made. It's still possible to generate such an input on purpose though. See code below for more details. """ Okay: The quicksort algorithm worst-case is O(N**2), but this implementation has been designed to avoid that for most real data. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: qsort() documentation
On Mon, 18 Apr 2016, Hans Petter Selasky wrote: Hi, Are there any objections adding the following as part of documenting our kernel's qsort function? Index: sys/libkern/qsort.c === --- sys/libkern/qsort.c (revision 298202) +++ sys/libkern/qsort.c (working copy) @@ -45,6 +45,10 @@ /* * Qsort routine from Bentley & McIlroy's "Engineering a Sort Function". + * + * NOTE: This implementation of qsort() was designed to not have the "was designed to avoid the" + * worst case complexity of N**2, as seen with the regular quick sort + * functions as described by Wikipedia. */ Why Wikipedia, specifically? There are a lot of places that describe quicksort. How about just Note: This implementation of qsort() is designed to avoid the worst-case complexity of N**2 that is often seen with standard versions. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Heads up
On Thu, 14 Apr 2016, Warner Losh wrote: On Thu, Apr 14, 2016 at 9:56 PM, Warren Block wrote: On Thu, 14 Apr 2016, Warner Losh wrote: The CAM I/O scheduler has been committed to current. This work is described in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the default scheduler doesn't change the default (old) behavior. One possible issue, however, is that it also enables NCQ Trims on ada SSDs. There are a few rogue drives that claim support for this feature, but actually implement data corrupt instead of queued trims. The list of known rogues is believed to be complete, but some caution is in order. Is the list of drives queryable? Is there an easy way to tell if the currently-connected drives are on the list? /usr/src/sys/cam/ata/ata_da.c has the list. dmesg will tell you if it detected a bad one since it prints the drive's quirks. But that's no big deal, because the bad one work just fine if you never issue a NCQ TRIM. This small group of drives were early adapters of this technology Here's the full list of known rogues: Crucial/Micron M500 (all firmware prior to MU07) Micron M510 MU01 firmware (newer firmware is good) Crucial/Micron M550 MU01 firmware (newer firmware is good) Crucial MX100 MU01 firmware (newer firmware is good) FCCT M500 all firmware Samsung 830 all firmware Samsung 840 all firmware Samsung 850 all firmware All of these are at least 18 months old (if not older). There's some confusing in Linux lists on the full impact of the Samsung drives (there was a bug in the Linux implementation (that can't be present in the FreeBSD implementation) that may have been the root cause for the Samsung black listing). Out of an abundance of caution, I've kept them in the list. Also, it's my belief that the Crucial/Micron models with MU01 firmware were mostly corrected after early samples since most of the channel drives I've helped people debug had MU02 firmware. Also, a quick google search shows the MU02 firmware for each of these models has been available for at least a year. After updating a Dell E7240, booting showed a bunch of FPDMA errors and then panicked after about 30 seconds. The SSD is a Samsung PM851 mSATA drive with firmware EXT4AD0Q. I believe this is the OEM version of the Samsung 840 Evo. According to the Dell support page, the machine shipped on January 22, 2015. So while the drive might not have been manufactured in a while, Dell was still using them that recently. Note that this is a used machine, I have only had it a week. After booting with mfsBSD, a quick fsck, and setting kern.cam.ada.0.quirks=0x2 in /boot/loader.conf, it came up without errors and appears to be working normally. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Heads up
On Thu, 14 Apr 2016, Warner Losh wrote: The CAM I/O scheduler has been committed to current. This work is described in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the default scheduler doesn't change the default (old) behavior. One possible issue, however, is that it also enables NCQ Trims on ada SSDs. There are a few rogue drives that claim support for this feature, but actually implement data corrupt instead of queued trims. The list of known rogues is believed to be complete, but some caution is in order. Is the list of drives queryable? Is there an easy way to tell if the currently-connected drives are on the list? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
D3702: add support for Bluetooth Magic Mouse
Is anyone working on Bluetooth stuff? https://reviews.freebsd.org/D3702 adds support for the Apple Magic Mouse, and has been tested and reported working: https://lists.freebsd.org/pipermail/freebsd-bluetooth/2016-April/002053.html Could someone please review and commit this? Thanks! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Need some help with ports and rebuilding the world
On Wed, 30 Mar 2016, Aleksander Alekseev wrote: CPUTYPE?=native CFLAGS+=-O2 -pipe CXXFLAGS+=-O2 -pipe These will bite with no provocation, and prevent ports that want to set their own flags from using them. Frankly as a rule of thumb I prefer binary packages. But how would you recommend to change these lines? You see if I use ports I would like compiled code to be optimized and preferably for local CPU. Don't set them at all, just remove those lines from make.conf. Well, let me be more specific. It is probably safe to set CPUTYPE, although choosing native has caused problems for me, where specifically setting a type like core-avx2 has been fine. It is just the CFLAGS and CXXFLAGS that are best not set. When not set, the world and kernel build will use safe defaults, but ports that can safely override those flags for better performance can do so. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Need some help with ports and rebuilding the world
On Tue, 29 Mar 2016, Aleksander Alekseev wrote: Do you still have your old make.conf for comparison? Sure. Current make.conf: ``` CPUTYPE?=native CFLAGS+=-O2 -pipe CXXFLAGS+=-O2 -pipe These will bite with no provocation, and prevent ports that want to set their own flags from using them. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Need some help with ports and rebuilding the world
On Mon, 28 Mar 2016, Aleksander Alekseev wrote: I think I realized what's going on. I probably rebuilded the world on two different machines but forgot to do it on this one. I will re-check this and report results a bit later. OK, here is a problem. I can't upgrade the world because of compile errors I mentioned before: http://lpaste.net/948188758727983104 This issue reproduces with both CLang 3.6 and new CLang compiled manually from trunk (I created symlinks clang++-3.9 and clang-cpp-3.9 to clang-3.9 and it solved my problem with CLang I mentioned before). Did you erase /usr/src before checking out -CURRENT? Obsolete files left in there can easily break things. 'svn stat /usr/src' will show those files with a '?'. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: question on support processor Intel Atom Z3735F
On Fri, 25 Mar 2016, Lundberg, Johannes wrote: One problem is that most of these devices have only 32 bit UEFI which FreeBSD does not support (except Intel Compute Stick which has 64 bit UEFI). The MinnowBoard has both 32-bit and 64-bit UEFI. My Turbot came with 64-bit UEFI, and the FreeBSD amd64 UEFI install image works fine with it. This is an Atom E3826 board. I use special built Grub to boot a 64 bit Arch Linux on this chip, maybe same approach could be used to boot a 64 bit FreeBSD. However, you probably won't be able to use the internal eMMC (if your device got it) since the controller can not initiate mmc memory correctly. Work in progress here though by me and Ilya. On a side note, it would though be nice to have 32 bit UEFI support on FreeBSD because that would include support for Intel IoT boards like Galileo etc which are all 32 bit. Might be a lot of work though.. If any existing 32-bit Linux UEFI loader could be made to work with FreeBSD (possibly chainloading?), that would be better than nothing. I would like to have the opposite method also, having a 64-bit UEFI boot a 32-bit FreeBSD. (Why? So my run-on-anything 32-bit FreeBSD image could still work on any UEFI system.) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: boot loaders got fatter in the last few days
On Fri, 18 Mar 2016, Guido Falsi wrote: On 03/18/16 17:54, José Pérez wrote: Hi Guido, maybe it's because of this: https://svnweb.freebsd.org/base?view=revision&revision=296963 I see. There is a problem with this though, we have howtos suggesting 64K for the size of the freebsd-boot gpt partition: https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 now that size isn't sufficient anymore. We should at least update these information soon. I have always recommended using the largest possible size for the bootcode partition, 512K. There is no reason to go with a smaller size, the space savings are insignificant. It is safe to guess that bootcode will never get smaller. I also recommend starting the first real partition at 1M. This also is frequently ignored. Here are my instructions: http://www.wonkity.com/~wblock/docs/html/disksetup.html The wiki should be updated. Better yet, that section should be removed and the corrected procedure shown in the Handbook. Also repartitioning could be problematic in certain scenarios. I think this change should be at least published in UPDATING and maybe also in the future release notes for 11.0. Personally I'll find a way of reorganizing my disks to fit this change, but it's something that could byte users. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] packaging the base system with pkg(8)
On Sun, 6 Mar 2016, Glen Barber wrote: On Sun, Mar 06, 2016 at 12:39:57PM +0100, Baptiste Daroussin wrote: On Thu, Mar 03, 2016 at 10:27:00AM +, Matthew Seaman wrote: On 03/02/16 23:54, Glen Barber wrote: Also note (as repeated below), running 'pkg delete -a' will implicitly remove base system packages after they are installed. This has the potential for many feet to be shot, given that up to now, 'pkg delete -a' would always leave you with a viable system. We already make an exception for pkg itself -- you need 'pkg delete -fa' to actually remove pkg(8) as well. (Note to self: this needs to be documented in the pkg-delete(8) man page.) We should have similar exceptions for the essential bits of the base system -- at minimum everything you need to boot the system up and install stuff from a package repository. We should also have a command line that will remove all ported software but leave the base intact. Maybe by adding '-r reponame' functionality to 'pkg delete'? It is planned to have a "precious" flag for packages which will prevent pkg delete -a from dropping them Note, there are valid use cases for deleting all packages, even those marked as 'precious'. For example, a test chroot(8) or jail(8). So the 'precious' flag would also need an override. # pkg delete -f --delete-my-precious-yes-i-know-just-do-it-already -a ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVE-2015-7547: critical bug in libc
On Thu, 18 Feb 2016, Kubilay Kocak wrote: On 18/02/2016 3:51 AM, Warren Block wrote: On Wed, 17 Feb 2016, Eric van Gyzen wrote: On 02/17/2016 08:19, Warren Block wrote: On Wed, 17 Feb 2016, Kurt Jaeger wrote: A short note on the www.freebsd.org website would probably be helpful, as this case will produce a lot of noise. Maybe a short article like we did for leap seconds? https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html Articles are permanent, which makes sense for the recurring issue of leap seconds. This vulnerability is transient, so I would suggest a news item. Yes, but news items are usually just links. For the amount of information we have so far, an article seems like the easiest way to do this. Or maybe an addition to the security part of the web site? For now, I'll collect the information as just text. Don't we also want our sec teams to investigate/confirm it anyway, independent of how it's communicated? Absolutely. If so, doesn't a security advisory (with secteam and/or ports-secteam as appropriate) make the most sense here, given the scope of vulnerability for base/linux emulation/ports is yet to be completely established and is still to be investigated properly? Have there been security advisories for unconfirmed or not-actually-a-problem events before? My impression was that they have only been announced when a problem exists and action needs to be taken. However, a real problem *does* exist for Linux VMs and applications on FreeBSD, so it could be addressed that way. A "we are investigating" advisory right now could do some good, if the protocols allow it. Finally, would users expect a news item, an article or a heads up from our security teams for something like this, even in the case where it's only a "confirmed we're not affected" ? A news item linking to a "it's not us!" advisory would be no problem. People have to go looking for that. Those who are subscribed to the security mailing list will receive those notices directly, and because those are expected to be problems that need to be addressed immediately, it might cause some initial palpitations as if it were an actual problem with FreeBSD. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVE-2015-7547: critical bug in libc
On Wed, 17 Feb 2016, Eric van Gyzen wrote: On 02/17/2016 08:19, Warren Block wrote: On Wed, 17 Feb 2016, Kurt Jaeger wrote: A short note on the www.freebsd.org website would probably be helpful, as this case will produce a lot of noise. Maybe a short article like we did for leap seconds? https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html Articles are permanent, which makes sense for the recurring issue of leap seconds. This vulnerability is transient, so I would suggest a news item. Yes, but news items are usually just links. For the amount of information we have so far, an article seems like the easiest way to do this. Or maybe an addition to the security part of the web site? For now, I'll collect the information as just text. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: CVE-2015-7547: critical bug in libc
On Wed, 17 Feb 2016, Kurt Jaeger wrote: Hi! The project that's vulnerable is called "glibc", not "libc". The BSDs don't use glibc, so the phrase "nothing to see here" applies. glibc isn't even available in FreeBSD's ports tree. TL;DR: FreeBSD is not affected by CVE-2015-7547. What about software that uses emulators/linux_base? A short note on the www.freebsd.org website would probably be helpful, as this case will produce a lot of noise. Maybe a short article like we did for leap seconds? https://www.freebsd.org/doc/en_US.ISO8859-1/articles/leap-seconds/article.html I can help with that. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Aw: Re: No X on Dell E6540
On Tue, 15 Dec 2015, Carsten Kunze wrote: Hello Michael, It looks like that is a machine with Haswell integrated graphics. Haswell graphics has not yet landed in CURRENT but there is a development branch availible for testing. https://wiki.freebsd.org/Graphics/Update%20i915%20GPU%20driver%20to%20L inux%203.8 there is also an additional AMD graphics card in this laptop (AMD Radeon HD 8790M). Is this supported by CURRENT? The vesa driver can be run on most systems where the newer graphics are not directly supported. See the last example here: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x-config.html#x-config-video-cards-file ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Depreciate and remove gbde
On Mon, 19 Oct 2015, John-Mark Gurney wrote: Ed Maste wrote this message on Mon, Oct 19, 2015 at 17:13 -0400: On 19 October 2015 at 16:50, John-Mark Gurney wrote: O. Hartmann wrote this message on Mon, Oct 19, 2015 at 06:19 +0200: For me, I'd like to know what is the benefit/performance of each technique and a clear preparation of each ones advantages over the other. That would make the decission process much easier and hopefully would not scare people away and announce "FreeBSD does not have a, b, c, ..." ... So, one thing that the docs talk about is that geli uses the crypto(9) framework. This doesn't mean much on it's own, but if you have a machine with AES-NI instructions or an accelerator card that supports the cipher mode used, then you can get faster performance of hardware off load, while gbde uses the software only routines which are slow.. John-Mark, thanks for listing these differences. This is the sort of information we should have available for end users to help choose one or the other -- this info ought to make it into the handbook. I'm working on updating the section now... Also realized we should include verbage to say that it's best to use page size sectors when possible to reduce overhead of the crypto... I can help with markup and editing. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Buildworld ccache support
On Thu, 15 Oct 2015, Bryan Drewery wrote: Hi, If you are interested in using ccache in buildworld please consider using this patch locally and giving me some feedback. The current advice for ccache+buildworld (the CC:= trick in make.conf) actually results in the build thinking you are using a cross-compiler which results in unintended side-effects. It also doesn't work with meta mode as it handles CC and toolchain differently. This patch intends to cover all cases. https://people.freebsd.org/~bdrewery/patches/world-ccache.diff To use just set WITH_CCACHE_BUILD= in src.conf or make.conf. I purposely matched it to the same as the ports build. Will this work on -stable? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: em broken on current amd64
On Sat, 12 Sep 2015, Mark R V Murray wrote: I just caught this, on today’s build: em0: Watchdog timeout Queue[0]-- resetting Interface is RUNNING and ACTIVE em0: TX Queue 0 -- em0: hw tdh = 127, hw tdt = 139 em0: Tx Queue Status = -2147483648 em0: TX descriptors avail = 1012 em0: Tx Descriptors avail failure = 0 em0: RX Queue 0 -- em0: hw rdh = 0, hw rdt = 1023 em0: RX discarded packets = 0 em0: RX Next to Check = 0 em0: RX Next to Refresh = 1023 [graveyard] /usr/ports 09:42 pm # uname -a FreeBSD graveyard.grondar.org 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r287705: Sat Sep 12 15:07:54 BST 2015 r...@graveyard.grondar.org:/b/obj/usr/src/sys/G_AMD64_GATE amd64 That happened on an amd64 10-STABLE (r287148) system here a couple of days ago. Both I217-V and 82574L cards in that system, but I did not save the message and can't say which had the error. Never seen before, has not happened again. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ramblings.. or not
On Fri, 28 Aug 2015, Lars Engels wrote: On Thu, Aug 27, 2015 at 02:31:21PM -0700, Craig Rodrigues wrote: On Wed, Aug 26, 2015 at 8:44 PM, Julian Elischer wrote: We should also do a better job of productising and incorporating GSOC work.. Definitely! It's sad to see people put a lot of working into something via GSOC, and then have the work die on the vine once the summer is over. There's a lack of communication. Every year we have GSOC students working on a part of FreeBSD, but after GSOC is over nothing happens. Some code goes into base quietly, some good code may be lurking in an external repository but nobody knows. My proposal is that every student and mentor should write a short summary of the work done and if was already committed to the tree or why it hasn't been committed. That is an excellent idea. Isn't something like that already submitted to Google at the end of the project? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for FreeBSD 2015Q2 (April-June) Status Reports
Have you submitted your quarterly report yet? People need to know about the cool things being done with, or to, or by FreeBSD. In an effort that will surely never come back to haunt us all, I have committed all the reports I saw in monthly@ to the upcoming status report. However, I am also easily distracted by shiny objects and might have missed some. If you have not yet received a passive-aggressive "thanks" mail, please make sure your report is included here: https://svnweb.freebsd.org/doc/head/en_US.ISO8859-1/htdocs/news/status/report-2015-04-2015-06.xml?view=markup If your report is missing or not present, please resubmit to b...@freebsd.org, mont...@freebsd.org, and cc me at wbl...@freebsd.org. The deadline is July 14 (yes, today), but of course some of us would rather wait than miss interesting reports. Or dull ones, to be honest. But there is an interesting report lurking inside even the dull ones. Particularly if some words are replaced with others. Assistance in polishing a bare list of feats into a truly Herculean accomplishment can be provided on a limited-time, first-come first-serve, contents may have settled during shipment basis. Grammer can be goodered and Englished up, too. On Wed, 8 Jul 2015, Benjamin Kaduk wrote: Dear FreeBSD Community, Only one week remains before the deadline to submit entries for the next FreeBSD Quarterly Status update -- the deadline is July 14, 2015, for work done in April through June. Status report submissions do not have to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about what you're working on. Submission of reports is not restricted to committers. Anyone doing anything interesting and FreeBSD-related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly at freebsd.org . There is also an XML template [2] which can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We are looking forward to all of your 2015Q2 reports! Thanks, Ben (on behalf of monthly@) [1] http://www.freebsd.org/cgi/monthly.cgi [2] http://www.freebsd.org/news/status/report-sample.xml [3] http://www.freebsd.org/news/status/howto.html [4] http://www.freebsd.org/news/status/report-2014-10-2014-12.html [5] http://www.freebsd.org/news/status/report-2015-01-2015-03.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lenovo BIOS boot fix
On Mon, 13 Jul 2015, Adrian Chadd wrote: But the problem here is that we're using GPT but /not/ UEFI, right? That's why that's all a mess? If you have a GPT layout, but it boots on a BIOS machine, the missing active flag on a standards-correct PMBR partition usually does not keep it from booting. Usually. The Lenovo thing is just a bug, firmware that sees GPT and automatically assumes that a GPT disk has all the UEFI features (extra partitions and security and cryptography and all that). That is wrong. Lenovo can fix it, and there should be villagers with pitchforks at their gates politely requesting that they fix it for these still-broken models like they have for other models. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lenovo BIOS boot fix
On Mon, 13 Jul 2015, Adrian Chadd wrote: I'm really confused. Why is the active flag not set again? I thought that was the whole point of the active flag in the partition table. At one point, smart people explained this to me. My fault if I do not remember it correctly (not that it will stop me from attempting an explanation): MBR partitions have active flags. The BIOS is supposed to boot from the one that is set active. It is not required that one be set active, though. Most BIOS systems will still boot without any MBR partitions set active, presumably from the first partition. The PMBR on a GPT disk is a simulation of an MBR. However, according to the GPT standard, that simulated first MBR partition in the PMBR must not be set active. A strict UEFI implementation will *not* boot if there is an active flag set for a PMBR partition. Earlier versions of the FreeBSD PMBR had the PMBR partition set active, which was wrong. The current version is correct. I'm fairly sure we've seen people with both problems on the mailing lists and in the forums: BIOS systems that would not boot without an MBR partition set active, and UEFI systems that would not boot when a PMBR partition was set active. They are rare, but it goes to prove you can't win. (To fix old, incorrect FreeBSD PMBR versions, gpart can be used to set the "active" property on the GPT disk itself, which clears an active flag set on a PMBR partition. So the problem should already be fixed, but this is the "set active" we are talking about.) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lenovo BIOS boot fix
On Mon, 13 Jul 2015, Kevin Oberman wrote: This is possibly orthogonal and possibly not of use on X2nn systems, but I boot my T520 with a GPT formatted disk as the secondary drive by having the MBR disk0 configured with booteasy and telling it to boot disk1. While this is of no use on single spindle systems like the X220, I have been told that a MBR USB drive can be used to do the same thing. I have not tried this and can't confirm, though. Clearly a kludge work-around, but better than nothing and works well for me as I have always left Windows on the main drive and put FreeBSD on the removable one. Please, whoever has one of these systems, find a contact address for Lenovo. It should be on every one of these messages, and we should be encouraging every affected user to contact Lenovo support. I can post it in the forums, also. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lenovo BIOS boot fix
On Mon, 13 Jul 2015, Allan Jude wrote: On 2015-07-13 14:08, Warren Block wrote: On Mon, 13 Jul 2015, Allan Jude wrote: On 2015-07-13 11:19, Warren Block wrote: Needing the active flag set is indeed a different problem. I am working on a patch for bsdinstall that will allow the user to request the active bit be set as well. For GPT, that should be the default, because it matches the standard. I would like to see an effort to get Lenovo to fix their broken UEFI/BIOS. Adding non-standard PMBR configurations should be short-term hack. Lenovo has fixed the issue in newer models, x230, t530, t540 etc work fine. Just the x220, t420, and t520 etc series do not. The latest BIOS update for the x220 was less than two months ago, so it is still supported. That they've fixed the problem in other models shows they understand the issue. So owners of those models should be bugging Lenovo, so to speak. Long-term, it seems like they as a company would be concerned that special bug fixes naming their specific models are needed. Short-term, we probably can't avoid this. It would be nice to be able to remove a Lenovo-specific hack from gpart in the future with a commit that says "Fixed by Lenovo BIOS update #123, no longer needed". I tried the latest bios update for the X220, from 2015-05-27 It does not resolve the issue. Also, it required some hoop jumping, as they only provide a bootable cd (x220s do not have CD drives) and a windows program. However, if others are interested, this handy perl script: http://userpages.uni-koblenz.de/~krienke/ftp/noarch/geteltorito/ can be used to extract the el torito image from that .iso to a file, that can then be dd'd to a USB stick and update the bios. Sorry, I did not mean to imply that the latest X220 BIOS fixed the problem, just that they were continuing to release BIOS updates for it and could not disown responsibility by saying the system was no longer supported. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lenovo BIOS boot fix
On Mon, 13 Jul 2015, Allan Jude wrote: On 2015-07-13 11:19, Warren Block wrote: Needing the active flag set is indeed a different problem. I am working on a patch for bsdinstall that will allow the user to request the active bit be set as well. For GPT, that should be the default, because it matches the standard. I would like to see an effort to get Lenovo to fix their broken UEFI/BIOS. Adding non-standard PMBR configurations should be short-term hack. Lenovo has fixed the issue in newer models, x230, t530, t540 etc work fine. Just the x220, t420, and t520 etc series do not. The latest BIOS update for the x220 was less than two months ago, so it is still supported. That they've fixed the problem in other models shows they understand the issue. So owners of those models should be bugging Lenovo, so to speak. Long-term, it seems like they as a company would be concerned that special bug fixes naming their specific models are needed. Short-term, we probably can't avoid this. It would be nice to be able to remove a Lenovo-specific hack from gpart in the future with a commit that says "Fixed by Lenovo BIOS update #123, no longer needed". ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lenovo BIOS boot fix
Needing the active flag set is indeed a different problem. I am working on a patch for bsdinstall that will allow the user to request the active bit be set as well. For GPT, that should be the default, because it matches the standard. I would like to see an effort to get Lenovo to fix their broken UEFI/BIOS. Adding non-standard PMBR configurations should be short-term hack. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Newer yacc needed for building world
On Wed, 22 Apr 2015, Willem Jan Withagen wrote: Hi, [I thought that I've seen talk about this before.] On a customers system I'm trying to build a new world, with a fresh tree. I've deleted lines from other tracks in parallel compilation. --- aslcompilerparse.c --- yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f - maximum table size exceeded *** [aslcompilerparse.c] Error code 2 And I do not find yacc in the tools/tmp tree. So here the buildsystem is in a catch22. And perhaps yacc needs to be added to the buildtools? Probably I can get out of this by first cd /usr/src/usr.bin/yacc make; make install Yes: https://lists.freebsd.org/pipermail/freebsd-current/2015-February/054740.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: default pager (csh)
On Thu, 19 Feb 2015, Kevin Oberman wrote: On Thu, Feb 19, 2015 at 5:10 PM, Warren Block wrote: On Thu, 19 Feb 2015, Julian Elischer wrote: On 2/18/15 3:41 PM, Xin Li wrote: The _only_ reason that I can think of is that more(1) does not clear screen for certain terminals (done with 'ti' and 'te' sequences), while less(1) when running as less does. The less(1) behavior can be annoying to some people (sometimes even myself when using less to show contents of a file and ^Z to paste them), and unfortunately quite a few of them also happen to be the more vocal ones when it comes to a change. I find that behaviour infuriating I page down to a place to get some text on the screen to use as a reference, then exit to run a command with that information, and *bam* the info I wanted to use has gone away. It doesn't do that on csh. Or maybe I figured out how to prevent it long ago and forgot, but all I use is this: setenv PAGER "less -RS" You probably did what I used to do. Modify the termcaps/terminfo to eliminate this behavior. See Exorcising the Evil Alternate Screen. In the past, FreeBSD disabled this by default. It was changed several years ago, but you can change it back as per the aboved referenced article. I'm pretty sure I have not done that, it would show up in mergemaster. As far as I can remember, less(1) has never done that clear-the-screen thing on FreeBSD, which is why it is so jarring on Linux. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: default pager (csh)
On Thu, 19 Feb 2015, Julian Elischer wrote: On 2/18/15 3:41 PM, Xin Li wrote: The _only_ reason that I can think of is that more(1) does not clear screen for certain terminals (done with 'ti' and 'te' sequences), while less(1) when running as less does. The less(1) behavior can be annoying to some people (sometimes even myself when using less to show contents of a file and ^Z to paste them), and unfortunately quite a few of them also happen to be the more vocal ones when it comes to a change. I find that behaviour infuriating I page down to a place to get some text on the screen to use as a reference, then exit to run a command with that information, and *bam* the info I wanted to use has gone away. It doesn't do that on csh. Or maybe I figured out how to prevent it long ago and forgot, but all I use is this: setenv PAGER "less -RS" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Acer C720 Chromebook (was: Re: looking for new netbook)
On Wed, 7 Jan 2015, Matthias Apitz wrote: The keyboard of the C720, in principle a normal PC105, mine with German layout QWERTZ, is a bit tricky: it has - only F-keys from F1 to F10 and they are labeled with symbols for the ChromeOS applications; - no hardware power-off (only by an ACPI key which is situated where F11 would be, i.e. right above the Backspace key, you see the risk :-) ) - no Windows key which could be used as Modifier-key in X11; - no PageUP/DOWN keys Ouch. But the older Acer netbooks used Fn+up/down, so probably something similar can be done. Alt+up/down, maybe. When researching this machine a couple of weeks back, I saw somewhere that it was based on a similar existing PC-compatible Acer model, V3 or V5 maybe, or the ES1 series (can't find the reference again, of course). But all of those with 11.6" displays look to have older or less powerful processors, typically the Celeron N2840. The Celeron 2955 in the C720 is about 50% faster. The E3-111-P8DW has a faster CPU, but it is a third-generation N3530. Standard hard drive and socketed RAM, though. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Moving troff only documentation to the doc repository
On Sun, 23 Nov 2014, Remko Lodder wrote: On 23 Nov 2014, at 20:10, Baptiste Daroussin wrote: Hi all, I would like to move the troff documentation which is not very useful anymore on a recent FreeBSD system but still part of history into the doc repository, a dedicated branch will probably fit (anyone has an idea for the name of the branch?) FYI the troff only docs concern: share/docs/{papers,psd,smm,usd} Anyone has a concern about that? Not from me, I actually have never read the documentation. How about doc-history, or something where we can archive documentation that has high historic value? There is the doc archive: https://docs.freebsd.org/doc/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP] man(1) now uses mandoc
On Sun, 23 Nov 2014, Baptiste Daroussin wrote: The default renderer on HEAD has been switched to mandoc(1) by default The man(1) command has been instrumented to first test the manpage and fallback on groff if the man page cannot be rendered with mandoc(1). If base is built without groff then man(1) recommands to install groff from packages. makewhatis(1), apropos(1) have not yet been switched to mandoc(1) equivalent. Thanks and congratulations to all involved! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: Enabling vt(4) by default
On Wed, 5 Nov 2014, Chris H wrote: On Wed, 5 Nov 2014 08:15:04 -0700 (MST) Warren Block wrote On Wed, 5 Nov 2014, Chris H wrote: On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn wrote >> No, video mode won't work with the nVidia blob. That requires a KMS (in-kernel) driver. Thank you for the reply, Gary. Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck? Or Intel, or anything with KMS drivers. Thanks. Everything I manage, is using nVidia. Looks like the kms VESA might work. But I'm not sure if there would be any appreciable gain going that route (assuming it's even possible). It's worth asking Nvidia directly. I would not be optimistic about that, but it's easy to try, and they might surprise everyone. Another option might be nouveau. Don't know the current status of whether that works on FreeBSD, though. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: Enabling vt(4) by default
On Wed, 5 Nov 2014, Chris H wrote: On Wed, 5 Nov 2014 10:19:51 +0100 Gary Jennejohn wrote No, video mode won't work with the nVidia blob. That requires a KMS (in-kernel) driver. Thank you for the reply, Gary. Ahh. I see. So unless I have ATI hardware, I'm pretty much out of luck? Or Intel, or anything with KMS drivers. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WiFi 802.11/ac PCIe supported adaptor
On Sun, 19 Oct 2014, O. Hartmann wrote: Am Sun, 28 Sep 2014 14:50:02 -0600 (MDT) Warren Block schrieb: On Sun, 28 Sep 2014, Gavin Atkinson wrote: On Sun, 28 Sep 2014, O. Hartmann wrote: Networking wasn't an issue for me for years, but now, sitting on a pile of neat new hardware of which FreeBSD can not make any serious use, let me rethink. Luckily, The Lenovo laptops have a mini PCIe WiFi NIC - if I'm willing to follow FreeBSDs agony I'm able to swap the NIC with a piece of hardware that is supported. But it is additional Unfortunately, many Lenovo laptops lock the BIOS down in such a way that they won't boot without the NIC they were shipped with :( Yes, I realized this very sadly today. Intel 6300 WiFi adapter isn't recognized, the crap of Laptop rejects starting firmware and I get a message telling me using uncertified hardware. Last time I bought a Laptop from Lenovo! Well, or a short list of approved Lenovo-branded cards. In the past, Lenovo (or IBM) has supplied Atheros cards. The trick will be finding that list and identifying the chipsets on each. There are also unofficial BIOS modifications to remove the limits. There are lists, but they are outdated and newer chipsets aren't listed. No, I mean each particular Thinkpad notebook has a list of allowed cards in the BIOS. However, it is not the same list for each model. So the trick is to find the list of approved cards for your particular model, and then figure out which of those is Atheros-based. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WiFi 802.11/ac PCIe supported adaptor
On Sun, 28 Sep 2014, Gavin Atkinson wrote: On Sun, 28 Sep 2014, O. Hartmann wrote: Networking wasn't an issue for me for years, but now, sitting on a pile of neat new hardware of which FreeBSD can not make any serious use, let me rethink. Luckily, The Lenovo laptops have a mini PCIe WiFi NIC - if I'm willing to follow FreeBSDs agony I'm able to swap the NIC with a piece of hardware that is supported. But it is additional Unfortunately, many Lenovo laptops lock the BIOS down in such a way that they won't boot without the NIC they were shipped with :( Well, or a short list of approved Lenovo-branded cards. In the past, Lenovo (or IBM) has supplied Atheros cards. The trick will be finding that list and identifying the chipsets on each. There are also unofficial BIOS modifications to remove the limits. it is also due to a bad politics. nVidia, for instance, offers a BLOB for their GPUs. Yeah! But no OpenCL support. AMD offers nothing but promises and their efforts regarding opensource drivers is a pity. AMD has actually supported the open Radeon driver, both with programming information and (I think) employing developers to work on it. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WiFi 802.11/ac PCIe supported adaptor
On Sat, 27 Sep 2014, O. Hartmann wrote: I'm looking for a replacemnt for my 802.11g WiFi PCIe adaptor card and want to replace it with an 802.11ac adaptor. Since I made very bad experiences with CURRENT and support of modest modern hardware (Haswell CPU/Intel 7260 DualBand WiFi NIC), I'd like to ask here first. I found this PCIe adaptor card attractive: GigaByte Gigabyte GC-WB867D-I I can not find ad hoc the WLAN chip used on that specific card, but maybe someone has experiences with that litte board. Newegg reviews say this is an Intel 7260HMW: http://www.newegg.com/Product/Product.aspx?Item=N82E16813995032&Tpk=N82E16813995032 I don't know if that is supported on FreeBSD yet. PCIe to mini-PCIe adapters like that can be found separately, allowing the use of any mini-PCIe card. I've successfully tested an Atheros AR9280 card in one. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
On Sat, 20 Sep 2014, O. Hartmann wrote: The very same CURRENT (most recent as I built world on all system today) doesn't recognize the Haswell's HD4600 iGPU (i5-4200M). So, it seems impossible to me that people can report having this GPU working if even the most recent FreeBSD CURRENT doesn't recognize it. Sorry, on the laptop in question the integrated HD4600 does show up as a vga0: device in the pciconf-listing (it is very early and I stoped looking at the very end ...). At this point, it's worth trying the vesa driver, which should work on Haswell. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
On Sat, 20 Sep 2014, O. Hartmann wrote: Am Sat, 20 Sep 2014 07:36:21 -0600 (MDT) Warren Block schrieb: On Fri, 19 Sep 2014, O. Hartmann wrote: nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo ThinkPad Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and dedicated nVidia GT 740M (Optimus) working correctly. Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The extra GPU uses the same display memory and can be enabled to speed up the Intel graphics or disabled for power saving. I don't know if versions where the Nvidia section is a full discrete video adapter that can be used alone are still called "Optimus". Some Optimus owners have reported being able to use the Intel drivers after disabling the Nvidia GPU in the BIOS or UEFI. If an option to disable the Nvidia GPU is not present, some people have reported success with an xorg.conf that uses only the intel driver and ignores the Nvidia hardware. Thanks Warren. But this sounds even more frustrating now. I look around the web even at Lenovo's support forum. Many people report the GT 740M nVidia adaptor as a discrete adaptor with Optimus technology and everything sounds to me like it can be selected exclusively. What you describes is that I definitely need to use the HD4600 iGPU on FreeBSD in the first place since the nVidia hardware is a kind of "appendix" to the HD4600. Optimus started out that way, but they might use the same name now for models where the additional GPU is a full discrete adapter. Anyway, I also tried to configure X11 as HD4600 only and X11 doesn't work properly: it doesn't even start up and loading the "intel" driver complains about a missing device - preceeded by a lot of /dev/dri errors. This indicates to me, in a naiv manner, that this HD4600 isn't recodnized by the kernel, either. I do not see any kind of vga0: entry in the kernel log when enabling "Integrated Graphics" only in the laptop's UEFI/Firmware. When enabling "nVidia Optimus", a recognized vga0: device shows up. Whoops, HD4600 is Haswell. The intel driver on FreeBSD does not support Haswell video yet. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT
On Fri, 19 Sep 2014, O. Hartmann wrote: nVidia's BLOB from port x11/nvidia-driver seems to have problems in FreeBSD 11.0-CURRENT #2 r271869: Fri Sep 19 13:28:03 CEST 2014 amd64, on Lenovo ThinkPad Edge E540 laptop with CPU i5-4200M (Haswell) with integrated HD4600 Intel iGPU and dedicated nVidia GT 740M (Optimus) working correctly. Optimus is supposed to be full Intel graphics plus an Nvidia GPU. The extra GPU uses the same display memory and can be enabled to speed up the Intel graphics or disabled for power saving. I don't know if versions where the Nvidia section is a full discrete video adapter that can be used alone are still called "Optimus". Some Optimus owners have reported being able to use the Intel drivers after disabling the Nvidia GPU in the BIOS or UEFI. If an option to disable the Nvidia GPU is not present, some people have reported success with an xorg.conf that uses only the intel driver and ignores the Nvidia hardware. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: did tar(1) loose xz compression support in 11?
On Tue, 26 Aug 2014, Daniel Eischen wrote: On Tue, 26 Aug 2014, Tim Kientzle wrote: On Aug 26, 2014, at 11:05 AM, Chris H wrote: Greetings, I'm currently testing 11. My build / install is from about 2 days ago. I generally use xz compression, when creating archives. But when I attempt the following: tar -cvJ --options xz:9 -f ./archive-name.tar.xz ./file it returns the following: tar: Undefined option: `xz:9' This has always worked in previous versions. Has the syntax changed, and the man(1) pages just haven't caught up? I can?t see any evidence in libarchive?s source that this ever worked. The man page is a little confusing. Here it says: --options options Select optional behaviors for particular modules. The argument is a text string containing comma-separated keywords and values. These are passed to the modules that handle particular formats to control how those formats will behave. Each option has one of the following forms: key=value The key will be set to the specified value in every module that supports it. Modules that do not support this key will ignore it. Then below, after the last option, it says: ... zip:compression=type Use type as compression method. Supported values are store (uncompressed) and deflate (gzip algorithm). If a provided option is not supported by any module, that is a fatal error. The first states that it is ignored, the latter states that it is a fatal error. The meaning of "any module" is subtle, at least for my feeble brain ;-) It suggests that options are passed to all modules, and each module is free to ignore options it does not understand. But at least one module must understand the option, or a fatal error is reported. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: How to get a mouse in vt(4) -- NEWCONS
On Mon, 25 Aug 2014, Chris H wrote: I also read that hw.vga.textmode is available. However sysctl hw.vga.textmode returns unknown oid. It is a boot-time-only setting for loader.conf. hw.vga.textmode=1 boots in text mode. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: No bootable device
On Sun, 10 Aug 2014, Eric L. Camachat wrote: /usr/local/libexec/ppf_verify: pgp command failed gpg: Signature made Sun Aug 10 16:49:09 2014 MDT gpg:using DSA key 0x49F050BB7A0EC18C gpg: Can't check signature: No public key -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/09/2014 10:32, Mehmet Erol Sanliturk wrote: the installed systems are not bootable , and the last sentence on the screen is the following : No bootable device -- insert boot disk and press any key If you installed into GPT partitions like this: $ gpart show ada0 => 34 488397101 ada0 GPT (233G) 34 1038 1 freebsd-boot (519K) 1072 455081984 2 freebsd-ufs (217G) 455083056 33314079 3 freebsd-swap (16G) Try to make GPT in MBR as bootable (active) partition: $ fdisk -s /dev/ada0 /dev/ada0: 484521 cyl 16 hd 63 sec PartStartSize Type Flags 1: 1 488397167 0xee 0x80 $ fdisk -p /dev/ada0 # /dev/ada0 g c484521 h16 s63 p 1 0xee 1 488397167 a 1 This is an known issue on HP laptops. The simpler version is gpart set -a active ada0 There are multiple possible issues. This one is due to strict compliance with the GPT standard. Another problem is when a BIOS system does weird things based on an MBR partition type. Some Lenovo systems do that. When that is the problem, using MBR partitioning rather than the PMBR from GPT can work. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On Fri, 25 Jul 2014, Craig Rodrigues wrote: On Fri, Jul 25, 2014 at 2:26 PM, Garrett Wollman wrote: In article you write: >Writing "an article" is hard. Writing a small section on how deleting >packages is different between pkg and, say, apt, is much easier. The >scope is known. Indeed, it's pretty trivial. I think the sort of article Craig was looking for was more on the order of apt command pkg command apt-get update pkg update (*1) ... ... (*1) Explanation of differences between how apt behaves and how pkg behaves. The set of common apt operations is pretty well-known, and most of them have direct pkg(8) equivalents. Garrett is describing exactly what I am looking for. I'm not looking for a complicated article explaining the internal differences between apt and pkg. Very few people have the interest or patience to read that. Providing a simple table contrasting the basic apt/yum/rpm/pkg commands for installing/upgrading/deleting packages is mostly what is needed. This gave me a flashback to the last time somebody said "Oh, I just want a simple little program." :) We need to show people that installing packages on FreeBSD is not like the "bad old pkg_add days" which people have bad memories of. We need to show that pkg is as good as what people are used to on modern Linux distributions. The wiki should be ideal for this. Start a table, fill in what you can, and others can fill in the other parts. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?
On Fri, 25 Jul 2014, Craig Rodrigues wrote: What I'd like to see is an article on freebsd.org either on the wiki or in the handbook, which compares using apt, yum, rpm, whatever to pkg. Is anyone interested in working on an article like this? I don't have the bandwidth right now. A person to write that article needs detailed knowledge of pkg and the Linux package systems. I don't have that, but would be willing to help you develop an outline for the article. Having a design like that makes it easier to write when time and resources are available. Writing "an article" is hard. Writing a small section on how deleting packages is different between pkg and, say, apt, is much easier. The scope is known. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Boot loader too large
On Fri, 11 Jul 2014, Benjamin Kaduk wrote: On Fri, Jul 4, 2014 at 7:07 AM, Alie Tan wrote: On Fri, Jul 4, 2014 at 5:57 PM, Alie Tan wrote: Hi, I am getting Boot loader too large message while using FreeBSD-11.0-CURRENT-i386-20140701-r268111-disc1.iso Is there any way to solve this issue? Strange, resizing the freebsd-boot to 128k solved my issue. why default slice size making such issue? Resizing to 128k from what value? I seem to recall that having larger freebsd-boot partitions caused problems. Up to 512K is okay, but larger than that is a problem for the bootcode. I suggest always using 512K, it's not like using less saves an appreciable amount of space. And bootcode grows sometimes. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart(8) man page missing list documentation
On Tue, 1 Jul 2014, Chris Ross wrote: Looking at the man page for gpart(8) on a recent 10-stable system, I was trying to find out what the -a option to list does. (shown in the output of gpart when run with no parameters). Interestingly, despite ?list? being highlighted in paragraph text as an action for the command, it does not appear in the summary at the top of the page, nor in the detailed DESCRIPTION section that describes each of the actions. This appears to still be the case on HEAD, as well. I assume this is worth fixing and MFC?ing? A PR was just entered for that: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191534 "list" and "status" and a couple of others that only apply for some GEOM modules (load, unload) are part of the base GEOM command set. I was going to say we should just refer the reader to another page, maybe geom(8). But gmirror(8) does include those commands in the synopsis. We should be consistent with this, and I'd lean toward doing it the way gmirror(8) does now. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd and utf-8 directory names
On Tue, 1 Jul 2014, d...@gmx.com wrote: In other words, "You, the general user, should learn the art of operating system development (on your own) for the sole purpose of being able to fix the bug yourself." It's one approach to solving a technical problem, but not the only one. You can fix it yourself, possibly involving a lot of learning. Or you can ask, encourage, or even pay others to fix it. This should all start with a bug report to make sure the problem is documented. If people already know there are bugs in the msdosfs code, those same people should be able to supply details to fill out the bug report. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Turning TESTS on by default
On Sun, 8 Jun 2014, Julio Merino wrote: On Fri, Jun 6, 2014 at 11:33 PM, Konstantin Belousov wrote: It is the same as the debugging kernel. The INVARIANTS, WITNESS, DEBUG and DIAGNOSTIC options are not enabled for the user consumption. No; this is not the same at all. All the options you mention introduce a performance penalty on the system at *run* time and the _only_ way to get rid of such penalty completely is to disable the options at *build* time (sysctl doesn't make the cut because the system would still need to check a boolean value). Because these toggles affect run-time performance, and because they are intended for developers only, they are not the default on release builds. Building the test suite has no impact whatsoever on the system at run-time. The test suite is just a bunch of files in a self-contained location. We ought to ship such files as tests.tgz to give users a very easy way of not installing them though. How much of an impact does the test suite have in terms of disk space (probably not much) and buildworld time (possibly not much, either)? Users being able to report the results of tests could demystify a lot of bug reports. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: diskid documentation
On Mon, 2 Jun 2014, Michael W. Lucas wrote: On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. Wait-- one type of one label can hide another? I thought a big point of labels was to remove ambiguity... Can't get more unambiguous than only having one label! The word to look for here is "wither". When a device label name is opened exclusively (like mounting a device), other labels for that device are supposed to "wither" and disappear from view. (My understanding of this is incomplete. Garrett Wollman sent me a very nice explanation of how this works, which I have read but not enough times yet.) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Hello fdclose
On Fri, 21 Mar 2014, Dag-Erling Smørgrav wrote: Warren Block writes: Dag-Erling Smørgrav writes: We always use [The .Nm foo utility or The .Fn foo function] instead of just .Nm or .Fn at the start of a sentence, but never (or rarely) within a sentence. By "we", do you mean the FreeBSD project or your local organization? Is there a specific reason the redundant wording, or is it just customary? I mean the FreeBSD project, and the reason is as John stated: all sentences must start with a capital letter. I've gotten so used to this over the past 15 years that I even do it in email and other non-FreeBSD written material. DES "Because it's been that way for 15 years" is not always a justification (consider BIND in base, for example :). I'll let this drop for now, but still find it interesting that it is not mentioned in the FDP Primer, and those style guide rules date back at least 15 years. It may be that the original doc project members felt that capitalizing the first word of a sentence was so obvious that it did not need to be stated. Or possibly, that it was a rule that could be usefully broken at times. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Hello fdclose
On Thu, 20 Mar 2014, Dag-Erling Smørgrav wrote: Warren Block writes: John Baldwin writes: Warren Block writes: .Fn fdclose is equivalent to .Fn fclose , but the file descriptor is returned rather than closed. Yes, but this has the 'no capital letter at the start of a sentence' problem. I've heard that mentioned before, but have never seen any actual rule regarding it. And we do have actual rules about avoiding redundant phrases: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/book.html#writing-style-guidelines We always use The .Nm foo utility or The .Fn foo function instead of just .Nm or .Fn at the start of a sentence, but never (or rarely) within a sentence. By "we", do you mean the FreeBSD project or your local organization? Is there a specific reason the redundant wording, or is it just customary? I suspect that usage is similar to that for an acronym, defining it on the first usage but only then. Both mdoc and DocBook markup should accomplish the same thing. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Hello fdclose
On Wed, 19 Mar 2014, John Baldwin wrote: On Wednesday, March 19, 2014 12:38:57 am Warren Block wrote: On Tue, 18 Mar 2014, John Baldwin wrote: On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote: Hi, After our previous discuss [1] I prepare fdclosedir(3) function which was committed by Pawel (cc'ed) in commit r254499. A while ago I also prepare the fdclose function. Unfortunately, this new function is a little bit more tricky then previous one. Can I ask you for a review of this patch? I think the code is fine. I have a few suggestions on the manpage wording: The +.Fn fdclose +function is equivalent to the +.Fn fclose +function except that this function returns file descriptor instead of +closing it. +.Pp +The I would move fdclose() to its own paragraph and reword this sentence as: "The fdclose() function is equivalent to fclose() except that it does not close the underlying file descriptor." .Fn fdclose is equivalent to .Fn fclose , but the file descriptor is returned rather than closed. Likewise in other sections, the markup is supposed to do the job of pointing out that something is a function. Yes, but this has the 'no capital letter at the start of a sentence' problem. I've heard that mentioned before, but have never seen any actual rule regarding it. And we do have actual rules about avoiding redundant phrases: http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/book.html#writing-style-guidelines While normal words should be capitalized as the first word in a sentence, special words that are case-sensitive override that (IMO). Also, I do think reusing the 'underlying file descriptor' language is important in the context of the earlier description of fclose(). Sorry, a problem with my micro-optimization: .Fn fdclose is equivalent to .Fn fclose , but does not close the underlying file descriptor. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Hello fdclose
On Tue, 18 Mar 2014, John Baldwin wrote: On Monday, March 17, 2014 7:23:19 pm Mariusz Zaborski wrote: Hi, After our previous discuss [1] I prepare fdclosedir(3) function which was committed by Pawel (cc'ed) in commit r254499. A while ago I also prepare the fdclose function. Unfortunately, this new function is a little bit more tricky then previous one. Can I ask you for a review of this patch? I think the code is fine. I have a few suggestions on the manpage wording: The +.Fn fdclose +function is equivalent to the +.Fn fclose +function except that this function returns file descriptor instead of +closing it. +.Pp +The I would move fdclose() to its own paragraph and reword this sentence as: "The fdclose() function is equivalent to fclose() except that it does not close the underlying file descriptor." .Fn fdclose is equivalent to .Fn fclose , but the file descriptor is returned rather than closed. Likewise in other sections, the markup is supposed to do the job of pointing out that something is a function. textproc/igor can identify some problems with wording. It also checks for rudimentary mdoc(7) requirements. If desired, I'm willing to edit this man page. (I've learned far too recently that most people do not want to be consulted on wording, they just want it fixed. That's now the approach I take: make all the corrections and return it, rather than a back-and-forth with the danger of edit fatigue.) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: zfs boot manual pages
On Tue, 4 Feb 2014, Scot Hetzel wrote: On Tue, Feb 4, 2014 at 7:53 AM, Andriy Gapon wrote: I've started working on manual pages for the zfs boot chain. Please [p]review my work in progress here: https://github.com/avg-I/freebsd/compare/review;zfs-boot-man-pages Any additions, corrections, suggestions and other kinds of reviewing are welcome. Patches and pull requests are very welcome! Many thanks to Warren Block for the initial review and many fixes. One fix for the gptzfsboot man page would be to mention that gptzfsboot is installed into a GPT partition of type freebsd-boot, and that the -i 1 refers to the GPT index for this partition. We are missing that from the gptboot.8 page also. gptzfsboot is installed in a freebsd-boot partition, usually the first partition on the disk. A ``protective MBR'' (see gpart(8)) is typically used in combination with gptzfsboot. To install gptzfsboot on the ada0 drive: gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada0 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.
On Thu, 23 Jan 2014, Kevin Oberman wrote: On Thu, Jan 23, 2014 at 7:47 AM, Thomas Hoffmann wrote: On Thu, Jan 23, 2014 at 9:56 AM, Warren Block wrote: > > > Using -DNOCLEAN with an existing /usr/obj can go even faster than ccache: > less than two minutes for a buildworld on my frequently updated i5/SSD > system, sometimes less than one minute. Can you elaborate on this, please? I always clear my /usr/obj before starting a buildworld, which takes 2 hours to run on my system. Are you saying if I do "make -DNOCLEAN buildworld" I do not have to clear /usr/obj first Yes. Removing /usr/obj is a faster way of doing 'make clean', mostly. AND my buildworld will run faster Yes, because make will see that many/most files have already been built. (AND with no downside)? Well... mostly. :) I noticed that after 10.0-RELEASE, uname on my system still said "PRERELEASE". That code had not been rebuilt because make did not see it as needing a rebuild. You can still delete /usr/obj and run a full buildworld from scratch every so often. I should give credit to bdrewery@ for reminding me about -DNOCLEAN when I was whining about ccache not working on 10.0. It turned out to be a better solution. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.
On Thu, 23 Jan 2014, Jakub Lach wrote: I plan to stay some time on 9.2-STABLE (already pkgng and clangfied) waiting maybe till next release from 10-STABLE tree, however 10-STABLE will be where I will be eventually heading, so notes in this spirit are valuable reminders at least, I appreciate it. My experiences converting a couple of systems from 9-STABLE to 10-STABLE over the last couple of months were really pretty easy. These were source updates for both base and ports. Despite changing from pkg_* to pkg and KMS X drivers at the same time, it was surprisingly smooth. If you have devel/ccache installed, remove it before starting, though, it has problems with clang. Using -DNOCLEAN with an existing /usr/obj can go even faster than ccache: less than two minutes for a buildworld on my frequently updated i5/SSD system, sometimes less than one minute. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Intel graphics driver broken on 10-RC5
On Thu, 9 Jan 2014, David Chisnall wrote: Hi Johannes, Are you using the packaged Xorg in both cases? Currently, the default for 10 is the old (pre-KMS) X.org and the default for 11 (HEAD) is the newer (post-KMS) one. If you're using the default one, would you mind trying the new one? You can build it from ports by putting this in your make.conf: WITH_NEW_XORG=yes WITH_GALLIUM=yes I'm currently running it with AMD graphics on 10-RC4 and finding it works a lot better than the older version, and we're considering enabling it for the 10.0-RELEASE. The down side is that, without newcons, you lose working VTs after X has started. The wiki now has the update procedure: https://wiki.freebsd.org/Graphics#Installing_KMS_Ports This will work either to update an already-installed X, or to install it from scratch (just install x11/xorg afterwards). It has been tested on 9.2 and 10-STABLE. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD 10.0-RC3 Now Available
On Fri, 27 Dec 2013, Mathieu Arnold wrote: +--On 27 décembre 2013 10:28:07 -0500 Thomas Hoffmann wrote: | All the examples I've seen for updating bootcode assume GPT. If one has | MBR (as I do) and assuming the following basic scheme: | | gpart show ada0 | => 63 976773105 ada0 MBR (466G) | 63 976773105 1 freebsd [active] (466G) | | gpart show ada0s1 | =>0 976773105 ada0s1 BSD (466G) | 0 943218736 1 freebsd-zfs (450G) | 943218736 33554369 2 freebsd-swap (16G) | | would the equivalent bootcode statement be: | | gpart bootcode -b /boot/pmbr -p /boot/zfsboot ada0s1 No, the PMBR is for GPT partitioning only. | where the boot code is /boot/zfsboot (rather than /boot/gptzfsboot) and | ada0s1 is the slice on which FreeBSD is installed? Hum, no, if you're using MBR and not GPT, you can't use gpart, Why not? gpart is not GPT-specific. It handles MBR and BSDlabel bootcode correctly. you have to do something aweful like this : # dd if=/boot/zfsboot of=/dev/ada0 count=1 That will overwrite the MBR partition table. # sysctl kern.geom.debugflags=0x10 # dd if=/boot/zfsboot of=/dev/ada0 skip=1 seek=1024 That seems dangerous. I have not tried with zfsboot, but this should be close: # gpart bootcode -b /boot/zfsboot ada0 # gpart bootcode -b /boot/zfsboot ada0s1 Untested! The first one may need to use /boot/mbr. A better way to do this, provided the system does not have a broken BIOS, would be to backup, repartition with GPT, and restore, avoiding the complication of multiple partitioning schemes. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cron(8) improvement
On Sun, 10 Nov 2013, Philipp Ost wrote: Warren Block schrieb: [...] ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. Why not just use an additional entry in rc.conf? rsnapshot_cron="YES" (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on start/restart.) This brings up another problem. When a port is removed, what is done with ports cron entries that have been user modified? Normally, modified files would not be removed, but a cron entry for a removed port definitely should not be running any more, even if the admin forgot to remove the entry in rc.conf. But just removing the modified file is bad also, because maybe the port was just removed as part of an upgrade. Given the above scenario, would it be acceptable to set the entry in rc.conf, $portname_cron=YES, to $portname_cron=NO without touching the modified files and inform the user about having done so? I would not want the system modifying rc.conf for me, but don't have a better idea at present. Maybe move customized cronfiles to an "old" folder on deinstall, so at least the user could recover them. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: cron(8) improvement
On Sun, 10 Nov 2013, Daniel O'Connor wrote: On 10 Nov 2013, at 24:24, Matthew Seaman wrote: 2) Should ports / packages populate these cron.d directories? This is a much more interesting question. Effectively its asking if a port / package should provide some level of automatic configuration -- a thing that has previously been a no-no for FreeBSD. I think it would be OK if they installed entries in a disabled state. That would be my preference also. ie either the file is named such that it is ignored by cron (preferable IMO) or the entries in them are commented out. Why not just use an additional entry in rc.conf? rsnapshot_cron="YES" (If there is a /usr/local/etc/cron.d/rsnapshot, add it to cron on start/restart.) This brings up another problem. When a port is removed, what is done with ports cron entries that have been user modified? Normally, modified files would not be removed, but a cron entry for a removed port definitely should not be running any more, even if the admin forgot to remove the entry in rc.conf. But just removing the modified file is bad also, because maybe the port was just removed as part of an upgrade. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Overriding sector size on disks?
On Fri, 1 Nov 2013, Adrian Chadd wrote: Hi! I have an odd problem. That, honestly, can't be that odd. I have a bunch of SATA disks that when plugged into the laptop directly, show up as 512 byte sectors. But if I plug it in via this iomega USB caddy, they show up as 4k sector devices. ISTR some Hitachi external USB disk enclosures do that. Since they are not a general-purpose enclosure but came wrapped around specific Hitachi disks, it's not really their fault. Because of this, partitions just plainly don't work. Has anyone faced this? Is there some trick to do to get these things to go back to being 512 byte sector devices so one can use them? Similarly, because they show up as 512 byte sector devices on macosx/linux, they can read/write NTFS/MSDOS partitions on the thing. But if I plug it into freebsd, it shows up as a 4k sector device and things plainly don't work. Is it out of the question to discard the enclosure as too bugged to use? Otherwise, there is a small chance that the vendor has a firmware update that isn't stupid. Or maybe even a jumper in the enclosure. Reference: http://forum.hddguru.com/viewtopic.php?t=21099&start= has some information which might help. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: /usr/src/lib/msun errors
On Sun, 13 Oct 2013, Joe Nosay wrote: On Sun, Oct 13, 2013 at 11:57 AM, Joe Nosay wrote: Someone had to tell me what to do. Steve, are you the only person in the multiverse that is free of making any mistakes? Nobody was accusing you of doing it intentionally. Anyway, that problem is now solved--thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Tue, 8 Oct 2013, Teske, Devin wrote: "But shell is nasty; slow; and not as powerful as C" (it depends in what context; the first is rhetoric, the second is only true for poor implement- ations, and the third may be true in some contexts, but I consider the answer to "how maintainable is it" to be a factor in the "power" of a language, so don't necessarily consider C to be more powerful than shell as the latter is as-or-more maintainable with fewer LoC and a higher return on investment; see previous [above] arguments). My question would be: why are sh and C the only choices? If the answer is "because that's all we have in base", is that a valid concern? As far as sh, it lacks many high- or even mid-level constructs and has real problems with quoting, parsing, and output (2>&1 >&3, for example). These make it harder to do things (aka, more code to accomplish a task, more code to be maintained, more difficult to modify) than the higher level Perubython languages. In any case, thanks for working on this. A functioning program in any language is better than a non-existent "better" one. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Tue, 8 Oct 2013, Freddie Cash wrote: On Tue, Oct 8, 2013 at 1:17 PM, Nathan Whitehorn wrote: 4. What is this gnop stuff for? Can't comment on the rest, but gnop is required to create 4K-aligned vdevs where the minimum block size is 4K (aka ashift=12). Right, but to emphasize: the gnop hack forces ZFS to 4K blocks. It does not, by itself, guarantee alignment with 4K native blocks on the drive, that has to be done by making the partitions aligned. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Mon, 7 Oct 2013, Allan Jude wrote: On 2013-10-07 16:43, Warren Block wrote: On Mon, 7 Oct 2013, Allan Jude wrote: Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 . That is a good idea, I'll add that I've also hit this: http://lists.freebsd.org/pipermail/freebsd-sysinstall/2013-September/000949.html and plan to throw in a fix for that. Which makes more sense, blindly 'killall dhclient' before we try to acquire a new lease, or detect that dhclient is running and try to use the IP that has already been assigned? killall seems all right. In fact, internally, it's going to do that check. If nothing named dhclient is running, it will return immediately. Although on 10.0, dhclient does not want to die sometimes. Here's another PR for usability: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/161547 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT] Patch to bsdinstall to support root-on-ZFS and GELI
On Mon, 7 Oct 2013, Allan Jude wrote: Additional, it includes some other changes to bsdinstall: 1. Change the default to the 'non-standard keyboard mapping' prompt to no Please see http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/162175 . ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: X related ports not finding version strings and hanging
On Sun, 6 Oct 2013, Kevin Oberman wrote: As usual with such upgrades, pkg_libchk is your friend. Assuming you have updated pixman: portmaster graphics/libGL graphics/dri pkg_libchk -o | grep pixman | cut -d: -f1 | sort | uniq > pixman-files.txt portmaster =D `cat pixman-files.txt` portmaster -aD portmaster -y -clean-distfiles pkg_libchk -q > /tmp/to-be-rebuilt.txt portmaster `cat /tmp/to-be-rebuilt.txt` worked for me, although I did it after following the pixman instructions in /usr/ports/UPDATING. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Moused + HAL + rc.conf + Boot
On Mon, 16 Sep 2013, Nilton Jose Rizzo wrote: Hi all, I'm here again! When I start my box, the moused is run. My mouse is an USB mouse. I put in rc.conf this knob: moused_enable="NO", but is ignored by start up script and moused is run, this is a problem to the HAL, because the HAL try to open /dev/ums0 again and can't do it. I need to change to text console and kill the moused process. I have to logout from account X ( via gdm) and I login again to mouse work. It's started in two night ago. see: FreeBSD valfenda 10.0-ALPHA1 FreeBSD 10.0-ALPHA1 #4 r255503: Fri Sep 13 08:18:27 BRT 2013 rizzo@valfenda:/usr/obj/usr/src/sys/VALFENDA amd64 moused is started by devd when a USB mouse is connected. To disable it, add moused_nondefault_enable=" to /etc/rc.conf. But it's generally preferable to disable xorg's use of HAL by adding Option "AutoAddDevices" "Off" to the ServerLayout section of xorg.conf. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 10-stable does not boot on Dell E1505 any more
On Sat, 14 Sep 2013, Jan Kokemüller wrote: r255569 does not find /dev/ada0s2a and "?" at the mountroot> prompt shows no devices. I've had the same problem after I updated my kernel today. I tracked it down to the hyperv drivers that were added in r255524. Without the "device hyperv" line in my kernconf the system boots fine again. Interesting! Notice this fresh commit: http://svnweb.freebsd.org/base?view=revision&sortby=date&revision=255574 A custom kernel without the hyperv device works. Thanks!___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
10-stable does not boot on Dell E1505 any more
This is an older Dell E1505, Core 2 but does not have AHCI. r255569 does not find /dev/ada0s2a and "?" at the mountroot> prompt shows no devices. r255451 from September 10 boots fine. Also possibly relevant is that after successfully building and installing world and kernel, /boot/kernel.old is not being replaced. This is good at present because the old kernel still works, but shouldn't kernel.old be replaced on installkernel? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: usb mouse and xorg
On Tue, 10 Sep 2013, Sergey V. Dyatko wrote: I have working touchpad (it is work fine before) and mouse with hacked devd.conf (doesn't try tip from gjb@ yet) from my xorg.conf: Section "ServerLayout" Identifier "X.org Configured" Screen 0 "Screen0" 0 0 InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" EndSection Section "ServerFlags" Option "DontVTSwitch" "off" Option "AllowEmptyInput" "off" http://www.wonkity.com/~wblock/docs/html/aei.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart: can not add MBR partitions with "gpart add -t, mbr"
On Fri, 21 Jun 2013, Genre Roger wrote: When I refer to gpart(8) manpage (9.1 release, updated jan 25,2013), I find the description of partition types a bit confusing. Considering the case of a MoBo with "old way" Bios (non UEFI), the only scheme allowed to get a bootable system is MBR. (Note that after booting, your OS is able to manage gpt-scheme on different providers.) Sorry, I don't understand. GPT boots fine on a BIOS system. I'm using it on several systems. Then, if you speak "bsd-ish", you are able to add on the "MBR"-scheme provider up to 4 "freebsd-type" slices, each of them containing up to 8 partitions with a BSD filesystem (or swap space). Yes. This is a partitions-inside-a-slice configuration, used for quite a while because it provides more partitions than MBR's four, and also because it allows a standard PC to multi-boot from any of the four MBR slices. Technically, it's a hack. It's complex and shows that both partitioning schemes (MBR and bsdlabel) have weaknesses. Or, if you speak "msdos-ish", you would be able to add on the "MBR" provider up to 4 "msdos-type" partitions (or 3 + 1 extended ), each of them containing one filesystem. The manpage does'nt list explicitly the type for this second case; Oliver try to use "mbr", decribed as "A partition that is sub-partitioned by a Master Boot Record (MBR). This type is known as "!024dee41-33e7-11d3-9d69-0008c781f39f " by GPT.". Such definition is'nt very explicit. In general, it's rare to find a FreeBSD system that uses MBR slices directly because there are only four. But it can be done by combining one or more of the standard filesystems and not subdividing the slices: ada0s1: freebsd (/, /var, /tmp, and /usr combined into a single / filesystem) ada0s2: swap That would leave s3 and s4 available for other uses. Let me show the example below on my provider ada0 : $ gpart show => 63 976773105 ada0 MBR (465G) 63 136314864 1 freebsd [active] (65G) 136314927 840458241- free - (400G) =>0 136314864 ada0s1 BSD (65G) 08388608 1 freebsd-ufs (4.0G) 8388608 16777216 2 freebsd-swap (8.0G) 25165824 16777216 4 freebsd-ufs (8.0G) 419430408388608 5 freebsd-ufs (4.0G) 50331648 85983215 6 freebsd-ufs (41G) 136314863 1 - free - (512B) $ sudo gpart add -t mbr -i 2 -s 8G ada0 Password: gpart: Invalid argument MBR is not a type of partition, it is a partitioning method or "scheme" as the gpart man page calls them. The partitioning scheme is dictated by the type of system. Standard x86 computers are only going to be able to use MBR or GPT. $ sudo gpart add -t \!12 -i 2 -s 8G ada0 ada0s2 added \!12 is just an MS-DOS partition (FAT32 with LBA). $ sudo newfs_msdos ada0s2 /dev/ada0s2: 16773056 sectors in 262079 FAT32 clusters (32768 bytes/cluster) BytesPerSec=512 SecPerClust=64 ResSectors=32 FATs=2 Media=0xf0 SecPerTrack=63 Heads=16 HiddenSecs=0 HugeSectors=16777215 FATsecs=2048 RootCluster=2 FSInfo=1 Backup=2 $ sudo gpart add -t freebsd -i 3 -s 8G ada0 ada0s3 added $ gpart show ada0 => 63 976773105 ada0 MBR (465G) 63 136314864 1 freebsd [active] (65G) 136314927 16777215 2 !12 (8G) 153092142 16777215 3 freebsd (8G) 169869357 806903811- free - (384G) $ sudo newfs_msdos ada0s3 /dev/ada0s3: 16773056 sectors in 262079 FAT32 clusters (32768 bytes/cluster) BytesPerSec=512 SecPerClust=64 ResSectors=32 FATs=2 Media=0xf0 SecPerTrack=63 Heads=16 HiddenSecs=0 HugeSectors=16777215 FATsecs=2048 RootCluster=2 FSInfo=1 Backup=2 $ this example show that, if you want a "msdos" or "fat32" partition, both the type "\!12" or "freebsd" allows you to create a partition where you could install a msdos filesystem (but the "mbr" does not). It shows that MBR is a partitioning scheme, not a partition type. It also demonstrates that newfs_msdos does not check the partition type of the partition on which it is creating a filesystem. Neither does newfs. That is appropriate behavior. The partition type is so that bootcode and other software that deals with partitions does not have to guess what is on a particular partition, but has it identified explicitly. Such behaviour is not surprising, (using freebsd-type to format as msdos means you don't use the space allowed for labeling); I don't understand what you are saying there. Offhand, I can't think of any reason to misidentify a partition intentionally. but what is really the purpose of the listed "mbr"-type in the gpart(8) manpage? MBR is a partitioning scheme, comparable to GPT but more limited. APM is a partitioning scheme for PPC Macs, VTOC8 is a partitioning scheme for Sparc. The partitioning scheme determines which types of partitions are allowed. For MBR, there are lots of partition types for variations for MS-DOS (includi
Re: gpart: can not add MBR partitions with "gpart add -t mbr"
On Tue, 18 Jun 2013, O. Hartmann wrote: Having a 1TB disk with a MBR partition layout created successfully with "gpart create -s MBR ada4", which is shown as Geom name: ada4 modified: false state: OK fwheads: 16 fwsectors: 63 last: 1953525167 first: 63 entries: 4 scheme: MBR Consumers: 1. Name: ada4 Mediasize: 1000204886016 (931G) Sectorsize: 512 Mode: r0w0e0 it is impossible for me to create a partition with gpart add -t mbr ada4 as it can be read in the manpage of gpart. I can't find that in 9-stable or -head. If it's a literal example, please point it out and I'll fix it. Whatever I do, I receive a useless error from gpart gpart: Invalid argument with no further information. In kernel, I already added GEOM_MBR. geom_part_mbr and geom_part_ldm kernel modules are then already loaded. I tried to figure out what's going wrong but this seems highly enigmatic. What am I doing wrong? "mbr" is partitioning scheme, not a partition type. Common MBR partition types that gpart knows by name are freebsd, freebsd-ufs, freebsd-zfs, ntfs, no doubt lots of others but offhand I don't know where to get the whole list. Examples shown here (MBR in the second half): http://www.wonkity.com/~wblock/docs/html/disksetup.html Numbers can also be used for partition types by prefixing them with an exclamation point, but that must be escaped to keep the shell from interpreting it: gpart add -t \!12 -s1G ada0 That would add a "FAT32X/LBA" partition. There's a list of values here: http://en.wikipedia.org/wiki/Partition_type ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 10-CURRENT i386 memstick snapshots broken?
On Sat, 8 Jun 2013, Glen Barber wrote: The problem is creating the gpart(8) partition scheme on the md(4) device. Below follows script(1) output of what the make-memstick.sh script does: Script started on Sun Jun 9 00:41:08 2013 root@snap:/snap/releng # chroot /snap/releng/10-i386-snap root@snap:/ # cd /usr/obj/usr/src/release root@snap:/usr/obj/usr/src/release # echo \ '/dev/ufs/FreeBSD_Install / ufs ro,noatime 1 1' > release/etc/fstab root@snap:/usr/obj/usr/src/release # makefs -B \ little -o label=FreeBSD_Install test.img release Calculated size of `test.img': 649420800 bytes, 12922 inodes Extent size set to 8192 test.img: 619.3MB (1268400 sectors) block size 8192, fragment size 1024 using 12 cylinder groups of 54.40MB, 6963 blks, 1152 inodes. super-block backups (for fsck -b #) at: 32, 111440, 222848, 334256, 445664, 557072, 668480, 779888, 891296, 1002704, 1114112, 1225520, Populating `test.img' Image `test.img' complete root@snap:/usr/obj/usr/src/release # mdconfig -a -t vnode -f test.img md0 All fine up until this point. Now the gpart(8) partition is created: root@snap:/usr/obj/usr/src/release # gpart create -s BSD /dev/md0 gpart: Inappropriate ioctl for device root@snap:/usr/obj/usr/src/release # gpart list md0 Segmentation fault (core dumped) This might be a good time to stop using a bare bsdlabel (aka "dangerously dedicated"). MBR plus bsdlabel is not great, but more widely understood, and other operating systems will at least recognize the MBR slice. I can help with this if needed. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ipfilter(4) needs maintainer
On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo wrote: 2013/04/13 16:01?Scott Long ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Is it possible to move ipfilter into a port? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart, slice starts at 0
On Sun, 17 Feb 2013, Erich Dollansky wrote: gpart destroy -F da0 diskinfo da0 dd if=/dev/zero of=/dev/da0 bs=512 count=34 dd if=/dev/zero of=/dev/da0 bs=512 count=34 seek=312581774 Someone here on the lists (I unfortunately forget who) showed a sneaky easier way to do this: gpart destroy -F da0 gpart create -s gpt da0 gpart destroy -F da0 This did not make a difference. It's an easier way to destroy the backup table at the end of the disk, whether one was there before or not, without having to calculate the location. gpart show -p da0 gpart create -s MBR da0 gpart add -t freebsd da0 gpart show -p da0 gpart show -p da0s1 gpart set -a active -i 1 da0 # # The following line always gives an error: # # gpart create -s BSD da0s1 'destroy' is not recursive. It destroys the geom found on the device given, but does not write to any geoms inside those geoms. This is obvious. What surprises me is that create does not write a new and empty description to the disk. It does, but not being recursive, it does not destroy the geoms inside the one given to the command (da0). You had: da0 (MBR) da0s1 (bsdlabel) After the destroy, it became da0 (null) da0s1 (bsdlabel) This can happen with any of the setups where there are geoms inside other geoms. The second part of your question, about da0 starting a block zero: [X220]...Appl/Some Tools (root) > gpart show da0 => 63 312581745 da0 MBR (149G) 63 3125817451 freebsd [active] (149G) [X220]...Appl/Some Tools (root) > gpart show da0s1 =>0 312581745 da0s1 BSD (149G) 0 312581745 - free - (149G) That shows slice one starts at block 63, standard for MBR. The space inside the slice (da0s1) starts at block 0 *of the slice*. This is a bit confusing for me but it does not really matter as long as the programs get it straight. This is again because of the geom inside a geom setup. The actual start block is the start of the slice (block 63) plus the start of the FreeBSD partition inside the slice (currently 0). When you create FreeBSD partitions inside da0s1, they will have nonzero offsets from the start of the slice. There are examples shown here: http://forums.freebsd.org/showpost.php?p=206204&postcount=11 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart, slice starts at 0
On Sat, 16 Feb 2013, Erich Dollansky wrote: I did this to get a disk partitioned: #!/bin/tcsh Gah! gpart destroy -F da0 diskinfo da0 dd if=/dev/zero of=/dev/da0 bs=512 count=34 dd if=/dev/zero of=/dev/da0 bs=512 count=34 seek=312581774 Someone here on the lists (I unfortunately forget who) showed a sneaky easier way to do this: gpart destroy -F da0 gpart create -s gpt da0 gpart destroy -F da0 gpart show -p da0 gpart create -s MBR da0 gpart add -t freebsd da0 gpart show -p da0 gpart show -p da0s1 gpart set -a active -i 1 da0 # # The following line always gives an error: # # gpart create -s BSD da0s1 'destroy' is not recursive. It destroys the geom found on the device given, but does not write to any geoms inside those geoms. MBR/bsdlabel puts FreeBSD partitions inside MBR slices. So da0 has been erased, but the bsdlabel blocks for da0s1 are still present. If you recreate da0, da0s1 will magically reappear. Destroy the FreeBSD disklabel stuff in the slices first: gpart destroy -F da0s1 Or instead, use GPT partitioning to avoid dealing with the problem of one type of partitions inside a different type of partitions. GPT makes disk partitioning a lot easier. The second part of your question, about da0 starting a block zero: [X220]...Appl/Some Tools (root) > gpart show da0 => 63 312581745 da0 MBR (149G) 63 3125817451 freebsd [active] (149G) [X220]...Appl/Some Tools (root) > gpart show da0s1 =>0 312581745 da0s1 BSD (149G) 0 312581745 - free - (149G) That shows slice one starts at block 63, standard for MBR. The space inside the slice (da0s1) starts at block 0 *of the slice*. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 7+ days of dogfood
On Mon, 11 Feb 2013, Lars Engels wrote: I also dislike that src build times increased over the years since I run CURRENT on my notebooks (starting 7-CURRENT, now 10-CURRENT). Wouldn't it be possible to add a DO_NOT_BUILD_CLANG_AND_GCC_IF_NOTHING_CHANGED= yes switch to src.conf? Building clang takes ages and gcc is also pretty big... devel/ccache really makes a gcc system buildworld a lot faster. I don't know why more people don't use it; why recompile so many things that have not changed? My recollection of testing it with clang was that it did not make much of an improvement. Could be better now. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Xorg totally unusable with KMS and new Xorg on Sandy Bridge system: how to undo
On Fri, 8 Feb 2013, Thomas Mueller wrote: Thomas Mueller writes: I built the newer Xorg and it falls flat: goes to a nongraphic screen that is blank except for a rectangular cursor in the upper left corner, and now I want to get back to the earlier Xorg. System is Intel Sandy Bridge with i7 CPU. Robert Huff responds: You don't mention your graphics chip explicitly, but building libdrm with the KMS option was enough to prevent X from starting on a Radeon HD 3300. ("Experimental", indeed! :-) Other will be able to help more if you could post the contents of "/var/log/Xorg.0.log" and your xorg.conf file. My /var/log/Xorg.0.log has 0 bytes! To Andrey Fesenko : Were you able to start X with # cat /etc/make.conf WITH_NEW_XORG=true WITH_KMS=true X.Org X Server 1.10.6 Release Date: 2012-02-10 intel(0): Integrated Graphics Chipset: Intel(R) Sandybridge Mobile (GT2+) (end of quote from Andrey Fesenko) After adding those, graphics/libdrm must be rebuilt, and x11-drivers/xf86-video-intel must have the KMS option enabled and be rebuilt. If you just added WITH_NEW_XORG, there will be other xorg components that need to be updated. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gpart resize vs. cache?
On Sun, 3 Feb 2013, Tim Kientzle wrote: On Feb 3, 2013, at 1:08 PM, Ian Lepore wrote: On Sun, 2013-02-03 at 12:06 -0800, Tim Kientzle wrote: I'm tinkering with a disk image that automatically fills whatever media you put it onto. But I'm having trouble with gpart resize failing. Disk layout: MBR with two slices mmcsd0s1 and mmcsd0s2 bsdlabel with one partition mmcsd0s2a Before I can use growfs, I have two gpart resize operations: 1) gpart resize -i 2 mmcsd0 2) gpart resize -i 1 mmcsd0s2 Step 1 resizes mmcsd0s2 and always succeeds. Step 2 resizes mmcsd0s2a and always fails with "No space on device." BUT if I reboot between these steps, step #2 always succeeds. I suspect that step #1 is updating the partition information on disk but that step #2 is somehow reading the old size of mmcsd0s2 and thus finding that there is no available space to grow the partition. BTW, I've added some debug messages to gpart and the second resize is failing because the new computed size is a little smaller than the old size (maybe because of a different alignment?). But it's certainly not sizing to the new container size. MBR always forces alignment to imaginary CHS tracks, as if you used -a63 in gpart. But it's not gpart, it's the kernel being really strict about standards. As far as I've been able to tell, there is no way around that short of possibly dd-ing a preconstructed MBR partition table into place. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem after installkernel going from 9.0 to CURRENT
On Thu, 3 Jan 2013, Kevin Oberman wrote: One possibility: I believe I labeled each of the partitions during the gpt creation process. Can I use those labels to (hopefully) by-pass this issue? Yes! This is the current recommended way of doing it. cat /etc/fstab # DeviceMountpoint FStype Options DumpPass# /dev/gpt/swap noneswapsw 0 0 /dev/gpt/root / ufs rw 1 1 /dev/gpt/tmp/tmpufs rw 2 2 /dev/gpt/usr/usrufs rw 2 2 /dev/gpt/var/varufs rw 2 2 To avoid collisions, I recommend people use unique labels on each system. I sometimes pick a couple of letters from the system name or drive: xfswap, xfrootfs, xftmpfs, xfusrfs, xfvarfs. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: problem after installkernel going from 9.0 to CURRENT
On Wed, 2 Jan 2013, Robert Huff wrote: (While this may not be a strictly CURRENT issue, I asked on questions@, but have not found a solution.) Situation: One of my boxes failed, and for various reasons it became easier to just scrub and rebuild it. Like its predecessor it will run CURRENT 1) Using BSDinstall, I flushed then created the first disk: ada2p1 freebsd-boot128k ada2p2 freebsd-swap4g ada2p3 freebsd-ufs 25g (There are non-bootable disks at ada0, -1, and -3.) 2) Installed off the 9.0 CD, got it up and running, everything was good. 3) Used csup (tag=.) to update the source tree as of 00:01 on 12/30. 4a) Built world - OK. 4b) Build kernel - OK. 4c) Ran mergemaster - OK. 4d) Installed kernel - OK. 5) On rebooting, the loader(??) claims to not be able to find a bootable partition - i.e. I get a screen that ends in "mountroot > ". Providing the presumptive value by hand returns "error 19". 6) Boot using installation CD and use "gpart show" to double check device names and partitions; everything looks good. 7) Try normal booting again, no go. This is my first time installing to a completely GPT partitioned system, and I have (obviously) failed to grok something. I checked src/UPDATING and found nothing which covered this. What have I bungled, and how do I fix it? It really does not sound like a GPT problem, because 9.0 booted. The -current kernel can't find/detect the device. Scrolling back in the console buffer might find a problem. buildworld/kernel/installworld do not affect the disk partitioning, but can change the code that looks for those partitions. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.1-RC3 LiveCD missing features
On Fri, 7 Dec 2012, Garrett Cooper wrote: On Fri, Dec 7, 2012 at 11:06 PM, CeDeROM wrote: Hello Ian :-) This is the problem - / is read only and /etc/resolv.conf already links to nonexistent file. This way I cannot modify its content nor link other file (i.e. /var/resolv.conf) to /etc/resolv.conf. Creating /var/resolv.conf does not help either. I think /etc/resolv.conf should point to /var/resolv.conf from start so the resolver is functional :-) I generally get around this with mdmfs and unionfs mounts, but it's a bit annoying... I'll see if I can file a PR with all of the things that need to be fixed/enhanced and maybe fix some of the items if I get some time (if the liveCD used rc.initdiskless it would be considerably simpler and some key filesystems would be writable after boot). Martin Matuska's excellent mfsBSD (http://mfsbsd.vx.sk/) could be a source for ideas or techniques. It does things like this well. (I was going to say it does *most* things well, but can't actually think of anything it does not do well.) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.1-RC3 LiveCD missing features
On Fri, 7 Dec 2012, Chuck Burns wrote: dd if=/dev/zer of=/dev/ada0 ^^^ There's your "badblocks" program. Any hard drive made in the last decade have been self-remapping.. That should be /dev/zero. And this will be very slow, going one 512-byte block at a time. Using a 64K or 128K buffer (bs=128K) will speed it up tremendously. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sluggish X.org/Xfce behavior
On Tue, 20 Nov 2012, René Ladan wrote: On 20-11-2012 15:34, Warren Block wrote: On Tue, 20 Nov 2012, René Ladan wrote: since last weekend (November 17th) I have been noticing a sluggish behavior of X.org/Xfce. Typical symptoms are: - Alt-Tab not reacting all of the time - pulldown/popup menus not allowing selections with mouse (typically in Terminal/pidgin), or moving the mouse (touchpad) results in an automatic click - typing something in a Terminal requires mouse (touchpad) movements for the text to show up - sometimes moving the mouse (touchpad) is required for the laptop to "wake up"; this is noticeable when Thunderbird downloads all messages from the period when the laptop was "frozen". This is one of the problems that having Option "AllowEmptyInput" "Off" in xorg.conf causes. If you have that, substitute Option "AutoAddDevices" "Off" in the same place. Commenting out "AllowEmptyInput" "Off" (and not having an AutoAddDevices entry) works for me. Must do better homework... http://www.wonkity.com/~wblock/docs/html/aei.html gives more detail.___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sluggish X.org/Xfce behavior
On Tue, 20 Nov 2012, René Ladan wrote: since last weekend (November 17th) I have been noticing a sluggish behavior of X.org/Xfce. Typical symptoms are: - Alt-Tab not reacting all of the time - pulldown/popup menus not allowing selections with mouse (typically in Terminal/pidgin), or moving the mouse (touchpad) results in an automatic click - typing something in a Terminal requires mouse (touchpad) movements for the text to show up - sometimes moving the mouse (touchpad) is required for the laptop to "wake up"; this is noticeable when Thunderbird downloads all messages from the period when the laptop was "frozen". This is one of the problems that having Option "AllowEmptyInput" "Off" in xorg.conf causes. If you have that, substitute Option "AutoAddDevices" "Off" in the same place.___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: No ATA disks on 9.1-RC3
On Mon, 19 Nov 2012, Alex Keda wrote: I try update my laptop - Compaq 6715s from 9.0 to 9.1-rc3 it cannot boot, because no HDD found dmesg from 9.0/9.1 and pciconf in attached files If there is an IDE/AHCI mode setting in the BIOS, switch it to the other setting. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.1-RC3 feels okay :-)
On Thu, 8 Nov 2012, Richard Kuhns wrote: On 11/08/12 10:45, Warren Block wrote: On Thu, 8 Nov 2012, CeDeROM wrote: I have tested additional options in xorg runtime :-) With the patched xorg mouse driver 1.7.1 (or driver version >=1.7.2) situation is following: 1. With hald and dbus no xorg.conf file is needed. However it might bo option to pass some additional featutes parameters with xorg.conf. 2. With no hald and dbus mouse and keyboard does not work in xorg unless Option "AllowEmptyInput" "False" is added to Section "ServerLayout" by hand in xorg.conf. Without this option input does not work even if xorg.conf defines it! AllowEmptyInput=False forces to detect input deviced by Xorg at startup. No. AllowEmptyInput is wrong. It was causing so many problems that it has been removed from later xorg-server releases. Option "AutoAddDevices" "Off" is the one that means "dont' use Hal to detect input devices". Thank you for this hint! This could be added to the handbook :-) AllowEmptyInput=False should be a default for Xorg IMO we can report it to the Xorg project! :-) Really, the simplest solution is to build xorg-server with the HAL option disabled. I agree that this should be the default. Just a comment: according to http://wiki.freebsd.org/VirtualBox, Hal is still required for VirtualBox in order to have host DVD/CD access. This is probably a permissions thing. VirtualBox sees the device, but can't quite mount it. So hal may not be actually required for that function in VirtualBox, but figuring out just what is needed without hal remains to be done. KDE and Gnome both still need hal, but AFAIK do not require it to be used for xorg input device detection. xfce4 works fine without hal. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.1-RC3 feels okay :-)
On Thu, 8 Nov 2012, Tomek CEDRO wrote: WARNING!!! When AllowEmptyInput = False AND Hal is running really really bad things happen to Xorg!! Keys are messed up and screen is refreshed only after mouse move! Things are slow and the end of the word is near :-) AllowEmptyInput seems to be exclusive with Hal!! Please confirm :-) It's a known problem, in the same class as "Doctor, it hurts when I do this." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.1-RC3 feels okay :-)
On Thu, 8 Nov 2012, Ian Lepore wrote: On Thu, 2012-11-08 at 08:45 -0700, Warren Block wrote: On Thu, 8 Nov 2012, CeDeROM wrote: I have tested additional options in xorg runtime :-) With the patched xorg mouse driver 1.7.1 (or driver version >=1.7.2) situation is following: 1. With hald and dbus no xorg.conf file is needed. However it might bo option to pass some additional featutes parameters with xorg.conf. 2. With no hald and dbus mouse and keyboard does not work in xorg unless Option "AllowEmptyInput" "False" is added to Section "ServerLayout" by hand in xorg.conf. Without this option input does not work even if xorg.conf defines it! AllowEmptyInput=False forces to detect input deviced by Xorg at startup. No. AllowEmptyInput is wrong. It was causing so many problems that it has been removed from later xorg-server releases. This is disturbing news. We build embedded systems at work that use X for presentation and have no input devices. I understand that AllowEmptyInput is inappropriate to work around the problem we're discussing here, but that doesn't mean it's never needed. The xorg folks should be able to suggest the right replacement. Option "AutoAddDevices" "Off" is the one that means "dont' use Hal to detect input devices". Thank you for this hint! This could be added to the handbook :-) AllowEmptyInput=False should be a default for Xorg IMO we can report it to the Xorg project! :-) Really, the simplest solution is to build xorg-server with the HAL option disabled. I agree that this should be the default. So if you're using xorg-server that was built with hal included (maybe because you're more a package than a ports kind of person and have no control over the build), is AutoAddDevices still the right option to manipulate? That is, will it disable the use of hal and fall back to honoring the xorg.conf input devices even if the server was built with hal support? xorg-server with hal support and AutoAddDevices Off in xorg.conf should be equivalent to xorg-server built without hal support. Put another way: if xorg-server is built without hal support, AutoAddDevices is irrelevant, it can't use hal for input device detection anyway. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.1-RC3 feels okay :-)
On Thu, 8 Nov 2012, CeDeROM wrote: I have tested additional options in xorg runtime :-) With the patched xorg mouse driver 1.7.1 (or driver version >=1.7.2) situation is following: 1. With hald and dbus no xorg.conf file is needed. However it might bo option to pass some additional featutes parameters with xorg.conf. 2. With no hald and dbus mouse and keyboard does not work in xorg unless Option "AllowEmptyInput" "False" is added to Section "ServerLayout" by hand in xorg.conf. Without this option input does not work even if xorg.conf defines it! AllowEmptyInput=False forces to detect input deviced by Xorg at startup. No. AllowEmptyInput is wrong. It was causing so many problems that it has been removed from later xorg-server releases. Option "AutoAddDevices" "Off" is the one that means "dont' use Hal to detect input devices". Thank you for this hint! This could be added to the handbook :-) AllowEmptyInput=False should be a default for Xorg IMO we can report it to the Xorg project! :-) Really, the simplest solution is to build xorg-server with the HAL option disabled. I agree that this should be the default. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.1-RC3 feels okay :-)
On Wed, 7 Nov 2012, CeDeROM wrote: Isn't this a Xorg bug then? When I have no configuration file Hal should provide the configuration, so sooner or later the mouse should start moving... but is does not.. Do I get http://www.wonkity.com/~wblock/docs/html/aei.html correct that when I am using xorg.conf there is no need for Hal and when I am using Hal there is no need for xorg.conf? Not quite, no. xorg.conf is the configuration file for xorg-server. It can do a lot more than just identify input devices. Option "AutoAddDevices" "Off" tells xorg-server: even if hal is present and running, don't use it to detect input devices. AFAIK, hal is not used by xorg-server for anything else. All other autoconfig (video card detection, monitor detection, it even has its own built-in input device detection) is done by the xorg server itself. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.1-RC3 feels okay :-)
On Wed, 7 Nov 2012, Julian H. Stacey wrote: Ian Lepore wrote: Before you do that, read this: http://www.wonkity.com/~wblock/docs/html/aei.html The page is bad here: "Summary ... just let xorg-server use hald by default." FreeBSD 8.3-RELEASE & 9.0-RELEASE by default do Not run hald. See: /usr/local/etc/rc.d/hald # Add the following line to /etc/rc.conf to enable the HAL daemon: # # hald_enable="YES" There is no hald_enable="YES" in /etc/defaults/rc.conf (Happily, IMO). It's not saying that hald is run by default, merely that xorg-server will try to use it by default. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"