Re: Apollo Lake kernel panic

[Predrag Punosevac]

I was able to boot machine which crashed with bsd.sp kernel. Please see
message below. That kernel is non-patched kernel as I was running
normally bsd.mp kernel. Also I forgot to say in my previous message that
I didn't mess with C states (BIOS option). I was also using legacy (not
pure UEFI boot) as the the original installation was done on the system 
which didn't support UEFI boot.


OpenBSD 6.2 (GENERIC) #132: Tue Oct  3 21:18:21 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC
real mem = 16799846400 (16021MB)
avail mem = 16283758592 (15529MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xed450 (18 entries)
bios0: vendor American Megatrends Inc. version "P1.30" date 04/18/2017
bios0: ASRock J4205-ITX
acpi0 at bios0: rev 2
acpi0: sleep states S0 S4 S5
acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP LPIT APIC NPKT PRAM WSMT SSDT 
SSDT AAFT SSDT SSDT SSDT SSDT SSDT UEFI BERT WDAT NHLT
acpi0: wakeup devices SIO1(S4) PS2K(S4) UAR1(S4) HDAS(S3) XHC_(S4) XDCI(S4) 
BRCM(S0) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) 
RP04(S4) PXSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 32 bits
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Pentium(R) CPU J4205 @ 1.50GHz, 1497.60 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,FSGSBASE,SMEP,ERMS,MPX,RDSEED,SMAP,CLFLUSHOPT,PT,SHA,SENSOR,ARAT
cpu0: 1MB 64b/line 16-way L2 cache
cpu0: TSC frequency 149760 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 19MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2.4.2.1.1, IBE
cpu at mainbus0: not configured
cpu at mainbus0: not configured
cpu at mainbus0: not configured
ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP03)
acpiprt2 at acpi0: bus 2 (RP04)
acpiprt3 at acpi0: bus 3 (RP05)
acpiprt4 at acpi0: bus 4 (RP06)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C3(10@150 mwait.1@0x60), C2(10@50 mwait.1@0x21), C1(1000@1 
mwait.1@0x1), PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
"INT3452" at acpi0 not configured
"INT3452" at acpi0 not configured
"INT3452" at acpi0 not configured
"INT3452" at acpi0 not configured
"INT33A1" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD1F
cpu0: Enhanced SpeedStep 1497 MHz: speeds: 1501, 1500, 1400, 1300, 1200, 1100, 
1000, 900, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x5af0 rev 0x0b
inteldrm0 at pci0 dev 2 function 0 vendor "Intel", unknown product 0x5a84 rev 
0x0b
drm0 at inteldrm0
inteldrm0: msi
error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load 
firmware i915/bxt_dmc_ver1.bin (-22)
error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC, error -8 
(ignored)
inteldrm0: 1440x900, 32bpp
Unclaimed register detected after writing to register 0x68980
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
azalia0 at pci0 dev 14 function 0 vendor "Intel", unknown product 0x5a98 rev 
0x0b: msi
azalia0: codecs: Realtek/0x0892, 0x/0x, using Realtek/0x0892
audio0 at azalia0
vendor "Intel", unknown product 0x5a9a (class communications subclass 
miscellaneous, rev 0x0b) at pci0 dev 15 function 0 not configured
ahci0 at pci0 dev 18 function 0 vendor "Intel", unknown product 0x5ae3 rev 
0x0b: msi, AHCI 1.3.1
ahci0: port 0: 6.0Gb/s
ahci0: port 1: 6.0Gb/s
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct 
fixed naa.5000c500a20c8afc
sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors
sd1 at scsibus1 targ 1 lun 0:  SCSI3 0/direct 
fixed naa.5000c500a20c72e9
sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors
ppb0 at pci0 dev 19 function 0 vendor "Intel", unknown product 0x5ad8 rev 0xfb: 
msi
pci1 at ppb0 bus 1
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x11: RTL8168G/8111G (0x4c00), 
msi, address 70:85:c2:4a:bf:5b
rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
ppb1 at pci0 dev 19 function 1 vendor "Intel", unknown product 0x5ad9 rev 0xfb: 
msi
pci2 at ppb1 bus 2
ppb2 at pci0 dev 19 function 2 vendor "Intel", unknown product 0x5ada rev 0xfb: 
msi
pci3 at ppb2 bus 3
ahci1 at pci3 dev 0 function 0 "ASMedia ASM1061 AHCI" rev 0x02: msi, AHCI 1.2
ahci1: port 0: 1.5Gb/s
scsibus2 at ahci1: 32 targets
cd0 at scsibus2 targ 0 lun 0: 

Re: Apollo Lake kernel panic

[Predrag Punosevac]

Pedro Ramos wrote:

> Please find attached the dmesg from ASRock J4205-ITX.
> 
> 
> Best regards,
> Pedro Ramos
> 
> 
> ["asrock.j4205-itx.dmesg.gz" (application/x-gzip)]

Unfortunatelly I got one of those few weeks ago and it is nothing but
the trouble. The first one died but NewEgg sent me the second one. I
don't know where to begin. 

With the default ACPI configuration options

1. Suspend to RAM  enabled  
2. ACPI HPET Table enabled 

one can't clearly shut down 6.2 stable. This is what I got 

www.devio.us/~ppunosevac/kernel-panic-1.jpg

The system was frozen to the point that I could not get crash trace. 
With suspend to RAM and HPET table disabled I could finally do 

shutdown -p now

without crashing kernel.

I see that even on 6.2 current dmesg which was sent bunch of errors in
dmesg

pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x5af0
rev 0x0b
inteldrm0 at pci0 dev 2 function 0 vendor "Intel", unknown product
0x5a84 rev 0x0b
drm0 at inteldrm0
inteldrm0: msi
error: [drm:pid0:i915_firmware_load_error_print] *ERROR* failed to load
firmware i915/bxt_dmc_ver1.bin (-22)
error: [drm:pid0:i915_gem_init_hw] *ERROR* Failed to initialize GuC,
error -8 (ignored)


Unfortunatelly at this point my system is trashed so I can't post dmesg
from of 6.2 stable. Namely after trying to start Chrome I got kernel
panic again but I was able this time to trace it 

www.devio.us/~ppunosevac/kernel-panic-2.jpg
 
Now the system hangs on the boot with the message 

entry point at 0x1000158 

My boot device was RAID 1 and I would appreciate if somebody could give
me a suggestion if I can recover the system (I do have the backup for
data). 

Few more things. I could not get X running on my DVI-D 4:3 monitor.
However both VGA output and HDMI were working. HDMI had no problem using
my high definition Panasonic TV. 

If you attach HDD to ASMedia ASM1061 SATA ports (there are 2 of those
and there are two of SATA3 6.0Gb/s Connectors, support NCQ, AHCI and Hot
Plug) S.M.A.R.T. daemon will refuse to start. I have not investigated
this further.

