About OpenBSD OpenFlow status
Hi OpenBSD Folks, I am concerned about the activeness of OpenBSD's openflow support. In fact, I think a clean coded, secure operating system like OpenBSD will be very successful in SDN. Yes, I know openflow is perhaps only 5% of the SDN concept. But OpenBSD is constantly making progress in this regard. In my opinion, the introduction of json support to dynamic routing protocols such as BGP and OSPF is an important step for the SDN orchestration in the APIs world. I apologize for doing so much chatter. I would like to ask my question without further ado: Will OpenBSD openflow support continue to be developed? Thanks & Cheers.
Re: qemu/kvm viornd0 problems with OpenBSD 6.7
Hello once again. Steffen Nurpmeso wrote in <20200525221543.zdgwt%stef...@sdaoden.eu>: |Ya, thanks!, i am doing my OpenBSD 6.7 today! | |I have switched to use "-device virtio-rng-pci" in qemu not too |long ago after figuring out it works quite nice and almost |everybody seems to support it. It is detected just fine for |OpenBSD 6.4 .. 6.6, but OpenBSD 6.7 causes qemu/kvm to abort with |a libgcrypt error: "Fatal: no entropy gathering module detected". |It works fine if i do not use this -device. Ok, once i started doing food for the animals (just fyi) i had the idea that the "-chroot ." i use might be the problem. I have no idea .. it seems mknod might no longer do what it is supposed to on Linux, hm, random and urandom however i supplied without any positive effects. Anyhow, i can confirm that OpenBSD 6.7 boots regulary with that virtio-rng if i do not chroot qemu! (So maybe i have to supply --bind mounts for dev etc. Hm.) Good night, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
qemu/kvm viornd0 problems with OpenBSD 6.7
Hello!
Ya, thanks!, i am doing my OpenBSD 6.7 today!
I have switched to use "-device virtio-rng-pci" in qemu not too
long ago after figuring out it works quite nice and almost
everybody seems to support it. It is detected just fine for
OpenBSD 6.4 .. 6.6, but OpenBSD 6.7 causes qemu/kvm to abort with
a libgcrypt error: "Fatal: no entropy gathering module detected".
It works fine if i do not use this -device.
I can tell you this happens with qemu 4.2.0 and on qemu 5.0.0, on
Linux 4.19.{117,123,124}, yep, and it seems to make qemu/kvm
shiver. 4.19.117 even could no longer shutdown the computer
correctly, i seem to recall the last message before the hang being
"kvm: exiting hardware virtualization". This never happened
before, once i was using this kernel actively.
I also get
starting network daemons: sshd smtpd sndiod(failed).
for my
o-0607-x86# cat /etc/rc.conf.local
library_aslr=no
sndiod_flags=no
which feels wrong. It is still sndiod_flags in rc.conf.
(I also got a "reordering libraries" on the first boot, i think,
even though the file was already in place. No problem here no
more, however.)
Out in the forest now. It seems i have to reprepare my MUA port
tomorrow thus, will post it to ports@.
Thank you, and Ciao! from Germany,
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: Dovecot and multi-factor auth support
On Mon, May 25, 2020 at 3:29 AM Darren S. wrote: > OpenBSD 6.6 amd64 > OpenSMTPD 6.6.0 > Dovecot 2.3.9.3 (9f41b88fa) > login_duo 1.11.2 > > I'm working with an OpenSMTPD/Dovecot installation that will support > users authenticating over the internet and I'm curious if any form of > multi-factor authentication is possible for IMAP (and optionally, > SMTP). What about: - using LDAP as auth backend for dovecot - integrate Duo with LDAP server ? You mentioned Duo but any strong authentication system LDAP compatible should works (Okta can act like LDAP server, too) -f
Re: Help, i want to ask if my Asus Vivobook Ryzen 3 , Vega 3 can run openbsd
I run Vega 3 graphics on desktops. There are a few quirks, the most important being to turn off the hardware cursor. If I read the upgrade notice for 6.7 correctly, the cursor problem may be fixed in that version. Don't know about wireless. You may have to get a usb wireless dongle. I had terrible (but ultimately solvable) problems associated with the bios getting linux to work on a Thinkpad E series which runs on AMD cpu/graphics. Hopefully ASUS doesn't have the same problem. Best of luck! Dave Raymond On 5/25/20, David McMackins wrote: > I've seen other reports that the new Vega graphics don't work with the > amdgpu driver. I'd be curious to know your results. Can't hurt to try > anyway. > > > Regards, > > David E. McMackins II > www.mcmackins.org www.delwink.com > > On 5/25/20 12:12 PM, Charlie Burnett wrote: >> Ryzen 3 Vega is based on the Raven architecture, which has worked for me >> on >> machines before so I'm not sure you'd have much issue with it, I'd >> imagine >> it'd just work "out of the box". Wireless is up in the air, since the >> card >> didn't seem to be listed on the specifications online. >> >> On Mon, May 25, 2020 at 10:49 AM flint pyrite >> wrote: >> >>> You probably should check for wifi compatibility. >>> >>> On Sun, May 24, 2020 at 9:50 PM Digital Crow >>> wrote: >>> Help, i want to ask if my Asus Vivobook Ryzen 3 , Vega 3 can run openbsd I have problems with freebsd i can't run xorg it has a problem with efi framebuffer and amdgpu driver. It seems that this laptop can boot only efi partitions there's no setting on bios about csm or anything else related to it. Is it possible openbsd would work ? Also is the process the same as freebsd ? I need to install drm-kmod and add kld_list amdgpu on rc.conf The openbsd installer create efi boot partition ? I think this laptop can boot only efi partitions >>> > > -- David J. Raymond david.raym...@nmt.edu http://physics.nmt.edu/~raymond
Re: Howto change login mechanism on OpenBSD
Hello Again,
Actually I updated the /etc/ttys file and add my program instead of getty.
However, after boot, there was still OpenBSD login prompt before my program
started.
On the other hand, I tried chpass -s $myprogram $user, but still I'm faced with
the same problem again, there was OpenBSD login prompt..
In short, I want to disable OpenBSD login prompt and execute my program. If
user exits this external program, my program should run again etc.
On Thu, 21 May 2020 01:53:29 +0200 Jeff Joshua Rollin
wrote
On Wed, 2020-05-20 at 17:00 -0500, Edgar Pettijohn wrote:
> On Wed, May 20, 2020 at 09:50:17PM +
> >
> > I believe /etc/ttys controls getty, which may or not help. Getty is
> > respawned too.
> > https://man.openbsd.org/man5/ttys.5
>
> I think you're right. Might just need to change a line in /etc/ttys
> to
> execute /bin/{my_program}.
>
> Edgar
>
Perhaps a better way would be just to change the user's login shell to
the name of your program: chpass -s $myprogram $user. That way you can
use OpenBSD's login authentication, and login automatically runs the
program when the user logs in; when the user quits the program they are
automatically logged out. Provided there's no way to execute a shell
from within the program, they therefore can't execute arbitrary code
once logged in. It's easy to add a user for this single purpose: just
add the user as normal, and specify $myprogram as the shell.
Jeff.
Sending IPv6 packets via an interface even when NDP is not available
How can I force all IPv6 packets sent via a certain route to: - Be directed out of a certain interface - Sent to a certain MAC address - Regardless of whether NDP works? I don’t know the peer’s IPv6 address, but I do know the interface and MAC address. Sincerely, Demi signature.asc Description: OpenPGP digital signature
Re: Help, i want to ask if my Asus Vivobook Ryzen 3 , Vega 3 can run openbsd
I've seen other reports that the new Vega graphics don't work with the amdgpu driver. I'd be curious to know your results. Can't hurt to try anyway. Regards, David E. McMackins II www.mcmackins.org www.delwink.com On 5/25/20 12:12 PM, Charlie Burnett wrote: > Ryzen 3 Vega is based on the Raven architecture, which has worked for me on > machines before so I'm not sure you'd have much issue with it, I'd imagine > it'd just work "out of the box". Wireless is up in the air, since the card > didn't seem to be listed on the specifications online. > > On Mon, May 25, 2020 at 10:49 AM flint pyrite > wrote: > >> You probably should check for wifi compatibility. >> >> On Sun, May 24, 2020 at 9:50 PM Digital Crow >> wrote: >> >>> Help, i want to ask if my Asus Vivobook Ryzen 3 , Vega 3 can run openbsd >>> I have problems with freebsd i can't run xorg it has a problem with efi >>> framebuffer and amdgpu driver. >>> It seems that this laptop can boot only efi partitions there's no setting >>> on bios about csm or anything else related to it. >>> Is it possible openbsd would work ? >>> Also is the process the same as freebsd ? >>> I need to install drm-kmod and add kld_list amdgpu on rc.conf >>> The openbsd installer create efi boot partition ? >>> I think this laptop can boot only efi partitions >>> >>
Re: Help, i want to ask if my Asus Vivobook Ryzen 3 , Vega 3 can run openbsd
Ryzen 3 Vega is based on the Raven architecture, which has worked for me on machines before so I'm not sure you'd have much issue with it, I'd imagine it'd just work "out of the box". Wireless is up in the air, since the card didn't seem to be listed on the specifications online. On Mon, May 25, 2020 at 10:49 AM flint pyrite wrote: > You probably should check for wifi compatibility. > > On Sun, May 24, 2020 at 9:50 PM Digital Crow > wrote: > > > Help, i want to ask if my Asus Vivobook Ryzen 3 , Vega 3 can run openbsd > > I have problems with freebsd i can't run xorg it has a problem with efi > > framebuffer and amdgpu driver. > > It seems that this laptop can boot only efi partitions there's no setting > > on bios about csm or anything else related to it. > > Is it possible openbsd would work ? > > Also is the process the same as freebsd ? > > I need to install drm-kmod and add kld_list amdgpu on rc.conf > > The openbsd installer create efi boot partition ? > > I think this laptop can boot only efi partitions > > >
Re: Kernel relinking on old boxen at every boot
Otto Moerbeek wrote: > I run > > nice /usr/libexec/reorder_kernel & > > And my landisk is usable from the start. I don't even tweak my landisk. These machines are 30% the performance of the OP's complaint. I don't see any reason to change the way it works.
Re: sysupgrade confused by additional disk?
On 2020-05-25 10:21, Why 42? The lists account. wrote: ,,, > At some point I added a second (larger) disk to hold my user data (i.e. > home). It seems that this new disk took over the name sd0 and the OpenBSD > system disk itself became known as sd1. yep. Things like that are where the duids came in. > The OpenBSD OS still boots and runs without issue, however this change > seems to have confused sysupgrade. After it downloads and reboots I now > get prompted to choose I)nstall, U)grade, etc. If I recall correctly, > this step used to run automatically without any intervention. Is that > right? While OpenBSD itself is great about using duids, those are defined in the 'a' partition of the boot disk..which is usually the first disk. But in your case, the "first disk" doesn't include the 'a' partitionand the /etc/fstab file...which is probably causing the upgrade kernel to choke. > My first thought was I could fix the issue by using sysctl to reassign > the disk name to uuid mapping (i.e. the hw.disknames values) ... No, that won't work -- the disks are assigned at boot. > Any other suggestions as to how to fix this? > > Thinking some more about it, shouldn't sysupgrade just use those very > disk uuid values to identify its targets in the first place ... thus > avoiding the whole issue in the first place? think about that a moment. You are running OpenBSD. You run sysupgrade, it pulls down all the new tgz files. And it ... REBOOTS. I think you are asking that the old kernel passes info to the newly rebooted kernel. It's probably doable, or could fail earlier to let you know you have a problem, but I'm driving myself batty thinking about the multi-platform and edge cases. The best solution for YOU I can think of would be to put a small 'a' partition on your sd0 for root, and have your system boot from that, but use sd1 for all the rest of the system file systems. Or just do traditional upgrades. Nick.
Re: Kernel relinking on old boxen at every boot
On 2020-05-25 11:35, ULF wrote: ... > My question is: > > considering that an opt out option has been already turned down, could at > least old architectures be benefited of a "delay" option e.g. like tune2fs > sets a fsck every n-th boot, could KARL, just for very old machines be > tuned, say, to be applied every 10/20 boots? oh, please no. So you want my old machine to USUALLY boot in a minute or so...but once in a while, you want it to take many times that long with no real warning that "don't panic, this reboot will take many times the usual amount"? No...we got Linux machines that do that...very horribly unpleasant. It also disables the primary advantage of KARL -- If you find a way to tickle a bug in the OpenBSD kernel, PROBABLY the first result will be to crash the kernel (due to other safety things). You WANT it to come up on a different kernel NEXT TIME, not after a bunch more crashes while the attacker figures out how to turn a crash-bug into an exploit-bug.. If you really want to kill this security feature, don't pretend it's still there helping you...turn it off and know it's off. KARL is really easy to disable IF that's what you really want to do. You probably want to kill the library relinking, too (if your disks don't suck, I find the library re-linking more painful than the kernel relinking. If your disks suck (i.e., USB thumb drive), they are both painful). Also easy. I, toolike running old hw, but I'd rather OpenBSD be made as good as possible for modern stuff so people can do real work on it than to be crippled by trying to optimize for a bunch of us old hw collectors. We can disable KARL and library re-linking if we want to -- and that's how it should be, build for the productive masses, leave the edge cases to the nut-jobs like us. :) Nick.
Re: Help, i want to ask if my Asus Vivobook Ryzen 3 , Vega 3 can run openbsd
You probably should check for wifi compatibility. On Sun, May 24, 2020 at 9:50 PM Digital Crow wrote: > Help, i want to ask if my Asus Vivobook Ryzen 3 , Vega 3 can run openbsd > I have problems with freebsd i can't run xorg it has a problem with efi > framebuffer and amdgpu driver. > It seems that this laptop can boot only efi partitions there's no setting > on bios about csm or anything else related to it. > Is it possible openbsd would work ? > Also is the process the same as freebsd ? > I need to install drm-kmod and add kld_list amdgpu on rc.conf > The openbsd installer create efi boot partition ? > I think this laptop can boot only efi partitions >
Re: Kernel relinking on old boxen at every boot
On Mon, May 25, 2020 at 05:35:17PM +0200, ULF wrote: > Hello Devs, > > I followed, some time ago, the proposal of a user who suggested a diff for > an "opt out" of KARL to be placed in /etc/rc.conf.local, proposal which > which wasn't welcomed well. > > While agreeing that on servers and modern machines this is a great security > feature which implies quite a small overhead, on the other side I am the > owner of several old i386 boxen, mainly run just for hobby purposes for > some hours a month, as, I could suppose, some other hobbists might do. > > On Pentium 3's every boot means at least 5-7 minutes wait to have a usable > machine, while on lower end boxen 10 minutes were already a desirable > target, because on first gen Pentiums the time is well above. > > This does not only meet pure number crunching, but, on old hardwares, also > means extra stress for old disks which, especially on laptops, will become > one day irreplaceable because of shortage. Not to consider extra > electricity and time, whenever the machine needs a reboot. > > Maybe other old platforms, beyond i386, might be affected this way too. > > My question is: > > considering that an opt out option has been already turned down, could at > least old architectures be benefited of a "delay" option e.g. like tune2fs > sets a fsck every n-th boot, could KARL, just for very old machines be > tuned, say, to be applied every 10/20 boots? > > Thank you very much for your attention. > Ulf I run nice /usr/libexec/reorder_kernel & And my landisk is usable from the start. -Otto
Kernel relinking on old boxen at every boot
Hello Devs, I followed, some time ago, the proposal of a user who suggested a diff for an "opt out" of KARL to be placed in /etc/rc.conf.local, proposal which which wasn't welcomed well. While agreeing that on servers and modern machines this is a great security feature which implies quite a small overhead, on the other side I am the owner of several old i386 boxen, mainly run just for hobby purposes for some hours a month, as, I could suppose, some other hobbists might do. On Pentium 3's every boot means at least 5-7 minutes wait to have a usable machine, while on lower end boxen 10 minutes were already a desirable target, because on first gen Pentiums the time is well above. This does not only meet pure number crunching, but, on old hardwares, also means extra stress for old disks which, especially on laptops, will become one day irreplaceable because of shortage. Not to consider extra electricity and time, whenever the machine needs a reboot. Maybe other old platforms, beyond i386, might be affected this way too. My question is: considering that an opt out option has been already turned down, could at least old architectures be benefited of a "delay" option e.g. like tune2fs sets a fsck every n-th boot, could KARL, just for very old machines be tuned, say, to be applied every 10/20 boots? Thank you very much for your attention. Ulf
6.7 feature: dt(4), a driver and framework for Dynamic Profiling ...
Hi Again, Couple of points regarding this new feature: > Imported dt(4), a driver and framework for Dynamic Profiling, and an > accompanying bug tracer that speaks the dt(5) language. What is this "bug tracer" executable called? So far I have been unable to find it :( Could it be that this is a reference to the DTrace project? There is, I think, a typo in https://www.openbsd.org/plus67.html where the same sentence refers to "bt(5)" i.e. "Bravo Tango": > Imported dt(4), a driver and framework for Dynamic Profiling, and an > accompanying bug tracer that speaks the bt(5) language. FYI, on my freshly sysupgraded 6.7 system there is a man page for "dt" in section 4, but nothing is found for dt in 5 i.e. > man: No entry for dt in section 5 of the manual. (Also not for bt.) Just FYI, in the Web page https://www.openbsd.org/67.html "dt(5)" is a link to just "dt" which then takes the user back to the section 4 page. Cheers, Robb.
Re: rc.conf.local sorted?
On Mon, May 25, 2020 at 03:22:11PM +0200, Why 42? The lists account. wrote: > > Hi All, > > After running sysupgrade to update from 6.6 (snapshot) to the newest > version I noticed that the comments I added to /etc/rc.conf.local no > longer made sense (if they ever did :)). > > It looks as if the file has been sorted e.g. > > ... > > # Also increase the number of -b(uffer) frames so as to avoid "stutter" > > under high CPU load. Default (7680) + 1024. See: man sndiod > > # Boot time messages: > > # For NFS > > # Prefer Postfix > > # So this should expose raw device "rsnd/1" the "Burr-Brown from TI USB > > Audio CODEC" (aka "audio1" or "uaudio0") as subdevice: "cyrus" > > # Sound subsystem: sndiod > > # Tell syslog to write mark messages every 30 minutes > > # audio1 at uaudio0 > > # uaudio0 at uhub3 port 1 configuration 1 interface 1 "Burr-Brown from TI > > USB Audio CODEC" rev 1.10/1.00 addr 7 > > # uaudio0: class v1, full-speed, sync, channels: 2 play, 2 rec, 3 ctls > > lockd_flags= > > mountd_flags= > > nfsd_flags=-n 7 -t > > pkg_scripts=messagebus postfix > > portmap_flags= > > sensorsd_flags= > > smtpd_flags=NO > > sndiod_flags="-b 8704 -f rsnd/1 -s cyrus" > > ... > > Is this normal? It doesn't seem like something I would have been likely > to have done manually/accidentally. > > Based on the file mtime it seems as if this happened at boot time, or > perhaps at the time of the first boot after the sysupgrade. > > Strangely sysupgrade itself doesn't have much to say about what it > installed e.g. in messages log I just see: > > sysupgrade: installed new /bsd.upgrade. Old kernel version: OpenBSD > > 6.6-current (GENERIC.MP) #55: Sun Mar 15 02:21:01 MDT 2020 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Per uname I am currently running: 6.7 GENERIC.MP#213 amd64 > > Just wondering if this is the expected behaviour ... Did you use rcctl(8) ? -- Antoine
rc.conf.local sorted?
Hi All, After running sysupgrade to update from 6.6 (snapshot) to the newest version I noticed that the comments I added to /etc/rc.conf.local no longer made sense (if they ever did :)). It looks as if the file has been sorted e.g. > ... > # Also increase the number of -b(uffer) frames so as to avoid "stutter" under > high CPU load. Default (7680) + 1024. See: man sndiod > # Boot time messages: > # For NFS > # Prefer Postfix > # So this should expose raw device "rsnd/1" the "Burr-Brown from TI USB Audio > CODEC" (aka "audio1" or "uaudio0") as subdevice: "cyrus" > # Sound subsystem: sndiod > # Tell syslog to write mark messages every 30 minutes > # audio1 at uaudio0 > # uaudio0 at uhub3 port 1 configuration 1 interface 1 "Burr-Brown from TI USB > Audio CODEC" rev 1.10/1.00 addr 7 > # uaudio0: class v1, full-speed, sync, channels: 2 play, 2 rec, 3 ctls > lockd_flags= > mountd_flags= > nfsd_flags=-n 7 -t > pkg_scripts=messagebus postfix > portmap_flags= > sensorsd_flags= > smtpd_flags=NO > sndiod_flags="-b 8704 -f rsnd/1 -s cyrus" > ... Is this normal? It doesn't seem like something I would have been likely to have done manually/accidentally. Based on the file mtime it seems as if this happened at boot time, or perhaps at the time of the first boot after the sysupgrade. Strangely sysupgrade itself doesn't have much to say about what it installed e.g. in messages log I just see: > sysupgrade: installed new /bsd.upgrade. Old kernel version: OpenBSD > 6.6-current (GENERIC.MP) #55: Sun Mar 15 02:21:01 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Per uname I am currently running: 6.7 GENERIC.MP#213 amd64 Just wondering if this is the expected behaviour ... Cheers, Robb.
sysupgrade confused by additional disk?
Hi All, I use sysupgrade to update to new snapshot versions (of 6.6). Brilliant! At some point I added a second (larger) disk to hold my user data (i.e. home). It seems that this new disk took over the name sd0 and the OpenBSD system disk itself became known as sd1. The OpenBSD OS still boots and runs without issue, however this change seems to have confused sysupgrade. After it downloads and reboots I now get prompted to choose I)nstall, U)grade, etc. If I recall correctly, this step used to run automatically without any intervention. Is that right? At this point I can choose the upgrade option and manually run through the process, normally without issue (very helpful prompting/feedback e.g. with the mount points!). Still, it would be nice if this could be once again automatic ... My first thought was I could fix the issue by using sysctl to reassign the disk name to uuid mapping (i.e. the hw.disknames values) so that the OS was once again on sd0. Unfortunately that didn't seem to work. Is it the case that some of these sysctl/system variables are read-only or cannot be set? Or maybe I did something incorrectly ... also not impossible :) Any other suggestions as to how to fix this? Thinking some more about it, shouldn't sysupgrade just use those very disk uuid values to identify its targets in the first place ... thus avoiding the whole issue in the first place? Thanks in advance for your feedback! Just FYI: storage hardware configuration looks like this: > nvme0 at pci1 dev 0 function 0 "Samsung SM981/PM981 NVMe" rev 0x00: msix, > NVMe 1.3 > nvme0: Samsung SSD 970 EVO Plus 500GB, firmware 1B2QEXM7, serial > S4EVNG0M109821X > sd1 at scsibus2 targ 1 lun 0: > sd0 at scsibus1 targ 2 lun 0: > naa.5002538e4109632a The NVMe device sd1 has all the OS partitions (/, /usr, etc), the SSD device sd0 was added later to provide more space (too many photos :)). Yours, Robb.
Re: Problem with pkg_add -uv after 6.7 upgrade on i386
Thank you very much, maybe it was some kind of silent corruption due to old IDE disk, anyway pkg_check and then again pkg_add -u fixed all the trouble. I will keep this in mind, should it happen again. Have a nice day! On Mon, May 25, 2020 at 2:52 PM Marc Espie wrote: > On Mon, May 25, 2020 at 01:01:07PM +0200, Paolo Aglialoro wrote: > > Hello Folks, > > > > I just upgraded a PIII box freshly installed with 6.6 last month. > > Everything went right with sysupgrade (big kudos do devs). > > > > Problems started when upgrading installed packages, here follows the > output > > of pkg_add -uv. What can this be? > > Corruption of your filesystem *prior* to running pkg_add -u > > Run pkg_check. > > > > adwaita-icon-theme-3.34.3:.libs-pango+.libs1-pango+.libs2-pango+.libs3-pango+.libs4-pango+pango-1.42.4p3->pango-1.44.7p0 > > 't read packing-list from installed package > > > \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00 > > Invalid \0 character in pathname for ftis: /var/db/pkg/\0 at > > /usr/libdata/perl5/OpenBSD/PackingList.pm line 520. > > File > > > /var/db/pkg/\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00/+CONTENTS > ... > > those are actually fairly obvious error messages. >
Re: FAQ/Multimedia: Burning CDs and DVDs
Stefan Wollny(stefan.wol...@web.de) on 2020.05.24 22:59:57 +0200: > Hi there! > > > I just noticed that the sections on burning CDs and DVDs are no longer > present in OpenBSD's FAQ related to multimedia. > > Is this intentional? probably yes > I didn't see anything on this on tech@ or misc@... Not everything needs a long discussion... The real question here is: What question do you have (that was answered by that webpage)? And is it asked frequently? /Benno PS: https://web.archive.org/web/20150716003030/http://www.openbsd.org/faq/faq13.html#burnCD
Re: Problem with pkg_add -uv after 6.7 upgrade on i386
On Mon, May 25, 2020 at 01:01:07PM +0200, Paolo Aglialoro wrote: > Hello Folks, > > I just upgraded a PIII box freshly installed with 6.6 last month. > Everything went right with sysupgrade (big kudos do devs). > > Problems started when upgrading installed packages, here follows the output > of pkg_add -uv. What can this be? Corruption of your filesystem *prior* to running pkg_add -u Run pkg_check. > adwaita-icon-theme-3.34.3:.libs-pango+.libs1-pango+.libs2-pango+.libs3-pango+.libs4-pango+pango-1.42.4p3->pango-1.44.7p0 > 't read packing-list from installed package > \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00 > Invalid \0 character in pathname for ftis: /var/db/pkg/\0 at > /usr/libdata/perl5/OpenBSD/PackingList.pm line 520. > File > /var/db/pkg/\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00/+CONTENTS ... those are actually fairly obvious error messages.
Re: Why does OpenBSD still include Perl in its base installation?
Another thing to consider: why is perl in the base system. Assume you need a script language, because writing everything in C is cumbersome. What are the choices ? - you need something under and acceptable licence, so python is out. (Artistic Licence is "close enough"); - you need something that builds everywhere, so python is out (hard to build without dynamic libraries, that was vax...); - you want a modicum of security, so shell and tcl and php are out. - awk would kind of work, except it's not that readable, and it wouldn't scale up to some of the things we use perl for. Perl constituted a great compromise back in the day I chose it to replace pkg_add. It still IS a great compromise, and it's not THAT large compared to other pieces. Over the years, things have moved back from language to language. makewhatis used to be C+shell, then it became perl, and now it's pure C because it's integrated in mandoc... I shudder to think how much time was spent in there. Note that Ingo also moved /etc/security from shell to perl, so he's not adverse to perl. As far as I'm concerned, having perl in the base system is a strength of OpenBSD... it does minimize the number of script languages used for ports infrastructure as compared to other languages. perl also has impressive support tools, be they in the base system or in ports. NYTProf is still the best profiler I've ever seen on any language.
[tmux] 'send-keys' command behavior (Ctrl + Arrow keys) in post-6.7
Greetings,
Hope misc@ is the right place for this kind of issues, since I do not
have enough info to fill in a proper bugs@ report.
In both 6.7 and -current, when I issue (in tmux) 'cat -v' I see the
following:
- Left, Right, Up, Down keys:
^[[C ^[[D ^[[A ^[[B
- C-Left, C-Right, C-Up, C-Down combinations:
^[[1;5D ^[[1;5C ^[[1;5A ^[[1;5B
In order to navigate seamlessly between vim and tmux splits using a
consistent set of hotkeys I use a vim plugin (vim-tmux-navigator) and I
have the following settings in ~/.tmux.conf:
bind-key -n 'C-Up'run-shell "(tmux display-message -p '#{pane_current_command}' | grep
-iq vim) && tmux send-keys 'C-Up' || tmux select-pane -U"
bind-key -n 'C-Down' run-shell "(tmux display-message -p '#{pane_current_command}' | grep
-iq vim) && tmux send-keys 'C-Down' || tmux select-pane -D"
bind-key -n 'C-Right' run-shell "(tmux display-message -p '#{pane_current_command}' | grep
-iq vim) && tmux send-keys 'C-Right'|| tmux select-pane -R"
bind-key -n 'C-Left' run-shell "(tmux display-message -p '#{pane_current_command}' | grep
-iq vim) && tmux send-keys 'C-Left' || tmux select-pane -L"
Now, in 6.7 tmux, opening vim and issuing ^v in insert mode before the
key combinations I see (as expected):
- Left, Right, Up, Down keys:
^[OD ^[OC ^[OA ^[OB
- C-Left, C-Right, C-Up, C-Down combinations:
^[[1;5D ^[[1;5C ^[[1;5A ^[[1;5B
but in -current I see the same codes for both singular arrow keys and
Ctrl combinations:
OpenBSD theseus.atlantide.priv 6.7 GENERIC.MP#206 amd64
- Left, Right, Up, Down keys:
^[OD ^[OC ^[OA ^[OB
- C-Left, C-Right, C-Up, C-Down combinations:
^[OD ^[OC ^[OA ^[OB
(for both 6.7 and -current vim version is 8.2.534). Of course, this way
my settings in vim are screwed.
I do not see many relevant commits in tmux since 6.7, except maybe:
https://marc.info/?l=openbsd-cvs=158964667912505=2
https://marc.info/?l=openbsd-cvs=158964675612518=2
https://marc.info/?l=openbsd-cvs=158964675612518=2
but I didn't try to bisect.
Any thoughts?
--
Alessandro De Laurenzis
[mailto:jus...@atlantide.mooo.com]
Web: http://www.atlantide.mooo.com
LinkedIn: http://it.linkedin.com/in/delaurenzis
Problem with pkg_add -uv after 6.7 upgrade on i386
Hello Folks, I just upgraded a PIII box freshly installed with 6.6 last month. Everything went right with sysupgrade (big kudos do devs). Problems started when upgrading installed packages, here follows the output of pkg_add -uv. What can this be? Thanks Pasha --- Update candidates: quirks-3.325 -> quirks-3.325 quirks-3.325 signed on 2020-05-23T20:09:38Z Update candidates: ImageMagick-6.9.10.86p0 -> ImageMagick-6.9.10.86p0 Update candidates: tiff-4.1.0 -> tiff-4.1.0 Update candidates: jpeg-2.0.4p0v0 -> jpeg-2.0.4p0v0 Update candidates: xz-5.2.5 -> xz-5.2.5 Update candidates: zstd-1.4.4p1 -> zstd-1.4.4p1 Update candidates: lz4-1.9.2p0 -> lz4-1.9.2p0 Update candidates: jbigkit-2.1 -> jbigkit-2.1 Update candidates: libiconv-1.16p0 -> libiconv-1.16p0 Update candidates: djvulibre-3.5.27p6 -> djvulibre-3.5.27p6 Update candidates: shared-mime-info-1.15 -> shared-mime-info-1.15 Update candidates: libxml-2.9.10p0 -> libxml-2.9.10p0 Update candidates: glib2-2.62.6 -> glib2-2.62.6 Update candidates: gettext-runtime-0.20.1p1 -> gettext-runtime-0.20.1p1 Update candidates: python-3.7.7 -> python-3.7.7 Update candidates: libffi-3.3 -> libffi-3.3 Update candidates: sqlite3-3.31.1p0 -> sqlite3-3.31.1p0 Update candidates: bzip2-1.0.8 -> bzip2-1.0.8 Update candidates: pcre-8.41p2 -> pcre-8.41p2 Update candidates: gtk-update-icon-cache-3.24.20 -> gtk-update-icon-cache-3.24.20 Update candidates: hicolor-icon-theme-0.17 -> hicolor-icon-theme-0.17 Update candidates: gdk-pixbuf-2.40.0p2 -> gdk-pixbuf-2.40.0p2 Update candidates: jasper-2.0.14 -> jasper-2.0.14 Update candidates: png-1.6.37 -> png-1.6.37 Update candidates: lcms2-2.9p0 -> lcms2-2.9p0 Update candidates: openjp2-2.3.1p0 -> openjp2-2.3.1p0 Update candidates: libraw-0.19.5p0 -> libraw-0.19.5p0 Update candidates: fftw3-3.3.8p1 -> fftw3-3.3.8p1 Update candidates: fftw3-common-3.3.8p1 -> fftw3-common-3.3.8p1 Update candidates: libwebp-1.1.0 -> libwebp-1.1.0 Update candidates: giflib-5.1.6 -> giflib-5.1.6 Update candidates: adwaita-icon-theme-3.32.0 -> adwaita-icon-theme-3.34.3 Update candidates: librsvg-2.46.4 -> librsvg-2.48.4 Update candidates: pango-1.42.4p3 -> pango-1.44.7p0 Update candidates: fribidi-1.0.9 -> fribidi-1.0.9 Update candidates: harfbuzz-2.6.5 -> harfbuzz-2.6.5 Update candidates: graphite2-1.3.14 -> graphite2-1.3.14 Update candidates: cairo-1.16.0 -> cairo-1.16.0 Update candidates: lzo2-2.10p2 -> lzo2-2.10p2 Adding adwaita-icon-theme-3.34.3:.libs-pango+.libs1-pango+.libs2-pango+.libs3-pango+.libs4-pango+pango-1.42.4p3->pango-1.44.7p0 't read packing-list from installed package \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00 Invalid \0 character in pathname for ftis: /var/db/pkg/\0 at /usr/libdata/perl5/OpenBSD/PackingList.pm line 520. File /var/db/pkg/\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00/+CONTENTS does not exist Error: ? missing from installation Invalid \0 character in pathname for open: /var/db/pkg/\0 at /usr/libdata/perl5/OpenBSD/PackingList.pm line 315. Warning: couldn't read packing-list from installed package \00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00 Invalid \0 character in pathname for ftis: /var/db/pkg/\0 at /usr/libdata/perl5/OpenBSD/PackingList.pm line 520. File /var/db/pkg/\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00/+CONTENTS does not exist Error: missing from installation Invalid \0 character in pathname for ftfile: /var/db/pkg/\0 at /usr/libdata/perl5/OpenBSD/RequiredBy.pm line 39. Invalid \0 character in pathname for ftfile: /var/db/pkg/\0 at /usr/libdata/perl5/OpenBSD/RequiredBy.pm line 39. Invalid \0 character in pathname for unlink: /var/db/pkg/\0 at /usr/libdata/perl5/OpenBSD/RequiredBy.pm line 61. Invalid \0 character in pathname for open: /var/db/pkg/\0 at /usr/libdata/perl5/OpenBSD/RequiredBy.pm line 67. to_install: pcre-8.41p2 => //pcre-8.41p2/ jpeg-2.0.4p0v0 => //jpeg-2.0.4p0v0/ djvulibre-3.5.27p6 => //djvulibre-3.5.27p6/ harfbuzz-2.6.5 => //harfbuzz-2.6.5/ openjp2-2.3.1p0 => //openjp2-2.3.1p0/ libwebp-1.1.0 => //libwebp-1.1.0/ xz-5.2.5 => //xz-5.2.5/ libffi-3.3 => //libffi-3.3/ gettext-runtime-0.20.1p1 => //gettext-runtime-0.20.1p1/ graphite2-1.3.14 => //graphite2-1.3.14/ zstd-1.4.4p1 => //zstd-1.4.4p1/ tiff-4.1.0 => //tiff-4.1.0/ libxml-2.9.10p0 => //libxml-2.9.10p0/ sqlite3-3.31.1p0 => //sqlite3-3.31.1p0/ png-1.6.37 => //png-1.6.37/ lz4-1.9.2p0 => //lz4-1.9.2p0/ cairo-1.16.0 => //cairo-1.16.0/ hicolor-icon-theme-0.17 => //hicolor-icon-theme-0.17/ pango-1.44.7p0 => pango-1.44.7p0/.libs4-pango-1.42.4p3,.libs2-pango-1.42.4p3,.libs3-pango-1.42.4p3,pango-1.42.4p3,.libs-pango-1.42.4p3,.libs1-pango-1.42.4p3// fribidi-1.0.9 => //fribidi-1.0.9/ lzo2-2.10p2 => //lzo2-2.10p2/ shared-mime-info-1.15 => //shared-mime-info-1.15/ jasper-2.0.14 => //jasper-2.0.14/ lcms2-2.9p0 => //lcms2-2.9p0/ adwaita-icon-theme-3.34.3 =>
Re: Distorted sound in 6.7
On 25/05/2020, Alexandre Ratchov wrote: > On Fri, May 22, 2020 at 12:35:06PM +0100, Maurice McCarthy wrote: >> Hi, >> >> Since installing 6.7 I've found that human voices in mpv or youtube >> sound either very quiet or as-if "under water" or bubbly. I was >> unable to cure this with sndioctl but succeeded with the old mixerctl >> >> doas outputs.master=200,150 >> > > Most probably the speaker(s) are not properly wired and left and right > channels cancel each other. You could check this as follows: play a > mono file and meanwhile try the following: > > doas outputs.master=200,0 > doas outputs.master=0,200 > doas outputs.master=200,200 > > first two should play but the last one should produce (almost) > silence. > >> If I understand sndioctl well enough this kind of left and right >> speaker adjustment is not possible under sndioctl. dmesg attached. >> > > fwiw, to control individual channels (if hardware allows it), put the > channel number between squire brackets: > > sndioctl output[1].level=0 > Thank you Alexandre. You were spot on about playing the mono file. I failed to make it clear that I normally use headphones jacked into the onboard sound. (My good lady does not share my taste in music.) It turns out they don't support separate channels. Thanks again for the enlightenment.
Re: 6.7 boot crashes on "entry point at" X1 Carbon gen7 i7-10510U
On Mon, May 25, 2020 at 6:04 PM Otto Moerbeek wrote: > > On Mon, May 25, 2020 at 08:29:56AM +0200, Otto Moerbeek wrote: > > > On Sun, May 24, 2020 at 09:46:09PM +0900, John Mettraux wrote: > > > > > On Sun, May 24, 2020 at 8:38 PM Otto Moerbeek wrote: > > > > > > > > On Sun, May 24, 2020 at 08:26:43PM +0900, John Mettraux wrote: > > > > > > > > > On Sun, May 24, 2020 at 5:36 PM Stuart Henderson > > > > > wrote: > > > > > > > > > > > > On 2020-05-23, John Mettraux wrote: > > > > > > > > > > > > > > (...) > > > > > > > > > > > > > > Hard power down is the only way out, but rebooting still leads > > > > > > > immediately to the > > > > > > > "entry point at 0x1001000" wall. It is consistent. I tried boot > > > > > > > -c, > > > > > > > boot -d or boot -s, > > > > > > > still the same wall. > > > > > > > > > > > > > > I have just tried with the install67.img snapshot (22-May-2020 > > > > > > > 21:12 > > > > > > > 476545024) from > > > > > > > https://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/ but it leads > > > > > > > to the same > > > > > > > "entry point at 0x1001000" right after boot. > > > > > > > > > > > > Try downloading a 6.7 kernel (bsd.mp) to e.g. /bsd.test, and from > > > > > > the 6.6 boot > > > > > > loader type "b /bsd.test". Do you still get the hang? This will > > > > > > give you an idea > > > > > > whether the problem in 6.7 is with the newer boot loader or the > > > > > > kernel. > > > > > > > > > > I can confirm that the hang doesn't happen with the 6.7 kernel and > > > > > the 6.6 boot > > > > > loader (bootx64 3.46). The hang happens with the 6.7 boot loader > > > > > (3.50). > > > > > > > > > > I will try to do a 6.7 install with the 3.46 boot loader. > > > > > > > > Can you also try using legacy boot mode (mbr)? There should be some > > > > setting in the bios to enable that. > > > > > > > > -Otto > > > > > > I tried to set the boot mode to [Legacy First] and [Legacy Only]. In > > > both cases the Boot 3.47 kicked in > > > and allowed me to install. > > > > > > I performed the install on the machine drive (sd0) with MBR and the > > > install was successful. > > > Dmesg below for the resulting 6.7 Snapshot. > > > > > > I tried to install on sd0 with GPT. The install warned me "An EFI/GPT > > > disk may not boot. Proceed?" > > > I answered yes. The install proceeded but upon reboot it froze with > > > the "entry point at 0x1001000". > > > This was with bootx64 3.50. > > > > > > I am going to re-install with sd0 MBR. > > > > > > Thanks a lot! > > > > > > John > > > > I have an x1 6th generation that also does not like to boot using EFI. > > There's is a difference though: it already had problems with EFI > > when I initially installed it in Feb 2019. > > > > I'll see if I can find some time to make a more detail diagnosis. > > I just tried and EFI boot with the latst snap works on it. efifb(4) > is not configured but for the rest it seems to work ok using bootx64 > 3.50 and BIOS version 1.44. > > -Otto Hello, I have tried yesterday an EFI boot with the install67.img snapshot (22-May-2020 21:12), but it froze at "entry point at 0x1001000". I had this laptop with a vanilla 6.6 booting from EFI until last week. I have now re-installed a vanilla 6.7 booting from MBR following your advice and it's fine for now. Thanks again! John
Re: Dovecot and multi-factor auth support
>> Is there any sort of supported way of wiring up login_duo with >> OpenSMTPD and Dovecot, or using bsdauth in some way to enforce a >> second auth factor? > >bsdauth isn't really setup for multi factor, the only way I've seen >this >done is splitting the password field into a fixed-length OTP and a >password. I use a ssh tunnel for access to dovecot, with the same username via bsdauth. Not exactly two factor at the account level but even more secure IMO and ssh has two factor ability now too. I tried but abandoned switching to client tls certs as keeping tunnels or vpns open isn't so great on mobile for notifications and ensuring clients trust one CA, especially on mobiles is impossible? Nowadays, without writing your own client (all use android trust store?!) Note: bsdauth may be being removed by dovecot, annoyingly. http://openbsd-archive.7691.n7.nabble.com/bsdauth-being-removed-from-Dovecot-td387268.html
Re: 6.7 boot crashes on "entry point at" X1 Carbon gen7 i7-10510U
On Mon, May 25, 2020 at 08:29:56AM +0200, Otto Moerbeek wrote: > On Sun, May 24, 2020 at 09:46:09PM +0900, John Mettraux wrote: > > > On Sun, May 24, 2020 at 8:38 PM Otto Moerbeek wrote: > > > > > > On Sun, May 24, 2020 at 08:26:43PM +0900, John Mettraux wrote: > > > > > > > On Sun, May 24, 2020 at 5:36 PM Stuart Henderson > > > > wrote: > > > > > > > > > > On 2020-05-23, John Mettraux wrote: > > > > > > > > > > > > (...) > > > > > > > > > > > > Hard power down is the only way out, but rebooting still leads > > > > > > immediately to the > > > > > > "entry point at 0x1001000" wall. It is consistent. I tried boot -c, > > > > > > boot -d or boot -s, > > > > > > still the same wall. > > > > > > > > > > > > I have just tried with the install67.img snapshot (22-May-2020 21:12 > > > > > > 476545024) from > > > > > > https://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/ but it leads > > > > > > to the same > > > > > > "entry point at 0x1001000" right after boot. > > > > > > > > > > Try downloading a 6.7 kernel (bsd.mp) to e.g. /bsd.test, and from the > > > > > 6.6 boot > > > > > loader type "b /bsd.test". Do you still get the hang? This will give > > > > > you an idea > > > > > whether the problem in 6.7 is with the newer boot loader or the > > > > > kernel. > > > > > > > > I can confirm that the hang doesn't happen with the 6.7 kernel and the > > > > 6.6 boot > > > > loader (bootx64 3.46). The hang happens with the 6.7 boot loader (3.50). > > > > > > > > I will try to do a 6.7 install with the 3.46 boot loader. > > > > > > Can you also try using legacy boot mode (mbr)? There should be some > > > setting in the bios to enable that. > > > > > > -Otto > > > > I tried to set the boot mode to [Legacy First] and [Legacy Only]. In > > both cases the Boot 3.47 kicked in > > and allowed me to install. > > > > I performed the install on the machine drive (sd0) with MBR and the > > install was successful. > > Dmesg below for the resulting 6.7 Snapshot. > > > > I tried to install on sd0 with GPT. The install warned me "An EFI/GPT > > disk may not boot. Proceed?" > > I answered yes. The install proceeded but upon reboot it froze with > > the "entry point at 0x1001000". > > This was with bootx64 3.50. > > > > I am going to re-install with sd0 MBR. > > > > Thanks a lot! > > > > John > > I have an x1 6th generation that also does not like to boot using EFI. > There's is a difference though: it already had problems with EFI > when I initially installed it in Feb 2019. > > I'll see if I can find some time to make a more detail diagnosis. I just tried and EFI boot with the latst snap works on it. efifb(4) is not configured but for the rest it seems to work ok using bootx64 3.50 and BIOS version 1.44. -Otto
Re: Dovecot and multi-factor auth support
On 2020-05-25, Darren S. wrote: > OpenBSD 6.6 amd64 > OpenSMTPD 6.6.0 > Dovecot 2.3.9.3 (9f41b88fa) > login_duo 1.11.2 > > I'm working with an OpenSMTPD/Dovecot installation that will support > users authenticating over the internet and I'm curious if any form of > multi-factor authentication is possible for IMAP (and optionally, > SMTP). No, this can't really work directly for IMAP (you could have a mechanism that uses a password and OTP together in the password field, but a typical client will make multiple connections at different times, so this won't work in a usable way). Current methods working something along these lines use OAuth2 - multi factor would be used when creating an access token (usually done via a web interface) and then an IMAP/SMTP client would use this for the normal logins. Dovecot supports this for IMAP - I haven't noticed any open source MTAs that do this for SMTP though (gmail offers it and it works in some MUAs). > Currently SMTP auth and Dovecot both authenticate users over TLS using > their system user passwords. I have also set up Duo MFA for sshd using > the login_duo package so admins can additionally authenticate with a > push notification to phone. > > Is there any sort of supported way of wiring up login_duo with > OpenSMTPD and Dovecot, or using bsdauth in some way to enforce a > second auth factor? bsdauth isn't really setup for multi factor, the only way I've seen this done is splitting the password field into a fixed-length OTP and a password.
Re: Message WARNING: CHECK AND RESET THE DATE! in kvm guests
On Mon, May 25, 2020 at 07:53:47AM +, Carlos Lopez wrote: > Hi all, > > After upgrading four kvm guests to OpenBSD 6.7, I see the following messages > when these guests starts: > > WARNING: clock gained 2 days > WARNING: CHECK AND RESET THE DATE! This means the clock compared to the last mounted filesystem time differ. Show what ntpd is doing after boot (see /var/log/daemon). If ntpd sets the time ok, there is nothing further to be done. It's just a warning that the kernel initially isn't sure about the time. -Otto > > All four guests are fully patched. Dmesg output: > > OpenBSD 6.7 (GENERIC) #1: Sat May 16 16:07:20 MDT 2020 > r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC > real mem = 788389888 (751MB) > avail mem = 752021504 (717MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5af0 (9 entries) > bios0: vendor SeaBIOS version "1.11.1-4.module+el8.1.0+4066+0f1aadab" date > 04/01/2014 > bios0: Red Hat KVM > acpi0 at bios0: ACPI 3.0 > acpi0: sleep states S5 > acpi0: tables DSDT FACP APIC MCFG > 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: Intel Core Processor (Broadwell), 1900.30 MHz, 06-3d-02 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,ARAT,XSAVEOPT,MELTDOWN > cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB > 64b/line 16-way L2 cache > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 1000MHz > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins > acpimcfg0 at acpi0 > acpimcfg0: addr 0xb000, bus 0-255 > acpiprt0 at acpi0: bus 0 (PCI0) > acpicpu0 at acpi0: C1(@1 halt!) > "ACPI0006" at acpi0 not configured > acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 > acpicmos0 at acpi0 > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "QEMU0002" at acpi0 not configured > "ACPI0010" at acpi0 not configured > cpu0: using Broadwell MDS workaround > pvbus0 at mainbus0: KVM > pvclock0 at pvbus0 > pci0 at mainbus0 bus 0 > Pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00 > vga1 at pci0 dev 1 function 0 "Red Hat QXL Video" rev 0x04 > wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) > wsdisplay0: screen 1-5 added (80x25, vt100 emulation) > ppb0 at pci0 dev 2 function 0 vendor "Red Hat", unknown product 0x000c rev > 0x00: apic 0 int 22 > pci1 at ppb0 bus 1 > virtio0 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01 > vio0 at virtio0: address 00:50:56:f3:d8:1f > virtio0: msix shared > ppb1 at pci0 dev 2 function 1 vendor "Red Hat", unknown product 0x000c rev > 0x00: apic 0 int 22 > pci2 at ppb1 bus 2 > virtio1 at pci2 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01 > vio1 at virtio1: address 00:50:56:b8:2b:4a > virtio1: msix shared > ppb2 at pci0 dev 2 function 2 vendor "Red Hat", unknown product 0x000c rev > 0x00: apic 0 int 22 > pci3 at ppb2 bus 3 > virtio2 at pci3 dev 0 function 0 "Qumranet Virtio 1.x Console" rev 0x01 > virtio2: no matching child driver; not configured > ppb3 at pci0 dev 2 function 3 vendor "Red Hat", unknown product 0x000c rev > 0x00: apic 0 int 22 > pci4 at ppb3 bus 4 > virtio3 at pci4 dev 0 function 0 "Qumranet Virtio 1.x Storage" rev 0x01 > vioblk0 at virtio3 > scsibus1 at vioblk0: 2 targets > sd0 at scsibus1 targ 0 lun 0: > sd0: 16384MB, 512 bytes/sector, 33554432 sectors > virtio3: msix shared > ppb4 at pci0 dev 2 function 4 vendor "Red Hat", unknown product 0x000c rev > 0x00: apic 0 int 22 > pci5 at ppb4 bus 5 > virtio4 at pci5 dev 0 function 0 vendor "Qumranet", unknown product 0x1045 > rev 0x01 > viomb0 at virtio4 > virtio4: apic 0 int 22 > ppb5 at pci0 dev 2 function 5 vendor "Red Hat", unknown product 0x000c rev > 0x00: apic 0 int 22 > pci6 at ppb5 bus 6 > virtio5 at pci6 dev 0 function 0 "Qumranet Virtio 1.x RNG" rev 0x01 > viornd0 at virtio5 > virtio5: apic 0 int 22 > ppb6 at pci0 dev 2 function 6 vendor "Red Hat", unknown product 0x000c rev > 0x00: apic 0 int 22 > pci7 at ppb6 bus 7 > pcib0 at pci0 dev 31 function 0 "Intel 82801IB LPC" rev 0x02 > ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x02: msi, AHCI 1.0 > scsibus2 at ahci0: 32 targets > ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 0 int 16 > iic0 at ichiic0 > isa0 at pcib0 > isadma0 at isa0 > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > pckbc0 at
Message WARNING: CHECK AND RESET THE DATE! in kvm guests
Hi all, After upgrading four kvm guests to OpenBSD 6.7, I see the following messages when these guests starts: WARNING: clock gained 2 days WARNING: CHECK AND RESET THE DATE! All four guests are fully patched. Dmesg output: OpenBSD 6.7 (GENERIC) #1: Sat May 16 16:07:20 MDT 2020 r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 788389888 (751MB) avail mem = 752021504 (717MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf5af0 (9 entries) bios0: vendor SeaBIOS version "1.11.1-4.module+el8.1.0+4066+0f1aadab" date 04/01/2014 bios0: Red Hat KVM acpi0 at bios0: ACPI 3.0 acpi0: sleep states S5 acpi0: tables DSDT FACP APIC MCFG 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: Intel Core Processor (Broadwell), 1900.30 MHz, 06-3d-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,PCLMUL,SSSE3,FMA3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,RDTSCP,LONG,LAHF,ABM,3DNOWP,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,ARAT,XSAVEOPT,MELTDOWN cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 1000MHz ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xb000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: C1(@1 halt!) "ACPI0006" at acpi0 not configured acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 "PNP0A06" at acpi0 not configured "PNP0A06" at acpi0 not configured "QEMU0002" at acpi0 not configured "ACPI0010" at acpi0 not configured cpu0: using Broadwell MDS workaround pvbus0 at mainbus0: KVM pvclock0 at pvbus0 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel 82G33 Host" rev 0x00 vga1 at pci0 dev 1 function 0 "Red Hat QXL Video" rev 0x04 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) ppb0 at pci0 dev 2 function 0 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci1 at ppb0 bus 1 virtio0 at pci1 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01 vio0 at virtio0: address 00:50:56:f3:d8:1f virtio0: msix shared ppb1 at pci0 dev 2 function 1 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci2 at ppb1 bus 2 virtio1 at pci2 dev 0 function 0 "Qumranet Virtio 1.x Network" rev 0x01 vio1 at virtio1: address 00:50:56:b8:2b:4a virtio1: msix shared ppb2 at pci0 dev 2 function 2 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci3 at ppb2 bus 3 virtio2 at pci3 dev 0 function 0 "Qumranet Virtio 1.x Console" rev 0x01 virtio2: no matching child driver; not configured ppb3 at pci0 dev 2 function 3 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci4 at ppb3 bus 4 virtio3 at pci4 dev 0 function 0 "Qumranet Virtio 1.x Storage" rev 0x01 vioblk0 at virtio3 scsibus1 at vioblk0: 2 targets sd0 at scsibus1 targ 0 lun 0: sd0: 16384MB, 512 bytes/sector, 33554432 sectors virtio3: msix shared ppb4 at pci0 dev 2 function 4 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci5 at ppb4 bus 5 virtio4 at pci5 dev 0 function 0 vendor "Qumranet", unknown product 0x1045 rev 0x01 viomb0 at virtio4 virtio4: apic 0 int 22 ppb5 at pci0 dev 2 function 5 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci6 at ppb5 bus 6 virtio5 at pci6 dev 0 function 0 "Qumranet Virtio 1.x RNG" rev 0x01 viornd0 at virtio5 virtio5: apic 0 int 22 ppb6 at pci0 dev 2 function 6 vendor "Red Hat", unknown product 0x000c rev 0x00: apic 0 int 22 pci7 at ppb6 bus 7 pcib0 at pci0 dev 31 function 0 "Intel 82801IB LPC" rev 0x02 ahci0 at pci0 dev 31 function 2 "Intel 82801I AHCI" rev 0x02: msi, AHCI 1.0 scsibus2 at ahci0: 32 targets ichiic0 at pci0 dev 31 function 3 "Intel 82801I SMBus" rev 0x02: apic 0 int 16 iic0 at ichiic0 isa0 at pcib0 isadma0 at isa0 com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pckbc0 at isa0 port 0x60/5 irq 1 irq 12 pckbd0 at pckbc0 (kbd slot) wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 spkr0 at pcppi0 vscsi0 at root scsibus3 at vscsi0: 256 targets softraid0 at root scsibus4 at softraid0: 256 targets root on sd0a (91a26d47938d3239.a) swap on sd0b dump on sd0b WARNING: clock gained 2 days WARNING: CHECK AND RESET THE DATE! Do I need to reconfigure something in OpenBSD? Regards, C. L. Martinez
Re: Why does OpenBSD still include Perl in its base installation?
Good morning Dawid, Have you looked at different installations methods and post install options ? Customizing the Install Process https://www.openbsd.org/faq/faq4.html#site This will certainly be worth looking at if you intend to optimize and customize installation. Regards, Jean-François Le 23/05/2020 à 17:38, Dawid Czeluśniak a écrit : An important note: If you do any of that and subsequently encounter a problem, you must 1. Assume you created that problem for yourself 2. Not file a bug report 3. Not complain to others on OpenBSD mailing lists. Fair enough. Thank you all for a detailed explanation.
Re: 6.7 boot crashes on "entry point at" X1 Carbon gen7 i7-10510U
On Sun, May 24, 2020 at 09:46:09PM +0900, John Mettraux wrote: > On Sun, May 24, 2020 at 8:38 PM Otto Moerbeek wrote: > > > > On Sun, May 24, 2020 at 08:26:43PM +0900, John Mettraux wrote: > > > > > On Sun, May 24, 2020 at 5:36 PM Stuart Henderson > > > wrote: > > > > > > > > On 2020-05-23, John Mettraux wrote: > > > > > > > > > > (...) > > > > > > > > > > Hard power down is the only way out, but rebooting still leads > > > > > immediately to the > > > > > "entry point at 0x1001000" wall. It is consistent. I tried boot -c, > > > > > boot -d or boot -s, > > > > > still the same wall. > > > > > > > > > > I have just tried with the install67.img snapshot (22-May-2020 21:12 > > > > > 476545024) from > > > > > https://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/ but it leads to > > > > > the same > > > > > "entry point at 0x1001000" right after boot. > > > > > > > > Try downloading a 6.7 kernel (bsd.mp) to e.g. /bsd.test, and from the > > > > 6.6 boot > > > > loader type "b /bsd.test". Do you still get the hang? This will give > > > > you an idea > > > > whether the problem in 6.7 is with the newer boot loader or the kernel. > > > > > > I can confirm that the hang doesn't happen with the 6.7 kernel and the > > > 6.6 boot > > > loader (bootx64 3.46). The hang happens with the 6.7 boot loader (3.50). > > > > > > I will try to do a 6.7 install with the 3.46 boot loader. > > > > Can you also try using legacy boot mode (mbr)? There should be some > > setting in the bios to enable that. > > > > -Otto > > I tried to set the boot mode to [Legacy First] and [Legacy Only]. In > both cases the Boot 3.47 kicked in > and allowed me to install. > > I performed the install on the machine drive (sd0) with MBR and the > install was successful. > Dmesg below for the resulting 6.7 Snapshot. > > I tried to install on sd0 with GPT. The install warned me "An EFI/GPT > disk may not boot. Proceed?" > I answered yes. The install proceeded but upon reboot it froze with > the "entry point at 0x1001000". > This was with bootx64 3.50. > > I am going to re-install with sd0 MBR. > > Thanks a lot! > > John I have an x1 6th generation that also does not like to boot using EFI. There's is a difference though: it already had problems with EFI when I initially installed it in Feb 2019. I'll see if I can find some time to make a more detail diagnosis. -Otto > > ---dmesg--- > > OpenBSD 6.7-current (RAMDISK_CD) #204: Fri May 22 20:38:04 MDT 2020 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD > real mem = 16197828608 (15447MB) > avail mem = 15702892544 (14975MB) > random: good seed from bootblocks > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x6cc77000 (65 entries) > bios0: vendor LENOVO version "N2QET18W (1.12 )" date 12/10/2019 > bios0: LENOVO 20R1CTO1WW > acpi0 at bios0: ACPI 6.1 > acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT TPM2 SSDT HPET APIC > MCFG ECDT SSDT SSDT SSDT NHLT BOOT SSDT LPIT WSMT SSDT DBGP DBG2 MSDM > BATB DMAR UEFI FPDT > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-10510U CPU @ 1.80GHz, 7498.82 MHz, 06-8e-0c > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: apic clock running at 24MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins > acpiec0 at acpi0 > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (RP01) > acpiprt2 at acpi0: bus -1 (RP02) > 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 3 (RP09) > acpiprt10 at acpi0: bus -1 (RP10) > acpiprt11 at acpi0: bus -1 (RP11) > acpiprt12 at acpi0: bus -1 (RP12) > acpiprt13 at acpi0: bus 5 (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) > acpiprt20 at acpi0: bus -1 (RP20) > acpiprt21 at acpi0: bus -1 (RP21) > acpiprt22 at acpi0: bus -1 (RP22) > acpiprt23 at acpi0:
