6.2 : x : not working as expected

2018-02-18 Thread Mayuresh Kathe
a startx starts up the graphical environment, but only partially
works as expected. i have included the .cwmrc and .xinitrc and
request help.
-- cwmrc --
#fontname "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1"

bind CM-t terminal
bind CM-l lock
bind CM-s ssh
bind CM-r restart
bind CM-q quit

command top "xterm -e top"


-- xinitrc --
#!/bin/sh
userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

if [ -f $sysresources ]; then
xrdb -merge $sysresources
fi

if [ -f $sysmodmap ]; then
xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then
xrdb -merge "$userresources"
fi

if [ -f "$usermodmap" ]; then
xmodmap "$usermodmap"
fi

id1=$HOME/.ssh/identity
id2=$HOME/.ssh/id_dsa
id3=$HOME/.ssh/id_rsa
id4=$HOME/.ssh/id_ecdsa
if [ -x /usr/bin/ssh-agent ] && [ -f $id1 -o -f $id2 -o -f $id3 -o -f $id4 ];
then
eval `ssh-agent -s`
ssh-add < /dev/null
fi

xclock -digital -update 1 -geometry 200x30-1+1 &
xconsole -iconic -geometry 400x60-1-1 &
xterm -geometry 80x24+100+100 &
xsetroot -solid black &
synclient touchpadoff=1 &
cwm || xterm

if [ "$SSH_AGENT_PID" ]; then
ssh-add -D < /dev/null
eval `ssh-agent -s -k`
fi

thanks.



Re: 6.2 : x : not working as expected

2018-02-18 Thread C.
-> 2018-02-18 Sun 09:50, Mayuresh Kathe, :
> a startx starts up the graphical environment, but only partially
> works as expected. i have included the .cwmrc and .xinitrc and
> request help.

What exactly did you expect? What actually happened?

Not much to help you with without knowing what's wrong in the first
place.

> -- cwmrc --
> #fontname "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1"
> 
> bind CM-t terminal
> bind CM-l lock
> bind CM-s ssh
> bind CM-r restart
> bind CM-q quit
> 
> command top "xterm -e top"
> 
> 
> -- xinitrc --
> #!/bin/sh
> userresources=$HOME/.Xresources
> usermodmap=$HOME/.Xmodmap
> sysresources=/etc/X11/xinit/.Xresources
> sysmodmap=/etc/X11/xinit/.Xmodmap
> 
> if [ -f $sysresources ]; then
> xrdb -merge $sysresources
> fi
> 
> if [ -f $sysmodmap ]; then
> xmodmap $sysmodmap
> fi
> 
> if [ -f "$userresources" ]; then
> xrdb -merge "$userresources"
> fi
> 
> if [ -f "$usermodmap" ]; then
> xmodmap "$usermodmap"
> fi
> 
> id1=$HOME/.ssh/identity
> id2=$HOME/.ssh/id_dsa
> id3=$HOME/.ssh/id_rsa
> id4=$HOME/.ssh/id_ecdsa
> if [ -x /usr/bin/ssh-agent ] && [ -f $id1 -o -f $id2 -o -f $id3 -o -f $id4 ];
> then
>   eval `ssh-agent -s`
>   ssh-add < /dev/null
> fi
> 
> xclock -digital -update 1 -geometry 200x30-1+1 &
> xconsole -iconic -geometry 400x60-1-1 &
> xterm -geometry 80x24+100+100 &
> xsetroot -solid black &
> synclient touchpadoff=1 &
> cwm || xterm
> 
> if [ "$SSH_AGENT_PID" ]; then
>   ssh-add -D < /dev/null
>   eval `ssh-agent -s -k`
> fi

You might want to move the "cwm || xterm" line to the bottom of the
file. As far as I know the call to the WM should be the last one in
~/.xinitrc.

Kind regards
Christian
-- 
[ Insert favourite quote here. ]


signature.asc
Description: PGP signature


Re: Bandwidth Queuing on Asymmetrical Connections?

2018-02-18 Thread Daniel Gracia
 As said, shaping figures are to be applied to outbound interfaces. So,
i.e., should you need to limit the inbound/outbound BW of the internal host
w.x.y.z, being your egress iface 'xl0' and your local iface 'em0', you
would limit to 100Mbps traffic going to w.x.y.z through 'em0', and limit to
10Mbps traffic comming from w.x.y.z through 'xl0' (always outgoing flows).

Regards!


Re: 6.2 : x : not working as expected

2018-02-18 Thread Mayuresh Kathe
i expected the "m + c + t" to bring up another terminal, at the basic level.
nothing happens, the keys just don't do anything other than allowing me to
type text into the terminal which is brought up by default per xinitrc

> From christ...@hiberno.net  Sun Feb 18 04:46:28 2018
> From: "C." 
> To: Mayuresh Kathe 
> Cc: misc@openbsd.org
> Subject: Re: 6.2 : x : not working as expected
> X-Virus-Status: Clean
>
>
> --vswgxdlct7jiejdq
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> -> 2018-02-18 Sun 09:50, Mayuresh Kathe, :
> > a startx starts up the graphical environment, but only partially
> > works as expected. i have included the .cwmrc and .xinitrc and
> > request help.
>
> What exactly did you expect? What actually happened?
>
> Not much to help you with without knowing what's wrong in the first
> place.
>
> > -- cwmrc --
> > #fontname "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-=
> 1"
> >=20
> > bind CM-t terminal
> > bind CM-l lock
> > bind CM-s ssh
> > bind CM-r restart
> > bind CM-q quit
> >=20
> > command top "xterm -e top"
> >=20
> >=20
> > -- xinitrc --
> > #!/bin/sh
> > userresources=3D$HOME/.Xresources
> > usermodmap=3D$HOME/.Xmodmap
> > sysresources=3D/etc/X11/xinit/.Xresources
> > sysmodmap=3D/etc/X11/xinit/.Xmodmap
> >=20
> > if [ -f $sysresources ]; then
> > xrdb -merge $sysresources
> > fi
> >=20
> > if [ -f $sysmodmap ]; then
> > xmodmap $sysmodmap
> > fi
> >=20
> > if [ -f "$userresources" ]; then
> > xrdb -merge "$userresources"
> > fi
> >=20
> > if [ -f "$usermodmap" ]; then
> > xmodmap "$usermodmap"
> > fi
> >=20
> > id1=3D$HOME/.ssh/identity
> > id2=3D$HOME/.ssh/id_dsa
> > id3=3D$HOME/.ssh/id_rsa
> > id4=3D$HOME/.ssh/id_ecdsa
> > if [ -x /usr/bin/ssh-agent ] && [ -f $id1 -o -f $id2 -o -f $id3 -o -f $id=
> 4 ];
> > then
> > eval `ssh-agent -s`
> > ssh-add < /dev/null
> > fi
> >=20
> > xclock -digital -update 1 -geometry 200x30-1+1 &
> > xconsole -iconic -geometry 400x60-1-1 &
> > xterm -geometry 80x24+100+100 &
> > xsetroot -solid black &
> > synclient touchpadoff=3D1 &
> > cwm || xterm
> >=20
> > if [ "$SSH_AGENT_PID" ]; then
> > ssh-add -D < /dev/null
> > eval `ssh-agent -s -k`
> > fi
>
> You might want to move the "cwm || xterm" line to the bottom of the
> file. As far as I know the call to the WM should be the last one in
> ~/.xinitrc.
>
> Kind regards
> Christian
> --=20
> [ Insert favourite quote here. ]
>
> --vswgxdlct7jiejdq
> Content-Type: application/pgp-signature; name="signature.asc"
>
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEE0ESRuuQ6Dud1TAfTmhR73W3euusFAlqJS2gACgkQmhR73W3e
> uutW0g/+N/oLaNUcJVcPu2+UcnxGZn8j3v1nrgfTF2wDFeJ2GcXbiU/ifUfDDW25
> FJEkSbSi+UP0yNn6sPwL1SiQklncCM4J77Ju2t6cqMGOjULRdt3RViSxxa5NVuam
> Av7Pv/vdG6IEhBRqiOFIWvoaqcf/q2kaDvf8Xw50uFvQUQgWIqxO8YX/b4V1GHHj
> +7Cpyfx6jOF8gp7eis0cdXEa6P/ChbrZ4ZAEDX8W9U9g0ylh9iwquoC4jGC+EcVB
> THEFSTRlKZqafiVOgRd4fgOVjeE8GNC6KLZo7q5DXLzYddODvr3XsxEl5LCkv3IG
> COiJLY/YSuR0WfDS68QMVif1bLQ5GaYuuMCm0K8zwkk0QMGztqlTPmAPeMD27zwC
> qe+K75My6uM90zjY+7rCJYs1p3P/p7ad1fxhtP5RZ88BguA1mwkc83npqzroqcf1
> mSHtQOWiWGXl8qcqeQ9gtSaXE+7+p6tEG/2Jt4z5zReMmbgAINrnKw4UIqrZlU8Y
> YWK+QO3D7jshua1WyGkR0DydyOWr51jrfqGlvvFu1aeR2CgyrimsICo2IoDeSZFH
> 4TRwjijw22KJwJcTHQ+usjCVVjY/cIX7RmajF1O7y7kQ77mLn55qzpZ74uuUtqoL
> /phXBmjis7aPwrEajHXdA0q4u0jG/ONwAGNcL6eggzoLbqtSF0g=
> =Pvq0
> -END PGP SIGNATURE-
>
> --vswgxdlct7jiejdq--
>



