Re: webcam fixes and changes in -current

[Claudio Correa]

Thank you very much,
you made a difference in a teacher's life.

Regards

Laurence Tratt  wrote:

> Lots of us have to use webcams more than we used to. There have been
> some recent changes in OpenBSD support for webcams that some might
> find useful. Most of the hard work was done by Marcus Glocker, with
> input from Ingo Feinerer, sc.dying, and myself.
> 
> The first change is that MJPEG in cameras now works reliably. In
> essence, most webcams can deliver uncompressed video at a low frame
> rate or compressed (MJPEG) at a high frame rate. The latter tickled a
> limitation in the USB stack, which led to the picture breaking up --
> and which is now fixed! If you want to know what your camera is
> capable of, my suggestion is to install ffmpeg and then run:
> 
>   $ ffplay -f v4l2 -list_formats all -i /dev/video0
> 
> which will output lots of stuff, but at the end has the important
> bits:
> 
>   [video4linux2,v4l2 @ 0x914fbbb6000] Raw   : yuyv422 :
>   YUYV : 640x480 160x90 160x120 176x144 320x180 320x240
> 352x288 432x240 640x360 800x448 800x600 864x480 960x720 1024x576
> 1280x720 1600x896 1920x1080 2304x1296 2304x1536 [video4linux2,v4l2 @
> 0x914fbbb6000] Compressed:   mjpeg :MJPEG :
> 640x480 160x90 160x120 176x144 320x180 320x240 352x288 432x240
> 640x360 800x448 800x600 864x480 960x720 1024x576 1280x720 1600x896
> 1920x1080
> 
> This shows that my C920s webcam has a maximum MJPEG resolution of
> 1920x1080. The "raw" options (yuyv422) might look tempting as they
> have a max resolution of 2304x1536, but "video -q" shows they can
> only achieve low frame rates:
> 
>   $ video -q
>   video device /dev/video:
> encodings: yuy2
> frame sizes (width x height, in pixels) and rates (in frames per
> second): 160x90: 30, 24, 20, 15, 10, 7, 5
>   160x120: 30, 24, 20, 15, 10, 7, 5
>   176x144: 30, 24, 20, 15, 10, 7, 5
>   320x180: 30, 24, 20, 15, 10, 7, 5
>   320x240: 30, 24, 20, 15, 10, 7, 5
>   352x288: 30, 24, 20, 15, 10, 7, 5
>   432x240: 30, 24, 20, 15, 10, 7, 5
>   640x360: 30, 24, 20, 15, 10, 7, 5
>   640x480: 30, 24, 20, 15, 10, 7, 5
>   800x448: 30, 24, 20, 15, 10, 7, 5
>   800x600: 24, 20, 15, 10, 7, 5
>   864x480: 24, 20, 15, 10, 7, 5
>   960x720: 15, 10, 7, 5
>   1024x576: 15, 10, 7, 5
>   1280x720: 10, 7, 5
>   1600x896: 7, 5
>   1920x1080: 5
>   2304x1296: 2
>   2304x1536: 2
> controls: brightness, contrast, saturation, gain, sharpness,
> white_balance_temperature
> 
> As that suggests, video(1) only easily supports YUY2/YUYV422. The
> easiest way to see higher frame rates I know of is to use ffmpeg.
> Most cameras can sustain 30fps (or sometimes 60fps) at high
> resolutions as can be seen with:
> 
>   $ ffplay -f v4l2 -input_format mjpeg -video_size 1920x1080 -i
> /dev/video0
> 
> If you use video chat in a browser, you should find that it can now
> reliably support higher resolutions without problems.
> 
> video(1) has also been extended to allow altering webcam controls
> from the command-line. In order to do this, nothing else can be using
> the webcam; however, the settings are "sticky" so they effect
> subsequent programs which use the webcam. I can see the current
> settings with:
> 
>   $ video -c
>   brightness=128
>   contrast=128
>   saturation=128
>   gain=0
>   sharpness=128
>   white_balance_temperature=auto
> 
> and I can reset things back to a known state with:
> 
>   $ video -d
> 
> I can change e.g. brightness with:
> 
>   $ video brightness=200
>   brightness: 128 -> 200
> 
> Some, though not all, controls have automatic adjustment. If your
> webcam has the white_balance_temperature control, it probably
> defaults to "auto", meaning that it tries to adjust based on how
> yellow/white it thinks the light is. In my experience, the automatic
> adjustment ends up making everything look like a Smurfs homage (i.e.
> too blue). video(1) allows us to override the automatic setting and
> specify a temperature manually (in Kelvin). During the day I might
> use:
> 
>   $ video white_balance_temperature=5000
>   white_balance_temperature: auto -> 5000
> 
> If you really want, you can use "auto" as a value for such controls
> instead of a numeric value. Note further that if you're used to other
> operating systems webcam support, you might expect there to be two
> white balance temperature controls (one for the manual temperature
> and a separate auto boolean): video(1) unifies them.
> 
> You can specify multiple controls at once e.g.:
> 
>   $ video brightness=50 white_balance_temperature=3000
>   brightness: 128 -> 50
>   white_balance_temperature: auto -> 3000
> 
> Be aware that uvideo doesn't yet support the "camera terminal control
> requests" part of the UVC spec so some controls (e.g. zoom, pan, and
> exposure) cannot be altered. If and when uvideo gains such support,
> the necessary changes to video(1) will be trivial.
> 
> Overall, I think this makes webcams 