Sound Realtek ALC892 did work as well as Realtek 8111GR Gigabit LAN.
I could not make a use of 1 x PCI Express 2.0 x1 Slot. Note also that
M.2 is only for WiFi not for storage device.

I am not feeling good about this purchase right now. Maybe somebody
could give me some pointers.

Best,
Predrag   

Re: Cheap 2x NIC OpenBSD device

[Chris Cappuccio]

Sean Murphy [s.pat.mu...@gmail.com] wrote:
> You can install OpenBSD on it.  As noted in the thread by techay Ted
> Unangst has a good write up on the unit on his blog.
> 

A side note, OpenBSD 6.2-current will take better advantage of the multiple 
cores using the cnmac interface (or will soon) on this box than the 6.2 release.

Re: Bad network performance on apu2c4

[Chris Cappuccio]

Rupert Gallagher [r...@protonmail.com] wrote:
> Out of curiosity, I just tested an apu2c4 server with obsd 6.1, against a 
> windows 10 client on LAN with a 1Gbit CISCO switch in between and 9K MTU on 
> both sides, using iperf3 -P10. The result is a spectacular 950Mbits/sec.
> 

This is not a regression. The APU2 has limited CPU power and can handle larger 
packets much better than typically internet-routable 1500 byte packets. The 
same traffic level, with 1500 byte packets generates 6 times more packets per 
second than that traffic level with 9000 bytes packets. There is ongoing work 
to improve the network stack performance on boxes like the APU2 (which have 4 
cores). You will see improvements. If you want it better today, you need a 
faster box.

Chris

Re: FOSDEM 2018 - Distributions Devroom Call for Participation

[Bryan Steele]

On Fri, Nov 03, 2017 at 08:57:52PM +0100, leo_...@volny.cz wrote:
> "Brian Exelbierd"  wrote:
> > Online at:
> > https://lists.fosdem.org/pipermail/fosdem/2017-October/002648.html
> > 
> > The Distributions devroom will take place Sunday 4 February 2018 at
> > FOSDEM, in Brussels, Belgium at the Université Libre de Bruxelles.
> 
> Interesting. What does this have to do with OpenBSD?

Quite a bit, actually. FOSDEM has had a BSD devroom track for years.

> And I'll sign it with my shit.
> 
> Stop spamming us, really.
> 
> --schaafuit.

I'd gladly welcome their mail if it means we'll never again receive 
any of yours.

Go away.

-Bryan.

Re: FOSDEM 2018 - Distributions Devroom Call for Participation

[Ingo Schwarze]

Hi leo_tck,

leo_...@volny.cz wrote on Fri, Nov 03, 2017 at 08:57:52PM +0100:

> [I don't normally respond to spam,

This is not spam.  It is an on-topic posting.

Please refrain from insulting people, in particular those posting
rarely who may not be very familiar with OpenBSD and might be
mislead to think that such insults would be normal or acceptable
in an OpenBSD context.

> "Brian Exelbierd"  wrote:

>> Online at:
>> https://lists.fosdem.org/pipermail/fosdem/2017-October/002648.html
>>
>> The Distributions devroom will take place Sunday 4 February 2018 at
>> FOSDEM, in Brussels, Belgium at the Universite Libre de Bruxelles.

> Interesting.  What does this have to do with OpenBSD?

FOSDEM is a major conference about Free Software, arguably even the
major conference in Europe.  OpenBSD as a free operating system.
OpenBSD developers have presented at FOSDEM in the past.  I'm
actually considering to propose a presentation myself, and i'm
grateful for the heads-up.

I consider FOSDEM a major opportunity for communication among
free operating systems that rarely talk to each other.  The *BSD
conferences are no doubt useful too, but less suited to that
particular purpose.

While some of your questions may be interesting and some of your
criticisms might have a point, discussing most of them would be
off-topic on this list.  A call for proposals for a major free
software conference is clearly on topic here; nitpicking on the
concept of the conference is not.

Yours,
  Ingo

-- 
Ingo Schwarze 

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Theo de Raadt]

>I was finally able to bring our OpenBSD based Network Management System up
>to the current OS release (it was a couple of years out of date) but this
>process broke access to a large number of older HP switches on our network.
>Thorough analysis of the problem and study of the source code lead me to
>believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14:
>
>increase the minimum modulus that we will send or accept in
>diffie-hellman-group-exchange to 2048 bits;
>
>Within the file it further explains that this is mitigation for DH
>precomputation attacks. I understand and appreciate strengthening server
>code. But this breaks the use of SSH client leaving little recourse other
>than perhaps telnet with NO encryption instead of somewhat weak encryption,
>as the "server" is outside of our control. (I already checked that we have
>the latest firmware, less than one year old.)

If your switch management is located on a locked-down intranet, aka
'darknet', you can handle this with configuration, or not update the
clients that connect to their legacy servers.

But I guess they are not on a darknet, because you worry about telnet.

>Is this an oversight or is there a particular logic to intentionally
>breaking compatibility with a not-insignificant base of installed equipment?

Absolutely the latter.  It is intentional.  Security and
interopability often collide, especially as new research papers get
written and computational abilities expand.  Circumstances arise where
both needs cannot be satisfied and past decisions must be evaluated and
upgraded.  Decisions like this are not taken lightheartedly.

BTW you can contact HP tech support and tell them that the latest
Cisco Nexus productline just performed a update to latest (well 6
months ago) OpenSSH.  Including ditching SSH1 support.  Cisco has
shorter lifecycles than HP, but did so even for many EOL products in
that line.  So HP could get around to this.

RE: FOSDEM 2018 - Distributions Devroom Call for Participation

[leo_tck]

Hi,

[I don't normally respond to spam, but I need to blow off some
 frustration =)]

"Brian Exelbierd"  wrote:
> Online at:
> https://lists.fosdem.org/pipermail/fosdem/2017-October/002648.html
> 
> The Distributions devroom will take place Sunday 4 February 2018 at
> FOSDEM, in Brussels, Belgium at the Universit=C3=A9 Libre de Bruxelles.

Interesting. What does this have to do with OpenBSD?

> For this year's distributions devroom, we want to focus on the ways that
> distribution technologies can be leveraged to allow for easier
> creation of a multi-verse of artifacts from single source trees.

Uhm, what does that *mean*, in technical terms?

> We also
> want to continue to highlight the huge efforts being made in shared
> environments around Build/Test/Release cycles.

Define 'shared environments'?

> We welcome submissions targeted at contributors interested in issues
> unique to distributions, especially in the following topics:
> 
> - Distribution and Community collaborations, eg: how does code flow from
>   developers to end users across communities, ensuring trust and code
>   audibility
^^

