Re: signify: invalid comment in SHA256
On Sat, Jun 17, 2023 at 10:33:01PM -0700, Philip Guenther wrote: > On Sat, Jun 17, 2023 at 9:38???PM Avon Robertson wrote: > > > Used lynx to get the 4 files shown below. The shell prompt is a 2 > > line prompt with current dir on 1st line,'$ ' only, on the 2nd line. > > > > Below is output captured from a tmux pane with a script. > > > > aahno:/ > > $ cat /etc/installurl > > https://mirror.aarnet.edu.au/pub/OpenBSD > > aahno:/ > > $ lynx $(cat /etc/installurl)/snapshots/amd64 > > aahno:/ > > $ cd ~/download > > aahno:/home/anon/download > > $ ls -la > > total 1361400 > > drwxr-x--- 2 anon anon512 Jun 18 15:35 . > > drwxr-xr-x 25 anon anon 1536 Jun 18 08:01 .. > > -rw-r- 1 anon anon 44817 Jun 18 15:34 INSTALL.amd64 > > -rw-r- 1 anon anon 1992 Jun 18 15:34 SHA256 > > -rw-r- 1 anon anon 2144 Jun 18 15:34 SHA256.sig > > -rw-r- 1 anon anon 696745984 Jun 18 15:36 install73.img > > aahno:/home/anon/download > > $ signify -C -p /etc/signify/openbsd-73-base.pub -x SHA256 install73.img > > signify: invalid comment in SHA256; must start with 'untrusted comment: ' > > aahno:/home/anon/download > > > You downloaded SHA256.sig, but then told signify to read the SHA256 file. > Perhaps you should follow all the examples for signify and pass it the > SHA256.sig file. > > > Philip Guenther What a dummy I am Philip. I was reading the example in INSTALL.amd64 as I entered the command too. Thank you for your reply.
Re: signify: invalid comment in SHA256
On Sat, Jun 17, 2023 at 9:38 PM Avon Robertson wrote: > Used lynx to get the 4 files shown below. The shell prompt is a 2 > line prompt with current dir on 1st line,'$ ' only, on the 2nd line. > > Below is output captured from a tmux pane with a script. > > aahno:/ > $ cat /etc/installurl > https://mirror.aarnet.edu.au/pub/OpenBSD > aahno:/ > $ lynx $(cat /etc/installurl)/snapshots/amd64 > aahno:/ > $ cd ~/download > aahno:/home/anon/download > $ ls -la > total 1361400 > drwxr-x--- 2 anon anon512 Jun 18 15:35 . > drwxr-xr-x 25 anon anon 1536 Jun 18 08:01 .. > -rw-r- 1 anon anon 44817 Jun 18 15:34 INSTALL.amd64 > -rw-r- 1 anon anon 1992 Jun 18 15:34 SHA256 > -rw-r- 1 anon anon 2144 Jun 18 15:34 SHA256.sig > -rw-r- 1 anon anon 696745984 Jun 18 15:36 install73.img > aahno:/home/anon/download > $ signify -C -p /etc/signify/openbsd-73-base.pub -x SHA256 install73.img > signify: invalid comment in SHA256; must start with 'untrusted comment: ' > aahno:/home/anon/download You downloaded SHA256.sig, but then told signify to read the SHA256 file. Perhaps you should follow all the examples for signify and pass it the SHA256.sig file. Philip Guenther
signify: invalid comment in SHA256
Hello, Used lynx to get the 4 files shown below. The shell prompt is a 2 line prompt with current dir on 1st line,'$ ' only, on the 2nd line. Below is output captured from a tmux pane with a script. aahno:/ $ cat /etc/installurl https://mirror.aarnet.edu.au/pub/OpenBSD aahno:/ $ lynx $(cat /etc/installurl)/snapshots/amd64 aahno:/ $ cd ~/download aahno:/home/anon/download $ ls -la total 1361400 drwxr-x--- 2 anon anon512 Jun 18 15:35 . drwxr-xr-x 25 anon anon 1536 Jun 18 08:01 .. -rw-r- 1 anon anon 44817 Jun 18 15:34 INSTALL.amd64 -rw-r- 1 anon anon 1992 Jun 18 15:34 SHA256 -rw-r- 1 anon anon 2144 Jun 18 15:34 SHA256.sig -rw-r- 1 anon anon 696745984 Jun 18 15:36 install73.img aahno:/home/anon/download $ signify -C -p /etc/signify/openbsd-73-base.pub -x SHA256 install73.img signify: invalid comment in SHA256; must start with 'untrusted comment: ' aahno:/home/anon/download $ gtmuxpane /home/anon/mailinc/signify-invalid-comment.txt Is the above 'untrusted comment: ' a stopper for installing with this install73.img. Advice will be very appreciated.
Re: Hibernation on Thinkpad Carbon X1 gen 7 - unhibernate failed
On Sat, 17 Jun 2023 19:00 +0100, Chris Narkiewicz wrote: > On Sat, 2023-06-17 at 09:21 -0600, Ashlen wrote: > > I have a 7th gen X1 Carbon and am not sure that the hardware is the > > issue here. I've only experienced this very rarely. > > > > I can confirm that I managed to unhibernate successfully and the error > is no longer occuring, confirming your observation. > > However, image unhibernation took about 5 minutes. > > unhibernating @ block 50329532 length 750MB <- this takes ~5 minutes > Unpacking image... <- this few seconds and I'm back in X11 > > I was so confused that I thought it just hangs. > > How long does it take to ZZZ and unhibernate? > > Cheers, > Chris > I'd assume that varies depending on the exact hardware in your machine and the amount of memory saved to disk. Sometimes I've noticed that unhibernating takes a couple of minutes if I had a lot of tabs open in a browser or something, but it doesn't bother me that much. Otherwise, I don't have the expertise in C to continue a meaningful discussion about this. All I really did was search misc@ and grep the source code.
Re: Hibernation on Thinkpad Carbon X1 gen 7 - unhibernate failed
On Sat, 2023-06-17 at 09:21 -0600, Ashlen wrote: > I have a 7th gen X1 Carbon and am not sure that the hardware is the > issue here. I've only experienced this very rarely. > I can confirm that I managed to unhibernate successfully and the error is no longer occuring, confirming your observation. However, image unhibernation took about 5 minutes. unhibernating @ block 50329532 length 750MB <- this takes ~5 minutes Unpacking image... <- this few seconds and I'm back in X11 I was so confused that I thought it just hangs. How long does it take to ZZZ and unhibernate? Cheers, Chris
Re: Hibernation on Thinkpad Carbon X1 gen 7 - unhibernate failed
On Fri, 16 Jun 2023 19:23 -0400, Dave Voutila wrote: > > Chris Narkiewicz writes: > > > Hi, > > > > I got Thinkpad Carbon X1 gen7 and I tried to test hibernation (ZZZ). > > Do you have a dmesg? > > > > > When system is resumed, it took several minutes to load image. > > dmesg shows: > > > > unhibernate failed: original kernel changed > > > > and my iwm0 wifi card is not visible anymore. > > > > Is there someobdy with 7th gen X1 that could confirm? > > According to https://jcs.org/2019/08/14/x1c7 it should work. > > > > Thanks for any suggestions, > > Chris > I have a 7th gen X1 Carbon and am not sure that the hardware is the issue here. I've only experienced this very rarely. That error is from a function named hibernate_compare_signature in sys/kern/subr_hibernate.c. It's a safety check that makes sure the machine matches the memory configuration and kernel of the one that wrote the signature. Did you syspatch(8) and then hibernate or something, particularly after syspatch says to reboot? That'd probably cause that to happen. https://marc.info/?l=openbsd-misc&m=162341221700319&w=2 P.S. Even though I'm not OP, here's my dmesg if it helps in some way. OpenBSD 7.3-current (GENERIC.MP) #1240: Wed Jun 14 23:02:31 MDT 2023 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16959836160 (16174MB) avail mem = 16426180608 (15665MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xc7d49000 (64 entries) bios0: vendor LENOVO version "N2HET71W (1.54 )" date 08/03/2022 bios0: LENOVO 20QDUS efi0 at bios0: UEFI 2.6 efi0: Lenovo rev 0x1540 acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT TPM2 UEFI SSDT HPET APIC MCFG ECDT SSDT SSDT SSDT BOOT SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB NHLT DMAR FPDT BGRT UEFI acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1727.61 MHz, 06-8e-0c 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,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1450.28 MHz, 06-8e-0c 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,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1215.61 MHz, 06-8e-0c 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,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB 64b/line 4-way L2 cache, 8MB 64b/line 16-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-8565U CPU @ 1.80GHz, 1054.83 MHz, 06-8e-0c 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
Re: encrypted_hdd_data_recovery(OpenBSD_7.3)
On 6/17/23 08:40, soko.tica wrote: Hello list, I have managed to screw by #fsck_ffs /dev/sd1a the root partition of my unmounted HDD (OpenBSD 7.3 stable, possibly not fully updated). It crashed during boot due to the power outage, than it was unable to boot and required fsck_ffs, and I answered 'F' to the 'Fyn' prompt. Here is the present status of it (it is sd0 in this sequence). === Script started on Sat Jun 17 12:26:43 2023 think# disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: HGST HTS725050A7 duid: 35e70751b7e36f98 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 60801 total sectors: 976773168 boundstart: 64 boundend: 976768065 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a:976768001 64RAID c:9767731680 unused think# ^D Script done on Sat Jun 17 12:26:54 2023 === this is as I'd expect. but you aren't showing what happens when you try to unlock it I understand you have a problem, but you haven't told us what it is. If you have a problem when unlocking the disk with the bioctl command, you probably aren't going to get your data back. If you can get the drive unlocked and available as another logical drive, you will probably have to fsck each partition within it. Hopefully any horrible problems here would be contained to individual partitions, and you can pull data off the rest. ... Naturally, there is data there, and naturally, I have no backup of it. Of course I do know the passphrase, it is my hdd. this is what we call a learning experience. If there is any chance to recover it, please let me know. chance, maybe. But almost by design, encrypted storage is more fragile than unencrypted storage. Nick.
encrypted_hdd_data_recovery(OpenBSD_7.3)
Hello list, I have managed to screw by #fsck_ffs /dev/sd1a the root partition of my unmounted HDD (OpenBSD 7.3 stable, possibly not fully updated). It crashed during boot due to the power outage, than it was unable to boot and required fsck_ffs, and I answered 'F' to the 'Fyn' prompt. Here is the present status of it (it is sd0 in this sequence). === Script started on Sat Jun 17 12:26:43 2023 think# disklabel sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: HGST HTS725050A7 duid: 35e70751b7e36f98 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 60801 total sectors: 976773168 boundstart: 64 boundend: 976768065 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a:976768001 64RAID c:9767731680 unused think# ^D Script done on Sat Jun 17 12:26:54 2023 === It was created as per the instructions here https://www.openbsd.org/faq/faq14.html#softraidFDE possibly during 6.9, or 7.0. Naturally, there is data there, and naturally, I have no backup of it. Of course I do know the passphrase, it is my hdd. If there is any chance to recover it, please let me know. Regards, a seasoned noob user Soko Tica