Re: Can I boot without GPU ("headless")?

[Greg Thomas]

On Sat, Aug 29, 2020 at 10:48 AM Henry W. Peterson <
henrywillpeter...@outlook.com> wrote:

>
> To Ian Darwin :
>
> But the password has already been entered, that is previous the boot
> prompt.
>
> When I type "set tty com0", would that immediately switch console? I
> thought it established the console for the single user mode while loading
> /bsd (typical white letters on a blue background).
>

Yes, it's been a long while but if you have a monitor and keyboard attached
you will no longer be able to use them.  For getting further info from the
boot  process you'll have to have a serial console attached.


>
> About the "pins"; yes, those are the ones. But I was assuming to use them
> on both ends. Are you suggesting the use of an USB to Serial adapter to
> safely disconnect the USB end of the cable and that it would make it then
> safe to disconnect the other end too?
>

Yes, I believe it's safe to remove them in any order actually.

Greg

Re: Can I boot without GPU ("headless")?

[Ottavio Caruso]

On 28/08/2020 20:27, Henry W. Peterson wrote:



Could I be booting the system had I said yes (without actually using the port, 
again, I would use ssh)?

If so, can I change this after installation?

If not, is there anything I can do to be able to boot without the graphics card?

Thank you.




Not 100% sure if this answers you question, but I boot a qemu instance 
of OpenBSD/amd64 6.6 with serial console enabled:


-daemonize -display none  -nodefaults \
-serial mon:telnet:127.0.0.1:,server,nowait \

and vga driver disabled:

- vga none -nodefaults \

And then I have this in boot.conf

$ cat /etc/boot.conf
stty com0 9600
set tty com0

and ttys:

$ grep tty00 /etc/ttys
tty00   "/usr/libexec/getty std.9600" vt220on secure


I can then access the VM via either telnet (to the virtualized serial 
console) or ssh.



--
Ottavio Caruso

Re: Very slow clock in Debian vmm guest

[Aaron Miller]

Hi Jordan,

Thanks for the link -- I have not tested it yet but I believe it
will solve my issue. I did search the misc list but I did not see
anything in the past year that seemed relevant to my particular
time issue.

--Aaron

On Sat, 2020-08-29 at 01:17 -0700, Jordan Geoghegan wrote:
> If you check the mailing list archives, you will see that this
> issue has 
> been discussed extensively.
> 
> Dave Voutila has written a linux vmm kernel driver to work
> around some 
> of the issues:
> 
> https://github.com/voutilad/virtio_vmmci
> 
> Regards,
> 
> Jordan
> 
> On 2020-08-28 20:48, Aaron Miller wrote:
> > I have a debian testing guest running in vmm(4) on my -current
> > system, and the internal clock is very slow. For example
> > running
> > `sleep 3` takes about 10 seconds of real time to run. This is
> > too
> > much for ntpd to correct, unfortunately.
> > 
> > Anyone know what the problem is and how I might go about
> > fixing
> > it? Thanks!
> > 
> > --Aaron
> > [dmesg snipped]