Re: 6.2 : x : not working as expected

2018-02-18 Thread Maksym Sheremet
On Sun, 18 Feb 2018 05:40:49 -0500 (EST)
mayur...@devio.us (Mayuresh Kathe) wrote:

> i expected the "m + c + t" to bring up another terminal, at the basic
> level. nothing happens, the keys just don't do anything other than
> allowing me to type text into the terminal which is brought up by
> default per xinitrc
> 
> > > -- xinitrc --
> > > . . .
> > > cwm || xterm
> > > . . .

So your cwm is not running and you expect it to work?



Re: spamd and IPv6

2018-02-18 Thread Aham Brahmasmi
> Sent: Wednesday, February 14, 2018 at 11:30 AM
> From: "Denis Fondras" 
> To: misc@openbsd.org
> Subject: Re: spamd and IPv6
>
> > does anyone can tell me what the state of spamd and IPv6 is? I would
> > have expected it to work but I can't set for exampe ::1 or [::1] as a
> > listening address (neither alone or together with 127.0.0.1).
> > 
> 
> Unsupported yet. phessler@ has a diff for it.
> 
> 
Hi Denis,

Thank you for the information.

Hi phessler@,

I am interested in the spamd and IPv6 functionality, primarily because
an IPv4 address costs a lot and I wish to run an IPv6-only mail server.

If possible, I would request you to please merge the IPv6 functionality
in the base spamd.

I understand that most volks will consider this to be stupid for someone
like me who is still learning his way around an OS. However, OpenBSD has
been relatively straight forward and hence my IPv6-only (mis?)adventure.

Thanks.

Regards,
ab
-|-|-|-|-|-|-|--



Re: 6.2 : x : not working as expected

2018-02-18 Thread C.
-> 2018-02-18 Sun 11:40, Mayuresh Kathe, :
> i expected the "m + c + t" to bring up another terminal, at the basic level.
> nothing happens, the keys just don't do anything other than allowing me to
> type text into the terminal which is brought up by default per xinitrc

"man 5 cwmrc" tells us that 

> bind CM-t terminal

should be "bind-key CM-t terminal". 

I suspect "cwmrc" is never really started. You want to try a blank
~/.cwmrc and see whether that works (try the default keybindings then)
and go line by line from there.

And do make sure you've read cwmrc(5). 
-- 
[ Insert favourite quote here. ]


signature.asc
Description: PGP signature


Re: NAT for dual-WAN with public and private LAN

