Re: Failing to build a bootable custom kernel

[Valery Ushakov]

On Wed, Apr 10, 2024 at 15:04:51 -0400, Jared Barnak wrote:

> for now. It works (I think), but I don't have any gunzipped images.

Do you mean installation images?  Like

  
http://ftp.netbsd.org/pub/NetBSD/NetBSD-10.0/images/NetBSD-10.0-amd64-live.img.gz

I was under impression you only need a custom kernel, so why waste
time rebuilding everything when you can grab it from CDN/releng? :)

> In "How to get started hacking NetBSD", I was confused
> on where .img.gz file come from and was confused by the
> following command:
> 
> ```
> # Create a disk image.
> mkdir ~/vm
> cd ~/obj/releasedir/evbarm-aarch64/binary/gzimg
> gunzip -c ~/vm/disk.img
> # Make it a sparse 10 GB image.
> cd ~/vm
> dd if=/dev/zero of=disk.img oseek=10g bs=1 count=1
> # Make a symlink to the kernel.
> KERNDIR=~/obj/sys/arch/evbarm/compile/GENERIC64
> ln -sfn $KERNDIR/netbsd.img .
> ```
> 
> But booting into QEMU is proving challenging, the slide provided in the
> video specifies the following
> 
> But the `-c` flag writes to stdout, and I don't understand why that's
> needed. Can't I use the uncompressed kernel created with
> `kernel.gdb=DEBUG_KERNEL`?

The command in that example takes a complete installed system image
from the release dir (if you grab it from cdn/releng it will be in
your downloads dir) and create a disk instance for you VM from it.

> gunzip -c < arm64.img.gz > ~/vm/disk.img

It uses -c b/c you want the original image from the build process
(self-built or downloaded) to be left intact and create an instance
that your VM will use.  The "> ~/vm/disk.img" redirection does just
that.

> # Make it a sparse 10 GB image.
> cd ~/vm
> dd if=/dev/zero of=disk.img oseek=10g bs=1 count=1

But since that image is small, you want to give the system a bit more
space, so you write a single byte at 10GB.  The disk.img nominally
becomes a 10GB file, but the space between the end of the original
uncompressed content and that one byte is not actually allocated on
the disk, hence such file is called "sparse".  The disk blocks for the
contents inside that "hole" will be allocated on demand as you use
that disk image.


