Re: umb0 broke in 6.9
On 2021/06/14 16:15, Paul B. Henson wrote:
> On Mon, Jun 14, 2021 at 08:07:15AM -, Stuart Henderson wrote:
>
> > just add "#define UMB_DEBUG" to if_umb.c and send the full dmesg output.
>
> Hmm, that's didn't work, I also needed to update umb_debug = 1 in the
> code? After that, I got a little output, full dmesg included below but
> the umb part looks like:
ah yes, thanks.
> umb0 at uhub0 port 3 configuration 1 interface 12 "Sierra Wireless,
> Incorporated Sierra Wireless MC7455 Qualcomm\M-. Snapdragon? X7 LTE-A"
> rev 2.10/0.06 addr 2
> umb0: NCM align=4 div=4 rem=0
> umb0: Only NTB16 format supported.
> umb0: -> snd MBIM_OPEN_MSG (tid 1)
> umb0: vers 1.0
> umb0: stop: reached state DOWN
> umb0: init: opening ...
> umb0: -> snd MBIM_OPEN_MSG (tid 2)
> umb0: init: opening ...
> umb0: -> snd MBIM_OPEN_MSG (tid 3)
> umb0: stop: reached state DOWN
>
> This seems kind of like the original problem I had with the card when it
> was attached to the internal USB2 minipci slot rather than to the
> external USB3 one:
>
> http://openbsd-archive.7691.n7.nabble.com/umb-device-SIM-has-no-PIN-td331358.html
ah, I was wondering if I'd broken something with the fcc auth change when
it moved to a combined quirks table (which is why I wanted that debug),
but reading that mail reminded me that EM7455 wasn't quite the same as
MC7455.. there were a few other changes in umb but looking at the
debug messages I don't think your device is using those.
> Maybe a change in the USB code broke it?
it's possible, there were changes to other parts of USB that did cause
problems for some umb devices, though the ones that were reported at the
time were fixed.
at this point if I had the device I'd probably try bisecting to try and
find when the problem started .. with 6.9 userland you can probably get
away with just booting the relevant older kernel for a test for probably
most/maybe all of the way back to 6.8. ftp.hostserver.de/archive has
daily amd64 snaps going back 3 months, which takes you before the umb
changes, but probably after some of the other usb stack changes. if it's
still failing with the earliest of those let me know and I can dig out
some older ones, or do a date-based checkout ("cvs up -D 2021/01/01"
etc) and try some builds yourself.
>
> OpenBSD 6.9-stable (GENERIC.MP) #12: Mon Jun 14 15:54:43 PDT 2021
> r...@obsd-bld.pbhware.com:/sys/arch/amd64/compile/GENERIC.MP
> real mem = 4261011456 (4063MB)
> avail mem = 4116484096 (3925MB)
> User Kernel Config
> UKC> disable Humsm
> 361 umsm* disabled
> UKC> quit
> Continuing...
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcff9f020 (7 entries)
> bios0: vendor coreboot version "v4.6.3" date 20171030
> bios0: PC Engines PC Engines apu3
> acpi0 at bios0: ACPI 4.0
> acpi0: sleep states S0 S1 S2 S4 S5
> acpi0: tables DSDT FACP SSDT TCPA APIC HEST SSDT SSDT HPET
> acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4)
> UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4)
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: AMD GX-412TC SOC, 998.40 MHz, 16-30-01
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
> cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line
> 16-way L2 cache
> cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 99MHz
> cpu0: mwait min=64, max=64, IBE
> cpu1 at mainbus0: apid 1 (application processor)
> cpu1: AMD GX-412TC SOC, 998.13 MHz, 16-30-01
> cpu1:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT
> cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line
> 16-way L2 cache
> cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative
> cpu1: smt 0, core 1, package 0
> cpu2 at mainbus0: apid 2 (application processor)
> cpu2: AMD GX-412TC SOC, 998.13 MHz, 16-30-01
> cpu2:
>
Re: umb0 broke in 6.9
On Mon, Jun 14, 2021 at 08:07:15AM -, Stuart Henderson wrote: > just add "#define UMB_DEBUG" to if_umb.c and send the full dmesg output. Hmm, that's didn't work, I also needed to update umb_debug = 1 in the code? After that, I got a little output, full dmesg included below but the umb part looks like: umb0 at uhub0 port 3 configuration 1 interface 12 "Sierra Wireless, Incorporated Sierra Wireless MC7455 Qualcomm\M-. Snapdragon? X7 LTE-A" rev 2.10/0.06 addr 2 umb0: NCM align=4 div=4 rem=0 umb0: Only NTB16 format supported. umb0: -> snd MBIM_OPEN_MSG (tid 1) umb0: vers 1.0 umb0: stop: reached state DOWN umb0: init: opening ... umb0: -> snd MBIM_OPEN_MSG (tid 2) umb0: init: opening ... umb0: -> snd MBIM_OPEN_MSG (tid 3) umb0: stop: reached state DOWN This seems kind of like the original problem I had with the card when it was attached to the internal USB2 minipci slot rather than to the external USB3 one: http://openbsd-archive.7691.n7.nabble.com/umb-device-SIM-has-no-PIN-td331358.html Maybe a change in the USB code broke it? OpenBSD 6.9-stable (GENERIC.MP) #12: Mon Jun 14 15:54:43 PDT 2021 r...@obsd-bld.pbhware.com:/sys/arch/amd64/compile/GENERIC.MP real mem = 4261011456 (4063MB) avail mem = 4116484096 (3925MB) User Kernel Config UKC> disable Humsm 361 umsm* disabled UKC> quit Continuing... random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcff9f020 (7 entries) bios0: vendor coreboot version "v4.6.3" date 20171030 bios0: PC Engines PC Engines apu3 acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S1 S2 S4 S5 acpi0: tables DSDT FACP SSDT TCPA APIC HEST SSDT SSDT HPET acpi0: wakeup devices PWRB(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.40 MHz, 16-30-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD GX-412TC SOC, 998.13 MHz, 16-30-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu1: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: AMD GX-412TC SOC, 998.13 MHz, 16-30-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu2: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu2: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu2: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu2: disabling user TSC (skew=-144) cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: AMD GX-412TC SOC, 998.13 MHz, 16-30-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu3: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu3: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu3: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 4 pa 0xfec0, version 21, 24 pins ioapic1 at mainbus0: apid 5 pa
6.9 kernel compile fails
I'm trying to compile a kernel with some debugging enabled for an problem I've having with umb, and now my problem has turning into an error compiling the kernel :). After getting the error on my updated from 6.8 code base, I whacked it and did a fresh checkout, but it still shows up: -bash-5.1$ pwd /sys/arch/amd64/compile/GENERIC.MP -bash-5.1$ make make: don't know how to make /usr/src/sys/dev/pci/drm/i915/dvo_ch7017.c (prerequisite of: dvo_ch7017.o) Stop in /sys/arch/amd64/compile/GENERIC.MP It looks like that file is at: /usr/src/sys/dev/pci/drm/i915/display/dvo_ch7017.c not where it's looking: /usr/src/sys/dev/pci/drm/i915/dvo_ch7017.c I created a symlink and then it complained about a missing header file, so I made another symlink, and it complained about another C file, etc etc, until I finally just ran: ln -s display/* . A whole bunch of stuff compiled, then it complained about: make: don't know how to make /usr/src/sys/dev/pci/drm/i915/i915_gem_clflush.c (prerequisite of: i915_gem_clflush.o) so queue: ln -s gem/* . ln -s gt/* . ln -s uc/* . and it trundled along for a while, then: make: don't know how to make /usr/src/sys/dev/isa/asmc.c (prerequisite of: asmc.o) Finally, after: ln -s ../acpi/asmc.c . it finished compiling and the resultant kernel seems to work. It seems odd the stable kernel source would be broken, but I'm not sure what I might have done wrong? It's a fresh checkout, and there's not much to compiling it. The box doing to compiling was updated from 6.8, I haven't tried on a box with a fresh 6.9 install. Thanks...
Re: Question regarding queueing in pf.conf(5) and WireGuard
You should apply queue on interface attached to network you want to limit
banwidth from. For example if your home network attached to 1GB em1 and you
want to limit web for certain ip addresses, perhaps something like this will
work
...
table { ip addrs list }
queue lanq on em1 bandwidth 950M
queue landefq parent lanq bandwidth 950M qlimit 1024 default
queue slowweb parent lanq bandwidth 32K max 64K
match in on em1 proto tcp from to port { www https } set queue slowweb
match out on egress inet from !(egress:network) to any nat-to (egress:0)
...
Some examples on Solene`s page:
https://dataswamp.org/~solene/2021-02-07-limit.html
And also there is a Book of PF written by Peter N. M. Hansteen
On Mon, Jun 14, 2021 at 11:59:59AM -0600, Ashlen wrote:
> Hello. I have an APU4D4 running OpenBSD and acting as a router for my
> home network. It connects to the Internet via pppoe(4), which uses em(4)
> as the physical interface.
>
> The router has a /etc/hostname.wg0 file that connects it as a client to
> my VPN provider on boot. Then, /etc/pf.conf has a nat-to rule for
> WireGuard, for IP masquerading. Here's said rule:
>
> match out on wg inet from !(wg:network) to any nat-to (wg:0)
>
> In pf.conf(5), there's mention of this simple configuration
> for bandwidth control:
>
> queue outq on em0 bandwidth 9M max 9M flows 1024 qlimit 1024 \
>default
>
> I want to employ this rule. My question is, which interface is
> appropriate to choose for queueing? pppoe0, em0, or wg0? I'd think wg0,
> as I'm unsure how pf(4) would classify traffic otherwise. However, I'm
> not confident in that conclusion, so I decided to ask.
>
> If additional details are needed, I'm happy to provide them.
>
> --
> https://amissing.link
>
Question regarding queueing in pf.conf(5) and WireGuard
Hello. I have an APU4D4 running OpenBSD and acting as a router for my home network. It connects to the Internet via pppoe(4), which uses em(4) as the physical interface. The router has a /etc/hostname.wg0 file that connects it as a client to my VPN provider on boot. Then, /etc/pf.conf has a nat-to rule for WireGuard, for IP masquerading. Here's said rule: match out on wg inet from !(wg:network) to any nat-to (wg:0) In pf.conf(5), there's mention of this simple configuration for bandwidth control: queue outq on em0 bandwidth 9M max 9M flows 1024 qlimit 1024 \ default I want to employ this rule. My question is, which interface is appropriate to choose for queueing? pppoe0, em0, or wg0? I'd think wg0, as I'm unsure how pf(4) would classify traffic otherwise. However, I'm not confident in that conclusion, so I decided to ask. If additional details are needed, I'm happy to provide them. -- https://amissing.link
Re: Who is responsible for ports.su? (admittedly a non-canon resource)
rop...@gmail.com (ropers), 2021.06.14 (Mon) 00:21 (CEST): > > On 2021-06-13, ropers wrote: > >> Sorry to disturb, but does anyone know how to contact whoever is > >> responsible for ports.su? > >> An email address would be great, though I'm not sure if it's okay to > >> post that on-list. Perhaps it's okay to send that off-list? > On 13/06/2021, Stuart Henderson wrote: > > It's Constantine Murenin, I'm not sure of working contact methods. Ian, if you are still into it, maybe try the email from his latest post? https://marc.info/?l=openbsd-misc=158567929032597 Marcus
Re: An OpenBSD Consumer Gateway Launch
Tommy, dear, I am female. And generally, my apologies for the disclaimer, we work mostly in LE, and are required by legal to put it at the end of emails, as most of you will know. I personally do not see the point but as we deal with multi-national companies that do the same it has become somewhat of a standard. I should have removed it before sending. Cheers Nan June 14, 2021 12:05 PM, "Tommy Nevtelen" wrote: > On 14/06/2021 08.15, Stuart Longland wrote: > >> Secondly, isn't it a bit late to tell me _now_ that your email is >> confidential _after_ I have read the body in full? I don't know how >> people read emails in the European Union, but here in Australia, I >> start at the top and read to the bottom, not bottom to top (maybe that >> explains the business world's like for top-posting). > > Maybe you were the intended recipient and he assumed you read emails > upside down. Being in Australia and all. :) > > (I'm sorry about this email but I just had to :) > > /T
Re: An OpenBSD Consumer Gateway Launch
On 14/06/2021 08.15, Stuart Longland wrote: Secondly, isn't it a bit late to tell me _now_ that your email is confidential _after_ I have read the body in full? I don't know how people read emails in the European Union, but here in Australia, I start at the top and read to the bottom, not bottom to top (maybe that explains the business world's like for top-posting). Maybe you were the intended recipient and he assumed you read emails upside down. Being in Australia and all. :) (I'm sorry about this email but I just had to :) /T
Re: An OpenBSD Consumer Gateway Launch
On Fri, 11 Jun 2021 16:15:50 + fern.tje...@aiyja.com wrote: > Disclaimer: This e-mail communication and any attachments to it, are > confidential and privileged to Etheria Services and Etheria Group, within the > European Union, and this includes its sister companies, and to the correct > recipients of this email, which are directly applicable to GDPR regulations, > and only confidential use of that designated recipient(s) named above in this > email may receive the contents herein. If you are not the intended recipient > of this message, you are hereby notified that any review, dissemination, > distribution or copying of this message is strictly prohibited and may be > unlawful and can result in heavy fines relative to your company's income. > Please notify the sender immediately and destroy all copies of this message > along with all attachments. We give no rights to any reader of this email, to > sell or forward our employee or company details on, to any third party, > without specific written request Stupid question, but _why_ are we sending this to a public mailing list if it's confidential? I can guarantee the email _will_ be seen by people _not_ listed as "correct recipients" because it can be seen by theoretically **anyone**. Secondly, isn't it a bit late to tell me _now_ that your email is confidential _after_ I have read the body in full? I don't know how people read emails in the European Union, but here in Australia, I start at the top and read to the bottom, not bottom to top (maybe that explains the business world's like for top-posting). That is how I was taught to read when I was learning to read in primary school back in the early 90s, and how I continue to read English text today: I know the law is an ass best ridden backwards, but I didn't think "backwards" is how I was meant to read legal documents too! Thirdly, how I am I meant to "destroy" the copies, assuming I am not a "correct recipient" (which, by the way, is not defined). If this means destruction of the physical storage devices, do I get compensated by Etheria Group for the 5× 2TB HDDs and 4× 2TB SSDs, any of which "may" be "storing" in part or in full, the very email they want "destroyed"? And what comes of all the _other_ data I have sharing those storage volumes that your footer so forcefully asserts should be cast to the bit bucket? It's a nice gesture publicly thanking the OpenBSD authors for their hard efforts, but legal fashion be damned, I strongly object to the demands made in your email's footer. -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: umb0 broke in 6.9
On 2021-06-13, Paul B. Henson wrote: > I just upgraded a box that has a cell data card in it and it no longer > seems to work :(. The card is: > > umb0 at uhub0 port 3 configuration 1 interface 12 "Sierra Wireless, > Incorporated Sierra Wireless MC7455 Qualcomm\M-. Snapdragon? X7 LTE-A" > rev 2.10/0.06 addr 2 > > The contents of /etc/hostname.umb0 are just: > > apn r.ispsn > > The interface shows: > > umb0: flags=8811 mtu 1500 > index 6 priority 6 llprio 3 > roaming disabled registration unknown > state down cell-class none > SIM not initialized PIN required > APN r.ispsn > status: down > > There is no PIN on the SIM. It was working fine right before the upgrade. > The only umb change I see in the changelog is: > > Added vid/pid table to umb(4) allowing matching to alternate configurations. > > I'm not sure what that means or if my config needs something changed to > work again? Any suggestions appreciated. The card is in an external > minipci adapter connected via USB3. The server is a PC Engines apu3 which > actually has an internal minipci connector, but I couldn't get that to > work as internally it was connected via USB2 and there were issues with > that chipset. I vaguely recall it was actually failing something like > this 8-/. > > Thanks... > > Please build a kernel with UNB_DEBUG defined (easiest way is probably just add "#define UMB_DEBUG" to if_umb.c and send the full dmesg output. I don't think the changes made should affect your card but that would let us check.
Re: autofs
amd. -- Sent from a phone, apologies for poor formatting. On 13 June 2021 23:23:34 Gustavo Rios wrote: avoid autofs ? or amd ? Which should i avoid ? Em dom., 13 de jun. de 2021 às 18:48, Stuart Henderson escreveu: On 2021-06-12, James Cook wrote: On Fri, Jun 11, 2021 at 11:04:15PM -0300, Gustavo Rios wrote: Hi folks! I have a questions regarding OpenBSD. Does it supports autofs ? Any reference regarding how to implement it? Thanks in advance. -- The lion and the tiger may be more powerful, but the wolves do not perform in the circus See amd(8). I have not used it or Linux's autofs, but I think they have the same purpose. They do, but they work quite differently; amd(8) uses a localhost NFSv2 mount. There are some issues with this, including a 2GB maximum file size. You might do better to avoid it if possible. -- The lion and the tiger may be more powerful, but the wolves do not perform in the circus