2018-02-18 Thread miraculli .
On 17 February 2018 at 23:07, Richard Procter 
wrote:
>
>
> On 18/02/2018, at 8:39 AM, Richard Procter wrote:
>
> > Hi,
> >
> > I've never attempted such a setup so the following are general pointers
> > which may be mistaken.
> >
> > On 18/02/2018, at 3:08 AM, miraculli . wrote:
> > [...]
> > I would attempt a simpler config first. I suspect you're following
> > the advice in https://www.openbsd.org/faq/pf/pools.html - which is
> >
> > pass in on $int_if from $lan_net \
> >route-to { ($ext_if1 $ext_gw1), ($ext_if2 $ext_gw2) } \
> >round-robin
> >
> > Only once this is working attempt to use the egress group as a
short-hand.
> >
> >> # START: here I want to block wifi-guests to have access to office-lan
but
> >> doesn´t seem to work too.
> >> block return out from vlan64:network to vlan32:network
> >> #END
> >
> > I would block this on the input side -- IIRC by the time the packet
> > has reached the output side it has already had its source address
> > rewritten by NAT. e.g.
> >
> > block in on $wifi_if to $office_if:network
> > block in on $office_if to $wifi_if:network # probably also want this
converse
>
> actually a simpler way to achieve this would be to preface the rules with
>
> block
>
> and then explicitly allow the traffic you want to pass, e.g.
>
> pass out inet
> pass in on ${int_if}
>
> (these rules apply only to new flows; e.g. if you make an outbound
> TCP connection, and the rules allow it, pf will then create a state that
> allows traffic in the reverse direction through; there's no need to
> specify this explicitly in the rules, and in fact the rules won't be
> consulted if a matching state already exists for a packet. One way to
> inspect existing states is via # systat state).
>
> >
> >> pass in on egress inet proto icmp icmp-type $icmp_types
> >
> > the icmp_types are probably too restrictive. e.g. TCP relies on
> > ICMP fragmentation-needed messages to implement MTU path discovery
> > over IPv4. OpenBSD implements secure defaults in its own handling
> > of ICMP so far as I know. e.g. it ignores ICMP redirects by default.
> >
> > $ sysctl net.inet.icmp.rediraccept
> > net.inet.icmp.rediraccept=0
> >
> > I myself am comfortable with
> >
> > pass inet proto icmp
> >
> > at the end of my pf.conf. (but I do not consider myself an
> > authority on pf configuration!)
> >
> >
> > good luck!
> >
> > Richard.
> >

Hi Richard,
and misc,

thanks for your advice and motivation to tinker a little bit more!
I think i got it working... at least tcpdump and pftop show something is
going on on both pppoe-links.

Just for the record, here is my new pf.conf which is also simplified and
made it more explicit.
It seems to work with interface-groups like vlan, pppoe.
Maybe I missunderstand what egress is meant for but anyways, I could
achieve the same with pppoe


table  { 0.0.0.0/8 10.0.0.0/8 127.0.0.0/8 169.254.0.0/16 \
   172.16.0.0/12 192.0.0.0/24 192.0.2.0/24 224.0.0.0/3 \
   192.168.0.0/16 198.18.0.0/15 198.51.100.0/24\
   203.0.113.0/24 }
set block-policy drop
#set loginterface egress
set skip on lo0
match in all scrub (no-df random-id max-mss 1440)
match out on pppoe0 from vlan:network nat-to (pppoe0)
match out on pppoe1 from vlan:network nat-to (pppoe1)
block in quick on pppoe from  to any
block return out quick on pppoe from any to 
block all
pass out on vlan to vlan:network
pass in quick on vlan from vlan:network to vlan
pass in on vlan route-to {(pppoe0 pppoe0:network), (pppoe1 pppoe1:network)}
round-robin
pass out on pppoe
block return in on vlan from vlan64:network to vlan32:network
pass in on egress inet proto icmp all
pass in on egress inet proto tcp from any to (egress) port 22


Still one thing to achieve: prefer vlan32 packets over vlan64.

Thanks a lot so far
Thomas


Re: NAT for dual-WAN with public and private LAN

2018-02-18 Thread Thomas Huber
One addional question regarding this topic:

Basically I tried to follow /faq/pf/pools.html.
In the example, there is a addional rule to keep
https-traffic on one single connection, which I understand as
skipping load-balancing for https completely.
The load-balancing itself is done with the 'round-robin' method.

So I ask myself why not
a) use the 'least-states' method to maybe balance more evenly?

b) use with 'sticky-address' to avoid the problems with https-traffic
and make use of both WAN-connections for https-traffic?

Both options ('route-to  least-states sticky-address') seem to
work fine for me but maybe I miss something in the big picture?

Thanks
Thomas


vmd - Unable to reboot Alpine guest

2018-02-18 Thread Aham Brahmasmi
Hi,

I have a simple installation of OpenBSD 6.2 with latest patches
installed on an amd64 machine.

I am unable to reboot an Alpine Linux 3.7.0 guest.

1) I have installed an Alpine Linux guest and it works fine on vmd. The
entry in "vmctl status" properly lists the guest after host boot.

$ vmctl status
   ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
1   11.0G###M   ttyp0 root vmname

2) Now when I run "reboot" within the Alpine guest, one CPU on the
host machine starts hitting 100%. Later the screen displays a blue
background error message.

Tailing the /var/log/messages lists the following error messages:

/bsd: vmx_fault_page: uvm_fault returns 14, GPA=0xa148, rip=0xf7d8a
vmd: vcpu_run_loop: vm 1 / vcpu 0 run ioctl failed: Bad address

At this point, the 100% CPU returns to normal load.

3) A subsequent "vmctl status" does not show the vm.

$ vmctl status
   ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME

Trying to start the vm via a "vmctl start vmname" outputs the following

$ doas vmctl start vmname
vmctl: start vm command failed: Operation already in progress

