Re: ls in color
On Fri, 2023-12-08 at 19:45 +0100, Karel Lucas wrote: > > > Op 08-12-2023 om 19:42 schreef Theo de Raadt: > > Karel Lucas wrote: > > > > > In openBSD V7.4 I would like to see the output of ls in color, > > > and > > > therefore would like to know how to configure that. The output of > > > "man > > > ls" provides no information about this. Can anyone give me a tip? > > Black and white are also colours. > > > That is not what I had in mind! > You can install colorls and alias it to ls. https://openports.pl/path/sysutils/colorls -- David
Re: VMs not rebooting
Dave Voutila writes: > "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. > Removing the boot device directive worked. I didn't have to remove the cdrom specification though. Thank you. I appreciate 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: 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: VMs not rebooting
Mike Larkin writes: > On Sun, Dec 10, 2023 at 03:16:22PM -0600, Robert B. Carleton wrote: >> Mike Larkin writes: >> >> > On Sun, Dec 10, 2023 at 01:03:27PM -0600, Robert B. Carleton wrote: >> >> 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 >> >> interface { switch "int_switch" } >> >> interface { switch "ext_switch" } >> >> } >> >> >> > >> > I've not heard of anyone else having reboot vs shutdown issues recently. >> > I just did a shutdown -r now on my local machine and it works here: >> > >> > >> > -vmmtech- /var/www/logs# shutdown -r now >> > Shutdown NOW! >> > shutdown: [pid 95485] >> > >> > *** FINAL System shutdown message from root *** >> > System going down IMMEDIATELY >> > >> > >> > -vmmtech- /var/www/logs# >> > System shutdown time has arrived >> > >> > -vmmtech- /var/www/logs# syncing disks... done >> > vmmci0: powerdown >> > rebooting... >> > >> > >> > >> > Using drive 0, partition 3. >> > Loading.. >> > probing: pc0 com0 mem[638K 3838M 256M a20=on] >> > disk: hd0+ >> >>> OpenBSD/amd64 BOOT 3.65 >> > \ >> > com0: 115200 baud >> > switching console to com0 >> >>> OpenBSD/amd64 BOOT 3.65 >> > boot> >> > - >> > >> >> 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. >> > >> > harmless >> > >> >> >> >> 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. >> >> >> > >> > amd64 guest or i386? >> >> The guests are amd64. Here's a transcript, including a pause to allow >> the boot reordering to finish: >> >> === start transcript === >> athena$ doas vmctl start batch2 >> vmctl: started vm 1 successfully, tty /dev/ttyp2 >> athena$ doas vmctl console batch2 >> Connected to /dev/ttyp2 (speed 115200) >> >> >> OpenBSD/amd64 (batch2.rbcarleton.net) (tty00) >> >> login: root >> Password: >> Last login: Sun Dec 10 14:58:05 on tty00 >> OpenBSD 7.4 (GENERIC) #2: Fri Dec 8 15:38:40 MST 2023 >> >> Welcome to OpenBSD: The proactively secure Unix-like operating system. >> >> Please use the sendbug(1) utility to report bugs in the system. >> Before reporting a bug, please try to reproduce it with the latest >> version of the code. With bug reports, please try to ensure that >> enough information to reproduce the problem is enclosed, and if a >> known fix for it exists, include that as well. >> >> You have mail. >> batch2# shutdown -r now >> Shutdown NOW! >> shutdown: [pid 47954] >> >> *** FINAL System shutdown message from r...@batch2.rbcarleton.net *** >> System going down IMMEDIATELY >> >> >> batch2# >> System shutdown time has arrived >> >> batch2# syncing disks... done >> vmmci0: powerdown >> rebooting... >> >> [EOT] >> athena$ >> === end transcript === >> >> A note I'll add is that I don't recall getting the EOT at the end of the >> transcript >> until I hit the enter key. >> > > I don't think it will matter much but can you send a host dmesg? Either reply > here or use sendbug. I sent the dmesg off the mailing list. Thanks for taking a look.
Re: VMs not rebooting
On Sun, Dec 10, 2023 at 03:16:22PM -0600, Robert B. Carleton wrote: > Mike Larkin writes: > > > On Sun, Dec 10, 2023 at 01:03:27PM -0600, Robert B. Carleton wrote: > >> 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 > >> interface { switch "int_switch" } > >> interface { switch "ext_switch" } > >> } > >> > > > > I've not heard of anyone else having reboot vs shutdown issues recently. > > I just did a shutdown -r now on my local machine and it works here: > > > > > > -vmmtech- /var/www/logs# shutdown -r now > > Shutdown NOW! > > shutdown: [pid 95485] > > > > *** FINAL System shutdown message from root *** > > System going down IMMEDIATELY > > > > > > -vmmtech- /var/www/logs# > > System shutdown time has arrived > > > > -vmmtech- /var/www/logs# syncing disks... done > > vmmci0: powerdown > > rebooting... > > > > > > > > Using drive 0, partition 3. > > Loading.. > > probing: pc0 com0 mem[638K 3838M 256M a20=on] > > disk: hd0+ > >>> OpenBSD/amd64 BOOT 3.65 > > \ > > com0: 115200 baud > > switching console to com0 > >>> OpenBSD/amd64 BOOT 3.65 > > boot> > > - > > > >> 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. > > > > harmless > > > >> > >> 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. > >> > > > > amd64 guest or i386? > > The guests are amd64. Here's a transcript, including a pause to allow > the boot reordering to finish: > > === start transcript === > athena$ doas vmctl start batch2 > vmctl: started vm 1 successfully, tty /dev/ttyp2 > athena$ doas vmctl console batch2 > Connected to /dev/ttyp2 (speed 115200) > > > OpenBSD/amd64 (batch2.rbcarleton.net) (tty00) > > login: root > Password: > Last login: Sun Dec 10 14:58:05 on tty00 > OpenBSD 7.4 (GENERIC) #2: Fri Dec 8 15:38:40 MST 2023 > > Welcome to OpenBSD: The proactively secure Unix-like operating system. > > Please use the sendbug(1) utility to report bugs in the system. > Before reporting a bug, please try to reproduce it with the latest > version of the code. With bug reports, please try to ensure that > enough information to reproduce the problem is enclosed, and if a > known fix for it exists, include that as well. > > You have mail. > batch2# shutdown -r now > Shutdown NOW! > shutdown: [pid 47954] > > *** FINAL System shutdown message from r...@batch2.rbcarleton.net *** > System going down IMMEDIATELY > > > batch2# > System shutdown time has arrived > > batch2# syncing disks... done > vmmci0: powerdown > rebooting... > > [EOT] > athena$ > === end transcript === > > A note I'll add is that I don't recall getting the EOT at the end of the > transcript > until I hit the enter key. > I don't think it will matter much but can you send a host dmesg? Either reply here or use sendbug.
Re: VMs not rebooting
Mike Larkin writes: > On Sun, Dec 10, 2023 at 01:03:27PM -0600, Robert B. Carleton wrote: >> 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 >> interface { switch "int_switch" } >> interface { switch "ext_switch" } >> } >> > > I've not heard of anyone else having reboot vs shutdown issues recently. > I just did a shutdown -r now on my local machine and it works here: > > > -vmmtech- /var/www/logs# shutdown -r now > Shutdown NOW! > shutdown: [pid 95485] > > *** FINAL System shutdown message from root *** > System going down IMMEDIATELY > > > -vmmtech- /var/www/logs# > System shutdown time has arrived > > -vmmtech- /var/www/logs# syncing disks... done > vmmci0: powerdown > rebooting... > > > > Using drive 0, partition 3. > Loading.. > probing: pc0 com0 mem[638K 3838M 256M a20=on] > disk: hd0+ >>> OpenBSD/amd64 BOOT 3.65 > \ > com0: 115200 baud > switching console to com0 >>> OpenBSD/amd64 BOOT 3.65 > boot> > - > >> 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. > > harmless > >> >> 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. >> > > amd64 guest or i386? The guests are amd64. Here's a transcript, including a pause to allow the boot reordering to finish: === start transcript === athena$ doas vmctl start batch2 vmctl: started vm 1 successfully, tty /dev/ttyp2 athena$ doas vmctl console batch2 Connected to /dev/ttyp2 (speed 115200) OpenBSD/amd64 (batch2.rbcarleton.net) (tty00) login: root Password: Last login: Sun Dec 10 14:58:05 on tty00 OpenBSD 7.4 (GENERIC) #2: Fri Dec 8 15:38:40 MST 2023 Welcome to OpenBSD: The proactively secure Unix-like operating system. Please use the sendbug(1) utility to report bugs in the system. Before reporting a bug, please try to reproduce it with the latest version of the code. With bug reports, please try to ensure that enough information to reproduce the problem is enclosed, and if a known fix for it exists, include that as well. You have mail. batch2# shutdown -r now Shutdown NOW! shutdown: [pid 47954] *** FINAL System shutdown message from r...@batch2.rbcarleton.net *** System going down IMMEDIATELY batch2# System shutdown time has arrived batch2# syncing disks... done vmmci0: powerdown rebooting... [EOT] athena$ === end transcript === A note I'll add is that I don't recall getting the EOT at the end of the transcript until I hit the enter key.
Re: VMs not rebooting
On Sun, Dec 10, 2023 at 01:03:27PM -0600, Robert B. Carleton wrote: > 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 > interface { switch "int_switch" } > interface { switch "ext_switch" } > } > I've not heard of anyone else having reboot vs shutdown issues recently. I just did a shutdown -r now on my local machine and it works here: -vmmtech- /var/www/logs# shutdown -r now Shutdown NOW! shutdown: [pid 95485] *** FINAL System shutdown message from root *** System going down IMMEDIATELY -vmmtech- /var/www/logs# System shutdown time has arrived -vmmtech- /var/www/logs# syncing disks... done vmmci0: powerdown rebooting... Using drive 0, partition 3. Loading.. probing: pc0 com0 mem[638K 3838M 256M a20=on] disk: hd0+ >> OpenBSD/amd64 BOOT 3.65 \ com0: 115200 baud switching console to com0 >> OpenBSD/amd64 BOOT 3.65 boot> - > 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. harmless > > 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. > amd64 guest or i386?
VMs not rebooting
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 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: cumbersome mtree (OT!) - Process to have RADXIDE (MIT) among ports
Just forwarded to ports@. Please keep me posted.. -- Nowarez Market Dec 10, 2023 11:31:43 Jan Stary : > wrong list, > wrong subject
Re: cumbersome mtree (OT!) - Process to have RADXIDE (MIT) among ports
wrong list, wrong subject On Dec 09 21:47:21, my2...@has.im wrote: > > Hello, > > I just reached version 1.2.5 of RADXIDE (MIT license), turned around > many bugs, templetized its colors, contacted previous snippets code > authors figuring in About. > > Now, I'm wondering what is eventually the process to have RADXIDE as > a small package inside OpenBSD. > > Nevertheless this would like the last invitation to try the software to > check it out. > > Thnx, > > == Nowarez Market > > > > Nowarez Market wrote: > > > > For who is wondering (and not) I come from publishing RADXIDE ver > > 1.0.5 (tcl-tk, MIT license) I could appreciate anyone involvement or > > feedback. > > > > https://radxide.com > > https://github.com/par7133/RADXIDE > >
Re: Weird network performance with iwn(4)
Stuart Henderson wrote: > I checked for openwrt support but your AP has a relatively uncommon > Realtek SoC and it seems fairly unlikely to happen so you're probably > stuck with the vendor firmware. > > Maybe try forcing "mode 11n" or "mode 11g" with ifconfig and see if > that's any better. Interestingly enough, "mode 11g" won't join the AP. 11n works and it's a steady 300KByte/sec, it doesn't go up and down like with 11ac. Anyway, I'll see if I can find myself another AP to deploy here, maybe it's just some fringe compatibility issue. Daniel