> To boot into Qemu, I have
> 
> ```
> #!/urs/bin/sh
> 
> /usr/bin/qemu-system-x86_64 \
> -kernel = ./obj/releasedir/amd64/binary/kernel/netbsd-DEBUG_KERNEL \
[...]
> And this yields the following error"
> 
> ```
> WARNING: Image format was not specified for
> './obj/releasedir/amd64/binary/kernel/netbsd-DEBUG_KERNEL.gz' and
> probing guessed raw.
>  Automatically detecting the format is dangerous for raw
> images, write operations on block 0 will be restricted.
>  Specify the 'raw' format explicitly to remove the restrictions.
> qemu-system-x86_64: root=dk1: drive with bus=0, unit=0 (index=0) exists
> ```

(disclaimer: I never tried to run NetBSD/amd64 under qemu.  I'm kinda
partial to VirtualBox :)

I'm not sure netbsd kenel can be direct-booted by qemu with --kernel.
The live image should be bootable as a normal disk and it comes with
GENERIC already installed.  You will have to boot into the VM and
install the new kernel inside the VM, I gather.  I'm sure there are
people on this list that are more knowledgeable about this than I am.


-uwe

Re: Failing to build a bootable custom kernel

[Valery Ushakov]

On Sun, Apr 07, 2024 at 19:28:24 -0400, Jared Barnak wrote:

> export DESTDIR=/home/jared/Projects/netbsd/obj/destdir
[...]
> ./build.sh -u -O ../obj -U - -E m amd64 -N3 -j24
> install=/home/jared/Projects/netbsd/obj/destdir
> ```
> 
> which then yields the following error
> 
> ```
> [ same error repeated ]
> pax: Unable to copy
> /home/jared/Projects/netbsd/obj/destdir/./usr/share/tmac/mm/se_ms.cov,
> file would overwrite itself

You are asking build.sh to install files from destdir into destdir
which pax duly reports.


> I'm trying to build a custom kernel so that I am able to debug it over real
> and virtualized systems (i.e., use kdb on real hardware and gdb in qemu).

If you only need a custom kernel, why do you ask build.sh to install
everything?

ISTR build.sh has an option to build just the kernel.  kernel.gdb=CONF
according to the usage.  (I usually just do nbconfig plus
nbmake-$machine by hand, b/c that's what build.sh will eventually do
anyway and I personally find it easier and clearer to cut out the
extra scripting layer).


-uwe

Re: using screenblank

[Valery Ushakov]

On Sun, Mar 31, 2024 at 09:42:08 +0900, Henry wrote:

> Two questions concerning /usr/sbin/screenblank:
> 1) How do I get the text console screen to unblank/resume?  The
> defaults, keyboard and mouse activity, don't work.  I've also tried
> "-i /dev/wskbd1" and "-i /dev/wsmouse1" to no avail.  All I've been
> able to do is login over tcp and kill -9 the screenblank process.
> (Thank goodness that works.)
> 2) Once I get 1) solved, what file would be a good place to put the
> screenblank command line so that the screenblanker will start its
> countdown at the login prompt, so I don't have to login to manually
> start screenblank?

For 2) - add to your rc.conf:

  screenblank=YES
  # screenblank_flags="" # and adjust this if needed

For 1) - what is the relevant dmesg output for wscons?  Have you read
the man page?  Do the keyboard/mouse device get their mtime updated?
Etc...

Most of my netbsd machines are headless these days, so I haven't run
screenblank in a while, but I used to use it on different
architectures.


-uwe

Re: NetBSD Localization

[Valery Ushakov]

On Mon, Feb 26, 2024 at 11:06:09 -0500, Ivan "Rambius" Ivanov wrote:

> On Sat, Feb 24, 2024 at 9:20 PM Valery Ushakov  wrote:
> >
> > On Sat, Feb 24, 2024 at 13:42:55 +0100, Martin Neitzel wrote:
> >
> > > > I can use setxkbmap in X to change the input language. If I am in text
> > > > mode and not in X how can I switch the input language?
> > >
> > > See wsconsctl(8), in particular the first example there.
> >
> > I guess the question is not about setting the layout, but switching
> > between say latin and cyrillic within one layout.
> 
> This is exactly what I was looking for - switching from latin
> cyrillic. Is it possible to do that outside of X11?

As I said, it doesn't look like there's a locking version of mode
switch.  Obviously, typing the other alphabet while constantly holding
mode switch is not practical :)

I haven't touched this in ages, so my memory is _very_ hazy (serial
consoles ftw!).  It should be relatively trivial to add to wskbd.c a
locking mode switch (like caps lock for caps) along the current
non-locking (like shift for caps).

I think the next stumbling block will be the adding the keysym mappings.

I never was too motiviated to look at this b/c wscons can only do
8-bit encodings (koi8, 8859-5) and with the shift to unicode they are
not very useful in the console.  Also, have I already mentioned serial
consoles? :)

So while the problem of switching to the other group within the same
layout is simple in isolation, it's the other surrounding issues that
conspire to make it a bit of a drag.

-uwe

Re: makewhatis is missing on netbsd 6.1.4

[Valery Ushakov]

On Sun, Feb 25, 2024 at 05:28:47 +0300, Valery Ushakov wrote:

> On Sat, Feb 24, 2024 at 19:22:54 +, xuser wrote:
> 
> > makewhatis is missing on netbsd 6.1.4 what sould i do?
> 
> makewhatis was replaced by makemandb.  You can build from source with
> MKMAKEMANDB="no" if you need the old makewhatis.

Sorry, I mean MKMAKEMANDB=no - this is a make variable.


-uwe

Re: makewhatis is missing on netbsd 6.1.4

[Valery Ushakov]

On Sat, Feb 24, 2024 at 19:22:54 +, xuser wrote:

> makewhatis is missing on netbsd 6.1.4 what sould i do?

makewhatis was replaced by makemandb.  You can build from source with
MKMAKEMANDB="no" if you need the old makewhatis.

-uwe

Re: NetBSD Localization

[Valery Ushakov]

On Sat, Feb 24, 2024 at 13:42:55 +0100, Martin Neitzel wrote:

> > I can use setxkbmap in X to change the input language. If I am in text
> > mode and not in X how can I switch the input language?
> 
> See wsconsctl(8), in particular the first example there.

I guess the question is not about setting the layout, but switching
between say latin and cyrillic within one layout.  KS_Mode_switch only
shifts to the last two columns while pressed, there seems to be no way
to toggle it (there's only update_modifier(id, type, 0, MOD_MODESHIFT)
call with "toggle" set to false).

-uwe

Re: How to render Groff / troff output directly on the terminal

[Valery Ushakov]

On Mon, Jan 15, 2024 at 23:29:52 +0100, Martin Neitzel wrote:

> IRI> groff -ms -Tps test.ms > test.ps
> IRI> gs test.ps
> IRI>
> IRI> Is there a way to render groff / troff's output directly to the
> IRI> terminal similar to the way man outputs to the terminal?
> 
> Depending on your terminal's locale, format for the ascii, latin1,
> or utf9 backend.  That is, instead of
> 
>   -Tps
> 
> use one of
> 
>   -Tascii
>   -Tlatin1
>   -Tutf8

You can use also just use nroff(1) that will select the appropriate -T
automatically based on your locale settings.

-uwe

grep unusable in UTF-8?

[Valery Ushakov]

On a ppc mini g4 (1.25MHz).

  $ LC_CTYPE=C time grep pool messages > /dev/null
  0.01 real 0.00 user 0.00 sys

but in a UTF-8 locale:

  $ LC_CTYPE=en_US.UTF-8 time grep pool messages > /dev/null
  9.54 real 9.38 user 0.01 sys

though when there are no matches:

  $ LC_CTYPE=en_US.UTF-8 time grep fool messages > /dev/null
  0.05 real 0.03 user 0.01 sys


So a UTF-8 locale seems to make grep unusable for practical purposes. %-O

-uwe

Re: [cross]compiling world and mk.conf

[Valery Ushakov]

On Wed, Nov 08, 2023 at 13:07:09 +0100, Martin Husemann wrote:

> Alternatively you can use conditionals in mk.conf, like:
> 
> .if ${MACHINE} == "sparc"
> CFLAGS+= -mcpu=v8 -mtune=supersparc
> .endif

*tsk tsk*... :)

  CPUFLAGS = -mcpu=v8 -mtune=...

please.


> .if ${MACHINE_ARCH} != shark
> MKKDEBUG=yes
> .endif

*tsk tsk tsk*... :)

And you also got MACHINE and MACHINE_ARCH swapped :)


Yeah, what Martin said modulo corrections.  You can use three levels
from more generic to more specific:

MACHINE_CPU e.g. sh3 or arm
MACHINE_ARCH e.g. sh3el or earmv7hfeb
MACHINE e.g. landisk or shark

You can ask for the list with: ./build.sh list-arch

-uwe

Re: mount -u use fstab options and wapbl log questions

[Valery Ushakov]

On Thu, Aug 10, 2023 at 14:05:57 +, Jeremy C. Reed wrote:

> I saw in mount(8):
> 
> "The set of options is determined by first extracting the options for 
> the file system from the fstab(5) file ..."
> 
> But when I did
> 
> mount -u /
> 
> Then mount didn't show the "log".
> 
> t1:reed$ grep ffs /etc/fstab
> NAME=8ab393d0-4743-11e8-9359-b8ac6fdf499d   /   ffs 
> rw,log   1 1
> 
> So then I did
> 
> mount -u -o log /
> 
> mount then showed:
> 
> /dev/dk0 on / type ffs (log, local)
> 
> Does the mount -u used the fstab options?
> 
> (Sorry I didn't read the code or look at newer versions.)

I'm a bit surprised the man page says that.  I can see:

sbin/mount/mount.c:243
/* ignore the fstab file options.  */
fs->fs_mntops = NULL;

that has been there for decades.  I guess I sort of always
unconsciously assumed that, b/c that seems like the right thing for -u
to do.


-uwe

Re: detecting keyboard events (using wskbd?)

[Valery Ushakov]

On Sun, Aug 06, 2023 at 20:09:10 +, pouya+lists.net...@nohup.io wrote:

> But before I sank even more hours in confused attempts to figure
> out how to actually do this, I thought I'd ask if anyone here could
> perhaps provide some further guidance.

A long time ago I ported qt embedded to run on wscons.  The patches
are still around:

  http://ftp.netbsd.org/pub/NetBSD/misc/uwe/qtemb443-netbsd-20090210.tgz

src/gui/embedded/qkbdwskbd_qws.cpp might be useful, hopefully.

-uwe

Re: cannot disable output processing in pseudo-terminal (between openpty(3) parent and child)

[Valery Ushakov]

On Mon, Jul 31, 2023 at 06:41:13 +, pouya+lists.net...@nohup.io wrote:

> One difference I see with your code is that you don't seem to change
> the controlling terminal in the child with setsid(2) and a TIOCSCTTY
> ioctl(2).

I only need to feed some input to the terminal emulation code, so the
scaffolding is minimal :).  The child programs are usually just cat,
printf, tputs.


> It made no difference.  In both cases running stty(1) with operands
> "raw" or "-opost" are ineffective and OPOST remains set after
> running them.
[...]
> I'm still puzzled as to why I can't disable OPOST programmatically
> or using stty.
> 
> FWIW I have set TERM=dumb in my terminal and that also seems to
> affect input and output processing.

The fact that TERM affects this is a sign that you likely have
something like a shell with line-editing interfering as RVP suggested
in another message.


-uwe

Re: cannot disable output processing in pseudo-terminal (between openpty(3) parent and child)

[Valery Ushakov]

On Sun, Jul 30, 2023 at 23:04:23 +, pouya+lists.net...@nohup.io wrote:

> One of my use cases requires the child process to emit a binary
> stream to be read by the parent.  The parent is notified first via
> a specific escape sequence.  This almost works, except I can't
> figure out how to disable output processing on this stream, and in
> particular the parent receives extra CR characters for every LF
> (NL) the child sends.
> 
> I have tried setting every file descriptor I could think of to raw
> mode (parent stdin, child stdin, both sides of the duplex fd between
> parent and child) via the tcsetattr(3) gymnastics mentioned above,
> to no avail.

FWIW, I have a simple program I've been using to debug kernel vt100
emulator, and:

$ ./wsemul -- printf '\n'
$ hexdump -C wsemul.raw 
  0d 0a |..|
0002
$ ./wsemul -- sh -c 'stty raw; printf "\n";'
$ hexdump -C wsemul.raw 
  0a|.|
0001

where wsemul.raw is the (unfortunately named) dump of everything
received from the slave on the master side.

The program doesn't do anything fancy with the pty.

https://hg.sr.ht/~nbuwe/wsemul/browse/run.c?rev=tip

-uwe

Re: Disable kernel message prefix timestamps?

[Valery Ushakov]

[NB: HTML-only mail probably won't make it to the list]

On Mon, Feb 06, 2023 at 17:01:22 +0500, Vitaly Shevtsov wrote:

> I think it may be not be possible with sysctl, because sysctl is
> read when the kernel is already loaded.  So it can be possible
> through either boot.cfg or recompiling.

It *is* possible, it's just a bit late so you will see the initial
messages with timestamps :) But yes, you're right, some kind of boot
option for this is a good idea too.

-uwe

Re: Disable kernel message prefix timestamps?

[Valery Ushakov]

On Mon, Feb 06, 2023 at 00:49:11 -0500, John Rash wrote:

> Is it possible to disable the linux kernel-style timestamps that
> prefix kernel messages?

I don't think there's a canned, ready to use knob for that.  For now
you can only compile a custom kernel with

  options KLOG_NOTIMESTAMP


Should be ~trivial to add a sysctl to disable the stamps (and to
control timestamp precision, while there), it's just nobody bothered
so far.

-uwe

Re: NetBSD 9.3 amd64 won't turn off display backlight

[Valery Ushakov]

On Thu, Dec 29, 2022 at 21:48:46 +0100, Damien Boureille wrote:

> # wsconsctl -d -w backlight=0
> wsconsctl: WSDISPLAYIO_PARAM_BACKLIGHT: Inappropriate ioctl for device
> 
> # sysctl -a | grep acpi.acpi
> hw.acpi.acpiout1.brightness = 50
> hw.acpi.acpivga0.bios_switch = 1
> 
> This works fine but only dims the display:
> # sysctl -w hw.acpi.acpiout1.brightness=0
> 
> No other relevant variable seems available in sysctl.


Does screenblank(8) work?  You can force the screen off imeediately
with

  screenblank -b

and unblank with

  screenblank -u

Trying it from an ssh session first might be a prudent thing to do, or
be ready to type the second command blindly :)

-uwe

Re: sending/receiving UTF-8 characters from terminal to program

[Valery Ushakov]

On Fri, Jan 20, 2023 at 15:09:44 +0100, r0ller wrote:

> Well, checking what printf results in, I get:
> 
> $printf 'n?z'|hexdump -C
>   6e e9 7a  |n.z|
> 0003
> $printf $'n\uE9z'|hexdump -C
>   6e c3 a9 7a   |n..z|
> 0004
> 
> It's definitely different from what you got for 'n?z'. What does
> that mean?

In the second example you specify \uE9 which is the unicode code point
for e with acute.  It is then uncondionally converted by printf to
UTF-8 (which is two bytes: 0xc3 0xa9) on output.

Your terminal input is in 8859-1 it seems.  0xe9 in the first example
is "LATIN SMALL LETTER E WITH ACUTE" that is unicode code point \u00E9
which is encoded in latin-1 as 0xE9.  So your terminal inserted 0xe9
when you pressed that key.  May be you need to specify -u8 option or
utf8 resource?  (I'm mostly using netbsd headless, so I haven't been
following the current status of utf8 support in X).

-uwe

Re: 'cd' if HOME is unset

[Valery Ushakov]

On Sat, Dec 24, 2022 at 22:32:22 -0500, Jan Schaumann wrote:

> Robert Elz  wrote:
> > Why bother?
> 
> I happily admit that it's a rare edge case. I simply
> find it surprising that 'cd' gives up if HOME is
> unset.  Seems unintuitive to me.

Some would say, "gives up", some would say it makes you aware you have
a problem. :)

DWIM is enticing, sure, but at some point it trasmutes into that
JavaScript "WAT" talk moment.

-uwe

Re: Running a service on a console in the foreground

[Valery Ushakov]

On Sun, Nov 20, 2022 at 15:41:24 +, Benny Siegert wrote:

> Is it possible to have some program running in the foreground on one of the
> VTs on startup, instead of getty? I would like it to start up on boot and
> use the console for input and output. How do you set up such a thing, or is
> this simply not supported?

Use getty autologin ("al") feature in gettytab(5)?

-uwe

Re: updating direct from 5 to 9?

[Valery Ushakov]

On Sat, Aug 20, 2022 at 11:15:34 -0400, Greg Troxel wrote:

> I am helping someone update an i386 system from 5 to 9, which is on
> the net but without console (remote hands possible but really want
> to avoid that).

You can install netbsd 5 under qemu or vbox and to do a test-drive
upgrade to 9 :).  Make a snapshot before doing the upgrade so that you
can re-start easily if something goes wrong.

GENERIC has compat for everything since 0.9, so the new kernel should
be fine for the old 5 userland.

I think the largest upgrade I did was a sparc from 2007 (whatever
version it was) to current from about two years ago.

-uwe

Re: Bug in NetBSD grep ?

[Valery Ushakov]

On Tue, Aug 16, 2022 at 22:40:52 +0200, Marc Baudoin wrote:

> The following command-line:
> 
> echo 00:00: | grep -E '^([0]{2}[:-]){2}$'
> 
> doesn't print anything on NetBSD (9.3) but it prints 00:00: back
> (as it should, unless I made a mistake in my regular expression):
> - on NetBSD with GNU grep from pkgsrc
[...]
> Is there a problem with the grep command shipped with NetBSD?

Hmm, we still have gnu grep as grep, don't we?  Should be obvious from
grep --help.  Or did you build yourself with MKBSDGREP=yes?

Anyway, a quick test on a netbsd-9 VM (a bit older than 9.3) from a
release-9 tree:

  $ echo 00:00: | ./obj/grep -E '^([0]{2}[:-]){2}$'
  00:00:

-uwe

Re: NetBSD 9.2 installer can't detect disk of some Hetzner VPSes

[Valery Ushakov]

On Sun, Jul 10, 2022 at 15:38:05 +, Chavdar Ivanov wrote:

> Without any intention of stealing the topic, talking about vioscsi, I found
> a small curio today - my disks attached to vioscsi are detected only when my
> VirtualBox host is configured to use UEFI (and that is the sole difference).
> In both cases I see the message 'generic HBA error' on vioscsi0 probe, but
> in the BIOS case the disk is not detected at all. In the UEFI case, it
> works, although during the installation one sees an endless sequence of
> 
>vioscsi0: autoconfiguration error: error reserving 35 (nsegs 35)
>sd0(vioscsi0:0:0:0): adapter resource shortage
> 
> messages, but the installation eventually succeeds 

FWIF, on what is to be VBox 7 I have netbsd vm (currentish kernel)
with root on vioscsi.  generic HBA error is our scsipi trying to use
SCSI_MAINTENANCE_IN and SCSI_MODE_SENSE_6.

virtio1 at pci0 dev 15 function 0
virtio1: SCSI device (rev. 0x01)
vioscsi0 at virtio1: features: 0x1
vioscsi0: cmd_per_lun 128 qsize 1024 seg_max 126 max_target 2 max_lun 1
virtio1: interrupting at ioapic0 pin 23
scsibus0 at vioscsi0: 3 targets, 2 luns per target
sd0 at scsibus0 target 0 lun 0:  disk fixed
...
sd0(vioscsi0:0:0:0): generic HBA error
sd0: fabricating a geometry
sd0: 16384 MB, 16384 cyl, 64 head, 32 sec, 512 bytes/sect x 33554432 sectors
...
sd0(vioscsi0:0:0:0): generic HBA error
sd0: fabricating a geometry
sd0: async, 8-bit transfers, tagged queueing
boot device: sd0
root on sd0a dumps on sd0b


> (one still needs fixed ip
> address setup, as dhcpcd is for some reason failing with vioif0, giving me a
> useless APIPA address, using a bridged networking to a WiFi adapter on a
> Windos 10 VirtualBox host).

Does the same problem exist with other network card type?  "Bridged to
wifi" is a bit fragile and doesn't work correctly with some routers
that try to optimize for performance and ignore broadcast flag in the
DHCP request.


-uwe

Re: Setting keyboard layout on xterm

[Valery Ushakov]

On Thu, Jun 30, 2022 at 04:12:37 -0400, Thomas Dickey wrote:

> "xsrc" is a separate tree - see
> 
> http://cvsweb.netbsd.org/bsdweb.cgi/?only_with_tag=MAIN
> 
> however, it's mostly empty, and the Git mirror
> 
> https://github.com/NetBSD/xsrc
> 
> doesn't have much source-code (for some reason, even emptier).
> In particular, there is no xterm source-code.

It most certainly does :).

  https://github.com/NetBSD/xsrc/tree/trunk/external/mit/xterm/dist

It might be a bit weird at the first glance, but it conforms to the
pattern external/$LICENSE/$PROGRAM/dist used in the NetBSD tree:

Compare src/external/gpl3/gcc/dist or external/historical/nawk/dist

-uwe

Re: cannot start detached sessions (with -m -d) back to back

[Valery Ushakov]

On Sat, Jan 01, 2022 at 21:49:00 +, RVP wrote:

> OK, but, I think we can do better than rudely sending processes a SIGHUP.
> Using the BSD-native /dev/ptm device (via openpty(3) & friends) instead of
> /dev/ptmx seems to do the right thing: EOF when the PTY master is closed.
> 
> File a PR (Category: pkg)

Why pkg?  This is a kernel bug.  POSIX doesn't seem to say anything
about this, but Christos pointed out e.g. 

  https://docstore.mik.ua/manuals/hp-ux/en/B2355-60130/pty.7.html

that says

  A read() request made on the slave side of a pty after the master
  side is closed returns 0 bytes. Closing the master side of a pty
  sends a SIGHUP hangup signal to the tty process group number of the
  corresponding slave side and flushes pending input and output.

Solaris docs for (STREAMS-based) ptys say:

  When the master device is closed, an M_HANGUP message is sent to the
  slave device to render the device unusable. The process on the slave
  side gets the errno ENXIO when attempting to write on that stream,
  but it will be able to read any data remaining on the stream head
  read queue. When all the data has been read, read(2) returns 0,
  indicating that the stream can no longer be used.

-uwe

Re: cannot start detached sessions (with -m -d) back to back

[Valery Ushakov]

On Fri, Dec 31, 2021 at 02:08:02 +, RVP wrote:

> On Fri, 31 Dec 2021, Valery Ushakov wrote:
> 
> > I think screen is racing against the child process in MakeWindow.
> 
> I think something else might also be going on:

Ouch.  That probably also explains why I was getting corrupt
ktrace.out files sometimes, there was still that ghost shell that was
being traced.

That most likely is a contributing factor.  If the stuck program is
still holding onto the slave side, the parent screen process gets
select return earlier, I guess.

When the pty that still has the ghost shell attached to the slave side
is reallocated, the ghost shell returns from read with

 16982  16982 sh   RET   read RESTART

reissues read and gets EOF.  So if the new child wins the race, the
new shell gets the pty and the new screen session is started.


> 2. For some reason, on NetBSD, closing the master PTY-fd in screen does not
>cause programs on the slave side to exit (on EOF).

This seems like a bug to me, but I don't know much about tty driver.


> Hope this helps...

Thanks!


-uwe

Re: cannot start detached sessions (with -m -d) back to back

[Valery Ushakov]

On Fri, Dec 31, 2021 at 03:18:08 +0300, Valery Ushakov wrote:

> I think screen is racing against the child process in MakeWindow.

I filed https://savannah.gnu.org/bugs/index.php?61749 for this.

-uwe

Re: cannot start detached sessions (with -m -d) back to back

[Valery Ushakov]

On Thu, Dec 30, 2021 at 06:55:24 +0300, Valery Ushakov wrote:

> Building screeen with debugging shows that succesful session start has
> for the first read from the window:
> 
>  + hit ev fd 5 type 1!
> going to read from window fd 5
>  -> 5 bytes
> 
> but failed attempt has
> 
>  + hit ev fd 5 type 1!
> going to read from window fd 5
> Window 0: EOF - killing window
> 
> where fd 5 is obtained from the cloning pty device /dev/ptmx (ptm(4))
> 
> The comment in ptcread says:
> 
>   /*
>* We want to block until the slave
>* is open, and there's something to read;
>* but if we lost the slave or we're NBIO,
>* then return the appropriate error instead.
>*/
> ...
>   if (!ISSET(tp->t_state, TS_CARR_ON)) {
>   error = 0;   /* EOF */
>   goto out;
>   }

I think screen is racing against the child process in MakeWindow.
>From a quick look it seems that the parent opens the master side and
saves the slave name.  Then it calls ForkWindow and adds the master fd
to the list of descriptors to poll.  Now the race is on, b/c it takes
some time for the child to open the slave side, and if the parent wins
the race, it will get EOF from the master, as the slave is not open
yet.  E.g. a failed attempt:

$ kdump | sed -n -e '/select/p' -e '/EOF/p' \
 -e '/\/dev\/pts/{' -e 'N' -e '/open/p' -e '}'
  4831   4831 screen   CALL  __select50(0x100,0x7f7fff3739f0,0x7f7fff373a10,0,0)
  4831   4831 screen   RET   __select50 1
   "Window 0: EOF (errno 0) - killing window\n"
  5218   5218 screen   NAMI  "/dev/pts/7"
  5218   5218 screen   RET   open 0


vs. a succesful one:


 19165  19165 screen   CALL  __select50(0x100,0x7f7fff30a910,0x7f7fff30a930,0,0)
 26839  26839 screen   NAMI  "/dev/pts/7"
 26839  26839 screen   RET   open 0
 19165  19165 screen   RET   __select50 1
   "serv_select_fn called\n"
 19165  19165 screen   CALL  __select50(0x100,0x7f7fff30a910,0x7f7fff30a930,0,0)
 19165  19165 screen   RET   __select50 1


Using brute force to make screen pre-open the slave in the parent
process should take care of the race

--- pty.c~  2021-12-29 23:50:37.231129335 +0300
+++ pty.c   2021-12-31 03:11:48.652558852 +0300
@@ -288,6 +288,7 @@ char **ttyn;
 }
   initmaster(f);
   *ttyn = TtyName;
+  pty_preopen = 1; /* XXX: uwe */
   return f;
 }
 #endif


This is the HAVE_SVR4_PTYS version of OpenPTY (yes, screen still uses
k function definitions :)

-uwe

Re: cannot start detached sessions (with -m -d) back to back

[Valery Ushakov]

On Wed, Dec 29, 2021 at 13:40:31 -0500, Adam Russell wrote:

> What I am finding is that works to some extent, but then that second session
> seems to quickly end.
> 
> Here I start a session, list all sessions, quit all sessions, sleep for 10
> seconds, start a new session, list all sessions, sleep one second, and then
> list all sessions again.
> 
> As you can see the second sessions, created after the ten second sleep, does
> get created, but is gone a second later.

Building screeen with debugging shows that succesful session start has
for the first read from the window:

 + hit ev fd 5 type 1!
going to read from window fd 5
 -> 5 bytes

but failed attempt has

 + hit ev fd 5 type 1!
going to read from window fd 5
Window 0: EOF - killing window

where fd 5 is obtained from the cloning pty device /dev/ptmx (ptm(4))

The comment in ptcread says:

/*
 * We want to block until the slave
 * is open, and there's something to read;
 * but if we lost the slave or we're NBIO,
 * then return the appropriate error instead.
 */
...
if (!ISSET(tp->t_state, TS_CARR_ON)) {
error = 0;   /* EOF */
goto out;
}

Need to ask someone familiar with the pty internals.

-uwe

Re: cannot start detached sessions (with -m -d) back to back

[Valery Ushakov]

On Wed, Dec 29, 2021 at 00:01:38 -0500, Adam Russell wrote:

> This is what I see
> 
> -bash-5.1$ /usr/pkg/bin/screen -S some-session -p 0 -m -d
> -bash-5.1$ screen -X quit
> -bash-5.1$ /usr/pkg/bin/screen -S some-session -p 0 -m -d
> -bash-5.1$ screen -X quit
>  No screen session found.

I was going to say I can't reproduce it, but then I could.

I couldn't reproduce the problem as is, but I have screenrc that
starts a bunch of windows, so I tested with -c /dev/null and then I do
see the problem.  The second invocation doesn't start the new screen,
just as you show.  But if you wait a little bit (about 5 seconds it
would seem) after the first session is quat, then the new session is
created ok again.

[pardon my bash^Wcsh'isms, but i think it's appropriate here as it
indicates the command is repeated as-is from history and spares the
reader doing the verfication]


$ screen -S test -c /dev/null -d -m -p 0; screen -ls; screen -S test -X quit
There is a screen on:
6098.pts-0.nbvio(Detached)
1 Socket in /tmp/screens/S-uwe.
No screen session found.
$ !!
screen -S test -c /dev/null -d -m -p 0; screen -ls; screen -S test -X quit
There are screens on:
6098.pts-0.nbvio(Detached)
2902.test   (Detached)
2 Sockets in /tmp/screens/S-uwe.
$ !!
screen -S test -c /dev/null -d -m -p 0; screen -ls; screen -S test -X quit
There is a screen on:
6098.pts-0.nbvio(Detached)
1 Socket in /tmp/screens/S-uwe.
No screen session found.
$ !!
screen -S test -c /dev/null -d -m -p 0; screen -ls; screen -S test -X quit
There are screens on:
6098.pts-0.nbvio(Detached)
14114.test  (Detached)
2 Sockets in /tmp/screens/S-uwe.

This is with natural typing pace.


-uwe

Re: man page inquiry

[Valery Ushakov]

Chavdar Ivanov  wrote:

>> > original package might be buggy (autoconf substitutions use @
>> > not #) and needs a fix.
>>
>> You are no doubt quite correct with that suggestion. I will
>> carry it out as simply as I can manage.
>
> I don't think it is pkgsrc's fault - the original wdm.man.in file
> contains the #configdir# string, before 'make patch'. The executable
> uses the /usr/pkg/etc/wdm directory, as uwe@ surmised. A sed command
> to replace #configdir# with ${PKG_SYSCONFDIR} should suffice.

>From a quick look wdm already tries to replace them in its own
makefile by calling config.status, but config.status looks for @var@,
not #var#, so just patch the man page to have @ instead of # and it
should work I guess.

-uwe

Re: man page inquiry

[Valery Ushakov]

Bob Bernstein  wrote:

>> Looks like a pkgsrc bug that failed to properly substitute the 
>> actual value before installing the man page.
> 
> Do you care to take a stab at what that value might be were it 
> to be correctly displayed?

I don't have the slightest idea.  /usr/pkg/etc/wdm probably.  You
should really report this to pkgsrc folks.  I guess the original
package might be buggy (autoconf substitutions use @ not #) and needs
a fix.

-uwe

Re: backspace in wscons console sends ^H to processes

[Valery Ushakov]

On Tue, Jul 20, 2021 at 06:03:55 -, Michael van Elst wrote:

> >But anyway. The big point is that teletypes actually just had a key 
> >labelled "rubout". That key did send a DEL character, though.
> 
> N.B. I haven't actually seen a key labelled "rubout". But the editor manual
> mentioned it a lot (together with "altmode" for what is nowadays known
> as Escape).

On soviet terminals the  was called/labeled  for
"alternative" or "auto register 2" (where "register" is used in the
same sense as in music, i.e. a range of characters, i.e. "altmode 2")
and that name still sometimes makes it to modern keyboards with
russian keycaps (and is completely opaque to anyone who didn't see
keyboards from before the 1990s).

http://www.leningrad.su/museum/show_big.php?n=1539


"altmode 1" was  (0x10, "data link escape", whose usage was
defined by ISO 1745).

-uwe

Re: Some questions about build.sh, machine, -u and tools

[Valery Ushakov]

On Wed, May 05, 2021 at 12:57:21 +0200, Rocky Hotas wrote:

> On mag 03 16:42, Valery Ushakov wrote:
>
> > TL;DR: src/BUILDING explains most of these things.
> 
> It has the header of a Section 8 manpage, but it is not accessible as
> such (`man BUILDING', `man 8 BUILDING' or with lower keys). Is this
> normal?

