Re: Why is tmpfs not working on OpenBSD?
On Monday, September 6th, 2021 at 12:50 PM, Marc Espie wrote: > On Sun, Sep 05, 2021 at 10:12:33PM +, iio7 wrote: > > > > On 2021-09-05, iio7 < > > > > > > i...@protonmail.com > > > > > > wrote: > > > > > > > mount -t tmpfs tmpfs /home/foo/tmp/ > > > > === > > > > > > > > mount_tmpfs: tmpfs on /home/foo/tmp: Operation not supported > > > > > It isn't built into the standard kernels, disabled with this commit:: > > > > > revision 1.229 > > > > > > date: 2016/07/25 19:52:56 > > > > > > disable tmpfs because it receives zero maintainance. > > > > Why isn't it removed? It is kinda "misguiding". > > There might be hope that someone who has the time would do proper > > maintenance... That's fine. I just naturally assumed that something like this would be mentioned in the man page, or on the FAQ or somewhere else, which is where I looked. When I didn't find anything I just assumed that there where something wrong with my system or setup. I didn't even consider searching the mailing list because I would never had guessed that OpenBSD was in this state. Over the years I have come to know OpenBSD for its prime documentation. Shipping a solution in the base that isn't working is not what I normally connect with OpenBSD.
Re: Why is tmpfs not working on OpenBSD?
On Mon, Sep 6, 2021, at 8:44 PM, iio7 wrote: > On Monday, September 6th, 2021 at 12:50 PM, Marc Espie > wrote: > > > On Sun, Sep 05, 2021 at 10:12:33PM +, iio7 wrote: > > > > > > On 2021-09-05, iio7 < > > > > > > > > i...@protonmail.com > > > > > > > > wrote: > > > > > > > > > mount -t tmpfs tmpfs /home/foo/tmp/ > > > > > === > > > > > > > > > > mount_tmpfs: tmpfs on /home/foo/tmp: Operation not supported > > > > > > > It isn't built into the standard kernels, disabled with this commit:: > > > > > > > revision 1.229 > > > > > > > > date: 2016/07/25 19:52:56 > > > > > > > > disable tmpfs because it receives zero maintainance. > > > > > > Why isn't it removed? It is kinda "misguiding". > > > > There might be hope that someone who has the time would do proper > > > > maintenance... > > That's fine. I just naturally assumed that something like this would > be mentioned in the man page, or on the FAQ or somewhere else, which > is where I looked. When I didn't find anything I just assumed that > there where something wrong with my system or setup. I didn't even > consider searching the mailing list because I would never had guessed > that OpenBSD was in this state. Over the years I have come to know > OpenBSD for its prime documentation. Shipping a solution in the base > that isn't working is not what I normally connect with OpenBSD. > > It would be helpful if the mount_tmpfs man page mentioned that it is no longer supported. Seems like that man page was last updated in November 16, 2014.
video(1) crashing on Lenovo B50
This is current/amd64 on a Lenovo B50 (dmesg below). The camera attaches as uvideo0 at uhub1 port 3 configuration 1 interface 0 "CKZEABCTH Lenovo EasyCamera" rev 2.00/0.04 addr 5 video0 at uvideo0 With the default install, after # chown myuser /dev/video* # sysctl kern.video.record=1 video(1) starts fine (under myuser), but crashes after 'f', i.e. entering full screen, saying $ video X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 12 (X_ConfigureWindow) Value in failed request: 0x0 Serial number of failed request: 71 Current serial number in output stream: 72 This happens in the default fvwm; but not in cwm, with a ~/.xsession file that says just cwm. Is that a video(1) bug? A fvwm(1) bug? How can I help debug this? Jan $ video -q video device /dev/video: encodings: yuy2 frame sizes (width x height, in pixels) and rates (in frames per second): 160x120: 30, 15 320x240: 30, 15 640x360: 30, 15 640x480: 30, 15 800x600: 15 1280x720: 8 controls: brightness, contrast, saturation, hue, gamma, sharpness, white_balance_temperature, backlight_compensation $ video -c brightness=50 contrast=50 saturation=50 hue=50 gamma=50 sharpness=50 white_balance_temperature=auto backlight_compensation=0 OpenBSD 7.0-beta (GENERIC.MP) #201: Mon Sep 6 06:26:18 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4158328832 (3965MB) avail mem = 4016304128 (3830MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xe6ec0 (54 entries) bios0: vendor LENOVO version "9CCN35WW(V3.01)" date 10/16/2015 bios0: LENOVO 20382 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP MSDM LPIT MCFG SSDT UEFI APIC SSDT UEFI HPET SSDT SSDT FPDT acpi0: wakeup devices XHC1(S3) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S3) RP04(S4) PXSX(S4) PWRB(S4) BRCM(S0) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Pentium(R) CPU N3540 @ 2.16GHz, 2167.08 MHz, 06-37-08 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,SENSOR,ARAT,MELTDOWN cpu0: 1MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 83MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Pentium(R) CPU N3540 @ 2.16GHz, 2166.68 MHz, 06-37-08 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,SENSOR,ARAT,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) Pentium(R) CPU N3540 @ 2.16GHz, 2166.68 MHz, 06-37-08 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,SENSOR,ARAT,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) Pentium(R) CPU N3540 @ 2.16GHz, 2166.69 MHz, 06-37-08 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,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,SENSOR,ARAT,MELTDOWN cpu3: 1MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 87 pins, remapped acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 3 (RP03) acpiprt4 at acpi0: bus 4 (RP04) acpiec0 at acpi0 acpicmos0 at acpi0 acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 "ETD0626" at acpi0 not configured "VPC2004" at acpi0 not configured acpibat0 at acpi0: BAT1 model "PABAS0241231" serial 41167 type Li-Ion oem "LENOVO " acpiac0 at acpi0: AC unit online acpibtn0 at acpi0: LID0 "DMA0F28" at acpi0 not configured acpibtn1 at acpi0: PWRB "BCM2E1A"
Re: Recover partition table/FFS2 after overwrite?
On 9/6/21 9:22 AM, Thomas Windisch wrote: I think I just overwrote my file system by using sd1 instead of sd2: # pv install69.img > /dev/rsd1c sd1 is softraid crypto device that holds the system partitions and data: $ df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/sd1a 1.9G143M1.7G 8%/ /dev/sd1f 843G734G 66.2G92%/home /dev/sd1b 9.7G 14.5M9.2G 0%/tmp /dev/sd1e 48.4G 40.8G5.2G89%/usr /dev/sd1d 19.4G 16.9G1.5G92%/var # disklabel sd1 # /dev/rsd1c: type: SCSI disk: SCSI disk label: SR CRYPTO duid: a1f07cee2aba3a55 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 121600 total sectors: 1953518528 boundstart: 64 boundend: 1953504000 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 4208960 64 4.2BSD 2048 16384 12960 # / b: 20980896 4209024 4.2BSD 2048 16384 12960 # /tmp c: 19535185280 unused d: 41945696 25189920 4.2BSD 2048 16384 12960 # /var e:104872320 67135616 4.2BSD 2048 16384 12960 # /usr f: 1781496064172007936 4.2BSD 8192 65536 52270 # /home The system is currently up and running. I'm not sure what has been overwritten. Possibly only sd1a /? Is it possible to recover from this without loosing access to the data in /home, /var, /usr? You may be in luck. Only the FDISK partition table, the BSD partition table, root, and /tmp are gone. This is what I'd do. Someone more knowledgeable could know better. Power the system down asap so that the system won't try to use the bad data. If you wrote onto the -encrypted- partition marked OpenBSD not the one holding it marked RAID in that drive's fdisk it's only painful. Install onto a -different- drive to make a rescue system. If you just nuked the -encrypted- partition, Go to part B. Otherwise, if you nuked the RAID partition: Part A: Boot the rescue system -c to disable softraid. Reset the fdisk partition table on the nuked drive. write a disklabel containing the RAID partition where the encrypted one lived. You must find someone who knows the softraid metadata. That person would have to tell you how to write -just- the metadata -only-. Reenable softraid on the rescue system. If necessary, reboot it. The encrypted disk should reappear. It has no structure. Use fdisk to establish the OpenBSD are. Use disklabel to reestablish your partitions. part B: On the encrypted partition: Use fdisk to make the OpenBSD area and disklabel to write the partition table. Mount and copy your precious data onto some other drive. Boot from bsd.rd Install on the partially recovered encrypted drive. The install program should recognize the rewritten partition table. Otherwise use a custom partition table matching your old one. Clear all the mount point names other than / and /tmp, That tells the install program to -not- newfs them. When rebooting at the end you may need to use -s to fix any custom configuration that needs to be done early. Fix the rest of your custom configuration once the system is up. Reinstall packages etc etc etc. With luck everything is back to normal. Little portable USB drives are $60 or so for 1 TB. Pretty large ones don't cost a lot more. This doesn't happen often but... maybe a page somewhere online? Geoff Steckel
Recover partition table/FFS2 after overwrite?
I think I just overwrote my file system by using sd1 instead of sd2: # pv install69.img > /dev/rsd1c sd1 is softraid crypto device that holds the system partitions and data: $ df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/sd1a 1.9G143M1.7G 8%/ /dev/sd1f 843G734G 66.2G92%/home /dev/sd1b 9.7G 14.5M9.2G 0%/tmp /dev/sd1e 48.4G 40.8G5.2G89%/usr /dev/sd1d 19.4G 16.9G1.5G92%/var # disklabel sd1 # /dev/rsd1c: type: SCSI disk: SCSI disk label: SR CRYPTO duid: a1f07cee2aba3a55 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 121600 total sectors: 1953518528 boundstart: 64 boundend: 1953504000 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 4208960 64 4.2BSD 2048 16384 12960 # / b: 20980896 4209024 4.2BSD 2048 16384 12960 # /tmp c: 19535185280 unused d: 41945696 25189920 4.2BSD 2048 16384 12960 # /var e:104872320 67135616 4.2BSD 2048 16384 12960 # /usr f: 1781496064172007936 4.2BSD 8192 65536 52270 # /home The system is currently up and running. I'm not sure what has been overwritten. Possibly only sd1a /? Is it possible to recover from this without loosing access to the data in /home, /var, /usr?
Re: Why is tmpfs not working on OpenBSD?
On Sun, Sep 05, 2021 at 10:12:33PM +, iio7 wrote: > > On 2021-09-05, iio7 < > i...@protonmail.com > > wrote: > >> # mount -t tmpfs tmpfs /home/foo/tmp/ > >> mount_tmpfs: tmpfs on /home/foo/tmp: Operation not supported > > > It isn't built into the standard kernels, disabled with this commit:: > > > revision 1.229 > > date: 2016/07/25 19:52:56 > > disable tmpfs because it receives zero maintainance. > > Why isn't it removed? It is kinda "misguiding". > There might be hope that someone who has the time would do proper maintenance...
Re: how handle freeze ?
On 5. 09. 21 17:41, Cord wrote: Hello, I have a stable openbsd69 installed on a raspberry 3b+. It freezes often especially when I'm connected to internet through a 4g usb modem. I'm connected to the rpi from linux by serial and ethernet ssh. There is not any log, kernel panic or message in console. thanks cord I'd suggest pasting a dmesg and isolating the culprit. Is the issue still happening without the 4G modem? What other devices are you using with the Pi? -- Kristjan Komloši
Re: Why is tmpfs not working on OpenBSD?
On Monday, September 6th, 2021 at 12:49 AM, Theo de Raadt wrote: > iio7 i...@protonmail.com wrote: > > > On Sunday, September 5th, 2021 at 10:41 PM, Theo de Raadt > > dera...@openbsd.org wrote: > > > > > iio7 i...@protonmail.com wrote: > > > > > > > > On 2021-09-05, iio7 < > > > > > > > > > > i...@protonmail.com > > > > > > > > > > wrote: > > > > > > > > > > > mount -t tmpfs tmpfs /home/foo/tmp/ > > > > > > === > > > > > > > > > > > > mount_tmpfs: tmpfs on /home/foo/tmp: Operation not supported > > > > > > > > > It isn't built into the standard kernels, disabled with this commit:: > > > > > > > > > revision 1.229 > > > > > > > > > > date: 2016/07/25 19:52:56 > > > > > > > > > > disable tmpfs because it receives zero maintainance. > > > > > > > > Why isn't it removed? It is kinda "misguiding". > > > > > > Shucks, you must feel terrible about our decision. > > > > Well, compared to the fact that you, back in 2016, wrote that, > > > > "We don't spend hours of our time adding unimportant notes to that file.", > > concerning updating the FAQ about this, maybe > > > > instead of giving these useless comments, that you apparently > > > > have got plenty of time to do, you should actually provide some > > > > kind of useful information somewhere! > > or we could decide we don't owe whiners like you anything > > and continue to focus only on what we want to do Sure, you do that while I cancel my financial support and then find something better to spend it on.
Re: Why is tmpfs not working on OpenBSD?
>> iio7 wrote: >>> instead of giving these useless comments, that you apparently >>> have got plenty of time to do, you should actually provide some >>> kind of useful information somewhere! > deraadt wrote: >> or we could decide we don't owe whiners like you anything >> and continue to focus only on what we want to do iio7 wrote: > Sure, you do that while I cancel my financial support and then > find something better to spend it on. How well do you think that threat will work for you when it didn't work for DARPA?
Re: xterm not opening on latest snapshot?
mkdir ~/.cache should get you get going again until xterm is fixed. On 6 September 2021 08:41:38 CEST, henkjan gersen wrote: >That indeed gives much more output, but not sure it gives more clarity >as it ends with this: > >-- >69930 xterm CALL mprotect(0xf4aab8c6000,0x1000,0x3) >69930 xterm RET mprotect 0 >69930 xterm CALL mprotect(0xf4aab8c6000,0x1000,0x169930 xterm RET mprotect 0 >69930 xterm CALL munmap(0xf4aab8c6000,0x1000) >69930 xterm RET munmap 0 >69930 xterm CALL exit(1) >77728 ksh PSIG SIGHUP SIG_DFL >-- >From the output just before this the only thing that stands out to me >is that it fails to find "/home/hge/.cache/fontconfig" as that returns >an error for the unveil call and the writing of "xterm: unveil" in the >.xsession-errors happens immediately after that. > >On Sun, 5 Sept 2021 at 20:44, Theo de Raadt wrote: >> >> It is setgid (privdrop) for utmp support, so ktrace stops reporting on >> what the program is doing. If you temporarily chmod your utmp file a+w, >> remove the setgid bit from the xterm binary, then you will likely be >> able to ktrace further to get closer to identifying the issue. >> >> henkjan gersen wrote: >> >> > Assuming I should run "ktrace -di xterm" it doesn't show any failure >> > condition at the end, i.e. the last lines from the kdump are >> > -- >> > 90075 ktrace NAMI "/usr/X11R6/bin/xterm" >> > 90075 ktrace ARGS >> > [0] = "xterm" >> > -- >> > To me that last line looks like the process launches successfully, yet >> > no xterm window shows. All errors that are shown before these lines >> > are because it tries to locate xterm in various system-folders until >> > it finds it in /usr/X11R6/bin >> > >> > @Dave: I'm running using snapshots, so it will take me some time to >> > get to the stage where I can try your diff. I haven't gone through >> > building xenocara before (aware that the FAQ describes how to do it). >> > >> > On Sun, 5 Sept 2021 at 15:12, Theo de Raadt wrote: >> > > >> > > henkjan gersen wrote: >> > > >> > > > On this mornings snapshot that I just upgraded to I can no longer open >> > > > an xterm window. Based on the .xsession-error this must be related to >> > > > the unveil capabilities that got added last week as I see "xterm: >> > > > unveil" appearing in that file. >> > > > >> > > > Can someone give a hint on what I'm missing to be able to open an >> > > > xterm window again? >> > > >> > > ktrace -di, and kdump >> > > >> > > The idea is to spot a failure condition near the end. >> > > >> > > -- Sent from a mobile device. Please excuse poor formatting.
Re: xterm not opening on latest snapshot?
That indeed gives much more output, but not sure it gives more clarity as it ends with this: -- 69930 xterm CALL mprotect(0xf4aab8c6000,0x1000,0x3) 69930 xterm RET mprotect 0 69930 xterm CALL mprotect(0xf4aab8c6000,0x1000,0x1From the output just before this the only thing that stands out to me is that it fails to find "/home/hge/.cache/fontconfig" as that returns an error for the unveil call and the writing of "xterm: unveil" in the .xsession-errors happens immediately after that. On Sun, 5 Sept 2021 at 20:44, Theo de Raadt wrote: > > It is setgid (privdrop) for utmp support, so ktrace stops reporting on > what the program is doing. If you temporarily chmod your utmp file a+w, > remove the setgid bit from the xterm binary, then you will likely be > able to ktrace further to get closer to identifying the issue. > > henkjan gersen wrote: > > > Assuming I should run "ktrace -di xterm" it doesn't show any failure > > condition at the end, i.e. the last lines from the kdump are > > -- > > 90075 ktrace NAMI "/usr/X11R6/bin/xterm" > > 90075 ktrace ARGS > > [0] = "xterm" > > -- > > To me that last line looks like the process launches successfully, yet > > no xterm window shows. All errors that are shown before these lines > > are because it tries to locate xterm in various system-folders until > > it finds it in /usr/X11R6/bin > > > > @Dave: I'm running using snapshots, so it will take me some time to > > get to the stage where I can try your diff. I haven't gone through > > building xenocara before (aware that the FAQ describes how to do it). > > > > On Sun, 5 Sept 2021 at 15:12, Theo de Raadt wrote: > > > > > > henkjan gersen wrote: > > > > > > > On this mornings snapshot that I just upgraded to I can no longer open > > > > an xterm window. Based on the .xsession-error this must be related to > > > > the unveil capabilities that got added last week as I see "xterm: > > > > unveil" appearing in that file. > > > > > > > > Can someone give a hint on what I'm missing to be able to open an > > > > xterm window again? > > > > > > ktrace -di, and kdump > > > > > > The idea is to spot a failure condition near the end. > > > > >
