Re: sysupgrade doesn't like the path
On Sat, Oct 10, 2020 at 2:42 PM Ed Ahlsen-Girard wrote: > > sysupgrade is looking for files in 6.9 (which isn't being found). Is > this due to a slow mirror upgrade or just "near release stuff"? If you are trying to refresh a snapshot, I found using "sysupgrade -s" solved this problem when I refreshed a few days ago.
Re: sysupgrade doesn't like the path
Ed Ahlsen-Girard wrote: > sysupgrade is looking for files in 6.9 (which isn't being found). Is > this due to a slow mirror upgrade or just "near release stuff"? fw_update, sysupgrade, pkg_add, syspatch, and some other things have heuristic issues near release, and it is difficult to fix because what we release gets a bit incoherent and weird. we don't want these things to probe too much and then for the probes to be attackable.
sysupgrade doesn't like the path
sysupgrade is looking for files in 6.9 (which isn't being found). Is this due to a slow mirror upgrade or just "near release stuff"? -- Edward Ahlsen-Girard Ft Walton Beach, FL
Re: tmux rc script not stopping
In retrospect, command -v seems to be more portable than which[1]. So a better version would be: if command -v tmux >/dev/null 2>&1; then # if not inside a tmux session, and if no session is started, start # a new session test -z "$TMUX" && (tmux attach || tmux new-session) fi Though I suppose this is likely academic in nature. [1]: https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then -- https://amissing.link
Re: Dell XPS 9575: Can't resume from standby or suspend
On 10/10/20 4:40 PM, Brennan Vincent wrote: On 10/10/20 3:29 PM, Brennan Vincent wrote: On `apm -S` or `zzz`, the system appears to power down, but when I try to wake it back up, the power does come on (fans spin, keyboard lights come on) but the screen is black and the system is unresponsive. /var/log/messages attached. Anyone have some idea what steps I should take to investigate/debug this? Thanks Brennan Forgot to mention: I am running -current. If I boot with `disable amdgpu`, the issue goes away. It is probably related to this issue, which I reported previously, and which was at least partially fixed (I don't get panics now, at any rate): http://openbsd-archive.7691.n7.nabble.com/Dell-XPS-9575-with-dual-discrete-integrated-GPU-amdgpu-causes-kernel-panic-td377365.html
Re: Dell XPS 9575: Can't resume from standby or suspend
On 10/10/20 3:29 PM, Brennan Vincent wrote: On `apm -S` or `zzz`, the system appears to power down, but when I try to wake it back up, the power does come on (fans spin, keyboard lights come on) but the screen is black and the system is unresponsive. /var/log/messages attached. Anyone have some idea what steps I should take to investigate/debug this? Thanks Brennan Forgot to mention: I am running -current.
Dell XPS 9575: Can't resume from standby or suspend
On `apm -S` or `zzz`, the system appears to power down, but when I try to wake it back up, the power does come on (fans spin, keyboard lights come on) but the screen is black and the system is unresponsive. /var/log/messages attached. Anyone have some idea what steps I should take to investigate/debug this? Thanks Brennan Oct 10 15:09:28 Incheon syslogd[81622]: start Oct 10 15:09:28 Incheon /bsd: syncing disks... done Oct 10 15:09:28 Incheon /bsd: newstate RUN -> INIT Oct 10 15:09:28 Incheon /bsd: RX status=6 Oct 10 15:09:28 Incheon /bsd: rebooting... Oct 10 15:09:28 Incheon /bsd: OpenBSD 6.8-current (GENERIC.MP) #1: Sat Oct 10 14:59:29 EDT 2020 Oct 10 15:09:28 Incheon /bsd: bren...@incheon.my.domain:/home/brennan/openbsd/src/sys/arch/amd64/compile/GENERIC.MP Oct 10 15:09:28 Incheon /bsd: real mem = 16867749888 (16086MB) Oct 10 15:09:28 Incheon /bsd: avail mem = 16341458944 (15584MB) Oct 10 15:09:28 Incheon /bsd: random: good seed from bootblocks Oct 10 15:09:28 Incheon /bsd: mpath0 at root Oct 10 15:09:28 Incheon /bsd: scsibus0 at mpath0: 256 targets Oct 10 15:09:28 Incheon /bsd: mainbus0 at root Oct 10 15:09:28 Incheon /bsd: bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xe7450 (96 entries) Oct 10 15:09:28 Incheon /bsd: bios0: vendor Dell Inc. version "1.7.1" date 07/07/2019 Oct 10 15:09:28 Incheon /bsd: bios0: Dell Inc. XPS 15 9575 Oct 10 15:09:28 Incheon /bsd: acpi0 at bios0: ACPI 5.0 Oct 10 15:09:28 Incheon /bsd: acpi0: sleep states S0 S3 S4 S5 Oct 10 15:09:28 Incheon /bsd: acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT BOOT SSDT SSDT HPET SSDT UEFI SSDT LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC SSDT NHLT BGRT TPM2 SSDT ASF! DMAR Oct 10 15:09:28 Incheon /bsd: acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) PXSX(S4) [...] Oct 10 15:09:28 Incheon /bsd: acpitimer0 at acpi0: 3579545 Hz, 24 bits Oct 10 15:09:28 Incheon /bsd: acpimadt0 at acpi0 addr 0xfee0: PC-AT compat Oct 10 15:09:28 Incheon /bsd: cpu0 at mainbus0: apid 0 (boot processor) Oct 10 15:09:28 Incheon /bsd: cpu0: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz, 3692.88 MHz, 06-9e-09 Oct 10 15:09:28 Incheon /bsd: 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN Oct 10 15:09:28 Incheon /bsd: cpu0: 256KB 64b/line 8-way L2 cache Oct 10 15:09:28 Incheon /bsd: cpu0: smt 0, core 0, package 0 Oct 10 15:09:28 Incheon /bsd: mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges Oct 10 15:09:28 Incheon /bsd: cpu0: apic clock running at 24MHz Oct 10 15:09:28 Incheon /bsd: cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE Oct 10 15:09:28 Incheon /bsd: cpu1 at mainbus0: apid 2 (application processor) Oct 10 15:09:28 Incheon /bsd: cpu1: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz, 3691.40 MHz, 06-9e-09 Oct 10 15:09:28 Incheon /bsd: 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN Oct 10 15:09:28 Incheon /bsd: cpu1: 256KB 64b/line 8-way L2 cache Oct 10 15:09:28 Incheon /bsd: cpu1: smt 0, core 1, package 0 Oct 10 15:09:28 Incheon /bsd: cpu2 at mainbus0: apid 4 (application processor) Oct 10 15:09:28 Incheon /bsd: cpu2: Intel(R) Core(TM) i7-8705G CPU @ 3.10GHz, 3691.40 MHz, 06-9e-09 Oct 10 15:09:28 Incheon /bsd: 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,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN Oct 10 15:09:28 Incheon /bsd: cpu2: 256KB 64b/line 8-way L2 cache Oct 10 15:09:28 Incheon /bsd: cpu2: smt 0, core 2, package 0 Oct 10 15:09:28 Incheon /bsd: cpu3 at mainbus0: apid 6 (application processor) Oct 10 15:09:28 Incheon /bsd: cpu3: Intel(R) Core(TM) i7-8705
Re: tmux rc script not stopping
On 20/10/07 02:34PM, ben wrote: > Hello, Misc; > > I'm attempting to write an rc script to start a tmux session: What problem are you trying to solve by using an rc script? I have this in my .kshrc for automatic tmux sessions: if which tmux >/dev/null 2>&1; then # if not inside a tmux session, and if no session is started, start # a new session test -z "$TMUX" && (tmux attach || tmux new-session) fi Of course, in the end the solution depends on what you want to do. -- https://amissing.link
Re: Snapshot crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)
Hi, on my Lenovo V130 I've to build a custom kernel without radeondrm and amdgpu. https://marc.info/?l=openbsd-misc&m=159276382718317&w=2 The modified efiboot.c, see https://marc.info/?l=openbsd-misc&m=159401011632149&w=2, doesnt work on this machine. Best regards, Sven On 10/9/20 9:32 PM, Kastus Shchuka wrote: On Fri, Oct 09, 2020 at 03:37:37PM +0400, Michel von Behr wrote: Hi all, I'm trying to run snapshot on a Chuwi Lapbook laptop (Intel Gemini Lake), but I get stuck at boot time with the message "entry point at: 0x1001000". Based on previous discussions [1] it looks like the problem is with BOOTX64.EFI For now I'll be running -stable, but I would like to follow -current. Is there a way to run -current with an old version of BOOTX64.EFI for example? (i.e., the only alternatives I'm seeing is either 1) compiling a GENERIC kernel with the older version of BOOTX64.EFI src, or 2) (try to) compile a custom/smaller kernel to avoid the issue). [1] https://marc.info/?l=openbsd-misc&m=159147446008114&w=2 Any pointing to the right direction is welcome. I had the same problem with EFI on ASRock J4105M system, essentially failing to boot a kernel larger than certain size. I posted my solution here: https://marc.info/?l=openbsd-misc&m=159401011632149&w=2 I guess the patch requires more testing before asking for it to be committed. Thanks, Kastus
Re: Snapshot crash on boot, "entry point at: 0x1001000" (Intel Gemini Lake)
On 2020-10-09, Michel von Behr wrote: > I'm trying to run snapshot on a Chuwi Lapbook laptop (Intel Gemini Lake), > but I get stuck at boot time with the message "entry point at: 0x1001000". > Based on previous discussions [1] it looks like the problem is with > BOOTX64.EFI > For now I'll be running -stable, but I would like to follow -current. Is > there a way to run -current with an old version of BOOTX64.EFI for example? If you upgrade by downloading and untarring sets on the running system, you can avoid updating the bootloader, the basic method is described in http://www.openbsd.org/faq/upgrade67.html#NoInstKern (obviously skip the "update the bootloader" step). Note that newer versions of the bootloader read the seed for early RNG use in the kernel, I'm not sure when it was added but you might miss out on that with a 6.7 bootloader.
Re: Recommended License
And by the same logic, the original BSD license does not demand that
the permission ("Redistribution and use in source and binary forms,
with or without modification, are permitted provided that the
following conditions are met") be copied.
It only demands that the copyright note and the disclaimer be copied, and
also the rule that this must happen in succesive redistributions
(if they are permited in some way).
That "The FreeBSD Project" copirights "the compilation of
software known as FreeBSD" and seems to take himself the right to
license software it has not the copyright, is strange.
Rod.
Re: Recommended License
Well, my last question is perhaps superflous, because it is impossible to make the many authors agree, but I wonder that FreeBSD copyrights "The compilation of software known as FreeBSD" in its /usr/src/COPYRIGHT: The compilation of software known as FreeBSD is distributed under the following terms: Copyright (c) 1992-2020 The FreeBSD Project. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: [...] " Rod.
Recommended License
I just read this: https://cvsweb.openbsd.org/src/share/misc/license.template?rev=HEAD It is a nice license, because it is short, and I wonder why a permisive license cannot be shorter (well, I do not understand the many legal words). But perhaps to short? It does not mention that the disclaimer should be copied as in the original BSD licence. From the meaning I cannot see that a disclaimer is part of the "permission notice". As I see, authors in OpenBSD retain their copyright? Do they agree to a common license for the whole? Rod.
