Re: nfe0 connection not as reliable; a few questions...
On Sat, 23 Apr 2016 19:48:46 -0700 (PDT), "Jeffrey Bouquet"
wrote:
> Updated current { from Sept last year } to this week... and nfe0 now seems
> to require a reboot
> daily at least { no access to beyond-the-lan ... }
>
> Is there maybe some tunable (net.inet... ) related or sysctl { kern.ipc... }
> similar, that
> could be a cause? New code of ifconfig or the network stack within the last
> seven
> months or so? Usual fixes of MTU size to set?
>
> The coincidence of the daily network stack loss with the installkernel/world
> r298350 would
> at first glance rule out hardware issues... Hadn't seen that type of network
> issue before
> { I can connect to the gateway, but the modem { comtrend } in bridge mode
> seems
> to fail. }.I checked some of the n...@freebsd.org list to no avail...
> The modem had worked
> fine for about two weeks previously... at least.
>
> Apologies for wasting anyone's time; there are tests I could run with more
> machines on the
> lan, but though to ask here first. And did not think of those setups until
> after I had half-completed
> this email...
>
> 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"
Progress [still unsure]. On a hunch I ran a small .sh to ping a site
periodically
[ not constantly and within terms of its
usage of course.] That .sh was set up some years back to keep a wifi
connection up [laptop].
On this desktop, which had a network disconnect at under two hours and under 4
hours, within
the last twenty-four hours or so, it has
now, at least once, had the network reliable for over six hours.
I've yet to do two other tests ( outage wholly across the lan and a different
driver ) but hoping for
this workaround to be feasible...
___
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: why 100 packages are evil
On Sat, 23 Apr 2016 18:52:32 +0100 Matthew Seaman wrote about Re: why 100 packages are evil: MS> > Is freebsd-update going away as result of the new packaging ? > Yes. It will be replaced by 'pkg upgrade' -- as far as I know, that's > the plan for 11.0-RELEASE. Hm... I never had any troubles with freebsd-update, it always "just worked" for me. OTOH, I remember having several issues with pkg, requiring to fix databases manually and so on. cu Gerrit ___ 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
Em seg, 25 de abr de 2016 01:55, Otacílio escreveu: > Em 24/04/2016 14:49, Ivan Klymenko escreveu: > > On Fri, 15 Apr 2016 11:44:43 +0300 > > Ivan Klymenko wrote: > > > >> On Thu, 14 Apr 2016 16:42:33 -0600 > >> 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. > >>> > >>> Warner > >> Hi. > >> Thanks for you work. > >> But i have problem with VirtualBox if i use the kernel with option > >> CAM_NETFLIX_IOSCHED > >> http://imgur.com/JpcfW1h > > This problem is not over. > > After the update on other hardware from r296979 to r298512 (!!! without > > option CAM_NETFLIX_IOSCHED !!!) due to errors in recording the virtual > > machine to a virtual disk I lost completely virtual machine with > > permanent damage to the integrity of the file system in the inside of > > the virtual machine. > > > > This is a serious bug! > > > > Who cares not to fall into the same situation - is testing yourself > > and needed more testers. > > Because there is a suspicion that the problem is also relevant for > > bhyve VM. > > With me on this no more neither the strength nor the desire nor > > time. > > > > 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" > > Dears. > > I have updated my FreeBSD 11 guest on Virtualbox to rev 298522 > > FreeBSD nostromo 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r298522: Sun Apr > 24 07:25:34 BRT 2016 ota@nostromo:/usr/obj/usr/src/sys/NOSTROMO amd64 > > The virtualbox is 5.0.18 r10667 running on Windows 10. The FreeBSD guest > is running virtualbox additions > > virtualbox-ose-additions-4.3.38 VirtualBox additions for FreeBSD guests > > I'm using this machine to build FreeBSD images to Beaglebone Black using > crouchet and cross compile packages using poudriere. I have finished a > full build of FreeBSD 11 r298522 to Beaglebone and actually I'm > upgrading my poudriere jail to 298522. Until now all runs fine. This is > my conf of kernels: > > [ota@nostromo /usr/src/sys]$ diff amd64/conf/GENERIC amd64/conf/NOSTROMO > 85,92c85,92 > < options DDB# Support DDB. > < options GDB# Support remote GDB. > < options DEADLKRES# Enable the deadlock resolver > < options INVARIANTS# Enable calls of extra sanity checking > < options INVARIANT_SUPPORT# Extra sanity checks of internal > structures, required by INVARIANTS > < options WITNESS# Enable checks to detect deadlocks and > cycles > < options WITNESS_SKIPSPIN# Don't run witness on spinlocks for > speed > < options MALLOC_DEBUG_MAXZONES=8# Separate malloc(9) zones > --- > > #options DDB# Support DDB. > > #options GDB# Support remote GDB. > > #options DEADLKRES# Enable the deadlock resolver > > #options INVARIANTS# Enable calls of extra sanity checking > > #options INVARIANT_SUPPORT# Extra sanity checks of internal > structures, required by INVARIANTS > > #options WITNESS# Enable checks to detect deadlocks > and cycles > > #options WITNESS_SKIPSPIN# Don't run witness on spinlocks for > speed > > #options MALLOC_DEBUG_MAXZONES=8# Separate malloc(9) zones > [ota@nostromo /usr/src/sys]$ diff arm/conf/BEAGLEBONE > arm/conf/BEAGLEBONE-DEBUG > 153a154,156 > > > > #optionsIEEE80211_AMPDU_AGE# Add a A-MPDU RX aging > > #options IEEE80211_DEBUG > > > Until now both machines are running without problems and with full > stress. The Beaglebone is compiling kernel and the amd64 have compiled > freebsd to beaglebone. If exists some tests that I can made to help > please let me know. > > []'s > -Otacílio > The machines are using UFS > ___ 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
Em 24/04/2016 14:49, Ivan Klymenko escreveu: On Fri, 15 Apr 2016 11:44:43 +0300 Ivan Klymenko wrote: On Thu, 14 Apr 2016 16:42:33 -0600 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. Warner Hi. Thanks for you work. But i have problem with VirtualBox if i use the kernel with option CAM_NETFLIX_IOSCHED http://imgur.com/JpcfW1h This problem is not over. After the update on other hardware from r296979 to r298512 (!!! without option CAM_NETFLIX_IOSCHED !!!) due to errors in recording the virtual machine to a virtual disk I lost completely virtual machine with permanent damage to the integrity of the file system in the inside of the virtual machine. This is a serious bug! Who cares not to fall into the same situation - is testing yourself and needed more testers. Because there is a suspicion that the problem is also relevant for bhyve VM. With me on this no more neither the strength nor the desire nor time. 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" Dears. I have updated my FreeBSD 11 guest on Virtualbox to rev 298522 FreeBSD nostromo 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r298522: Sun Apr 24 07:25:34 BRT 2016 ota@nostromo:/usr/obj/usr/src/sys/NOSTROMO amd64 The virtualbox is 5.0.18 r10667 running on Windows 10. The FreeBSD guest is running virtualbox additions virtualbox-ose-additions-4.3.38 VirtualBox additions for FreeBSD guests I'm using this machine to build FreeBSD images to Beaglebone Black using crouchet and cross compile packages using poudriere. I have finished a full build of FreeBSD 11 r298522 to Beaglebone and actually I'm upgrading my poudriere jail to 298522. Until now all runs fine. This is my conf of kernels: [ota@nostromo /usr/src/sys]$ diff amd64/conf/GENERIC amd64/conf/NOSTROMO 85,92c85,92 < options DDB# Support DDB. < options GDB# Support remote GDB. < options DEADLKRES# Enable the deadlock resolver < options INVARIANTS# Enable calls of extra sanity checking < options INVARIANT_SUPPORT# Extra sanity checks of internal structures, required by INVARIANTS < options WITNESS# Enable checks to detect deadlocks and cycles < options WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed < options MALLOC_DEBUG_MAXZONES=8# Separate malloc(9) zones --- > #options DDB# Support DDB. > #options GDB# Support remote GDB. > #options DEADLKRES# Enable the deadlock resolver > #options INVARIANTS# Enable calls of extra sanity checking > #options INVARIANT_SUPPORT# Extra sanity checks of internal structures, required by INVARIANTS > #options WITNESS# Enable checks to detect deadlocks and cycles > #options WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed > #options MALLOC_DEBUG_MAXZONES=8# Separate malloc(9) zones [ota@nostromo /usr/src/sys]$ diff arm/conf/BEAGLEBONE arm/conf/BEAGLEBONE-DEBUG 153a154,156 > > #optionsIEEE80211_AMPDU_AGE# Add a A-MPDU RX aging > #options IEEE80211_DEBUG Until now both machines are running without problems and with full stress. The Beaglebone is compiling kernel and the amd64 have compiled freebsd to beaglebone. If exists some tests that I can made to help please let me know. []'s -Otacílio ___ 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"
Fail to download mysql57-server from port
Hi members. I try to install MySQL server 5.7 on FreeBSD 10.3 and found a lot of error during download package as following. Could you please suggest me how to solve this problem? PS. I already fetch and extract new port. root@rd00:/usr/ports/databases/mysql57-server # less distinfo SHA256 (mysql-5.7.10.tar.gz) = 1ea1644884d086a23eafd8ccb04d517fbd43da3a6a06036f23c5c3a111e25c74 SIZE (mysql-5.7.10.tar.gz) = 48919371 SHA256 (boost_1_59_0.tar.gz) = 47f11c8844e579d02691a607fbd32540104a9ac7a2534a8ddaef50daf502baac SIZE (boost_1_59_0.tar.gz) = 83709983 root@rd00:/usr/ports/databases/mysql57-server # root@rd00:/usr/ports/databases/mysql57-server # make install clean ===> License GPLv2 accepted by the user ===> Found saved configuration for mysql57-server-5.7.10_4 ===> mysql57-server-5.7.10_4 depends on file: /usr/local/sbin/pkg - found => mysql-5.7.10.tar.gz doesn't seem to exist in /usr/ports/distfiles/. => Attempting to fetch ftp://ftp.fi.muni.cz/pub/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: ftp://ftp.fi.muni.cz/pub/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: No route to host => Attempting to fetch http://mysql.mirrors.cybercity.dk/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: http://mysql.mirrors.cybercity.dk/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: Connection reset by peer => Attempting to fetch ftp://ftp.fh-wolfenbuettel.de/pub/database/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: ftp://ftp.fh-wolfenbuettel.de/pub/database/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: Operation timed out => Attempting to fetch ftp://ftp.gwdg.de/pub/misc/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: ftp://ftp.gwdg.de/pub/misc/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: No route to host => Attempting to fetch http://netmirror.org/mirror/mysql.com/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: http://netmirror.org/mirror/mysql.com/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: Not Found => Attempting to fetch ftp://netmirror.org/mysql.com/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: ftp://netmirror.org/mysql.com/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: Operation timed out => Attempting to fetch http://mirrors.ntua.gr/MySQL/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: http://mirrors.ntua.gr/MySQL/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: Not Found => Attempting to fetch ftp://ftp.ntua.gr/pub/databases/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: ftp://ftp.ntua.gr/pub/databases/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: No route to host => Attempting to fetch http://mysql.sote.hu/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: http://mysql.sote.hu/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: No address record => Attempting to fetch ftp://ftp.rhnet.is/pub/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: ftp://ftp.rhnet.is/pub/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: Operation timed out => Attempting to fetch ftp://mirror.widexs.nl/pub/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: ftp://mirror.widexs.nl/pub/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: Operation timed out => Attempting to fetch ftp://mirror.switch.ch/mirror/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: ftp://mirror.switch.ch/mirror/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: No route to host => Attempting to fetch http://mysql.dp.ua/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: http://mysql.dp.ua/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: No address record => Attempting to fetch http://mysql.mirrored.ca/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: http://mysql.mirrored.ca/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: size mismatch: expected 48919371, actual 51 => Attempting to fetch ftp://mirror.services.wisc.edu/mirrors/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: ftp://mirror.services.wisc.edu/mirrors/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: No address record => Attempting to fetch http://mysql.mirrors.pair.com/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: http://mysql.mirrors.pair.com/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: Not Found => Attempting to fetch ftp://ftp.linorg.usp.br/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: ftp://ftp.linorg.usp.br/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: No address record => Attempting to fetch ftp://ftp.cbn.net.id/mirror/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: ftp://ftp.cbn.net.id/mirror/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: Operation timed out => Attempting to fetch ftp://ftp.easynet.be/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: ftp://ftp.easynet.be/mysql/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: No route to host => Attempting to fetch http://download.softagency.net/MySQL/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz fetch: http://download.softagency.net/MySQL/Downloads/MySQL-5.7/mysql-5.7.10.tar.gz: Forbidden => Attempting to fetch http://distcache.FreeBSD.org/ports-distfiles/mysql-5.7.10.tar.gz mysql-5.7.10.tar.gz 1% of 46 MB 43 kBps 19m23s BR, Teerapatr K. __
Re: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))
On Sun, Apr 24, 2016 at 12:14 PM, Daniel Eischen wrote: > On Sun, 24 Apr 2016, Warner Losh wrote: > > On Sun, Apr 24, 2016 at 6:34 AM, Daniel Eischen >> wrote: >> >> On Sat, 23 Apr 2016, Warner Losh wrote: >>> >>> On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen >>> wrote: [CC trimmed] > > On Fri, 22 Apr 2016, Warner Losh wrote: > > > I personally will be refraining from engaging further. I plan on seeing >> what gaps there are by adding support to NanoBSD for packages. I'll be >> busy >> with that. In talking to Glen and others, we've already identified a >> few >> easy gaps to fill. Once they've done that, I'll get going on NanoBSD >> with >> the goal to be able to use it to build a bootable system of any >> architecture from packages with no root privs. I expect to find >> issues, >> but >> I don't expect to find any issue that's intractable. I expect after >> the >> issues are resolved, the end product will be better for everybody. >> >> >> Thank you for working on NanoBSD. Do you think it would be possible > to add support for optionally building dump(8) images instead of dd? > > What do you mean by that, exactly? It would be relatively easy to add a step that runs dump on the _.disk.image file and squirrel that away. Last orders the code currently calls it, I believe. Is it something as simple as this, or is there some more complexity that I'm failing to understand or grasp? >>> Perhaps I'm missing something, but when last_orders() is called, >>> isn't the disk already unmounted and 'mdconfig -d -u' already >>> run? >>> >> >> >> dump 0f - _.disk.image > ~/foo.dump >> >> worked for me just now. Is there some reason that it wouldn't work for >> you in last orders if you tossed a NANO_DISKIMGDIR in front of it >> and last orders would work for you. You could even pipe it into some >> compression program... >> > > Huh, I didn't know you could do that on the image file. > I feel dumb, now ;-) Don't feel too dumb. If I specify foo.dump as the filename, dump kinda loses its mind when it gets to the end of file. Not sure why. Warner ___ 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
I'll try virtualbox again, but it booted fine when I tried it before. I'll give bhyve a sping. I haven't tried it in quite some time, but it worked about 9 months ago. But since I don't even know what the errors you are seeing are, I can't tell you that it is similar to some other error reports or something completely new. Warner On Sun, Apr 24, 2016 at 11:49 AM, Ivan Klymenko wrote: > On Fri, 15 Apr 2016 11:44:43 +0300 > Ivan Klymenko wrote: > > > On Thu, 14 Apr 2016 16:42:33 -0600 > > 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. > > > > > > Warner > > > > Hi. > > Thanks for you work. > > But i have problem with VirtualBox if i use the kernel with option > > CAM_NETFLIX_IOSCHED > > http://imgur.com/JpcfW1h > > This problem is not over. > After the update on other hardware from r296979 to r298512 (!!! without > option CAM_NETFLIX_IOSCHED !!!) due to errors in recording the virtual > machine to a virtual disk I lost completely virtual machine with > permanent damage to the integrity of the file system in the inside of > the virtual machine. > > This is a serious bug! > > Who cares not to fall into the same situation - is testing yourself > and needed more testers. > Because there is a suspicion that the problem is also relevant for > bhyve VM. > With me on this no more neither the strength nor the desire nor > time. > > 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"
ixv device_attach: ixv0 attach returned 5 (was sr-iov issues, reset_hw() failed with error -100)
The sr-iov vf driver is failing to attach.
# pciconf -lv: (filtered to only relevant output)
ix0@pci0:129:0:0: class=0x02 card=0x1458 chip=0x15288086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Controller 10-Gigabit X540-AT2'
class = network
subclass = ethernet
ix1@pci0:129:0:1: class=0x02 card=0x1458 chip=0x15288086 rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = 'Ethernet Controller 10-Gigabit X540-AT2'
class = network
subclass = ethernet
none155@pci0:129:0:129: class=0x02 card=0x1458 chip=0x15158086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'X540 Ethernet Controller Virtual Function'
class = network
subclass = ethernet
none156@pci0:129:0:131: class=0x02 card=0x1458 chip=0x15158086
rev=0x01 hdr=0x00
vendor = 'Intel Corporation'
device = 'X540 Ethernet Controller Virtual Function'
class = network
subclass = ethernet
# devctl attach pci0:129:0:129
devctl: Failed to attach pci0:129:0:129: Input/output error
# dmesg
ixv0: at device 0.129 numa-domain 1 on pci12
ixv0: Using MSIX interrupts with 2 vectors
ixv0: ixgbe_reset_hw() failed with error -100
device_attach: ixv0 attach returned 5
# cat /etc/iovctl.conf
PF {
device : ix1;
num_vfs : 31;
}
DEFAULT {
passthrough : true;
}
VF-0 {
passthrough : false;
}
VF-1 {
passthrough : false;
}
Any ideas?
Ultima
___
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 Mon, Apr 25, 2016 at 10:40:24AM +0800, Alastair Hogge wrote: > Will /usr/src/release/release.sh eventually support building base packages > as an option? Yes. Glen signature.asc Description: PGP signature
Re: [CFT] packaging the base system with pkg(8)
Dear FreeBSD community, Thanks so much for this awesome effort. Will /usr/src/release/release.sh eventually support building base packages as an option? If possible, is it something that we could see soon? Ta, Alastair -- Why isn't there a special name for the tops of your feet? -- Lily Tomlin ___ 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: New rc.d scripts on current
On Sun, Apr 24, 2016 at 08:33:11AM -0700, Manfred Antar wrote:
> Updated /etc yesterday via mergemaster.
> Now I’m getting this on reboot. Everything seems to be working alright.
>
> eval: disk: not found
> eval: disk: not found
> eval: ${GELI ...}: Bad substitutio
> FreeBSD/amd64 (pozo.com) (ttyu0)
>
> login:
>
> Not sure if it is error or new feature.
>
> Manfred
It was my fault. the geli2 rc script had the description text in the
"name" variable.
pgpnoNGomKfo8.pgp
Description: PGP signature
Re: extremely slow to get to loader
Hi, I'm expecting the same behaviour after updating to r298524. It hangs for 5-10 minutes at "BTX loader" screen and after that loads successfully. While hanging, according to HDD LED on my laptop, it actively doing disk I/O operations, and all of this looks pretty scary. I'm using standard not-encrypted ZFS-on-root installation, if that matter. -- Regards, Ruslan T.O.S. Of Reality ___ 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: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))
On Sun, 24 Apr 2016, Warner Losh wrote: On Sun, Apr 24, 2016 at 6:34 AM, Daniel Eischen wrote: On Sat, 23 Apr 2016, Warner Losh wrote: On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen wrote: [CC trimmed] On Fri, 22 Apr 2016, Warner Losh wrote: I personally will be refraining from engaging further. I plan on seeing what gaps there are by adding support to NanoBSD for packages. I'll be busy with that. In talking to Glen and others, we've already identified a few easy gaps to fill. Once they've done that, I'll get going on NanoBSD with the goal to be able to use it to build a bootable system of any architecture from packages with no root privs. I expect to find issues, but I don't expect to find any issue that's intractable. I expect after the issues are resolved, the end product will be better for everybody. Thank you for working on NanoBSD. Do you think it would be possible to add support for optionally building dump(8) images instead of dd? What do you mean by that, exactly? It would be relatively easy to add a step that runs dump on the _.disk.image file and squirrel that away. Last orders the code currently calls it, I believe. Is it something as simple as this, or is there some more complexity that I'm failing to understand or grasp? Perhaps I'm missing something, but when last_orders() is called, isn't the disk already unmounted and 'mdconfig -d -u' already run? dump 0f - _.disk.image > ~/foo.dump worked for me just now. Is there some reason that it wouldn't work for you in last orders if you tossed a NANO_DISKIMGDIR in front of it and last orders would work for you. You could even pipe it into some compression program... Huh, I didn't know you could do that on the image file. I feel dumb, now ;-) -- DE ___ 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 Fri, 15 Apr 2016 11:44:43 +0300 Ivan Klymenko wrote: > On Thu, 14 Apr 2016 16:42:33 -0600 > 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. > > > > Warner > > Hi. > Thanks for you work. > But i have problem with VirtualBox if i use the kernel with option > CAM_NETFLIX_IOSCHED > http://imgur.com/JpcfW1h This problem is not over. After the update on other hardware from r296979 to r298512 (!!! without option CAM_NETFLIX_IOSCHED !!!) due to errors in recording the virtual machine to a virtual disk I lost completely virtual machine with permanent damage to the integrity of the file system in the inside of the virtual machine. This is a serious bug! Who cares not to fall into the same situation - is testing yourself and needed more testers. Because there is a suspicion that the problem is also relevant for bhyve VM. With me on this no more neither the strength nor the desire nor time. 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: extremely slow to get to loader
On 2016-04-21 20:56, Johannes Dieterich wrote: On Thu, Apr 21, 2016 at 12:16 PM, Allan Jude wrote: On 2016-04-21 10:46, Johannes Dieterich wrote: Dear all, with r298385, I observe extremely long times from turning on my laptop to reach loader. This is a regression compared to a roughly 1 week old CURRENT. This is an AMD A12-8800B laptop booting in legacy mode into a ZFS+GELI setup. Please let me know how I can help to solve this issue. Thanks, Johannes ___ 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" Can you describe where exactly it is slow? Yes, it hangs after "BIOS drive C: is disk 0" for a good 3 minutes before it eventually continues. Once you get to the loader menu (the beastie menu), can you choose the option to go to the loader prompt, and type: bcachestat And provide the output of that. Here we go (w/o mistakes I hope...): cache blocks: 32768 cache blocksz: 572 unit cache blocks: 32768 cached units: 1 1162 ops 0 bypasses 12109 hits 739 misses Thanks so much for the response! Johannes I'm seeing similar, PLUS the kernel seems(!) to not continue on to the RC scripts after mount root. (BIOS BOOT). I reverted to an older kernel and boot block and zfsloader to get up. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 ___ 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: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))
On Sun, Apr 24, 2016 at 6:34 AM, Daniel Eischen wrote: > On Sat, 23 Apr 2016, Warner Losh wrote: > > On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen >> wrote: >> >> [CC trimmed] >>> >>> On Fri, 22 Apr 2016, Warner Losh wrote: >>> >>> I personally will be refraining from engaging further. I plan on seeing what gaps there are by adding support to NanoBSD for packages. I'll be busy with that. In talking to Glen and others, we've already identified a few easy gaps to fill. Once they've done that, I'll get going on NanoBSD with the goal to be able to use it to build a bootable system of any architecture from packages with no root privs. I expect to find issues, but I don't expect to find any issue that's intractable. I expect after the issues are resolved, the end product will be better for everybody. >>> Thank you for working on NanoBSD. Do you think it would be possible >>> to add support for optionally building dump(8) images instead of dd? >>> >> >> >> What do you mean by that, exactly? It would be relatively easy to add >> a step that runs dump on the _.disk.image file and squirrel that away. >> Last orders the code currently calls it, I believe. Is it something as >> simple >> as this, or is there some more complexity that I'm failing to understand >> or grasp? >> > > Perhaps I'm missing something, but when last_orders() is called, > isn't the disk already unmounted and 'mdconfig -d -u' already > run? dump 0f - _.disk.image > ~/foo.dump worked for me just now. Is there some reason that it wouldn't work for you in last orders if you tossed a NANO_DISKIMGDIR in front of it and last orders would work for you. You could even pipe it into some compression program... Warner ___ 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: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))
> On Apr 24, 2016, at 05:34, Daniel Eischen wrote: > >> On Sat, 23 Apr 2016, Warner Losh wrote: >> >> On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen >> wrote: >> >>> [CC trimmed] >>> On Fri, 22 Apr 2016, Warner Losh wrote: I personally will be refraining from engaging further. I plan on seeing what gaps there are by adding support to NanoBSD for packages. I'll be busy with that. In talking to Glen and others, we've already identified a few easy gaps to fill. Once they've done that, I'll get going on NanoBSD with the goal to be able to use it to build a bootable system of any architecture from packages with no root privs. I expect to find issues, but I don't expect to find any issue that's intractable. I expect after the issues are resolved, the end product will be better for everybody. >>> >>> Thank you for working on NanoBSD. Do you think it would be possible >>> to add support for optionally building dump(8) images instead of dd? >> >> >> What do you mean by that, exactly? It would be relatively easy to add >> a step that runs dump on the _.disk.image file and squirrel that away. >> Last orders the code currently calls it, I believe. Is it something as >> simple >> as this, or is there some more complexity that I'm failing to understand >> or grasp? > > Perhaps I'm missing something, but when last_orders() is called, > isn't the disk already unmounted and 'mdconfig -d -u' already > run? Yup. > -- > DE > ___ > 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-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
New rc.d scripts on current
Updated /etc yesterday via mergemaster.
Now I’m getting this on reboot. Everything seems to be working alright.
eval: disk: not found
eval: disk: not found
eval: ${GELI ...}: Bad substitutio
FreeBSD/amd64 (pozo.com) (ttyu0)
login:
Not sure if it is error or new feature.
Manfred
___
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: NanoBSD (Was Re: [CFT] packaging the base system with pkg(8))
On Sat, 23 Apr 2016, Warner Losh wrote: On Sat, Apr 23, 2016 at 7:51 AM, Daniel Eischen wrote: [CC trimmed] On Fri, 22 Apr 2016, Warner Losh wrote: I personally will be refraining from engaging further. I plan on seeing what gaps there are by adding support to NanoBSD for packages. I'll be busy with that. In talking to Glen and others, we've already identified a few easy gaps to fill. Once they've done that, I'll get going on NanoBSD with the goal to be able to use it to build a bootable system of any architecture from packages with no root privs. I expect to find issues, but I don't expect to find any issue that's intractable. I expect after the issues are resolved, the end product will be better for everybody. Thank you for working on NanoBSD. Do you think it would be possible to add support for optionally building dump(8) images instead of dd? What do you mean by that, exactly? It would be relatively easy to add a step that runs dump on the _.disk.image file and squirrel that away. Last orders the code currently calls it, I believe. Is it something as simple as this, or is there some more complexity that I'm failing to understand or grasp? Perhaps I'm missing something, but when last_orders() is called, isn't the disk already unmounted and 'mdconfig -d -u' already run? -- DE ___ 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"