Yes.  It's just formatted using mdoc, but is not installed as part of
system manual pages.


> > On Mon, May 03, 2021 at 12:18:54 +0200, Rocky Hotas wrote:
> 
> > Roughly speaking MACHINE determines with kernel, bootloader, etc the
> > system uses.  You can have multiple MACHINE_ARCH for the same MACHINE
> > when the machine can have different ABIs (e.g. old arm, earm) or run
> > in different endianness (big, little) or bitness (32, 64).
> 
> Ok! Even if two MACHINEs with different ABIs or endiannes have really
> few common features, maybe just the commercial brand and the
> partitioning scheme.  Sorry, this is extreme of course, but the common
> MACHINE idea still looks weird to me.

I think Martin explained it pretty well in another followup.


> > tooldir* is default TOOLDIR, a place where the cross tools are
> > installed, you can set it with -T option to build.sh.  tools is the
> > objdir for the src/tools, a place where tools are built.  The choice
> > to put tooldir inside objdir by default might be a bit confusing, IMO.
> > Personally, I just use explicit -T.
> 
> Ok! My previous guess was wrong, then. So, IIUC: src/tools are the cross
> tools. The directory tools is just an intermediate step in the building
> of the cross tools. Once they are built, their executables are finally
> placed in the TOOLDIR.

