Re: vmm computer freeze
Justin Yates Fletcher writes: > Hi all, > > Occasionally when I start a VM (Alpine v3.19) the host computer freezes > solid and requires a hard power off. > > It is not consistent but it does seem more stable when I have fewer > things running on the computer. If I have a desktop running, web > browser, video player, editor, etc. then starting a VM seems to cause > the freeze more often... I can't say that with certainty though but > maybe I am running into some kernel limit? > > The computer is running -current but the issue has been there since I > first installed OpenBSD on the computer with the 7.5 release. > > Any input on how to debug this? Or other pointers? The freeze could be the kernel panicking. If you're running X at the time, you will most likely not see the panic message or ddb prompt. If you're able to reproduce this consistently, try switching to another console (e.g. alt-ctrl-F1) and starting the vm there. That way if there's a panic you should see it and we can better dig into the issue. > > dmesg, vm.conf, and sysctl.conf attached. > I didn't see anything abnormal in dmesg or vm.conf. I'm not familiar with the sysv_shmem kernel stuff, so no idea if those settings make sense. -dv
Re: Debian 12 Under VMM
04-psyche.tot...@icloud.com writes:
> Hi all,
>
> I am trying to run Debian 12 under VMM.
>
> I can see on the email from 2024-04-02 that Bruce managed to make it work,
> but I don't know how.
>
> The crux of the issue is that the Debian ISO installer does not seem to work
> under serial console.
You need to modify the kernel boot args to disable video and rely on
serial console. I can't recall whatever the graphics arg is to the linux
kernel, but you typically want something like vga=off and then set the
console arg. I recommend setting both that and io_delay:
console=ttyS0,115200 io_delay=none
io_delay will make the kernel skip doing some pointless artificial
delays that don't matter with vmd.
>
> Here's what I did:
>
> /etc/vm.conf
>
> vm "vm1" {
> memory 1G
> disable
> cdrom "/isos/debian-12.5.0-amd64-netinst.iso"
> disk "/disks/disk_vm1.qcow2" format qcow2
> local interface
> }
>
> When I then start the vm, I am greeted with the message:
>
> "Press a key, otherwise speech synthesis will be started in 27 seconds..."
>
>
> and then after keypress
>
> "
> Undefined video mode number: 314
> Press to see video modes available, to continue, or wait 30
> sec
> "
>
> and it then crashes.
>
> Can anyone (maybe Bruce) point me in the right direction?
>
> Thanks!
> Jake
Re: Does anyone know whether this hardware runs OpenBSD?
Steve Litt writes: > Does anyone know whether this hardware runs OpenBSD? > > https://www.walmart.com/ip/MeLE-Quieter3Q-Fanless-Mini-PC-N5105-Windows-11-8GB-256GB-4K-UHD-Wifi-6-Mini-Desktop-Computer-New/2177929669 Maybe... Looking at: https://www.cnx-software.com/2022/06/03/mele-quieter3q-review-ultra-thin-fanless-mini-pc-tested-with-windows-11-ubuntu-22-04/ It seems to use components that should be supported. The wifi might work with iwx(4). Not sure about the mmc controller, so whatever works with that m.2 slot you might want to put in some storage that way. For anyone curious, that link has a dmesg from Ubuntu 22.04 on the machine in question. > > Thanks, > > SteveT > > Steve Litt > > Autumn 2023 featured book: Rapid Learning for the 21st Century > http://www.troubleshooters.com/rl21
update to virtio_vmmci for linux 6.6 guests in vmd
Just cut a new release to fix building virtio_vmmci [1] on Linux guests. This is my port of vmmci(4) to Linux to allow Linux guests in vmd(8) safely shutdown when stopping vmd and also synchronize/update their rtc's if you suspend/hibernate and then resume the host machine. Not to be confused with vmm_clock [2], which is a port of pvclock(2) and Linux's kvm-clock driver to provide paravirtualized clocksource. If you run a Linux guest with a 6.6 or newer kernel, try out the latest virtio_vmmci. If it doesn't compile, please ping me. Patches or PRs appreciated as well...but I don't watch GH activity much so be sure to ping me. -dv [1] https://github.com/voutilad/virtio_vmmci/releases/tag/0.6.0 [2] https://github.com/voutilad/vmm_clock
Re: vmd silently exits (after 7.4 upgrade)
Dave Voutila writes: > "Piotr K. Isajew" writes: > >> Hello, >> >> I'm observing this on one of my machines (which I seldom use >> nowadays) after upgrading it to 7.4. The machine had existing >> vm.conf setup which worked for me in the past. >> >> Now "rcctl start vmd" reports: >> vmd(ok) >> >> but just after that executing "vmctl status" gives: >> vmctl: connect: /var/run/vmd.sock: Connection refused >> >> and there is no vmd process running. >> >> When I try to start vmd from command line, it generates some >> output, but it is not really helpful in determining what could be >> the problem: >> >> /usr/sbin/vmd -d -v -v -v -v -v -v -v -v -v -v -v >> vmd: startup >> vmd: vm_register: registering vm 1 >> vmd: /etc/vm.conf:18: vm "lindev" registered (disabled) >> vmd: vmd_configure: setting staggered start configuration to parallelism: 4 >> and delay: 30 >> vmd: vmd_configure: starting vms in staggered fashion >> vmd: start_vm_batch: starting batch of 4 vms >> vmd: start_vm_batch: not starting vm lindev (disabled) >> vmd: start_vm_batch: done starting vms >> vmd: vmd: getgrnam > > Run sysmerge. You're missing the new _vmd group introduced in 7.4: > > $ grep vmd /etc/group > _vmd:*:107: > err...also check the agentx group. That is probably the actual missing group in this case: $ grep agentx /etc/group _agentx:*:92: >> vmd: exiting >> control: config_getconfig: control retrieving config >> control: control exiting, pid 33268 >> # priv: config_getconfig: priv retrieving config >> priv: priv exiting, pid 1161 >> vmm: config_getconfig: vmm retrieving config >> vmm: vmm exiting, pid 48824 >> >> >> dmesg excerpt >> OpenBSD 7.4 (GENERIC.MP) #2: Fri Dec 8 15:39:04 MST 2023 >> >> r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP >> cpu0: Intel(R) Xeon(R) CPU E31225 @ 3.10GHz, 3093.12 MHz, 06-2a-07, patch >> 002f >> 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN >> >> cpu0: using VERW MDS workaround (except on vmm entry) >> vmm0 at mainbus0: VMX/EPT
Re: vmd silently exits (after 7.4 upgrade)
"Piotr K. Isajew" writes: > Hello, > > I'm observing this on one of my machines (which I seldom use > nowadays) after upgrading it to 7.4. The machine had existing > vm.conf setup which worked for me in the past. > > Now "rcctl start vmd" reports: > vmd(ok) > > but just after that executing "vmctl status" gives: > vmctl: connect: /var/run/vmd.sock: Connection refused > > and there is no vmd process running. > > When I try to start vmd from command line, it generates some > output, but it is not really helpful in determining what could be > the problem: > > /usr/sbin/vmd -d -v -v -v -v -v -v -v -v -v -v -v > vmd: startup > vmd: vm_register: registering vm 1 > vmd: /etc/vm.conf:18: vm "lindev" registered (disabled) > vmd: vmd_configure: setting staggered start configuration to parallelism: 4 > and delay: 30 > vmd: vmd_configure: starting vms in staggered fashion > vmd: start_vm_batch: starting batch of 4 vms > vmd: start_vm_batch: not starting vm lindev (disabled) > vmd: start_vm_batch: done starting vms > vmd: vmd: getgrnam Run sysmerge. You're missing the new _vmd group introduced in 7.4: $ grep vmd /etc/group _vmd:*:107: > vmd: exiting > control: config_getconfig: control retrieving config > control: control exiting, pid 33268 > # priv: config_getconfig: priv retrieving config > priv: priv exiting, pid 1161 > vmm: config_getconfig: vmm retrieving config > vmm: vmm exiting, pid 48824 > > > dmesg excerpt > OpenBSD 7.4 (GENERIC.MP) #2: Fri Dec 8 15:39:04 MST 2023 > > r...@syspatch-74-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > cpu0: Intel(R) Xeon(R) CPU E31225 @ 3.10GHz, 3093.12 MHz, 06-2a-07, patch > 002f > 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,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > > cpu0: using VERW MDS workaround (except on vmm entry) > vmm0 at mainbus0: VMX/EPT
Re: Power usage in Dell XPS 17
Jag Talon writes: > I was wondering if I could get help with reducing power consumption on > my laptop. > > I have a Dell XPS 17 9700 that's newly running 7.4 (dmesg in > attachment) and previously it was running Fedora. Real-world usage > seems to have gone from 4 hrs to about 40 mins so I was wondering if > I'm missing anything: > > * I've tried using `apm -A`, `apm -L`, and `obsdfreqd` but any > improvement seems small. > > * I've tried lowering the resolution from 3840x2400 to 1680x1050, > which improved things a little bit, but not much. When `xenodm` or > `gdm` is not running it still gets pretty hot. > > * It still consumes a lot of power even when I'm not using it, so it > doesn't seem to be a CPU issue. > > Are there other things that I could try looking into? Does anyone have > experience with this laptop? > > I get the feeling that it could perhaps be the Nvidia GPU running in > the background even when it's unsupported? Is that possible? Can you disable that in the uefi/bios settings? There may also be other power settings in there to tweak. While OpenBSD doesn't have the fanciest power management, the firmware can still do something to throttle or change power states of systems.
Re: Clock stops working on OpenBSD qemu/kvm guest
Lévai, Dániel writes: > Turns out the clock stopped every night at the time when backups were > running and thus the VM was paused (saved, or 'managedsaved' if > someone uses libvirt) for a minute. > Not sure why, though; while I was testing pause/resume the clock > didn't stop, it just failed to get synced by ntpd(8). Maybe over time > the drift was too much? >From my experience, ntp daemons will try not to just jump the clock forward or backwards by too great an amount and instead increase or decrease time advancement to try to sync. It's indeed possible you drifted too far for ntpd to handle through this method. You might want to look into installing the Qemu guest agent in OpenBSD vms: https://marc.info/?l=openbsd-ports&m=158936392710472&w=2 Usually these agents handle properly setting the rtc after a suspend/resume cycle of the vm. (That's what the vmmci(4) driver does, for instance, in OpenBSD guests running atop OpenBSD's vmd(8).) > > Anyway, the rather curious thing was ntpd(8) not syncing the clock > properly after resume, so I ended up giving the 'trusted' option to > the server I'm using here. Strangely, it still took quite some time > [1], but in the end it managed to sync - so I guess this should work > in the long run. > > > [1] > Jan 30 11:50:33 ntpd[83421]: peer 148.6.0.1 now valid > Jan 30 11:54:37 ntpd[4758]: adjusting local clock by 23.831836s > Jan 30 11:54:37 ntpd[83421]: clock is now synced > Jan 30 11:54:37 ntpd[83421]: constraint reply from 9.9.9.9: offset 23.653130 > Jan 30 11:57:48 ntpd[4758]: adjusting local clock by 22.879877s > Jan 30 11:57:48 ntpd[83421]: clock is now unsynced > Jan 30 12:01:34 ntpd[4758]: adjusting local clock by 21.754396s > Jan 30 12:04:51 ntpd[4758]: adjusting local clock by 20.774539s > Jan 30 12:08:33 ntpd[4758]: adjusting local clock by 19.670413s > Jan 30 12:12:43 ntpd[4758]: adjusting local clock by 18.426017s > Jan 30 12:17:04 ntpd[4758]: adjusting local clock by 17.127167s > Jan 30 12:21:19 ntpd[4758]: adjusting local clock by 15.857846s > Jan 30 12:21:53 ntpd[4758]: adjusting local clock by 15.688043s > Jan 30 12:25:30 ntpd[4758]: adjusting local clock by 14.613690s > Jan 30 12:29:49 ntpd[4758]: adjusting local clock by 13.323883s > Jan 30 12:33:32 ntpd[4758]: adjusting local clock by 12.204646s > Jan 30 12:34:06 ntpd[4758]: adjusting local clock by 12.036162s > Jan 30 12:35:10 ntpd[4758]: adjusting local clock by 11.712658s > Jan 30 12:36:13 ntpd[4758]: adjusting local clock by 11.412870s > Jan 30 12:39:55 ntpd[4758]: adjusting local clock by 10.308062s > Jan 30 12:43:34 ntpd[4758]: adjusting local clock by 9.208613s > Jan 30 12:44:07 ntpd[4758]: adjusting local clock by 9.048595s > Jan 30 12:47:48 ntpd[4758]: adjusting local clock by 7.950845s > Jan 30 12:49:27 ntpd[4758]: adjusting local clock by 7.460912s > Jan 30 12:53:08 ntpd[4758]: adjusting local clock by 6.360250s > Jan 30 12:56:22 ntpd[4758]: adjusting local clock by 5.385971s > Jan 30 12:56:53 ntpd[4758]: adjusting local clock by 5.241883s > Jan 30 13:01:13 ntpd[4758]: adjusting local clock by 3.951414s > Jan 30 13:04:22 ntpd[4758]: adjusting local clock by 3.009970s > Jan 30 13:07:05 ntpd[4758]: adjusting local clock by 2.201024s > Jan 30 13:11:18 ntpd[4758]: adjusting local clock by 0.937320s > Jan 30 13:12:22 ntpd[4758]: adjusting local clock by 0.613777s > Jan 30 13:13:27 ntpd[4758]: adjusting local clock by 0.285335s > Jan 30 13:14:32 ntpd[83421]: clock is now synced
Re: Clock stops working on OpenBSD qemu/kvm guest
Lévai, Dániel writes: > Hi all! > > I have this OpenBSD 7.4 qemu/kvm VM managed by libvirt on an Ubuntu 22.04 > host. > > I started to notice this month that it started to act weird, it seems > like the clock stops every night. I couldn't pinpoint exactly what > caused the change in behavior, the host had two package updates that > raised suspicion: > 2024-01-11 06:51:04 upgrade linux-image-generic-hwe-22.04:amd64 > 6.2.0.39.40~22.04.16 6.5.0.14.14~22.04.7 > 2024-01-12 09:10:36 upgrade libvirt-daemon:amd64 8.0.0-1ubuntu7.7 > 8.0.0-1ubuntu7.8 > > But none of the changelogs /seemed/ relevant. > > Anyway, the symptoms are funny, it always involves the clock stopping/not > working after some period of time. > > When this happens, I cannot login with SSH. The ssh client connects, > it even asks for the private key, but after confirmation it times out. > > The really funny things happen when I log in on the console - that I can do: > > When I try to ping anything from the host, it stops after the first > successful packets (echo/reply) and then hangs (I can CTRL+C). > Interestingly I can ping the VM from the hypervisor host indefinitely, > but running tcpdump on the guest doesn't show anything immediately. In > fact, looking at tcpdump while doing *anything* network related on the > VM or to the VM doesn't result in any output right away. > That being said, after a couple of minutes, output from tcpdump starts > to flood the screen but I cannot say exactly why or when, it just > suddenly happens. > > Running `sleep 1` just hangs. > > When I run `date` consecutively it shows: > Fri Jan 26 04:20:42 CET 2024 > Fri Jan 26 04:20:39 CET 2024 > Fri Jan 26 04:20:40 CET 2024 > Fri Jan 26 04:20:41 CET 2024 > Fri Jan 26 04:20:42 CET 2024 > Fri Jan 26 04:20:43 CET 2024 > Fri Jan 26 04:20:41 CET 2024 > Fri Jan 26 04:20:42 CET 2024 Definitely should not be seeing time moving backwards. That's not good. > > It always works again after a reboot - forced reset, because it cannot shut > down gracefully. > > Originally I was using SP kernel but tried with MP recently too, just out of > curiosity - no luck. > > I found two old posts seemingly related: > https://marc.info/?t=15294229612&r=1&w=2 > ^^ I don't have that sysctl on the host and that kernel is very old there. > What is your Linux kernel version? > https://www.reddit.com/r/openbsd/comments/13c9nh1/clock_issue_with_vmm_guest_on_73/ > This is on an OpenBSD host, so I can't try that sysctl either. > > This has been set on the guest, though (defaults): > kern.timecounter.tick=1 > kern.timecounter.timestepwarnings=0 > kern.timecounter.hardware=pvclock0 > kern.timecounter.choice=i8254(0) pvclock0(1500) acpitimer0(1000) > > So pvclock should be relying on KVM to properly deal with TSC paravirtualzation. Do you see this issue with Linux guests using kvmclock? (Or do your Linux guests decide on a different clocksource?) > Any clues would be appreciated, > Daniel > > > dmesg: > OpenBSD 7.4 (GENERIC.MP) #1397: Tue Oct 10 09:02:37 MDT 2023 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 519929856 (495MB) > avail mem = 484507648 (462MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5960 (10 entries) > bios0: vendor SeaBIOS version "1.15.0-1" date 04/01/2014 > bios0: QEMU Standard PC (i440FX + PIIX, 1996) > acpi0 at bios0: ACPI 1.0 > acpi0: sleep states S5 > acpi0: tables DSDT FACP APIC WAET > acpi0: wakeup devices > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: 12th Gen Intel(R) Core(TM) i7-12700K, 3609.77 MHz, 06-97-02 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,SSBD,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 4MB > 64b/line 16-way L2 cache, 16MB 64b/line 16-way L3 cache > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 1000MHz > cpu1 at mainbus0: apid 1 (application processor) > cpu1: 12th Gen Intel(R) Core(TM) i7-12700K, 3609.78 MHz, 06-97-02 > cpu1: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,VMX,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,SHA,UMIP,PKU,WAITPKG,MD_CLEAR,IBRS,IBPB,STIBP,SS
Re: getpath from a file descriptor
bi...@iscarioth.org writes: > Hello, dear OpenBSD's devs. I hope everything works well for you. I'm > here to ask (maybe) a question that can displease you. > > Working on some projects, I saw a lot of them using fcntl(fd, > F_GETPATH) like MacOs/NetBSD do, or proc with a famous symlink to > the file path (but procfs has been removed). Does OpenBSD have a > syscall for receiving the path from a file descriptor ? No. See this previous conversation from 2 years ago when this last came up in the mailing lists. claudio@ sums it up: https://marc.info/?l=openbsd-tech&m=164250539119078&w=2 > > If not, how can I get them in a other way ? > If not possible, do you planning to implements F_GETPATH, ? > > have a good days ! > Best Regards, Bilal.
Re: Run VM with 16G or more?
"Kirill A. Korinsky" writes: > [[PGP Signed Part:Undecided]] >> On 2. Jan 2024, at 18:41, Dave Voutila wrote: >> "Kirill A. Korinsky" writes: > >>> vmctl -v start... doesn't help a bit >> >> How much physicaly memory does the host machine have? We currently don't >> allow oversubscribing memory with vmm/vmd. If the host only has 16GB >> that could be the cause. > > hw.physmem=137257779200 > hw.usermem=133537726464 > > and machine is used only for run VMs. > >> If that's not the case, can you run vmd in debug mode and get the log >> output? > > Sure, I run /usr/sbin/vmd -vvv -d and the error is: > > vmd: config_setvm: vm 3 restarted after 9.757221 seconds, limit 0/3 > vmd: config_setvm: can't open tap tap Ah, that. > vmd: failed to start vm podman > vmd: vm_stop: vmd config_setvm stopping vm 3 > > This machine runs 4 more VM and this one (huge) should be 5th. Try this: # cd /dev && sh MAKEDEV tap4 By default I believe on amd64 we create tap[0-3]. You might need to define additional special files to represent 4+ taps. -dv
Re: Run VM with 16G or more?
"Kirill A. Korinsky" writes: >> On 2. Jan 2024, at 12:07, Kirill A. Korinsky wrote: >> >> Confirmed that it is: >> >> island$ grep '^vmd:' -A 2 /etc/login.conf >> vmd:\ >> :datasize=16384M:\ >> :tc=daemon: >> island$ > > > Wel.. after that changes error has been changed to: > >> vmctl: start vm command failed: Unknown error: -1 yeah that error description sucks...should be changed > > > vmctl -v start... doesn't help a bit How much physicaly memory does the host machine have? We currently don't allow oversubscribing memory with vmm/vmd. If the host only has 16GB that could be the cause. If that's not the case, can you run vmd in debug mode and get the log output?
Re: Appimage
Kevin Chadwick writes: > I'm not sure if this is a pipe dream but atleast I imagine the filesystem API > and /proc avoidance is likely possible. > Depends on what you're smoking in said pipe. > "https://github.com/AppImage/AppImageKit/issues/98";
Re: VMs not rebooting
"Robert B. Carleton" writes:
> I have a number virtual machines, and I've noticed that they power off
> instead of rebooting when using "shutdown -r now" on the guest. This is
> the general form for a configuration in the /etc/vm.conf:
>
> vm "batch2" {
> memory 2G
> enable
> cdrom /home/ISO/OpenBSD/7.4/install74.iso
> disk /home/vm/batch2/disk0.qcow2
> boot device disk
Stab in the dark, but try removing the "boot device disk" line as well
as the cdrom one. Does it still behave like that?
There's a sneaky edge case where we don't handle a reboot. claudio@
bugged me about it awhile back but I've been slow to dig into it.
> interface { switch "int_switch" }
> interface { switch "ext_switch" }
> }
>
> I also tried running vmd from the command line with "-d -vv". Here's the
> end of the logging when I tried to reboot the guest:
>
> vm/batch2: vcpu_exit_eptviolation: fault already handled
> vm/batch2: vcpu_exit_eptviolation: fault already handled
> vm/batch2: vcpu_exit_eptviolation: fault already handled
> vm/batch2: vmmci_ack: vm 7 requested shutdown
> vm/batch2: virtio_shutdown: waiting on device pid 35337
> vm/batch2: virtio_dispatch_dev: pipe dead (EV_READ)
> vm/batch2: virtio_shutdown: device for pid 35337 is stopped
> vm/batch2: virtio_shutdown: waiting on device pid 64912
> vm/batch2: virtio_shutdown: device for pid 64912 is stopped
> vm/batch2: virtio_shutdown: waiting on device pid 34607
> vm/batch2: virtio_shutdown: device for pid 34607 is stopped
> vmm: vmm_sighdlr: handling signal 20
> vmm: vmm_sighdlr: terminated vm batch2 (id 1)
> vmm: vm_remove: vmm vmm_sighdlr removing vm 1 from running config
> vmm: vm_stop: vmm vmm_sighdlr stopping vm 1
> vmd: vm_stop: vmd vmd_dispatch_vmm stopping vm 1
>
> The three "vcpu_exit_eptviolation: fault already handled" lines seemed
> to happen continuously during run time for the guest.
>
> Is there some kind of configuration that I'm missing? I read the vmctl,
> and vm.conf man pages. I also looked at the examples in
> /etc/examples. Nothing stood out, so far.
>
> I'm running OpenBSD 7.4 on the hypervisor and guests. Any suggestions?
>
> PS: Overall, using vmm has been a good experience. I'm pretty happy with
> it.
Re: What could cause high CPU load averages (no actual CPU usage)?
Mike Fischer writes: > I have been observing occasional bouts of high load averages on > several servers I administer and I am trying to find the cause. (I > monitor these machines so that I can implement corrective measures in > case of any malicious or abnormal activity. I think this is benign, > but I’d still like to find the cause.) > > Once the high load average starts, only a reboot seems to (temporarily) > return the values to their normal levels. > > The actual CPU usage (as measured by vmstat) stays low even if the load > average is elevated. > > The servers are VMs running on a VMWare host (ESXi). This was seen with > OpenBSD 7.3 and 7.4 amd64. > > I can not determine anything inside the VM that causes this. There > seems to be no correlation to pfstat(8) graphs, log entries, known > events, or anything else I can determine. restarting all of the rc.d > services never made any difference. > > Could this be caused by something on the VMWare host machine? (The > host seems to be operating at limit regarding RAM for example. But the > VM is only using the normal percentage of its allocated RAM — way > below 100% and very constant usage, no swap.) > > How can I further debug this, keeping in mind that these are production > machines and experimentation is limited to benign things that don’t cause > outages. > Can you share a dmesg of one of the 7.4 vm? The output of `vmstat -iz` might help narrow it down to a stuck interrupt. Also, try running systat(1) and observe things as they happen.
Re: Lenovo Thinkpad T14 Gen3 very slow on MP kernel, faster on GENERIC
Stuart Henderson writes: > On 2023-10-17, Comète wrote: >> Hi, >> >> Wow ! you're absolutely right ! If I unplug, no lagg anymore. >> So the solution should be to apply your patch and rebuild the kernel ? > > It's certainly worth trying. If you do, please report back here. > I have a particular Lenovo machine (AMD Ryzen-based, though) that routinely suffers from some perf throttling I think (guessing) in the bios or hardware itself. Usually a complete shutdown and plugging and unplugging the power gets it to start working as expected. Until then it's dog slow showing now reason why (pretty sure apm shows a normal cpu frequency and there's no interrupt storm). I would not be surprised if that's the same problem reported here. It happens enough to be mildly annoying, but not enough (and it's not my daily driver) that I have dug into it further beyond just the power cycle. Is it kernel state? Bios? /shrug
Re: vmd and /dev/sd*
Manuel Giraud writes: > Mike Larkin writes: > >> On Thu, Oct 12, 2023 at 09:24:33AM -0600, Theo de Raadt wrote: >>> Manuel Giraud wrote: >>> >>> > > Manuel Giraud writes: >>> > > >>> > >> Hi, >>> > >> >>> > >> I can't find the information on this list (or elsewhere). Is it >>> > >> possible to have a vm that access a disk through its device? The >>> > >> following does not seem to work: >>> > >> >>> > >> # vmctl start -cL -m 1G -b /bsd.rd -d /dev/sd1c myvm >>> > >> vmctl: start vm command failed: Unknown error: -1 >>> > > >>> > > No, passing file descriptors to devices over ipc sockets isn't currently >>> > > allowed by the kernel. You'd need to use the raw character device, too, >>> > > afaik if passing them were allowed. >>> > >>> > Ok, noted. BTW I have the same error passing the raw character device. >>> >>> >>> >>> I made the decision to not allow passing of weird file descriptor types >>> very intentionally. I'm still very sure that is the right decision. >>> >>> Here's 1 program which wants to do it, but the other 1000 pledge'd programs >>> are being protected from being passed an incorrect fd and then doing system >>> calls upon it which behave "different". By that, I mean seek, read, and >>> write short-operation behaviours are subtly different outside of files and >>> sockets, and it would also expose some ioctl (which is MOSTLY limited by >>> pledge, but ioctl "request" values are just numbers, and they can overlap in >>> surprising ways). >>> >> >> I would like to make clear that vmd does not "want to do it", and that I >> agree >> that the current design of not being able to pass these types of fds is >> correct. It may be slightly inconvient for certain niche use cases, but not >> worth weakening everything else or putting in hacks. Just dd the device you >> want to a .raw file and use that. > > Thanks for making that clear. I do not understand all the security > implications but you do :) Maybe to prevent future request, you could > have a more explicit error message. I agree reporting "Unknown error" is unhelpful. I don't think having something specific to people trying to use devices instead of files is worth the effort as none of the documentation should be implying that's a feature.
Re: vmd and /dev/sd*
Manuel Giraud writes: > Hi, > > I can't find the information on this list (or elsewhere). Is it > possible to have a vm that access a disk through its device? The > following does not seem to work: > > # vmctl start -cL -m 1G -b /bsd.rd -d /dev/sd1c myvm > vmctl: start vm command failed: Unknown error: -1 No, passing file descriptors to devices over ipc sockets isn't currently allowed by the kernel. You'd need to use the raw character device, too, afaik if passing them were allowed. > > What would be the alternatives? None I know of.
Re: OpenBSD 7.3 found a process with PID 0
Alessandro Baggi writes: > Hi list, > running this python3 script: > > #!/usr/bin/env python3 > import psutil > > pids = psutil.pids() > for i in pids: > p = psutil.Process(i) > with p.oneshot(): > print(str(i) + " " + p.name()) > > The result start with: > > 0 swapper > 1 init > 536 smtpd > 868 ksh > ... > > This process does not appear in ps, top and htop. You need to display kernel threads. $ ps -p 0 -H PID TID TT STATTIME COMMAND 0 10 ?? DK 0:01.04 (swapper) > > How could be that there is a process with PID 0 before init? > Probably I'm missing something about OpenBSD core. > > Can someone point me in the right direction? > > Thank you in advance. > > Alessandro.
Re: Panic during 7.3 installation on VM
Alessandro Baggi writes: > Hi list, > I'm trying to install OpenBSD 7.3 on a VM (Linux KVM) but when it > starts to install sets I got panic and "syncing disk... 8 8 8 8 ..." > until it reboot automatically. Can you share the panic and backtrace? > > This is a simple installation, no disk encryption, default OpenBSD layout... > Please share the exact settings or the dmesg from booting the vm. > The VM has VNC Server as "graphic" instead of spice, disk is SATA and > it has fixed allocation. > > Someone can put me in the right direction? > > Thank you in advance.
Re: desire for journaled filesystem
John Holland writes: > I just had a kernel panic when reloading a firefox tab pointed at > facebook. After restarting, all the filesystems had errors but /home > was particularly bad and caused the boot to stop and prompt if I > wanted to enter a root shell. > > > I eventually got fsck to mark the /home filesystem clean but it found >>4000 lost files that it moved to lost&found. I am not so experienced > with this, running "file" on a few of them shows that they may be > intact files but they have numeric names now. > > > I've really been enjoying OpenBSD but I think it could really use a > journaled filesystem. I believe I have the correct options in fstab > for the best results: > > 1f08fbc2b303f0ef.k /home ffs rw,softdep,noatime,nodev,nosuid 1 2 You don't mention what version you're running, but I would say don't run with softdep if you prefer data safety over "performance." It's effectively a no-op in -current IIRC. So if you're on 7.3 or earlier, ditch it. > > > I was just thinking how much I was enjoying OpenBSD compared to some > others when this happened. > > > OpenZFS? License issues? Hammer? Anything?
Re: non-hardware 2fa options for openssh
Daniel Jakots writes: > On Tue, 29 Aug 2023 10:07:18 -0500, "myml...@gmx.com" > wrote: > >> Hi All, >> >> I want to secure an openssh server with two factor authentication and >> have seen the hardware token methods, most recently i've been seeing >> yubi/FIDO methods. >> >> Ideally I would like to avoid having to depend on a usb size device >> that could easily be lost. > > Using something based on TOTP (Cf. rfc6238) is probably your best bet > then. > >> I looked around and found mention of google authenticator as an >> option, phones aren't much bigger than usb sticks but people protect >> their phone as if it was their soul, but the newest mention I can >> find is many years old. > > AFAIK, google authenticator is simply an app doing the math for TOTP. > There are multiple basic opensource apps (on both Android and iphones) > which can provide you with the right TOTP based on the seed/secret. > > And if you don't want to use a phone, you can use oathtool(1) from > security/oath-toolkit. > I think some password managers also are able to generate the TOTP. > >> My question is there any recent documentation / information on setting >> up an openssh server with non-hardware based two factor >> authentication? This does NOT have to be google authenticator, any >> similar service will suffice. > > login_totp(8), login.conf(5), sshd_config(5), and maybe a couple of > others. > > You can also want to look at sysutils/login_oath (which I've been using > for years), but maybe for new setups, the login_totp from base makes > more sense. > login_totp is in base?
Re: Immutable Page Protections
Justin Handville writes: > I'm assuming that misc@ is probably the best place for this e-mail, > although it gets a bit in the tech@ weeds. I upgraded to 7.3 not so > long ago, and I noticed that a daemon I had written was no longer > working properly. For reasons that are probably too much to get into > here, I statically link the daemon. It's a single binary that makes use > of pledge / unveil, and privilege separation. This all works fine. It > also has another trick, which unfortunately no longer works in 7.3. > > To reduce the code footprint of this daemon as well as the potential > gadget attack surface, I have it drop any code that it will no longer > execute. This happens after fork / exec on a child, and also after > initialization code executes before the child process enters its steady > state. This is trivially done by grouping functions into custom page > aligned sections in the ELF binary, and running mprotect on these > sections with PROT_NONE. I considered munmap as well as other tricks, > but so far, this seems to be the most portable way to handle this trick > that I could think of between BSD and Linux. I'm sure others are more > clever. It's a cheap defense in depth protection that simplifies my use > case. Have you considered a libexec approach instead? If the goal is to keep a child process having only the executable pages it needs for operations, why not split up the program design instead of mucking with ELF stuff? That surely has to be even more portable. > > As of OpenBSD 7.3, when the immutable flag entered mainstream, this > trick no longer works. Given that my trick is a total hack, I'm not too > broken up about it. Of course, this change led me to doing some poking > around. > > I noticed that in sys/uvm/uvm_map.c, an exception was granted to allow > Chrome to drop the write flag for a region for userland compatibility. > That makes sense as a temporary measure. I'm wondering, however, if it > might not make sense to think about this functionality differently. > Instead of immutable memory regions, why can't we consider a more > pledge-like ratcheting for memory regions, where bits can be removed, > but never added back? How does this impact the gadget attack surface > that led to the immutable flag being considered to begin with? > > For the time being, I extended the exception in uvm_map.c on my own > OpenBSD systems to allow immutable regions to be stripped of all > protection flags with a call to mprotect. So, in addition to allowing RW > to R, if the region is any combination of PROT_READ, PROT_WRITE, or > PROT_EXEC, then it can be reduced to PROT_NONE. This seemed the safer > option for patching for now. Of course, this further breaks the > definition of "immutable", but at least immutable regions can only have > protection bits removed. > > My reason for mailing misc@ is just to bring up this data point from a > single user. I'm certain that the OpenBSD developers have reasons for > preferring a pure immutable flag, but having a mechanism for ratcheting > down protections is useful at least for me, and is apparently useful > enough in userland going from RW to R, that an exception was carved out > for now. Of course, I'm more than happy to work with the developers to > come up with a plan for upstreaming this feature if it's something > useful. If not, I have no problem adding it to my personal list of > patches I maintain that I doubt anyone else would want or need. > > - Justin
Re: Hibernation on Thinkpad Carbon X1 gen 7 - unhibernate failed
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
Re: support of thinkpad arm
BESSOT Jean-Michel writes: > Hello > > I wish to know if the last thinkpad arm will be supported by openbsd > before buying one. > > here the computer: > https://www.lenovo.com/fr/fr/p/laptops/thinkpad/thinkpadx/thinkpad--x13s-(13-inch-snapdragon)/len101t0019 > > what do you know about this ? > A few of us have them, including myself. It's fine if you're looking to hack on arm64 stuff but probably not a great daily driver as we currently lack support for wifi and accelerated graphics. You'd really need to follow -current. If this isn't want you're looking for in a system I would not recommend it currently. -dv
Re: 7.3 vmm/vmd shutdown page flush behavior?
not jacinda ardern writes: > Perhaps it's just me, but upon upgrading to 7.3, I noticed that when VMs > shut down, there appears to be a flurry of disk activity right after the > VM OS shuts down, which seems like page flushing of mapped and/or cached > pages. I seem to also not recall as high a value for cached memory usage > in 7.2, but perhaps I just never really looked before. Pretty sure you mean -current and you're following snapshots, right? If so, I just introduced changes to resolve this that may not be in the latest snaps yet. If you're seeing this on a 7.3-stable/release system, I'd be a bit surprised. -dv
Re: Issues booting alpine linux > 3.5 on vmm - openbsd7.2
Dave Voutila writes:
> di...@santanas.co.za writes:
>
>> Hi OpenBSD friends,
>>
>> Just a report, not sure if it's helpful, but @voutilad requested [1] I
>> send the details to the mailing list.
>>
>> I have seen a few reports online[1][2], about some users not being able to
>> boot newer alpine linux versions (and other linux OS' in my
>> experience). Specifically I've seen the last version that boots is
>> 3.5.3.
>>
>> My system is openbsd 7.2 on my hardware Lenovo ThinkPad E14 Gen 4
>> laptop.
>>
>> The issue, when the alpine linux VM boots, it kernel panics.
>>
>> [0.052602]local IPI:
>> [0.052602] invalid opcode: [#1] SMP PTI
>> [0.052602] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.79-0-virt
>> #1-Alpine
>> [0.052602] Hardware name: OpenBSD VMM, BIOS 1.14.0p0-OpenBSD-vmm
>> 01/01/2011
>> [0.052602] RIP: 0010:delay_halt_tpause+0xd/0x20
>> [ 0.052602] Code: 75 fb 48 ff c8 31 c0 31 ff c3 cc cc cc cc 66 66 2e
> 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 8d 04 37 31 c9 48 89 c2 48 c1
> ea 20 <66> 0f ae f1 31 c0 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc 53 48
> c7
>
> The key issue here is the invalid opcode error coming from the
> instruction starting with 66 0f ae, which is a TPAUSE
> instruction. Hence the RIP pointing to "delay_halt_tpause" in the Linux
> kernel.
>
> I don't think I have any newer Intel hardware that supports the "User
> Wait" instructions (aka WAITPKG). My Intel research says it premiered in
> Tremont, Alder Lake, Sapphire Rapids so I can't test locally, but the
> docs from Intel (SDM Vol. 2B 4-719) say:
>
> Prior to executing the TPAUSE instruction, an operating system may
> specify the maximum delay it allows the processor to suspend its
> operation. It can do so by writing TSC-quanta value to the
> following 32-bit MSR (IA32_UMWAIT_CONTROL at MSR index E1H)...
>
> We probably should be masking the CPUID value for TPAUSE in the values
> vmm(4) communicates via vmm_handle_cpuid.
>
>
The below diff defines the cpuid bit for detecting the WAITPKG
feature. It adds the value to vmm's cpuid mask and also updates the
i386/amd64 cpu identification info.
Can someone with a newer Intel system try this out?
diff refs/heads/master refs/heads/vmm-tsleep
commit - 515b7b0d87d9ff8cd5eae1449555f3d6e625fa49
commit + 6343cff9c1cfbbf9ba2cb06cfeca507caa06fc8c
blob - 001a437045be145322be30288c1f47d63fb07634
blob + 0bd908e273a1c0e6324e1bc9f8c8ca921555c86f
--- sys/arch/amd64/amd64/identcpu.c
+++ sys/arch/amd64/amd64/identcpu.c
@@ -208,6 +208,7 @@ const struct {
{ SEFF0ECX_AVX512VBMI, "AVX512VBMI" },
{ SEFF0ECX_UMIP,"UMIP" },
{ SEFF0ECX_PKU, "PKU" },
+ { SEFF0ECX_WAITPKG, "WAITPKG" },
}, cpu_seff0_edxfeatures[] = {
{ SEFF0EDX_AVX512_4FNNIW, "AVX512FNNIW" },
{ SEFF0EDX_AVX512_4FMAPS, "AVX512FMAPS" },
blob - cbde6cf9b02fc882a8ed17aa6adb5c43249e0302
blob + b26bd32e2d9ea7386b1f58960dea40b787d6a341
--- sys/arch/amd64/include/specialreg.h
+++ sys/arch/amd64/include/specialreg.h
@@ -201,6 +201,7 @@
#define SEFF0ECX_AVX512VBMI0x0002 /* AVX-512 vector bit inst */
#define SEFF0ECX_UMIP 0x0004 /* UMIP support */
#define SEFF0ECX_PKU 0x0008 /* Page prot keys for user mode */
+#define SEFF0ECX_WAITPKG 0x0010 /* UMONITOR/UMWAIT/TPAUSE insns */
/* SEFF EDX bits */
#define SEFF0EDX_AVX512_4FNNIW 0x0004 /* AVX-512 neural network insns */
#define SEFF0EDX_AVX512_4FMAPS 0x0008 /* AVX-512 mult accum single prec */
blob - 6b4802abf4b508495cdbc961bd799d3fa83b9c36
blob + bbe10bd4cfd7e778132eca1d97594e10513ac172
--- sys/arch/amd64/include/vmmvar.h
+++ sys/arch/amd64/include/vmmvar.h
@@ -672,7 +672,12 @@ struct vm_mprotect_ept_params {
SEFF0EBX_AVX512IFMA | SEFF0EBX_AVX512PF | \
SEFF0EBX_AVX512ER | SEFF0EBX_AVX512CD | \
SEFF0EBX_AVX512BW | SEFF0EBX_AVX512VL)
-#define VMM_SEFF0ECX_MASK ~(SEFF0ECX_AVX512VBMI)
+/*
+ * Copy from host minus:
+ * AVX-512 vector bit (SEFF0ECX_AVX512VBMI)
+ * UMONITOR/UMWAIT/TPAUSE (SEFF0ECX_WAITPKG)
+ */
+#define VMM_SEFF0ECX_MASK ~(SEFF0ECX_AVX512VBMI | SEFF0ECX_WAITPKG)
/* EDX mask contains the bits to include */
#define VMM_SEFF0EDX_MASK (SEFF0EDX_MD_CLEAR)
blob - 310208ac4cdb262aaedfa9b78d869fd5911607b2
blob + ccf1164fd658a69dc383e1602ae0ce1f269de4e4
--- sys/arch/i386/i386/machdep.c
+++ sys/arch/i386/i386/machdep.c
@@ -1038,6 +1038,7 @@ const struct cpu_cpuid_feature cpu_seff0_ecxfeatures[]
{ SEFF0ECX_UMIP,"UMIP" },
{ SEFF0ECX_AVX512VBMI, "AVX512VBMI" },
{ SEFF0ECX_PKU, "PKU" },
+ { SEFF0ECX_WAITPKG
Re: Issues booting alpine linux > 3.5 on vmm - openbsd7.2
di...@santanas.co.za writes:
> Hi OpenBSD friends,
>
> Just a report, not sure if it's helpful, but @voutilad requested [1] I
> send the details to the mailing list.
>
> I have seen a few reports online[1][2], about some users not being able to
> boot newer alpine linux versions (and other linux OS' in my
> experience). Specifically I've seen the last version that boots is
> 3.5.3.
>
> My system is openbsd 7.2 on my hardware Lenovo ThinkPad E14 Gen 4
> laptop.
>
> The issue, when the alpine linux VM boots, it kernel panics.
>
> [0.052602]local IPI:
> [0.052602] invalid opcode: [#1] SMP PTI
> [0.052602] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.79-0-virt
> #1-Alpine
> [0.052602] Hardware name: OpenBSD VMM, BIOS 1.14.0p0-OpenBSD-vmm
> 01/01/2011
> [0.052602] RIP: 0010:delay_halt_tpause+0xd/0x20
> [0.052602] Code: 75 fb 48 ff c8 31 c0 31 ff c3 cc cc cc cc 66 66 2e 0f 1f
> 84 00 00 00 00 00 0f 1f 40 00 48 8d 04 37 31 c9 48 89 c2 48 c1 ea 20 <66> 0f
> ae f1 31 c0 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc 53 48 c7
The key issue here is the invalid opcode error coming from the
instruction starting with 66 0f ae, which is a TPAUSE
instruction. Hence the RIP pointing to "delay_halt_tpause" in the Linux
kernel.
I don't think I have any newer Intel hardware that supports the "User
Wait" instructions (aka WAITPKG). My Intel research says it premiered in
Tremont, Alder Lake, Sapphire Rapids so I can't test locally, but the
docs from Intel (SDM Vol. 2B 4-719) say:
Prior to executing the TPAUSE instruction, an operating system may
specify the maximum delay it allows the processor to suspend its
operation. It can do so by writing TSC-quanta value to the
following 32-bit MSR (IA32_UMWAIT_CONTROL at MSR index E1H)...
We probably should be masking the CPUID value for TPAUSE in the values
vmm(4) communicates via vmm_handle_cpuid.
> [0.052602] RSP: :abb88000be58 EFLAGS: 00010207
> [0.052602] RAX: 0400ed7bcebe RBX: 0400ed7bc48a RCX:
>
> [0.052602] RDX: 0400 RSI: 0a34 RDI:
> 0400ed7bc48a
> [0.052602] RBP: 0a34 R08: R09:
>
> [0.052602] R10: R11: R12:
> 000f423f
> [0.052602] R13: 34f08bbb5552eaa2 R14: 7d508ff23393eff5 R15:
> 49ec817d3937
> [0.052602] FS: () GS:93e07e60()
> knlGS:
> [0.052602] CS: 0010 DS: ES: CR0: 80050013
> [0.052602] CR2: 93e04c801000 CR3: 0c00a000 CR4:
> 00150eb0
> [0.052602] Call Trace:
> [0.052602]
> [0.052602] delay_halt+0x36/0x60
> [0.052602] test_nmi_ipi.constprop.0+0xce/0x147
> [0.052602] dotest.constprop.0+0x1e/0xf2
> [0.052602] nmi_selftest+0x9b/0x213
> [0.052602] native_smp_cpus_done+0x4c/0x10e
> [0.052602] kernel_init_freeable+0x1bd/0x369
> [0.052602] ? rest_init+0xc0/0xc0
> [0.052602] kernel_init+0x11/0x120
> [0.052602] ret_from_fork+0x22/0x30
> [0.052602]
> [0.052602] Modules linked in:
> [0.052618] ---[ end trace 710ae769548b59b6 ]---
> [0.054142] RIP: 0010:delay_halt_tpause+0xd/0x20
> [0.055698] Code: 75 fb 48 ff c8 31 c0 31 ff c3 cc cc cc cc 66 66 2e 0f 1f
> 84 00 00 00 00 00 0f 1f 40 00 48 8d 04 37 31 c9 48 89 c2 48 c1 ea 20 <66> 0f
> ae f1 31 c0 31 d2 31 c9 31 f6 31 ff c3 cc cc cc cc 53 48 c7
> [0.061264] RSP: :abb88000be58 EFLAGS: 00010207
> [0.062602] RAX: 0400ed7bcebe RBX: 0400ed7bc48a RCX:
>
> [0.062602] RDX: 0400 RSI: 0a34 RDI:
> 0400ed7bc48a
> [0.062614] RBP: 0a34 R08: R09:
>
> [0.064880] R10: R11: R12:
> 000f423f
> [0.067126] R13: 34f08bbb5552eaa2 R14: 7d508ff23393eff5 R15:
> 49ec817d3937
> [0.069334] FS: () GS:93e07e60()
> knlGS:
> [0.071885] CS: 0010 DS: ES: CR0: 80050013
> [0.072602] CR2: 93e04c801000 CR3: 0c00a000 CR4:
> 00150eb0
> [0.072602] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b
> [0.072602] ---[ end Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x000b ]---
>
> my vm.conf
>
> vm "docker" {
> disable
> memory 1G
> cdrom "/home/ds/vms/alpine-virt-3.17.0-x86_64.iso"
> disk "/home/ds/vms/docker.img"
> local interface
> }
>
>
> My dmesg is below[3].
>
> I have attempted below actions, however they haven't made any difference:
> - try debian-11.6.0-amd64-netinst.iso. It doesnt panic, that I can
> see, but seems to freeze right at the beginning.
> - pass "console=/dev/ttyS0,115200" to the kernel command line arguments.
> - boot my system with default sysctl values.
>
> @voutilad
Re: vmm(4)/vmd(8) trouble: vmd exits with proc_dispatch msgbuf_write error
"Theo de Raadt" writes:
>> vmd: getgrnam
>> parent: proc_dispatch: msgbuf_write: Broken pipe
>
> Your /etc/group file is out of date.
>
> And this code in vm_agentx.c is very unreasonable:
>
> /*
> * Make sure we can connect to /var/agentx/master with the correct
> * group permissions.
> */
> if ((grp = getgrnam(AGENTX_GROUP)) == NULL)
> fatal("getgrnam");
>
> It's crazy; people who are not using that stuff should not pay the price.
Agreed. If martijn@ isn't available to fix/relax this I'll write
something up later this week.
Re: vmm(4)/vmd(8) trouble: vmd exits with proc_dispatch msgbuf_write error
"matthew j weaver" writes: > Howdy, all. > > I'm at my wit's end and am hoping somebody can spot what I'm > overlooking. > > I cannot get vmd to run on some hardware which seems like it should > support virtualization. CPU is an Intel(R) Core(TM) i5-7200U (full dmesg > is below my message). > > sietchtabr# dmesg|grep vmm > cpu0: using VERW MDS workaround (except on vmm entry) > vmm0 at mainbus0: VMX/EPT > > > Here's my minimum representation -- I've worked backwards to no vm.conf > in an attempt to make sure it's not my configuration which causes vmd to > exit shortly after startup. I see the same behavior with various > configuration files, including the one from /etc/exmaples: > > sietchtabr# dmesg | egrep '(VMX/EPT|SVM/RVI)' > vmm0 at mainbus0: VMX/EPT > vmm0 at mainbus0: VMX/EPT > sietchtabr# doas fw_update > fw_update: added none; updated none; kept athn,intel,inteldrm,vmm > sietchtabr# doas syspatch > sietchtabr# doas vmd -dvvv > startup > failed to open /etc/vm.conf: No such file or directory > vmd_configure: setting staggered start configuration to parallelism: 2 > and delay: 30 > vmd_configure: starting vms in staggered fashion > start_vm_batch: starting batch of 2 vms > start_vm_batch: done starting vms > vmd: getgrnam This looks to be coming from vm_agentx.c. What does this look like on your machine? $ group info _agentx name_agentx passwd * gid 92 members If that group is missing, how did you install or update to 7.2? > parent: proc_dispatch: msgbuf_write: Broken pipe > config_getconfig: control retrieving config > control exiting, pid 61440 > priv exiting, pid 51297 > vmm exiting, pid 49736 > sietchtabr# > > What I am missing or what might be my next steps to investigate? I'm > baffled. > > cheers > weaver > > > OpenBSD 7.2 (GENERIC.MP) #0: Wed Oct 26 12:01:47 MDT 2022 > > r...@syspatch-72-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 34256113664 (32669MB) > avail mem = 33200508928 (31662MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x8d317000 (86 entries) > bios0: vendor American Megatrends Inc. version "5.12" date 07/08/2019 > bios0: Protectli FW6 > acpi0 at bios0: ACPI 6.1 > acpi0: sleep states S0 S5 > acpi0: tables DSDT FACP APIC FPDT MCFG SSDT FIDT SSDT HPET SSDT SSDT UEFI > SSDT LPIT WSMT SSDT SSDT SSDT SSDT DBGP DBG2 DMAR ASF! > acpi0: wakeup devices PS2K(S0) PS2M(S0) RP09(S0) PXSX(S0) RP10(S0) PXSX(S0) > RP11(S0) PXSX(S0) RP12(S0) PXSX(S0) RP13(S0) PXSX(S0) RP01(S0) PXSX(S0) > RP02(S0) PXSX(S0) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, 2394.42 MHz, 06-8e-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,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 > cpu0: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 4-way L2 cache, 3MB 64b/line 12-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) i5-7200U CPU @ 2.50GHz, 2394.43 MHz, 06-8e-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,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 > cpu1: 32KB 64b/line 8-way D-cache, 32KB 64b/line 8-way I-cache, 256KB > 64b/line 4-way L2 cache, 3MB 64b/line 12-way L3 cache > cpu1: smt 0, core 1, package 0 > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins > acpimcfg0 at acpi0 > acpimcfg0: addr 0xe000, bus 0-255 > acpihpet0 at acpi0: 2399 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (PEG0) > acpiprt2 at acpi0: bus -1 (PEG1) > acpiprt3 at acpi0: bus -1 (PEG2) > acpiprt4 at acpi0: bus -1 (RP09) > acpiprt5 at acpi0: bus -1 (RP10) > acpiprt6 at acpi0: bus -1 (RP11) > acpiprt7 at acpi0: bus -1 (RP12) > acpiprt8 at acpi0: bus -1 (RP13) > acpiprt9 at acpi0: bu
updated vmm support modules for older Linux guests
I finally got around to slapping more hacky #ifdef's onto my vmm_clock [1] and virtio_vmmci [2] Linux kernel modules because I found older Linux kernel versions (~3.10 era) didn't support compiling them. If you host things like CentOS 7 guests under vmm(4)/vmd(8), I recommend trying them out and opening a GitHub issue in the respective project if there's something wrong. (PR's welcome.) No idea what I'm talking about? * virtio_vmmci - Linux port of vmmci(4) that helps signal reboots/rtc sync with Linux guests via vmctl(8) and vmd(8). * vmm_clock - duct-taped version of kvmclock to work with vmm(4)'s pvclock(4) paravirtualized clock. -dv [1] https://github.com/voutilad/virtio_vmmci [2] https://github.com/voutilad/vmm_clock
Re: VM(D) Interface Question
Holger Glaess writes: > Hi > > > how many Interfaces can an single VM have ? > > > With 3 Interface in my vm.conf the vm works, with 4 not i get "to many > interfaces". > The maximum supported per vm is currently 4. Without your config or invocation triggering the "too many interfaces" when you use 4, I cannot explain any further. Debug output would also be helpful to make sure it's the message coming from the config parsing as I suspect. -dv
Re: whither struct __kvm?
"Lyndon Nerenberg (VE7TFX/VE6BBM)" writes: > The first declaration in is: > > typedef struct __kvm kvm_t; > > and yet 'grep -r __kvm /usr/include /sys' returns only the above > line. What am I missing? > Since you don't say what you're expecting to *see* I'm not sure how to tell you what you aren't seeing. Let's assume you want to know about where the struct comes from and what uses it... man 3 kvm Do you even have a source tree checked out to /usr/src? See /usr/src/lib/libkvm. -dv
Re: Lenovo IdeaPad 3 14ITL05 EST turbo mode
Mikhail writes: > Recently I've bought subject laptop, but it had an issue - when I was > doing git clone of a any huge tree, like linux kernel, it shut down in > the beginning of 'Resolving deltas' stage. I'd tested Debian 11 and > OpenBSD (current) - Debian shut down almost immediately, OpenBSD was > working randomly but about ~3 minutes. > > Service guys set up Windows 10 on it and git clone worked fine there, > they also did AIDA64 stress testing for a day, and I'd tested latest > Ubuntu 22.04.1 and it worked without the issue. I did some digging and > came up with this commit: > > --- > commit 086aa750ab8f1698a6c6eaafe1458279776ce66d > from: tb > date: Wed Aug 11 18:15:50 2021 UTC > > Make hw.setperf percentages proportional to the enhanced speed step > frequencies on intel processors. This way, the default hw.setperf=99 > corresponds to the maximum ordinary speed while setting it to 100 > enables turbo mode. > > Tested in snaps for a week, positive feedback from several. > > M sys/arch/amd64/amd64/est.c > --- > > Apparently setperf was set to 100, and if the CPU works in that "turbo > mode" for long enough it overheats and shuts down (sensors shows > temperature of ~100C while in 'Resolving deltas'). > > Work around was to set: > hw.perfpolicy=manual > hw.setperf=99 > > I was watching how Windows 10 behaves and noticed that when CPU > intensive thing starts - it boosts CPU for 100% for about 5 seconds and > then drops it to 85% and continue to work in this mode till the end of > the task. > > My previous laptop is around 12 years old, so I don't follow how modern > HW in this segment works, I was told that current laptops can work in > high speed mode only for a while, and then they should back to normal > speeds, otherwise behavior is unpredictable (as with this one). > > I'd like to know from your experience - is that shitty cooling design > from Lenovo, or the OSes should be more careful about setting turbo > mode? Since the commit is 1 year old and no one complained, I assume > it's first, but would like to know opinion of the list. Both, imo. My Surface Go3 exhibits this, so if I'm compiling a kernel or running a high-cpu process for more than 30s or so I manualy setperf to ~45-55 otherwise it overheats and the firmware does a safety shutoff. Some folks as well as myself have experimented with implementing more "modern" HWP support but from my experience doing so it's not a silver bullet in these thermal situations. Intel's SDM isn't very clear, to me, on how much faith we can put into the cpu to self-regulate and it's clear from looking at other OS's they have to use thermal sensors to do some self-regulation. Diffs have floated around, but it's not a simple problem to solve, unfortunately. And while Intel does it one way...AMD has their own conventions. We also don't generally have concensus on the actual problem we want to solve. Some folks care about battery life. I care about thermal issues and don't want something burning a hole through my lap and killing itself in the process. This leads to too many knobs and dials in everyone's proposed diffs. so the tl;dr: any passively cooled mobile Intel chipsets these days are really a gamble and the hw vendors are punting responsibility to os developers to account for their lack of cooling. -dv
Re: cpus spinning using three or more pipes in a chain
Stuart Henderson writes:
> On 2022-08-15, gwes wrote:
>> Unexpected behavior:
>> When I try to chain three programs together with pipes moving lots
>> of data spin time goes up on most or all CPUs.
>> Is this known or expected?
>>
>> the chain [shortened] was
>> find /someplace -maxdepth 2 -type f -name '*.flac' -exec \
>> metaflac -list --block-type=VORBIS_COMMENT {} + | \
>> awk '{mangle}' | \
>> sed -e 's/foo/bar/' | \
>> sort -o outfile
>>
>> On a slow (1.6GHz 8GB) system with an SSD the spin times went
>> as high as 50% on all cpus. When that happens the sys times
>> also go very high rendering the system effectively
>> unusable. Swap space used = 0.
>> That system is no longer available for testing.
>>
>> This is a simplified example on a Ryzen 3600G w/64MB ram & reasonable
>> rotating rust:
>> The test file is 3.6G
>> Under some test cases the spin times go as high as 20% on two or three CPUs
>> simultaneously. Those are transient and hard to capture.
>> I can rerun this using -CURRENT if that would give better information.
>>
>> Rsults have been more or less the same 6.9, 7.0, 7.1
>>
>> 11881$ cat m2abc.txz m2abc.txz m2abc.txz | cat | cat | cat > xx
>
> -current looks similar. (I catted /bsd a few times to make a test file,
> in this case the filesystem is on softraid crypto over nvme).
>
> CPU0: 0.0% user, 0.0% nice, 45.1% sys, 15.7% spin, 23.5% intr, 15.7% idle
> CPU1: 0.0% user, 0.0% nice, 33.3% sys, 41.2% spin, 0.0% intr, 25.5% idle
> CPU2: 2.0% user, 0.0% nice, 39.2% sys, 23.5% spin, 0.0% intr, 35.3% idle
> CPU3: 2.0% user, 0.0% nice, 29.4% sys, 27.5% spin, 0.0% intr, 41.2% idle
> Memory: Real: 5172M/15G act/tot Free: 654M Cache: 6685M Swap: 22M/2048M
>
> "yes | cat | cat | cat > xx" doesn't hit it.
>
> Don't know if it gives any clues but a flamegraph generated while
> running the multiple cat pipe on my laptop looks like
> https://junkpile.org/cat-spin-flame.svg
_kernel_lock() was in 24% of the samples. If you add up the spin you get
about 90%, which is ~24% of 400%...the max possible sum of spin across 4
cpus.
Comes from the dofilereadv() -> vn_read() -> _kernel_lock() chain.
I think that explains why your `yes | cat...` example doesn't hit
it. I'm not on/near a machine with btrace available to generate a
flamegraph for that example but curious what it looks like.
-dv
Re: Mutt cannot sent mail in OpenBsd
wim writes: > Hi everybody, > > I have this weird issue. > I can read the mails with mutt on openbsd but when I want to sent I > get this message from the mutt log: > [2022-07-08 14:33:16] mutt_send_message() Sending message... > [2022-07-08 14:33:16] raw_socket_open() Looking up mail.thinkerwim.org... > [2022-07-08 14:33:16] raw_socket_open() Connecting to > mail.thinkerwim.org... > [2022-07-08 14:33:16] ssl_negotiate() SSL failed: > error:14FFF086:SSL routines:(UNKNOWN)SSL_internal:certificate verify > failed > [2022-07-08 14:33:16] smtp_open() Could not negotiate TLS connection > > From the OPENSMTPD maillog I find this > Jul 8 14:33:16 thinkerwim smtpd[86584]: f5be1a0080460e5e smtp > connected address=46.23.92.40 host=mail.thinkerwim.org > Jul 8 14:33:16 thinkerwim smtpd[86584]: f5be1a0080460e5e smtp > disconnected reason="io-error: handshake failed: error:1403F416:SSL > routines:ACCEPT_SR_FINISHED:sslv3 alert certificate unknown" > > > The weird thing is , if I run the same configuration of mutt on my > linux machine everything works. > You might want to rethink your definition of "works" in this case. > Any idea ? > You sure you've configured a certificate and TLS on your mailserver? I don't see one. I a TLS listener on port :443 of mail.thinkerwim.org but that cert is for www.thinkerwim.org. $ openssl s_client -showcerts -servername mail.thinkerwim.org -connect mail.thinkerwim.org:587 CONNECTED(0003) 14696819295368:error:1400442E:SSL routines:CONNECT_CR_SRVR_HELLO:tlsv1 alert protocol version:/usr/src/lib/libssl/tls13_lib.c:151: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 5 bytes and written 322 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.3 Cipher: Session-ID: Session-ID-ctx: Master-Key: Start Time: 1657288016 Timeout : 7200 (sec) Verify return code: 0 (ok) ---
Re: Latest -current boots very slow in VM
Mischa writes: > Hi All, > > Just updated one of my -current test VMs to the snapshot of June 30. > The boot process takes extremely long. As soon as it's booting: > > ### > Using drive 0, partition 3. > Loading.. > probing: pc0 com0 mem[638K 3838M 4352M a20=on] > disk: hd0+ >>> OpenBSD/amd64 BOOT 3.53 > \ > com0: 115200 baud > switching console to com0 >>> OpenBSD/amd64 BOOT 3.53 > boot> > NOTE: random seed is being reused. > booting hd0a:/bsd: 15590680+3761168+305600+0+1167360 > [1158148+128+1222128+926180]=0x1705860 > entry point at 0x81001000 > ### > > The above is all normal speed, and after this point all characters are > printed at the speed of around 1 second per character. > For example printing the below in the console: > > ### > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights > reserved. > Copyright (c) 1995-2022 OpenBSD. All rights reserved. > https://www.OpenBSD.org > > OpenBSD 7.1-current (GENERIC) #574: Thu Jun 30 12:08:08 MDT 2022 > ### > > Took around 4-5 minutes. > After: > > ### > cpu0: Intel(R) Xeon(R) CPU E5-2667 v3 @ 3.20GHz, 3200.02 MHz, 06-3f-02 > ### > > It's speeding up a little. > > The host itself runs 7.1-stable, and there are 11 other VMs (running > 7.1-stable). > The previou release was an older -current without any issues. > On hardware it boots normal. Anything obvious I am missing? > What does the guest vmd process look like? Is the cpu% in top showing it's very busy? Is it just serial console that's slow on the guest? (If you connect via ssh, is it normal?) -dv
Re: Framework laptop fails to enter sleep/suspend/hibernate
Andrew W writes: > Not sure what else to try but I can't seem to get sleep/suspend to work on > my frame.work laptop. I've tried OpenBSD 7.0 and 7.1 now, running off a 1TB > USB drive. S4/Hibernation is not supported when swap is on a USB disk. I haven't read the suspend code paths lately, but I wouldn't be susprised if this is a problem as well. > > Running apm -S or apm -z the screen goes blank and the keyboard remains > backlit, eventually the fan starts spinning faster. I need to long press > the power button to force shutdown the machine. Hibernate says it's not > supported, which is a bit less of a concern to me but having one of them > working would be very helpful. > > I've tried w/o X running, same results. I don't see any failures related to > the TPM in dmesg but also I've tried w/ it set to "hidden" in the bios, > same result. > > I'm new to OpenBSD so maybe I'm missing something important to get this > working but I haven't seen much in the way of configuration related to this > functionality? Can you try with your root and swap partitions on your nvme disk and not on USB? Barring that, capturing all your machine details with sendbug(1) would be helpful. -dv
Re: reordering libraries: fdcresult: overrun
rtw0 dtw0 writes: > Hi, > When my OpenBSD vm boots I receive the following message: > > *reordering libraries: fdcresult: overrun* > Vm version, host version, etc. etc. Not enough info here. There was an issue address in vmm(4) that caused noise from the fdc(4) driver, but that was fixed in November and will be in 7.1 once released. https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/amd64/vmm.c?rev=1.295&content-type=text/x-cvsweb-markup -dv
Re: Thinkpad T480 high cpu after zzz
at pci0 dev 29 function 2 "Intel 100 Series PCIE" rev 0xf1: msi > pci8 at ppb7 bus 61 > nvme0 at pci8 dev 0 function 0 "Intel NVMe" rev 0x03: msix, NVMe 1.3 > nvme0: INTEL SSDPEKKF256G8L, firmware L15P, serial PHHH8520066K256B > scsibus1 at nvme0: 2 targets, initiator 0 > sd0 at scsibus1 targ 1 lun 0: > sd0: 244198MB, 512 bytes/sector, 500118192 sectors > pcib0 at pci0 dev 31 function 0 "Intel 200 Series LPC" rev 0x21 > "Intel 100 Series PMC" rev 0x21 at pci0 dev 31 function 2 not configured > azalia0 at pci0 dev 31 function 3 "Intel 200 Series HD Audio" rev 0x21: msi > azalia0: codecs: Realtek ALC257, Intel/0x280b, using Realtek ALC257 > audio0 at azalia0 > ichiic0 at pci0 dev 31 function 4 "Intel 100 Series SMBus" rev 0x21: > apic 2 int 16 > iic0 at ichiic0 > em0 at pci0 dev 31 function 6 "Intel I219-V" rev 0x21: msi, address > e8:6a:64:f6:3b:a9 > isa0 at pcib0 > isadma0 at isa0 > pckbc0 at isa0 port 0x60/5 irq 1 irq 12 > pckbd0 at pckbc0 (kbd slot) > wskbd0 at pckbd0: console keyboard > pms0 at pckbc0 (aux slot) > wsmouse0 at pms0 mux 0 > wsmouse1 at pms0 mux 0 > pms0: Synaptics clickpad, firmware 8.16, 0x1e2b1 0x940300 0x33cc40 > 0xf016a3 0x12e800 > pcppi0 at isa0 port 0x61 > spkr0 at pcppi0 > vmm0 at mainbus0: VMX/EPT > efifb at mainbus0 not configured > uhub0: port 3, set config 0 at addr 2 failed > uhub0: device problem, disabling port 3 > ugen0 at uhub0 port 7 "Intel Bluetooth" rev 2.00/0.10 addr 2 > uvideo0 at uhub0 port 8 configuration 1 interface 0 "Azurewave > Integrated Camera" rev 2.01/17.11 addr 3 > video0 at uvideo0 > ugen1 at uhub0 port 9 "Synaptics product 0x009a" rev 2.00/1.64 addr 4 > umass0 at uhub0 port 15 configuration 1 interface 0 "Generic > USB3.0-CRW" rev 3.00/2.04 addr 5 > umass0: using SCSI over Bulk-Only > scsibus2 at umass0: 2 targets, initiator 0 > sd1 at scsibus2 targ 1 lun 0: removable > serial.0bda031650103090 > vscsi0 at root > scsibus3 at vscsi0: 256 targets > softraid0 at root > scsibus4 at softraid0: 256 targets > root on sd0a (139b9fe31154e28e.a) swap on sd0b dump on sd0b > inteldrm0: 1920x1080, 32bpp > wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation), using wskbd0 > wsdisplay0: screen 1-5 added (std, vt100 emulation) > iwm0: hw rev 0x230, fw ver 36.ca7b901d.0, address 48:89:e7:99:be:25 > > > tail -f /var/log/messages & zzz > > Mar 14 18:28:23 ashen apmd: system suspending > Mar 14 18:28:23 ashen apmd: battery status: high. external power > status: connected. estimated battery life 100% > Mar 14 18:28:25 ashen /bsd: ugen0 detached > Mar 14 18:28:26 ashen /bsd: video0 detached > Mar 14 18:28:26 ashen /bsd: uvideo0 detached > Mar 14 18:28:27 ashen /bsd: ugen1 detached > Mar 14 18:28:28 ashen /bsd: sd1 detached > Mar 14 18:28:28 ashen /bsd: scsibus2 detached > Mar 14 18:28:29 ashen /bsd: umass0 detached > Mar 14 18:28:35 ashen /bsd: uhub0 detached > Mar 14 18:28:35 ashen /bsd: uhub1 detached > Mar 14 18:28:35 ashen /bsd: uhub0 at usb0 configuration 1 interface 0 > "Intel xHCI root hub" rev 3.00/1.00 addr 1 > Mar 14 18:28:35 ashen /bsd: uhub1 at usb1 configuration 1 interface 0 > "Intel xHCI root hub" rev 3.00/1.00 addr 1 > Mar 14 18:28:35 ashen /bsd: ugen0 at uhub0 port 3 "Generic EMV > Smartcard Reader" rev 2.01/1.20 addr 2 > Mar 14 18:28:46 ashen /bsd: ugen0: setting configuration index 0 failed > Mar 14 18:28:46 ashen /bsd: ugen1 at uhub0 port 7 "Intel Bluetooth" > rev 2.00/0.10 addr 3 > Mar 14 18:28:47 ashen /bsd: > drm:pid91513:intel_ddi_sanitize_encoder_pll_mapping *NOTICE* [drm] > [ENCODER:94:DDI \M-j/PHY h] is disabled/in DSI mode with an ungated > DDI clock, gate it > Mar 14 18:28:47 ashen /bsd: > drm:pid91513:intel_ddi_sanitize_encoder_pll_mapping *NOTICE* [drm] > [ENCODER:102:DDI \M-j/PHY h] is disabled/in DSI mode with an ungated > DDI clock, gate it > Mar 14 18:28:47 ashen /bsd: > drm:pid91513:intel_ddi_sanitize_encoder_pll_mapping *NOTICE* [drm] > [ENCODER:116:DDI \M-j/PHY h] is disabled/in DSI mode with an ungated > DDI clock, gate it > Mar 14 18:28:47 ashen apmd: system resumed from sleep > Mar 14 18:28:47 ashen apmd: battery status: high. external power > status: connected. estimated battery life 100% > Mar 14 18:28:48 ashen /bsd: uvideo0 at uhub0 port 8 configuration 1 > interface 0 "Azurewave Integrated Camera" rev 2.01/17.11 addr 4 > Mar 14 18:28:48 ashen /bsd: video0 at uvideo0 > Mar 14 18:28:49 ashen /bsd: ugen2 at uhub0 port 9 "Synaptics product > 0x009a" rev 2.00/1.64 addr 5 > Mar 14 18:28:50 ashen /bsd: umass0 at uhub0 port 15 configuration 1 > interface 0 "Generic USB3.0-CRW" rev 3.00/2.04 addr 6 > Mar 14 18:28:50 ashen /bsd: umass0: using SCSI over Bulk-Only > Mar 14 18:28:50 ashen /bsd: scsibus2 at umass0: 2 targets, initiator 0 > Mar 14 18:28:50 ashen /bsd: sd1 at scsibus2 targ 1 lun 0: SD/MMC, 1.00> removable serial.0bda031650103090 -- -Dave Voutila
Re: login.conf daemon datasize limit effects on VMs with 4GB+ RAM
"Ted Unangst" writes:
> On 2022-02-25, Robert Nagy wrote:
>> Maybe we need a default vmd class? What do you guys think?
>
> Regardless of what the limit is, this seems like a daemon where people
> will bump into the limit. Perhaps a reminder is in order too?
>
The reminder is good, but we still need to fix the problem that the vmm
process can abort given the child dies so quickly. On my machine, the
call to read(2) results in a zero byte read, tripping the existing fatal
path.
diff ff838b72f50de699ee43d3dac58ff7e8435669ee /usr/src
blob - 4c6c99f1133cec7cb1e38dfd22e595e4d2023842
file + usr.sbin/vmd/vm.c
--- usr.sbin/vmd/vm.c
+++ usr.sbin/vmd/vm.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -292,8 +293,12 @@ start_vm(struct vmd_vm *vm, int fd)
ret = alloc_guest_mem(vcp);
if (ret) {
+ struct rlimit lim;
+ const char *msg = "could not allocate guest memory - exiting";
+ if (getrlimit(RLIMIT_DATA, &lim) == 0)
+ msg = "could not allocate guest memory (data limit is
%llu) - exiting";
errno = ret;
- fatal("could not allocate guest memory - exiting");
+ fatal(msg, lim.rlim_cur);
}
ret = vmm_create_vm(vcp);
blob - eb75b4c587884ec43704420ef4172386a5b39bd9
file + usr.sbin/vmd/vmm.c
--- usr.sbin/vmd/vmm.c
+++ usr.sbin/vmd/vmm.c
@@ -616,6 +616,7 @@ vmm_start_vm(struct imsg *imsg, uint32_t *id, pid_t *p
int ret = EINVAL;
int fds[2];
size_t i, j;
+ ssize_t sz;
if ((vm = vm_getbyvmid(imsg->hdr.peerid)) == NULL) {
log_warnx("%s: can't find vm", __func__);
@@ -674,9 +675,13 @@ vmm_start_vm(struct imsg *imsg, uint32_t *id, pid_t *p
}
/* Read back the kernel-generated vm id from the child */
- if (read(fds[0], &vcp->vcp_id, sizeof(vcp->vcp_id)) !=
- sizeof(vcp->vcp_id))
+ sz = read(fds[0], &vcp->vcp_id, sizeof(vcp->vcp_id));
+ if (sz < 0)
fatal("read vcp id");
+ else if (sz != sizeof(vcp->vcp_id)) {
+ log_warn("failed to read vcp id");
+ goto err;
+ }
if (vcp->vcp_id == 0)
goto err;
Re: acpi0: sleep states S0 S3 S5, was: S0 S3 S4 S5
Try the next snap. I believe a diff slipped in temporarily. -dv > On Feb 18, 2022, at 11:38, Marcus MERIGHI wrote: > > Hello! > > I'm not sure this should go to bugs@. > > On three machines that I upgraded to the latest snapshot > yesterday, "S4" vanished: > > -acpi0: sleep states S0 S3 S4 S5 > +acpi0: sleep states S0 S3 S5 > > These are all amd64. > > Dmesgs below, seperated by "-". > > Marcus > > - Shuttle Inc. DS57U > > OpenBSD 7.0-current (GENERIC.MP) #361: Thu Feb 17 01:50:24 MST 2022 >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 16031678464 (15289MB) > avail mem = 15528607744 (14809MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec2f0 (82 entries) > bios0: vendor American Megatrends Inc. version "1.06" date 03/04/2015 > bios0: Shuttle Inc. DS57U > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! > SLIC SSDT SSDT SSDT DMAR > acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) > PEGP(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) > PXSX(S4) RP05(S4) PXSX(S4) [...] > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i5-5200U CPU @ 2.20GHz, 2494.65 MHz, 06-3d-04 > 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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu0: 256KB 64b/line 8-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 99MHz > 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) i5-5200U CPU @ 2.20GHz, 2494.23 MHz, 06-3d-04 > 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,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN > cpu1: 256KB 64b/line 8-way L2 cache > cpu1: smt 0, core 1, package 0 > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins > acpimadt0: bogus nmi for apid 0 > acpimadt0: bogus nmi for apid 2 > acpimcfg0 at acpi0 > acpimcfg0: addr 0xf800, bus 0-63 > acpihpet0 at acpi0: 14318179 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (PEG0) > acpiprt2 at acpi0: bus -1 (PEG1) > acpiprt3 at acpi0: bus -1 (PEG2) > acpiprt4 at acpi0: bus 1 (RP01) > acpiprt5 at acpi0: bus -1 (RP02) > acpiprt6 at acpi0: bus 2 (RP03) > acpiprt7 at acpi0: bus 3 (RP04) > acpiprt8 at acpi0: bus -1 (RP05) > acpiprt9 at acpi0: bus -1 (RP06) > acpiprt10 at acpi0: bus -1 (RP07) > acpiprt11 at acpi0: bus -1 (RP08) > acpiec0 at acpi0: not present > acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 > com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 3: ns16550a, 16 byte fifo > com1 at acpi0 UAR2 addr 0x2f8/0x8 irq 4: ns16550a, 16 byte fifo > acpicmos0 at acpi0 > acpibtn0 at acpi0: SLPB > acpibtn1 at acpi0: PWRB > "PNP0C0B" at acpi0 not configured > "PNP0C0B" at acpi0 not configured > "PNP0C0B" at acpi0 not configured > "PNP0C0B" at acpi0 not configured > "PNP0C0B" at acpi0 not configured > acpicpu0 at acpi0: C2(500@67 mwait.1@0x10), C1(1000@1 mwait.1), PSS > acpicpu1 at acpi0: C2(500@67 mwait.1@0x10), C1(1000@1 mwait.1), PSS > acpipwrres0 at acpi0: PG00, resource for PEG0 > acpipwrres1 at acpi0: PG01, resource for PEG1 > acpipwrres2 at acpi0: PG02, resource for PEG2 > acpipwrres3 at acpi0: FN00, resource for FAN0 > acpipwrres4 at acpi0: FN01, resource for FAN1 > acpipwrres5 at acpi0: FN02, resource for FAN2 > acpipwrres6 at acpi0: FN03, resource for FAN3 > acpipwrres7 at acpi0: FN04, resource for FAN4 > acpitz0 at acpi0: critical temperature is 105 degC > acpitz1 at acpi0: critical temperature is 105 degC > acpivideo0 at acpi0: GFX0 > acpivout0 at acpivideo0: DD1F > cpu0: using VERW MDS workaround (except on vmm entry) > cpu0: Enhanced SpeedStep 2494 MHz: speeds: 2201, 2200, 2100, 2000, 1800, > 1700, 1600, 1500, 1300, 1200, 1100, 1000, 900, 700, 600, 500 MHz > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel Core 5G Host" rev 0x09 > inteldrm0 at pci0 dev 2 function 0 "Intel HD Gr
Re: Suspend/hibernate broken [upgrade: 6.9 to 7.0] (solution)
Clint Pachl writes: > This is how I got suspend and hibernate working again on my Huawei > Matebook after upgrading to 7.0 release. I thought I'd share here in > case it helps someone else. > > > SYNOPSIS: > > Initiating a "sleep" state blanks the screen and illuminates the > keyboard (indicating sleep is immenent); but the laptop would never go > to sleep. It would also never wake up. However, pressing the power > button cleanly shutdown the system. > > After comparing the 7.0 dmesg with an older version (6.6), I noticed > this difference: > > tpm0 at acpi0 TPM_ addr 0xfed40040/0x1000: timed out waiting for > validity > > acpi(4) confirmed that the TPM does connect to the ACPI driver. The > kernel error message above is a good hint that the TPM could be > preventing suspend and hibernate. Quite possible. > > > SOLUTION #1: > > I disabled TPM in the kernel at the boot prompt (i.e., boot -c). Within > UKC, "tpm" matched another device. I disabled TPM specifying the device > number (devno) of the tpm0 device. > > UKC> list tpm > UKC> disable 433 > > If this is the solution for you, make it permanent using the kernel > configuration file, bsd.re-config(5). > > > SOLUTION #2: > > There is a "TCM/TPM" setting in BIOS; I disabled it. Booting the > base 7.0 kernel (TPM enabled) also fixed "sleep" modes. > > This is the solution I decided to use. > This is the best approach. > > REQUEST FOR COMMENT: > > I'm not sure if disabling TPM like this creates a security issue. > Please let me know if there are negative repercussions. > The tpm driver exists only to assist suspend/hibernate. It's not used for anything involving "security." > Also, is this a bug that should be reported to bugs@? > Any chance you can try -current? Or maybe provide a copy of /var/db/acpi/TPM.*? You can either disassemble it with iasl from the acpica port, provide an inline hex dump via hexdump(1), or the binary. It can tell me what the TPM start method is that your hardware wants the OS to use. I recently added support to -current for a start method seen in some TPM 2.0 devices, but it doesn't support all known methods. It might allow you to avoid disabling in the BIOS. A full dmesg would also be appreciated. > > ACPI from 7.0 DMESG: > > "ELAN2201" at acpi0 not configured > "INT0E0C" at acpi0 not configured > "INT33A1" at acpi0 not configured > "INT3400" at acpi0 not configured > "INT3403" at acpi0 not configured > "INT3403" at acpi0 not configured > "INT3403" at acpi0 not configured > "INT3403" at acpi0 not configured > "INT3403" at acpi0 not configured > "INT344B" at acpi0 not configured > "PNP0C14" at acpi0 not configured > "PNP0C14" at acpi0 not configured > "PNP0C14" at acpi0 not configured > "WDT0001" at acpi0 not configured > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP UEFI UEFI ECDT SSDT MSDM SSDT SSDT TPM2 SSDT > SSDT SSDT ASPT BOOT HPET APIC MCFG SSDT WSMT SSDT DBGP DBG2 SSDT SSDT > DMAR NHLT FPDT BGRT acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) > HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) > PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) [...] acpiac0 at acpi0: AC > unit online acpials0 at acpi0: ALSD acpibat0 at acpi0: BAT0 model > "BASE-BAT" serial 123456789 type Li oem "Kollur" acpibtn0 at acpi0: > LID_ acpibtn1 at acpi0: PWRB acpicmos0 at acpi0 > acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), > C1(1000@1 mwait.1), PSS > acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), > C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@1034 mwait.1@0x60), > C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: > C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 > mwait.1), PSS acpiec0 at acpi0 acpihpet0 at acpi0: 2399 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > acpimcfg0 at acpi0 > acpimcfg0: addr 0xe000, bus 0-255 > acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (RP01) > acpiprt10 at acpi0: bus -1 (RP10) > acpiprt11 at acpi0: bus -1 (RP11) > acpiprt12 at acpi0: bus -1 (RP12) > acpiprt13 at acpi0: bus -1 (RP13) > acpiprt14 at acpi0: bus -1 (RP14) > acpiprt15 at acpi0: bus -1 (RP15) > acpiprt16 at acpi0: bus -1 (RP16) > acpiprt17 at acpi0: bus -1 (RP17) > acpiprt18 at acpi0: bus -1 (RP18) > acpiprt19 at acpi0: bus -1 (RP19) > acpiprt2 at acpi0: bus -1 (RP02) > acpiprt20 at acpi0: bus -1 (RP20) > acpiprt21 at acpi0: bus -1 (RP21) > acpiprt22 at acpi0: bus -1 (RP22) > acpiprt23 at acpi0: bus -1 (RP23) > acpiprt24 at acpi0: bus -1 (RP24) > acpiprt3 at acpi0: bus -1 (RP03) > acpiprt4 at acpi0: bus -1 (RP04) > acpiprt5 at acpi0: bus -1 (RP05) > acpiprt6 at acpi0: bus -1 (RP06) > acpiprt7 at acpi0: bus 1 (RP07) > acpiprt8 at acpi0: bus -1 (RP08) > acpiprt9 at acpi0: bus 2 (RP09) > acpipwrres0 at acpi0: WRST > acpipwrres1 at acpi0: WRST > acpipwrres10 at acpi0: WRST > acpipwrres11 at acpi0: WRST > ac
Re: unable to send external mail with smtpd
freddiebub...@countermail.com writes: > Hi, I'm new to openbsd having just set it up on my x200 and loving it > (running so much better than my old distro). after reading through > c0ffee's laptop set up guide and the afterboot man page i'm struggling > to work out why i can't send mail through my mail account w smtpd. i > have asked my provider for support about the issues i saw other people > having (port 25 not being open) but they said that wasn't it and they > were unsure about the problem. below i have linked to a paste of my > smtpd.conf and my maillog. Personally i'm struggling to work out whats > wrong from the log but i'm assuming i've not set something up right... > > maillog: http://ix.io/3ChF I looked at your log messages and the only thing I can think of is this mail provider requires some auth approach smtpd doesn't support (CRAM-Md5). It seems they're more interested in supporting mail clients and not a relaying connection from an MTA is my guess. See: https://support.countermail.com/kb/faq.php?id=90 In that case, don't use smptd and configure whatever mail client you use to connect directly to their service. (...or get a new service provider that doesn't require CRAM-MD5) Unless something's changed in 7-8 years I don't think OpenSMTPD is going to support CRAM-MD5. See this old GH exchange with Gilles for some background on why: https://github.com/OpenSMTPD/OpenSMTPD/issues/430 -dv
Re: Alpine Linux guest running slow after upgraded to OpenBSD 7.0
Siegfried Levin writes: > An Alpine Linux 3.10 guest VM is running quite slow after I upgraded > the host to 7.0. It takes quite long to get a response. Other OpenBSD > guests seems ok. Is anyone having the same issue? Thanks. You'll need to share a bit more detail for any constructive help; "quite long" and "a response" are too vague. A lot changed in 7.0 outside just vmm(4)/vmd(8). -dv
Re: xterm not opening on latest snapshot?
henkjan gersen writes:
> 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?
Can you try again with this diff? It should add logging and specify
which unveil is failing.
Index: app/xterm/main.c
===
RCS file: /cvs/xenocara/app/xterm/main.c,v
retrieving revision 1.50
diff -u -p -r1.50 main.c
--- app/xterm/main.c2 Sep 2021 09:31:38 - 1.50
+++ app/xterm/main.c5 Sep 2021 13:58:13 -
@@ -2911,18 +2911,18 @@ main(int argc, char *argv[]ENVP_ARG)
snprintf(homefile, sizeof homefile, "%s/.fonts", env);
if (unveil(homefile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", homefile);
exit(1);
}
snprintf(homefile, sizeof homefile, "%s/.cache/fontconfig",
env);
if (unveil(homefile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", homefile);
exit(1);
}
snprintf(homefile, sizeof homefile, "%s/.icons", env);
if (unveil(homefile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", homefile);
exit(1);
}
}
@@ -2931,12 +2931,12 @@ main(int argc, char *argv[]ENVP_ARG)
snprintf(xdgfile, sizeof xdgfile, "%s/fontconfig", env);
if (unveil(xdgfile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", xdgfile);
exit(1);
}
snprintf(xdgfile, sizeof xdgfile, "%s/icons", env);
if (unveil(xdgfile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", xdgfile);
exit(1);
}
}
@@ -2945,12 +2945,12 @@ main(int argc, char *argv[]ENVP_ARG)
snprintf(xdgfile, sizeof xdgfile, "%s/fontconfig", env);
if (unveil(xdgfile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", xdgfile);
exit(1);
}
snprintf(xdgfile, sizeof xdgfile, "%s/icons", env);
if (unveil(xdgfile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", xdgfile);
exit(1);
}
}
@@ -2959,7 +2959,7 @@ main(int argc, char *argv[]ENVP_ARG)
snprintf(xdgfile, sizeof xdgfile, "%s/fontconfig", env);
if (unveil(xdgfile, "r") == -1) {
-xtermWarning("unveil\n");
+xtermWarning("unveil %s\n", xdgfile);
exit(1);
}
}
@@ -2970,7 +2970,7 @@ main(int argc, char *argv[]ENVP_ARG)
(unveil("/usr/local/lib/X11/icons", "r") == -1) ||
(unveil(etc_utmp, "w") == -1) ||
(unveil(etc_wtmp, "w") == -1)) {
-xtermWarning("unveil\n");
+xtermWarning("unveil many, %s, %s\n", etc_utmp, etc_wtmp);
exit(1);
}
Re: Why 16 year old zlib 1.2.3 in OpenBSD 6.9 released May 2021 please?
Theo de Raadt writes: > Dave Voutila wrote: > >> Theo de Raadt writes: >> >> >> I think the easiest path here is to incorporate the new upstream into a >> >> port, unless someone is familiar with zlib and can cherrypick out the >> >> commit(s) that resolve the issue. (I didn't find zlib in ports already.) >> > >> > That is completely impossible. It must be in base. There are 3 copies >> > in base -- userland, kernel, and bootblocks. They must be kept in sync. >> >> Not saying to replace what's in base, but have a different version in >> ports available for ports. I was thinking along the lines of egcc or >> eopenssl in that the port co-exists with base and ports that need them >> need tweaking to use them. > > You've got to be kidding. In what world does it help to require -I and > -l lines all over the place, or else everything breaks. I'm in 100% agreement it sucks and it's something I believe is already done for ports that require OpenSSL. /shrug. My thinking was instead of having to test all of base across all archs with any potential fix, we could isolate the change to maybe the R port if other R packages or whatever have run into this. But I'm not volunteering to do either so I'll stop beating this horse now before it never walks again. -dv
Re: Why 16 year old zlib 1.2.3 in OpenBSD 6.9 released May 2021 please?
Theo de Raadt writes: >> I think the easiest path here is to incorporate the new upstream into a >> port, unless someone is familiar with zlib and can cherrypick out the >> commit(s) that resolve the issue. (I didn't find zlib in ports already.) > > That is completely impossible. It must be in base. There are 3 copies > in base -- userland, kernel, and bootblocks. They must be kept in sync. Not saying to replace what's in base, but have a different version in ports available for ports. I was thinking along the lines of egcc or eopenssl in that the port co-exists with base and ports that need them need tweaking to use them. > > It gets updated when things matter. I wasn't aware a change had happened > which matters. The thread makes me unenthusiastic, because I cannot tell > what changed that matters. Updating it is not a trivial effort, because > every bootblock needs testing. I've done it twice... I figured and want to be clear I am *not* volunteering for that exercise! I don't see a change that matters for base. -dv
Re: Why 16 year old zlib 1.2.3 in OpenBSD 6.9 released May 2021 please?
Matt Dowle writes: > Hi, > > Is it intentional or is there any good reason that OpenBSD 6.9 released May > 2021 uses a 16 year old version of zlib (v1.2.3; July 2005)? The latest > version v1.2.11 (Jan 2017) is 4 years old. > > Background here: https://github.com/Rdatatable/data.table/pull/5049 Had a chat with Matt off-list and took a very terse look at zlib's current status w.r.t. building just on amd64 -current. I think the easiest path here is to incorporate the new upstream into a port, unless someone is familiar with zlib and can cherrypick out the commit(s) that resolve the issue. (I didn't find zlib in ports already.) To be honest, the extend of my effort was: 1. clone zlib master branch from https://github.com/madler/zlib 2. try building with clang on amd64 -current...which fails. 3. try building with GCC 8.4 from ports...which "just works" (didn't even need gmake). To be clear: I didn't test if this actually fixed any issues. Then any ports that need the newer zlib and can't use the one in base can use the port. For folks that maintain ports...does this sound feasible or am I dreaming? (Assuming someone writes and maintains the port.) -dv
Re: Machine age and OpenBSD - Thinkpad R51e
Thomas Vetere writes: > Hello everyone, > > I was looking to get a laptop to run OpenBSD. The one I am looking at in > particular is the Thinkpad R51e (2005). I like this particular model > because it does not come with any extra hardware that OpenBSD does not > support in the first place (bluetooth, camera, etc.) My main concern is the > longevity that this model would have going forward. I already have a '94 > Thinkpad that cannot run the latest OpenBSD well because hardware support > was gradually dropped during code cleanups, etc (i.e. newer versions of X11 > removed support for my ancient graphics chip because it just wasn't worth > the time to maintain the code). Does anyone know, given the age of that > model, how many years I might get out of it with OpenBSD and its packaged > software before hardware support starts to drop? What is a good rule of > thumb for selecting a machine to run OpenBSD with respect to its age? > > Thank you for your help! I think that machine (R51e) is 32-bit only, so it doesn't have much runway if you're looking to keep up with Xenocara/X11 changes. I'd recommend looking for at least a slightly more recent Intel-based machine that's 64-bit. I know the x230's are popular and fairly user serviceable.
Re: use tablet interface under vm running linux / pressure on wacom
Rudolf Sykora writes: > I just want to check if, perhaps, there is something new about the > possibility of the mentioned 'device passthrough' in vmd. Nope. I recommend either finding a device that works as required with OpenBSD or improving the existing driver to make your device work. -dv
Re: Best practices mirroring large file-system hierarchies?
limit=32768 > net.inet.tcp.sackholelimit=32768 > net.inet.tcp.always_keepalive=0 > net.inet.tcp.synuselimit=10 > net.inet.tcp.rootonly=2049 > net.inet.tcp.synhashsize=293 > net.inet.udp.checksum=1 > net.inet.udp.baddynamic=7,9,13,18,19,22,37,39,49,53,67,68,69,70,80,88,105,107,109,110,111,123,129,135,137,138,139,143,161,162,163,164,177,178,179,191,194,199,201,202,204,206,210,213,220,372,389,427,444,445,464,468,500,512,513,514,517,518,520,525,533,546,547,548,554,587,623,631,636,646,664,706,749,750,751,853,993,995,1433,1434,1524,1525,1645,1646,1701,1723,1812,1813,1900,2049,2401,3031,3517,3689,3784,3785,4190,,4500,4559,4754,4755,4789,5002,5060,5298,5353,5354,5432,7000,7001,7002,7003,7004,7005,7006,7007,7008,7009,7784,8025,8067,9418,10050,10051,16992,16993,16994,16995,20005,26740 > net.inet.udp.recvspace=41600 > net.inet.udp.sendspace=9216 > net.inet.udp.rootonly=2049 > net.inet.gre.allow=0 > net.inet.gre.wccp=0 > net.inet.esp.enable=1 > net.inet.esp.udpencap=1 > net.inet.esp.udpencap_port=4500 > net.inet.ah.enable=1 > net.inet.etherip.allow=0 > net.inet.ipcomp.enable=0 > net.inet.carp.allow=1 > net.inet.carp.preempt=0 > net.inet.carp.log=2 > net.inet.divert.recvspace=65636 > net.inet.divert.sendspace=65636 > net.inet6.ip6.forwarding=0 > net.inet6.ip6.redirect=1 > net.inet6.ip6.hlim=64 > net.inet6.ip6.mrtproto=0 > net.inet6.ip6.maxfragpackets=200 > net.inet6.ip6.log_interval=5 > net.inet6.ip6.hdrnestlimit=10 > net.inet6.ip6.dad_count=1 > net.inet6.ip6.auto_flowlabel=1 > net.inet6.ip6.defmcasthlim=1 > net.inet6.ip6.use_deprecated=1 > net.inet6.ip6.maxfrags=200 > net.inet6.ip6.mforwarding=0 > net.inet6.ip6.multipath=0 > net.inet6.ip6.multicast_mtudisc=0 > net.inet6.ip6.neighborgcthresh=2048 > net.inet6.ip6.maxdynroutes=4096 > net.inet6.ip6.dad_pending=0 > net.inet6.ip6.mtudisctimeout=600 > net.inet6.icmp6.redirtimeout=600 > net.inet6.icmp6.nd6_delay=5 > net.inet6.icmp6.nd6_umaxtries=3 > net.inet6.icmp6.nd6_mmaxtries=3 > net.inet6.icmp6.errppslimit=100 > net.inet6.icmp6.nd6_maxnudhint=0 > net.inet6.icmp6.mtudisc_hiwat=1280 > net.inet6.icmp6.mtudisc_lowat=256 > net.inet6.icmp6.nd6_debug=0 > net.inet6.divert.recvspace=65636 > net.inet6.divert.sendspace=65636 > net.bpf.bufsize=32768 > net.bpf.maxbufsize=2097152 > net.mpls.ttl=255 > net.mpls.mapttl_ip=1 > net.mpls.mapttl_ip6=0 > net.pipex.enable=0 > hw.machine=amd64 > hw.model=AMD Opteron(TM) Processor 6276 > hw.ncpu=16 > hw.byteorder=1234 > hw.pagesize=4096 > hw.disknames=sd0:48d117fdb8bf80d1,sd1:59a3ee4ba41ddb29,sd2:36ab3ca77b9c2e6f,sd3:362548917ef7bfba,sd4:ceb3422dc4d34ab5,sd5:5bc682b7aa33d82f,sd6:da46565a96a9a13a,sd7:43b4ba0f34af8d17,sd8:168427c044825975 > hw.diskcount=9 > hw.sensors.sdtemp0.temp0=53.25 degC > hw.sensors.sdtemp1.temp0=55.50 degC > hw.sensors.sdtemp2.temp0=55.75 degC > hw.sensors.sdtemp3.temp0=55.25 degC > hw.sensors.sdtemp4.temp0=55.25 degC > hw.sensors.sdtemp5.temp0=55.00 degC > hw.sensors.sdtemp6.temp0=55.25 degC > hw.sensors.sdtemp7.temp0=53.00 degC > hw.sensors.nvt0.temp1=62.75 degC > hw.sensors.nvt0.temp4=80.50 degC > hw.sensors.nvt0.fan0=164 RPM > hw.sensors.nvt0.fan1=767 RPM > hw.sensors.nvt0.fan2=164 RPM > hw.sensors.nvt0.fan3=453 RPM > hw.sensors.nvt0.fan4=164 RPM > hw.sensors.nvt0.fan5=164 RPM > hw.sensors.nvt0.volt0=8.00 VDC > hw.sensors.nvt0.volt2=7.28 VDC > hw.sensors.nvt0.volt6=7.79 VDC > hw.sensors.nvt0.volt7=6.28 VDC > hw.sensors.nvt0.volt8=7.49 VDC > hw.sensors.nvt0.volt9=6.30 VDC > hw.sensors.nvt0.volt10=7.12 VDC > hw.sensors.nvt0.volt11=7.63 VDC (VTT) > hw.sensors.nvt0.volt12=3.46 VDC (3VDD) > hw.sensors.nvt0.volt13=3.46 VDC (3VSB) > hw.sensors.nvt0.volt14=4.19 VDC (VBat) > hw.sensors.km0.temp0=42.38 degC > hw.sensors.km1.temp0=42.00 degC > hw.cpuspeed=2300 > hw.vendor=Supermicro > hw.product=H8SGL > hw.version=1234567890 > hw.serialno=1234567890 > hw.uuid=534d4349-0002-337a-c40c-337ac40cb061 > hw.physmem=68701257728 > hw.usermem=68701241344 > hw.ncpufound=16 > hw.allowpowerdown=1 > hw.smt=0 > hw.ncpuonline=8 > machdep.console_device=ttyC0 > machdep.bios.diskinfo.128=bootdev = 0xa204, cylinders = 1024, > heads = 255, sectors = 63 > machdep.bios.diskinfo.129=bootdev = 0xa0020204, cylinders = 1024, > heads = 255, sectors = 63 > machdep.bios.diskinfo.130=bootdev = 0xa0030204, cylinders = 1024, > heads = 255, sectors = 63 > machdep.bios.diskinfo.131=bootdev = 0xa0040204, cylinders = 1024, > heads = 255, sectors = 63 > machdep.bios.diskinfo.132=bootdev = 0xa0050204, cylinders = 1024, > heads = 255, sectors = 63 > machdep.bios.diskinfo.133=bootdev = 0xa0060204, cylinders = 1024, > heads = 255, sectors = 63 > machdep.bios.diskinfo.134=bootdev = 0xa0080204, cylinders = 1024, > heads = 255, sectors = 63 > machdep.bios.diskinfo.135=bootdev = 0xa0070204, cylinders = 1024, > heads = 255, sectors = 63 > machdep.bios.cksumlen=2 > machdep.allowaperture=0 > machdep.cpuvendor=AuthenticAMD > machdep.cpuid=0x600f12 > machdep.cpufeature=0x179bfbff > machdep.kbdreset=0 > machdep.xcrypt=0 > machdep.lidaction=1 > machdep.forceukbd=0 > machdep.tscfreq=236969 > machdep.invarianttsc=1 > machdep.pwraction=1 > ddb.radix=16 > ddb.max_width=80 > ddb.max_line=25 > ddb.tab_stop_width=8 > ddb.panic=1 > ddb.console=0 > ddb.log=1 > ddb.trigger=0 > vfs.mounts.ffs has 16 mounted instances > vfs.mounts.mfs has 2 mounted instances > vfs.ffs.max_softdeps=23704 > vfs.ffs.sd_tickdelay=2 > vfs.ffs.sd_worklist_push=0 > vfs.ffs.sd_blk_limit_push=0 > vfs.ffs.sd_ino_limit_push=0 > vfs.ffs.sd_blk_limit_hit=0 > vfs.ffs.sd_ino_limit_hit=0 > vfs.ffs.sd_sync_limit_hit=0 > vfs.ffs.sd_indir_blk_ptrs=1618 > vfs.ffs.sd_inode_bitmap=4201 > vfs.ffs.sd_direct_blk_ptrs=14680 > vfs.ffs.sd_dir_entry=8615 > vfs.ffs.dirhash_dirsize=2560 > vfs.ffs.dirhash_maxmem=5242880 > vfs.ffs.dirhash_mem=5184849 > vfs.nfs.iothreads=-1 > vfs.fuse.fusefs_open_devices=0 > vfs.fuse.fusefs_fbufs_in=0 > vfs.fuse.fusefs_fbufs_wait=0 > vfs.fuse.fusefs_pool_pages=0 -- -Dave Voutila
Re: vmctl start: vm command failed: Operation already in progress (no one VM run in the same time)
Martin writes: > Try to start VM from previously (<6.9) working command as below: > > $ doas /usr/sbin/vmctl start -m 8G -c -n vmlan -d /path/to/vm.qcow2 vm > > Now I have trouble with it on 6.9amd64 with 1-5 patches installed. > > $ doas rcctl status vmd > vmd(ok) > > command above returns: > vmctl start: vm command failed: Operation already in progress Common cause of this is having the vm already defined in vm.conf. Run vmd with verbose logging, ideally in the foreground, and please share the output. > > Even if "$ vmctl check" shows ALL machines are stopped > > if I stopped vmd I see proper error with non active vmd.sock > $ doas rcctl stop vmd > vmd(ok) > > vmctl: connect: /var/run/vmd.sock: connection refused >
Re: VMM 6.9amd64 host video acceleration
Martin writes: > Hi list, > > Just wonder how to enable video acceleration on VMM guest's side (Debian) if > it was possible. Maybe PCIe passthru should be present for that purpose? There is nothing to accelerate: vmd(8) doesn't emulate a display or video device. vmm(4) doesn't support pass-through to host hardware either. -dv
Re: Unable to boot 6.9 bsd.rd on 6.8 vmd host
Mischa writes: > Hi All, > > I have a couple of machines running on 6.8 still, will upgrade soon. :) > For some reason when I am trying to boot a 6.9 bsd.rd nothing is happening. 6.9 bsd.rd's for amd64 are gzip'd. For 6.9, vmd was taught how to boot compressed kernels/ramdisks. > > It's only showing: > Connected to /dev/ttypq (speed 115200) > > Nothing else appears. > Booting from a 6.8 bsd.rd works normally. > > Equally booting from 6.9 bsd.rd on a 6.9 host works as expected as well. > > Something I can do to make this work? gunzip the ramdisk and a 6.8 vmd instance should be able to boot it. Once you have a guest updated and it's using seabios it will be booting off the disk image and it shouldn't matter at that point. -dv
Re: vmm error mesg since upgrade to 6.9
Dave Voutila writes: > > I've managed to reproduce it on my end using vmd(8) from 6.9 and a > config similar to what you and Holger are using. I have a few hunches > and looking into it. > An errata for 6.9 was released addressing the underlying issue. As this is specific to vmd(8), this only affects users on amd64 using vmd(8). See https://www.openbsd.org/errata69.html Should be available via syspatch(8) now that it's had time to replicate out to mirrors. Thanks Holger and Mischa for reporting the issue and helping me troubleshoot! -dv
Re: vmm error mesg since upgrade to 6.9
Mischa Peters writes:
>> On 2 May 2021, at 14:25, Dave Voutila wrote:
>>
>>
>> Mischa writes:
>>
>>>
>>> Interestingly I am seeing the same on my 6.9 hosts, except the host running
>>> -current.
>>
>> Hmm. -current has some small changes to virtio emulation, specifically
>> fixing some bad casts I found [1]. That might explain the difference
>> with -current.
>>
>>> The hosts are similar in regards to configuration.
>>> I have migrated from bridge/vether to veb/vport.
>>>
>>> May 2 13:14:38 r2 vmd[59033]: vionet_enq_rx: descriptor too small for
>>> packet data
>>> May 2 13:15:12 r2 last message repeated 11 times
>>> May 2 13:17:13 r2 last message repeated 34 times
>>>
>>> # vmctl show | grep 59033
>>> 6 59033 14.0G1.8G ttyp5 root running images
>>>
>>> # vm.conf
>>> switch "uplink_vlan880" {
>>>interface veb880
>>> }
>>> vm "images" {
>>>memory 4G
>>>disk "/var/vmm/images.qcow2"
>>>disk "/var/vmm/images_extra.qcow2"
>>>interface tap { switch "uplink_vlan880" }
>>> }
>>>
>>> # cat /etc/hostname.em0
>>> up
>>> # cat /etc/hostname.veb880
>>> add vlan880
>>> add vport880
>>> up
>>> # cat /etc/hostname.vlan880
>>> vnetid 880 parent em0
>>> up
>>> # cat /etc/hostname.vport880
>>> inet 46.23.xx.xx 255.255.255.0
>>> inet6 2a03:6000:xxx::xx
>>> up
>>>
>>> I am using a combination of dhcp and static IP config on both hosts to
>>> provision the VMs.
>>
>> Are you running dhcpd(8) on the host? Or using vmd(8)'s built-in dhcp
>> service?
>
> Only using dhcpd on the host.
>
>>> What else can be relevant?
>>
>> Logging into my obsd.ams host (that I haven't updated yet to 6.9) it's
>> using "dhcp" in /etc/hostname.vio0. Do you see this same issue with
>> *guests* running 6.8? Or only 6.9?
>
> The host running -current only has 6.8 VMs. The hosts where I see the
> messages are 6.9 VMs on 6.9 hosts.
>
> Let me spin a 6.9 -release host and run a bunch of 6.8 VMs. And or a mix.
>
I've managed to reproduce it on my end using vmd(8) from 6.9 and a
config similar to what you and Holger are using. I have a few hunches
and looking into it.
-dv
Re: vmm error mesg since upgrade to 6.9
Mischa writes:
>
> Interestingly I am seeing the same on my 6.9 hosts, except the host running
> -current.
Hmm. -current has some small changes to virtio emulation, specifically
fixing some bad casts I found [1]. That might explain the difference
with -current.
> The hosts are similar in regards to configuration.
> I have migrated from bridge/vether to veb/vport.
>
> May 2 13:14:38 r2 vmd[59033]: vionet_enq_rx: descriptor too small for packet
> data
> May 2 13:15:12 r2 last message repeated 11 times
> May 2 13:17:13 r2 last message repeated 34 times
>
> # vmctl show | grep 59033
>6 59033 14.0G1.8G ttyp5 root running images
>
> # vm.conf
> switch "uplink_vlan880" {
> interface veb880
> }
> vm "images" {
> memory 4G
> disk "/var/vmm/images.qcow2"
> disk "/var/vmm/images_extra.qcow2"
> interface tap { switch "uplink_vlan880" }
> }
>
> # cat /etc/hostname.em0
> up
> # cat /etc/hostname.veb880
> add vlan880
> add vport880
> up
> # cat /etc/hostname.vlan880
> vnetid 880 parent em0
> up
> # cat /etc/hostname.vport880
> inet 46.23.xx.xx 255.255.255.0
> inet6 2a03:6000:xxx::xx
> up
>
> I am using a combination of dhcp and static IP config on both hosts to
> provision the VMs.
Are you running dhcpd(8) on the host? Or using vmd(8)'s built-in dhcp
service?
>
> What else can be relevant?
Logging into my obsd.ams host (that I haven't updated yet to 6.9) it's
using "dhcp" in /etc/hostname.vio0. Do you see this same issue with
*guests* running 6.8? Or only 6.9?
-dv
[1]
https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/vmd/virtio.c.diff?r1=1.84&r2=1.85&only_with_tag=MAIN
Re: vmm error mesg since upgrade to 6.9
Holger Glaess writes: > hi > > > i did the upgrade von 6.8 to 6.9 . > > > after reboot i get in my messages log > > > vmd[56]: vionet_enq_rx: descriptor too small for packet data > > > i run only one vm on my box, this is also upgraded to 6.9. > > > how can i fix this ? > > Can you share some more details? Does networking work? How do you start this vm (what are the networking arguments)? Need more info to reproduce what you're seeing. There were minimal changes in the virtio emulation between 6.8 and 6.9. One of the few changes involved dhcp/bootp packet intercept, so I'm curious what your guest is doing. -dv
Re: X11 Freeze and Crash on Lenovo Thinkpad T14 AMD GEN1
niamkik writes: > Hi, > > Just got the same issue, this time, my connection was still present. Here the > message from dmesg after going into single-user mode by killing init process. > > [drm] *ERROR* ring sdma0 timeout, signaled seq=30079, emitted seq=30079 > [drm] *ERROR* Process information: process pid 0 thread pid 0 > > Xorg process was a zombie at this time. This behavior seems to be generated > when the screen is going blank, in my case, when xautolock is executed or > screensaver is set. My first crash was on 2nd April, just after using the > last current version at this time. It seems a user with a T14s with similar hardware reported issues with hibernate. [1] Does your system properly suspend/resume and hibernate/resume? I'm sadly no eXpert on X or drm...but if you're getting a segfault, it might be helpful to get the core dump and see what the stack was via gdb. -Dave [1] https://marc.info/?l=openbsd-bugs&m=161654860102192&w=2
Re: vmm page fault with VM upgraded from Ubuntu 18LTS to 20LTS
Noah writes: > vmm crashes during boot after upgrading a VM from Ubuntu 18 to Ubuntu 20. > Host is running 6.8 with all syspatches > > vmd -dvvv output provides a log entry of: > vcpu_run_loop: vm 7 / vcpu 0 run ioctl failed: Bad address > > and this coincides with a kernel message: > vmx_fault_page: uvm_fault returns 14, GPA=0xfe001818, rip=0xb98a31b4 It's a known issue. Newer Ubuntu kernels are built with an Intel PMC driver that probes mmio registers on (IIRC) Intel Skylake and newer systems. vmm(4) and vmd(8) do not support mmio like this at the moment. There's no way to disable the probing as it's not a kernel module, so no combination of linux boot args will help. There are some hacky patches that would work if you were on -current, but unless you want to stay on bleeding edge, it's probably a bigger hastle than it's worth. This is in my backlog, however...I have a Kaby Lake system impacted by this. -Dave
Re: Keeping xlock on top in cwm
tetrahe...@danwin1210.me writes: > On Tue, Mar 16, 2021 at 06:11:09PM +, tetrahe...@danwin1210.me wrote: >> In cwm, is there a way to keep a particular window (in this case, >> xclock) "always on top"? >> >>I don't see anything in the man page, but maybe I missed something: >>https://man.openbsd.org/cwmrc > > I worked out how to set a "gap" so that maximized windows won't > obscure the xclock line at the bottom. That helped. Unfortunately, > it's not enough. By default `xconsole` is sized and positioned so, if > brought forward, `xconsole` obscures `xclock`. That invariably happens > if cycling through windows... You can change or remove xconsole from starting by modifying /etc/X11/xenodm/Xsetup_0
Re: vmm/vmd disk issue
Jan Johansson writes: > Mike Larkin wrote: >> On Tue, Mar 09, 2021 at 09:38:57AM -0500, Ian Darwin wrote: >> > On Tue, Mar 09, 2021 at 09:52:03AM +0100, Jan Johansson wrote: >> > > If I try to cp or dd the disk image on the host it fails >> > > >> > > dd if=disk.raw.old of=disk.raw.bak bs=1m >> > > dd: disk.raw.old: Input/output error >> > > 8858+0 records in >> > > 8858+0 records out >> > > 9288286208 bytes transferred in 102.048 secs (91018010 bytes/sec) >> > > >> > > The host show no other signs of failing hardware. >> > > >> > > Is this a software or a hardware error? >> > >> > Given that it gives an error outside the VM, it's likely hardware. >> > >> >> Agreed. Sorta hard to fault vmd(8) if it's not even running. > > Since these are sparse files, could the vioblk(4) somehow write > incorrect data that later will make it unreadable such as a > pointer pointing into nothingness? > > The messages > > vmd[39543]: vioblk write error: Input/output error > vmd[39543]: wr vioblk: disk write error > > was produced and 01:30 when all the 4 guests and the host all run > the daily script (which makes backup and other maintenance tasks) > if that could have any impact. > > Should there not be anything on the host logging errors to > dmesg/syslog such as sd(4) or ahci(4)? > > (If it is not obvious my understanding of how the virtio/vioblk > stuff hooks in to the disk stack is very limited) > vmd(8) reads/writes to the disk image files (both raw and qcow2) using pread(2)/pwrite(2) calls. The qcow2 handling is a bit more complex, but they're still just calling pread/pwrite as far as I'm aware. Have you run fsck(8) on your host? > This drive was installed in august 2020 and if I recall correctly > it was because of this issue. So I am thinkig cable or > motherboard. > > If I decide to replace would it make sense to make this a > softraid mirror (RAID1) to avoid or get better indication of this > kind of problems in the future or would only add more parts that > can break? > > I'am currently trying to provoke the drive from the host with > > dd if=/dev/random of=test.raw bs=1m count=17000 > > then cp/dd and cmp to see if I can make it break for real. I'd say maybe make sure you have backups of anything important first if you're purposely going to break things. :-) -- -Dave Voutila
Re: Alpine-virt vmd guest tsc directive
On Mon, Jun 29, 2020 at 4:46 PM Martin wrote: > > According to man vmctl for both: -current and 6.7 -b should be used for base > images. -b works just before kernel+vmm+vmctl -current update. Re-read it. You're mixing the `vmctl start` and `vmctl create` commands. They reuse options but the -b options have nothing to do with each other and even with `vmctl start` it's a flag for a kernel or custom bios...not an iso. > > Please check https://man.openbsd.org/vmctl.8 > > Can it be a bug? No. -Dave
Re: Alpine-virt vmd guest tsc directive
On Mon, Jun 29, 2020 at 4:05 PM Martin wrote: > After build kernel+vmd+vmctl sources from -current I have an issue with > installing a system from *.iso images. > The command below works fine before update, but not now > > $ doas vmctl start -m 1G -c -n vmlan -b /home/iso/install67.iso -d > /home/vmm/guest.qcow2 guest I don't believe that syntax was ever correct for vmctl(8). Check your use of -b.
Re: Alpine-virt vmd guest tsc directive
On Mon, Jun 29, 2020 at 10:57 AM Martin wrote: > > Hi Dave, > > Alpine kernel 5.4.43-1-virt guest openbsd 6.7 stable host. Try to compile vmd > from -current to improve linux guests stability. Are you also running a -current kernel? vmm(4) is in the OpenBSD kernel...vmd(8) is in base. > > set clocksource=tsc in /etc/update-extlinux.conf > run update-extlinux to install boot loader. > > Next boot getting this in dmesg: > > ... > [Frimware Bug]: TSC doesn't count with P0 frequency! > tsc: Fast TSC calibration failed > tsc: Unable to calibrate against PIT > tsc: No referece (HPET/PMTIMER) available > tsc: Marking TSC unstable due to could not calculate TSC khz > ... Honestly, chasing Linux tsc issues will waste your time. If you're using a -current snapshot, build https://github.com/voutilad/vmm_clock and load it as a Linux kernel module and give up chasing tsc calibration issues for now unless you want to get intimately familiar with the Linux kernel. > Dave, I've never asked about qcow2 or raw disks in any of my previous email. Apologies...saw another Martin (mar...@sukany.cz) reply to the same subject and thought you were the same Martin :-) -Dave
Re: Alpine-virt vmd guest tsc directive
On Mon, Jun 29, 2020 at 7:23 AM Martin wrote: > > Hi list, > > I'm using Alpine-virt linux (headless linux with 40Mb initial *.iso size) > which has tsc issues. Alpine uses syslinux lightweight boot loader by > default. In order to enable tsc I've added tsc=reliable tsc=noirqtime to > /etc/update-extlinux.conf before console=ttyS0,115200 and updated it > accordingly. You don't mention which Alpine and kernel version you're using. Also, you don't mention which OpenBSD version...-current or 6.7? Some major fixes just went into -current and look like they were in last night's amd64 snapshots. > > It seems no changes in tsc usage prior to /dev/rtc0 as boot log shows: > ... > * Setting system clock using the hardware clock [UTC] ...hwclock: select() to > /dev/rtc0 to wait for clock tick timed out > * Failed to set the system clock /dev/rtc0 has nothing to do with the tsc or clocksource. This looks like a separate issue and your guest isn't properly using the emulated mc146818 device. I'm guessing there are bigger issues here. > ... > > Does somebody know some way how set tsc as default clock source in Alpine > 5.4.43-1-virt guest? > Add the linux boot arg: clocksource=tsc But in all honesty, if you want better Linux guest stability, you'll need to use a -current snapshot. Regarding your comment about disks in your other email...what you saw with qcow2 vs raw probably has nothing to do with the emulated disks and everything to do with the stability improvements now in -current. -Dave
Re: OpenBSD alternatives to Pi-Hole
George writes: > Hi guys, > > I am trying to setup a Pi-Hole service, i.e. add blocking based on > empty DNS records zones files, for my local LAN and would like to ask > what people are using on OpenBSD in this role? > > Thanks in advance, > > George See unbound(8). I believe it's also used by the pi-hole distribution to provide the caching dns resolver. There are numerous blog posts online about how to configure unbound(8) for this, including on OpenBSD. -- -Dave Voutila
Re: VMM Debian guest serial setup help needed
George writes: > Hi guys, > > I apologize if this maybe out of topic even though it is truly related > to VMM than Debian. > > I am trying to setup a VMM Debian based guest but I'm not able to get > it to work. I found some description on the web about which settings > to edit in grub.cfg to enable the serial console and created a VM with > 10.3 in qcow2 disk format in KVM. Now I am trying to start the same on > OpenBSD 6.7 but keep getting the connected message and then just > "Rebooting " after I hit some keyboard keys seems like baud rate issue > but not sure. Not baudrate related, but there are some known issues in OpenBSD 6.7 related to the emulated uart device in vmd(8). (I have a patch if you follow -current[1] that fixes stability issues.) My advice is to install using vmm(4)/vmd(8) and not migrate an image from KVM. I believe Debian started including the virtio cdrom drivers finally...but, if not, google for some guides on adding those to the iso. Make sure you install OpenSSH and rely on ssh(1) connections to the guest. As soon as you can, modify the grub defaults in /etc/default/grub and set the GRUB_CMDLINE_LINUX_DEFAULT to include: tsc=reliable tsc=noirqtime console=ttyS0,115200 Make sure to run update-grub afterwards. You'll probably have a bad time with your clock, though Debian use a 4.x kernel, so it won't be too bad and may manage using tsc as a clocksource. Otherwise expect refined-jiffies as the clocksource and it may run at a rate of 50% of host time. I recommend you also build and install my Linux clone of vmmci(4)[2] within the Debian guest if you want safe guest shutdowns. > > After messing with it for a while now I am getting a new error: > > vmctl: could not open disk image(s) > > even thought the disk is there and readable to the user I have setup > in vm.conf in fact I have another VM with the same configuration and > disk with the same permissions and in the same location that works (it > is OpenBSD based). Use top(1) showing threads and command line args: top -C -g vmd Chances are you have a lingering vmd(8) process for the Debian guest using the disk. Kill -9 the one with the vm name. > > I would greatly appreciate it if someone has gone this path and can > share some config info with me. > > Cheers and thanks in advance, > > George [1] https://sisu.io/patches/vmd-thread-safety-07062020-v1.patch [2] https://github.com/voutilad/virtio_vmmci -Dave
Re: Running Windows inside vmm/vmd VM.
On Sat, Nov 23, 2019 at 12:18 AM Jordan Geoghegan wrote: > > However the timekeeping situation for my Linux VMs is bleak. On both > Void and Alpine, no clocks are even detected. In the dmesg it complains > about the TSC clock source being unstable. Ultimately, we're left with > only jiffies as a clock source option: Anecdotally, I've found distros using Linux kernels in the 4.9-4.14 range do ok in letting you force tsc even if it says it's unstable. Newer kernels often have a myriad of issues booting. (Might not be kernel related so much as just all the other stuff that changes around it.) If you experience either slight, chronic drift or drift related to the OpenBSD host suspending/resuming after long periods of time, I wrote a Linux kernel driver that mimics OpenBSD's vmmci(4) that may help: https://github.com/voutilad/virtio_vmmci The driver listens for notifications from vmd about clock drift events and use kernel api calls to adjust as needed, properly triggering anything scheduled. An added nicety is it'll also listen for shutdown/reboot events as well and try to cleanly reboot or halt the system via whatever init system the Linux guest uses, meaning services should have a chance to stop themselves. -Dave
Re: serial console images for installing on vmd based guests
On Wed, Mar 13, 2019 at 4:08 AM Claudio Jeker wrote: > > On Tue, Mar 12, 2019 at 11:48:01PM -0700, Mike Larkin wrote: > > On Tue, Mar 12, 2019 at 05:37:04PM -0700, Chris Cappuccio wrote: > > > Is there any archive of serial console bootable images (w/virtio support) > > > for Linux or other OSes to boot under vmd? > > > > > > > You mean installer images? Like things you would install from? Tons. > > > > If you're talking about pre-installed full OSes, it's unlikely. > > > > Debian still does not manage to ship an install media that has virtio > support. While it is possible to install via serial console it fails to > detect disks and net. There's a nice guide to adding virtio to a Debian install image for those that don't want to go the qemu route in bootstrapping a disk image: http://www.netzbasis.de/openbsd/vmd-debian/index.html -Dave
Re: clocksource tsc sometimes not available within debian vm on OpenBSD 6.4
On Fri, Mar 8, 2019 at 1:55 PM Joe M wrote: > > I have the same issue and have been using this driver. It sets the > correct time every 5 seconds. For this purpose, this solution is a > hack, but, I could not figure out a better solution. > > https://github.com/voutilad/virtio_vmmci/issues/1 As the author of the driver, let me clarify that the behavior now mimics the native vmmci(4) behavior in that it only syncs the clock when told to by the host system, which corresponds to the virtual mc146818 detected its own clock drift (see vmd(8) source code). In practice, this usually happens when the host system comes out of suspension/hibernation. The driver is not meant to resolve major issues like chronic clock drift that even ntp can't fix. > > Also, I noticed that vm clock would be very slow. It loses 28 minutes > for every 30 minutes. > > Another thing, watch out regarding tsc=unreliable kernel command line > option, the vm is getting unresponsive with it after an hour or so. > -Dave
Re: A (partial) vmmci(4) Linux implementation
> On Feb 25, 2019, at 7:29 PM, Mike Larkin wrote:
>
> On Sun, Feb 24, 2019 at 12:21:24PM -0500, Dave Voutila wrote:
>> I've been experimenting with implementing something like vmmci(4) for
>> Linux guests. It's started to prove useful to myself so maybe others
>> will benefit, even though there are currently some caveats[1].
>>
>> https://github.com/voutilad/virtio_vmmci
>>
>> My primary use case is keeping some Linux guests constantly running in
>> the background under the vmm(4) hypervisor on my laptop that sees quite
>> a few suspend (zzz)/resume cycles throughout my day.
>>
>> It currently consists of 2 Linux kernel modules, one representing a
>> virtio_pci implementation handling the quirks[2] of how vmd(8) exposes
>> the vmm control device and the other module is the actual virtio driver
>> implementation.
>>
>> I've tested it with a stock Ubuntu 18.0.4 install as well as with a
>> newer v4.20.12 tweaked Linux kernel[3] and so far seems to build and
>> work just fine using an OpenBSD snapshot from Monday 18 Feb as the host.
>>
>> It doesn't yet catch shutdown or restart events, but that's my next goal
>> since I'd like to make sure I get clean shutdowns via `vmctl stop`.
>>
>> -Dave
>>
>> [1]: https://github.com/voutilad/virtio_vmmci#current-state--known-caveats
>> [2]: https://github.com/voutilad/virtio_vmmci#learnings-from-virtio-hacking
>> [3]: https://github.com/voutilad/linux
>>
>
> Looks like a good start!
>
> For what it's worth, we should probably allocate a real virtio device number
> from Redhat or whoever controls that. I have an old email in my inbox with a
> few contact names, but I never got around to following up. That would fix the
> problem of the "stolen" virtio ID.
>
> We chose to implement what looks like a PCI hostbridge but used a fake PCI
> VID/PID for this. The reason for doing it this way is that if you say you are
> a host bridge that is well-known, you have to implement all the bug-for-bug
> compatibility that comes with that.
>
> I'll take a look at the register read/write thing, I'm not sure I entirely
> understand the issue you saw.
>
> -ml
I'll try to avoid too much Linux detail since this is misc@openbsd,
but it seems to be a difference related to the underlying Linux virtio
pci functions used for reading based on if your device is picked up as
a "modern" or "legacy" device.:
- virtio_pci_modern[1]: uses a similar approach to how
OpenBSD's virtio pci implementation works for reading config
registers where there are different routines for reading different
amounts of data.
- virtio_pci_legacy[2]: reads a byte using Linux's ioread8 from
the given register address, then reads a byte from address+1,
etc. until it reads up to the amount of data requested.
Given how vmd/virtio.c:vmmci_io [3] is implemented it expects a
read/write to specific register addresses, with logical gaps between
them based on the size of the data returned:
...
int
vmmci_io(int dir, uint16_t reg, uint32_t *data, uint8_t *intr,
void *unused, uint8_t sz)
{
*intr = 0xFF;
if (dir == 0) {
switch (reg) {
case VIRTIO_CONFIG_DEVICE_FEATURES:
case VIRTIO_CONFIG_QUEUE_SIZE:
case VIRTIO_CONFIG_ISR_STATUS:
log_warnx("%s: illegal write %x to %s",
__progname, *data, virtio_reg_name(reg));
break;
...
I had to change my driver to use the "modern" behavior even though
all OpenBSD virtio devices appear as "legacy" to the Linux virtio pci
framework. (So far writes using the legacy method are fine.)
I'm not convinced this warrants changes to vmd/virtio.c since this is
like fringe use case after fringe use case and all the other virtio
devices vmd(8) implements work. The VMM Control device is a bit of the
oddball because it's not using virtio queues to communicate and
instead relies on interrupts to notify the driver to go check the
config registers.
Which brings me to my last part: getting interrupts to work on my
driver. I figured it out this morning after ripping out MSI/MSI-X and
virtio queue stuff and have something working now and my driver picks
up the events listened for by vmmci(4). Shouldn't be too far now from
having a nice, clean shutdown or restart via `vmctl stop ubuntu`. Will
share when it’s ready if systemd doesn’t prematurely end my sanity
first.
-dv
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/virtio/virtio_pci_modern.c#n193
[2]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/virtio/virtio_pci_legacy.c#n50
[3]: https://github.com/openbsd/src/blob/master/usr.sbin/vmd/virtio.c#L1667
A (partial) vmmci(4) Linux implementation
I've been experimenting with implementing something like vmmci(4) for Linux guests. It's started to prove useful to myself so maybe others will benefit, even though there are currently some caveats[1]. https://github.com/voutilad/virtio_vmmci My primary use case is keeping some Linux guests constantly running in the background under the vmm(4) hypervisor on my laptop that sees quite a few suspend (zzz)/resume cycles throughout my day. It currently consists of 2 Linux kernel modules, one representing a virtio_pci implementation handling the quirks[2] of how vmd(8) exposes the vmm control device and the other module is the actual virtio driver implementation. I've tested it with a stock Ubuntu 18.0.4 install as well as with a newer v4.20.12 tweaked Linux kernel[3] and so far seems to build and work just fine using an OpenBSD snapshot from Monday 18 Feb as the host. It doesn't yet catch shutdown or restart events, but that's my next goal since I'd like to make sure I get clean shutdowns via `vmctl stop`. -Dave [1]: https://github.com/voutilad/virtio_vmmci#current-state--known-caveats [2]: https://github.com/voutilad/virtio_vmmci#learnings-from-virtio-hacking [3]: https://github.com/voutilad/linux
Re: Best Practices python virtualenv
Ken MacKenzie writes:
> Is there a recommended best practice when setting up an environment with
> python
> virtualenv with regards to wxallowed.
AFAIK nothing official.
>
> My typical workflow is under my home directory I have a
> dev/language/project/.venv type structure. I guess the simple solution is to
> mount /home as wxallowed in /etc/fstab, but is that truly the preferred way.
> Seems to make a new attack surface for anything in home.
>
Turning off any default mitigations is probably the opposite of "preferred".
> The other option I am thinking is to create a dev-username location in
> /usr/local somewhere and then ln -s that into my home structure accordingly.
>
> Since I am new to OpenBSD I figured I would ask first and did not find much
> on
> this topic other than third parties that seem to want to casually just add
> home
> to wxallowed.
>
I've been too lazy to dig into and "fix" this in the py{2,3}-virtualenv
port. The main issue is it copies the binary for the target python
executable and doesn't symlink it. It's really not a bug and more an
adaptation issue so I've not been inclined.
However, symbolic links to /usr/local/bin/python work fine if they're
located on partitions that aren't mounted wxallowed. I'd imagine if
virtualenv created a symlink things would "just work."
So what I do, instead of teaching virtualenv to symlink instead of copy,
is just confine my virtualenvs to /usr/local/venv (owned by root:wsrc).
I then just activate via the usual means of the activate script:
kogelvis$ . /usr/local/venv/my-project/bin/activate
Typically, on other systems, I'd locate it in ~/.venv but for my
personal machine it's not an issue.
I do set an environment variable:
WORKON_HOME=/usr/local/venv
in .profile so I can configure tools like emacs major modes to point to
where I want them to create/find virtual environments.
> Thanks in advance for any guidance,
>
> Ken
Re: With the latest snapshot there are some issues in Xfce, please help!
Zsolt Kantor writes: > Hello to all. > I installed the latest snapshot with Xfce. But there are some issues whit > Xfce. I found 3 problems. > > 1. The terminal size is very expanded, it is not 80x..., its 145x..., but if > I check the terminal properties the width setting is 80. Very strange. > The XFCE terminal? Might want to check ports@. No idea if this is an upstream change or in the port itself. > 2. There are some dependency problems when I try to install chromium > or firefox. For instance the colord package can not be found in the > snapshot packages repository, and other package dependency problems > are also displayed. So I can't install Chromium or Firefox. The snapshots are a moving target given the impending release of 6.3. Are you using `pkg_add -Dsnap firefox`? You might also need to grab the most recent build of -current if libraries were bumped. A dmesg would tell people if you're up to date or not. > > 3. My synaptic touchpad is not fully functional. In Xfce the touchpad > tab is missing from the mouse and touchpad configuration window. This > is not the case of 6.2. In OpenBSD 6.2 it was there. > See note from 2017/12/05: https://www.openbsd.org/faq/current.html You probably need a custom Xorg config, but if there is regression in functionality I'm sure reporting the delta and a dmesg would be helpful. Personally I've seen some improvements, but there were initial regressions that were reported and I believe resolved or worked around. > Will these issues corrected until the release? Or should I send an e-mail to > the bug's mailing list? > > Thanks!
Re: vmd - Unable to reboot Alpine guest
"Aham Brahmasmi" writes: >> On Sun, Feb 18, 2018 at 04:23:39PM +0100, Aham Brahmasmi wrote: >> > I am unable to reboot an Alpine Linux 3.7.0 guest. I can confirm that on 6.2-current, you can reboot an Alpine 3.7.0 guest without errors. >> > >> > Tailing the /var/log/messages lists the following error messages: >> > >> > /bsd: vmx_fault_page: uvm_fault returns 14, GPA=0xa148, rip=0xf7d8a >> > vmd: vcpu_run_loop: vm 1 / vcpu 0 run ioctl failed: Bad address >> > Here's what I see on 6.2-current when doing a `sudo reboot` inside the Alpine VM via SSH very shortly after startup (timestamps trimmed for brevity): kogelvis vmd[26727]: alpine: started vm 1 successfully, tty /dev/ttyp5 kogelvis vmd[93002]: vcpu_process_com_data: guest reading com1 when not ready kogelvis last message repeated 2 times kogelvis vmd[93002]: rtc_update_rega: set non-32KHz timebase not supported kogelvis vmd[93002]: rtc_update_rega: set non-32KHz timebase not supported kogelvis vmd[26727]: alpine: started vm 1 successfully, tty /dev/ttyp5 kogelvis vmd[49571]: vcpu_process_com_data: guest reading com1 when not ready kogelvis last message repeated 2 times > From what I understand, I first need to upgrade to the latest snapshot. > From there, I need to use source build instructions at > https://www.openbsd.org/faq/faq5.html#Bld to reach -current. AFAIK, You shouldn't need to build anything from source, just do the upgrade from a recent bsd.rd and then make sure to upgrade packages and clean out old dependencies. Depending on how you've configured certain software you might need to update some configs by hand, but you shouldn't have to compile anything other than software you've had to compile yourself to install under 6.1. (Aham, sorry if my reply is a bit mangled...for some reason I can't get your original post to reply to and had to grab your reply to Carlos.) -Dave
Re: macpro boot openbsd 6.2 , but ,,,
Have you tried using rEFInd for dual or triple-booting? http://www.rodsbooks.com/refind/index.html I use it to dual-boot macOS and OpenBSD on multiple systems. The order I follow during upgrades or installs: 1) Install or upgrade macOS first because it will overwrite rEFInd if present 2) Boot into macOS Recovery Mode and install rEFInd 3) Boot OpenBSD installation media using rEFInd and perform install or upgrade 4) Reboot and OpenBSD should be selectable in rEFInd (you can customize to make it have an icon, etc. see rEFInd docs.) That's basically it at a high level. I won't go into detail about disk partitions because that's a thoroughly documented topic. On Thu, Oct 19, 2017 at 10:16 AM, Tuyosi T wrote: > sorry correction > > (wrong) > any way the previous openbsd is 6.1 . > i use legacy PC and CD(install62.fs ) and install OpenBSD area . > [ don’t touch msdos aea (wd0i)] > > (right) > any way the previous openbsd is 6.1 . > i use legacy PC and CD(install62.iso ) and install OpenBSD area . > [ don’t touch msdos aea (wd0i)] > > > and the interesting is the following > > http://blog.goo.ne.jp/kazuhirospd/e/a5cc783017c1ff2a699fce129fc72921 > says that > > The screen got dark, and SSD began to access . > What began? > I was watching the display ..., > scared out of one's wits . > It came out on the screen with a light blue Windows flag. > It is the start screen of Windows 8.1. > By the way, this SSD was what I used on the main PC until this time. > i thought it stopped with an error on the way . > but it washed up as it was. > Windows was running natively on MacPRO ! > MacOSX could not be installed with my all efforts. > but MacPRO run Windows 8.1 with no problem . > what a sarcasm it was ! > --- > but this is not the case for openbsd . > > > and > https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html > says that > -- > Intel Core 2 Duo and Xeon processors are 64-bit. However, based on reader > reports received, as well as hands-on observation, it is believed that all > Macs with 64-bit processors released in 2006 only have a 32-bit EFI, and > consequently, only are capable of booting in 32-bit mode. This is of > particular disappointment to owners of the first Mac Pro, which despite > having a powerful 64-bit processor no doubt has had its "working life" cut > short by a 32-bit EFI. > - > > > --- > regards
Re: pointing installurl to current snapshot packages path does not work
One point of information, I'm pretty sure I'm wrong in what I said here:
> Keep installurl set to the snapshots directory of the mirror.
Not only does that not make sense, but if you installed via http that
shouldn't need to be changed while using the snapshot. The -Dsnap flag
should be all you need for pkg_{info,add}.
On Sat, Oct 7, 2017 at 9:47 AM, eelco van der vlugt wrote:
> thank you for your kind support. I notice that i should have better
> read the man pages and also see that in recent other thread these
> options have been raised too.
>
> Again, my humble thanks to this awsome community.
>
> eelco
>
> On 10/7/17, Dave Voutila wrote:
>>
>> Make sure you’re using the -Dsnap flag on pkg_add and pkg_info. Keep
>> installurl set to the snapshots directory of the mirror.
>>
>>> On Oct 7, 2017, at 9:10 AM, eelco van der vlugt
>>> wrote:
>>>
>>> Hello,
>>>
>>> I installed today via usb the latest snapshot > 2017-Oct-04 03:45 from
>>> leaseweb.
>>> When setting up I chose disk as install medium, so have no installurl
>>> set up at the beginning.
>>>
>>> Now i am trying to set up installurl so i can get latest packages.
>>>
>>> I have tried following in installurl >
>>>
>>> 1 https://ftp.eu.openbsd.org/pub/OpenBSD/
>>> 2 https://ftp.eu.openbsd.org/pub/OpenBSD/snaphots
>>> 3 https://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/packages/amd64
>>>
>>> and also with other mirrors, i always get same responces in the form that
>>>
>>> https://ftp.eu.openbsd.org/pub/OpenBSD/6.2/amd64/ is not found
>>>
>>> So even when i use the installurl to point into right path, the path
>>> is being changed into 6.2 and the rest.
>>>
>>> Can anyone explain to me what i am doing wrong and how i am supposed
>>> to get with pkg_add packages on my new install,
>>>
>>> thanks for understanding maybe this simple question for some person
>>> with more experience in openbsd management.
>>>
>>> eelco
>>>
>>
Re: pointing installurl to current snapshot packages path does not work
Make sure you’re using the -Dsnap flag on pkg_add and pkg_info. Keep installurl set to the snapshots directory of the mirror. > On Oct 7, 2017, at 9:10 AM, eelco van der vlugt wrote: > > Hello, > > I installed today via usb the latest snapshot > 2017-Oct-04 03:45 from > leaseweb. > When setting up I chose disk as install medium, so have no installurl > set up at the beginning. > > Now i am trying to set up installurl so i can get latest packages. > > I have tried following in installurl > > > 1 https://ftp.eu.openbsd.org/pub/OpenBSD/ > 2 https://ftp.eu.openbsd.org/pub/OpenBSD/snaphots > 3 https://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/packages/amd64 > > and also with other mirrors, i always get same responces in the form that > > https://ftp.eu.openbsd.org/pub/OpenBSD/6.2/amd64/ is not found > > So even when i use the installurl to point into right path, the path > is being changed into 6.2 and the rest. > > Can anyone explain to me what i am doing wrong and how i am supposed > to get with pkg_add packages on my new install, > > thanks for understanding maybe this simple question for some person > with more experience in openbsd management. > > eelco >
Re: Mid-2015 MacBook Pro
Ax0n, That RTC error seems to come from a system dependent startclocks() function, but it was modified in August by jcs@ removing the logic that would even print that very error: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/arch/amd64/isa/clock.c.diff?r1=1.24&r2=1.25 Commit message mentions it's probably a red herring. In your linked pictures it looks like you're installing a 6.2 snapshot (older than 11 August?), but the image with the RTC BIOS error says 6.1. The plot is indeed thickening. :-) On Thu, Sep 21, 2017 at 10:01 PM, Ax0n wrote: > This one *should* be identical to the one I've been issued by my employer > (on which I'm running OS X) -- in that case, it has the NVidia GeForce GT > 750M and the Intel Iris Pro. The Plot Thickens. > > There's an error about /etc/boot.conf. The keyboard works fine at the FDE > prompt, and at the boot> prompt. There's an RTC BIOS diagnostic error before > the kernel loads. At the UCK prompt, the cursor is glitching and the > keyboard is unresponsive. External keyboard isn't helping. > > Photos here, if it matters: https://imgur.com/a/iL6T0 > > On Thu, Sep 21, 2017 at 7:22 PM, Dave Voutila wrote: >> >> ax0n, >> >> Is that a model with both integrated Intel gpu and dedicated Radeon >> gpu? Maybe look at drm(4) and try removing the radeon driver since the >> intel one should work fine. >> >> The intel drivers work great on my early-2015 MBP (i5 Broadwell), but >> then again it doesn't have any dedicated graphics. >> >> -Dave >> >> On Thu, Sep 21, 2017 at 6:19 PM, Ax0n wrote: >> > I have a Mid-2015 MacBook Pro that I'm trying to get OpenBSD on. I >> > installed from the latest snapshot and from -RELEASE (installXX.fs >> > written >> > to SD card). The install goes fine (using an axen(4) USB dongle for >> > connectivity) but upon reboot, it gets part way through, then the screen >> > goes blank with the backlight on. Although I can briefly see the axen(4) >> > attach, it doesn't seem to get an IP address if I let it sit around for >> > a >> > few minutes. I can't get the dmesg, and I can't determine what the last >> > message is before the screen blanks. It doesn't appear to respond to the >> > keyboard. >> > >> > Has anyone gotten this working? Google is pointing me to a few posts >> > from >> > the likes of jcs@ and others about systems that are either slightly >> > newer >> > or slightly older than mine. Any suggestions on getting a good dmesg out >> > of >> > it? Devices I should consider disabling from UKC to get this thing off >> > the >> > ground? >> > >> > TIA- >> > ax0n > >
Re: Mid-2015 MacBook Pro
ax0n, Is that a model with both integrated Intel gpu and dedicated Radeon gpu? Maybe look at drm(4) and try removing the radeon driver since the intel one should work fine. The intel drivers work great on my early-2015 MBP (i5 Broadwell), but then again it doesn't have any dedicated graphics. -Dave On Thu, Sep 21, 2017 at 6:19 PM, Ax0n wrote: > I have a Mid-2015 MacBook Pro that I'm trying to get OpenBSD on. I > installed from the latest snapshot and from -RELEASE (installXX.fs written > to SD card). The install goes fine (using an axen(4) USB dongle for > connectivity) but upon reboot, it gets part way through, then the screen > goes blank with the backlight on. Although I can briefly see the axen(4) > attach, it doesn't seem to get an IP address if I let it sit around for a > few minutes. I can't get the dmesg, and I can't determine what the last > message is before the screen blanks. It doesn't appear to respond to the > keyboard. > > Has anyone gotten this working? Google is pointing me to a few posts from > the likes of jcs@ and others about systems that are either slightly newer > or slightly older than mine. Any suggestions on getting a good dmesg out of > it? Devices I should consider disabling from UKC to get this thing off the > ground? > > TIA- > ax0n
Re: [vmd] SVM flag on AMD Phenom II but vmd not working
Philippe, > When I try to install Alpine Linux, I can't even see the first step of > the installer. What command and arguments are you using to start the Alpine vm and which Alpine version are you using? You should at least get the "boot:" prompt via syslinux when attached via the serial console. I've spent a lot of time installing and using Alpine lately so I might be of some help. (Also, you might want to start with the "virt" iso from Alpine as it's pre-configured to use the serial console at boot.) > The only elements I have in the /var/log/daemon file are: > > Sep 17 15:49:59 vache vmd[69998]: SIOCBRDGADD: No such file or directory What arguments are you using to start the vm and what do you have defined in vm.conf? This looks to be a failure to add a network device to the bridge that vmd configures. > > How to make this easier to debug? Where can I find useful information? > You can increase verbosity by setting the flag "-v" on vmd via rcctl, or running vmd interactively using "-d" along with one or more "-v". See the vmd(8) man page. I believe you can also set verbosity via `vmctl log verbose` but I've never done that at runtime. -Dave
Re: VMM Serial Console issues with Alpine Linux in -current
Well this is embarrassing. Let's just say "console=ttyS0,115200" is not the same as "console=/dev/ttyS0,115200". Definitely user error. Sorry, Mike! On Sun, Sep 10, 2017 at 10:22 AM, Dave Voutila wrote: > Mike, > > Must be something specific to my machine as it's still not working for > me. I tried an upgrade and then a completely fresh install of the > snapshot from yesterday. I still see the same behavior across > different Alpine flavors. > > If I have some spare time this week I'll try to roll a custom Alpine > iso that boots with full debug logging to see if I can shed any light > on this issue. > > If anyone else has a MacBook Pro 12,1 model with i5-5257U CPU, I'm > curious if they too have the problem. > > -Dave > > On Tue, Sep 5, 2017 at 10:22 AM, Dave Voutila wrote: >> I'm away from that system for the next few days, but will be able to >> try again this weekend. >> >> I'll upgrade to the latest snapshot, grab the same exact Alpine iso, >> and try using your vmctl parameters. >> >> >> On Tue, Sep 5, 2017 at 12:46 AM, Mike Larkin wrote: >>> On Tue, Sep 05, 2017 at 12:20:58AM -0700, Mike Larkin wrote: >>>> On Sun, Sep 03, 2017 at 10:22:07PM -0700, Mike Larkin wrote: >>>> > On Sun, Sep 03, 2017 at 03:03:22PM -0400, Dave Voutila wrote: >>>> > > Decided to test using the "virt" Alpine build and it creates the error >>>> > > I alluded to but couldn't remember. Login as root succeeds, but when >>>> > > it tries to properly exec busybox's ash process it errors out with: >>>> > > >>>> > > -ash: can't access tty; job control turned off >>>> > > >>>> > > Still results in writing the prompt, but ash appears to exit and >>>> > > return you to the login prompt. >>>> > > >>>> > > Looking into the source for busybox, it seems to be triggered here: >>>> > > https://git.busybox.net/busybox/tree/shell/ash.c?h=1_27_stable#n3857 >>>> > > >>>> > > The call is to tcgetpgrp(3) trying to get the process group for the >>>> > > TTY file descriptor. >>>> > > >>>> > > I'm a wee bit in over my head at this point, but figured I'd share the >>>> > > latest. I'm honestly not sure if this is an issue with Alpine, but I >>>> > > think if I can get it to work with a serial console in QEMU then it's >>>> > > possibly a deficiency in VMD/SeaBIOS. >>>> > > >>>> > > -Dave Voutila >>>> > > >>>> > >>>> > shrug. nobody else has reported any issues at all with alpine. as a >>>> > matter >>>> > of fact it was the first linux distribution we got working and is part >>>> > of my set of VMs I test with regularly. >>>> > >>>> > -ml >>>> > >>>> >>>> Just to make sure there wasn't something odd going on, I reproduced this >>>> test >>>> using the standard alpine ISO just now using -current: >>>> >>>> # vmctl start test -i 1 -d >>>> /home/mlarkin/Downloads/alpine-standard-3.6.2-x86_64.iso -d test.raw -m >>>> 1024M -c >>>> >>>> At the boot: prompt, I used: >>>> >>>> boot: hardened console=ttyS0,115200 >>>> >>>> >>>> Alpine then booted as follows: >>>> >>>> [0.00] ACPI BIOS Error (bug): A valid RSDP was not found >>>> (20160831/tbxfroot-244) >>>> [0.08] ACPI BIOS Error (bug): A valid RSDP was not found >>>> (20160831/tbxfroot-244) >>>> [0.08] dmi: Firmware registration failed. >>>> >>>> >>>>OpenRC 0.24.1.faeb98e61b is starting up Linux 4.9.32-0-hardened (x86_64) >>>> >>>> * /proc is already mounted >>>> * Mounting /run ... * /run/openrc: creating directory >>>> * /run/lock: creating directory >>>> * /run/lock: correcting owner >>>> * Caching service dependencies ... [ ok ] >>>> * Remounting devtmpfs on /dev ... [ ok ] >>>> * Mounting /dev/mqueue ... [ ok ] >>>> * Mounting modloop ... [ ok ] >>>> * Mounting security filesystem ... [ ok ] >>>> * Mounting persistent storage (pstore) filesystem ... [ ok ] >>>> * Mounting cgroup filesystem ..
Re: VMM Serial Console issues with Alpine Linux in -current
Mike, Must be something specific to my machine as it's still not working for me. I tried an upgrade and then a completely fresh install of the snapshot from yesterday. I still see the same behavior across different Alpine flavors. If I have some spare time this week I'll try to roll a custom Alpine iso that boots with full debug logging to see if I can shed any light on this issue. If anyone else has a MacBook Pro 12,1 model with i5-5257U CPU, I'm curious if they too have the problem. -Dave On Tue, Sep 5, 2017 at 10:22 AM, Dave Voutila wrote: > I'm away from that system for the next few days, but will be able to > try again this weekend. > > I'll upgrade to the latest snapshot, grab the same exact Alpine iso, > and try using your vmctl parameters. > > > On Tue, Sep 5, 2017 at 12:46 AM, Mike Larkin wrote: >> On Tue, Sep 05, 2017 at 12:20:58AM -0700, Mike Larkin wrote: >>> On Sun, Sep 03, 2017 at 10:22:07PM -0700, Mike Larkin wrote: >>> > On Sun, Sep 03, 2017 at 03:03:22PM -0400, Dave Voutila wrote: >>> > > Decided to test using the "virt" Alpine build and it creates the error >>> > > I alluded to but couldn't remember. Login as root succeeds, but when >>> > > it tries to properly exec busybox's ash process it errors out with: >>> > > >>> > > -ash: can't access tty; job control turned off >>> > > >>> > > Still results in writing the prompt, but ash appears to exit and >>> > > return you to the login prompt. >>> > > >>> > > Looking into the source for busybox, it seems to be triggered here: >>> > > https://git.busybox.net/busybox/tree/shell/ash.c?h=1_27_stable#n3857 >>> > > >>> > > The call is to tcgetpgrp(3) trying to get the process group for the >>> > > TTY file descriptor. >>> > > >>> > > I'm a wee bit in over my head at this point, but figured I'd share the >>> > > latest. I'm honestly not sure if this is an issue with Alpine, but I >>> > > think if I can get it to work with a serial console in QEMU then it's >>> > > possibly a deficiency in VMD/SeaBIOS. >>> > > >>> > > -Dave Voutila >>> > > >>> > >>> > shrug. nobody else has reported any issues at all with alpine. as a matter >>> > of fact it was the first linux distribution we got working and is part >>> > of my set of VMs I test with regularly. >>> > >>> > -ml >>> > >>> >>> Just to make sure there wasn't something odd going on, I reproduced this >>> test >>> using the standard alpine ISO just now using -current: >>> >>> # vmctl start test -i 1 -d >>> /home/mlarkin/Downloads/alpine-standard-3.6.2-x86_64.iso -d test.raw -m >>> 1024M -c >>> >>> At the boot: prompt, I used: >>> >>> boot: hardened console=ttyS0,115200 >>> >>> >>> Alpine then booted as follows: >>> >>> [0.00] ACPI BIOS Error (bug): A valid RSDP was not found >>> (20160831/tbxfroot-244) >>> [0.08] ACPI BIOS Error (bug): A valid RSDP was not found >>> (20160831/tbxfroot-244) >>> [0.08] dmi: Firmware registration failed. >>> >>> >>>OpenRC 0.24.1.faeb98e61b is starting up Linux 4.9.32-0-hardened (x86_64) >>> >>> * /proc is already mounted >>> * Mounting /run ... * /run/openrc: creating directory >>> * /run/lock: creating directory >>> * /run/lock: correcting owner >>> * Caching service dependencies ... [ ok ] >>> * Remounting devtmpfs on /dev ... [ ok ] >>> * Mounting /dev/mqueue ... [ ok ] >>> * Mounting modloop ... [ ok ] >>> * Mounting security filesystem ... [ ok ] >>> * Mounting persistent storage (pstore) filesystem ... [ ok ] >>> * Mounting cgroup filesystem ... [ ok ] >>> * Starting busybox mdev ... [ ok ] >>> * Loading hardware drivers ... [ ok ] >>> * Loading modules ... [ ok ] >>> * Setting system clock using the hardware clock [UTC] ... [ ok ] >>> * Checking local filesystems ... [ ok ] >>> * Remounting filesystems ... [ ok ] >>> * Mounting local filesystems ... [ ok ] >>> * Configuring kernel parameters ... [ ok ] >>> * Migrating /var/lock to /run/lock ... [ ok ] >>> * Migrating /var/run to /run ... [ ok ] >>> * Creating user login records ... [ ok ] >>> * Wipi
Re: VMM Serial Console issues with Alpine Linux in -current
I'm away from that system for the next few days, but will be able to try again this weekend. I'll upgrade to the latest snapshot, grab the same exact Alpine iso, and try using your vmctl parameters. On Tue, Sep 5, 2017 at 12:46 AM, Mike Larkin wrote: > On Tue, Sep 05, 2017 at 12:20:58AM -0700, Mike Larkin wrote: >> On Sun, Sep 03, 2017 at 10:22:07PM -0700, Mike Larkin wrote: >> > On Sun, Sep 03, 2017 at 03:03:22PM -0400, Dave Voutila wrote: >> > > Decided to test using the "virt" Alpine build and it creates the error >> > > I alluded to but couldn't remember. Login as root succeeds, but when >> > > it tries to properly exec busybox's ash process it errors out with: >> > > >> > > -ash: can't access tty; job control turned off >> > > >> > > Still results in writing the prompt, but ash appears to exit and >> > > return you to the login prompt. >> > > >> > > Looking into the source for busybox, it seems to be triggered here: >> > > https://git.busybox.net/busybox/tree/shell/ash.c?h=1_27_stable#n3857 >> > > >> > > The call is to tcgetpgrp(3) trying to get the process group for the >> > > TTY file descriptor. >> > > >> > > I'm a wee bit in over my head at this point, but figured I'd share the >> > > latest. I'm honestly not sure if this is an issue with Alpine, but I >> > > think if I can get it to work with a serial console in QEMU then it's >> > > possibly a deficiency in VMD/SeaBIOS. >> > > >> > > -Dave Voutila >> > > >> > >> > shrug. nobody else has reported any issues at all with alpine. as a matter >> > of fact it was the first linux distribution we got working and is part >> > of my set of VMs I test with regularly. >> > >> > -ml >> > >> >> Just to make sure there wasn't something odd going on, I reproduced this test >> using the standard alpine ISO just now using -current: >> >> # vmctl start test -i 1 -d >> /home/mlarkin/Downloads/alpine-standard-3.6.2-x86_64.iso -d test.raw -m >> 1024M -c >> >> At the boot: prompt, I used: >> >> boot: hardened console=ttyS0,115200 >> >> >> Alpine then booted as follows: >> >> [0.00] ACPI BIOS Error (bug): A valid RSDP was not found >> (20160831/tbxfroot-244) >> [0.08] ACPI BIOS Error (bug): A valid RSDP was not found >> (20160831/tbxfroot-244) >> [0.08] dmi: Firmware registration failed. >> >> >>OpenRC 0.24.1.faeb98e61b is starting up Linux 4.9.32-0-hardened (x86_64) >> >> * /proc is already mounted >> * Mounting /run ... * /run/openrc: creating directory >> * /run/lock: creating directory >> * /run/lock: correcting owner >> * Caching service dependencies ... [ ok ] >> * Remounting devtmpfs on /dev ... [ ok ] >> * Mounting /dev/mqueue ... [ ok ] >> * Mounting modloop ... [ ok ] >> * Mounting security filesystem ... [ ok ] >> * Mounting persistent storage (pstore) filesystem ... [ ok ] >> * Mounting cgroup filesystem ... [ ok ] >> * Starting busybox mdev ... [ ok ] >> * Loading hardware drivers ... [ ok ] >> * Loading modules ... [ ok ] >> * Setting system clock using the hardware clock [UTC] ... [ ok ] >> * Checking local filesystems ... [ ok ] >> * Remounting filesystems ... [ ok ] >> * Mounting local filesystems ... [ ok ] >> * Configuring kernel parameters ... [ ok ] >> * Migrating /var/lock to /run/lock ... [ ok ] >> * Migrating /var/run to /run ... [ ok ] >> * Creating user login records ... [ ok ] >> * Wiping /tmp directory ... [ ok ] >> * Setting hostname ... [ ok ] >> * Starting busybox klogd ... [ ok ] >> * Starting busybox syslog ... [ ok ] >> >> Welcome to Alpine Linux 3.6 >> Kernel 4.9.32-0-hardened on an x86_64 (/dev/ttyS0) >> >> localhost login: root >> Welcome to Alpine! >> >> The Alpine Wiki contains a large amount of how-to guides and general >> information about administrating Alpine systems. >> See <http://wiki.alpinelinux.org>. >> >> You can setup the system with the command: setup-alpine >> >> You may change this message by editing /etc/motd. >> >> localhost:~# >> >> >> ... I then went on to install the system using setup-alpine and the docs >> from the alpine web site. No issues were seen, and the system booted up >> subsequently without the ISO (of course, after setting serial console >> in the boot config). >> >> I am going to pull down a snapshot and retest to see if there is something >> that may have snuck in that's not in my tree. >> >> -ml >> > > I just upgraded to this snap: > > OpenBSD 6.2-beta (GENERIC.MP) #70: Tue Sep 5 00:00:55 MDT 2017 > > and I had the same result as I just posted. No issues seen. > > Can you try to upgrade to the latest snap and try using a command line > like mine and see if this is still a problem? Otherwise I'm not sure why > your machine is behaving incorrectly. > > -ml
Re: VMM Serial Console issues with Alpine Linux in -current
Mike, Thanks for the reply. Unfortunately, this is during the initial Alpine iso boot _before_ a new user is created. Hence root is the only user in existance during login per their installation instructions (per https://wiki.alpinelinux.org/wiki/Installation). I dug a little further and found that using an older Alpine release (3.5.2) does not exhibit the same issues. It boots the install iso's fine and doesn't trigger the busybox ash error or the generic login error trying to spawn the tty after login. For reference, there's a pretty big Linux kernel jump between those Alpine releases: Alpine 3.5.2 - Linux kernel 4.4.59, busybox 1.25.1 Alpine 3.6.2 - Linux kernel 4.9.32, busybox 1.26.2 I've got Alpine 3.5.2 working and think I will try upgrading busybox first. If it still works I'll see if I can install a few different Linux kernels in the VM to select at boot to try to find the version that might be related to the problem I see in Alpine 3.6.2. (Also, I had self-replied previously with my busybox ash error before seeing your response thanks to Google spam filtering. Sorry for any confusion.) Thanks, -Dave On Sun, Sep 3, 2017 at 1:15 PM, Mike Larkin wrote: > On Sun, Sep 03, 2017 at 12:41:31PM -0400, Dave Voutila wrote: >> Hi misc@, >> >> I'm using the latest AMD64 snapshot from 2017-09-02 and can no longer >> log into an Alpine Linux VM. (This was working with a previous >> snapshot from a few days ago.) >> >> Currently I'm using the "vanilla" image from >> https://www.alpinelinux.org/downloads/ >> >> I've removed any presence of /etc/vm.conf so the only options are >> those I give at start. Here's the command: >> >> $ doas vmctl start alpine -Lc -d iso/alpine-vanilla-3.6.2-x86_64.iso -m 1G >> >> When it gets to the EXTLINUX boot loader, I'm explicitly passing in >> console=/dev/ttyS0,115200 (I've tried other baud rates as well to no >> avail). >> >> I do get to the Alpine Linux login prompt, however trying to login as >> root results in "Login incorrect." One of these attempts I did get an > > By default, alpine doesn't allow this. Log in as the user you created > during install and use su/sudo. > >> error saying something about not being able to open some device...so >> this has me believing it's either a VMM issue or maybe SeaBIOS issue. > > No. > >> This should be (and previously was working with) a password-less login >> for root. I'm not familiar enough with how Linux might be trying to >> spawn whatever thing it needs for the session after login, but my >> guess is it's failing in the background and giving me a generic error. >> >> [Note: as a sanity check, I can boot the same Alpine Linux ISO using >> QEMU and the password-less root login does work.] >> >> I've captured VMD's debug output during this using `vmd -d ` as follows: >> >> startup >> failed to open /etc/vm.conf: No such file or directory >> vm_opentty: vm alpine tty /dev/ttyp2 uid 0 gid 4 mode 620 >> vm_priv_ifconfig: interface tap0 description vm1-if0-alpine >> vm_priv_ifconfig: interface tap0 address 100.64.1.2/31 >> alpine: started vm 1 successfully, tty /dev/ttyp2 >> loadfile_bios: loaded BIOS image >> run_vm: initializing hardware for vm alpine >> virtio_init: vm "alpine" vio0 lladdr fe:e1:bb:d1:21:cc, local >> run_vm: starting vcpu threads for vm alpine >> vcpu_reset: resetting vcpu 0 for vm 1 >> run_vm: waiting on events for VM alpine >> i8259_write_datareg: master pic, reset IRQ vector to 0x8 >> i8259_write_datareg: slave pic, reset IRQ vector to 0x70 >> vcpu_exit_i8253: channel 0 reset, mode=0, start=65535 >> virtio_blk_io: device reset >> vcpu_process_com_lcr: set baudrate = 115200 >> i8259_write_datareg: master pic, reset IRQ vector to 0x30 >> i8259_write_datareg: slave pic, reset IRQ vector to 0x38 >> vcpu_exit_i8253: channel 0 reset, mode=7, start=3977 >> vcpu_exit_i8253: channel 2 reset, mode=7, start=65535 >> vcpu_exit_i8253: channel 2 reset, mode=7, start=65535 >> vcpu_exit_i8253: channel 2 reset, mode=7, start=65535 >> vcpu_exit_i8253: channel 2 reset, mode=7, start=65535 >> vcpu_process_com_lcr: set baudrate = 115200 >> vcpu_process_com_data: guest reading com1 when not ready >> virtio_blk_io: device reset >> virtio_net_io: device reset >> vcpu_process_com_data: guest reading com1 when not ready >> vcpu_process_com_data: guest reading com1 when not ready >> vcpu_process_com_lcr: set baudrate = 9600 >> vcpu_process_com_data: guest reading com1 when not ready >> vcpu_process_com_
Re: VMM Serial Console issues with Alpine Linux in -current
Decided to test using the "virt" Alpine build and it creates the error I alluded to but couldn't remember. Login as root succeeds, but when it tries to properly exec busybox's ash process it errors out with: -ash: can't access tty; job control turned off Still results in writing the prompt, but ash appears to exit and return you to the login prompt. Looking into the source for busybox, it seems to be triggered here: https://git.busybox.net/busybox/tree/shell/ash.c?h=1_27_stable#n3857 The call is to tcgetpgrp(3) trying to get the process group for the TTY file descriptor. I'm a wee bit in over my head at this point, but figured I'd share the latest. I'm honestly not sure if this is an issue with Alpine, but I think if I can get it to work with a serial console in QEMU then it's possibly a deficiency in VMD/SeaBIOS. -Dave Voutila On Sun, Sep 3, 2017 at 12:41 PM, Dave Voutila wrote: > Hi misc@, > > I'm using the latest AMD64 snapshot from 2017-09-02 and can no longer > log into an Alpine Linux VM. (This was working with a previous > snapshot from a few days ago.) > > Currently I'm using the "vanilla" image from > https://www.alpinelinux.org/downloads/ > > I've removed any presence of /etc/vm.conf so the only options are > those I give at start. Here's the command: > > $ doas vmctl start alpine -Lc -d iso/alpine-vanilla-3.6.2-x86_64.iso -m 1G > > When it gets to the EXTLINUX boot loader, I'm explicitly passing in > console=/dev/ttyS0,115200 (I've tried other baud rates as well to no > avail). > > I do get to the Alpine Linux login prompt, however trying to login as > root results in "Login incorrect." One of these attempts I did get an > error saying something about not being able to open some device...so > this has me believing it's either a VMM issue or maybe SeaBIOS issue. > This should be (and previously was working with) a password-less login > for root. I'm not familiar enough with how Linux might be trying to > spawn whatever thing it needs for the session after login, but my > guess is it's failing in the background and giving me a generic error. > > [Note: as a sanity check, I can boot the same Alpine Linux ISO using > QEMU and the password-less root login does work.] > > I've captured VMD's debug output during this using `vmd -d ` as follows: > > startup > failed to open /etc/vm.conf: No such file or directory > vm_opentty: vm alpine tty /dev/ttyp2 uid 0 gid 4 mode 620 > vm_priv_ifconfig: interface tap0 description vm1-if0-alpine > vm_priv_ifconfig: interface tap0 address 100.64.1.2/31 > alpine: started vm 1 successfully, tty /dev/ttyp2 > loadfile_bios: loaded BIOS image > run_vm: initializing hardware for vm alpine > virtio_init: vm "alpine" vio0 lladdr fe:e1:bb:d1:21:cc, local > run_vm: starting vcpu threads for vm alpine > vcpu_reset: resetting vcpu 0 for vm 1 > run_vm: waiting on events for VM alpine > i8259_write_datareg: master pic, reset IRQ vector to 0x8 > i8259_write_datareg: slave pic, reset IRQ vector to 0x70 > vcpu_exit_i8253: channel 0 reset, mode=0, start=65535 > virtio_blk_io: device reset > vcpu_process_com_lcr: set baudrate = 115200 > i8259_write_datareg: master pic, reset IRQ vector to 0x30 > i8259_write_datareg: slave pic, reset IRQ vector to 0x38 > vcpu_exit_i8253: channel 0 reset, mode=7, start=3977 > vcpu_exit_i8253: channel 2 reset, mode=7, start=65535 > vcpu_exit_i8253: channel 2 reset, mode=7, start=65535 > vcpu_exit_i8253: channel 2 reset, mode=7, start=65535 > vcpu_exit_i8253: channel 2 reset, mode=7, start=65535 > vcpu_process_com_lcr: set baudrate = 115200 > vcpu_process_com_data: guest reading com1 when not ready > virtio_blk_io: device reset > virtio_net_io: device reset > vcpu_process_com_data: guest reading com1 when not ready > vcpu_process_com_data: guest reading com1 when not ready > vcpu_process_com_lcr: set baudrate = 9600 > vcpu_process_com_data: guest reading com1 when not ready > vcpu_process_com_data: guest reading com1 when not ready > vcpu_process_com_data: guest reading com1 when not ready > vcpu_process_com_lcr: set baudrate = 9600 > vcpu_process_com_lcr: set baudrate = 115200 > alpine: vcpu_assert_pic_irq: can't assert INTR > control exiting, pid 63145 > priv exiting, pid 27770 > vmm exiting, pid 67773 > parent terminating > - > > My dmesg output is attached since it's longer. > > Any thoughts or suggestions would be appreciated! My current plan is > to wait a few days and try another snapshot. In the mean time I may > dig into the login process for Alpine and see if I can better > understand what it tries to do. > > Thanks, > Dave Voutila
VMM Serial Console issues with Alpine Linux in -current
Hi misc@, I'm using the latest AMD64 snapshot from 2017-09-02 and can no longer log into an Alpine Linux VM. (This was working with a previous snapshot from a few days ago.) Currently I'm using the "vanilla" image from https://www.alpinelinux.org/downloads/ I've removed any presence of /etc/vm.conf so the only options are those I give at start. Here's the command: $ doas vmctl start alpine -Lc -d iso/alpine-vanilla-3.6.2-x86_64.iso -m 1G When it gets to the EXTLINUX boot loader, I'm explicitly passing in console=/dev/ttyS0,115200 (I've tried other baud rates as well to no avail). I do get to the Alpine Linux login prompt, however trying to login as root results in "Login incorrect." One of these attempts I did get an error saying something about not being able to open some device...so this has me believing it's either a VMM issue or maybe SeaBIOS issue. This should be (and previously was working with) a password-less login for root. I'm not familiar enough with how Linux might be trying to spawn whatever thing it needs for the session after login, but my guess is it's failing in the background and giving me a generic error. [Note: as a sanity check, I can boot the same Alpine Linux ISO using QEMU and the password-less root login does work.] I've captured VMD's debug output during this using `vmd -d ` as follows: startup failed to open /etc/vm.conf: No such file or directory vm_opentty: vm alpine tty /dev/ttyp2 uid 0 gid 4 mode 620 vm_priv_ifconfig: interface tap0 description vm1-if0-alpine vm_priv_ifconfig: interface tap0 address 100.64.1.2/31 alpine: started vm 1 successfully, tty /dev/ttyp2 loadfile_bios: loaded BIOS image run_vm: initializing hardware for vm alpine virtio_init: vm "alpine" vio0 lladdr fe:e1:bb:d1:21:cc, local run_vm: starting vcpu threads for vm alpine vcpu_reset: resetting vcpu 0 for vm 1 run_vm: waiting on events for VM alpine i8259_write_datareg: master pic, reset IRQ vector to 0x8 i8259_write_datareg: slave pic, reset IRQ vector to 0x70 vcpu_exit_i8253: channel 0 reset, mode=0, start=65535 virtio_blk_io: device reset vcpu_process_com_lcr: set baudrate = 115200 i8259_write_datareg: master pic, reset IRQ vector to 0x30 i8259_write_datareg: slave pic, reset IRQ vector to 0x38 vcpu_exit_i8253: channel 0 reset, mode=7, start=3977 vcpu_exit_i8253: channel 2 reset, mode=7, start=65535 vcpu_exit_i8253: channel 2 reset, mode=7, start=65535 vcpu_exit_i8253: channel 2 reset, mode=7, start=65535 vcpu_exit_i8253: channel 2 reset, mode=7, start=65535 vcpu_process_com_lcr: set baudrate = 115200 vcpu_process_com_data: guest reading com1 when not ready virtio_blk_io: device reset virtio_net_io: device reset vcpu_process_com_data: guest reading com1 when not ready vcpu_process_com_data: guest reading com1 when not ready vcpu_process_com_lcr: set baudrate = 9600 vcpu_process_com_data: guest reading com1 when not ready vcpu_process_com_data: guest reading com1 when not ready vcpu_process_com_data: guest reading com1 when not ready vcpu_process_com_lcr: set baudrate = 9600 vcpu_process_com_lcr: set baudrate = 115200 alpine: vcpu_assert_pic_irq: can't assert INTR control exiting, pid 63145 priv exiting, pid 27770 vmm exiting, pid 67773 parent terminating - My dmesg output is attached since it's longer. Any thoughts or suggestions would be appreciated! My current plan is to wait a few days and try another snapshot. In the mean time I may dig into the login process for Alpine and see if I can better understand what it tries to do. Thanks, Dave Voutila dmesg-2017-09-03 Description: Binary data
