Re: Cannot interact with boot menu through (virtual) serial console.
Ottavio Caruso wrote: > I can see all the boot messages and I can log in through the serial > console, but I can't select any options at the boot menu. There is a qemu bug report for this: https://bugs.launchpad.net/bugs/1743191 -- Andreas Gustafsson, g...@gson.org
Re: ZFS status
On Feb 21, 2020, at 5:45 AM, Sad Clouds wrote: Hi, anyone knows the current status of ZFS for recently released NetBSD-9? There is a message on the console - "WARNING: ZFS on NetBSD is under development". OK, but what does this mean? There is a good chance it may lose/corrupt data, or it's pretty stable but watch out for minor issues? That, should you, presently, presume you have, enough people, or time, maybe you shouldn't. Backup strategies, aren't the same as number of backups, made, and kept. Do you have bit-for-bit backups, (*sp* foresnsic *sp*) More software tools? Maybe, instead of buying after a dip, or moving corporate stocks into bonds, correct issues you may not know, you now could have, and move stocks into cash on hand; Hire a Dev, for an Admin position, for a while, if, OR when, they present themselves to you, for example, if UR also, a business, or corporate entity.
Cannot interact with boot menu through (virtual) serial console.
Hi, Minor annoyance. I'm booting: $ uname -a NetBSD NetBSD 9.0 NetBSD 9.0 (GENERIC) #0: Fri Feb 14 00:06:28 UTC 2020 mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64 as a guest using qemu: qemu-system-x86_64 \ -drive if=virtio,file=/home/oc/VM/img/openbsd.image,index=0,media=disk \ -M q35,accel=kvm -m 350M -cpu host -smp $(nproc) \ -nic user,hostfwd=tcp::-:22,model=virtio-net-pci -nographic This is an upgrade from 8.1 after a fresh reinstall. I have installed the bootblocks on com0 and I have this in /boot.cfg: menu=Boot serial:rndseed /var/db/entropy-file;consdev com0;boot netbsd menu=Boot normally:rndseed /var/db/entropy-file;boot netbsd menu=Boot single user:rndseed /var/db/entropy-file;boot netbsd -s menu=Disable ACPI:rndseed /var/db/entropy-file;boot netbsd -2 menu=Disable ACPI and SMP:rndseed /var/db/entropy-file;boot netbsd -12 menu=Drop to boot prompt:prompt default=1 timeout=5 clear=1 I can see all the boot messages and I can log in through the serial console, but I can't select any options at the boot menu. No key seems to be recognised. The timer counts down from 5 to 0 and then boots the default option. If one day I wanted to boot into single mode, I wouldn't be able to do it without editing boot.cfg. As a term of comparison, I have the same setting for 2 VMs running FreeBSD and OpenBSD and I cannot replicate the same issue with either OSes. Any input will be appreciated. Full dmesg: https://dmesgd.nycbug.org/index.cgi?do=view=5409 -- Ottavio Caruso
Re: postinstall fixes failed: gid
Ottavio Caruso writes: > 2) Why do I need a nvmm group? The system has a plan for a group, almost certainly because some software runs under that group or grants permission to it. Do you really need it named? Probably not, but there is nothing to be gained in being different. > 3) I've manually added: > nvmm:*:34:root > to the group file and now I have no errors. Is this enough? Do I have > to rebuild any databases? No rebuild is necessary. I unpack etc and xetc sets to /usr/netbsd-etc (via INSTALL-NetBSD in etcmanage) and I do diff -u /usr/netbsd-etc/etc/group /etc/group and make sure I understand the differences. Similary for master.passsword, but that I edit with vipw.
Re: postinstall fixes failed: gid
Ottavio wrote: > [...] > gid fix: > Error groups (FIX MANUALLY): nvmm (missing) > Use the following as a template: > nvmm:*:34:root > and adjust if necessary > [...] > postinstall fixes failed: gid > > My questions are; > 1) Why has this happened? Is this a bug? It has happened because NetBSD tends to the safe side and doesn't add the group itself. You may have number "34" already used for some other group, and you need to resolve things in that case. It may also make sense to add users to the group, see below. > 2) Why do I need a nvmm group? This really dpends on the NVMM software kit. I don't have seen that myself and can't help you there (my only post-8 netbsd is a -current on a lwoly i386, no nvmm there). The nvmm-related man-pages should tell you the purpose of the group. I would expect virtual disks and machine descriptions will belong to that group and so anybody in the group would be allowed to manipulate/add/use/remove VMs. This is just a guess -- RTFM and check how the group is actually used in the filesystem for files and directories. > 3) I've manually added: > nvmm:*:34:root > to the group file and now I have no errors. Is this enough? Yes, well done. (Unless you already had another group 34 already.) > Do I have to rebuild any databases? No. /etc/group is just that plain file and you are done. (In contrast, the user file /etc/passwd is just a clone of /etc/master.passwd and changes to both are done using vipw(8).) Martin Neitzel
RE: Moritz Systems
Congratulations and Best of Luck for success. Very pleased to see NetBSD focused corporation :) On Wed, 04 Mar 2020 at 6:32 pm Kamil Rytarowski wrote: > I’m pleased to inform you about my new project. I have founded Moritz Systems. Moritz Systems is an IT start-up with focus to commercialize NetBSD derived products. Our mission is: - Enhancing the Operating System in areas critical for commercial users. - Building commercial products based on the NetBSD Operating System. Moritz Systems is a new company, but it is associated with experienced software developers from the BSD community supported by commercial and management experts. Our team has expertise in working on toolchains, low-level components, kernel and userland code, building tailor made distributions and packaging third party software in packaging collections. I will be pleased to have your suggestions regarding potential clients interested for our services and their requirements. I’m looking forward to your reply. Best regards, Kamil Rytarowski CTO, Moritz Systems www.moritz.systems [http://www.moritz.systems] -- Jay Patel https://www.unitedbsd.com/ [https://www.unitedbsd.com/] usually found @https://riot.im/app/#/room/#bsd:matrix.org [https://riot.im/app/#/room/%23bsd:matrix.org] [https://api.criptext.com/email/open/%3C1583327023204.043283%40criptext.com%3E]
Re: Linux-Netbsd huge difference of speed, same hardware
Others have said some of this: random devices are not apples to apples as they may have different behavior test urandom separately by dd from urandom to /dev/null test by reading and sending to /dev/null, bs=1m (not what you want to make fast, but interesting data point) It is possible that something in NetBSD should be improved. People here are not trying to claim that's not the case - just to make progress understanding. Also, on my apu2, using an internal mSATA SSD (exactly the same as yours), reading 1 GB from it and discarding it under NetBSD 8 amd64 (not what you are doing) gets me: $ dd if=/dev/rwd0d of=/dev/null bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 3.359 secs (319661156 bytes/sec) which looks good. (I have not tried to use an SD card on mine.)
postinstall fixes failed: gid
Hi, upgraded from 8.1 to 9.0 (amd64) Running: # postinstall -s /tmp/etc.tar.xz fix Full log at the end of this message, but relevant bits here: [...] gid fix: Error groups (FIX MANUALLY): nvmm (missing) Use the following as a template: nvmm:*:34:root and adjust if necessary [...] postinstall fixes failed: gid Leonardo Taccari gave me a fix once but I did not save it. My questions are; 1) Why has this happened? Is this a bug? 2) Why do I need a nvmm group? 3) I've manually added: nvmm:*:34:root to the group file and now I have no errors. Is this enough? Do I have to rebuild any databases? Thanks. # postinstall -s /tmp/etc.tar.xz fix Note: Creating temporary directory /tmp/_postinstall.1706.0/etc.tgz Note: Extracting files from /tmp/etc.tar.xz Source directory: /tmp/_postinstall.1706.0/etc.tgz (extracted from: /tmp/etc.tar.xz) Target directory: / bluetooth fix: ddbonpanic fix: defaults fix: (Checking for pf.boot.conf from /tmp/_postinstall.1706.0/etc.tgz/etc/defaults instead of /tmp/_postinstall.1706.0/etc.tgz/usr.sbin/pf/etc/defaults) dhcpcd fix: (Checking for dhcpcd.conf from /tmp/_postinstall.1706.0/etc.tgz/etc instead of /tmp/_postinstall.1706.0/etc.tgz/external/bsd/dhcpcd/dist/src) dhcpcdrundir fix: envsys fix: fontconfig fix: /tmp/_postinstall.1706.0/etc.tgz/etc/fonts/conf.avail is not a directory; skipping check gid fix: Error groups (FIX MANUALLY): nvmm (missing) Use the following as a template: nvmm:*:34:root and adjust if necessary. gpio fix: hosts fix: iscsi fix: makedev fix: (Checking for MAKEDEV from /tmp/_postinstall.1706.0/etc.tgz/dev instead of /tmp/_postinstall.1706.0) (Checking for MAKEDEV.local from /tmp/_postinstall.1706.0/etc.tgz/dev instead of /tmp/_postinstall.1706.0/etc.tgz/etc) motd fix: mtree fix: named fix: pam fix: periodic fix: pf fix: (Checking for pf.os from /tmp/_postinstall.1706.0/etc.tgz/etc instead of /tmp/_postinstall.1706.0/etc.tgz/dist/pf/etc) pwd_mkdb fix: rc fix: (Checking for blacklistd from /tmp/_postinstall.1706.0/etc.tgz/etc/rc.d instead of /tmp/_postinstall.1706.0/etc.tgz/external/bsd/blacklist/etc/rc.d) ssh fix: (Checking for moduli from /tmp/_postinstall.1706.0/etc.tgz/etc instead of /tmp/_postinstall.1706.0/etc.tgz/crypto/external/bsd/openssh/dist) wscons fix: x11 fix: xkb fix: uid fix: varrwho fix: tcpdumpchroot fix: atf fix: (Checking for NetBSD.conf from /tmp/_postinstall.1706.0/etc.tgz/etc/atf instead of /tmp/_postinstall.1706.0/etc.tgz/external/bsd/atf/etc/atf) (Checking for atf-run.hooks from /tmp/_postinstall.1706.0/etc.tgz/etc/atf instead of /tmp/_postinstall.1706.0/etc.tgz/external/bsd/atf/dist/tools/sample) catpages fix: manconf fix: ptyfsoldnodes fix: varshm fix: obsolete fix: postinstall fixes passed: bluetooth ddbonpanic defaults dhcpcd dhcpcdrundir envsys fontconfig gpio hosts iscsi makedev motd mtree named pam periodic pf pwd_mkdb rc ssh wscons x11 xkb uid varrwho tcpdumpchroot atf catpages manconf ptyfsoldnodes varshm obsolete postinstall fixes failed: gid -- Ottavio Caruso
Re: Linux-Netbsd huge difference of speed, same hardware
76nem...@gmx.ch (Pierre Dupond) writes: >This is to initialise a cgd partition with random data. One can use the >Netbsd way (by using "dd if=/dev/zero" on a cgd device with a random >key) but since I have initialised firstly the partition (mbr, not BSD) >on Linux I want to compare the same method on both systems. The speed of the random number generator can be significantly different and might be CPU limited. To be sure that you use the same method here, it's probably better to use a userland program (e.g. same versions of openssl rand) to generate the input. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Linux-Netbsd huge difference of speed, same hardware
mar...@duskware.de (Martin Husemann) writes: >> Why the use of the raw device makes a difference. >It avoids another level of buffering in the kernel. The block device also uses tiny 2KB requests that are extra slow for SD cards. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Moritz Systems
I’m pleased to inform you about my new project. I have founded Moritz Systems. Moritz Systems is an IT start-up with focus to commercialize NetBSD derived products. Our mission is: - Enhancing the Operating System in areas critical for commercial users. - Building commercial products based on the NetBSD Operating System. Moritz Systems is a new company, but it is associated with experienced software developers from the BSD community supported by commercial and management experts. Our team has expertise in working on toolchains, low-level components, kernel and userland code, building tailor made distributions and packaging third party software in packaging collections. I will be pleased to have your suggestions regarding potential clients interested for our services and their requirements. I’m looking forward to your reply. Best regards, Kamil Rytarowski CTO, Moritz Systems www.moritz.systems signature.asc Description: OpenPGP digital signature
Re: Linux-Netbsd huge difference of speed, same hardware
On Wed, Mar 04, 2020 at 10:07:29AM +0100, Pierre Dupond wrote: > Thanks for the tip. It is a little bit faster now > but still much less fast than with Linux. Why the use > of the raw device makes a difference. > > The transcript of the commands when using > the raw device is: > > oche# dd if=/dev/urandom of=/dev/rld0f bs=32k count=1000 > 1000+0 records in > 1000+0 records out > 32768000 bytes transferred in 7.726 secs (4241263 bytes/sec) > oche# dd if=/dev/urandom of=/dev/rld0f bs=32k count=1 > 1+0 records in > 1+0 records out > 32768 bytes transferred in 90.755 secs (3610599 bytes/sec) > oche# ^C > oche# dd if=/dev/urandom of=/dev/rld0f bs=2m count=100 > 100+0 records in > 100+0 records out > 209715200 bytes transferred in 45.064 secs (4653719 bytes/sec) Are you using the same implementation of dd(1) on both systems? As was previously mentioned, GNU dd may return before all data has actually been written to disk. Also, it's not clear whether you're actually testing the speed of the /dev/urandom device here. Maybe use a more neutral device such as /dev/zero or a static file? In the end, if Linux seems to be faster and better for doing what you need to do, then maybe do that thing on Linux? > > Le 04.03.20 à 08:20, Martin Husemann a écrit : > > On Wed, Mar 04, 2020 at 08:08:34AM +0100, Pierre Dupond wrote: > >> I try to execute the command "dd if=/dev/urandom of=/dev/ld0f bs=2m" (or > >> "bs=32k" but > >> this make no difference). > > > > You want of=/dev/rld0f here. > > > > Also I dimly remember gnu dd not flushing the output or something unless > > some special option is given, but that should not make a real difference for > > huge transfers. > > > > Martin > > -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden
Re: Linux-Netbsd huge difference of speed, same hardware
Le 04.03.20 à 10:41, Martin Husemann a écrit : > On Wed, Mar 04, 2020 at 10:07:29AM +0100, Pierre Dupond wrote: >> Thanks for the tip. It is a little bit faster now >> but still much less fast than with Linux. > > Just out of curiosity, why are you mising in /dev/urandom here? > For performance measurements probably /dev/zero is better (but I don't > know if SD cards optimize all-zero blocks). > This is to initialise a cgd partition with random data. One can use the Netbsd way (by using "dd if=/dev/zero" on a cgd device with a random key) but since I have initialised firstly the partition (mbr, not BSD) on Linux I want to compare the same method on both systems. The difference of speed made me think to an hardware/low level software problem on Netbsd. I generally prefer BSD flavour to Linux (mainly for using firewall and some other programs I find a little bit more convenient). Since this machine will be an important server (but without too much load), I can tolerate slowness but not hardware problems. > Is the speed of the card properly detected (i.e. does the dmesg part > you posted match the marketing numbers from the manufacturer)? > >> Why the use of the raw device makes a difference. > > It avoids another level of buffering in the kernel. Thanks, I understand better now why it's interesting to use the raw device. Pierre
Re: Linux-Netbsd huge difference of speed, same hardware
On Wed, Mar 04, 2020 at 10:41:14AM +0100, Martin Husemann wrote: > On Wed, Mar 04, 2020 at 10:07:29AM +0100, Pierre Dupond wrote: > > Thanks for the tip. It is a little bit faster now > > but still much less fast than with Linux. > > Just out of curiosity, why are you mising in /dev/urandom here? s/mising/mixing/ --- /me gets some coffee
Re: Linux-Netbsd huge difference of speed, same hardware
On Wed, Mar 04, 2020 at 10:07:29AM +0100, Pierre Dupond wrote: > Thanks for the tip. It is a little bit faster now > but still much less fast than with Linux. Just out of curiosity, why are you mising in /dev/urandom here? For performance measurements probably /dev/zero is better (but I don't know if SD cards optimize all-zero blocks). Is the speed of the card properly detected (i.e. does the dmesg part you posted match the marketing numbers from the manufacturer)? > Why the use of the raw device makes a difference. It avoids another level of buffering in the kernel. Martin
Re: Linux-Netbsd huge difference of speed, same hardware
Thanks for the tip. It is a little bit faster now but still much less fast than with Linux. Why the use of the raw device makes a difference. The transcript of the commands when using the raw device is: oche# dd if=/dev/urandom of=/dev/rld0f bs=32k count=1000 1000+0 records in 1000+0 records out 32768000 bytes transferred in 7.726 secs (4241263 bytes/sec) oche# dd if=/dev/urandom of=/dev/rld0f bs=32k count=1 1+0 records in 1+0 records out 32768 bytes transferred in 90.755 secs (3610599 bytes/sec) oche# ^C oche# dd if=/dev/urandom of=/dev/rld0f bs=2m count=100 100+0 records in 100+0 records out 209715200 bytes transferred in 45.064 secs (4653719 bytes/sec) Le 04.03.20 à 08:20, Martin Husemann a écrit : > On Wed, Mar 04, 2020 at 08:08:34AM +0100, Pierre Dupond wrote: >> I try to execute the command "dd if=/dev/urandom of=/dev/ld0f bs=2m" (or >> "bs=32k" but >> this make no difference). > > You want of=/dev/rld0f here. > > Also I dimly remember gnu dd not flushing the output or something unless > some special option is given, but that should not make a real difference for > huge transfers. > > Martin >