If by the "directory tools" you mean the one in the build directory
(it took me a while to realize that), then yes.  It's called an objdir
and is a standard make(1) feature.  Please check make(1).


> I was confused by the apparently different names that are present in
> tools and in tooldir.NetBSD-9.99.81-amd64. Instead, most of the names
> in tooldir.NetBSD-9.99.81-amd64 are just the names in tools, with `nb'
> prefix. Also, running from tooldir.NetBSD-9.99.81-amd64 a trivial (but
> effective, for a newbie)
> 
> diff nbsed ../../tools/sed/sed
> diff nbcat ../../tools/cat/cat
> 
> shows that the two files match. Correct me if I'm wrong.

Yes, we build our own make, sed, etc as part of the tools build and
install them in $TOOLDIR/bin.  We add nb- prefix to the installed
versions to avoid name clashes with the host programs.  E.g. GNU
programs (can) do the same, using g- prefix (and in some cases that g-
even fused into the name (gcc, gawk)).

-uwe

Re: Some questions about build.sh, machine, -u and tools

[Valery Ushakov]

TL;DR: src/BUILDING explains most of these things.

On Mon, May 03, 2021 at 12:18:54 +0200, Rocky Hotas wrote:

> I struggle instead about MACHINE. Some of them (sparc, vax) have
> just one MACHINE_ARCH with the same name. Some of them have just
> one MACHINE_ARCH with a different name (amd64). This allows to
> specify just one between `-m' or `-a', when building with build.sh.
> Then, there are the cases where a single MACHINE has several
> MACHINE_ARCH. So, what does MACHINE exactly refer to?

Roughly speaking MACHINE determines with kernel, bootloader, etc the
system uses.  You can have multiple MACHINE_ARCH for the same MACHINE
when the machine can have different ABIs (e.g. old arm, earm) or run
in different endianness (big, little) or bitness (32, 64).


> tooldir.NetBSD-9.99.81-amd64
> tools
> 
> `tooldir.NetBSD-9.99.81-amd64' actually contains the cross-compiler
> with its tools that have just been built: they are the actual `tools'
> created by build.sh and they are supposed to run on the host platform.
> 
> What exactly is, instead, the contents of the directory `tools'?
> Are they supposed to run on the build host platform to build the
> cross-compiler and its tools?

tooldir* is default TOOLDIR, a place where the cross tools are
installed, you can set it with -T option to build.sh.  tools is the
objdir for the src/tools, a place where tools are built.  The choice
to put tooldir inside objdir by default might be a bit confusing, IMO.
Personally, I just use explicit -T.


> IIUC, `-u' means that if anything between tools and kernel has already
> been built and its code has not been modified after build 1, now it
> won't be built again. Is this correct?

Yes, -u is an "update" build.  build.sh is not magic, it's just a
wrapper for plain old make.  Roughly speaking, -u tells it to not nuke
the existing objdir and destdir and just run make and let it do the
make thing, figuring out which things are out of date.

If you have a tree you've already built.  You can hack on, say,
src/games/trek and then just run $TOOLDIR/bin/nbmake-vax to compile
your changes, where nbmake-vax is just a script that invokes nbmake
host tool (i.e. good old make, compiled for the host you are on) with
a bunch of variables pointing to the right places to find sources, the
toolchain, etc.

-uwe

Re: 9.1 upgrade fails: Shared object"libc.so.12" not found

[Valery Ushakov]

Bob Bernstein  wrote:

> Shared object "libc.so.12" not found
[...]
> The message shown is what appeared as I finished what appeared 
> to be an uneventful upgrade from an old 'current' netbsd (May 
> of last year) to amd64 9.1.
[...]
> trouble appeared:
> panic init died (signal 0, exit 1)

As people pointed out you updated your system to something that is
newer in terms of time, but older in terms of versioning.

Before the installation you had (using random numbers for the sake of
the example) /lib/libc.so.42.256 from the -current you had installed.
Then you installed the relase that had /lib/libc.so.42.128.  So before
the upgrade you had in your /lib something like:

lrwxr-xr-x  1 root  wheel ... Dec 31  2019 libc.so -> libc.so.42.256
lrwxr-xr-x  1 root  wheel ... Dec 31  2019 libc.so.42 -> libc.so.42.256
-r--r--r--  1 root  wheel ... Dec 31  2019 libc.so.42.256

The libc.so link is for ld(1) to link new programs.

The libc.so.42 link is for for ld.elf_so(1) to run dynmaically linked
programs that have libc.so.42 recorded as NEEDED dependency.


After upnacking the 9.x sets your /lib looked like:

lrwxr-xr-x  1 root  wheel ... Jan  1  2020 libc.so -> libc.so.42.128
lrwxr-xr-x  1 root  wheel ... Jan  1  2020 libc.so.42 -> libc.so.42.128
-r--r--r--  1 root  wheel ... Jan  1  2020 libc.so.42.128   # 9.x
-r--r--r--  1 root  wheel ... Dec 31  2019 libc.so.42.256   # current


