Re: adding existing ipv6 network route returns ENOMEM instead of EEXIST if loopback route also exists
21.11.2020, 22:48, "Guy Yur" : > Hi, > > When adding a route with a netmask, add_route() in route_ctl.c > adds the route with destination address masked. > If the add failed (for example, the route exists) it calls > lookup_prefix() with the original unmasked destination. Thank you for the report! Indeed, there is a problem w.r.t non-masked dst handling. I'll look into that in the end of this week. > > In a scenario where a loopback route was added followed > by the network route being added, if the network route > is added again and the network route destination is the > same as the loopback route, lookup_prefix() will match on > the loopback route, not finding the network route and > add_route() will return ENOMEM instead of EEXIST. > Adding the route with just the network part returns EEXIST as expected. > > Example: > # route -6 add -host fd53:: -prefixlen 128 ::1 > # route -6 add -net fd53:: -prefixlen 64 ::1 > # route -6 add -net fd53:: -prefixlen 64 ::1 > route: writing to routing socket: Cannot allocate memory > add net fd53::: gateway ::1 fib 0: Cannot allocate memory > # route -6 add -net fd53:: -prefixlen 64 ::1 > add net fd53::: gateway ::1 fib 0: route already in table > > I was testing https://reviews.freebsd.org/D15406 > changes applied to r367863. > The changes call rtinit to add prefix route when > interface address is added/updated and uses the > interface address as the destination. > rtinit returned ENOMEM instead of EEXIST > causing dhcpcd to printCannot allocate memory. > > route commands above showing the problem were run > in r367863 without D15406 changesas well. > > Thanks, > Guy Yur > > ___ > 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"
Re: git tools for building in base?
Hi, On Tue, Nov 24, 2020 at 09:59:15PM -0700, Warner Losh wrote: On Tue, Nov 24, 2020 at 2:19 PM tech-lists wrote: As subject - what will there be in base to interact with the new git repo? I mean, right now, for svn there is svnlite. What for git? 'pkg add git' is your choice now. Shouldn't it be in base before the move to git? We will have got (from OpenBSD: Game Of Trees) in the future. It isn't quite there yet, however, so it's not in base. Do you agree that this situation is a bad look for an *operating system* ? Having to depend on a third-party tool to stay up-to-date and secure. In multiple locations it is said that installing a port is *at your own risk*. Personally, I'd like the official updating tool to have had the same level of analysis (and so the same level of "risk") on it as the base OS, (and also be under the same licence). I mean, shouldn't all the basic tools be present in an OS, at least in order to update it? And *then* migrate to the update method? When we migrated from CVS to Subversion, we didn't grow svnlite in the base for many months after the conversion. A mistake then and a mistake now with svn to git IMO. -- J. signature.asc Description: PGP signature
Re: git tools for building in base?
On Tue, Nov 24, 2020 at 09:59:15PM -0700, Warner Losh wrote: > On Tue, Nov 24, 2020 at 2:19 PM tech-lists wrote: > > > As subject - what will there be in base to interact with the new git repo? > > I mean, right now, for svn there is svnlite. What for git? > > > > 'pkg add git' is your choice now. pkg install not pkg add > > > > Shouldn't it be in base before the move to git? > > > > We will have got (from OpenBSD: Game Of Trees) in the future. It isn't > quite there yet, however, so it's not in base. When we migrated from CVS to > Subversion, we didn't grow svnlite in the base for many months after the > conversion. We hope to have it finished in time for 13.0. > > 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" signature.asc Description: PGP signature
Re: git tools for building in base?
On Wed, Nov 25, 2020 at 04:00:50PM +0100, Baptiste Daroussin wrote: > On Tue, Nov 24, 2020 at 09:59:15PM -0700, Warner Losh wrote: > > On Tue, Nov 24, 2020 at 2:19 PM tech-lists wrote: > > > > > As subject - what will there be in base to interact with the new git repo? > > > I mean, right now, for svn there is svnlite. What for git? > > > > > > > 'pkg add git' is your choice now. > > pkg install not pkg add There's also fetch for a one-time download of the ports tree (bootstrapping ports, for example). A HardenedBSD user would do this: fetch -o ports.tar.gz \ https://git-01.md.hardenedbsd.org/HardenedBSD/hardenedbsd-ports/archive/master.tar.gz mkdir -p /usr/ports tar -xf ports.tar.gz --strip-components 1 -C /usr/ports Something similar could be done in FreeBSDlandia. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: git tools for building in base?
On Tue, Nov 24, 2020 at 09:59:15PM -0700, Warner Losh wrote: > We hope to have it finished in time for 13.0. I also feel that it should be more a "requirement". I don't see the rush in getting 13.0 out the door. There is a lot to get working (especially in ports-land). mcl ___ 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: git tools for building in base?
On 2020-11-25, Warner Losh wrote: >> Shouldn't it be in base before the move to git? > > We will have got (from OpenBSD: Game Of Trees) in the future. It isn't > quite there yet, however, so it's not in base. Since got can't fetch from http(s) yet, there was talk of setting up anon-ssh access. What became of that? devel/got, for those who want to play. -- Christian "naddy" Weisgerber na...@mips.inka.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"
zpool export: umount failed, device inexplicably busy (lsof found nothing)
On 11/10/2020 11:21, Graham Perrin wrote: On 06/10/2020 21:29, Graham Perrin wrote: lsof finds no open file. How else might I tell why the device is busy? Mobile hard disk drive, USB. The same problem this morning, root@momh167-gjp4-8570p:~ # zpool export Transcend cannot unmount '/Volumes/t500': umount failed root@momh167-gjp4-8570p:~ # lsof /Volumes/t500/ lsof: WARNING: device cache mismatch: /dev/usb/0.5.2 lsof: WARNING: /root/.lsof_momh167-gjp4-8570p was updated. root@momh167-gjp4-8570p:~ # lsof /Volumes/t500/ root@momh167-gjp4-8570p:~ # usbconfig -d 0.5 dump_all_desc ugen0.5: at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) bLength = 0x0012 bDescriptorType = 0x0001 bcdUSB = 0x0300 bDeviceClass = 0x0009 bDeviceSubClass = 0x bDeviceProtocol = 0x0003 bMaxPacketSize0 = 0x0009 idVendor = 0x0424 idProduct = 0x5434 bcdDevice = 0x3082 iManufacturer = 0x0002 iProduct = 0x0003 iSerialNumber = 0x0001 <1239567> bNumConfigurations = 0x0001 Configuration index 0 bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x001f bNumInterfaces = 0x0001 bConfigurationValue = 0x0001 iConfiguration = 0x bmAttributes = 0x00e0 bMaxPower = 0x Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x bAlternateSetting = 0x bNumEndpoints = 0x0001 bInterfaceClass = 0x0009 bInterfaceSubClass = 0x bInterfaceProtocol = 0x iInterface = 0x Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 bmAttributes = 0x0013 wMaxPacketSize = 0x0002 bInterval = 0x0008 bRefresh = 0x bSynchAddress = 0x Additional Descriptor bLength = 0x06 bDescriptorType = 0x30 bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x06, 0x30, 0x00, 0x00, 0x02, 0x00 root@momh167-gjp4-8570p:~ # zpool export Transcend cannot unmount '/Volumes/t500': umount failed root@momh167-gjp4-8570p:~ # umount /Volumes/t500 umount: unmount of /Volumes/t500 failed: Device busy root@momh167-gjp4-8570p:~ # lsof /Volumes/t500/ root@momh167-gjp4-8570p:~ # When this last occurred, I could export the pool after signing out from KDE. The problem seemed to be consistently reproducible but (fingers crossed) no problem yesterday or today. Previously: most often using OpenZFS in base. Now using OpenZFS from ports, with r367936. If the problem recurs: is it _ever_ sane to get nothing listed by lsof for a volume that can not be unmounted? ___ 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: git tools for building in base?
On Wed, Nov 25, 2020 at 6:16 AM tech-lists wrote: > Hi, > > On Tue, Nov 24, 2020 at 09:59:15PM -0700, Warner Losh wrote: > >On Tue, Nov 24, 2020 at 2:19 PM tech-lists wrote: > > > >> As subject - what will there be in base to interact with the new git > repo? > >> I mean, right now, for svn there is svnlite. What for git? > >> > >'pkg add git' is your choice now. > > > >> Shouldn't it be in base before the move to git? > > > >We will have got (from OpenBSD: Game Of Trees) in the future. It isn't > >quite there yet, however, so it's not in base. > > Do you agree that this situation is a bad look for an *operating system* ? > Having to depend on a third-party tool to stay up-to-date and secure. > In the long term, perhaps. During a short-term transition, it seems acceptable. > In multiple locations it is said that installing a port is *at your own > risk*. Personally, I'd like the official updating tool to have had the > same level of analysis (and so the same level of "risk") on it as the base > OS, > (and also be under the same licence). > You can establish your own chain of trust to the sources, you can start here https://mirrors.edge.kernel.org/pub/software/scm/git/ if building from ports or installing a package is deemed to be too insecure. > I mean, shouldn't all the basic tools be present in an OS, at least in > order to update it? And *then* migrate to the update method? > git is a perfectly fine tool. Moving to git has a number of advantages to the project, so we must weigh the many different factors in doing that and not let a single item gate the entire process if that single item doesn't add enough value. -current is for bleeding edge users, and the cost / benefit analysis is skewed heavily towards the convenience of the developers when a choice needs to be made. In this case, the choice was made to progress with the cutover of the repo while allowing the natural development of got to proceed in parallel. One way to help this situation would be to contribute code to OpenBSD's got to help it mature to the point we can include it in the base system. There's logistical issues as well: today got only clones via ssh, and the typical distribution of git is via the git or https protocols (though developers often push commits via ssh). To overcome these limitations, we'd have to stand up additional infrastructure to allow for anonymous ssh into mirrors. This is in the planning stages, but is taking a back seat at the moment to getting the basic infrastructure up and running. > >When we migrated from CVS to Subversion, we didn't grow svnlite in > >the base for many months after the conversion. > > A mistake then and a mistake now with svn to git IMO. It wasn't considered a mistake at the time, nor do I consider this a mistake now. At the time Peter Wemm did the cutover, moving to a SCM that had atomic commits was considered a higher priority than necessarily needing svn in the base system. So our adaptation of svn back in the day proceeded in parallel with a repackaging of svn to allow a minimal version to be included with the base system. 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: git tools for building in base?
On Wed, Nov 25, 2020 at 9:25 AM Christian Weisgerber wrote: > On 2020-11-25, Warner Losh wrote: > > >> Shouldn't it be in base before the move to git? > > > > We will have got (from OpenBSD: Game Of Trees) in the future. It isn't > > quite there yet, however, so it's not in base. > > Since got can't fetch from http(s) yet, there was talk of setting > up anon-ssh access. What became of that? > It's on the list, but at a lower priority than getting the basics in place. > devel/got, for those who want to play. > Yes. You can also play with the github FreeBSD mirror via ssh, but you have to create an account. 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: git tools for building in base?
On Wed, Nov 25, 2020 at 8:09 AM Mark Linimon wrote: > On Tue, Nov 24, 2020 at 09:59:15PM -0700, Warner Losh wrote: > > We hope to have it finished in time for 13.0. > > I also feel that it should be more a "requirement". > > I don't see the rush in getting 13.0 out the door. There is a lot to > get working (especially in ports-land). > Without someone dedicated to make it happen, it can't be more than a 'hope to have it finished' item. 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"
possible usb3-connected hard drive spin down causing lag
Hi, I have a usb3-connected harddrive. dmesg shows this: [...] da0: Fixed Direct Access SPC-4 SCSI device [...] running current-r367806-arm64 I think it might be auto-spinning-down or auto-sleeping. It's making initial interaction lag of 2-3 seconds. Is there a sysctl or something somewhere where I can tell it to never sleep? Or is that something I'd need to contact the manufacturer about? Or is there an alternative strategy like tmpfs. It's not a "green" drive but I guess it might be "green" in that it's usb3 powered. I have vfs.read_max=128 in /etc/sysctl.conf zdb has ashift=12 In case it's relevant, the filesystem on the disk is zfs. Once "woken up", inferaction is quick, as expected. thanks, -- J. signature.asc Description: PGP signature