I propose reviving speak(1).

> - Automating building software for redistribution to minimize human
>   involvement, eg: bots that branch and build software, bots that
>   participate as team members extending human involvement

Counterproductive.

> - Cross-distribution collaboration on common issues, eg: content
>   distribution, infrastructure, and documentation

What's cross-distribution? Is it like cross-pollination?

> - Growing distribution communities, eg: onboarding new users, helping
>   new contributors learn community values and technology,  increasing
>   contributor technical skills, recognizing and rewarding contribution

Sounds like a schoolteacher approach to me. An onboarding school, haha!

> - Principals of Rolling Releases, Long Term Supported Releases (LTS),
>   Feature gated releases, and calendar releases

You do know that calendar releases have been obsolete since cal(1),
right?

Unless you like pretty pictures.

> - Distribution construction, installation, deployment, packaging and
>   content management

Ooh yes, when installing OpenBSD I'm very very interested in content
management, woohoo!

> - Balancing new code and active upstreams verus security updates, back
>   porting and minimization of user breaking changes

{,L}users are broken by design, so we don't need to worry about that =)

> - Delivering architecture independent software universally across
>   architectures within the confines of distribution systems

Gibberish.

> - Effectively communicating the difference in experience across
>   architectures for developers, packagers, and users

Ever heard of manual pages? They're great!

> - Working with vendors and including them in the community

What vendors? Most of them ain't interested.

> - The future of distributions, emerging trends and evolving user demands
>   from the idea of a platform

I DEMAND WINDOZE 3193179381, AND I DEMAND IT NOW!!!11!!1!! WH!11!!!

> Ideal submissions are actionable and opinionated. Submissions may
> be in the form of 25 or 50 minute talks, panel sessions, round-table
> discussions, or Birds of a Feather (BoF) sessions.

Actionable? Prolly. Opinionated? Yup. Write me in!

And I'll sign it with my shit.

Stop spamming us, really.

--schaafuit.

Re: Bad network performance on apu2c4

[Rupert Gallagher]

openbsd "current"... is it 6.1 or 6.2?

if 6.2, was it better with 6.1?

From a later message of yours, you mention ISP upload, but the OP did not 
mention it. Are you testing on LAN, WAN or internet?

Out of curiosity, I just tested an apu2c4 server with obsd 6.1, against a 
windows 10 client on LAN with a 1Gbit CISCO switch in between and 9K MTU on 
both sides, using iperf3 -P10. The result is a spectacular 950Mbits/sec.

Sent from ProtonMail Mobile

On Wed, Nov 1, 2017 at 09:14, Christer Solskogen  
wrote:

> Hi! I have a APU2C4 running OpenBSD-current (or.. .pretty current, from 27th 
> of October) - and according to iperf I'm not getting the speed that I was 
> expecting. Between the APU and the other machines I have I get: 465 Mbits/sec 
> - While between two other machines, connected to the same switch I get 939 
> Mbits/sec. So I'm pretty sure that APU is to blame. ifconfig: em0: flags=8b43 
>  mtu 1500 lladdr 00:0d:b9:41:6f:c8 index 1 priority 0 llprio 3 media: 
> Ethernet autoselect (1000baseT full-duplex) status: active inet 192.168.0.2 
> netmask 0xff00 broadcast 192.168.0.255 I've tried different MTU sizes as 
> well, but it does not seem to have any effect. 
> ,broadcast,running,promisc,allmulti,simplex,multicast>

Re: FAQ14: Growing disk partitions: fdisk

[Otto Moerbeek]

On Fri, Nov 03, 2017 at 05:12:54PM +0100, Alexander Hall wrote:

> 
> 
> On November 3, 2017 8:41:20 AM GMT+01:00, Otto Moerbeek  
> wrote:
> >On Fri, Nov 03, 2017 at 08:07:37AM +0100, Stephane HUC "PengouinBSD"
> >wrote:
> >
> >> 
> >> Le 11/03/17 à 07:27, Otto Moerbeek a écrit :
> >> (...)
> >> > 
> >> > My guess is that if you use duids in fstab then you should call it
> >by
> >> > that name withc fsck (which uses fstab). Alternatively, specify the
> >> > mount point.
> >> > 
> >> >  -Otto
> >> > 
> >> > 
> >> 
> >> Interesting point of view, but:
> >> 
> >> 1/ I've not change the writing of the fstab file. It is the fact of
> >the
> >> installer OpenBSD.
> >> 
> >> 2/ Normally, fsck uses fstab. But, as i wrote in my first message, it
> >> seems it not doing it.
> >> 
> >> > # fsck sd0d
> >> > fsck: sd0d: unknown special file or file system.
> >
> >It does use fstab, but it cannot find sd0d in fstab.
> >
> >> 
> >> 3/ By using duids, how i call fsck?
> >
> >fsck ef1ea0f909e0b8d8.d
> >
> >> 
> >> # fsck /tmp
> >> 
> >> ???
> >
> >That line didn't show properly in my mal client.
> >
> >> 
> >> 4/ And, yes, calling fsck as:
> >> 
> >> # fsck /dev/sd0d
> >> 
> >> seems run correctly!
> >
> >Yes, because if a full path is given, fsck uses that without
> >needing to consult fstab.
> 
> Is there some reason why one can it or is not convert fsck to use opendev()?

fsck never did interpret short names, so I would be surpised it it did
that suddenly.

-Otto

> 
> /Alexander
> 
> >
> >> 
> >> => But then why is it written in the FAQ this below, since it doesn't
> >> seem to work? (at least with stable amd64 OpenBSD)
> >> 
> >> "Before the partition can be mounted again, its integrity must be
> >> checked with fsck(8):
> >> 
> >> # fsck sd0h
> >> "
> >
> >That's an error in the FAQ. It has been fixed now,
> >
> > -Otto

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Ryan Freeman]

On Fri, Nov 03, 2017 at 12:06:22AM -0400, Jacob Leifman wrote:
> I was finally able to bring our OpenBSD based Network Management System up
> to the current OS release (it was a couple of years out of date) but this
> process broke access to a large number of older HP switches on our network.
> Thorough analysis of the problem and study of the source code lead me to
> believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14:
> 
> increase the minimum modulus that we will send or accept in
> diffie-hellman-group-exchange to 2048 bits;
> 
> Within the file it further explains that this is mitigation for DH
> precomputation attacks. I understand and appreciate strengthening server
> code. But this breaks the use of SSH client leaving little recourse other
> than perhaps telnet with NO encryption instead of somewhat weak encryption,
> as the "server" is outside of our control. (I already checked that we have
> the latest firmware, less than one year old.)
> 
> Curiously, diffie-hellman-group1-sha1, which is the only one supported by
> the switches, is an accepted KexAlgorithm value in OpenSSH 7.6 (OBSD 6.2);
> I was hoping that I could use it to explicitly request smaller DH but
> ultimately it still dies with "Invalid key length" error.
> 
> Is this an oversight or is there a particular logic to intentionally
> breaking compatibility with a not-insignificant base of installed equipment?