However, there is no vm listed in the output of "vmctl status".

$ vmctl status
   ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
$ doas rcctl check vmd
vmd(ok)
$ doas vmctl reload
vmctl: command failed

After vmctl reload, the tailed log contains:

vmd: /etc/vm.conf:##: vm "vmname" failed: Operation not permitted

I have run "poweroff" within Alpine as well, but it has a similar result
as above. The vm shuts down, there is no 100% CPU, but it is not visible
within the vmctl status. Trying to start via vmctl results in the same
output on commandline.

$ doas vmctl start vmname
vmctl: start vm command failed: Operation already in progress

The tailed log contains:

vmd: vcpu_run_loop: vm 3 / vcpu 0 run ioctl failed: Input/output error

4) A "doas vmctl stop #" results in one CPU hitting and staying at 100%.

$ doas vmctl stop #
$ top
  PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
  _vmd  280 1027M  102M onproc/0  thrdeat  ##.#H 99.02% vmd
$ vmctl status
   ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
1   11.0G###M   ttyp0 root vmname - stoppin

The only way that works right now is to do a "doas rcctl stop vmd",
"doas rcctl start vmd". However, this results in the entire vmd being
stopped and started.

The relevant section of /etc/vm.conf

vm vmname {
disk location/disk.img
interface tap0 {
locked lladdr 00:00:00:00:00:01
switch "local"
}
memory 1G
owner normaluser
}

switch "local" {
add vether0
interface bridge0
}

I am sorry for the long mail.

Thanks.

Regards,
ab.
-|-|-|-|-|-|-|--



Re: vmd - Unable to reboot Alpine guest

2018-02-18 Thread Carlos Cardenas
On Sun, Feb 18, 2018 at 04:23:39PM +0100, Aham Brahmasmi wrote:
> Hi,
> 
> I have a simple installation of OpenBSD 6.2 with latest patches
> installed on an amd64 machine.
> 
> I am unable to reboot an Alpine Linux 3.7.0 guest.
> 
> 1) I have installed an Alpine Linux guest and it works fine on vmd. The
> entry in "vmctl status" properly lists the guest after host boot.
> 
> $ vmctl status
>ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
> 1   11.0G###M   ttyp0 root vmname
> 
> 2) Now when I run "reboot" within the Alpine guest, one CPU on the
> host machine starts hitting 100%. Later the screen displays a blue
> background error message.
> 
> Tailing the /var/log/messages lists the following error messages:
> 
> /bsd: vmx_fault_page: uvm_fault returns 14, GPA=0xa148, rip=0xf7d8a
> vmd: vcpu_run_loop: vm 1 / vcpu 0 run ioctl failed: Bad address
> 
> At this point, the 100% CPU returns to normal load.
> 
> 3) A subsequent "vmctl status" does not show the vm.
> 
> $ vmctl status
>ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
> 
> Trying to start the vm via a "vmctl start vmname" outputs the following
> 
> $ doas vmctl start vmname
> vmctl: start vm command failed: Operation already in progress
> 
> However, there is no vm listed in the output of "vmctl status".
> 
> $ vmctl status
>ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
> $ doas rcctl check vmd
> vmd(ok)
> $ doas vmctl reload
> vmctl: command failed
> 
> After vmctl reload, the tailed log contains:
> 
> vmd: /etc/vm.conf:##: vm "vmname" failed: Operation not permitted
> 
> I have run "poweroff" within Alpine as well, but it has a similar result
> as above. The vm shuts down, there is no 100% CPU, but it is not visible
> within the vmctl status. Trying to start via vmctl results in the same
> output on commandline.
> 
> $ doas vmctl start vmname
> vmctl: start vm command failed: Operation already in progress
> 
> The tailed log contains:
> 
> vmd: vcpu_run_loop: vm 3 / vcpu 0 run ioctl failed: Input/output error
> 
> 4) A "doas vmctl stop #" results in one CPU hitting and staying at 100%.
> 
> $ doas vmctl stop #
> $ top
>   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
>   _vmd  280 1027M  102M onproc/0  thrdeat  ##.#H 99.02% vmd
> $ vmctl status
>ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
> 1   11.0G###M   ttyp0 root vmname - stoppin
> 
> The only way that works right now is to do a "doas rcctl stop vmd",
> "doas rcctl start vmd". However, this results in the entire vmd being
> stopped and started.
> 
> The relevant section of /etc/vm.conf
> 
> vm vmname {
> disk location/disk.img
> interface tap0 {
> locked lladdr 00:00:00:00:00:01
> switch "local"
> }
> memory 1G
> owner normaluser
> }
> 
> switch "local" {
> add vether0
> interface bridge0
> }
> 
> I am sorry for the long mail.
> 
> Thanks.
> 
> Regards,
> ab.
> -|-|-|-|-|-|-|--
> 

Quite of few bug fixes and enhancements to vmd occurred after 6.2 was released.

Is it possible to run your host with 6.2-current?

+--+
Carlos



Re: unable to boot new 6.2 install

2018-02-18 Thread niya



On 16/02/2018 04:34, Mike Larkin wrote:

On Fri, Feb 16, 2018 at 03:17:28AM +, niya wrote:

hi

i have installed openbsd 6.2 on a lenovo thinkcentre i5 desktop computer,

the installation completes fine afaics.

i reboot, the dmesg report scrolls up then the screen goes blank,

i can't tell if dmesg completes or stops half way through,

after which the machine doesn't respond to keyboard or mouse.

the following dmesg i retrieved dropping to a shell when booting from the
installation usb stick

i have also booted the machine with a live linux mint which works fine.

what could be causing the problem or what else can i do to retrieve any
meaningful diagnostics to forward to the list ?

---


a couple ideas:

1. try amd64. was there a specific reason you wanted to use i386 on this
relatively recent hardware?

2. if the screen goes black during autoconf, try disabling inteldrm to
see if any traces/stack dumps are printed. You can do this from the
boot> prompt by booting "bsd -c" or just "-c" and then "disable inteldrm"
when at the config prompt. "quit" after that to continue the boot.

-ml




thanks mike
i forgot amd64 was for amd and intel processors,
i have it installed now with the lumina desktop

shadrock



Re: vmd - Unable to reboot Alpine guest

2018-02-18 Thread Aham Brahmasmi
> Sent: Sunday, February 18, 2018 at 9:19 PM
> From: "Carlos Cardenas" 
> To: "Aham Brahmasmi" 
> Cc: misc@openbsd.org
> Subject: Re: vmd - Unable to reboot Alpine guest
>
> On Sun, Feb 18, 2018 at 04:23:39PM +0100, Aham Brahmasmi wrote:
> > Hi,
> > 
> > I have a simple installation of OpenBSD 6.2 with latest patches
> > installed on an amd64 machine.
> > 
> > I am unable to reboot an Alpine Linux 3.7.0 guest.
> > 
> > 1) I have installed an Alpine Linux guest and it works fine on vmd. The
> > entry in "vmctl status" properly lists the guest after host boot.
> > 
> > $ vmctl status
> >ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
> > 1   11.0G###M   ttyp0 root vmname
> > 
> > 2) Now when I run "reboot" within the Alpine guest, one CPU on the
> > host machine starts hitting 100%. Later the screen displays a blue
> > background error message.
> > 
> > Tailing the /var/log/messages lists the following error messages:
> > 
> > /bsd: vmx_fault_page: uvm_fault returns 14, GPA=0xa148, rip=0xf7d8a
> > vmd: vcpu_run_loop: vm 1 / vcpu 0 run ioctl failed: Bad address
> > 
> > At this point, the 100% CPU returns to normal load.
> > 
> > 3) A subsequent "vmctl status" does not show the vm.
> > 
> > $ vmctl status
> >ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
> > 
> > Trying to start the vm via a "vmctl start vmname" outputs the following
> > 
> > $ doas vmctl start vmname
> > vmctl: start vm command failed: Operation already in progress
> > 
> > However, there is no vm listed in the output of "vmctl status".
> > 
> > $ vmctl status
> >ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
> > $ doas rcctl check vmd
> > vmd(ok)
> > $ doas vmctl reload
> > vmctl: command failed
> > 
> > After vmctl reload, the tailed log contains:
> > 
> > vmd: /etc/vm.conf:##: vm "vmname" failed: Operation not permitted
> > 
> > I have run "poweroff" within Alpine as well, but it has a similar result
> > as above. The vm shuts down, there is no 100% CPU, but it is not visible
> > within the vmctl status. Trying to start via vmctl results in the same
> > output on commandline.
> > 
> > $ doas vmctl start vmname
> > vmctl: start vm command failed: Operation already in progress
> > 
> > The tailed log contains:
> > 
> > vmd: vcpu_run_loop: vm 3 / vcpu 0 run ioctl failed: Input/output error
> > 
> > 4) A "doas vmctl stop #" results in one CPU hitting and staying at 100%.
> > 
> > $ doas vmctl stop #
> > $ top
> >   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
> >   _vmd  280 1027M  102M onproc/0  thrdeat  ##.#H 99.02% vmd
> > $ vmctl status
> >ID   PID VCPUS  MAXMEM  CURMEM TTYOWNER NAME
> > 1   11.0G###M   ttyp0 root vmname - stoppin
> > 
> > The only way that works right now is to do a "doas rcctl stop vmd",
> > "doas rcctl start vmd". However, this results in the entire vmd being
> > stopped and started.
> > 
> > The relevant section of /etc/vm.conf
> > 
> > vm vmname {
> > disk location/disk.img
> > interface tap0 {
> > locked lladdr 00:00:00:00:00:01
> > switch "local"
> > }
> > memory 1G
> > owner normaluser
> > }
> > 
> > switch "local" {
> > add vether0
> > interface bridge0
> > }
> > 
> > I am sorry for the long mail.
> > 
> > Thanks.
> > 
> > Regards,
> > ab.
> > -|-|-|-|-|-|-|--
> > 
> 
> Quite of few bug fixes and enhancements to vmd occurred after 6.2 was 
> released.
> 
> Is it possible to run your host with 6.2-current?
> 
> +--+
> Carlos
> 
> 

Hi Carlos,

Thank you for your response.

I have been learning and understanding OpenBSD for around one month now.
As such, I had installed -release, and used syspatch to reach -stable.

I have spent some time right now trying to understand the mechanism to
reach -current from -stable.

>From what I understand, I first need to upgrade to the latest snapshot.
>From there, I need to use source build instructions at
https://www.openbsd.org/faq/faq5.html#Bld to reach -current.

I would like to do the above because I am also interested in the spamd
and IPv6 diff that phessler@ has. But right now, I am quite a bit
inexperienced, so you would have to be patient with me.

>From what I understand, to install snapshot I need to download
https://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/bsd.rd, boot that
at the boot prompt and then (U)pgrade from there.

To build from source, I need to follow the instructions at
https://www.openbsd.org/faq/faq5.html#Bld.

# cd /usr
# mkdir -p   xenocara ports
# chgrp wsrc xenocara ports
# chmod 775  xenocara ports

$ user mod -G wsrc normaluser
$ exit

$ cd /usr
$ cvs -qd anon...@anoncvs.ca.openbsd.org:/cvs checkout -P src

# cd /sys/arch/$(machine)/compile/GENERIC.MP
# make obj 
# make config 
# make && make install

# reboot

# cd /usr/src 
# make obj && make build
# sysmerge 
# cd /dev && ./MAKEDEV all