Now, postinstall(8) has code to delete unused minor versions.  It
*used* to be naive and only checked for the minor number, so in a
situation like the above (system downgrade) it would see 128 and 256,
conclude the 128 is less than 256 and must be older, and delete it.
So you would end up with

lrwxr-xr-x  1 root  wheel ... Jan  1  2020 libc.so -> libc.so.42.128
lrwxr-xr-x  1 root  wheel ... Jan  1  2020 libc.so.42 -> libc.so.42.128
-r--r--r--  1 root  wheel ... Dec 31  2019 libc.so.42.256

with the symlinks dangling and dynamic binaries (including init) that
depend on libc.so.42 effectively dead.

That's where you would get Shared object "libc.so.12" not found

Christos committed a fix for this in postinstall.in rev 1.5:

revision 1.5
date: 2019-06-15 16:07:09 +0300;  author: christos;  state: Exp;  lines: +33 
-10;  commitid: E0z7TwCLRxb8MhrB;
branches:  1.5.2;
exclude shared libraries that are currently in use from removal.

and seeing that 1.5 is the netbsd-9-base your 9.1 should have that
fix.  Yet it looks like somehow you managed to get yourself in a
situtation like the one described above.  I don't think you posted the
list of files from the hdd's /lib (I've only seen the one done for the
installation media by mistake).  So the first thing you need to
confirm is that you are indeed in the deal symlink situtation like the
above.

I'm not sure how did you manage to end up with the situtation like
this if it's indeed that case.  The postinstall you have from 9.*
should be ok.

To fix this (if that's indeed your problem) you can boot either with
an installation media or from the installed system but with -a and use
static (crunched) /rescue/init when it asks you.  Then you can unpack
base.tgz again to restore the necessary minor versions of the shared
libraries. if you feel adventurous, you can run postinstall fix
obsolete and see what if you can reproduce the problem :)

-uwe

Re: hosts(5) manpage update

[Valery Ushakov]

Henry Bent  wrote:

> I wasn't sure which mailing list to send this to, but I figured this would
> get a fair number of eyes.  The hosts(5) manpage still includes a section
> that dates from 1983(!) and while interesting from an historic perspective
> is probably very confusing to any modern user:
> 
> "This file may be created from the official host data base maintained at
> the Network Information Control Center (NIC), though local changes may be
> required to bring it up to date regarding unofficial aliases and/or
> unknown hosts.  As the data base maintained at NIC is incomplete, use of
> the name server is recommended for sites on the DARPA Internet."
> 
> Perhaps the time has come for its removal.

Heh, thanks for the suggestion :).  Done.

-uwe

Re: Unusable Realtek NIC after upgrading to NetBSD 9

[Valery Ushakov]

Rocky Hotas  wrote:

> Using NetBSD 8.1 in a laptop, both its Ethernet and WiFi NICs worked.
> Then, I made a NetBSD 9 (formal release) fresh install and the
> Ethernet NIC is almost unusable.
> 
> Here, the relevant dmesg part:
> 
> [ 1.055234] re0 at pci3 dev 0 function 0: RealTek
> 8100E/8101E/8102E/8102EL PCIe 10/100BaseTX (rev. 0x05)
> [ 1.055234] re0: interrupting at msix3 vec 0
> [ 1.055234] re0: Ethernet address 28:92:4a:29:53:5a
> [ 1.055234] re0: using 256 tx descriptors
> [ 1.055234] rlphy0 at re0 phy 7: RTL8201E 10/100 media interface,
> rev. 2
> [ 1.055234] rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX,
> auto
> 
> The card is detected and configured by the system, but it is extremely
> slow: a Google ping may take up to 10 seconds (yes, 1 ms). An ssh
> connection is extremely slow, making it unusable.
> 
> It seems that, if I use the card, the dmesg gets populated by this
> repeated message:
> 
> [ 20690.751223] re0: watchdog timeout
> [ 20695.773292] re0: watchdog timeout
> [ 20706.809817] re0: watchdog timeout
> [ 20720.853570] re0: watchdog timeout
> [ 20730.887686] re0: watchdog timeout
> 
> I also tried to boot disabling rlphy(4) (`userconf disable rlphy' from
> the boot prompt), and ukphy(4) is used instead, but nothing changed.
> The same happens with netbsd-9 (stable).
> This problem did not appear with NetBSD 8.1, so it is a regression.
> Is there anything I can do?

Data point.  I had something that looked similar enough to this with
my USL-5p (landisk)

re0 at pci0 dev 0 function 0: RealTek 8139C+ 10/100BaseTX (rev. 0x20)
re0: interrupting at irq 5
re0: Ethernet address 00:a0:b0:65:15:6c
re0: using 64 tx descriptors
rlphy0 at re0 phy 0: Realtek internal PHY
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

It was mostly sitting idle then one day it popped this watchdog
timeout and lost its network iirc.

Next time I powered it on it failed to boot b/c it runs with nfs root
and it had that watchdog timeout right from the start.  As far as I
can tell the relevant kernel versions were 8.99.12 and 8.99.36

I recently booted current on that machine (moved to a different
network) and it did work.

So, I'd try with booting a current'ish kernel on your machine.  Enough
compat is enabled by default in GENERIC, so you can just drop in
current as netbsd.new and boot it one off manually with the existing
9.0 install.

-uwe

Re: Man page names

[Valery Ushakov]

Todd Gruhn  wrote:

> I have noticed that there are many man pages with the name/form
> *.conf.5
> 
> Are  all man pages with the form *.* and *.*.* in section 5?

ld.so(1), mdoc.sampes(7), rpc.statd(8), etc...

> Can anyone see future problems  caused by linking
> a.b.c --> a_b_c  ?

Why?


-uwe

Re: library cleanup after a system upgrade

[Valery Ushakov]

Martin Husemann  wrote:


>  2) the major version was bumped
> -> new version is installed, old version stays around as 3rd party
>software in your installation could still refer to it.
>There are scripts for finding all references and actually
>obsolete libs, but this is typically a later (and partly
>manual) step after you have updated all pkgs too.

Re manual step...  From /usr/sbin/postinstall - this comment speaks
about an embedded awk script that does this work:

#   The implementation supports removing obsolete major libraries
#   if the awk variable AllLibs is set, although there is no way to
#   enable that in the enclosing shell function as this time.

We should probably use an environment variable to supply that
assignment on the awk invocation (-v AllLibs=1) so that you don't have
to copy and edit it.

POSTINSTALL_OBSOLETE_MAJOR_VERIONS_YES_I_KNOW_WHAT_I_AM_DOING or
something.

-uwe

Re: graphical desktop in virtualbox

[Valery Ushakov]

On Mon, Apr 06, 2020 at 10:48:45 +0100, Chavdar Ivanov wrote:

> 6. Apply the following small patch (perhaps an oversight by whoever
> has commited the corresponding file at VirtualBox, it works for me):
>
> # cat sleepqueue-r0drv-netbsd.patch

That's fallout from a *very* recent change in current
sys/sys/syncobj.h

revision 1.13
date: 2020-03-27 00:15:14 +0300;  author: ad;  state: Exp;  lines: +1 -2;  
commitid: re5SGpuLrcZHjX1C;
SOBJ_SLEEPQ_FIFO is gone

-uwe

Re: ECONNRESET not returned when calling send() on a socket

[Valery Ushakov]

On Mon, Dec 23, 2019 at 11:22:41 +, Sad Clouds wrote:

> I handle SIGPIPE now, but don't see the value of having both SIGPIPE
> and ECONNRESET for a socket. The behaviour is rather inconsistent,
> i.e. you call send() and sometimes you get a SIGPIPE signal and
> sometimes you don't. Maybe it's just a Linux issue and NetBSD always
> sends SIGPIPE.

Why do you keep inflicting this on yourself?  Just disable SIGPIPE
delivery for your sockets.  That's the way it's meant to be used.  

-uwe

Re: ECONNRESET not returned when calling send() on a socket

[Valery Ushakov]

On Sun, Dec 22, 2019 at 21:20:41 +, Sad Clouds wrote:

> On Sun, 22 Dec 2019 23:44:33 +0300
> Valery Ushakov  wrote:
> 
> > LOL.  Sorry :) I mean, you are already using poll(2).  It literally
> > cannot get *any* worse.  Literally.  The margins of this email are
> > just too narrow...  Sorry again, traumatic memories...
> > 
> > E.g. NetBSD and Solaris never report POLLHUP for sockets.  Windows and
> > OSX report POLLHUP when remote half-closes.  Linux reports it on full
> > close.  NetBSD and Solaris don't report POLLERR on failed connect(2),
> > just POLLOUT.  And I don't even want to think about scenarios like
> > reset after half-close...
> 
> Well, I don't have problems with poll(). For a small number of file
> descriptors it works quite well. Yes it does get expensive when you
> start using 1000s of file descriptors, but then you just use epoll(),
> kqueue(), etc.

This is not what I mean.

-uwe

Re: ECONNRESET not returned when calling send() on a socket

[Valery Ushakov]

On Sun, Dec 22, 2019 at 16:47:11 +, Sad Clouds wrote:

> On Sun, 22 Dec 2019 16:10:15 +0300
> Valery Ushakov  wrote:
> 
> > Of course since you are writing a networking server you DO want to be
> > notifed about send() errors and SIGPIPE gets in the way.  So you can
> > tell the kernel, "hey, I know what I'm doing, I will handle this
> > myself".  I don't remember off hand which OS has which of these flags,
> > but there're
> > 
> >   SOCK_NOSIGPIPE - can be or-ed into the type argument of socket(2)
> >   SO_NOSIGPIPE   - SOL_SOCKET level socket option
> >   MSG_NOSIGNAL   - send(2) flag
> > 
> 
> This is the problem, I'm trying to deal with various idiosyncrasies
> of sockets APIs. In order for the code to be portable and behave
> correctly across various platforms, you need to be aware of such
> issues, but it's not always obvious from the man pages.

LOL.  Sorry :) I mean, you are already using poll(2).  It literally
cannot get *any* worse.  Literally.  The margins of this email are
just too narrow...  Sorry again, traumatic memories...

E.g. NetBSD and Solaris never report POLLHUP for sockets.  Windows and
OSX report POLLHUP when remote half-closes.  Linux reports it on full
close.  NetBSD and Solaris don't report POLLERR on failed connect(2),
just POLLOUT.  And I don't even want to think about scenarios like
reset after half-close...


> What I don't understand is when the other end of TCP connection sends
> RST, performing a send() on a socket sometimes results in ECONNRESET
> and sometimes in SIGPIPE. Why?

On NetBSD you always get SIGPIPE (whn not turned off), right?


> The whole idea of SIGPIPE for sockets seems like huge mistake and
> just adds to confusion and potential to introducing bugs which
> terminate your process when this signal is not handled.  But, this
> is ancient history and that is how Unix was designed.

As I said, this is exactly how the unix pipes are supposed to work.
If the reader goes away, the writer gets SIGPIPE.  Not doing that for
sockets would be a huge mistake b/c a program should not care if its
stdout is secretly a socket.

If you want to handle this in your program you turn that default
behavior off with one of the *_NOSIG* flags.  Yes, it's #ifdef'y, but
not that bad.  If SOCK_NOSIGPIPE is defined, use it when you create
the socket.  Otherwise if SO_NOSIGPIPE is defined, set it after socket
is created.  If neither is defined use MSG_NOSIGNAL - probably you can
just always use it if it's defined for good measure and to simplify
the #ifdefs


-uwe

Re: About using NetBSD as a guest, why, how etc.

[Valery Ushakov]

On Tue, Dec 10, 2019 at 18:39:00 +1100, Malcolm Herbert wrote:

> My only gripe with VirtualBox is that it doesn't have native client
> tools support for the *BSD family and the vboxfs filesystem isn't
> available 

This is the semi-periodic reminder that Virtual Box Guest Additions do
support NetBSD, the code has been in the public VirtualBox repository
for more than 3 years (but vboxfs support *is* indeed missing).

GA have not been packaged though.  The main obstacle is that kernel
modules need access to some non-public kernel headers to be built.

-uwe

Re: daily vs named

[Valery Ushakov]

On Wed, Sep 18, 2019 at 12:25:57 +0100, Stephen Borrill wrote:

> On Tue, 17 Sep 2019, Dima Veselov wrote:
>
> > its not a great issue, but I wish to know if there is a clue
> > to daily(5) not complaining about relocated named(8).
> > I always move named(8) to /var/chroot as it is supposed
> > in rc.conf for security. After that daily(5) always complain:
> > 
> > Checking special files and directories. etc/namedb:
> >type (dir, link) etc/named.conf:
> >type (file, link)
> > 
> > Maybe there are some security exclusion mechanism around
> > distfiles?
> 
> You could do one of the following:
> 1) Add check_mtree_follow_symlinks=YES to /etc/security.conf
> 2) Add your own edited mtree entries to /etc/mtree/special.local

Yeah.  I have on my namesever:

$ cat /etc/mtree/special.local 
./etc/named.conftype=link mode=0755
./etc/namedbtype=link mode=0755


Perhaps we should install an empty (comment only) special.conf by
default.

-uwe

Re: Typo in vitut.txt

[Valery Ushakov]

adr  wrote:

> /usr/share/doc/usd/vi/vitut.txt lines 943-984/2970 ...
[...] 
> "...you shoud use a _named_ buffer."

Applied.  Thank you.

-uwe

Re: uniq on open streams

[Valery Ushakov]

Andreas Krey  wrote:

> [...] also:
> 
>netbsd$ uniq --help
>uniq: uniq: No such file or directory

Thanks, this one should be fixed now.

-uwe

Re: Swap over NFS

[Valery Ushakov]

Greg Troxel  wrote:
> BERTRAND Jo?l  writes:
> 
>>   I'm trying to configure swap over NFS (on a diskless workstation).
>>
>>   I have created a swapfile on nfsserver:/srv/schwarz/ (swapfile.0) and
>> added in client /etc/fstab :
>>
>> nfsserver:/srv/schwarz/swapfile.0 none swap sw,nfsmntpt=/swap
>>
>>   nfs server seems to run as expected as client can mount
>> nfsserver:/srv/schwarz in /
[...]
> I haven't used diskless for a really long time, so this question may be
> off.  If you have a single root exported partition that you have /swap
> in, why don't you just put swapfile.0 in swap in the first place, and
> use a swap line that adds the file, not trying to mount it?

Since the swap file is already inside the client's root as far as I
can tell, you don't have to mount it separately.  From the fstab of
one of my diskless machines:

  server:/export/root/krups / nfs rw
  # the swap file is server:/export/root/krups/swap
  /swap /swap swap sw

-uwe

Re: rc.d problem

[Valery Ushakov]

Dima Veselov  wrote:
> On Fri, Jan 18, 2019 at 02:16:31PM +0100, Martin Husemann wrote:
>> On Fri, Jan 18, 2019 at 04:07:06PM +0300, Dima Veselov wrote:
>> > I have completely no idea why 8.0-STABLE can't take non-integer value.
>> Is there a locale issu involved?
> 
> Ahh, magician, how did you got this??? Unbelievable.
> 
> [root@ranir ~]$ export LC_ALL=C
> [root@ranir ~]$ sleep 0.05
> [root@ranir ~]$ export LC_ALL=ru_RU.UTF-8
> [root@ranir ~]$ sleep 0.05
> usage: sleep seconds
> [root@ranir ~]$ sleep 0,05
> [root@ranir ~]$ 
> 
> That means it also work wrong in 8.0.
> 
> So, what shall we do with that now? Maybe its right to get ','
> instead of '.', but I beleive this should not work in commandline.
> 
> I have checked - Linux and FreeBSD sleep do not take ',' with 
> same locale.

Heh, reminds me how printing something from SunOS4 apps used to
generate PostScript with locale-specific decimal separator, and PS was
very confused by "floating comma" numbers :)

-uwe

Re: wscons.conf ledstate and screen issues

[Valery Ushakov]

Rocky Hotas  wrote:

> Second issue is about the creation of new screens. I modified from default
> the wscons.conf file as follows:
> 
> #screen 0   -   vt100
> screen 1-   vt100
> screen 2-   vt100
> screen 3-   vt100
> screen 4-   vt100
> screen 5-   vt100
> screen 6-   vt100
> screen 7-   vt100
> screen 8-   -
> 
> in order to have not only 4, but 8 available screens at boot, which can be
> accessed through Ctrl+Alt+Fn. However, this generated a
> 
> wsconscfg: WSDISPLAYIO_ADDSCREEN
> 
> error. It was impossible to create them.

The above is 9 screens, not 8.

-uwe

Re: wscons.conf ledstate and screen issues

[Valery Ushakov]

Rocky Hotas  wrote:

> After installing 8.0 amd64 and tweaking wscons.conf, I experienced exactly
> the same issue as in this old message:
> 
> https://mail-index.netbsd.org/netbsd-users/2012/09/24/msg011493.html
> 
> I would like to have num lock (and its led) active at the login screen.
> 
> # wsconsctl -w ledstate=2
> 
> works for the current session. I put the line
> 
> setvar  wskbd   ledstate2
> 
> in /etc/wscons.conf. After a reboot, this configuration is correctly
> applied, as shown by the led and the screen messages; however, the *first*
> key that is pressed (whatever it is) causes the default ledstate=0 to be
> restored.
> What could it be the problem?

>From a quick look - ledstate only controls the lights, not the
internal state of the keyboard driver (that handles numlock ).

-uwe

Re: Why is TERM=vt100 on the console?

[Valery Ushakov]

Valery Ushakov  wrote:

> Anyway, as I said, if you know you will always/mostly use wscons,
> just go and change the value in ttys.

Or even better, change console to off and ttyE0, which is already set
to wsvt25, to on.  This is the default e.g. on macppc (of the ports
that I use).

-uwe

Re: Why is TERM=vt100 on the console?

[Valery Ushakov]

m...@netbsd.org wrote:

> On Fri, Sep 14, 2018 at 11:08:29AM +0000, Valery Ushakov wrote:
>> m...@netbsd.org wrote:
>> 
>> > Every time we have this discussion someone ends up saying that yes,
>> > everything being terrible and not supporting anything modern is a
>> > great default. they like it that way.
>> 
>> /etc/ttys uses wsvt25 on all ttyE* for a long long time.  It only uses
>> vt100 for console, which may be a serial console, so vt100 is a safe
>> default there.  If you know you don't use serial console you can edit
>> 1 (one) line in ttys.  Do you really think this is "terrible"?
> 
> etc.sparc64/ttys:console"/usr/libexec/getty suncons"wsvt25 on 
> secure
> 
> Why is sparc{,64} exempt from having shitty defaults? because people
> who use it don't have to ask netbsd-users if they happen to use
> sufficiently shitty hardware to justify shitty defaults?

This is funny in a way, b/c on sparc it's very easy to switch between
serial console and wscons and I did it all the time when I still
hacked on sparc regularly.  When I had free monitor/keyboard I'd use
them, when that monitor/keyboard were hooked up to something else (or
when copy-pasting text to/from console was convenient, e.g. when
digging through OFW), I'd use serial.

vt100 is a *perfect* default for this (especially on sparc, that's why
it's funny) b/c terminal emulators you'd use to access serial are
predominantly vt-compatible.  It also works with wscons b/c wscons use
vt-compatible emulattion by default too.  Yes, TERM=vt100 will not
descibe everything that wscons can do (like colors), but it will work.
This is what defaults are for.  They are meant to work in most cases.
If i really needed colors on wscons, they were just a single
"TERM=wsvt25" command away.

Anyway, as I said, if you know you will always/mostly use wscons, just
go and change the value in ttys.  This is what that file is for.  In
the dark times when real CRT terminals were a thing that was what you
did when you hooked up a terminal to the system, you'd go and edit
ttys.  B/c you might have vt220 connected and then you have to move it
elsewhere, but then you hook up a Wyse terminal to that port, etc,
etc.

Yes, I get it, these days most people don't quite grasp why TERM is
even there.  Yes, on x86 where serial consoles are not normally used
on consumer machines there's an argument to be made for wsvt25 to be
the default for console (b/c people who actually use serial console on
x86 have enough clue to edit ttys to reflect the configuration of
their system).  But I'd say it's not the best strategy on your part to
open this discussion with an argument that has "shit" in every
sentence and with the technical side of the argument being,
effectively, "I can't edit one line in one file once" ("because I have
paws" as cat memes popular here often say).

-uwe

Re: Why is TERM=vt100 on the console?

[Valery Ushakov]

m...@netbsd.org wrote:

> Every time we have this discussion someone ends up saying that yes,
> everything being terrible and not supporting anything modern is a
> great default. they like it that way.

/etc/ttys uses wsvt25 on all ttyE* for a long long time.  It only uses
vt100 for console, which may be a serial console, so vt100 is a safe
default there.  If you know you don't use serial console you can edit
1 (one) line in ttys.  Do you really think this is "terrible"?

-uwe

Re: wip/virtualbox vs emulators/qemu vs xen performance comparison?

[Valery Ushakov]

Mayuresh  wrote:

> Various mailing lists report Virtualbox to be faster.  I have used
> the same on Linux and found it satisfactory.  I have used qemu on
> NetBSD and felt it was slower.

VirtualBox doesn't support NetBSD as a host.

-uwe

Re: PTHREAD_MUTEX_INITIALIZER on 6.1.5 issues

[Valery Ushakov]

Martin Husemann  wrote:

> On Wed, May 30, 2018 at 10:34:10AM +0200, Riccardo Mottola wrote:
>> well it should return a value, look here for POSIX:
>> 
>> http://pubs.opengroup.org/onlinepubs/7908799/xsh/pthread_mutex_init.html
> 
> I don't see where it says that it should return a value. Note that the
> synapsis give is exactly what works with NetBSD:
> 
> pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
> 
> and the description says:
> 
> In cases where default mutex attributes are
> appropriate, the macro PTHREAD_MUTEX_INITIALIZER can
> be used to initialise mutexes that are statically
> allocated.
> 
> Especially note the "statically allocated".

Also, "initializer" has a very specific meaning in the C standard.

-uwe

Re: PTHREAD_MUTEX_INITIALIZER on 6.1.5 issues

[Valery Ushakov]

Riccardo  wrote:


> I am testing build og GNUstep base (head) on NetBSD 6.1.5/sparc
> 
> Build fails with:
> 
>  Compiling file NSObject.m ...
> NSObject.m: In function '+[NSObject initialize]':
> NSObject.m:1049:34: error: expected expression before '{' token
> NSObject.m: At top level:
> 
> you can see the file here:
> https://github.com/gnustep/libs-base/blob/master/Source/NSObject.m

Please, always include the relevant code excerpt and the the specific
version of the file you refer to, so that the mail can be more or less
self-contained even without the external link and the external link
actually points to something you are discussing in the mail.

-uwe

Re: nc -N and EOF

[Valery Ushakov]

Patrick Welche  wrote:

> I tried
> 
>   echo "hello from server" | nc -l 1234
> 
>   nc -l 1234 << EOF
>   hello from server
>   EOF
> 
>   echo "hello from server" > tmpfile
>   nc -l 1234 < tmpfile
> 
> and in all cases
> 
>   nc  -N 127.0.0.1 1234
> 
> prints "hello from server" but doesn't exit.

Use

  nc -d localhost 1234

-uwe

Re: vt100

[Valery Ushakov]

Kamil Rytarowski  wrote:

> How to setup correctly vt100 in a terminal?
> 
> I've set exported TERM=vt100, called tset and stty and I keep
> observing artifacts.

Heh.  This is not how terminals work.  Forget about terminal emulators
for a momemnt.  Back in the day people used real CRT terminals and
each terminal model understood/spoke its own language.  On the host
side you would use TERM variable to tell your *programs* which
language they need to speak.  If you were using, say, Wyse terminals,
you couldn't magically make them into a vt100 by setting TERM on the
host.  OTOH some (many?) terminals supported several languages and you
could use your terminal's setup menu to tell it to speak DEC VT.


> I've uploaded screen shot of xterm and script(1) recording.
> 
> http://netbsd.org/~kamil/vt100/

The typescript looks strange.  Are you sure there was not accidental
conversion(s) to/from utf-8 somewhere along the path?


-uwe

Re: Getty on USB serial port

[Valery Ushakov]

Michael van Elst  wrote:

> On Fri, Sep 15, 2017 at 05:52:10AM -0400, William D. Jones wrote:
> 
>> ```
>> rpi-ptrain$ ls -l /dev/plcom0
>> crw---  1 uucp  wheel  93, 0 Jun 25 12:49 /dev/plcom0
>> rpi-ptrain$ ls -l /dev/ttyU0
>> crw---  1 wjones  tty  74, 0 Jun 25 17:42 /dev/ttyU0
> 
>> Why are they different, and why do I own `ttyU0` (I don't think NetBSD
>> dynamically creates/alters device nodes)?
> 
> plcom0 still has the default ownership, which is the uucp account for
> the original communication protocol ("Unix-to-Unix-CoPy").
> 
> ttyU0 was running getty, you logged in and the login process passes
> ownership of the tty to you. Ownership is reset when you log out.
> 
> The command 'write' is a very traditional way to send messages to
> other users on the system by just writing text to their tty. The
> command 'mesg' is used to grant and revoke write access for others.
> 
> You also need ownership to change tty settings, without this you
> couldn't run e.g. a screen editor like vi.

BTW, shouldn't dial-out devices be owned by "dialer" and
group-writable?  ISTR this was broken when uucp was removed from the
base.  I thought we had a PR for this, but I can't seem to find it.

-uwe

Re: uts(4) touchscreen calibration

[Valery Ushakov]

Frank Wille  wrote:

> One year ago I successfully used uts(4) on a Raspberry-Pi with a ViewSonic
> touch screen monitor. It worked perfectly after eliminating the black
> borders in the RPi's config.txt.
> 
> Now we got another ViewSonic touch screen (model TD2421), which is no
> longer correctly calibrated. Touching into the upper left quarter of the
> display seems to move the mouse in X11 over the whole screen.
> 
> Both have a native resolution of 1920x1080. Is there any possibility to
> calibrate uts(4) or wsmouse to match this monitor?

There's tpctl(8) for hpc* ports in src/usr.sbin/tpctl  It shouldn't be
that hard I think to modify it to work with any wsdisplay that can do
mapped mode.

-uwe

Re: Getty on USB serial port

[Valery Ushakov]

William D. Jones  wrote:

> * `getty` is in fact spawning the `NetBSD (hostname) (tty?) login:`
> message and prompt, correct?  Then `getty` will execve `login
> [user]` to ask for the password?  One thing that confuses me is that
> the "user" prompt from both login and getty are identical.  So I
> thought `getty` somehow execve's `login` to immediately show a
> prompt once certain conditions (RTS/CTS control?) of the serial line
> are met.

getty(8) prints the first login: prompt and reads the username to be
able to look at the input and try to infer additional tty modes, iirc.
E.g. when upper-case only terminals were still a thing it would check
the login name for upper case letters and turn on case mapping.  Then
"login user" it executes asks for the password, and if you make a
mistake, the next "login:" prompt is from login(1)..


-uwe

Re: Error trying to create gre tunnel

[Valery Ushakov]

On Sat, Aug 12, 2017 at 08:48:24 -0400, D'Arcy Cain wrote:

> On 08/12/2017 12:16 AM, Valery Ushakov wrote:
> > You can forward all trafic from the consumer gizmo internet facing
> > router (with single public IP address from the provider) to the
> > internal netbsd router.  It's usually called "DMZ host" in the web
> > interface.
> 
> I considered that but it seems insecure.  I do have a few ports pointing to
> the device already though so that would just open all of them.  I suppose it
> would be no worse than using the NetBSD box as my gateway router.

Yes, the netbsd router is effectively the gateway router.


> > PS: Hmm, looking at gre(4), shouldn't the example be fixed to say
> > 
> >ifconfig greN tunnel B C
> 
> I don't think so.  I am pretty sure that I read that the first argument to
> tunnel must be an address on the host server.  Not sure where I read that
> though as I have been doing a lot of research in the last day or two.  I
> couldn't find it in the man page.

Two points here: 1) the example I gave is adapted from the actual
working configuration I use; 2) in the man page example address C is
not mentioned at all in the configuration of "Router A".  How can
router A divine it, as it obviously needs to send the GRE packets to
the address C (remote-outer-ip).