While I agree with all the other posters that ideally all equipment
should be kept up-to-date rather than leaning on aging security
technology, I do realize that in some areas you simply have to get things
done and move on.

As such, I recommend this quick fix:

# pkg_add putty

This will give you the 'plink' command which is a cli putty ssh, and
it allows this stuff by default without making you add host entries
to ~/.ssh/config.  I have noticed it still does warn you when the end
point is using older ciphers but at least doesn't bomb out.

I started using this for older Cisco gear at $WORKPLACE as I grew tired
of editing the ssh config for the OpenSSH version :-)

Hope this helps,

Cheers!
-ryan

> 
> Thank you,
> 
> Jacob Leifman
> Educational Technology
> 
> Weymouth Public Schools
> 
> -- 
> CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is 
> intended only for the individual or entity to which it is addressed and may 
> contain confidential and/or privileged information. Any unauthorized 
> review, use, disclosure or distribution is prohibited. If you are not the 
> intended recipient, or the employee or agent responsible for delivering it 
> to the intended recipient, please contact the sender by reply e-mail and 
> destroy all copies of the original message. If you are the intended 
> recipient but do not wish to receive communication through this medium, 
> please advise the sender immediately. Please note that any views or 
> opinions presented in this email are solely those of the author and do not 
> necessarily represent those of the Weymouth Public Schools. 
> www.weymouthschools.org/

Re: FAQ14: Growing disk partitions: fdisk

[Alexander Hall]

On November 3, 2017 8:41:20 AM GMT+01:00, Otto Moerbeek  wrote:
>On Fri, Nov 03, 2017 at 08:07:37AM +0100, Stephane HUC "PengouinBSD"
>wrote:
>
>> 
>> Le 11/03/17 à 07:27, Otto Moerbeek a écrit :
>> (...)
>> > 
>> > My guess is that if you use duids in fstab then you should call it
>by
>> > that name withc fsck (which uses fstab). Alternatively, specify the
>> > mount point.
>> > 
>> >-Otto
>> > 
>> > 
>> 
>> Interesting point of view, but:
>> 
>> 1/ I've not change the writing of the fstab file. It is the fact of
>the
>> installer OpenBSD.
>> 
>> 2/ Normally, fsck uses fstab. But, as i wrote in my first message, it
>> seems it not doing it.
>> 
>> > # fsck sd0d
>> > fsck: sd0d: unknown special file or file system.
>
>It does use fstab, but it cannot find sd0d in fstab.
>
>> 
>> 3/ By using duids, how i call fsck?
>
>fsck ef1ea0f909e0b8d8.d
>
>> 
>> # fsck /tmp
>> 
>> ???
>
>That line didn't show properly in my mal client.
>
>> 
>> 4/ And, yes, calling fsck as:
>> 
>> # fsck /dev/sd0d
>> 
>> seems run correctly!
>
>Yes, because if a full path is given, fsck uses that without
>needing to consult fstab.

Is there some reason why one can it or is not convert fsck to use opendev()?

/Alexander

>
>> 
>> => But then why is it written in the FAQ this below, since it doesn't
>> seem to work? (at least with stable amd64 OpenBSD)
>> 
>> "Before the partition can be mounted again, its integrity must be
>> checked with fsck(8):
>> 
>> # fsck sd0h
>> "
>
>That's an error in the FAQ. It has been fixed now,
>
>   -Otto

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Allan Streib]

Chris Turner  writes:

> Encryption options can be selected by the client so long as they are available

Which is the issue. The change to usr.bin/ssh/dh.h was:

-#define DH_GRP_MIN 1024
+#define DH_GRP_MIN 2048

So the new DH_GRP_MIN value of 2048 is compiled in.

They could try reverting that commit locally and rebuilding.

Allan

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Kapetanakis Giannis]

On 03/11/17 15:27, Jacob Leifman wrote:

>> KexAlgorithms +diffie-hellman-group1-sha1
>> Ciphers +aes128-cbc
>>
>> Regards
>>
> 
> Hi,
> 
> Not quite, I have the converse problem -- using the modern ssh client and
> being unable to connect to an older embedded ssh server. But your solution
> indicates that in the ssh server implementation the explicit compatibility
> mode actually works. I find the incongruity between server and client
> approaches to backwards compatibility rather odd, since it is generally
> much easier to upgrade or replace a client application (end-user software)
> than the server application, especially embedded server as in my case.
> 
> -Jacob.

The reverse is done on your .ssh/config

host old-server
Hostname 10.0.0.1
KexAlgorithms diffie-hellman-group-exchange-sha1
Ciphers 
aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc

choose what works for you

ssh -v is a friend here to see where it complains.

G

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Chris Turner]

On 11/03/17 08:27, Jacob Leifman wrote:


Not quite, I have the converse problem -- using the modern ssh client and
being unable to connect to an older embedded ssh server. But your solution
indicates that in the ssh server implementation the explicit compatibility
mode actually works.


Encryption options can be selected by the client so long as they are available

e.g.:

ssh -X -oHostKeyAlgorithms=+ssh-dss -oPubKeyAcceptedKeyTypes=+dsa

or by adding a host-specific option in a ~/.ssh/config entry.

See ssh_config(5) and ssh -Q options.

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Jacob Leifman]

On Fri, Nov 3, 2017 at 9:17 AM, Solène Rapenne  wrote:

> Je 2017-11-03 05:06, Jacob Leifman skribis:
>
> I was finally able to bring our OpenBSD based Network Management System up
>> to the current OS release (it was a couple of years out of date) but this
>> process broke access to a large number of older HP switches on our
>> network.
>> Thorough analysis of the problem and study of the source code lead me to
>> believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14:
>>
>> increase the minimum modulus that we will send or accept in
>> diffie-hellman-group-exchange to 2048 bits;
>>
>> Within the file it further explains that this is mitigation for DH
>> precomputation attacks. I understand and appreciate strengthening server
>> code. But this breaks the use of SSH client leaving little recourse other
>> than perhaps telnet with NO encryption instead of somewhat weak
>> encryption,
>> as the "server" is outside of our control. (I already checked that we have
>> the latest firmware, less than one year old.)
>>
>> Curiously, diffie-hellman-group1-sha1, which is the only one supported by
>> the switches, is an accepted KexAlgorithm value in OpenSSH 7.6 (OBSD 6.2);
>> I was hoping that I could use it to explicitly request smaller DH but
>> ultimately it still dies with "Invalid key length" error.
>>
>> Is this an oversight or is there a particular logic to intentionally
>> breaking compatibility with a not-insignificant base of installed
>> equipment?
>>
>> Thank you,
>>
>> Jacob Leifman
>> Educational Technology
>>
>> Weymouth Public Schools
>>
>
> Hello,
>
> I'm not sure if it's what you ask but I had a problem with old ssh clients
> not able to connect to a recent ssh server after a system upgrade. I had to
> add this to my sshd config (on the server) to allow them to connect :
>
>
> KexAlgorithms +diffie-hellman-group1-sha1
> Ciphers +aes128-cbc
>
> Regards
>

