35C3 - Chaos Communication Congress 2018
Hello all, I'd like to ask if somebody is going to the congress this year. I attended last year too but I had to leave at the first day after 3 hours because I somehow got lost and didn't find a place "to be". Are there any plans for an assembly or similar or at least an openbsd-meetup where I could take part? Any information or direct contact via email would be really appreciated. -- Tony GPG-FP: 49CC8250 CDCF2183 6209C1AE 625677C1 F7783D5F Threema: DN8PJX4Z
Re: macppc - Booting with a SATA PCI drive
Oh no, the SATA adapter works fine. It’s recognized by Open Firmware and the boot menu lets me select the Tiger install. What I don’t know is how to *manually* boot it through the Open Firmware console so I can load the OpenBSD boot loader. Sent from my iPhone > On Oct 26, 2018, at 8:13 PM, Nick Holland wrote: > >> On 10/25/18 14:51, Katherine Rohl wrote: >> I’m trying to run OpenBSD and Tiger on one hard drive on a Mac G4 >> tower. I’ve successfully installed 6.4 onto the drive and I can still >> boot from Tiger, so that’s good. I then copied ofwboot to the Tiger >> partition (since it’s the first HFS+ partition). >> >> I have an Silicon Image 3112-based PCI SATA controller that’s >> recognized by OF. Unfortunately, I can’t remember how to tell Open >> Firmware to boot from a SATA drive attached to a PCI controller so I >> can specify the OpenBSD boot image! >> >> Does anyone know how to find out the partition’s location in the >> device tree so I can boot to BSD? I’m not good with Open Firmware, >> unfortunately. I’m more of a Classic person, with my Mac usually in >> OS 9. > > You have much greater faith in Apple firmware doing things with > non-Apple HW than I do. :) > > Apple built their firmware to boot MacOS from MacHW, and anything beyond > that that actually works is more good luck than their intent. I'm not > saying it's impossible, it's just not guaranteed. And it might be buggy > if it does try to work. > > I'd suggest just booting off your IDE disk and use your SATA disk as > non-boot space. Or perhaps a SATA to IDE adapter and attach it to the > factory IDE port. > > Nick. >
Re: macppc - Booting with a SATA PCI drive
On 10/25/18 14:51, Katherine Rohl wrote: > I’m trying to run OpenBSD and Tiger on one hard drive on a Mac G4 > tower. I’ve successfully installed 6.4 onto the drive and I can still > boot from Tiger, so that’s good. I then copied ofwboot to the Tiger > partition (since it’s the first HFS+ partition). > > I have an Silicon Image 3112-based PCI SATA controller that’s > recognized by OF. Unfortunately, I can’t remember how to tell Open > Firmware to boot from a SATA drive attached to a PCI controller so I > can specify the OpenBSD boot image! > > Does anyone know how to find out the partition’s location in the > device tree so I can boot to BSD? I’m not good with Open Firmware, > unfortunately. I’m more of a Classic person, with my Mac usually in > OS 9. You have much greater faith in Apple firmware doing things with non-Apple HW than I do. :) Apple built their firmware to boot MacOS from MacHW, and anything beyond that that actually works is more good luck than their intent. I'm not saying it's impossible, it's just not guaranteed. And it might be buggy if it does try to work. I'd suggest just booting off your IDE disk and use your SATA disk as non-boot space. Or perhaps a SATA to IDE adapter and attach it to the factory IDE port. Nick.
dmesg Gigabyte GA-J3455N-D3H
https://www.gigabyte.com/Motherboard/GA-J3455N-D3H-rev-10#ov OpenBSD 6.4 (GENERIC.MP) #364: Thu Oct 11 13:30:23 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4116643840 (3925MB) avail mem = 3982606336 (3798MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xec6a0 (50 entries) bios0: vendor American Megatrends Inc. version "F2" date 03/07/2017 bios0: Gigabyte Technology Co., Ltd. Default string acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP FPDT FIDT MCFG DBG2 DBGP HPET LPIT APIC NPKT PRAM WSMT SSDT SSDT SSDT SSDT SSDT SSDT SSDT UEFI DMAR WDAT acpi0: wakeup devices 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) RP05(S4) PXSX(S4) RP06(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 1920 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz, 1496.98 MHz, 06-5c-09 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,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 1MB 64b/line 16-way L2 cache 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 cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz, 1496.56 MHz, 06-5c-09 cpu1: 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,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz, 1496.58 MHz, 06-5c-09 cpu2: 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,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu2: 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Celeron(R) CPU J3455 @ 1.50GHz, 1496.56 MHz, 06-5c-09 cpu3: 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,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu3: 1MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 120 pins acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (RP01) acpiprt2 at acpi0: bus -1 (RP02) acpiprt3 at acpi0: bus 1 (RP03) acpiprt4 at acpi0: bus 2 (RP04) acpiprt5 at acpi0: bus 4 (RP05) acpiprt6 at acpi0: bus 5 (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 acpicpu1 at acpi0: C3(10@150 mwait.1@0x60), C2(10@50 mwait.1@0x21), C1(1000@1 mwait.1@0x1), PSS acpicpu2 at acpi0: C3(10@150 mwait.1@0x60), C2(10@50 mwait.1@0x21), C1(1000@1 mwait.1@0x1), PSS acpicpu3 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 acpicmos0 at acpi0 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 1496 MHz: speeds: 1501, 1500, 1400, 1300, 1200, 1100, 1000, 900, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Apollo Lake Host" rev 0x0b inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 500" rev 0x0b drm0 at inteldrm0 inteldrm0: msi erro
Sound from vmm guest
So I am working on a bit of an experiment. I have a debian sid guest in vmm. xrdp is installed as is the pulse audio module for xrdp so that it can see the xrdp output in the mixer. I can connect just fine till I try to get sound out. Remmina wouldn't work with sound so to have more control I tried xfreerdp. An example of the options I tried. xfreerdp /sound:sys:sndio,dev:/dev/audio /v:host Basically I can't get it to connect with sound. I can put together a whole log and all, but I was wondering if anyone can suggest how the /sound flag should be under openbsd, or perhaps an alternate method to get sound out of a vmm guest via gui. Or perhaps it is just not possible as of today. To mention I did double check I could cat a wav file to /dev/audio and that worked just fine. Ken
Re: Dell PowerEdge R410 not booting 6.4
On Thursday, October 25, 2018 9:59:09 PM -03 Philip Guenther wrote: > On Thu, Oct 25, 2018 at 8:44 PM diego righi wrote: > > So why openbsd 6.4 i386 and amd64 bootloaders (not biosboot, boot!) > > express different behavior? Wasn't openbsd about correctness? :/ > > If I'm wrong and it is documented that I can't do this fine, but so also > > > i386 should not work, this behavior is just strange for me, that's it. > > This is something that most people, perhaps even most software developers, > are not strongly aware of: that resource requirements are often both > fine-grained and sharp-edged. That is: the exact requirements can vary in > many fine-steps between systems, but there can be a sharp edge at which > performance plummets badly or the system totally fails. This is true of > *many* systems (including lots of cloud services) which work just fine > until they *suddenly* fail, because the memory straw broke the available > RAM camel's back, or the micro-service is now taking just _longer_ to > service one request than the inter-request arrival interval so the queue so > the queue grows in latency past the user/system tolerance. > > Case in point: the memory resources required by the biosboot code depend > many factors including: > * the size of the root partition > * the block size of the root partition (which is affected by the size) > * the inode number of the kernel being booted > * the exact disk block numbers which the booted kernel was put in > > We all, the developers and the community of user who actively test -current > kernel (THANK YOU!) exercise various combinations of those, the *vast* > majority of which use the recommended system layout. That recommend layout > doesn't push the first two of those items at all, and keeps the third and > fourth in sane ranges. > > Meanwhile, those using monster root partitions have unknowingly been > pushing the memory usage by biosboot, but below its limits. > > So, some change was made during the 6.3->6.4 dev cycle which requires > _slightly_ more memory in biosboot. Maybe it was something about the > compiler upgrades, or the maybe it was the SoftRaid crypto passphrase-retry > change. Or maybe it was the tiny tweak of making biosboot default the > console to com0 @ 115200 on VMs.Something made biosboot take more > memory...and now those systems with monster root partitions were pushed > over the edge of how much memory biosboot has available. > > Rule of thumb: the costs must be worth the gain. > So: > * enhancements and fixes break systems that don't get actively tested > * we are are not going to block enhancements/fixes because of that > * we test what we recommend, on many systems > * if a change breaks the recommended config, then it'll get reverted/fixed > * ...this is more likely the more quickly the problem is reported > * ...and even then the recommendation for the future might change > * we also test some systems that go beyond those recommendations... > * ...but not all > * if a system that doesn't follow the recommendations breaks as the result > of a change, the developers will make a judgement about whether the gain of > the change is worth the costs. We don't like breaking any config, even > unusual ones, but if we think the setup is inadvisable, we'll say so and > move on. > > In this particular case: > * the changes to biosboot where in snapshots for MONTHS, but no one > reported problems > * if you aren't following recommendations, and aren't testing snapshots, > then you should be 100% willing to change your configuration on upgrade, > 'cause you ain't giving the feedback necessary to keep your unusual config > alive > * SINGLE PARTITION CONFIGS ARE DUMB, DON'T DO THAT; DON'T BOTHER > COMPLAINING, JUST FIX THEM. > > > Philip Guenther Wow, that was enlightening! I seldom learnt as much off a single post than with this one. Thank you, thank you! Philip Guenther Cheers Eike
Re: Dell PowerEdge R410 not booting 6.4
On Fri, Oct 26, 2018 at 07:57:50AM +, Stuart Henderson wrote: > Using one big "a" partition means: > > - higher risk of filesystem damage to system partitions after an > unsafe restart (crash, power failure): if a partition isn't actively > written to, it's less likely to suffer damage > > - missing protective flags (e.g. nodev, nosuid) that are set on > mounts that don't need to hold device nodes/suid binaries > > * running a system configuration that is further away from what > other users are running, increasing the chance that you'll run > into bugs that others haven't found yet * > > The workaround some have been suggesting (using the i386 boot loader to > run amd64) takes you *even further* from a standard configuration. It > might get you out of a hole, but do yourself a favour, reinstall with > a more normal partition layout and restore from your backups. > > (it doesn't need to be the automatic default, but it's at least > advisable to have separate partitions for /, /usr, /usr/local, /var, > /home, and probably also /usr/ports if you are building from ports). I would add /tmp -Otto
Re: Dell PowerEdge R410 not booting 6.4
Using one big "a" partition means: - higher risk of filesystem damage to system partitions after an unsafe restart (crash, power failure): if a partition isn't actively written to, it's less likely to suffer damage - missing protective flags (e.g. nodev, nosuid) that are set on mounts that don't need to hold device nodes/suid binaries * running a system configuration that is further away from what other users are running, increasing the chance that you'll run into bugs that others haven't found yet * The workaround some have been suggesting (using the i386 boot loader to run amd64) takes you *even further* from a standard configuration. It might get you out of a hole, but do yourself a favour, reinstall with a more normal partition layout and restore from your backups. (it doesn't need to be the automatic default, but it's at least advisable to have separate partitions for /, /usr, /usr/local, /var, /home, and probably also /usr/ports if you are building from ports).