-uwe

Re: Error trying to create gre tunnel

[Valery Ushakov]

Andy Ruhl  wrote:

> On Fri, Aug 11, 2017 at 3:53 PM, D'Arcy Cain  wrote:
>> On 08/11/2017 12:37 PM, D'Arcy Cain wrote:
>> It turns out that I misunderstood the example.  Both servers need to be on
>> the public Internet.  In my case only the remote was.
>>
>> Is there some way to do this?  I can port forward but I suspect that that
>> won't work as it doesn't use TCP or UDP over the tunnel.  I looked at
>> OpenVPN but that only allows individual hosts to connect.  I am trying to
>> join two internal networks.
>>
>> I can get a second IP address for my system but I need something that works
>> for other clients who may not have that option.
> 
> I suppose you could try forwarding all GRE (ip protocol 47) inward to
> wherever the GRE tunnel lives inside the network. Have you tried that?
> 
> I haven't tried doing this, I can't tell you how it would work. It's
> normally best to do these tunnels at the internet facing router, and
> then set up routes so that your internal clients can reach the other
> side.

You can forward all trafic from the consumer gizmo internet facing
router (with single public IP address from the provider) to the
internal netbsd router.  It's usually called "DMZ host" in the web
interface.

To configure the tunnel on the internal router create
/etc/ifconfig.gre0 with:

  ! route add remote-outer-ip 192.168.1.1
  local-inner-ip remote-inner-ip netmask 0x link0 -link2 up
  tunnel 192.168.1.2 remote-outer-ip

Point default route on the netbsd router to remote-inner-ip.

Here 192.168.1.1 is the local address of the external consumer gizmo
router and 192.168.1.2 is the address of the netbsd router used to
talk to the gizmo.

If the other side is also behind NAT, use provider's public address
for remote-outer-ip

PS: Hmm, looking at gre(4), shouldn't the example be fixed to say

  ifconfig greN tunnel B C

-uwe

Re: NetBSD 7.1 i386 on Virtualbox (fatal breakpoint trap in supervisor mode)

[Valery Ushakov]

Thor Lancelot Simon <t...@panix.com> wrote:

> On Sun, Jul 16, 2017 at 05:35:09PM +0000, Valery Ushakov wrote:
>> 
>> Right, because you use VT-x.  Older CPUs and low-end CPUs (atoms)
>> don't have VT-x.  Even if your CPU supports it, you might also need to
>> explicitly enable VT-x in BIOS (not a problem for OSX).
> 
[...]
> The problem with VirtualBox without VT-x is that their trick of
> patching the guest OS to run in ring 3 doesn't play nice with our
> method of dynamically patching various primitives in the kernel to
> be efficient in particular machine configurations.  I thought they'd
> fixed that, though...

Finally found my old mail on the topic:

  http://mail-index.netbsd.org/netbsd-users/2013/06/21/msg013010.html

You refer to second problem.  Dunno if it's been fixed.  The first one
is more complex.

As for the TSS, someone with x86 clue should look into this.  Might
give a performance boost under qemu too - will be good for anita runs.

-uwe

Re: NetBSD 7.1 i386 on Virtualbox (fatal breakpoint trap in supervisor mode)

[Valery Ushakov]

Gua Chung Lim <ptkris...@gmail.com> wrote:
> * Valery Ushakov (u...@stderr.spb.ru) wrote:
>> Without VT-x enabled VirtualBox fails to run NetBSD by default.  This
>> is a VirtualBox limitation, it cannot correctly handle some low-level
>> kernel code that NetBSD uses.  IIRC, using --recompile-supervisor flag
>> should help in this case.
>
> I'm not quite sure what you mean.
> But on my machine, NetBSD runs behind VirtualBox on macOS host pretty 
> fine with default configuration. I have been running it for years.

Right, because you use VT-x.  Older CPUs and low-end CPUs (atoms)
don't have VT-x.  Even if your CPU supports it, you might also need to
explicitly enable VT-x in BIOS (not a problem for OSX).

-uwe

Re: NetBSD 7.1 i386 on Virtualbox (fatal breakpoint trap in supervisor mode)

[Valery Ushakov]

Rodolfo Edgar <sololistasdecor...@gmail.com> wrote:

> 2017-07-15 20:35 GMT-05:00, Valery Ushakov <u...@stderr.spb.ru>:
>> Rodolfo Edgar <sololistasdecor...@gmail.com> wrote:
>>
>>> I have machine when I am using virtualbox, I use 32 bits operating
>>> system as Debian, CentOS, FreeBSD, but NetBSD and OpenBSD have
>>> problem, in this case NetBSD 6.x or 7.x have problem:
>>> The screenshot about NetBSD and VirtualBox
>>>
>>> http://i.imgur.com/RtynhXn.png
>>>
>>> I want to use NetBSD, what is the procedure to do NetBSD install
>>> normally? Thanks you for your reply.
>>
>> Do you have VT-x enabled on the host?
> 
> Is not necesary,  because I can run 32 bits machines, currently have
> my real machine is a Notebook compaq 610, I have operating system 64
> bits, my guest all are 32 bits operating system, I have FreeBSD and
> others 32 bits, it's works, but NetBSD 32 bits nothing :(

What do you mean by "is not necessary"?  Do you have VT-x enabled or
not?

-uwe

Re: NetBSD 7.1 i386 on Virtualbox (fatal breakpoint trap in supervisor mode)

[Valery Ushakov]

Rodolfo Edgar  wrote:

> I have machine when I am using virtualbox, I use 32 bits operating
> system as Debian, CentOS, FreeBSD, but NetBSD and OpenBSD have
> problem, in this case NetBSD 6.x or 7.x have problem:
> The screenshot about NetBSD and VirtualBox
> 
> http://i.imgur.com/RtynhXn.png
> 
> I want to use NetBSD, what is the procedure to do NetBSD install
> normally? Thanks you for your reply.

Do you have VT-x enabled on the host?

-uwe

Re: Updates to man-k.org

[Valery Ushakov]

Abhinav Upadhyay  wrote:

> Just wanted to post some recent updates that I have made to
> http://man-k.org (a web interface on top of NetBSD's apropos(1)):

Thanks for your continuing work on this!

There appears to be a problem with NetBSD-7 index.  Searching for
anything returns nothing: "No relevant search results found. Please
try with better keywords."  The man pages themselves are there if you
edit the URL, e.g. http://man-k.org/man/NetBSD-7/1/sh

-uwe

Re: Best way to receive netbsd.org list messages?

[Valery Ushakov]

Thomas Mueller  wrote:

>> > I visited their website, also tried to browse messages from the news
>> > link on http://www.netbsd.org/mailinglists/ , got blank pages.
> 
>> Those links looks broken indeed, but NNTP does work.  E.g. if you look
>> at the headers of this message you can see it was sent via gmane's
>> NNTP.
> 
> I also visited gmane.org website, and get the impression that
> gmane.org is very undependable.  Or does NNTP work even when the web
> interface fails?

I don't use their web interface, so I wouldn't know anything about its
stability.  I have been using NNTP all this time without problems.

-uwe

Re: Best way to receive netbsd.org list messages?

[Valery Ushakov]

Thomas Mueller  wrote:
> Thomas Mueller  wrote:
> 
>> Do I do better to [...] use gmane with NNTP software?  There are
>> NNTP packages for Linux, *BSD, Haiku, even DOS (let's not forget
>> mutt).
> [...]
>> ... but somebody might be able to say how they fare with gmane.
> 
>> I've been using gmane nntp for a long time now to read a lot of netbsd
>> (and not only) mailing lists and I'm quite happy with it.
> 
>> The important part of the setup for me is that news/tin can cache
>> overviews.  That speeds things up *a lot*.  Over the years I've tried
>> to look at other newsreaders, but the delay of entering a group is
>> simply unbearable.  I guess I'm stuck with tin, but I'm sort of gotten
>> used to in the past 25 years anyway.
> 
>> -uwe
> 
> Now it looks like gmane is nonfunctional or at least very undependable.
> 
> I visited their website, also tried to browse messages from the news
> link on http://www.netbsd.org/mailinglists/ , got blank pages.

Those links looks broken indeed, but NNTP does work.  E.g. if you look
at the headers of this message you can see it was sent via gmane's
NNTP.

-uwe

Re: Best way to receive netbsd.org list messages?

[Valery Ushakov]

Thomas Mueller  wrote:

> Do I do better to [...] use gmane with NNTP software?  There are
> NNTP packages for Linux, *BSD, Haiku, even DOS (let's not forget
> mutt).
[...]
> ... but somebody might be able to say how they fare with gmane.

I've been using gmane nntp for a long time now to read a lot of netbsd
(and not only) mailing lists and I'm quite happy with it.

The important part of the setup for me is that news/tin can cache
overviews.  That speeds things up *a lot*.  Over the years I've tried
to look at other newsreaders, but the delay of entering a group is
simply unbearable.  I guess I'm stuck with tin, but I'm sort of gotten
used to in the past 25 years anyway.

-uwe

Re: debugging a memory leak

[Valery Ushakov]

Timo Buhrmester  wrote:

> > but it's limited to Linux, Darwin, and Solaris.
> 
> Last time I checked, FreeBSD also had valgrind working.  I wonder
> how much effort it would be to port it to NetBSD.

As far as I understand (I had my brushes with valgrind internals) it's
mostly the drudgery of, effectively, writing code that annotates all
the system calls and all ioctls.  And that's not fun, obviously.

-uwe

Re: question; how to build individual userland programs on NetBSD 7-RC3 ?

[Valery Ushakov]

Martin Husemann  wrote:

> On Wed, Sep 16, 2015 at 08:58:22AM +0200, Martin Husemann wrote:
>> The officialy sanctioned way is to create tools upfront (e.g. by runing
>> "build.sh tools" or a variant of that) and use nbmake-$arch from the
>> $TOOLDIR/bin/ directory created by that step.
> 
> Actually you will need more - one of the benefits of this version is that
> you may build arbitrary source tree versions on arbitrary host versions,
> so the header and libs do not need to be the same.
> 
> But this means "build.sh tools" is not enough, a full "build.sh build"
> is required (which, of course, includes the tool step). Maybe we should
> create a "build.sh libs-and-includes" ?

Exactly.

http://www.stderr.spb.ru/~uwe/netbsd/cross.html

-uwe

Re: something like linux-fb?

[Valery Ushakov]

Mayuresh Kathe mayur...@kathe.in wrote:
 On 2014-09-10 18:11, Mayuresh wrote:
 On Tue, Sep 09, 2014 at 11:02:42PM +0530, Mayuresh Kathe wrote:
 is there something under netbsd which provides capabilities similar
 to the linux graphics framebuffer driver?
 
 https://mail-index.netbsd.org/pkgsrc-wip-review/2012/02/26/msg001372.html
 
 perfect! thanks for that tip. :)
 is valeriy ushakov the same as uwe@?

yes :)

Though I don't see how am I related to that mail...

-uwe

Re: stdbool.h gcc compiler query

[Valery Ushakov]

Manuel Bouyer bou...@antioche.eu.org wrote:

 On Thu, Aug 08, 2013 at 11:09:12AM +0100, Patrick Welche wrote:

 One of the hunks of XSA-55 which I am trying to apply to xenkernel42 is:
 
 --- a/xen/include/xen/libelf.h
 +++ b/xen/include/xen/libelf.h
 @@ -29,6 +29,11 @@
  #error define architectural endianness
  #endif
  
 +#include stdbool.h
 +
 +typedef int elf_errorstatus; /* 0: ok; -ve (normally -1): error */
 +typedef int elf_negerrnoval; /* 0: ok; -EFOO: error */
 +
  #undef ELFSIZE
  #include elfstructs.h
  #ifdef __XEN__
 
 $ ls -l /usr/include/stdbool.h 
 -r--r--r--  1 root  wheel  1784 Apr 29 17:46 /usr/include/stdbool.h
 
 and the beginning of the long compiler line copied below contains
 -I/usr/include (as well as -nostdinc), so why do I see
 
 In file included from libelf-private.h:25:0,
  from libelf-tools.c:19:
 /tmp/pkgsrc/sysutils/xenkernel42/work.x86_64/xen-4.2.2/xen/include/xen/libelf.h:32:21:
  fatal error: stdbool.h: No such file or directory
 compilation terminated.
 
 ? (This is on -current/amd64)
 
 I guess it's because the -I/usr/include is after the -nostdinc
 
 Is stdbool.h really needed here ? AFAIK the build of the elf kernel
 should not rely on host includes, only its own includes.

sys/types.h defines bool/true/false for the kernel

-uwe