Hi,

Not quite, I have the converse problem -- using the modern ssh client and
being unable to connect to an older embedded ssh server. But your solution
indicates that in the ssh server implementation the explicit compatibility
mode actually works. I find the incongruity between server and client
approaches to backwards compatibility rather odd, since it is generally
much easier to upgrade or replace a client application (end-user software)
than the server application, especially embedded server as in my case.

-Jacob.

-- 
CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is 
intended only for the individual or entity to which it is addressed and may 
contain confidential and/or privileged information. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, or the employee or agent responsible for delivering it 
to the intended recipient, please contact the sender by reply e-mail and 
destroy all copies of the original message. If you are the intended 
recipient but do not wish to receive communication through this medium, 
please advise the sender immediately. Please note that any views or 
opinions presented in this email are solely those of the author and do not 
necessarily represent those of the Weymouth Public Schools. 
www.weymouthschools.org/

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Jacob Leifman]

On Fri, Nov 3, 2017 at 8:37 AM, Janne Johansson  wrote:

> 2017-11-03 5:06 GMT+01:00 Jacob Leifman  >:
>
>> I was finally able to bring our OpenBSD based Network Management System up
>> to the current OS release (it was a couple of years out of date) but this
>> process broke access to a large number of older HP switches on our
>> network.
>>
>
>
>> But this breaks the use of SSH client leaving little recourse other
>> than perhaps telnet with NO encryption instead of somewhat weak
>> encryption,
>> as the "server" is outside of our control. (I already checked that we have
>> the latest firmware, less than one year old.)
>>
>> Is this an oversight or is there a particular logic to intentionally
>> breaking compatibility with a not-insignificant base of installed
>> equipment?
>>
>>
> If your vendor, even with a <1y firmware still only can handle old and
> deprecated
> keysizes, you should not ask for everyone elses sshs to become worse, but
> rather
>
push the vendor to get up to speed, and since that will not work, you will
> have to
> resort to building older ssh and use that instead of the safer one that
> comes with
> the modern OS you upgraded to.
>
> Same goes for browsers and https, the bad parts of SSL/TLS gets weeded out
> in browsers
> so that the majority of users are safe, not kept to cater to the lowest
> common denominator
> of the laziest vendor still alive.
>
> You should be asking HP how come they can't keep the free sshd code
> updated,
> if security is your prime concern, not ask openbsd to lower everyone elses
> security.
>

I am not asking to lower anyone else's security or for SSH to "become
worse", I appreciate the default behavior being what it is. I am asking
about a way to have an explicit compatibility mode -- even if we are
successful at lobbying a behemoth like HP for an update, it will take time,
probably a lot of time. Nor is a chronically underfunded public school
district in the position to outright replace >$500K worth of switches that
do their primary duties without fail. Not having some kind of compatibility
mode, leaves me with choice of bad and worse. Typical K-12 management
neither understands tech nor can afford to divert funds to "frivolous"
upgrades. Their inevitable response is either "don't upgrade" or "choose
another product", a product that will not have even the basic security
level OpenBSD had say three years ago.


>
> --
> May the most significant bit of your life be positive.
>

-- 
CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is 
intended only for the individual or entity to which it is addressed and may 
contain confidential and/or privileged information. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, or the employee or agent responsible for delivering it 
to the intended recipient, please contact the sender by reply e-mail and 
destroy all copies of the original message. If you are the intended 
recipient but do not wish to receive communication through this medium, 
please advise the sender immediately. Please note that any views or 
opinions presented in this email are solely those of the author and do not 
necessarily represent those of the Weymouth Public Schools. 
www.weymouthschools.org/

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Janne Johansson]

2017-11-03 14:17 GMT+01:00 Jacob Leifman 
:

> On Fri, Nov 3, 2017 at 8:37 AM, Janne Johansson 
> wrote:
>
>> 2017-11-03 5:06 GMT+01:00 Jacob Leifman > .org>:
>>
>>>
>>> If your vendor, even with a <1y firmware still only can handle old and
>> deprecated
>> keysizes, you should not ask for everyone elses sshs to become worse, but
>> rather
>>
> push the vendor to get up to speed, and since that will not work, you will
>> have to
>> resort to building older ssh and use that instead of the safer one that
>> comes with
>> the modern OS you upgraded to.
>>
>> I am not asking to lower anyone else's security or for SSH to "become
> worse", I appreciate the default behavior being what it is. I am asking
> about a way to have an explicit compatibility mode -- even if we are
> successful at lobbying a behemoth like HP for an update, it will take time,
> probably a lot of time. Nor is a chronically underfunded public school
> district in the position to outright replace >$500K worth of switches that
> do their primary duties without fail. Not having some kind of compatibility
> mode, leaves me with choice of bad and worse. Typical K-12 management
> neither understands tech nor can afford to divert funds to "frivolous"
> upgrades. Their inevitable response is either "don't upgrade" or "choose
> another product", a product that will not have even the basic security
> level OpenBSD had say three years ago.
>

compat =>
https://www.openssh.com/openbsd.html
scroll to the bottom, get one of the old versions and compile that.

cost: $0

Probably same amount as HP paid to be able to have a deprecated sshd in
their product.

-- 
May the most significant bit of your life be positive.

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Solène Rapenne]

Je 2017-11-03 05:06, Jacob Leifman skribis:
I was finally able to bring our OpenBSD based Network Management System 
up
to the current OS release (it was a couple of years out of date) but 
this
process broke access to a large number of older HP switches on our 
network.
Thorough analysis of the problem and study of the source code lead me 
to

believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14:

increase the minimum modulus that we will send or accept in
diffie-hellman-group-exchange to 2048 bits;

Within the file it further explains that this is mitigation for DH
precomputation attacks. I understand and appreciate strengthening 
server
code. But this breaks the use of SSH client leaving little recourse 
other
than perhaps telnet with NO encryption instead of somewhat weak 
encryption,
as the "server" is outside of our control. (I already checked that we 
have

the latest firmware, less than one year old.)

Curiously, diffie-hellman-group1-sha1, which is the only one supported 
by
the switches, is an accepted KexAlgorithm value in OpenSSH 7.6 (OBSD 
6.2);

