ulpt vs kernel relinking
Hi, I have a printer that require ulpt to be disabled as mentionned in /usr/local/share/doc/pkg-readmes/cups. And it works. # config -fe /bsd disable ulpt quit After a reboot, I can notice : reorder_kernel: kernel relinking failed; see /usr/share/relink/kernel/GENERIC.MP/relink.log Ok, so I run, as mentioned in the above file : sha256 -h /var/db/kernel.SHA256 /bsd However, at next reboot, ulpt is reenabled. How can I still have KARL and use my printer ? -- thuban
Re: ulpt vs kernel relinking
config -e is incompatible with the KARL relinking sequence. For now, we consider KARL more valuable than config -e usage patterns. We've thought about this but for now we don't have a clever solution to solve this. Thuban wrote: > Hi, > I have a printer that require ulpt to be disabled > as mentionned in /usr/local/share/doc/pkg-readmes/cups. And it works. > > # config -fe /bsd > disable ulpt > quit > > After a reboot, I can notice : > > reorder_kernel: kernel relinking failed; see > /usr/share/relink/kernel/GENERIC.MP/relink.log > > Ok, so I run, as mentioned in the above file : > > sha256 -h /var/db/kernel.SHA256 /bsd > > However, at next reboot, ulpt is reenabled. > > How can I still have KARL and use my printer ? > > > -- > thuban >
Re: 6.5 PowerPC Packages
>On Thu, May 09, 2019 at 06:12:54PM -0400, Christopher Turkel wrote: >> Be careful, you could a rip a whole in the time space continuum. > >Speaking of ripping anything with the time space continuum. I know the >CD's are an artifact of the past, but since we have time machines, can >someone find out why it is that after the 5.5 release (with the back to >the future theme coincidentally) the macppc port was stopped being called >"macppc" on CD#2? Instead it was called "powerpc" again which it hasn't >been called since 3.0 days or so. At first I thought someone swapped my >CD with a pirated copy and messed up on this, but it seems that we've >been travelling in a parallel dimension since 5.5. I just noticed this >last week btw. This is akin to calling i386, x86 all of sudden. > >Why was it called powerpc on the CD #2, after 5.5? To see if anyone cared.
Re: 6.5 PowerPC Packages
On Thu, May 09, 2019 at 06:12:54PM -0400, Christopher Turkel wrote: > Be careful, you could a rip a whole in the time space continuum. Speaking of ripping anything with the time space continuum. I know the CD's are an artifact of the past, but since we have time machines, can someone find out why it is that after the 5.5 release (with the back to the future theme coincidentally) the macppc port was stopped being called "macppc" on CD#2? Instead it was called "powerpc" again which it hasn't been called since 3.0 days or so. At first I thought someone swapped my CD with a pirated copy and messed up on this, but it seems that we've been travelling in a parallel dimension since 5.5. I just noticed this last week btw. This is akin to calling i386, x86 all of sudden. Why was it called powerpc on the CD #2, after 5.5? Regards, -peter
Re: Danish FreeBSD Developer hates jews collectively
On Thu, 09 May 2019 18:03:04 + ossobser...@redchan.it wrote: > Background: Apparently a FreeBSD developer, a viking looking fellow, > has been hiding a secret: just as many of his predecessors in the > Danish cities during WWII (collaborators); He has a disdain for "the > jews" collectively. > Who cares!?
Re: Thinkpad A285 mouse issues
On Thu, May 09, 2019 at 04:17:40PM +0100, Oriol Demaria wrote: > I have this laptop and I'm having issues with this laptop. Wireless has to > be replaced and basically have to wait till the graphics card is properly > supported, right now is running X with the UEFI framebuffer. So this issues > are expected. > > But I'm having a very annoying bug on X. The mouse stops working, specially > Firefox seems to be a problem, but other apps too (perhaps I notice more > here as others I mainly use the keyboard). When I run xprop to try to figure > out something I get the error "Can't grab the mouse" and won't run. Seems > that some event holds the mouse, and prevents you from "clicking". > > Changed the touchpad to synaptics to see if it makes difference, seems to > improve a bit, but still the problem comes back. The other mouse devices are > using ws driver. Has someone got a workaround for this? Similar experience? Try a non-mp kernel or sysctl kern.timecounter.hardware=acpihpet0 > > Thanks in advance. > > Relevant part of the xorg log file: > > [ 18193.428] (II) XINPUT: Adding extended input device "/dev/wskbd" (type: > KEYBOARD, id 6) > [ 18193.925] (II) config/wscons: checking input device /dev/wsmouse0 > [ 18193.925] (**) /dev/wsmouse0: Applying InputClass "wsmouse touchpad" > [ 18193.925] (II) LoadModule: "synaptics" > [ 18193.927] (II) Loading /usr/X11R6/lib/modules/input/synaptics_drv.so > [ 18193.929] (II) Module synaptics: vendor="X.Org Foundation" > [ 18193.929]compiled for 1.19.7, module version = 1.9.1 > [ 18193.929]Module class: X.Org XInput Driver > [ 18193.929]ABI class: X.Org XInput driver, version 24.1 > [ 18193.929] (II) Using input driver 'synaptics' for '/dev/wsmouse0' > [ 18193.929] (**) /dev/wsmouse0: always reports core events > [ 18193.929] (**) Option "Device" "/dev/wsmouse0" > [ 18194.831] (--) synaptics: /dev/wsmouse0: x-axis range 1266 - 5676 > resolution 45 > [ 18194.831] (--) synaptics: /dev/wsmouse0: y-axis range 1094 - 4760 > resolution 69 > [ 18194.832] (**) /dev/wsmouse0: always reports core events > [ 18194.835] (II) XINPUT: Adding extended input device "/dev/wsmouse0" > (type: TOUCHPAD, id 7) > [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MinSpeed is now constant > deceleration 2.5 > [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MaxSpeed is now 1.75 > [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) AccelFactor is now 0.035 > [ 18194.836] (**) /dev/wsmouse0: (accel) keeping acceleration scheme 1 > [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration profile 1 > [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration factor: 2.000 > [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration threshold: 4 > [ 18195.340] (II) config/wscons: checking input device /dev/wsmouse > [ 18195.340] (II) LoadModule: "ws" > [ 18195.341] (II) Loading /usr/X11R6/lib/modules/input/ws_drv.so > [ 18195.342] (II) Module ws: vendor="X.Org Foundation" > [ 18195.342]compiled for 1.19.7, module version = 1.3.0 > [ 18195.342]Module class: X.Org XInput Driver > [ 18195.342]ABI class: X.Org XInput driver, version 24.1 > [ 18195.343] (II) Using input driver 'ws' for '/dev/wsmouse' > [ 18195.343] (**) /dev/wsmouse: always reports core events > [ 18195.343] (II) ws: /dev/wsmouse: debuglevel 0 > [ 18195.343] (**) Option "Device" "/dev/wsmouse" > [ 18195.343] (**) ws: /dev/wsmouse: ZAxisMapping: buttons 4 and 5 > [ 18195.343] (**) ws: /dev/wsmouse: WAxisMapping: buttons 6 and 7 > [ 18195.343] (**) ws: /dev/wsmouse: associated screen: 0 > [ 18195.372] (II) ws: /dev/wsmouse: minimum x position: 0 > [ 18195.372] (II) ws: /dev/wsmouse: maximum x position: 1919 > [ 18195.372] (II) ws: /dev/wsmouse: minimum y position: 0 > [ 18195.372] (II) ws: /dev/wsmouse: maximum y position: 1079 > [ 18195.372] (==) ws: /dev/wsmouse: Buttons: 7 > [ 18195.404] (**) ws: /dev/wsmouse: YAxisMapping: buttons 4 and 5 > [ 18195.404] (II) XINPUT: Adding extended input device "/dev/wsmouse" (type: > MOUSE, id 8) > [ 18195.436] (**) /dev/wsmouse: (accel) keeping acceleration scheme 1 > [ 18195.436] (**) /dev/wsmouse: (accel) acceleration profile 0 > [ 18195.436] (**) /dev/wsmouse: (accel) acceleration factor: 2.000 > [ 18195.436] (**) /dev/wsmouse: (accel) acceleration threshold: 4 > > wsconsctl | grep mouse > mouse.type=synaptics > mouse.rawmode=0 > mouse.scale=1266,5676,1094,4760,0,45,69 > mouse.tp.tapping=0 > mouse.tp.scaling=0.160 > mouse.tp.swapsides=0 > mouse.tp.disable=0 > mouse.tp.edges=0.0,5.0,10.0,5.0 > mouse1.type=ps2 > mouse2.type=usb > > > -- > Oriol Demaria > 2FFED630C16E4FF8 >
Re: Thinkpad A285 mouse issues
Could you please post a dmesg and your xorg.conf, and be a bit more specific about your observations? Does the problem only affect the touchpad, or all wsmouse devices? Does it occur regularly, always, sometimes? Does the mouse pointer just freeze, or is there random movement, or sluggish movement? In which way is it application-dependent? On 5/9/19 5:17 PM, Oriol Demaria wrote: > I have this laptop and I'm having issues with this laptop. Wireless has to be > replaced and basically have to wait till the graphics card is properly > supported, right now is running X with the UEFI framebuffer. So this issues > are expected. > > But I'm having a very annoying bug on X. The mouse stops working, specially > Firefox seems to be a problem, but other apps too (perhaps I notice more here > as others I mainly use the keyboard). When I run xprop to try to figure out > something I get the error "Can't grab the mouse" and won't run. Seems > that some event holds the mouse, and prevents you from "clicking". > > Changed the touchpad to synaptics to see if it makes difference, seems to > improve a bit, but still the problem comes back. The other mouse devices are > using ws driver. Has someone got a workaround for this? Similar experience? > > Thanks in advance. > > Relevant part of the xorg log file: > > [ 18193.428] (II) XINPUT: Adding extended input device "/dev/wskbd" (type: > KEYBOARD, id 6) > [ 18193.925] (II) config/wscons: checking input device /dev/wsmouse0 > [ 18193.925] (**) /dev/wsmouse0: Applying InputClass "wsmouse touchpad" > [ 18193.925] (II) LoadModule: "synaptics" > [ 18193.927] (II) Loading /usr/X11R6/lib/modules/input/synaptics_drv.so > [ 18193.929] (II) Module synaptics: vendor="X.Org Foundation" > [ 18193.929] compiled for 1.19.7, module version = 1.9.1 > [ 18193.929] Module class: X.Org XInput Driver > [ 18193.929] ABI class: X.Org XInput driver, version 24.1 > [ 18193.929] (II) Using input driver 'synaptics' for '/dev/wsmouse0' > [ 18193.929] (**) /dev/wsmouse0: always reports core events > [ 18193.929] (**) Option "Device" "/dev/wsmouse0" > [ 18194.831] (--) synaptics: /dev/wsmouse0: x-axis range 1266 - 5676 > resolution 45 > [ 18194.831] (--) synaptics: /dev/wsmouse0: y-axis range 1094 - 4760 > resolution 69 > [ 18194.832] (**) /dev/wsmouse0: always reports core events > [ 18194.835] (II) XINPUT: Adding extended input device "/dev/wsmouse0" (type: > TOUCHPAD, id 7) > [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MinSpeed is now constant > deceleration 2.5 > [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MaxSpeed is now 1.75 > [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) AccelFactor is now 0.035 > [ 18194.836] (**) /dev/wsmouse0: (accel) keeping acceleration scheme 1 > [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration profile 1 > [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration factor: 2.000 > [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration threshold: 4 > [ 18195.340] (II) config/wscons: checking input device /dev/wsmouse > [ 18195.340] (II) LoadModule: "ws" > [ 18195.341] (II) Loading /usr/X11R6/lib/modules/input/ws_drv.so > [ 18195.342] (II) Module ws: vendor="X.Org Foundation" > [ 18195.342] compiled for 1.19.7, module version = 1.3.0 > [ 18195.342] Module class: X.Org XInput Driver > [ 18195.342] ABI class: X.Org XInput driver, version 24.1 > [ 18195.343] (II) Using input driver 'ws' for '/dev/wsmouse' > [ 18195.343] (**) /dev/wsmouse: always reports core events > [ 18195.343] (II) ws: /dev/wsmouse: debuglevel 0 > [ 18195.343] (**) Option "Device" "/dev/wsmouse" > [ 18195.343] (**) ws: /dev/wsmouse: ZAxisMapping: buttons 4 and 5 > [ 18195.343] (**) ws: /dev/wsmouse: WAxisMapping: buttons 6 and 7 > [ 18195.343] (**) ws: /dev/wsmouse: associated screen: 0 > [ 18195.372] (II) ws: /dev/wsmouse: minimum x position: 0 > [ 18195.372] (II) ws: /dev/wsmouse: maximum x position: 1919 > [ 18195.372] (II) ws: /dev/wsmouse: minimum y position: 0 > [ 18195.372] (II) ws: /dev/wsmouse: maximum y position: 1079 > [ 18195.372] (==) ws: /dev/wsmouse: Buttons: 7 > [ 18195.404] (**) ws: /dev/wsmouse: YAxisMapping: buttons 4 and 5 > [ 18195.404] (II) XINPUT: Adding extended input device "/dev/wsmouse" (type: > MOUSE, id 8) > [ 18195.436] (**) /dev/wsmouse: (accel) keeping acceleration scheme 1 > [ 18195.436] (**) /dev/wsmouse: (accel) acceleration profile 0 > [ 18195.436] (**) /dev/wsmouse: (accel) acceleration factor: 2.000 > [ 18195.436] (**) /dev/wsmouse: (accel) acceleration threshold: 4 > > wsconsctl | grep mouse > mouse.type=synaptics > mouse.rawmode=0 > mouse.scale=1266,5676,1094,4760,0,45,69 > mouse.tp.tapping=0 > mouse.tp.scaling=0.160 > mouse.tp.swapsides=0 > mouse.tp.disable=0 > mouse.tp.edges=0.0,5.0,10.0,5.0 > mouse1.type=ps2 > mouse2.type=usb > >
Re: 6.5 PowerPC Packages
On Thu, May 9, 2019 at 5:55 PM Edgar Pettijohn wrote: > > On May 9, 2019 2:45 PM, Henry Bonath wrote: > > > > Only if said trailer is Delorean-shaped. > > Maybe just attach a second delorian to the first. > > > > > On Thu, May 9, 2019 at 3:43 PM Edgar Pettijohn > wrote: > > > > > > > > > On May 9, 2019 10:41 AM, danieljb...@icloud.com wrote: > > > > > > > > On Thu, May 09, 2019 at 08:55:40AM -0600, Theo de Raadt wrote: > > > > > The real reason is because we're low on current for the flux > capacitor, > > > > > after shifting time for the early 6.5 release. Not all the > machines > > > > > were able to fit into back seat of the Delorian. > > > > > > > > > > > > > Come on Theo, everybody knows that you can't run a flux capacitor > > > > without 1.21 gigawatts. Great Scott > > > > > > > > > > Perhaps we can get a trailer to pull behind the delorian so we can fit > all of the machines. > > > > > Be careful, you could a rip a whole in the time space continuum.
Re: 6.5 PowerPC Packages
On May 9, 2019 2:45 PM, Henry Bonath wrote: > > Only if said trailer is Delorean-shaped. Maybe just attach a second delorian to the first. > > On Thu, May 9, 2019 at 3:43 PM Edgar Pettijohn > wrote: > > > > > > On May 9, 2019 10:41 AM, danieljb...@icloud.com wrote: > > > > > > On Thu, May 09, 2019 at 08:55:40AM -0600, Theo de Raadt wrote: > > > > The real reason is because we're low on current for the flux capacitor, > > > > after shifting time for the early 6.5 release. Not all the machines > > > > were able to fit into back seat of the Delorian. > > > > > > > > > > Come on Theo, everybody knows that you can't run a flux capacitor > > > without 1.21 gigawatts. Great Scott > > > > > > > Perhaps we can get a trailer to pull behind the delorian so we can fit all > > of the machines. > >
Re: single user question
James Huddle on Thursday, May 9, 2019 9:22 AM: > Is anyone running in single-user mode regularly? > Is anyone running a web server, for instance, in single-user mode? This reads a lot like one of those questions where someone asks how to do a specific thing in a very specific way with a very specific tool, when the real question they should be asking is how to do it more generally. With that in mind, what are you actually trying to do? -- Troy
Re: post-6.5-upgrade bgpd(8) problem
On Thu, May 09, 2019 at 10:58:54AM -0500, Adam Thompson wrote:
> I've upgraded my looking glass from 6.4 to 6.5, and an experiencing an
> unexpected problem - routes learned from one (iBGP) peer are not being
> automatically exported to other (eBGP) peers.
>
> I did not change /etc/bgpd.conf, but behaviour seems to have changed
> nonetheless. The upgrade from 6.4 to 6.5 appeared smooth otherwise, nothing
> to suggest subtle breakage under the hood.
>
> As you can see below, this bgpd.conf is almost so simple it *can't* have
> problems. Apparently "almost" being the operative word.
>
> Under 6.4, this behaved as though "export none" only applied to the first
> group. Under 6.5, it behaves as though "export none" is a global setting.
>
> Under 6.5, bgpctl show produces:
> root@bgpmirror:~# bgpctl sh
> Neighbor ASMsgRcvdMsgSent OutQ Up/Down
> State/PrfRcvd
> Hermes IPv4 16796 128773 85 0 00:41:40
> 753748
> Hermes IPv6 16796 29727 85 0 00:41:40
> 68228
> MBNOG IPv4 65204 97 85 0 00:41:40
> 0
> MBNOG IPv6 65204 97 85 0 00:41:40
> 0
> BGPMon.io IPv4 6447 0 21 0 Never
> Active
> isolario.it IPv465517 86 85 0 00:41:39
> 0
> isolario.it IPv665517 86 85 0 00:41:39
> 0
> and the operator of the MBNOG route collector confirms that I stopped
> sending him a full routing table at the same time I did the OS upgrade.
>
> Any ideas? What other information would help diagnose this problem?
>
> Thanks,
> -Adam
>
>
>
> Dmesg & bgpd.conf:
> https://gist.github.com/athompso/e334d8621ce458925e25bb44b8068341
>
>
> bgpd.conf, duplicated here for convenience:
>
> ===BOF===
> route-collector yes
You have route-collector turned on and so you disable the decision process
and so no prefix will be selected and sent out. This is the way it is
supposed to work. Your setup is not a route-collector.
In 6.4 route-collector mode was broken (as in you could not turn it on)
and I fixed this. That is why your noticed the behaviour change.
> socket "/var/www/run/bgpd.rsock" restricted # for bgplg
>
> # settings
> nexthop qualify via default
> fib-update no
> dump table-v2 "/var/www/htdocs/bgplg/mrt/rib-dump.mrt" 3600
> dump updates in "/var/www/htdocs/bgplg/mrt/updates-in-%H%M" 300
> dump all in "/var/www/htdocs/bgplg/mrt/all-in-%H%M" 300
>
> # myself
> AS X
> router-id X.X.X.X
>
> # neighbors
>
> group hermes {
> enforce local-as no
> enforce neighbor-as no
> export none
>
> neighbor X.X.X.X {
> remote-as X
> descr "Hermes IPv4"
> }
> neighbor X:X:X:X::X {
> remote-as X
> descr "Hermes IPv6"
> }
> }
>
> group bgpresearch {
> multihop 32
> enforce local-as no
> enforce neighbor-as no
>
> neighbor 192.160.102.196 {
> remote-as 65204
> descr "MBNOG IPv4"
> }
> neighbor 2620:132:3003:300::196 {
> remote-as 65204
> descr "MBNOG IPv6"
> }
> neighbor 129.82.138.6 {
> remote-as 6447
> descr "BGPMon.io IPv4"
> }
> neighbor 146.48.78.12 {
> remote-as 65517
> descr "isolario.it IPv4"
> }
> neighbor 2a00:1620:c0:4e:146:48:78:12 {
> remote-as 65517
> descr "isolario.it IPv6"
> }
> }
>
> # policies
> allow quick from group hermes
> allow quick to group bgpresearch
> ===EOF===
>
> (if you want to see the unredacted version of bgpd.conf, ask and I'll email
> it directly to you, I just don't want internal addresses in the public
> archive.)
>
--
:wq Claudio
Re: post-6.5-upgrade bgpd(8) problem
On 2019-05-09 13:53, Sebastian Benoit wrote: bgpctl sh rib neigh out for all neighbors. All empty. Also look at bgpctl sh rib best Completely empty. if any routes are actually selected - maybe the "nexthop qualify via default" isnt working. I see two things... 1) when run as "bgpd -dv" I get repeated notifications about the same next-hops, dunno if that's normal or not. And 2) from bgpd.conf(5): route-collector (yes|no) If set to yes, the route selection process is turned off. The default is no. and I have it set to yes, since this is supposed to behave like a route collector. Granted, with a single source of routes at the moment, I could turn that off... let's see what happens when I do: Yup. That behaviour has definitely changed, somehow - taking a not-so-wild guess, it's likely _somehow_ related to claudio@'s introduction of Adj-Rib-Out but I'm not enough of a C programmer (or kernel routing expert) to say for sure. For now, commenting out the "route-collector yes" line in bgpd.conf will work, but there's a (for me) minor regression. I have no idea which way the code is supposed to behave, so can't tell if this is a bug or a bugfix! Based on CVS logs, it's probably a change introduced in rde.c after v1.442. -Adam
Re: single user question
On 5/9/2019 9:21 AM, James Huddle wrote: If the following questions trigger a sense of road rage, you may safely assume they are not directed to you. Is anyone running in single-user mode regularly? Is anyone running a web server, for instance, in single-user mode? Many thanks in advance. Shields up. -Jim It is theoretically possible to do that, but you'd have to do -a lot- of work to get it to do so. It'd be much easier finding a proper way to accomplish what you want without running single-user. Single-user is meant as a fail-safe in case your system is too broken to boot normally, but not so broken that you have to resort to bsd.rd It lacks the ability to start any daemons that aren't run as root, you'll have to manually mount your partitions (including remounting root as R/W), networking isn't going to be configured yet, and even when its up, you aren't going to have any security features turned on, and just so much else you'd expect in an OS is going to be missing.
Re: samba : snapshots of 6.5
I think that the microsoft will continue to change its network system in order not to be invaded by free UNIX . If so, the pursuit of samba will be painful . But it is only a personal imagination
Re: 6.5 PowerPC Packages
Only if said trailer is Delorean-shaped. On Thu, May 9, 2019 at 3:43 PM Edgar Pettijohn wrote: > > > On May 9, 2019 10:41 AM, danieljb...@icloud.com wrote: > > > > On Thu, May 09, 2019 at 08:55:40AM -0600, Theo de Raadt wrote: > > > The real reason is because we're low on current for the flux capacitor, > > > after shifting time for the early 6.5 release. Not all the machines > > > were able to fit into back seat of the Delorian. > > > > > > > Come on Theo, everybody knows that you can't run a flux capacitor > > without 1.21 gigawatts. Great Scott > > > > Perhaps we can get a trailer to pull behind the delorian so we can fit all of > the machines. >
Re: user unable to log in xenodm / Xorg session | XIO fatal io error 35
On Thu, May 2, 2019 at 7:53 PM wrote: > > SYMPTOM: Soon after a fresh OpenBSD install intended to use as a > laptop / work engine, and consequently a few uses of a graphical > session, suddenly the X session cannot start anymore : logging > in with a correct user/passwd pair provokes a crash and restart of the > X Display Manager, displaying the xdm login screen anew. > But I can still log in xdm as root. > > Xorg.0.log https://pastebin.com/pZDf90TE > xenodm.log https://pastebin.com/abjyLCyU > dmesg.boot https://pastebin.com/T3UGucB1 (also attached) Hi, What is the contents of your ~/.xsession & ~/.xsession-errors files? I had this same issue, and was able to solve it by removing .xsession or replacing it with an empty file. Ian
Re: Danish FreeBSD Developer hates jews collectively
On Thu, 9 May 2019 at 19:07, wrote: > > Background: Apparently a FreeBSD developer, a viking looking fellow, > has been hiding a secret: just as many of his predecessors in the Danish > cities during WWII (collaborators); He has a disdain for "the jews" > collectively. Freedom of expression exists to protect the rights of others to express views one might find distasteful; for a likeable/favourable expression needs no protection---it's axiomatically welcome. When opposing views are oppressed through gross generalisation and appeal to emotion, it is a clear sign that those who oppose a particular unpalatable expression lack logical argument to oppose it. For that reason, while I might (or might not) disagree with any particular expression, I would defend their right to express their views without fear, and implore others to do same while pointing big fingers of shame at those who actively suppress or oppress fundamental human freedoms! -- Igor M.
Re: 6.5 PowerPC Packages
On May 9, 2019 10:41 AM, danieljb...@icloud.com wrote: > > On Thu, May 09, 2019 at 08:55:40AM -0600, Theo de Raadt wrote: > > The real reason is because we're low on current for the flux capacitor, > > after shifting time for the early 6.5 release. Not all the machines > > were able to fit into back seat of the Delorian. > > > > Come on Theo, everybody knows that you can't run a flux capacitor > without 1.21 gigawatts. Great Scott > Perhaps we can get a trailer to pull behind the delorian so we can fit all of the machines.
Re: Danish FreeBSD Developer hates jews collectively
Enji Cooper writes: > Please leave this discussion on Twitter instead of flooding these mailing > lists. Linux/ > OpenBSD should not be exposed to this unnecessary drama, and FreeBSD-CURRENT > is the wro > ng mailing list for this (try freebsd-chat@ if you are so inclined). So you thought, why not spread it further? Matthew
Re: 6.5 PowerPC Packages
You get free shipping with any flux capacitor ‘ On Thursday, May 9, 2019, Paul Suh wrote: > On May 9, 2019, at 11:41 AM, danieljb...@icloud.com wrote: > > > > On Thu, May 09, 2019 at 08:55:40AM -0600, Theo de Raadt wrote: > >> The real reason is because we're low on current for the flux capacitor, > >> after shifting time for the early 6.5 release. Not all the machines > >> were able to fit into back seat of the Delorian. > >> > > > > Come on Theo, everybody knows that you can't run a flux capacitor > > without 1.21 gigawatts. Great Scott > > > > Not a problem. We can get a Mr. Fusion from Amazon to power the flux > capacitor: > > https://www.amazon.com/Back-Future-Mr-Fusion-Replica/dp/B00NPADMRK > > I'm off to setup a GoFundMe page for contributions towards one for the > OpenBSD project. ;-D > > > --Paul > >
Re: Danish FreeBSD Developer hates jews collectively
> On May 9, 2019, at 11:03 AM, ossobser...@redchan.it wrote: This is the only reply I’m going to give to this thread that seems like obvious troll bait. As a native English speaker who often gets into debates about controversial issues with respect to concepts like classism, LGBTIQ issues, race issues, etc, the argument phk@ made wasn’t necessary in favor of anti-semitism from the perspective of hating Jewish people or their culture/religion; it was more or less commentary about policy issues with Israelis vs Palestine, apartheid, the Gaza strip occupation and the fact that some of the Israeli people aren’t acting out against the issues between both parties in an attempt to end the conflict. With this in mind, it was a poorly worded response which led to a slippery slope in a discussion, done on a social medium (Twitter) that seems to get blown out of proportion really quickly (trolls and misinterpretation abound). This kind of reasoning presented sounds a lot like cognitive dissonance employed by the far-right in America vs individuals like Rep. Ilhan Omar, etc, where they play the victim in order to make leftist groups look like they tolerate hate against certain groups (in this case Jewish people). Does that mean that the left has anti-Semites? Yes, it can happen, regardless of one’s political allegiance if one is to believe the left vs right dichotomy (which I think is largely poppycock, meant to separate groups via tribalism, etc). However, I think a number of people are reading between the tea leaves in this thread. Do I think phk@ and others should potentially take a step back from the discussion and avoid digging a larger hole than has already been dug? Yes. It’s not my business to make people do that though, since I’m not in a leadership/policy making position. Please leave this discussion on Twitter instead of flooding these mailing lists. Linux/OpenBSD should not be exposed to this unnecessary drama, and FreeBSD-CURRENT is the wrong mailing list for this (try freebsd-chat@ if you are so inclined). -Enji PS I am not representing the FreeBSD project; I am only representing my personal opinion.
Re: post-6.5-upgrade bgpd(8) problem
Hi,
Adam Thompson(athom...@athompso.net) on 2019.05.09 10:58:54 -0500:
> I've upgraded my looking glass from 6.4 to 6.5, and an experiencing an
> unexpected problem - routes learned from one (iBGP) peer are not being
> automatically exported to other (eBGP) peers.
>
> I did not change /etc/bgpd.conf, but behaviour seems to have changed
> nonetheless. The upgrade from 6.4 to 6.5 appeared smooth otherwise,
> nothing to suggest subtle breakage under the hood.
>
> As you can see below, this bgpd.conf is almost so simple it *can't* have
> problems. Apparently "almost" being the operative word.
>
> Under 6.4, this behaved as though "export none" only applied to the
> first group. Under 6.5, it behaves as though "export none" is a global
> setting.
>
> Under 6.5, bgpctl show produces:
> root@bgpmirror:~# bgpctl sh
> Neighbor ASMsgRcvdMsgSent OutQ
> Up/Down State/PrfRcvd
> Hermes IPv4 16796 128773 85 0
> 00:41:40 753748
> Hermes IPv6 16796 29727 85 0
> 00:41:40 68228
> MBNOG IPv4 65204 97 85 0
> 00:41:40 0
> MBNOG IPv6 65204 97 85 0
> 00:41:40 0
> BGPMon.io IPv4 6447 0 21 0 Never
> Active
> isolario.it IPv465517 86 85 0
> 00:41:39 0
> isolario.it IPv665517 86 85 0
> 00:41:39 0
> and the operator of the MBNOG route collector confirms that I stopped
> sending him a full routing table at the same time I did the OS upgrade.
>
> Any ideas? What other information would help diagnose this problem?
>
> Thanks,
> -Adam
>
>
>
> Dmesg & bgpd.conf:
> https://gist.github.com/athompso/e334d8621ce458925e25bb44b8068341
>
>
> bgpd.conf, duplicated here for convenience:
>
> ===BOF===
> route-collector yes
> socket "/var/www/run/bgpd.rsock" restricted # for bgplg
>
> # settings
> nexthop qualify via default
> fib-update no
> dump table-v2 "/var/www/htdocs/bgplg/mrt/rib-dump.mrt" 3600
> dump updates in "/var/www/htdocs/bgplg/mrt/updates-in-%H%M" 300
> dump all in "/var/www/htdocs/bgplg/mrt/all-in-%H%M" 300
>
> # myself
> AS X
> router-id X.X.X.X
>
> # neighbors
>
> group hermes {
> enforce local-as no
> enforce neighbor-as no
> export none
>
> neighbor X.X.X.X {
> remote-as X
> descr "Hermes IPv4"
> }
> neighbor X:X:X:X::X {
> remote-as X
> descr "Hermes IPv6"
> }
> }
>
> group bgpresearch {
> multihop 32
> enforce local-as no
> enforce neighbor-as no
>
> neighbor 192.160.102.196 {
> remote-as 65204
> descr "MBNOG IPv4"
> }
> neighbor 2620:132:3003:300::196 {
> remote-as 65204
> descr "MBNOG IPv6"
> }
> neighbor 129.82.138.6 {
> remote-as 6447
> descr "BGPMon.io IPv4"
> }
> neighbor 146.48.78.12 {
> remote-as 65517
> descr "isolario.it IPv4"
> }
> neighbor 2a00:1620:c0:4e:146:48:78:12 {
> remote-as 65517
> descr "isolario.it IPv6"
> }
> }
>
> # policies
> allow quick from group hermes
> allow quick to group bgpresearch
> ===EOF===
Please check
bgpctl sh rib neigh out
for all neighbors.
Also look at
bgpctl sh rib best
if any routes are actually selected - maybe the "nexthop qualify via
default" isnt working.
/Benno
Re: single user question
James Huddle writes: > If the following questions trigger a sense of road rage, you may > safely assume they are not directed to you. > > Is anyone running in single-user mode regularly? I regularly boot things into single user mode to fix something or otherwise engage in acts which could be confounded by running processes holding resources open. I wouldn't say I regularly *run* in single-user mode though. > Is anyone running a web server, for instance, in single-user mode? I am not and I can't see what the benefit could be - the kernel is pretty good at process isolation. Assuming that you are asking because you perceive benefits to doing so, I would be interested to know what you think they are. As you felt the need to begin with a defensive posture I shall end with one; hopefully they will bookend that nonsense. This is not written in a spirit of road rage but a spirit of enquiry. Cheers, Matthew
Re: When will be created a great desktop experience for OpenBSD?
On Thu, May 09, 2019 at 12:52:18PM +0300, Mihai Popescu wrote: Still wondering what "great desktop experience" means ... Bullshit, that's what it means. In nearly 20 years on mailing lists and on the internet, I don't remember to have ever seen anyone asking such a stupid question like the one in the subject line. Ever. The OP doesn't seem to have the slightest grip on the fact that it's everyone's own job to configure and set up their "Desktops", just the way they want to have it. Or, alternatively, he expects the OBSD developers to fulfill his lazy wishes so he just can sit and wait see his "great desktop experience" roll onto his computer, freshly made - and at no cost, for sure - by the OBSD coders. Mindbogglingly stupid, an impudent, this idea .. Wolfgang -- OpenBSD: "software we primarily develop for ourselves -- in the hope that other people are like us and need similar things." -- Theo de Raadt
Re: 6.5 PowerPC Packages
On May 9, 2019, at 11:41 AM, danieljb...@icloud.com wrote: > > On Thu, May 09, 2019 at 08:55:40AM -0600, Theo de Raadt wrote: >> The real reason is because we're low on current for the flux capacitor, >> after shifting time for the early 6.5 release. Not all the machines >> were able to fit into back seat of the Delorian. >> > > Come on Theo, everybody knows that you can't run a flux capacitor > without 1.21 gigawatts. Great Scott > Not a problem. We can get a Mr. Fusion from Amazon to power the flux capacitor: https://www.amazon.com/Back-Future-Mr-Fusion-Replica/dp/B00NPADMRK I'm off to setup a GoFundMe page for contributions towards one for the OpenBSD project. ;-D --Paul
Re: 6.5 PowerPC Packages
On Thu, May 09, 2019 at 08:55:40AM -0600, Theo de Raadt wrote: > The real reason is because we're low on current for the flux capacitor, > after shifting time for the early 6.5 release. Not all the machines > were able to fit into back seat of the Delorian. > Come on Theo, everybody knows that you can't run a flux capacitor without 1.21 gigawatts. Great Scott
single user question
If the following questions trigger a sense of road rage, you may safely assume they are not directed to you. Is anyone running in single-user mode regularly? Is anyone running a web server, for instance, in single-user mode? Many thanks in advance. Shields up. -Jim
Re: 6.5 PowerPC Packages
Well, as far as I remember the flux capacitor runs on plutonium...Be cautious, Theo ... ;-)Joe Gesendet: Donnerstag, 09. Mai 2019 um 16:55 Uhr Von: "Theo de Raadt" An: "Christian Weisgerber" Cc: misc@openbsd.org Betreff: Re: 6.5 PowerPC PackagesChristian Weisgerber wrote: > On 2019-05-09, Henry Bonath wrote: > > > I'm not sure how many folks out there are PowerPC users, but I was > > just curious if anyone had an idea on if or when we might see those > > out in the mirrors. > > The build has been running for 25 days so far, across two machines, > and the packages will be uploaded once they are finished. > > There are two ways to go about this: We can delay the release until > all architectures have finished building, or we can start releasing > once the fast & popular archs are ready and the others will catch > up eventually. The real reason is because we're low on current for the flux capacitor, after shifting time for the early 6.5 release. Not all the machines were able to fit into back seat of the Delorian.
Re: 6.5 PowerPC Packages
On 2019-05-09, Henry Bonath wrote: > I figured that was the case, I suppose I was a little afraid that they > weren't coming! Each release, XY.html (so 65.html now) has a paragraph Many pre-built packages for each architecture: listing the architectures and the respective package count. If it says : that means we are building and there WILL be packages for that arch. I think we've only broken that promise once. (No hppa for 6.3.) -- Christian "naddy" Weisgerber na...@mips.inka.de
post-6.5-upgrade bgpd(8) problem
I've upgraded my looking glass from 6.4 to 6.5, and an experiencing an
unexpected problem - routes learned from one (iBGP) peer are not being
automatically exported to other (eBGP) peers.
I did not change /etc/bgpd.conf, but behaviour seems to have changed
nonetheless. The upgrade from 6.4 to 6.5 appeared smooth otherwise,
nothing to suggest subtle breakage under the hood.
As you can see below, this bgpd.conf is almost so simple it *can't* have
problems. Apparently "almost" being the operative word.
Under 6.4, this behaved as though "export none" only applied to the
first group. Under 6.5, it behaves as though "export none" is a global
setting.
Under 6.5, bgpctl show produces:
root@bgpmirror:~# bgpctl sh
Neighbor ASMsgRcvdMsgSent OutQ
Up/Down State/PrfRcvd
Hermes IPv4 16796 128773 85 0
00:41:40 753748
Hermes IPv6 16796 29727 85 0
00:41:40 68228
MBNOG IPv4 65204 97 85 0
00:41:40 0
MBNOG IPv6 65204 97 85 0
00:41:40 0
BGPMon.io IPv4 6447 0 21 0 Never
Active
isolario.it IPv465517 86 85 0
00:41:39 0
isolario.it IPv665517 86 85 0
00:41:39 0
and the operator of the MBNOG route collector confirms that I stopped
sending him a full routing table at the same time I did the OS upgrade.
Any ideas? What other information would help diagnose this problem?
Thanks,
-Adam
Dmesg & bgpd.conf:
https://gist.github.com/athompso/e334d8621ce458925e25bb44b8068341
bgpd.conf, duplicated here for convenience:
===BOF===
route-collector yes
socket "/var/www/run/bgpd.rsock" restricted # for bgplg
# settings
nexthop qualify via default
fib-update no
dump table-v2 "/var/www/htdocs/bgplg/mrt/rib-dump.mrt" 3600
dump updates in "/var/www/htdocs/bgplg/mrt/updates-in-%H%M" 300
dump all in "/var/www/htdocs/bgplg/mrt/all-in-%H%M" 300
# myself
AS X
router-id X.X.X.X
# neighbors
group hermes {
enforce local-as no
enforce neighbor-as no
export none
neighbor X.X.X.X {
remote-as X
descr "Hermes IPv4"
}
neighbor X:X:X:X::X {
remote-as X
descr "Hermes IPv6"
}
}
group bgpresearch {
multihop 32
enforce local-as no
enforce neighbor-as no
neighbor 192.160.102.196 {
remote-as 65204
descr "MBNOG IPv4"
}
neighbor 2620:132:3003:300::196 {
remote-as 65204
descr "MBNOG IPv6"
}
neighbor 129.82.138.6 {
remote-as 6447
descr "BGPMon.io IPv4"
}
neighbor 146.48.78.12 {
remote-as 65517
descr "isolario.it IPv4"
}
neighbor 2a00:1620:c0:4e:146:48:78:12 {
remote-as 65517
descr "isolario.it IPv6"
}
}
# policies
allow quick from group hermes
allow quick to group bgpresearch
===EOF===
(if you want to see the unredacted version of bgpd.conf, ask and I'll
email it directly to you, I just don't want internal addresses in the
public archive.)
Re: Double nat with pf ?
Mik J [mikyde...@yahoo.fr] wrote: > Hello, > Is it possible to nat both source and destination IP on the same openbsd pf > instance aka double nat ? > If yes do someone has an example of it ? are you trying to do "hairpin" NAT? what are you trying to accomplish?
Re: 6.5 PowerPC Packages
Andrew Luke Nesbit writes: > I am a user of Apple PowerBook G4, POWER8, and POWER9. I am new to > OpenBSD and I intend to experiment with it on these architectures. Unless https://www.openbsd.org/plat.html is out of date, it doesn't look like OpenBSD is currently supporting POWER8 or POWER9 plaftorms. Allan
Thinkpad A285 mouse issues
I have this laptop and I'm having issues with this laptop. Wireless has to be replaced and basically have to wait till the graphics card is properly supported, right now is running X with the UEFI framebuffer. So this issues are expected. But I'm having a very annoying bug on X. The mouse stops working, specially Firefox seems to be a problem, but other apps too (perhaps I notice more here as others I mainly use the keyboard). When I run xprop to try to figure out something I get the error "Can't grab the mouse" and won't run. Seems that some event holds the mouse, and prevents you from "clicking". Changed the touchpad to synaptics to see if it makes difference, seems to improve a bit, but still the problem comes back. The other mouse devices are using ws driver. Has someone got a workaround for this? Similar experience? Thanks in advance. Relevant part of the xorg log file: [ 18193.428] (II) XINPUT: Adding extended input device "/dev/wskbd" (type: KEYBOARD, id 6) [ 18193.925] (II) config/wscons: checking input device /dev/wsmouse0 [ 18193.925] (**) /dev/wsmouse0: Applying InputClass "wsmouse touchpad" [ 18193.925] (II) LoadModule: "synaptics" [ 18193.927] (II) Loading /usr/X11R6/lib/modules/input/synaptics_drv.so [ 18193.929] (II) Module synaptics: vendor="X.Org Foundation" [ 18193.929]compiled for 1.19.7, module version = 1.9.1 [ 18193.929]Module class: X.Org XInput Driver [ 18193.929]ABI class: X.Org XInput driver, version 24.1 [ 18193.929] (II) Using input driver 'synaptics' for '/dev/wsmouse0' [ 18193.929] (**) /dev/wsmouse0: always reports core events [ 18193.929] (**) Option "Device" "/dev/wsmouse0" [ 18194.831] (--) synaptics: /dev/wsmouse0: x-axis range 1266 - 5676 resolution 45 [ 18194.831] (--) synaptics: /dev/wsmouse0: y-axis range 1094 - 4760 resolution 69 [ 18194.832] (**) /dev/wsmouse0: always reports core events [ 18194.835] (II) XINPUT: Adding extended input device "/dev/wsmouse0" (type: TOUCHPAD, id 7) [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MinSpeed is now constant deceleration 2.5 [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) MaxSpeed is now 1.75 [ 18194.835] (**) synaptics: /dev/wsmouse0: (accel) AccelFactor is now 0.035 [ 18194.836] (**) /dev/wsmouse0: (accel) keeping acceleration scheme 1 [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration profile 1 [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration factor: 2.000 [ 18194.836] (**) /dev/wsmouse0: (accel) acceleration threshold: 4 [ 18195.340] (II) config/wscons: checking input device /dev/wsmouse [ 18195.340] (II) LoadModule: "ws" [ 18195.341] (II) Loading /usr/X11R6/lib/modules/input/ws_drv.so [ 18195.342] (II) Module ws: vendor="X.Org Foundation" [ 18195.342]compiled for 1.19.7, module version = 1.3.0 [ 18195.342]Module class: X.Org XInput Driver [ 18195.342]ABI class: X.Org XInput driver, version 24.1 [ 18195.343] (II) Using input driver 'ws' for '/dev/wsmouse' [ 18195.343] (**) /dev/wsmouse: always reports core events [ 18195.343] (II) ws: /dev/wsmouse: debuglevel 0 [ 18195.343] (**) Option "Device" "/dev/wsmouse" [ 18195.343] (**) ws: /dev/wsmouse: ZAxisMapping: buttons 4 and 5 [ 18195.343] (**) ws: /dev/wsmouse: WAxisMapping: buttons 6 and 7 [ 18195.343] (**) ws: /dev/wsmouse: associated screen: 0 [ 18195.372] (II) ws: /dev/wsmouse: minimum x position: 0 [ 18195.372] (II) ws: /dev/wsmouse: maximum x position: 1919 [ 18195.372] (II) ws: /dev/wsmouse: minimum y position: 0 [ 18195.372] (II) ws: /dev/wsmouse: maximum y position: 1079 [ 18195.372] (==) ws: /dev/wsmouse: Buttons: 7 [ 18195.404] (**) ws: /dev/wsmouse: YAxisMapping: buttons 4 and 5 [ 18195.404] (II) XINPUT: Adding extended input device "/dev/wsmouse" (type: MOUSE, id 8) [ 18195.436] (**) /dev/wsmouse: (accel) keeping acceleration scheme 1 [ 18195.436] (**) /dev/wsmouse: (accel) acceleration profile 0 [ 18195.436] (**) /dev/wsmouse: (accel) acceleration factor: 2.000 [ 18195.436] (**) /dev/wsmouse: (accel) acceleration threshold: 4 wsconsctl | grep mouse mouse.type=synaptics mouse.rawmode=0 mouse.scale=1266,5676,1094,4760,0,45,69 mouse.tp.tapping=0 mouse.tp.scaling=0.160 mouse.tp.swapsides=0 mouse.tp.disable=0 mouse.tp.edges=0.0,5.0,10.0,5.0 mouse1.type=ps2 mouse2.type=usb -- Oriol Demaria 2FFED630C16E4FF8
Re: 6.5 PowerPC Packages
That's good to know, thank you for sharing how the process works. My initial question was more of a curiosity than anything else. It's 100% understandable that these things take time, especially on older hardware. The early release of 6.5 was a nice surprise for sure! Thanks again! On Thu, May 9, 2019 at 10:53 AM Christian Weisgerber wrote: > > On 2019-05-09, Henry Bonath wrote: > > > I'm not sure how many folks out there are PowerPC users, but I was > > just curious if anyone had an idea on if or when we might see those > > out in the mirrors. > > The build has been running for 25 days so far, across two machines, > and the packages will be uploaded once they are finished. > > There are two ways to go about this: We can delay the release until > all architectures have finished building, or we can start releasing > once the fast & popular archs are ready and the others will catch > up eventually. > > -- > Christian "naddy" Weisgerber na...@mips.inka.de >
Re: 6.5 PowerPC Packages
On 09/05/2019 16:45, Andrew Luke Nesbit wrote: On 09/05/2019 14:56, Allan Streib wrote: Unless https://www.openbsd.org/plat.html is out of date, it doesn't look like OpenBSD is currently supporting POWER8 or POWER9 plaftorms. I wonder what is the best way to determine interest in getting OpenBSD to work on POWER8/9? My first thought is to ask around in the OpenBSD and OpenPOWER communities. Then to see if there is any natural rapport between them Andrew There was a massive thread on obtaining POWER8 hardware from IBM to support a porting of the OS three years ago. It amounted to IBM's opensource people not seeing it as viable because of lack of demand from their customers. I doubt this will change any time soon I'm afraid. Cheers, Noth
Re: 6.5 PowerPC Packages
Den tors 9 maj 2019 kl 16:49 skrev Andrew Luke Nesbit < em...@andrewnesbit.org>: > > Unless https://www.openbsd.org/plat.html is out of date, it doesn't look > > like OpenBSD is currently supporting POWER8 or POWER9 plaftorms. > > I wonder what is the best way to determine interest in getting OpenBSD > to work on POWER8/9? > Look for amount of diffs published in the direction of getting it to work. If that is zero or very close to zero, then interest is probably at the same level. -- May the most significant bit of your life be positive.
Re: 6.5 PowerPC Packages
On 2019 May 09 (Thu) at 15:45:54 +0100 (+0100), Andrew Luke Nesbit wrote: :On 09/05/2019 14:56, Allan Streib wrote: :> Unless https://www.openbsd.org/plat.html is out of date, it doesn't look :> like OpenBSD is currently supporting POWER8 or POWER9 plaftorms. : :I wonder what is the best way to determine interest in getting OpenBSD :to work on POWER8/9? : In order to support a new architgecture, OpenBSD would need 10 or more physical machines to be distrbuted among the build infrastructure and interested developers. Loans and offers for machines that are hosted offsite don't count, nor do VMs. :My first thought is to ask around in the OpenBSD and OpenPOWER :communities. Then to see if there is any natural rapport between them. : :Andrew :-- :OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 : -- If entropy is increasing, where is it coming from?
Re: 6.5 PowerPC Packages
Christian Weisgerber wrote: > On 2019-05-09, Henry Bonath wrote: > > > I'm not sure how many folks out there are PowerPC users, but I was > > just curious if anyone had an idea on if or when we might see those > > out in the mirrors. > > The build has been running for 25 days so far, across two machines, > and the packages will be uploaded once they are finished. > > There are two ways to go about this: We can delay the release until > all architectures have finished building, or we can start releasing > once the fast & popular archs are ready and the others will catch > up eventually. The real reason is because we're low on current for the flux capacitor, after shifting time for the early 6.5 release. Not all the machines were able to fit into back seat of the Delorian.
Re: 6.5 PowerPC Packages
On 2019-05-09, Henry Bonath wrote: > I'm not sure how many folks out there are PowerPC users, but I was > just curious if anyone had an idea on if or when we might see those > out in the mirrors. The build has been running for 25 days so far, across two machines, and the packages will be uploaded once they are finished. There are two ways to go about this: We can delay the release until all architectures have finished building, or we can start releasing once the fast & popular archs are ready and the others will catch up eventually. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: 6.5 PowerPC Packages
On 09/05/2019 14:56, Allan Streib wrote: > Unless https://www.openbsd.org/plat.html is out of date, it doesn't look > like OpenBSD is currently supporting POWER8 or POWER9 plaftorms. I wonder what is the best way to determine interest in getting OpenBSD to work on POWER8/9? My first thought is to ask around in the OpenBSD and OpenPOWER communities. Then to see if there is any natural rapport between them. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9 signature.asc Description: OpenPGP digital signature
free with zero size on macppc
This is 6.5-current on an old Mac Mini (7447A), full dmesg below. During the boot-up sequence, the kernel says: uhidev0 at uhub3 port 1 configuration 1 interface 0 "Logitech USB Keyboard" rev 1.10/64.00 addr 2 free with zero size: (127) Starting stack trace... db_stack_dump(91e670,e400,200dbb0,e624dbb8,e624db70,5f9c106,0,90) at db_stack_dump+0x88 free(1,3821c0,e624dc20,8de888,e001cc80,5,2,0) at free+0x298 hid_end_parse(e001cc80,8f724c,8de888,e624dc34,e001e800,0,e624dcb0,382178) at hid_end_parse+0x1c uhidev_maxrepid(1388,e624dc94,e624dc80,7,0,ff,0,0) at uhidev_maxrepid+0x84 uhidev_attach(1,7b6918,40a338,e624dd70,e001cc80,8f724c,90,e007b980) at uhidev_attach+0x160 config_attach(e001cc80,2,e0002750,40a338,e624dd70,e001cc80,e624dd60,665f28) at config_attach+0x20c usbd_probe_and_attach(e007b900,5f9c106,1,1,0,46d,c31c,6400) at usbd_probe_and_attach+0x2dc usbd_new_device(18,e0007fa8,e0007fc0,8de888,301,e001cc80,e624de30,7ecec8) at usbd_new_device+0x590 uhub_port_connect(8de888,e0007fc0,e624de70,6a4d8c,7d3a94,10,e624de70,a300) at uhub_port_connect+0x1b4 uhub_explore(1,5f9c106,0,0,8fb6b4,90,e624deb0,0) at uhub_explore+0x258 usb_explore(0,0,0,8fe6c8,0,1,86909,449104) at usb_explore+0x19c usb_task_thread(0,0,e624df30,4490d4,0,0,0,0) at usb_task_thread+0x110 fork_trampoline(0,0,0,0,0,0,0,0) at fork_trampoline+0x10 end trace frame: 0x0, count: 244 End of stack trace. uhidev0: iclass 3/1 free with zero size: (127) Starting stack trace... db_stack_dump(91e670,e400,200dbb0,e624dba8,e624db60,5f9c106,0,90) at db_stack_dump+0x88 free(1,3821c0,e624dc10,8de888,,0,2,0) at free+0x298 hid_end_parse(40,0,0,e624dc24,0,e001e800,e624dcb0,3f0d38) at hid_end_parse+0x1c hid_report_size(2,e000279c,e624dc50,7,0,ff,0,0) at hid_report_size+0xc8 uhidev_attach(1,7b6918,40a338,e624dd70,e001cc80,8f724c,90,e007b980) at uhidev_attach+0x20c config_attach(e001cc80,2,e0002750,40a338,e624dd70,e001cc80,e624dd60,665f28) at config_attach+0x20c usbd_probe_and_attach(e007b900,5f9c106,1,1,0,46d,c31c,6400) at usbd_probe_and_attach+0x2dc usbd_new_device(18,e0007fa8,e0007fc0,8de888,301,e001cc80,e624de30,7ecec8) at usbd_new_device+0x590 uhub_port_connect(8de888,e0007fc0,e624de70,6a4d8c,7d3a94,10,e624de70,a300) at uhub_port_connect+0x1b4 uhub_explore(1,5f9c106,0,0,8fb6b4,90,e624deb0,0) at uhub_explore+0x258 usb_explore(0,0,0,8fe6c8,0,1,86909,449104) at usb_explore+0x19c usb_task_thread(0,0,e624df30,4490d4,0,0,0,0) at usb_task_thread+0x110 fork_trampoline(0,0,0,0,0,0,0,0) at fork_trampoline+0x10 end trace frame: 0x0, count: 244 End of stack trace. free with zero size: (127) Starting stack trace... db_stack_dump(91e670,e400,200da90,e624da98,e624da50,5f9c106,0,90) at db_stack_dump+0x88 free(1,3821c0,e624db00,8de888,8de888,5,2,0) at free+0x298 hid_end_parse(8de888,ff,10006,10006,e624db14,e001e800,e624dba0,3f0ab8) at hid_end_parse+0x1c hid_is_collection(7f,0,e624db30,7,0,ff,0,0) at hid_is_collection+0xc8 ukbd_match(1,3821c0,e624dbd0,e007b980,41,5f9c106,8e8340,8e8340) at ukbd_match+0x50 uhidevsubmatch(40,0,0,e624dc24,0,e001e800,e624dc30,6658a4) at uhidevsubmatch+0x50 mapply(40,0,0,e624dc24,0,e001e800,e624dcb0,3f0d38) at mapply+0x64 config_search(0,0,0,380f10,e007b900,0,e624dcc8,0) at config_search+0x17c config_found_sm(0,5f9c106,40a338,8de888,e007b914,0,e624dd70,1) at config_found_sm+0x30 uhidev_attach(1,7b6918,40a338,e624dd70,e624dd70,e007b900,ff90,e007b980) at uhidev_attach+0x26c config_attach(e001cc80,2,e0002750,40a338,e624dd70,e001cc80,e624dd60,665f28) at config_attach+0x20c usbd_probe_and_attach(e007b900,5f9c106,1,1,0,46d,c31c,6400) at usbd_probe_and_attach+0x2dc usbd_new_device(18,e0007fa8,e0007fc0,8de888,301,e001cc80,e624de30,7ecec8) at usbd_new_device+0x590 uhub_port_connect(8de888,e0007fc0,e624de70,6a4d8c,7d3a94,10,e624de70,a300) at uhub_port_connect+0x1b4 uhub_explore(1,5f9c106,0,0,8fb6b4,90,e624deb0,0) at uhub_explore+0x258 usb_explore(0,0,0,8fe6c8,0,1,86909,449104) at usb_explore+0x19c usb_task_thread(0,0,e624df30,4490d4,0,0,0,0) at usb_task_thread+0x110 fork_trampoline(0,0,0,0,0,0,0,0) at fork_trampoline+0x10 end trace frame: 0x0, count: 239 End of stack trace. free with zero size: (127) Starting stack trace... db_stack_dump(91e670,e400,200da90,e624da98,e624da50,5f9c106,0,90) at db_stack_dump+0x88 free(1,3821c0,e624db00,8de888,8de888,5,2,0) at free+0x298 hid_end_parse(8de888,ff,10006,10001,e624db14,e001e800,e624dba0,3f0ab8) at hid_end_parse+0x1c hid_is_collection(7f,0,e624db30,7,0,ff,0,0) at hid_is_collection+0xc8 ums_match(1,3821c0,e624dbd0,e007b980,41,5f9c106,8e8340,8e8340) at ums_match+0x50 uhidevsubmatch(40,0,0,e624dc24,0,e001e800,e624dc30,6658a4) at uhidevsubmatch+0x50 mapply(40,0,0,e624dc24,0,e001e800,e624dcb0,3f0d38) at mapply+0x64 config_search(0,0,0,380f10,e007b900,0,e624dcc8,0) at config_search+0x17c config_found_sm(0,5f9c106,40a338,8de888,e007b914,0,e624dd70,1) at config_found_sm+0x30
Re: 6.5 PowerPC Packages
I figured that was the case, I suppose I was a little afraid that they weren't coming! On Thu, May 9, 2019 at 9:35 AM Tom Smyth wrote: > > Hi Henry, > > it takes a while to build all the packages on PowerPC ... IIRC > so it will take a while AFAIK > > Thanks > > On Thu, 9 May 2019 at 14:34, Henry Bonath wrote: > > > > I'm not sure how many folks out there are PowerPC users, but I was > > just curious if anyone had an idea on if or when we might see those > > out in the mirrors. > > > > I also suppose in the same vein, I could be learning how to pull the > > ports tree and build what I need that way :-) > > > > Thanks! > > > > > -- > Kindest regards, > Tom Smyth.
Re: 6.5 PowerPC Packages
On Thu, May 9, 2019, at 9:28 AM, Henry Bonath wrote: > I'm not sure how many folks out there are PowerPC users, but I was > just curious if anyone had an idea on if or when we might see those > out in the mirrors. I've got a 2003 lamp-style iMac that runs the macppc port of OpenBSD -CURRENT. It runs fine but could use a RAM upgrade and a new SSD. Pre-built package support for macppc isn't as extensive as on amd64; NetSurf is the best graphical web browser I've found in macppc packages, and I haven't dared try compiling from ports using only 256MB of RAM and the original 60GB HDD -- but at least I've got Emacs. -- Matthew Graybosch https://www.matthewgraybosch.com "Out of order? Even in the future nothing works."
Re: 6.5 PowerPC Packages
On 09/05/2019 14:26, Henry Bonath wrote: > I'm not sure how many folks out there are PowerPC users What exactly do you mean by PowerPC? I am a user of Apple PowerBook G4, POWER8, and POWER9. I am new to OpenBSD and I intend to experiment with it on these architectures. Andrew -- OpenPGP key: EB28 0338 28B7 19DA DAB0 B193 D21D 996E 883B E5B9
Re: 6.5 PowerPC Packages
Hi Henry, it takes a while to build all the packages on PowerPC ... IIRC so it will take a while AFAIK Thanks On Thu, 9 May 2019 at 14:34, Henry Bonath wrote: > > I'm not sure how many folks out there are PowerPC users, but I was > just curious if anyone had an idea on if or when we might see those > out in the mirrors. > > I also suppose in the same vein, I could be learning how to pull the > ports tree and build what I need that way :-) > > Thanks! > -- Kindest regards, Tom Smyth.
6.5 PowerPC Packages
I'm not sure how many folks out there are PowerPC users, but I was just curious if anyone had an idea on if or when we might see those out in the mirrors. I also suppose in the same vein, I could be learning how to pull the ports tree and build what I need that way :-) Thanks!
Re: When will be created a great desktop experience for OpenBSD?
Aren't new users forced to use fvwm already since that's the default? Removing the options won't stop those inclined from finding one they like in packages (unless alt. DEs and WMs are set to be culled from ports as well O_O). However, there is an opportunity for all GUI ports to include a mechanism to add a shortcut to executables in a given WM's menu, that would be made more practicable with a forced default. None of the Xlib window managers are resolution independent from what I can tell. Making fvwm comfortable to use on my 4K screen involved doubling the sizes of fonts, titlebars, borders, icons and the viewport window in .fvwmrc. I didn't bother trying to do the same with all the other fvwm modules and I don't think anyone should be expected to. Until the day comes when all of this, plus the X11 utilities (xterm et. al) can be configured automatically based on the Xserver dpi setting, cwm is the easiest to set up as only the border and font sizes need changing. -- Patrick Harper paia...@fastmail.com
Re: When will be created a great desktop experience for OpenBSD?
@ Steve > One point I didn't see in RFC's post is stability. When I used OpenBSD > back in 2010, subjectively it seemed more stable, more consistent, and > less surprising than any Linux I'd ever used (and of course than any > Windows I'd ever used). If my computer were just for web browsing, > social networking, email, and storing photos and videos, Ubuntu or Mint > would be stable enough. But the way I work, I often have over 50 > windows open. I can't afford the massive instability bestowed by "we do > it all for you" user interfaces. This is also true. In my experience with Gnome, KDE, et. al., these fancy configuration menus and wizards generally wind up being leaky abstractions. Writing a simple format into /etc/hostname.if has in my experience had far fewer caveats than NetworkManager or nm-applet. I had mostly addressed stability in terms of UI/UX design, but in the broader software quality meaning of the word it's a good point. I would be fine with using a fancy tool to configure everything... if it worked and was consistent. So far the only such tool I've found to deliver on that (actually functioning and being consistent) is OpenBSD's /etc/.
Re: Upgrade procedure encrypted filesystem (6.4 -> 6.5)
On 5/9/19 11:56 AM, cho...@jtan.com wrote: > shadrock uhuru writes: >> i've got a couple of follow up queries concerning post upgrade things todo. >> >> --- -dbus-1.12.10p0v0 --- >> Remember to update /etc/machine-id >> how do i update machine_id, i didn't find any man pages to explain ? > Ignore it. Nothing bad will happen. It's a linuxism. > >> --- -libxml-2.9.8p0 --- >> Remember to update /var/db/xmlcatalog >> how do i update /var/db/xmlcatalog, found man xmlcatalog but mentions >> nothing about updating ? > Ignore it. Nothing bad will happen. Nothing done in XML ever mattered. > >> --- -node-8.12.0 --- >> Error deleting directory /usr/local/lib/kde4/plugins: Directory not empty >> /usr/local/lib/kde4/plugins contains: >> >> ls /usr/local/lib/kde4/plugins >> >> accessible imageformats phonon_s_backend >> accessiblebridge kauth script >> designer kscreen styles >> grantlee marble >> gui_platform phonon_platform >> >> should i go ahead and delete everything in the directory manually ? > Remove everything that is to do with KDE and go and quietly contemplate > the life choices which led to you having it installed in the first place. Hi chohag it was a leftover when i first installed my laptop used it for about a week then switch to I3 and never looked back. will pkg_delete kde4 remove it all ? shadrock > Matthew >
Re: Upgrade procedure encrypted filesystem (6.4 -> 6.5)
shadrock uhuru writes: > i've got a couple of follow up queries concerning post upgrade things todo. > > --- -dbus-1.12.10p0v0 --- > Remember to update /etc/machine-id > how do i update machine_id, i didn't find any man pages to explain ? Ignore it. Nothing bad will happen. It's a linuxism. > --- -libxml-2.9.8p0 --- > Remember to update /var/db/xmlcatalog > how do i update /var/db/xmlcatalog, found man xmlcatalog but mentions > nothing about updating ? Ignore it. Nothing bad will happen. Nothing done in XML ever mattered. > --- -node-8.12.0 --- > Error deleting directory /usr/local/lib/kde4/plugins: Directory not empty > /usr/local/lib/kde4/plugins contains: > > ls /usr/local/lib/kde4/plugins > > accessible imageformats phonon_s_backend > accessiblebridge kauth script > designer kscreen styles > grantlee marble > gui_platform phonon_platform > > should i go ahead and delete everything in the directory manually ? Remove everything that is to do with KDE and go and quietly contemplate the life choices which led to you having it installed in the first place. Matthew
Re: Upgrade procedure encrypted filesystem (6.4 -> 6.5)
On 5/7/19 9:16 PM, Omar Polo wrote: > On Tue, May 07, 2019 at 02:04:03AM +0100, shadrock uhuru wrote: >> >> On 5/6/19 8:18 PM, Omar Polo wrote: >>> On Mon, May 06, 2019 at 07:46:53PM +0100, shadrock uhuru wrote: hi everyone when upgrading my laptop which is encrypted with a keydisk i assume that i boot the 6.5 kernel which will be on a usb stick with the keydisk inserted, will the hard drive still be decrypted and upgraded, also will the encryption step need to be redone or will the keydisk continue to unlock the 6.5 filesystem on subsequent reboots. thanks shadrock >>> Just follow the guide[1]: during the upgrade process the installer will >>> ask you what disk contains the installation. Be sure to point it to >>> the right disk. The disk will (of course!) still be encrypted after >>> the upgrade, and you won't need to do anything else. >>> >>> [1]: https://www.openbsd.org/faq/upgrade65.html >> many thanks Omar > I've forgot one thing (hope it's not too late.) Point the installer > to the right *virtual* disk. For example, in my case I have a disk > (attached as sd0) with FDE. When decrypted, a virtual disk sd1 is > attached, so when I upgrade I point the installer to sd1. In any case, > the installer will try to mount the partitions, so you should see an > error if you point it to the wrong disk. > > Also, sorry if I wrote directly to you instead of replying to the ml. > As always, I foget to CC :) either way works for me. Hi Omar and all who helped i got it upgraded, it was way easier than i expected, i've got a couple of follow up queries concerning post upgrade things todo. --- -dbus-1.12.10p0v0 --- Remember to update /etc/machine-id how do i update machine_id, i didn't find any man pages to explain ? --- -libxml-2.9.8p0 --- Remember to update /var/db/xmlcatalog how do i update /var/db/xmlcatalog, found man xmlcatalog but mentions nothing about updating ? --- -node-8.12.0 --- Error deleting directory /usr/local/lib/kde4/plugins: Directory not empty /usr/local/lib/kde4/plugins contains: ls /usr/local/lib/kde4/plugins accessible imageformats phonon_s_backend accessiblebridge kauth script designer kscreen styles grantlee marble gui_platform phonon_platform should i go ahead and delete everything in the directory manually ? shadrock
Re: When will be created a great desktop experience for OpenBSD?
> ... we should choose *ONE* window manager and delete all the others, and
> force people into a > single working model
There is no need to be so cruel. You can release OpenBSD like hosting
plans: free, basic, advanced and pro. You can rename them differently,
like Home, Enterprise, Business, Ultimate. Free will have that *ONE*
wm, then you add something for each level of upgrade. Needless to say
that starting from basic one has to pay :-{.
Still wondering what "great desktop experience" means ...
Re: When will be created a great desktop experience for OpenBSD?
On Wed, 8 May 2019 00:23:09 +0200 ropers wrote: > Tangentially related: Does anyone here routinely use the default fvwm? Yep - daily. Cheers, -- Craig Skinner | http://linkd.in/yGqkv7
Re: When will be created a great desktop experience for OpenBSD?
Steve Litt wrote: > > However I don't think shipping a > > different WM/DE is going to help. > > Back in 2010 or thereabouts, when I used OpenBSD on a laptop > regularly, OpenBSD offered a bunch of WM/DE's in its package manager. > That's a wonderful thing, because different people have different > workflow techniques. I assume OpenBSD still has several different > WM/DE's. > > I don't know whether OpenBSD has KDE or Gnome, and don't really care. I > kicked KDE off all my boxes in 2012 because it's it's a massively > entangled monolith. As far as Gnome, even if it *could* be used in the > absense of systemd, I view Gnome as a gateway drug to the > Freedesktop.org worldview of having every software strongly linked to > every other software, and I want no part of that noise. > > One point I didn't see in RFC's post is stability. When I used OpenBSD > back in 2010, subjectively it seemed more stable, more consistent, and > less surprising than any Linux I'd ever used (and of course than any > Windows I'd ever used). If my computer were just for web browsing, > social networking, email, and storing photos and videos, Ubuntu or Mint > would be stable enough. But the way I work, I often have over 50 > windows open. I can't afford the massive instability bestowed by "we do > it all for you" user interfaces. Very good points being made here. I'm going to match those points -- and similar to everyone else -- misread what is being said, and agree we should choose *ONE* window manager and delete all the others, and force people into a single working model. Look, it is clear that is what everyone wants. I apologize for the group -- we got distracted by the bogus model of "lots of choice is good choice". We'll get started on that community requested goal immediately. And I can assure, we will succeed: over many years we have assembled an accompolished team of code deleters. Internally we'll make a quick decision about which window manager satisfies you all, delete the rest, and prepare for the mission of convincing you all that we are correct and you should all adapt to that choice or run Linux instead. Personally I am a twm fan, but similar to others in this conversation I'll be humble and limit my viewpoint to 80% validity, as long as kde or anything fancy like that doesn't stand a chance I'm open to any point of view. Thank you all for your input.
Re: Is siteXX.tgz working in snapshots?
On Wed, May 08, 2019 at 09:20:30PM -0700, Greg Steuck wrote: > I have a script[1] which I run when "things change" to keep openbsd > syzbot current. Something changed between Apr 2 and now that made my > install procedure no longer execute install.site which I pack into > siteXX.tgz. I checked that siteXX is making it into the iso image that > I use for installation (the very bottom). > > My basic question is: is siteXX working for other people in recent > snapshots (may 8)? > > [1] > https://github.com/google/syzkaller/blob/master/tools/create-openbsd-gce-ci.sh > > Thanks > Greg > > P.S. Complete log from installation attempt with the current snapshot: > % ~/s/syzkaller/tools/create-openbsd-gce-ci.sh > install.site > etc/installurl > etc/rc.conf.local > etc/rc.local > etc/sysctl.conf > 1+0 records in > 1+0 records out > 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.000284258 s, 14.4 MB/s > Executing 'genisoimage -C 16,207120 -M /dev/fd/3 -l -R -graft-points > /6.5/amd64/site65.tgz=site65.tgz /auto_install.conf=auto_install.conf > /disklabel.template=disklabel.template /etc/boot.conf=boot.conf > /etc/random.seed=random.seed | builtin_dd > of=install65-amd64-patched.iso obs=32k seek=12945' > I: -input-charset not specified, using utf-8 (detected in locale settings) > Rock Ridge signatures found > Total translation table size: 0 > Total rockridge attributes bytes: 2521 > Total directory bytes: 8192 > Path table size(bytes): 48 > Max brk space used 0 > 207305 extents written (404 MB) > builtin_dd: 192*2KB out @ average infx1352KBps > install65-amd64-patched.iso: copying volume descriptor(s) > Formatting 'disk.raw', fmt=raw size=10737418240 > spawn qemu-system-x86_64 -nographic -smp 2 -drive > if=virtio,file=disk.raw,format=raw -cdrom install65-amd64-patched.iso > -net nic,model=virtio -net user -boot once=d -m 4000 -enable-kvm > >> OpenBSD/amd64 CDBOOT 3.42 > boot> > booting cd0a:/6.5/amd64/bsd.rd: 3695441+1532928+3893112+0+598016 > [372212+128+451392+300364]=0xa59b08 > entry point at 0x1001000 > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. > Copyright (c) 1995-2019 OpenBSD. All rights reserved. https://www.OpenBSD.org > > OpenBSD 6.5-current (RAMDISK_CD) #14: Wed May 8 19:07:27 MDT 2019 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD > real mem = 4177387520 (3983MB) > avail mem = 4046807040 (3859MB) > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xf68a0 (11 entries) > bios0: vendor SeaBIOS version "1.10.2-1" date 04/01/2014 > bios0: QEMU Standard PC (i440FX + PIIX, 1996) > acpi0 at bios0: rev 0 > acpi0: tables DSDT FACP APIC HPET > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: QEMU Virtual CPU version 2.5+, 2594.27 MHz, 06-06-03 > cpu0: > FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,SSE3,CX16,x2APIC,HV,NXE,LONG,LAHF,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: apic clock running at 1000MHz > cpu at mainbus0: not configured > ioapic0 at mainbus0: apid 0 pa 0xfec0, version 11, 24 pins > acpiprt0 at acpi0: bus 0 (PCI0) > acpicpu at acpi0 not configured > "ACPI0006" at acpi0 not configured > "PNP0A03" at acpi0 not configured > acpicmos0 at acpi0 > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "PNP0A06" at acpi0 not configured > "QEMU0002" at acpi0 not configured > "ACPI0010" at acpi0 not configured > pvbus0 at mainbus0: KVM > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02 > "Intel 82371SB ISA" rev 0x00 at pci0 dev 1 function 0 not configured > pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA, > channel 0 wired to compatibility, channel 1 wired to compatibility > pciide0: channel 0 disabled (no drives) > atapiscsi0 at pciide0 channel 1 drive 0 > scsibus0 at atapiscsi0: 2 targets > cd0 at scsibus0 targ 0 lun 0: ATAPI 5/cdrom > removable > cd0(pciide0:1:0): using PIO mode 4, DMA mode 2 > "Intel 82371AB Power" rev 0x03 at pci0 dev 1 function 3 not configured > vga1 at pci0 dev 2 function 0 "Bochs VGA" rev 0x02 > vga1: aperture needed > wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) > virtio0 at pci0 dev 3 function 0 "Qumranet Virtio Network" rev 0x00 > vio0 at virtio0: address 52:54:00:12:34:56 > virtio0: msix shared > virtio1 at pci0 dev 4 function 0 "Qumranet Virtio Storage" rev 0x00 > vioblk0 at virtio1 > scsibus1 at vioblk0: 2 targets > sd0 at scsibus1 targ 0 lun 0: SCSI3 0/direct fixed > sd0: 10240MB, 512 bytes/sector, 20971520 sectors > virtio1: msix shared > isa0 at mainbus0 > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > com0: console > pckbc0 at isa0 port 0x60/5 irq 1