Re: Can I boot without GPU ("headless")?

[Henry W. Peterson]

To Ian Darwin :

But the password has already been entered, that is previous the boot prompt.

When I type "set tty com0", would that immediately switch console? I thought it 
established the console for the single user mode while loading /bsd (typical 
white letters on a blue background).

About the "pins"; yes, those are the ones. But I was assuming to use them on 
both ends. Are you suggesting the use of an USB to Serial adapter to safely 
disconnect the USB end of the cable and that it would make it then safe to 
disconnect the other end too?

webcam fixes and changes in -current

[Laurence Tratt]

Lots of us have to use webcams more than we used to. There have been some
recent changes in OpenBSD support for webcams that some might find useful.
Most of the hard work was done by Marcus Glocker, with input from Ingo
Feinerer, sc.dying, and myself.

The first change is that MJPEG in cameras now works reliably. In essence,
most webcams can deliver uncompressed video at a low frame rate or
compressed (MJPEG) at a high frame rate. The latter tickled a limitation in
the USB stack, which led to the picture breaking up -- and which is now
fixed! If you want to know what your camera is capable of, my suggestion is
to install ffmpeg and then run:

  $ ffplay -f v4l2 -list_formats all -i /dev/video0

which will output lots of stuff, but at the end has the important bits:

  [video4linux2,v4l2 @ 0x914fbbb6000] Raw   : yuyv422 : 
YUYV : 640x480 160x90 160x120 176x144 320x180 320x240 352x288 432x240 640x360 
800x448 800x600 864x480 960x720 1024x576 1280x720 1600x896 1920x1080 2304x1296 
2304x1536
  [video4linux2,v4l2 @ 0x914fbbb6000] Compressed:   mjpeg :
MJPEG : 640x480 160x90 160x120 176x144 320x180 320x240 352x288 432x240 640x360 
800x448 800x600 864x480 960x720 1024x576 1280x720 1600x896 1920x1080

This shows that my C920s webcam has a maximum MJPEG resolution of 1920x1080.
The "raw" options (yuyv422) might look tempting as they have a max
resolution of 2304x1536, but "video -q" shows they can only achieve low
frame rates:

  $ video -q
  video device /dev/video:
encodings: yuy2
frame sizes (width x height, in pixels) and rates (in frames per second):
160x90: 30, 24, 20, 15, 10, 7, 5
160x120: 30, 24, 20, 15, 10, 7, 5
176x144: 30, 24, 20, 15, 10, 7, 5
320x180: 30, 24, 20, 15, 10, 7, 5
320x240: 30, 24, 20, 15, 10, 7, 5
352x288: 30, 24, 20, 15, 10, 7, 5
432x240: 30, 24, 20, 15, 10, 7, 5
640x360: 30, 24, 20, 15, 10, 7, 5
640x480: 30, 24, 20, 15, 10, 7, 5
800x448: 30, 24, 20, 15, 10, 7, 5
800x600: 24, 20, 15, 10, 7, 5
864x480: 24, 20, 15, 10, 7, 5
960x720: 15, 10, 7, 5
1024x576: 15, 10, 7, 5
1280x720: 10, 7, 5
1600x896: 7, 5
1920x1080: 5
2304x1296: 2
2304x1536: 2
controls: brightness, contrast, saturation, gain, sharpness, 
white_balance_temperature

As that suggests, video(1) only easily supports YUY2/YUYV422. The easiest
way to see higher frame rates I know of is to use ffmpeg. Most cameras can
sustain 30fps (or sometimes 60fps) at high resolutions as can be seen with:

  $ ffplay -f v4l2 -input_format mjpeg -video_size 1920x1080 -i /dev/video0

If you use video chat in a browser, you should find that it can now reliably
support higher resolutions without problems.

video(1) has also been extended to allow altering webcam controls from the
command-line. In order to do this, nothing else can be using the webcam;
however, the settings are "sticky" so they effect subsequent programs which
use the webcam. I can see the current settings with:

  $ video -c
  brightness=128
  contrast=128
  saturation=128
  gain=0
  sharpness=128
  white_balance_temperature=auto

and I can reset things back to a known state with:

  $ video -d