(O

make release-sets - question

2018-02-18 Thread Jiri B
Hello,

I try to understand why 'release-sets' does copy kernel.tgz from DESTDIR
into OS /usr? Could anybody explain the logic behind?

Thank you.

build1$ sed -n '/^release-sets:$/,/^$/p' /usr/src/etc/Makefile  
release-sets:
su ${BUILDUSER} -c 'exec ${MAKE} distribution'
su ${BUILDUSER} -c 'exec ${MAKE} kernels'
cp -p ${DESTDIR}/usr/share/relink/kernel.tgz 
/usr/share/relink/kernel.tgz
${MAKE} bootblocks
cd ${RELEASEDIR} && rm -f SHA256
cd ../distrib/sets && exec su ${BUILDUSER} -c 'exec sh maketars 
${OSrev}'

Jiri



Re: make release-sets - question

2018-02-18 Thread Theo Buehler
On Sun, Feb 18, 2018 at 03:13:35PM -0500, Jiri B wrote:
> Hello,
> 
> I try to understand why 'release-sets' does copy kernel.tgz from DESTDIR
> into OS /usr? Could anybody explain the logic behind?

This ensures that the build machine will have a snapshot kernel on next
reboot. The /usr/libexec/reorder_kernel script will untar this and
link a new /bsd with it.



Re: vmd - Unable to reboot Alpine guest

2018-02-18 Thread Dave Voutila
"Aham Brahmasmi"  writes:

>> On Sun, Feb 18, 2018 at 04:23:39PM +0100, Aham Brahmasmi wrote:
>> > I am unable to reboot an Alpine Linux 3.7.0 guest.

I can confirm that on 6.2-current, you can reboot an Alpine 3.7.0 guest
without errors.

>> > 
>> > Tailing the /var/log/messages lists the following error messages:
>> > 
>> > /bsd: vmx_fault_page: uvm_fault returns 14, GPA=0xa148, rip=0xf7d8a
>> > vmd: vcpu_run_loop: vm 1 / vcpu 0 run ioctl failed: Bad address
>> > 

Here's what I see on 6.2-current when doing a `sudo reboot` inside the
Alpine VM via SSH very shortly after startup (timestamps trimmed for brevity):

kogelvis vmd[26727]: alpine: started vm 1 successfully, tty /dev/ttyp5
kogelvis vmd[93002]: vcpu_process_com_data: guest reading com1 when not ready
kogelvis last message repeated 2 times
kogelvis vmd[93002]: rtc_update_rega: set non-32KHz timebase not supported
kogelvis vmd[93002]: rtc_update_rega: set non-32KHz timebase not supported
kogelvis vmd[26727]: alpine: started vm 1 successfully, tty /dev/ttyp5
kogelvis vmd[49571]: vcpu_process_com_data: guest reading com1 when not ready
kogelvis last message repeated 2 times

> From what I understand, I first need to upgrade to the latest snapshot.
> From there, I need to use source build instructions at
> https://www.openbsd.org/faq/faq5.html#Bld to reach -current.

AFAIK, You shouldn't need to build anything from source, just do the upgrade
from a recent bsd.rd and then make sure to upgrade packages and clean
out old dependencies. Depending on how you've configured certain
software you might need to update some configs by hand, but you
shouldn't have to compile anything other than software you've had to
compile yourself to install under 6.1.

(Aham, sorry if my reply is a bit mangled...for some reason I can't get your
original post to reply to and had to grab your reply to Carlos.)

-Dave



Re: vmd - Unable to reboot Alpine guest

2018-02-18 Thread Mike Larkin
On Sun, Feb 18, 2018 at 05:29:02PM -0500, Dave Voutila wrote:
> "Aham Brahmasmi"  writes:
> 
> >> On Sun, Feb 18, 2018 at 04:23:39PM +0100, Aham Brahmasmi wrote:
> >> > I am unable to reboot an Alpine Linux 3.7.0 guest.
> 
> I can confirm that on 6.2-current, you can reboot an Alpine 3.7.0 guest
> without errors.
> 
> >> > 
> >> > Tailing the /var/log/messages lists the following error messages:
> >> > 
> >> > /bsd: vmx_fault_page: uvm_fault returns 14, GPA=0xa148, rip=0xf7d8a
> >> > vmd: vcpu_run_loop: vm 1 / vcpu 0 run ioctl failed: Bad address
> >> > 
> 
> Here's what I see on 6.2-current when doing a `sudo reboot` inside the
> Alpine VM via SSH very shortly after startup (timestamps trimmed for brevity):
> 
> kogelvis vmd[26727]: alpine: started vm 1 successfully, tty /dev/ttyp5
> kogelvis vmd[93002]: vcpu_process_com_data: guest reading com1 when not ready
> kogelvis last message repeated 2 times
> kogelvis vmd[93002]: rtc_update_rega: set non-32KHz timebase not supported
> kogelvis vmd[93002]: rtc_update_rega: set non-32KHz timebase not supported
> kogelvis vmd[26727]: alpine: started vm 1 successfully, tty /dev/ttyp5
> kogelvis vmd[49571]: vcpu_process_com_data: guest reading com1 when not ready
> kogelvis last message repeated 2 times
> 
> > From what I understand, I first need to upgrade to the latest snapshot.
> > From there, I need to use source build instructions at
> > https://www.openbsd.org/faq/faq5.html#Bld to reach -current.
> 
> AFAIK, You shouldn't need to build anything from source, just do the upgrade
> from a recent bsd.rd and then make sure to upgrade packages and clean
> out old dependencies. Depending on how you've configured certain
> software you might need to update some configs by hand, but you
> shouldn't have to compile anything other than software you've had to
> compile yourself to install under 6.1.
> 
> (Aham, sorry if my reply is a bit mangled...for some reason I can't get your
> original post to reply to and had to grab your reply to Carlos.)
> 
> -Dave
> 

Thanks for confirming Dave.

The messages you posted above are pertty harmless, usual noise when running
Linux guests.

-ml



Re: Will vmm support VFIO/IOMMU?

2018-02-18 Thread Mike Larkin
On Sun, Feb 18, 2018 at 05:33:36AM +0700, Wean Irdeh wrote:
> Hi guys. Will vmm support VFIO/IOMMU like Intel VT-d, AMD Vi, and System
> MMU in the future?

someday