Re: ZFS RAIDZ1: resilvering at <17.3M/s => abyssal slow ...
On Thu, Dec 14, 2017 at 8:52 AM, O. Hartmann wrote: > Am Thu, 14 Dec 2017 15:46:17 +0100 > Dimitry Andric schrieb: > > > On 14 Dec 2017, at 14:43, O. Hartmann wrote: > > > > > > Am Thu, 14 Dec 2017 14:09:39 +0100 > > > Daniel Nebdal schrieb: > > >> On Thu, Dec 14, 2017 at 12:48 PM, O. Hartmann > wrote: > > >>> I just started the rebuild/resilvering process and watch the pool > crwaling at ~ 18 > > >>> MB/s. At the moment, there is no load on the array, the host is a > IvyBridge XEON > > >>> with 4 core/8 threads and 3,4 GHz and 16 GB of RAM. The HDDs are > attached to a > > >>> on-board SATA II (300 MB/s max) Intel chip - this just for the > record. > > >>> > > >>> Recently, I switch on the "sync" attribute on most of the defined > pools's zfs > > >>> filesystems > > >>> - I also use a SSD for ZIL/L2ARC caching, but it seems to be unused > recently in > > >>> FreeBSD CURRENT's ZFS - this from a observers perspective only. > > >>> > > >>> When scrubbing, I see recently also reduced performance on the pool, > so I'm > > >>> wondering about the low throughput at the very moment when > resilvering is in > > >>> progress. > > >>> > > >>> If the "perspective" of "zpool status" is correct, then I have to > wait after two > > >>> hours for another 100 hours - ~ 4 days? Ups ... I think there is > something badly > > >>> misconfigured or missing. > > ... > > >> This is kind of to be expected - for whatever reason, resilvers seem > > >> to go super slow at first and then speed up significantly. Just don't > > >> ask me how long "at first" is - I'd give it several (more) hours. > > > > Hopefully this will get better in the future, please read: > > > > http://open-zfs.org/wiki/Scrub/Resilver_Performance > > > > -Dimitry > > > > It has already been started to become better ;-) > > After a while now, the throughput is at 128 MBytes/s and the estimated > time decreased to > ~ 8 h now - that is much more appreciable than 4 days ;-) > If you are viewing the rate with zpool status, I don't think that is a close to realtime rate. I don't know of a way to check that either. -- Adam ___ 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"
iwn wlan connection losses after recent upgrade from 10-stable to head
Recently I upgraded my system to head from 10-stable: 11.0-CURRENT #0 r293760: iwn0: mem 0xe3c0-0xe3c01fff irq 17 at device 0.0 on pci2 net.wlan.debug: 1 net.wlan.0.debug: 1 wlan0: flags=8843 metric 0 mtu 1500 ether 24:77:03:07:32:b8 inet 192.168.254.21 netmask 0xff00 broadcast 192.168.254.255 nd6 options=29 media: IEEE 802.11 Wireless Ethernet MCS mode 11ng status: associated ssid SSID channel 1 (2412 MHz 11g ht/20) bssid 28:c6:8e:e6:04:7c country US authmode WPA2/802.11i privacy ON deftxkey UNDEF AES-CCM 2:128-bit AES-CCM 3:128-bit powersavemode CAM powersavesleep 100 txpower 13 bmiss 10 scanvalid 60 protmode CTS ampdulimit 64k ampdudensity 8 -amsdutx amsdurx shortgi wme roaming MANUAL groups: wlan While the 10-STABLE setup was never a pillar of reliability, HEAD seems to have made things worse for my wifi setup. Now my connections drops out several times a day at least resulting in logs such as this: wpa_supplicant[81975]: wlan0: CTRL-EVENT-DISCONNECTED bssid=28:c6:8e:e6:04:7c reason=0 kernel: wlan0: link state changed to DOWN wpa_supplicant[81975]: wlan0: Trying to associate with 28:c6:8e:e6:04:7c (SSID='SSID' freq=2412 MHz) wpa_supplicant[81975]: wlan0: Authentication with 28:c6:8e:e6:04:7c timed out. wpa_supplicant[81975]: wlan0: CTRL-EVENT-DISCONNECTED bssid=28:c6:8e:e6:04:7c reason=3 locally_generated=1 wpa_supplicant[81975]: wlan0: Trying to associate with 28:c6:8e:e6:04:7c (SSID='SSID' freq=2412 MHz) wpa_supplicant[81975]: wlan0: Authentication with 28:c6:8e:e6:04:7c timed out. wpa_supplicant[81975]: wlan0: CTRL-EVENT-DISCONNECTED bssid=28:c6:8e:e6:04:7c reason=3 locally_generated=1 wpa_supplicant[81975]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=1 ssid="SSID" auth_failures=1 duration=10 reason=CONN_FAILED wpa_supplicant[81975]: wlan0: CTRL-EVENT-SSID-REENABLED id=1 ssid="SSID" wpa_supplicant[81975]: wlan0: Trying to associate with 28:c6:8e:e6:04:7c (SSID='SSID' freq=2412 MHz) wpa_supplicant[81975]: wlan0: Authentication with 28:c6:8e:e6:04:7c timed out. wpa_supplicant[81975]: wlan0: CTRL-EVENT-DISCONNECTED bssid=28:c6:8e:e6:04:7c reason=3 locally_generated=1 wpa_supplicant[81975]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=1 ssid="SSID" auth_failures=2 duration=23 reason=CONN_FAILED wpa_supplicant[81975]: wlan0: CTRL-EVENT-SSID-REENABLED id=1 ssid="SSID" wpa_supplicant[81975]: wlan0: Trying to associate with 28:c6:8e:e6:04:7c (SSID='SSID' freq=2412 MHz) wpa_supplicant[81975]: wlan0: Authentication with 28:c6:8e:e6:04:7c timed out. Under 10-STABLE, such events were usually only a few times a week. I've just disabled N to see if that helps, but is the decreased reliability expected? Is there anything I can do to improve stability and preserve N? Thanks, -- Adam ___ 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: init(8) diagnostics?
On Sun, Nov 16, 2014 at 12:37 PM, Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > On Sun, Nov 16, 2014 at 01:23:00PM -0500, Allan Jude wrote: > > On 2014-11-16 13:07, Steve Kargl wrote: > > > In init(8), one finds under DIAGNOSISTICS > > > > > >"some processes would not die; ps axl advised." > > > > > > So, just how is one to actually run 'ps axl advised' as > > > the message appears as init(8) is killing off the system? > > > > > > > In this case 'advised' is not a literal part of the command, but rather, > > it is suggesting that running 'ps axl' will show which process(es) are > > still running, and those would be the ones that would not die. > > > > When this message comes up, how far through the shutdown are you? Does > > it stall there for a while? or continue quickly? > > > > Yes, I know that the message means that one should run 'ps axl'. > > The system is well beyond any hope of interactive commands at the > console. It appears right after init(8) stops syslogd and before > the 'stopping vnlru ... done.' message. > > I was hoping that I could put the command in /etc/shutdown.rc, but > reading that script did not provide the insight needed to automatically > run the command. > > It is somewhat surprising that init(8) does not give the PID(s) of > the offending process(es). Or why doesn't it just run it automatically. -- Adam ___ 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: android bsd connectivity tools etc ?
On Wed, Aug 13, 2014 at 6:47 PM, Julian H. Stacey wrote: > Hi, > Any tips for Android / FreeBSD BSD tools for connectivity etc ? > > I just got a Samsung Galaxy Note 3, with Android 4.4.2 kernel 3.4.0 > > It directs me to > https://www.android.com/filetransfer/ > which seems binary for mac > > I recall I will need current for IP tethering > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-usb-tethering.html > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-aggregation.html#networking-lagg-wired-and-wireless > > I'll build a current from a 10.0-RELEASE partition, > but now looking with 9.2-RELEASE I see: > > /dev/ > lrwxr-xr-x 1 root wheel9 Aug 14 00:01 ugen1.5@ -> usb/1.5.0 > crw--- 1 root operator 0x7a Aug 14 00:00 usb/1.5.0 > crw--- 1 root operator 0x8f Aug 14 00:00 usb/1.5.1 > crw--- 1 root operator 0x90 Aug 14 00:00 usb/1.5.2 > > devd .conf will need: >match "vendor""0x04e8"; >match "product" "0x6860"; >match "devclass" "0x00"; >match "devsubclass" "0x00"; >match "sernum""6758498c"; >match "release" "0x0400"; > I've no idea what to do for attach > > http://www.freebsd.org/cgi/ports.cgi?query=android&stype=all > has just > /usr/ports/devel/android-tools-adb/pkg-descr > & these for cross compiling later: > /usr/ports/lang/*gnatdroid*/pkg-descr > > I also found > ports/ > deskutils/tine20 > net/crtmpserver > net/linphone > https://source.android.com/source/index.html > > Any URLs, tips, comments welcome, Thanks > Android can run an sshd server as well as a socks proxy. -- Adam ___ 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 command can block the whole ZFS subsystem!
On Sun, Jan 5, 2014 at 9:41 AM, O. Hartmann wrote: > > > > > As already described by Dan and perhaps not followed up on: dedup > > requires at very large amount of memory. Assuming 32GB is sufficient > > is most likely wrong. > > > > What does zdb -S BACKUP00 say? > > That command is stuck for 2 hours by now ... That is expected. It is not stuck, it is running. It's output will indicate what is the minimum required for your dataset. The command will be slow if you have large dataset/insufficient ram. Really slow if both. -- Adam ___ 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 command can block the whole ZFS subsystem!
On Sun, Jan 5, 2014 at 2:11 AM, O. Hartmann wrote: > On Sun, 5 Jan 2014 10:14:26 +1100 > Peter Jeremy wrote: > > > On 2014-Jan-04 23:26:42 +0100, "O. Hartmann" > > wrote: > > >zfs list -r BACKUP00 > > >NAME USED AVAIL REFER MOUNTPOINT > > >BACKUP00 1.48T 1.19T 144K /BACKUP00 > > >BACKUP00/backup 1.47T 1.19T 1.47T /backup > > > > Well, that at least shows it's making progress - it's gone from 2.5T > > to 1.47T used (though I gather that has taken several days). Can you > > pleas post the result of > > zfs get all BACKUP00/backup > > > > Here we go: > > > NAME PROPERTY VALUE SOURCE > BACKUP00/backup type filesystem- > BACKUP00/backup creation Fr Dez 20 23:17 2013 - > BACKUP00/backup used 1.47T - > BACKUP00/backup available 1.19T - > BACKUP00/backup referenced1.47T - > BACKUP00/backup compressratio 1.00x - > BACKUP00/backup mounted no- > BACKUP00/backup quota none default > BACKUP00/backup reservation none default > BACKUP00/backup recordsize128K default > BACKUP00/backup mountpoint/backup local > BACKUP00/backup sharenfs off default > BACKUP00/backup checksum sha256local > BACKUP00/backup compression lz4 local > BACKUP00/backup atime ondefault > BACKUP00/backup devices ondefault > BACKUP00/backup exec ondefault > BACKUP00/backup setuidondefault > BACKUP00/backup readonly off default > BACKUP00/backup jailedoff default > BACKUP00/backup snapdir hiddendefault > BACKUP00/backup aclmode discard default > BACKUP00/backup aclinheritrestricteddefault > BACKUP00/backup canmount ondefault > BACKUP00/backup xattr ondefault > BACKUP00/backup copies1 default > BACKUP00/backup version 5 - > BACKUP00/backup utf8only off - > BACKUP00/backup normalization none - > BACKUP00/backup casesensitivity sensitive - > BACKUP00/backup vscan off default > BACKUP00/backup nbmandoff default > BACKUP00/backup sharesmb onlocal > BACKUP00/backup refquota none default > BACKUP00/backup refreservationnone default > BACKUP00/backup primarycache all default > BACKUP00/backup secondarycacheall default > BACKUP00/backup usedbysnapshots 0 - > BACKUP00/backup usedbydataset 1.47T - > BACKUP00/backup usedbychildren0 - > BACKUP00/backup usedbyrefreservation 0 - > BACKUP00/backup logbias latency default > BACKUP00/backup dedup onlocal > As already described by Dan and perhaps not followed up on: dedup requires at very large amount of memory. Assuming 32GB is sufficient is most likely wrong. What does zdb -S BACKUP00 say? Also I will note you were asked if the ZFS FS in question had dedup enabled. You replied with a response from an incorrect FS. -- Adam ___ 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: RTL8111/8168B not negotiating 1GB
On Thu, Jan 2, 2014 at 7:39 PM, Sam Fourman Jr. wrote: > Hello list, > > I have a Asus Sabertooth 990FXv2 motherboard, and a run of the mill > NetGear DGS2205 desktop gig switch > > with linux my Ethernet can negotiate at 1GB but with FreeBSD it can not > if I force the device to 1000baseT with ifconfig it does not work. > > > uname -a > FreeBSD NewBSD 11.0-CURRENT FreeBSD 11.0-CURRENT #1 r260188M: Thu Jan 2 > 04:27:49 CST 2014 sfourman@NewBSD:/usr/obj/usr/src/sys/GENERIC amd64 > > > > re0@pci0:10:0:0: class=0x02 card=0x85051043 chip=0x816810ec rev=0x09 > hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > device = 'RTL8111/8168B PCI Express Gigabit Ethernet controller' > class = network > subclass = ethernet > > > > root@NewBSD:/usr/home/sfourman/Desktop # ifconfig > re0: flags=8843 metric 0 mtu 1500 > > options=8209b > ether 60:a4:4c:60:d5:a7 > inet 192.168.1.31 netmask 0xff00 broadcast 192.168.1.255 > inet6 fe80::62a4:4cff:fe60:d5a7%re0 prefixlen 64 scopeid 0x1 > nd6 options=29 > media: Ethernet autoselect (100baseTX ) > status: active /etc/rc.conf is important here as well as the complete steps and output which provoked this response: "but with FreeBSD it can not if I force the device to 1000baseT with ifconfig it does not work." In the given output, autoselect clearly selects 100Mb connection, the question is why. -- Adam ___ 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] libdispatch (aka Grand Central Dispatch) in base
On Tue, Oct 29, 2013 at 9:04 PM, Teske, Devin wrote: > Hi all, > > I'd like to bring up the discussion for topic.. > > Importing libdispatch (aka Apple's Grand Central Dispatch) into base > (contrib?). > > Specifically into HEAD then MFC'd only as far back as stable/10. > > Here's the reason why: > http://devinteske.com/freebsd-installer-enhancements > > Summary: > For the purpose of providing a concurrency model better than pthreads for > the > expressed desire to bring about concurrent data processing (applicable > directly > to distributions, packages, signing and more). > > Multiple people have confirmed with me with respect to the above blog > article > that the concurrency model would be most efficient with libdispatch. > > Since the tool mentioned in the blog is > a. Compiling with clang > b. Requires newest dialog(3) that is only in stable/10 or higher > > I'd say that it looks like a match made in heaven. > > But of course, there's that one hang-up... dispatch is not available in > base yet. > > Is anyone working on getting dispatch into base? FWIW, I say +1 to your proposition and +1 to your contribs. However I say prove it works. , -- Adam ___ 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: rcs is gone?
On Mon, Oct 7, 2013 at 8:30 PM, Adam Vande More wrote: > > I would like to see RCS remain in base as well. Many enterprise distro > still ship it by default too. There is no compelling reason to remove it. > I sort of retract that statement. I thought the base RCS was already OpenRCS. I support the inclusion of OpenRCS. That functionality is very useful and many admins are used to having it present. -- Adam Vande More ___ 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: rcs is gone?
On Mon, Oct 7, 2013 at 8:16 PM, Julian Elischer wrote: > On 10/8/13 9:05 AM, Lyndon Nerenberg wrote: > >> On 2013-10-07, at 5:58 PM, Ian Lepore wrote: >> >> I have not re-read those threads to see just how much of the discussion >>> involved rcs, I just spot-checked a few and confirmed my memory that it >>> showed up in some of the messages there. >>> >> I don't see any discussion as to why the code (CVS, in this case) *needs* >> to be removed. >> >> What, in the current builds of 10.x, is broken by leaving RCS/CVS in >> place? And what, as 10.x moves forward towards a public release, will be >> broken by leaving this code in the base? >> > I have less of a problem with replacing CVS with svnlite than I have with > removing RCS. > After all CVS's main reason for being in the system has switched to > svnlite. > And if you are using CVS yourself for other developement, you are probbaly > further > on with installing a system and are already installing other packages. > that's not the case with RCS. I know that people use it as part of their > install > procedure. Plus RCS is used within other tools. e.g. patch etc. It's also > a REALLY SMALL > utility, suitable for embedding into scripts etc. (the Unix way(TM)) I > consider it a base utility. > It does a simple operation on a file. > > the discussion in arch was A YEAR AGO, was hidden under a differnet title, > and DID NOT RESULT > in a clear mandate to remove RCS. > > Please put it back, and inthe mena while while we discuss it properly this > time, please revert the commit > (official request.. as described in the group rules). I would like to see RCS remain in base as well. Many enterprise distro still ship it by default too. There is no compelling reason to remove it. -- Adam Vande More ___ 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, Dec 7, 2012 at 5:05 PM, Tomek CEDRO wrote: > As I get ffs_valloc kernel panic on my / I want to check for badblocks but > cannot do that from the system itself so I need another FreeBSD instance to > run badblocks on unmounted /. There are no badblocks on LiveCD and I cannot > simply download it with pkg_add -r. Installing another system just to test > existing one seems silly. It would be nice to finally have swiss army knife > on generic LiveCD FreeBSD install, not using linux windows hirens etc :-) > > I have just started dd if=root of=root from LiveCD, Ill let you know if > that worked :-) You probalby want a filesystem tool but it's impossible to tell since you didn't include all the relevant info. Try fsck. If you did want a "badblocks" tool from the base system, /sbin/recoverdisk is the best. dd is fine, but not as through as it. -- Adam Vande More ___ 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: after upgrade, can't restart apache via cron
On Thu, Nov 22, 2012 at 9:17 PM, Michael W. Lucas wrote: > > > FreeBSD bewilderbeast.blackhelicopters.org 10.0-CURRENT FreeBSD > 10.0-CURRENT #15: Thu Nov 8 14:02:45 EST 2012 > mwlu...@bewilderbeast.blackhelicopters.org:/usr/obj/usr/src/sys/GENERIC > amd64 > > I can manually restart apache22 with the following /etc/rc.conf entries: > > apache22_enable="YES" > apache22_fib=0 > > I have a cron entry that restarts apache regularly, to compensate for > some mysql daftness. > > 13 * * * * /usr/local/etc/rc.d/apache22 restart > > When this job runs, I get the following email: > > Performing sanity check on apache22 configuration: > Syntax OK > Stopping apache22. > Waiting for PIDS: 59501. > Performing sanity check on apache22 configuration: > Syntax OK > Starting apache22. > eval: setfib: not found > /usr/local/etc/rc.d/apache22: WARNING: failed to start apache22 > > If I run /usr/local/etc/rc.d/apache22 restart from the command line, I > can restart httpd without trouble. > > Any thoughts? > I would guess you need /usr/sbin/ in cron's path. -- Adam Vande More ___ 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: Upgrading FreeBSD to use the NEW pf syntax. (Copied from freebsd-pf)
On Tue, Nov 20, 2012 at 12:22 PM, Chuck Burns wrote: > The ones who want the old pf can maintain it.. those who want the new one, > can maintain *it*. This is beach front property on Fantasy Island. There isn't even enough manpower to sufficiently support one currently. -- Adam Vande More ___ 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: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 12:19 PM, Roman Divacky wrote: > > Can you please provide a small self contained test case that shows > that clang is doing worse on accuracy than gcc? > > So that we can analyze it and decide if it's a bug in the code or > in the compiler. So far we know absolutely nothing. > Not to speak for Steve, but he provided this information in another thread: http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036410.html -- Adam Vande More ___ 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: sysctl filesystem ?
On Mon, Jun 25, 2012 at 7:03 PM, Arnaud Lacombe wrote: > Hi folks, > > I find myself in a situation where I need to directly explore the > sysctl(8) tree from my program. The tricky part is this: > There is this: http://svnweb.freebsd.org/base/releng/4.7/sys/miscfs/kernfs/ -- Adam Vande More ___ 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: Enhancing the user experience with tcsh
On Thu, Feb 9, 2012 at 6:52 PM, Eitan Adler wrote: > In conf/160689 (http://www.freebsd.org/cgi/query-pr.cgi?pr=160689) > there has been some discussion about changing the default cshrc file. > > I'd like to commit something like the following based on Chris's patch > at the end of the thread. This post is an attempt to open the change > to wider discussion. > > commit dbe6cb730686dd53af7d06cc9b69b60e6e55549c > diff --git a/etc/root/dot.cshrc b/etc/root/dot.cshrc > --- a/etc/root/dot.cshrc > +++ b/etc/root/dot.cshrc > @@ -7,9 +7,10 @@ > > alias hhistory 25 > alias jjobs -l > -alias la ls -a > +alias la ls -aF > alias lf ls -FA > -alias ll ls -lA > +alias ll ls -lAF > > I don't like the change to alias ll. I use it frequently and the proposed change makes it less readable. Otherwise, these mostly seem overdue. -- Adam Vande More ___ 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: Need a README to explain items in download directory
On Sat, Sep 3, 2011 at 6:00 PM, Craig Rodrigues wrote: > For this line: > > (1) FreeBSD-8.2-RELEASE-i386-bootonly.iso - Requires an Internet > Connection > > Does this mean that this ISO has the minimal stuff to boot, and > then do an install by downloading packages over the Internet? I really > don't > know, that's why I'm asking. :) > While such wording may be helpful to a new user over completely absent directions, it's technically flawed. You don't need an internet connection, but rather a network connection or some other form of installation media. -- Adam Vande More ___ 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: Trying to install current from a memory stick and then a DVD and got a new and strange installer.
On Mon, Jul 25, 2011 at 11:46 AM, eculp wrote: > That makes two of us right now. I gave up, accepted the automatic > partition and everything else went as expected, I suppose. The disk results > are: > > # df > Filesystem 1K-blocksUsed Avail Capacity Mounted on > /dev/ada0p2 941441086 2150880 863974920 0%/ > devfs 1 1 0 100%/dev > > In my world from the beginning of commercial unix, I have never had a one > partition disk. I'm not sure if it is that bad with today's, controllers, > drives, drivers, etc. I hope someone chimes in with a "I see no major > problems with gpt." > > My major problem was editing the automatic swap that was set at 4G and the > menu would not let me change the 4G. The experienced option would not > accept a blank value as swap even though there was message that said it > would. > > I feel like a real idiot and am beginning to believe that it might be true. > The rest of the install was brain dead. It was possibly a bit simpler than > the previous. Less decisions ;) > > I had the idea the following were available in the new installer. > 1. Raid configuration > 2. ZFS > 3. Regular everyday simple disk partitioning as before. > > I wasn't able to find any functional option except the one mentioned above. > > Now, I have to accept this single partition or upgrade sources to date, > build a release and reinstall but I don't know if the problem has been > fixed. I'll probably give it a try. It isn't that much of a deal. > Hopefully I add something of value to this thread, but as a workaround you can use a PCBSD image and installer to install/partion plain vanilla FreeBSD with the options you mentioned earlier in a graphical enviroment. -- Adam Vande More ___ 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: Switch from legacy ata(4) to CAM-based ATA
On Sun, Apr 24, 2011 at 1:54 PM, Scott Long wrote: > Indeed, there's nothing wrong with preserving access to the system details > for the use of administration, troubleshooting, and even mere geeky > knowledge. This isn't about taking power away from the superusers, it's > about making the system smart enough to handle common situations reliably. > I'm sure that there some among us who pine for the good old days of manually > configuring and linking a kernel, but it's hard to argue that an > auto-configured kernel isn't pretty darn convenient most of the time. What > I'm proposing is just the next step in that process. > For me, your proposal would make life more difficult as it is on Linux. I've had to do more deployment/autoconfig setups recently and FreeBSD's method of device naming makes it much easier for me to deal with. I like the fact I easily know what disk is attached to what controller and what NIC driver is in use. The NIC specific naming is more useful than disk controller, but both have their places for me. It makes tweaking/troubleshooting quicker in some situations. In fact, I would like even more of it it, eg /dev/usbda0. What a disk is called is already different(for me) than what is in fstab since some(maybe many?) people are already using some of the abstraction methods currently available. If a sys-admin makes an effort, a consistent fstab is pretty easily achieved but it's better done by pre-deployment planning rather than after. If one of the new installer proposals handled this automatically, even better. My point is that device names are still an important hint to functionality particularly for auto-deployment/configure settings where specific hardware isn't always known ahead of time. -- Adam Vande More ___ 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: [Call for testers] FreeBSD VirtIO Network Driver
On Sun, Jan 2, 2011 at 5:02 PM, bv wrote: > Hi. > > I'd like to present the network VirtIO driver I've been working on for > the last few months in my spare time. It is not based on the NetBSD code > that is floating around. The attached patch should apply to both recent > -current and -stable. Early development was done on VirtualBox, > but most has been done on KVM/QEMU. > > I'm going to be away from my computer for the next couple of days, > I'll get to any email after then. > Thanks for this work, I'm sure it will be quite useful. I'm testing on a FreeBSD Virtualbox Host/Guest. Guest is CURRENT kern.osrevision: 199506 virtualbox-ose-3.2.10_2 My particular version of Virtualbox isn't optimized yet for virtio I believe, but I did see about 1/3 higher peak bandwidth and a definite reduction in CPU usage. -- Adam Vande More ___ 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: Should green_saver.ko shut off a laptop's backlight?
On Sat, Nov 27, 2010 at 6:39 PM, Doug Barton wrote: > My recollection is that green_saver should turn off an LCD backlight, but I > just loaded it up on my laptop and it's not doing so. It does remove the > text from the screen, but the backlight is still on (i.e., it is doing > exactly what blank_saver does). > > When running X DPMS works on that same laptop, so I know the hardware is > capable. This is 9-current amd64 at r214025. Any suggestions are welcome. > It's never worked for me either and this has been around awhile. http://www.freebsd.org/cgi/query-pr.cgi?pr=114928&cat= -- Adam Vande More ___ 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: Call for Documentation Contributors
On Thu, Sep 2, 2010 at 11:10 PM, Adam Vande More wrote: > Wouldn't it be a lot easier to have a nice article on installing > /usr/ports/misc/freebsd-doc-* from the date of the release of the installed > system? Or maybe offer archive web access to a handbook snapshot from that > date(Django does something similar)? Maintaining separate handbook branches > seems unrealistic if there aren't enough doc contributors to maintain one to > expectations, and IME discrepancies aren't very frequent. > I need to add to that installing release specific handbook/documentation via sysinstall is the Easy Button. -- Adam Vande More ___ 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: Call for Documentation Contributors
On Thu, Sep 2, 2010 at 5:54 PM, Daniel Gerzo wrote: > I actually think there is some point in this idea. The problem is that many > times we just leave notes or warnings specific for given releases, which can > many times lead to confusion (or people just don't notice) and as time goes > and we cut the support for given releases they get stale (e.g. We had many > of those for 5.x). > > We could just maintain the handbook in separate branches like we do with > src, keeping them all built online, and merge relevant things where > appropriate. This will, however, add quite a lot (for my taste) of > additional work for us. > Wouldn't it be a lot easier to have a nice article on installing /usr/ports/misc/freebsd-doc-* from the date of the release of the installed system? Or maybe offer archive web access to a handbook snapshot from that date(Django does something similar)? Maintaining separate handbook branches seems unrealistic if there aren't enough doc contributors to maintain one to expectations, and IME discrepancies aren't very frequent. -- Adam Vande More ___ 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: CD/DVD ejecting after sysinstall
On Sat, Aug 21, 2010 at 5:24 PM, Randi Harper wrote: > On Aug 20, 2010, at 14:21, Rui Paulo wrote: > > > > You are correct. We should not be ejecting the CD without a prompt. If > the commit is reverted, it should be explicitly noted in the code so that we > don't do this mistake again. > > > > Regards, > > -- > > Rui Paulo > > > > > > That's a judgement call, not an absolute. I think what we are doing isn't a > problem for 99.999% of use cases. > I think 99.999% is a bit high, as couple times during my FreeBSD usage this would have been a problem for me although is not currently an issue. I don't really know what problem this solves as it is unnecessary in 100% of use cases as far as I can tell. It's not that I don't appreciate the thought behind it, but this will be problem for others I imagine as well. It's a VERY big inconvenience sometimes to visit a datacenter when you thought you had a rock solid remote setup in place. In defense of the current behavior, you can get basically the same behavior by setting up a PXE boot system, but that is not always desirable or convenient. Also all KVM's don't give the option to remotely load ISO's. -- Adam Vande More ___ 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: Switchover to CAM ATA?
On Thu, Apr 22, 2010 at 11:25 AM, Julian Elischer wrote: > just one little fly in that ointment... booting. > > You need to be able to act with the raid in the same way the bios does > or you can't boot. I don't think geom would easlily do that but I could be > wrong. Certainly if you treat teh ata raid as just a bunch of striped disks, > then the bios will not be able to boot off it. > > of course don't take my word too seriosly asn I'm not running an ata raid > system at the moment. > gmirror booting works great only thing to change is fstab to reflect block dev changes, gstripe doesn't. I honestly wasn't aware ataraid could boot a striped volume, if so it does something geom can't. -- Adam Vande More ___ 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: Switchover to CAM ATA?
On Thu, Apr 22, 2010 at 10:42 AM, Freddie Cash wrote: > If a lowly user's vote counts for anything, I'd vote for the complete > removal of ataraid support. We have gstripe, gmirror, graid3, graid5, and > zfs (and gvinum for the masochistics). :) We don't need to support any of > the crappy pseudo-raid "hardware" out there. ataraid(4) has served it's > purpose, tiding us over until GEOM RAID facilities were in place. Now it's > time for it to be retired. > +1 on ataraid's retirement. > It doesn't seem to me that sysinstall supports gmirror or gstripe, so > even if they could be better, currently I think many users still use > ataraid for simple installations with mirrored disks. It's hard to say, I'm sure there are some. It's fairly trivial to create gmirrors or gstripes after the install is complete. Also, gstripe's are not bootable volumes. Handbook documentation has been guiding users to gmirror for some time now and gmirror is just much easier to work with IMO. I think sade(and by further discussion sysinstall) is now getting some attention and now supports geom devices, zfs, etc at least in one person's testbed. I know that's it's been tried before but there are actually screenshots from it. http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016418.html -- Adam Vande More ___ 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: ports and PBIs
On Fri, Apr 9, 2010 at 8:31 PM, Julian Elischer wrote: > > Alfred Perlstein , Matt at ix systems Kris (Mr PBI), some > others and I, felt that these ideas seemed to make some sense > and so I put them here for comment. > > FWIW, when I see these discussions I'm always left wondering what's the bad part? I do think there are problems, but there doesn't seem to be a clear defined set of what is wrong. IMO, there should be a defined set of goals to judge possible implementations against. In manys ways, simply having a "Lastest" package archive for RELEASE that is rebuilt say weekly which would resolve most of the problems I run into and address some the non-power users desires as well. Anyways, I'm sure this will be an entertaining thread. -- Adam Vande More ___ 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: Results of BIND RFC
On Fri, Apr 2, 2010 at 3:08 PM, Freddie Cash wrote: > Maybe I'm just a lowly sysadmin and ex-port maintainer, but ... > > No, no, no, definitely no, no, and no!! > > The greatest thing about FreeBSD is that there is a clear separation > between > the "base OS" and everything else (ports, local installs, etc). You get a > nice, clearly defined, base to build on. You get a stable base that > changes > infrequently, that you can add software to on whatever schedule you want. > > The worst thing about Linux distros is the lack of this clear separation > between the base and third-party apps. If you want to install an updated > version of Apache, you either have to update the whole damned distro, go > searching for some unsupported backports repos, or compile everything by > hand defeating the whole point of binary packages. > > Making the tools do deal with the base could be interesting, but please, > please, please don't shove everything into the pkg_tools and turning > FreeBSD > into "just a random collection of packages that kind of work together". > IOW, don't go down the distro path. > > Keep the base OS separate from third-party apps. Keep the tools to deal > with them separate. > True word, brother! If we wanted to run linux there are options for it. debs suck, rpms really suck. Those types of systems are sometimes faster to get up and rolling as long as you want vanilla apps, but they are a major PITA for many types of customizations which are a breeze with the ports tree. You'd be killing of one of the more elegant approaches in FreeBSD. Sure there are problem with it, but IMO adopting more severe problems isn't a good answer. Maybe that was a 4/1 too though. If so, good work. -- Adam Vande More ___ 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"