I can change e.g. brightness with:

  $ video brightness=200
  brightness: 128 -> 200

Some, though not all, controls have automatic adjustment. If your webcam has
the white_balance_temperature control, it probably defaults to "auto",
meaning that it tries to adjust based on how yellow/white it thinks the
light is. In my experience, the automatic adjustment ends up making
everything look like a Smurfs homage (i.e. too blue). video(1) allows us to
override the automatic setting and specify a temperature manually (in
Kelvin). During the day I might use:

  $ video white_balance_temperature=5000
  white_balance_temperature: auto -> 5000

If you really want, you can use "auto" as a value for such controls instead
of a numeric value. Note further that if you're used to other operating
systems webcam support, you might expect there to be two white balance
temperature controls (one for the manual temperature and a separate auto
boolean): video(1) unifies them.

You can specify multiple controls at once e.g.:

  $ video brightness=50 white_balance_temperature=3000
  brightness: 128 -> 50
  white_balance_temperature: auto -> 3000

Be aware that uvideo doesn't yet support the "camera terminal control
requests" part of the UVC spec so some controls (e.g. zoom, pan, and
exposure) cannot be altered. If and when uvideo gains such support, the
necessary changes to video(1) will be trivial.

Overall, I think this makes webcams much more usable under OpenBSD, and
thanks again to Marcus, because none of this would have happened without
him!


Laurie

Re: Can I boot without GPU ("headless")?

[Ian Darwin]

On Sat, Aug 29, 2020 at 03:56:29PM +, Henry W. Peterson wrote:

> It is not a problem for me to write commands on the boot prompt after every 
> turning on, that would eliminate the need to modify /etc/boot.conf, right? 
> Althogh I didn't know modifying that file affected the boot prompt itself. 
> Noted.
> 
> I do have another computer, the one I planned to use to connect by ssh, but I 
> do not have COM port cards (only pins on the motherboard) nor the cables.
> 
> It starts to feel pretty clear that I should try the following:
> 
> After correctly typing the decryption password, type:
> set tty com0
> stty com0 9600
> boot -c
> disable vga
> quit
> 
> Would this be enough to boot, to then connect by ssh (without modifying 
> /etc/ttys or having even a COM port card connected to the motherboard's pins)?

It should get you booted. In fact, it would probably work without the boot 
-c/disable vga/quit parts.
Setting the baud rate to 115200 might save a few seconds, too.

But then, if you have FDE, the mount will hang, as there's no way to enter the 
password, without a serial cable. "set tty com0" will tell init to read from 
the serial, not the physical keyboard

When you say "pins", is that a double row of pins sticking up? There are 
somewhat
standard cables you can buy that will plug into that and terminate in a DB9 
male socket.

On the other computer, you can buy a USB-to-serial adapter/cable that will plug 
into the
DB9 socket. This is what I use, for example.

Re: Can I boot without GPU ("headless")?

[Henry W. Peterson]

To Ian Darwin :

Sorry I didn't answer your first message, you sent it directly to Kenneth Gober 
with cc to me and I hadn't read it.

It is not a problem for me to write commands on the boot prompt after every 
turning on, that would eliminate the need to modify /etc/boot.conf, right? 
Althogh I didn't know modifying that file affected the boot prompt itself. 
Noted.

I do have another computer, the one I planned to use to connect by ssh, but I 
do not have COM port cards (only pins on the motherboard) nor the cables.

It starts to feel pretty clear that I should try the following:

After correctly typing the decryption password, type:
set tty com0
stty com0 9600
boot -c
disable vga
quit

Would this be enough to boot, to then connect by ssh (without modifying 
/etc/ttys or having even a COM port card connected to the motherboard's pins)?

Re: Can I boot without GPU ("headless")?

[xpetrl]

The motherboard has pins for a COM serial port, during installation I was asked if I 
wanted "com0" to become the default console. I said no.


A serial port connection for headless system is really useful, you could 
to enter the password for the encrypted disks and see the kernel's log 
from a terminal.

Re: how to figure out reverse package dependency?

[Matthias]

Just tried something more simple. Works fine for me so far.

https://github.com/mpfr/pkg_depts


On 2020-08-23 08:58, Jonathan Gray wrote:

On Sun, Aug 23, 2020 at 08:15:01AM +0200, Matthias wrote:

How do I figure out which packages directly or indirectly depend on a
specific package? Let's assume that only installed packages shall be
considered.

For example, if 'glib2' is the package in question, 'cairo',
'gdk-pixbuf', 'shared-mime-info', 'ImageMagick', etc. should be returned
as all those depend on 'glib2'.

Thank you.


This is really a question for ports@

One way would be to install databases/sqlports then run
'show-reverse-deps devel/glib2'

Re: Can I boot without GPU ("headless")?

[Henry W. Peterson]

To Ottavio Caruso :

It definitely answers the question on how to define com0 as the default console 
after installation (the /etc/ttys part was specially helpful) and confirms the 
need to disable vga generic driver. Thank you.

To Ian Darwin :

I assume that means the software would accept it. But still, as far as I know, 
it is not recommended from an electrical (and electronic?) point of view. A 
physical failure in these computers would not be acceptable, I would rather not 
take the risk.

Thank you both for your answers.

Re: Can I boot without GPU ("headless")?

[Ian Darwin]

On Sat, Aug 29, 2020 at 01:37:35PM +, Henry W. Peterson wrote:
> But then I would need to have every computer's serial port connected
> the whole time, right? As far as I know serial ports are not
> hot-swappable.
 
Nope. I have two APUs and only one is ever connected, since I have
only one USB-to-serial.  I move it back and forth as needed (which
isn't very often).

Re: Can I boot without GPU ("headless")?

[Henry W. Peterson]

To xpetrl :

But then I would need to have every computer's serial port connected the whole 
time, right? As far as I know serial ports are not hot-swappable.


To: Stuart Henderson 

The used graphics card has an Nvidia chipset, GT710, not a Radeon. Since there 
is no specific drivers for this at OpenBSD, it uses the generic vga driver. But 
I get your point.

About dmesg, I read the ddb(4) manual and I understand that typing "boot dump", 
powering off after reboot and turning on with the card reinstalled would make 
the previous dmesg somewhere accesible, but I was trying to avoid this. I will 
not have physical access to the computer until monday and even then I will need 
to take the card from another computer.


To Kenneth Gober :

Isn't "APU" an AMD trademark for their processors with GPU integrated?

If I choose com0 as the default console but don't connect anything to it (not 
even a COM port card to the motherboard's COM pins) would it still fail because 
no console is detected?

Could I choose an ssh console instead? If I remember correctly, ssh consoles 
also have their /dev/tty"something" device.

Thank you all for your answers

Re: Can I boot without GPU ("headless")?

[Kenneth Gober]

On Fri, Aug 28, 2020 at 3:32 PM Henry W. Peterson <
henrywillpeter...@outlook.com> wrote:

> Do I need a graphics card installed all the time?
>
> The motherboard has pins for a COM serial port, during installation I was
> asked if I wanted "com0" to become the default console. I said no.
>

I believe the requirement is that the system always needs a console
device.  The console device does not need to use a graphics card,
however; a serial port is an acceptable console.  I am guessing the problem
you are having is you said no to using a serial console
on com0, then removed the video card so you couldn't have a wscons console
either.  If you had answered yes to setting com0 to
be the default console, things would probably have worked.

There are several i386/amd64 systems that are sold without graphics
hardware, e.g. the PC Engines APU2, and the Soekris
systems while they were still available.  They work fine using com0 as the
console.

-ken

Re: WAF using OpenBSD relayd

[Stuart Henderson]

On 2020-08-28, Kihaguru Gathura  wrote:
> Hi,
>
> The subject to the previous email below read 'solved'. this was by error.
> this has not been solved.
>
> Any assistance is highly appreciated.

I think you will need to talk to your assessors and ask what they're
   
looking for.

Re: Can I boot without GPU ("headless")?

[Stuart Henderson]

On 2020-08-28, Henry W. Peterson  wrote:
> Hello,
>
> I have several Asus A320M-K motherboards with AMD Ryzen 3 1200 (which does 
> not include a GPU) in very simple computers.
>
> I installed OpenBSD on them using a GigaByte GT710 graphics card. After 
> reboot, everything works perfectly.
>
> My idea was to install and configure the systems with the graphics card and 
> then remove it and control them by SSH (I only have one card).
>
> I disabled at the BIOS the "Wait for F1 if Error" option so it continues 
> booting without the GPU. I am pretty sure it does:
>
> I encrypted the disk during installation with bioctl and softraid; if I do 
> nothing, type intentionally a wrong password or simply press enter, the "num 
> lock" led stays on and pressing the power button shut the system down in 
> immediately. If I type the correct password, after 10 seconds the "num lock" 
> led turns off and the power button only works if pressed for 5 seconds.
>
> So I assume the kernel panics because the GPU is missing.

After typing the password, you should be at a boot prompt, so at that
point try typing blind "boot -c", "disable radeondrm", "quit" and see
if that lets it boot. (I am wondering if there is enough hardware to
trigger attaching the drm driver but it then goes on to fail; without
dmesg this is hard to tell).

If that works, to get them booting automatically you can either build a
custom kernel with radeondrm disabled, or modify the on-disk one with
"config -ef /bsd", "disable radeondrm", "quit". Note this would need
repeating after updating the kernel (e.g. for installing syspatches)
so I'd consider it a temporary measure until more information can be
obtained from the system to find a better fix.

(You can also try a different OS version, if you are running 6.7 then try
a -current snapshot or vice-versa, changes in the DRM code may have made this
behave differently.)

> Do I need a graphics card installed all the time?
>
> The motherboard has pins for a COM serial port, during installation I was 
> asked if I wanted "com0" to become the default console. I said no.
>
> Could I be booting the system had I said yes (without actually using the 
> port, again, I would use ssh)?

I suspect it would also fail, but (with a serial port connected to
another machine) would let you see information about the crash which
may help someone fix it.

> If so, can I change this after installation?

This changes two things; /etc/boot.conf is set to add "stty com0 "
and "set tty com0" (these can alternatively be typed at the boot loader 
prompt), and /etc/ttys to enable a getty on the serial console.

If you're able to connect up a serial port (so, whatever is needed to
connect to the port header, plus a null modem cable to another machine)
then just typing the stty/set boot loader commands would be enough to
see any panic messages or see where it hangs, and so provide information
which might be enough to identify the problem.

Re: Microsoft's war on plain text email in open source

[Stuart Longland]

On 27/8/20 2:12 pm, andrew fabbro wrote:
>> “It is a fairly specific workflow that is a challenge for some newer
>> developers to engage with. As an example, my partner submitted a patch
>> to OpenBSD a few weeks ago, and he had to set up an entirely new mail
>> client which didn’t mangle his email message to HTML-ise or do other
>> things to it, so he could even make that one patch. That’s a barrier to
>> entry that’s pretty high for somebody who may want to be a first-time
>> contributor.”"
>>
> If someone struggles to send a plain-text email, what are the odds their
> OpenBSD patch is going to be accepted...

It's not like tools don't exist for doing exactly that built into the
version control system… *cough* `git send-email` *cough*.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Re: Microsoft's war on plain text email in open source

[Stuart Longland]

On 27/8/20 7:27 am, Peter Nicolai Mathias Hansteen wrote:
> Sort of related, I dust off an exchange/outlook rant of mine from a little 
> while back (most of it still applies, unfortunately): 
> https://bsdly.blogspot.com/2011/02/problem-isnt-email-its-microsoft.html 
> 


> The first revelation came when I heard a co-worker praise newer Microsoft 
> Office releases "because 2007 and newer has discussions". I was forced to 
> imagine how life must have been like without threading as we've tended to 
> call it on the USENET and mailing lists since, well, the late 1980s.


I literally laughed out loud at that.  So they've had threading for only
13 years now?  Geez… so it's not just Microsloth's UIs that are "flat".
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Plaintext vs HTML in email [was Re: Microsoft's war on plain text email in open source]

[Stuart Longland]

On 27/8/20 6:17 am, Daniel Ouellet wrote:
> On 8/26/20 3:08 PM, Chris Bennett wrote:
>> On Wed, Aug 26, 2020 at 12:28:00PM -0500, Mike Hammett wrote:
>>> Text-only was great in 1985. 
>>>
>>>
>>
>> And it's still pretty badass in 2020.
>> I really love the way company networks are brought down by a little
>> helpful Javascript in an HTML email.
> 
> I truly HATE HTML emails.
> 
> Anyone that needs HTML emails really have nothing interesting to say as
> it add absolutely NOTHING to the conversation and is useless.
> 
> I would gladly live in 1985 for ever if that mean I don't have to deal
> with the bulky crap of HTML emails.

I think there are use cases where HTML is valid, but it's also overkill.
 Yes, sometimes it is useful to have some limited formatting, tables and
inline images have their benefits.

That's about where it ends.  I'm the only one in my workplace that uses
plain-text email.  I think it more professional to send an email that is
safely viewable everywhere, rather than to send emails that require
unsafe options to be turned on (I don't care if said options are
normally turned on by default).

That said, I've struck numerous companies that seriously need the IT
security clue-by-four to come a-visiting.

https://stuartl.longlandclan.id.au/blog/2020/08/05/html-email-ought-to-be-considered-harmful/

That's my take on the situation… when you consider the amount that has
been "bolted on" to HTML over the past 28 years, then you consider that
many people use a fully-fledged web browser to access their email (via a
web-based client), the security implications of that are scary.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Help fund COVID-19 research:
https://stuartl.longlandclan.id.au/blog/2020/04/20/who-covid19/

Re: Can I boot without GPU ("headless")?

[Henry W. Peterson]

(It seems there was a problem with the quotes in my previous reply)


To Daniel Sullivan :

I assume that does not have amd64 archictecture. Does it use at least i386 
(like Intel Atom)? I'm wondering if that lack of need for graphics is also in 
place for amd64.


To Greg Thomas :

Just to be sure, the CPU itself did not include a GPU either, right? Can you 
tell me what processor you were using?

Also, did you use a graphics card for installation and initial configuration 
before activating the serial console?


To both (and anyone else who'd like to join):

If I choose "com0" as "tty" as the link Greg sent says, would I need to 
actually use it? I have the pins on the motherboard but not even a serial port 
card connected to them. As I said, I was planning to use ssh for the console.

Thank you both again.

De: owner-m...@openbsd.org  en nombre de Henry W. 
Peterson 
Enviado: sábado, 29 de agosto de 2020 11:59
Para: misc@openbsd.org 
Asunto: Re: Can I boot without GPU ("headless")?

Thank you both for your answers

On Sat Aug 29 00:46:51 2020 PM Daniel Sullivan  wrote:

>I log into an Edgerouter 4 all the time using the >COM port, and that thing 
>has no graphics >hardware whatsoever. Should work!

I assume that does not have amd64 archictecture. Does it use at least i386 
(like Intel Atom)? I'm wondering if that lack of need for graphics is also in 
place for amd64.

On Sat Aug 29 01:25:51 2020 PM Greg Thomas  
wrote:

>This is old and things may have changed since then, but for the simple PC
>without a graphics card that I used for a wireless AP running off
>compact flash this is all I did:
>
>https://www.cyberciti.biz/faq/openbsd-connect-serial-console/
>

Just to be sure, the CPU itself did not include a GPU either, right? Can you 
tell me what processor you were using?

Also, did you use a graphics card for installation and initial configuration 
before activating the serial console?

For both (and anyone else who'd like to join), if I choose "com0" as "tty" as 
the link Greg sent says, would I need to actually use it? I have the pins on 
the motherboard but not even a serial port card connected to them. As I said, I 
was planning to use ssh for the console.

Thank you both again.

Re: Can I boot without GPU ("headless")?

[Henry W. Peterson]

Thank you both for your answers

On Sat Aug 29 00:46:51 2020 PM Daniel Sullivan  wrote:

>I log into an Edgerouter 4 all the time using the >COM port, and that thing 
>has no graphics >hardware whatsoever. Should work!

I assume that does not have amd64 archictecture. Does it use at least i386 
(like Intel Atom)? I'm wondering if that lack of need for graphics is also in 
place for amd64.

On Sat Aug 29 01:25:51 2020 PM Greg Thomas  
wrote:

>This is old and things may have changed since then, but for the simple PC
>without a graphics card that I used for a wireless AP running off
>compact flash this is all I did:
>
>https://www.cyberciti.biz/faq/openbsd-connect-serial-console/
>

Just to be sure, the CPU itself did not include a GPU either, right? Can you 
tell me what processor you were using?

Also, did you use a graphics card for installation and initial configuration 
before activating the serial console?

For both (and anyone else who'd like to join), if I choose "com0" as "tty" as 
the link Greg sent says, would I need to actually use it? I have the pins on 
the motherboard but not even a serial port card connected to them. As I said, I 
was planning to use ssh for the console.

Thank you both again.

Re: routing ipv6 over wireguard

[Simon Fryer]

All,

On Fri, 28 Aug 2020 at 19:09, Stuart Henderson  wrote:

> On 2020-08-26, Alarig Le Lay  wrote:
> > Hi,
> >
> > On Tue 25 Aug 2020 15:27:27 GMT, Aisha Tammy wrote:
> >> (peer A)$ tcpdump -inet6 -i vio0 icmp6
> >> 15:23:04.918459 fe80::fc00:2ff:feee:5248 > ff02::1:ff42:6: icmp6:
> >> neighbor sol: who has 2001:19f0:5:5cd5::6942:6
> >>
> >> (a lot of such lines)
> >
> > It seems that you have been provided a *connected* /64, so the router
> > tried to do NDP for your peer, which isn’t possible because the peer
> > isn’t on the same L2.
> >
> > You have ask your provider to *route* you a range. Then, it will be your
> > VM that will manage it.
>
> Or do proxy ndp(8) for the address (like you would do with proxy ARP
> for v4 in the same situation).
>

Cheers.

ndp(8) works a treat!

Simon

-- 

"Well, an engineer is not concerned with the truth; that is left to
philosophers and theologians: the prime concern of an engineer is
the utility of the final product."
Lectures on the Electrical Properties of Materials, L.Solymar, D.Walsh

Re: Very slow clock in Debian vmm guest

[Jordan Geoghegan]

If you check the mailing list archives, you will see that this issue has 
been discussed extensively.


Dave Voutila has written a linux vmm kernel driver to work around some 
of the issues:


https://github.com/voutilad/virtio_vmmci

Regards,

Jordan

On 2020-08-28 20:48, Aaron Miller wrote:

I have a debian testing guest running in vmm(4) on my -current
system, and the internal clock is very slow. For example running
`sleep 3` takes about 10 seconds of real time to run. This is too
much for ntpd to correct, unfortunately.

Anyone know what the problem is and how I might go about fixing
it? Thanks!

--Aaron

OpenBSD 6.7-current (GENERIC.MP) #36: Sat Aug 22 11:27:03 MDT 2020
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENE
RIC.MP
real mem = 16827916288 (16048MB)
avail mem = 16302870528 (15547MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xccbfd000 (65 entries)
bios0: vendor LENOVO version "N14ET37W (1.15 )" date 09/06/2016
bios0: LENOVO 20BSCTO1WW
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC ASF! HPET ECDT APIC MCFG SSDT SSDT
SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA SSDT UEFI
MSDM BATB FPDT UEFI DMAR
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3)
EHC1(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 14318179 Hz
acpiec0 at acpi0
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.30 MHz, 06-3d-
04
cpu0:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,
PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,D
TES64,MWAIT,DS-
CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE
4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAG
E1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI
1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,MD_CLEAR,
IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.16 MHz, 06-3d-
04
cpu1:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,
PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,D
TES64,MWAIT,DS-
CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE
4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAG
E1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI
1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,MD_CLEAR,
IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.17 MHz, 06-3d-
04
cpu2:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,
PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,D
TES64,MWAIT,DS-
CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE
4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAG
E1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI
1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,MD_CLEAR,
IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 798.16 MHz, 06-3d-
04
cpu3:
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,
PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,D
TES64,MWAIT,DS-
CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE
4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAG
E1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI
1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,RDSEED,ADX,SMAP,PT,MD_CLEAR,
IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins
acpimcfg0 at acpi0
acpimcfg0: addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 3 (EXP1)
acpiprt3 at acpi0: bus 4 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpiprt5 at acpi0: bus -1 (EXP6)
acpicpu0 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148
mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148
mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148
mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(200@233 mwait.1@0x40), C2(200@148
mwait.1@0x33), C1(1000@1