I was hoping that I could use it to explicitly request smaller DH but
ultimately it still dies with "Invalid key length" error.

Is this an oversight or is there a particular logic to intentionally
breaking compatibility with a not-insignificant base of installed 
equipment?


Thank you,

Jacob Leifman
Educational Technology

Weymouth Public Schools


Hello,

I'm not sure if it's what you ask but I had a problem with old ssh 
clients
not able to connect to a recent ssh server after a system upgrade. I had 
to

add this to my sshd config (on the server) to allow them to connect :


KexAlgorithms +diffie-hellman-group1-sha1
Ciphers +aes128-cbc

Regards

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Janne Johansson]

2017-11-03 13:53 GMT+01:00 Gregory Edigarov :

> You should be asking HP how come they can't keep the free sshd code
>> updated,
>> if security is your prime concern, not ask openbsd to lower everyone elses
>> security.
>>
>> I think for most vendors, it is a rather administrative, than technical
> question.
> Yes, their technical people can update code, yes they can do it quick, but
> their management is slow...
>
>
I think you can let them update for decades and they will not update the
sshd anyhow.
So in the end, the conclusion was true, "since ssh has moved on, if I want
to keep using
my old hw, I need to resort to insecure ways of administering them", where
it may be
ancient ssh clients or telnet or serial ports.

When it comes to IT security, stuff like "was removed 2 years ago, and
deprecated for
X years before that, and better versions have been available for X+Y years"
actually
matters.

You can wave your arms and pretend as if this was a big shock for you, but
actually there is a lot of diligence being skipped in order for someone to
end up in a
situation like this. And not just in the customer end, but the vendor also.
And everyone
else that keep an unpatched admin station around just to make that random
old system
going even though vendors claim to care for your security.

-- 
May the most significant bit of your life be positive.

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Otto Moerbeek]

On Fri, Nov 03, 2017 at 02:53:53PM +0200, Gregory Edigarov wrote:

> I think for most vendors, it is a rather administrative, than technical
> question.
> Yes, their technical people can update code, yes they can do it quick, but
> their management is slow...

Often, the same management is telling everybody security is of the
highest concern to them, so make them deliver on that.

-Otto

FOSDEM 2018 - Distributions Devroom Call for Participation

[Brian Exelbierd]

Online at:
https://lists.fosdem.org/pipermail/fosdem/2017-October/002648.html

The Distributions devroom will take place Sunday 4 February 2018 at
FOSDEM, in Brussels, Belgium at the Université Libre de Bruxelles.

For this year's distributions devroom, we want to focus on the ways that
distribution technologies can be leveraged to allow for easier
creation of a multi-verse of artifacts from single source trees. We also
want to continue to highlight the huge efforts being made in shared
environments around Build/Test/Release cycles.

We welcome submissions targeted at contributors interested in issues
unique to distributions, especially in the following topics:

- Distribution and Community collaborations, eg: how does code flow from
  developers to end users across communities, ensuring trust and code
  audibility

- Automating building software for redistribution to minimize human
  involvement, eg: bots that branch and build software, bots that
  participate as team members extending human involvement

- Cross-distribution collaboration on common issues, eg: content
  distribution, infrastructure, and documentation

- Growing distribution communities, eg: onboarding new users, helping
  new contributors learn community values and technology,  increasing
  contributor technical skills, recognizing and rewarding contribution

- Principals of Rolling Releases, Long Term Supported Releases (LTS),
  Feature gated releases, and calendar releases

- Distribution construction, installation, deployment, packaging and
  content management

- Balancing new code and active upstreams verus security updates, back
  porting and minimization of user breaking changes

- Delivering architecture independent software universally across
  architectures within the confines of distribution systems

- Effectively communicating the difference in experience across
  architectures for developers, packagers, and users

- Working with vendors and including them in the community

- The future of distributions, emerging trends and evolving user demands
  from the idea of a platform

Ideal submissions are actionable and opinionated. Submissions may
be in the form of 25 or 50 minute talks, panel sessions, round-table
discussions, or Birds of a Feather (BoF) sessions.

Dates
--
Submission Deadline: 03-Dec-2017 @ 2359 GMT
Acceptance Notification: 8-Dec-2017
Final Schedule Posted: 15-Dec-2017

How to submit
--
Visit https://penta.fosdem.org/submission/FOSDEM18

1.) If you do not have an account, create one here
2.) Click 'Create Event'
3.) Enter your presentation details
4.) Be sure to select the Distributions Devroom track!
5.) Submit

What to include
---
- The title of your submission
- A 1-paragraph Abstract
- A longer description including the benefit of your talk to your target
  audience, including a definition of your target audience.
- Approximate length / type of submission (talk, BoF, ...)
- Links to related websites/blogs/talk material (if any)

Administrative Notes

We will be live-streaming and recording the Distributions Devroom.
Presenting at FOSDEM implies permission to record your session and
distribute the recording afterwards. All videos will be made available
under the standard FOSDEM content license (CC-BY).

If you have any questions, feel free to contact the
devroom organizers: distributions-devr...@lists.fosdem.org
(https://lists.fosdem.org/listinfo/distributions-devroom)

Cheers!

Brian Exelbierd (twitter: @bexelbie) and Brian Stinson (twitter:
@bstinsonmhk) for and on behalf of The Distributions Devroom Program
Committee

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Gregory Edigarov]

On 03.11.17 14:37, Janne Johansson wrote:

2017-11-03 5:06 GMT+01:00 Jacob Leifman :


I was finally able to bring our OpenBSD based Network Management System up
to the current OS release (it was a couple of years out of date) but this
process broke access to a large number of older HP switches on our network.




But this breaks the use of SSH client leaving little recourse other
than perhaps telnet with NO encryption instead of somewhat weak encryption,
as the "server" is outside of our control. (I already checked that we have
the latest firmware, less than one year old.)

Is this an oversight or is there a particular logic to intentionally
breaking compatibility with a not-insignificant base of installed
equipment?



If your vendor, even with a <1y firmware still only can handle old and
deprecated
keysizes, you should not ask for everyone elses sshs to become worse, but
rather
push the vendor to get up to speed, and since that will not work, you will
have to
resort to building older ssh and use that instead of the safer one that
comes with
the modern OS you upgraded to.

Same goes for browsers and https, the bad parts of SSL/TLS gets weeded out
in browsers
so that the majority of users are safe, not kept to cater to the lowest
common denominator
of the laziest vendor still alive.

You should be asking HP how come they can't keep the free sshd code updated,
if security is your prime concern, not ask openbsd to lower everyone elses
security.

I think for most vendors, it is a rather administrative, than technical 
question.
Yes, their technical people can update code, yes they can do it quick, 
but their management is slow...

Re: Is there an option switch to lower minimum DH strength in SSH client?

[Janne Johansson]

2017-11-03 5:06 GMT+01:00 Jacob Leifman :

> I was finally able to bring our OpenBSD based Network Management System up
> to the current OS release (it was a couple of years out of date) but this
> process broke access to a large number of older HP switches on our network.
>


> But this breaks the use of SSH client leaving little recourse other
> than perhaps telnet with NO encryption instead of somewhat weak encryption,
> as the "server" is outside of our control. (I already checked that we have
> the latest firmware, less than one year old.)
>
> Is this an oversight or is there a particular logic to intentionally
> breaking compatibility with a not-insignificant base of installed
> equipment?
>
>
If your vendor, even with a <1y firmware still only can handle old and
deprecated
keysizes, you should not ask for everyone elses sshs to become worse, but
rather
push the vendor to get up to speed, and since that will not work, you will
have to
resort to building older ssh and use that instead of the safer one that
comes with
the modern OS you upgraded to.

Same goes for browsers and https, the bad parts of SSL/TLS gets weeded out
in browsers
so that the majority of users are safe, not kept to cater to the lowest
common denominator
of the laziest vendor still alive.

You should be asking HP how come they can't keep the free sshd code updated,
if security is your prime concern, not ask openbsd to lower everyone elses
security.

-- 
May the most significant bit of your life be positive.

Re: Fail2ban alternative for OpenBSD

[Gregory Edigarov]

On 02.11.17 20:19, Stuart Henderson wrote:

On 2017-10-30, Gregory Edigarov  wrote:

On 29.10.17 03:20, x9p wrote:

Coming from the Linux world, I wonder if there is a better alternative
to fail2ban, already being used in OpenBSD servers by the majority.


I suggest you NEVER use such "solutions". It's security by obscurity
model, and therefore a bad very very bad thing.
You'd be much safer completely turning off password authentication,
using keys instead.

If someone is pushing a lot of auth attempts, they can be consuming meaningful
amounts of cpu. (They're usually too quick to show up in top). So restricting it
can be useful from that point of view.

Myself, I normally restrict ssh to connecting from a predefined list of IPs 
though ...

And it is a right behavior when you can define such a list.
myself, I just turn off password auth, and have my keys on a pen drive.

Is there an option switch to lower minimum DH strength in SSH client?

[Jacob Leifman]

I was finally able to bring our OpenBSD based Network Management System up
to the current OS release (it was a couple of years out of date) but this
process broke access to a large number of older HP switches on our network.
Thorough analysis of the problem and study of the source code lead me to
believe that the culprit is commit to usr.bin/ssh/dh.h rev 1.14:

increase the minimum modulus that we will send or accept in
diffie-hellman-group-exchange to 2048 bits;

Within the file it further explains that this is mitigation for DH
precomputation attacks. I understand and appreciate strengthening server
code. But this breaks the use of SSH client leaving little recourse other
than perhaps telnet with NO encryption instead of somewhat weak encryption,
as the "server" is outside of our control. (I already checked that we have
the latest firmware, less than one year old.)

Curiously, diffie-hellman-group1-sha1, which is the only one supported by
the switches, is an accepted KexAlgorithm value in OpenSSH 7.6 (OBSD 6.2);
I was hoping that I could use it to explicitly request smaller DH but
ultimately it still dies with "Invalid key length" error.

Is this an oversight or is there a particular logic to intentionally
breaking compatibility with a not-insignificant base of installed equipment?

Thank you,

Jacob Leifman
Educational Technology

Weymouth Public Schools

-- 
CONFIDENTIALITY NOTICE: This e-mail message and any attachment to it is 
intended only for the individual or entity to which it is addressed and may 
contain confidential and/or privileged information. Any unauthorized 
review, use, disclosure or distribution is prohibited. If you are not the 
intended recipient, or the employee or agent responsible for delivering it 
to the intended recipient, please contact the sender by reply e-mail and 
destroy all copies of the original message. If you are the intended 
recipient but do not wish to receive communication through this medium, 
please advise the sender immediately. Please note that any views or 
opinions presented in this email are solely those of the author and do not 
necessarily represent those of the Weymouth Public Schools. 
www.weymouthschools.org/

Re: Apollo Lake

[Pedro Ramos]

Às 17:29 de 02/10/2017, Chris Cappuccio escreveu:

The Asrock J3710 is supported with inteldrm and ethernet etc...

Predrag Punosevac [punoseva...@gmail.com] wrote:

Hi Misc,

The motherboard on my desktop machine just died. I would like to go
fanless embedded. Something like ASRock J3455-ITX.

https://www.newegg.com/Product/Product.aspx?Item=N82E16813157728=1

However I am bit concern about Apollo Lake family of products. Can
anyone post a dmesg? I am open for any suggestions.

Best,
Predrag


Please find attached the dmesg from ASRock J4205-ITX.


Best regards,
Pedro Ramos



asrock.j4205-itx.dmesg.gz
Description: GNU Zip compressed data

Re: FAQ14: Growing disk partitions: fdisk

[Otto Moerbeek]

On Fri, Nov 03, 2017 at 08:07:37AM +0100, Stephane HUC "PengouinBSD" wrote:

> 
> Le 11/03/17 à 07:27, Otto Moerbeek a écrit :
> (...)
> > 
> > My guess is that if you use duids in fstab then you should call it by
> > that name withc fsck (which uses fstab). Alternatively, specify the
> > mount point.
> > 
> > -Otto
> > 
> > 
> 
> Interesting point of view, but:
> 
> 1/ I've not change the writing of the fstab file. It is the fact of the
> installer OpenBSD.
> 
> 2/ Normally, fsck uses fstab. But, as i wrote in my first message, it
> seems it not doing it.
> 
> > # fsck sd0d
> > fsck: sd0d: unknown special file or file system.

It does use fstab, but it cannot find sd0d in fstab.

> 
> 3/ By using duids, how i call fsck?

fsck ef1ea0f909e0b8d8.d

> 
> # fsck /tmp
> 
> ???

That line didn't show properly in my mal client.

> 
> 4/ And, yes, calling fsck as:
> 
> # fsck /dev/sd0d
> 
> seems run correctly!

Yes, because if a full path is given, fsck uses that without
needing to consult fstab.

> 
> => But then why is it written in the FAQ this below, since it doesn't
> seem to work? (at least with stable amd64 OpenBSD)
> 
> "Before the partition can be mounted again, its integrity must be
> checked with fsck(8):
> 
> # fsck sd0h
> "

That's an error in the FAQ. It has been fixed now,

-Otto

Re: Bad network performance on apu2c4

[Christer Solskogen]

On Fri, Nov 3, 2017 at 2:15 AM, Stuart Henderson 
wrote:

> On 2017/11/03 00:10, Christer Solskogen wrote:
> > On Thu, Nov 2, 2017 at 7:24 PM, Stuart Henderson 
> > wrote:
> >
> > Forwarding is kernel-only and should be faster than userland
> > sending. So if
> > you're trying to determine performance when used for forwarding,
> > you need to
> > have other machine/s sending and receiving packets for the test
> >
> >
> > The thing is the the uplink to my ISP is supposed to be 500Mbit/sec.
> > But I only get around 400MB/s, which seems a bit low for a gigabit
> > interface.
> > Problem is not with the ISP, as I've tested with an old-ish laptop. (I
> > even get a bit more than 500Mbit/s!)
> > Perhaps current is using some extra debug-stuff that slows things down?
> >
>
> You may get a little more with tweaks, but the real answer is the ongoing
> work
> to improve SMP in the OpenBSD network stack. I like the APU2 but that's
> a rather fast connection and running fairly close to current limits.
>

Ok, thanks for the explanation ! :-)

-- 
chs

Re: FAQ14: Growing disk partitions: fdisk

[Theo Buehler]

> => But then why is it written in the FAQ this below, since it doesn't
> seem to work? (at least with stable amd64 OpenBSD)

i tested it before giving my ok, but apparently i overlooked this detail.
fixed, thanks

Re: FAQ14: Growing disk partitions: fdisk

[Stephane HUC "PengouinBSD"]

Le 11/03/17 à 07:27, Otto Moerbeek a écrit :
(...)
> 
> My guess is that if you use duids in fstab then you should call it by
> that name withc fsck (which uses fstab). Alternatively, specify the
> mount point.
> 
>   -Otto
> 
> 

Interesting point of view, but:

1/ I've not change the writing of the fstab file. It is the fact of the
installer OpenBSD.

2/ Normally, fsck uses fstab. But, as i wrote in my first message, it
seems it not doing it.

> # fsck sd0d
> fsck: sd0d: unknown special file or file system.

3/ By using duids, how i call fsck?

# fsck /tmp

???

4/ And, yes, calling fsck as:

# fsck /dev/sd0d

seems run correctly!

=> But then why is it written in the FAQ this below, since it doesn't
seem to work? (at least with stable amd64 OpenBSD)

"Before the partition can be mounted again, its integrity must be
checked with fsck(8):

# fsck sd0h
"



-- 
~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD " +=<<<

Stephane HUC as PengouinBSD or CIOTBSD
b...@stephane-huc.net



signature.asc
Description: OpenPGP digital signature

Re: FAQ14: Growing disk partitions: fdisk

[Otto Moerbeek]

On Fri, Nov 03, 2017 at 05:08:53AM +0100, Stephane HUC "PengouinBSD" wrote:

> Hi...
> 
> there seems to be a problem with fsck command on OpenBSD 6.2 amd64 -stable.
> 
> Into the FAQ14, "Growing disk partitions" section, it's written:
> 
> "Before the partition can be mounted again, its integrity must be
> checked with fsck(8):
> 
> # fsck sd0h
> "
> 
> but one of our forum members obsd4a.net asks us if it's normal that it
> doesn't work.
> 
> I read the FAQ, and attempt with my laptop.
> 
> My disklabel:
> 
> [code]
> #disklabel -E sd0
> Label editor (enter '?' for help at any prompt)
> > p
> OpenBSD area: 64-976768065; size: 976768001; free: 194252529
> #size   offset  fstype [fsize bsize   cpg]
>   a: 10486016104780352  4.2BSD   2048 16384 12958 # /
>   b: 17100976  2097216swap# none
>   c:9767731680  unused
>   d: 10474368115266368  4.2BSD   2048 16384 12958 # /tmp
>   e: 20964832125740736  4.2BSD   2048 16384 12958 # /var
>   f:  4194304 69128768  4.2BSD   2048 16384 12958 # /usr
>   g:  2097152 73323072  4.2BSD   2048 16384 12958 #
> /usr/X11R6
>   h: 20971520 75420224  4.2BSD   2048 16384 12958 #
> /usr/local
>   i:  4194304 96391744  4.2BSD   2048 16384 12958 # /usr/src
>   j: 20964832817772736  4.2BSD   2048 16384 12958 # /usr/obj
>   k: 20964832146705568  4.2BSD   2048 16384 12958 # /var/log
>   l:629137472167670400  4.2BSD   4096 32768 26062 # /home
>   m: 20964864796807872  4.2BSD   2048 16384 12958 #
> /usr/ports
> > q
> No label changes.
> [/code]
> 
> Ok, i attempt to check only my slide /tmp... fstype: 4.2BSD
> 
> My fstab file is:
> $ cat /etc/fstab
> 
> ef1ea0f909e0b8d8.b none swap sw
> ef1ea0f909e0b8d8.a / ffs rw,softdep 1 1
> ef1ea0f909e0b8d8.l /home ffs rw,nodev,nosuid,softdep 1 2
> ef1ea0f909e0b8d8.d /tmp ffs rw,nodev,nosuid,softdep 1 2
> ef1ea0f909e0b8d8.f /usr ffs rw,nodev,softdep 1 2
> ef1ea0f909e0b8d8.g /usr/X11R6 ffs rw,nodev,softdep 1 2
> ef1ea0f909e0b8d8.h /usr/local ffs rw,wxallowed,nodev,softdep 1 2
> ef1ea0f909e0b8d8.j /usr/obj ffs rw,nodev,nosuid,softdep 1 2
> ef1ea0f909e0b8d8.m /usr/ports ffs rw,nodev,nosuid,softdep,wxallowed 1 2
> ef1ea0f909e0b8d8.i /usr/src ffs rw,nodev,nosuid,softdep 1 2
> ef1ea0f909e0b8d8.e /var ffs rw,nodev,nosuid,softdep 1 2
> ef1ea0f909e0b8d8.k /var/log ffs rw,nodev,noexec,nosuid,softdep 1 2
> 
> The fs type /tmp seems to be good:
> $ awk '/\/tmp/ { print $3 }' /etc/fstab
> ffs
> 
> ffs = 4.2BSD! OK.
> 
> But if i attempt to fsck, with rights root:
> # fsck sd0d
> fsck: sd0d: unknown special file or file system.
> 
> ???
> 
> If i use fsck_ffs, its OK!
> # fsck_ffs sd0d
> ** /dev/sd0d (sd0d)
> ** File system is clean; not checking
> 
> Error into FAQ14 or fdisk's bug?
> 
> -- 
> ~ " Fully Basic System Distinguish Life! " ~ " Libre as a BSD "   +=<<<
> 
> Stephane HUC as PengouinBSD or CIOTBSD
> b...@stephane-huc.net
> 

My guess is that if you use duids in fstab then you should call it by
that name withc fsck (which uses fstab). Alternatively, specify the
mount point.

-Otto