sponsor NetBSD for 2020 https://github.com/sponsors/NetBSD
Hey -- the end of the year is coming up fast. Wouldn't you feel better about yourself if you added a github sponsorship to balance out your incredible year? :) Do you live in one of these places? Australia Austria Belgium Canada Cyprus Czech Republic Denmark Estonia Finland France Germany Greece Hong Kong SAR Ireland Italy Japan Latvia Lithuania Luxembourg Malta Mexico Netherlands New Zealand Norway Poland Portugal Singapore Slovakia Slovenia Spain Sweden Switzerland United Kingdom United States of America then sign up: https://github.com/sponsors/NetBSD A little while ago we added some very low tiers so it's not a lot of money at all!
daily CVS update output
Updating src tree: P src/distrib/sets/lists/tests/mi P src/distrib/syspkg/sets/comp/Makefile cvs update: `src/distrib/syspkg/sets/comp/comp-c-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-c-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-c-catman/Makefile' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-cvs-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-cvs-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-cvs-catman/Makefile' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-cxx-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-cxx-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-cxx-catman/Makefile' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-debug-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-debug-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-debug-catman/Makefile' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-fortran-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-fortran-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-fortran-catman/Makefile' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-sys-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-sys-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-sys-catman/Makefile' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-sysutil-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-sysutil-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-sysutil-catman/Makefile' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-util-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-util-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/comp/comp-util-catman/Makefile' is no longer in the repository P src/distrib/syspkg/sets/games/Makefile cvs update: `src/distrib/syspkg/sets/games/games-games-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/games/games-games-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/games/games-games-catman/Makefile' is no longer in the repository cvs update: `src/distrib/syspkg/sets/games/games-utils-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/games/games-utils-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/games/games-utils-catman/Makefile' is no longer in the repository P src/distrib/syspkg/sets/man/Makefile cvs update: `src/distrib/syspkg/sets/man/man-adosfs-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-adosfs-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-adosfs-catman/Makefile' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-amd-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-amd-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-amd-catman/Makefile' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-audio-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-audio-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-audio-catman/Makefile' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-bind-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-bind-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-bind-catman/Makefile' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-bootserver-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-bootserver-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-bootserver-catman/Makefile' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-c-catman/COMMENT' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-c-catman/DESCR' is no longer in the repository cvs update: `src/distrib/syspkg/sets/man/man-c-catman/Makefile' is no longer in the repository cvs update:
Re: XEN help needed
Am 09.11.2020 um 16:55 schrieb g...@duzan.org: > > >> >> Hello all you XEN experts! >> >> I've got a XEN3_DOMU virtual machine currently running NetBSD 8.1, and >> hosted on a commercial provider (www.prgmr.com). Since I'm running >> 8.1 I think that implies that I'm running in HVM mode? hmm, why? i have NetBSD DomUs even in PV since many years (darkly remember NetBSD 4 or 5) too. You should see it by i.e. network device naming (i.e. xennetX) if so and some further PV devices by dmsg. niels. — Niels Dettenbach https://www.syndicat.com https://www.syndicat.com/pub_key.asc
Re: recent sysinst UX changes
>> Lack of good randomness does not quite equal insecure install. Warn >> about it, sure, but I think *requiring* randomness is a bad idea. >> For example, I've been working with recent NetBSD at work, for >> something for which the presence or absence of good random-seed data >> makes absolutely no difference to security. > Unfortunately it leads to surprise failures if programs ever use > /dev/random. This does not happen for the product in question. There isn't even any entry "random" in /dev in the shipped filesystem - there are only 50 entries in its /dev. I recognize that we won't be using sysinst for the shipped filesystem image anyway. I'm just trying to point out that typical installs needing $THING is not a good reason to insist on everyone having $THING. (For whose value of "typical installs", anyway?) I'm building kernels with neither INET nor INET6 - it doesn't quite work out of the box for 9.1, but it's close enough that only a few files need fixing. Last time I tried it, sysinst let me install a system with no IP address configuration. IMO this should be the same: done by default, automatically if it's easy, but should be skippable if the user says to despite the warnings. In any case, even if the installed system needs a random seed file, that is not the same thing as sysinst needing to install it. > So far we've seen: > - Firefox refusing to start IMO, bug in Firefox. Hanging during startup when trying to do something like fetch a user's configured initial page which is stuck behind HTTPS, that's fine, even expected. Refusing to start? No. > - Python having problems Depending on what the "problems" are, I could call this anything from "expected" to "bug in python". In any case, even if NetBSD were to ship with firefox and python, nothing says the user has to use either one; I still don't see these as justifying sysinst insisting on installing a random seed file. > And some more things that have been patched not to use /dev/random. Sure. And if you don't set the timezone, you'll be stuck in UTC. And if you don't set up a mailer, mail won't work. If you don't set any DNS servers, things depending on name resolution won't work. I don't see this as fundamentally any different. Warning, fine. Enforcing, not - IMO! - fine. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: recent sysinst UX changes
On Mon, Nov 09, 2020 at 11:15:52PM +0100, Vincent DEFERT wrote: > On 09/11/2020 21:49, m...@netbsd.org wrote: > > Unfortunately it leads to surprise failures if programs ever use > > /dev/random. If not seeded, reads from it will block forever. > If it has such consequences, the installer - or maybe a 'first-run' startup > script? - should of course take care of it. > That said, UX aside, a human being is certainly the less appropriate > "device" to properly handle such a computer-centric task. This discussion started about the INSTALLER doing it. Joerg
Re: recent sysinst UX changes
On 09/11/2020 21:49, m...@netbsd.org wrote: Unfortunately it leads to surprise failures if programs ever use /dev/random. If not seeded, reads from it will block forever. If it has such consequences, the installer - or maybe a 'first-run' startup script? - should of course take care of it. That said, UX aside, a human being is certainly the less appropriate "device" to properly handle such a computer-centric task.
Re: recent sysinst UX changes
On Mon, Nov 09, 2020 at 09:53:50AM -0500, Mouse wrote: > > So: happy to make it more userfriendly, simpler, rephrase messages, > > whatever needed - but we should not end up with insecure installs. > > Lack of good randomness does not quite equal insecure install. Warn > about it, sure, but I think *requiring* randomness is a bad idea. For > example, I've been working with recent NetBSD at work, for something > for which the presence or absence of good random-seed data makes > absolutely no difference to security. Unfortunately it leads to surprise failures if programs ever use /dev/random. If not seeded, reads from it will block forever. So far we've seen: - Firefox refusing to start - Python having problems And some more things that have been patched not to use /dev/random.
Re: recent sysinst UX changes
On Mon, Nov 09, 2020 at 10:10:56AM +, nia wrote: > i run into it on real hardware, thinkpad t60. > > my preference is: > > - when booting in a VM, if there is no RNG device attached, > the system should print a warning with instructions on how > to attach the device. In practice this means running in Qemu I guess? For all machines there is the possibility virtio-rng device as per spec (is there another?) and mentioned in the virtio bounty on tech-kern@. For x86_64 aka AMD64, the situation can be a lot easier. When running Qemu on an recent host using NVMM, the RDRANDOM instruction is not trapped and will use the hosts entropy. I've checked this with installing the 9.99.75 installation CD and installing on a harddisc. At no time i've been asked for entropy. So apparently when using qemu+nvmm new installs automatically get good entropy to start with. Reinoud
Re: XEN help needed
Hi Paul, > I've got a XEN3_DOMU virtual machine currently running NetBSD 8.1, and > hosted on a commercial provider (www.prgmr.com). Since I'm running > 8.1 I think that implies that I'm running in HVM mode? most NetBSD's on prgmr running in PV mode currently as far as I understood (at least, mine does) > Anyway, the provider will soon be upgrading their host to a PVHVM-only > environment. That means that I need to upgrade, to -current. not really. I was in touch with them and the original background is XSA-286, which affects PV DomU's and the recommended mitigation is to use HVM. There are patches to fix XSA-286 also for PV, but some have performance impact, some not, some may not fix it completely etc. Nevertheless, prgmr's approach to get rid of PV's eliminates the problem with xsa-286. [snip] > > I'm really reluctant to update my userland at this time unless it is > absolutely necessary. prgmr did not force me to go HVM as I remarked, I'm running NetBSD and want to stay on NetBSD for the time being until PVHVM is on a release and I'm fully aware of XSA-286. At least, this was my understanding ;-) Furthermore, they are planning a couple of AMD based Dom0 systems, which should behave differently and a move of NetBSD-PV-DomUs may happen once those systems are ready for service. cheers Martin
Re: XEN help needed
> Hello all you XEN experts! > > I've got a XEN3_DOMU virtual machine currently running NetBSD 8.1, and > hosted on a commercial provider (www.prgmr.com). Since I'm running > 8.1 I think that implies that I'm running in HVM mode? I'm running 8.1_STABLE on PRGMR, and I'm running PV. They have a menu item on their console interface to provide "system details", which should confirm it for you. > Anyway, the provider will soon be upgrading their host to a PVHVM-only > environment. That means that I need to upgrade, to -current. The last message I got from them on the subject wasn't completely clear, but it sounded like they thought they could adjust a couple things, move us to new hardware, and things would go on as normal. So I'd follow up with PRGMR support before doing anything. Gary > So, a few questions. (I'm a really dummy when it comes to XEN, so > please forgive me if the questions don't make sense! Where's my copy > of O'Reilly's ``XEN For Dummies'' when I need it? :) ) > > 1. Since I'm switching to PVHVM, will there be any differences in the > "visible" devices? Will I need to update my kernel config? Or > will a -current XEN3_DOMU kernel work "out of the box"? > > 2. Will I be able to update only my kernel, and continue running my > 8.1 userland? > > 3. Will I need to make any configuration changes to things in /etc ? > > I'm really reluctant to update my userland at this time unless it is > absolutely necessary. > > Thanks in advance for any advice you can offer. > > > > ++--+---+ > | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | > | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | > | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | > ++--+---+ >
XEN help needed
Hello all you XEN experts! I've got a XEN3_DOMU virtual machine currently running NetBSD 8.1, and hosted on a commercial provider (www.prgmr.com). Since I'm running 8.1 I think that implies that I'm running in HVM mode? Anyway, the provider will soon be upgrading their host to a PVHVM-only environment. That means that I need to upgrade, to -current. So, a few questions. (I'm a really dummy when it comes to XEN, so please forgive me if the questions don't make sense! Where's my copy of O'Reilly's ``XEN For Dummies'' when I need it? :) ) 1. Since I'm switching to PVHVM, will there be any differences in the "visible" devices? Will I need to update my kernel config? Or will a -current XEN3_DOMU kernel work "out of the box"? 2. Will I be able to update only my kernel, and continue running my 8.1 userland? 3. Will I need to make any configuration changes to things in /etc ? I'm really reluctant to update my userland at this time unless it is absolutely necessary. Thanks in advance for any advice you can offer. ++--+---+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | ++--+---+
Re: recent sysinst UX changes
> So: happy to make it more userfriendly, simpler, rephrase messages, > whatever needed - but we should not end up with insecure installs. Lack of good randomness does not quite equal insecure install. Warn about it, sure, but I think *requiring* randomness is a bad idea. For example, I've been working with recent NetBSD at work, for something for which the presence or absence of good random-seed data makes absolutely no difference to security. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Side effects when taring up /dev
Hi, I observed some weird behavior when I ran tar on a filesystem with a /dev directory. I ran the equivalent of: (cd / && tar -cf - . ) | (cd /somewhere && tar -xpf - ) and got the following error messages: tar: Couldn't list extended attributes: Invalid argument tar: Couldn't list extended attributes: Invalid argument tar: Couldn't list extended attributes: Invalid argument tar: Couldn't list extended attributes: Invalid argument tar: Couldn't list extended attributes: Invalid argument tar: Couldn't list extended attributes: Invalid argument On the console, I got: [ 72536.9865017] cd0: sector size 0 [ 72537.0265040] cd0: sector size 0 [ 72633.4720213] tap0: detached and then the console would no longer accept any input. I had to hup the getty process to get it going again. This was on a Sun Enterprise 450 Ultrasparc system, with a real CD player installed, and a real serial port console. I tried something similar on a Xen/amd64 VM running NetBSD 9.99.75. A simple (cd /dev && tar -cf /dev/null ./tap) gave similar error messages from tar, and the console message: [ 454.6728584] tap0: detached It seems that tar opens the ./tap device and then tries to retrieve some acl attributes. I speculate that somehow this again causes a tap0 device to be created, and then shortly deleted again. Should tar really open a device node like this? Many devices will "do stuff" on open, and I would say it is not expected that running tar in a directory with device nodes should change the system state like that. -jarle -- There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors.
Automated report: NetBSD-current/i386 build success
The NetBSD-current/i386 build is working again. The following commits were made between the last failed build and the successful build: 2020.11.09.10.19.18 martin src/share/mk/bsd.prog.mk,v 1.334 2020.11.09.10.19.41 martin src/usr.sbin/makemandb/Makefile,v 1.11 Logs can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2020.11.html#2020.11.09.10.19.41
Re: recent sysinst UX changesg
On Mon, Nov 09, 2020 at 11:03:31AM +, nia wrote:
> On Mon, Nov 09, 2020 at 11:18:31AM +0100, Martin Husemann wrote:
> > On Mon, Nov 09, 2020 at 10:10:56AM +, nia wrote:
> > > fwiw, i think the default options should be as close to Just Work as
> > > possible.
> > >
> > > i have installed NetBSD irl with people who have only a little bit of unix
> > > knowledge, and watched them wince every time something doesn't go as
> > > planned.
> > > often this is on older, spare hardware, that's just to play with the OS
> > > on,
> > > so it is likely to not have >2015 CPU features (RDRAND).
> >
> > I totaly agree with both of this, but "just work" is not a clear target,
> > especially when a simple step makes a difference in security (whether
> > manually typing in random things *does* make a difference is probably
> > for another debate).
> >
> > The description pointing at copying output from another machine is just
> > an option (and it actually helps a lot when you do installs via serial
> > console or similar).
> >
> > So: happy to make it more userfriendly, simpler, rephrase messages,
> > whatever needed - but we should not end up with insecure installs.
> >
> > Martin
>
> Requiring users to type in data is just going to result in a lot of
> users mashing the keyboard to get an install to work, is all I'm saying.
> That's no better than copying 32 bytes back into /dev/urandom to continue
> with the existing seed. The installation involves user input, after all.
>
> Treating USB RNGs as a common use case for everyday installs is an odd
> decision. They're probably common to have among a subset of NetBSD
> developers, and, well, nobody else.
>
> +{This system seems to lack a cryptographically strong pseudo random
> +number generator. There is not enough entropy available to create secure
> +keys (e.g. ssh host keys).
> +
> +You may use random data generated on another computer and load it
> +here, or you could enter random characters manually.
> +
> +If you own a USB random number device, connect it now and select
> +the "Re-test" option.}
>
> I would change this to:
>
> "{This system seems to lack a quality hardware random number generator.
>
> For increased system security, you may load random data generated
> on another computer. NetBSD will then use this as a seed.
>
> Otherwise, the installer can continue with a potentially insecure
> seed using data collected during the installation process.}"
>
> +message entropy_continue {Continue with existing potentially insecure
> seed}
> +message entropy_download_seed{Import random data from another
> machine}
>
> Lacking a HWRNG is the actual problem. Let's describe the actual problem.
> I don't think we need to present every new user installing NetBSD with
> information about USB RNG devices or crypto jargon.
By the way,
My thinkpad t60 has an audio dac. It has inputs. Audio DACs physically produce
random noise.
Since this is sysinst, power consumption concerns about sampling from
the DAC don't apply: Enable all inputs in sysinst, set gain to max, read 32
bytes from /dev/audio, return to normal state.
There's really no reason at all for this hardware to have entropy problems.
Re: recent sysinst UX changes
On Mon, Nov 09, 2020 at 11:03:31AM +, nia wrote: > On Mon, Nov 09, 2020 at 11:18:31AM +0100, Martin Husemann wrote: > > On Mon, Nov 09, 2020 at 10:10:56AM +, nia wrote: > > > fwiw, i think the default options should be as close to Just Work as > > > possible. > > > > > > i have installed NetBSD irl with people who have only a little bit of unix > > > knowledge, and watched them wince every time something doesn't go as > > > planned. > > > often this is on older, spare hardware, that's just to play with the OS > > > on, > > > so it is likely to not have >2015 CPU features (RDRAND). > > > > I totaly agree with both of this, but "just work" is not a clear target, > > especially when a simple step makes a difference in security (whether > > manually typing in random things *does* make a difference is probably > > for another debate). > > > > The description pointing at copying output from another machine is just > > an option (and it actually helps a lot when you do installs via serial > > console or similar). > > > > So: happy to make it more userfriendly, simpler, rephrase messages, > > whatever needed - but we should not end up with insecure installs. > > > > Martin > > Requiring users to type in data is just going to result in a lot of > users mashing the keyboard to get an install to work, is all I'm saying. ...which is actually a completely reasonable method. Heck, it's how people have been using PGP for decades. Joerg
Re: recent sysinst UX changes
On Mon, Nov 09, 2020 at 11:18:31AM +0100, Martin Husemann wrote:
> On Mon, Nov 09, 2020 at 10:10:56AM +, nia wrote:
> > fwiw, i think the default options should be as close to Just Work as
> > possible.
> >
> > i have installed NetBSD irl with people who have only a little bit of unix
> > knowledge, and watched them wince every time something doesn't go as
> > planned.
> > often this is on older, spare hardware, that's just to play with the OS on,
> > so it is likely to not have >2015 CPU features (RDRAND).
>
> I totaly agree with both of this, but "just work" is not a clear target,
> especially when a simple step makes a difference in security (whether
> manually typing in random things *does* make a difference is probably
> for another debate).
>
> The description pointing at copying output from another machine is just
> an option (and it actually helps a lot when you do installs via serial
> console or similar).
>
> So: happy to make it more userfriendly, simpler, rephrase messages,
> whatever needed - but we should not end up with insecure installs.
>
> Martin
Requiring users to type in data is just going to result in a lot of
users mashing the keyboard to get an install to work, is all I'm saying.
That's no better than copying 32 bytes back into /dev/urandom to continue
with the existing seed. The installation involves user input, after all.
Treating USB RNGs as a common use case for everyday installs is an odd
decision. They're probably common to have among a subset of NetBSD
developers, and, well, nobody else.
+{This system seems to lack a cryptographically strong pseudo random
+number generator. There is not enough entropy available to create secure
+keys (e.g. ssh host keys).
+
+You may use random data generated on another computer and load it
+here, or you could enter random characters manually.
+
+If you own a USB random number device, connect it now and select
+the "Re-test" option.}
I would change this to:
"{This system seems to lack a quality hardware random number generator.
For increased system security, you may load random data generated
on another computer. NetBSD will then use this as a seed.
Otherwise, the installer can continue with a potentially insecure
seed using data collected during the installation process.}"
+message entropy_continue {Continue with existing potentially insecure
seed}
+message entropy_download_seed {Import random data from another machine}
Lacking a HWRNG is the actual problem. Let's describe the actual problem.
I don't think we need to present every new user installing NetBSD with
information about USB RNG devices or crypto jargon.
Oddball small memory qemu images and networking
Hi folks, On Mon, May 18, 2020 at 09:41:17PM +, Andrew Doran wrote: > Finally got around to trying this. Having beaten on it for a while with > real hardware I don't see any problem with swapping over NFS on 9.99.63. > > On Sat, May 02, 2020 at 12:06:48PM +1000, Paul Ripke wrote: > > > I have a qemu guest for experimenting with -current, 1 CPU & 64MiB RAM. > > 64 megs, I'm surprised it makes to the login prompt. I can get a prompt and compile some stuff locally in 48 MiB but no network until sat 80 MiB. As a challenge I tried a bog standard GENERIC 9.99.69/amd64 on qemu with small amounts of memory with a `harddisc' including a swap space. I increased the memory size in steps of 2 MiB. With one CPU 40 MiB boots but fsck_ffs killed due to out of swap; swap is later? 42 MiB booted to multiuser, mount_ffs failing 44 MiB booted to multiuser but is bog slow due to swap, no dhcpcd 46 MiB booted to multiuser fine, usable, no dhcpcd ... 66 MiB booted to multiuser fine, dhcpcd sometimes works ... 80 MiB booted to multiuser fine, dhcpcd works reliable With 2 CPUs : 44 MiB doesn't boot and creates a panic in pmap_get_physpage() 46 MiB booted to multiuser but slowish due to swapping 48 MiB booted to multiuser fine, more usable, no dhcpcd ... 54 MiB booted to multiuser fine, dhcpcd sporadically works ... 60 MiB booted to multiuser fine, dhcpcd sometimes works ... 70 MiB booted to multiuser fine, dhcpcd mostly works ... 80 MiB booted to multiuser fine, dhcpcd works reliable Network buffers are thus limiting its useability in such odd small memory systems even though swap is available; the kernel can't allocate memory for SIOCAOFADDR when done manually. Its strange that it sometimes succeeds though! Not useless though as without network, a 1 CPU machine can already compile on a 48Mb machine on FFS. Note that on very low memory (60MiB) I can compile programs hosted over NFS (when dhcpcd works) though SIGINFO can print odd stuff like: [ 174.2806880] load: 0.48 cmd: cc1 3164 [0x693f93fb] 0.00u 267344117007.14s 1% 9572k When compiling on bigger, say 80MiB it prints normal times. Hope this was of help, Reinoud
Re: recent sysinst UX changes
On Mon, Nov 09, 2020 at 10:10:56AM +, nia wrote: > fwiw, i think the default options should be as close to Just Work as possible. > > i have installed NetBSD irl with people who have only a little bit of unix > knowledge, and watched them wince every time something doesn't go as planned. > often this is on older, spare hardware, that's just to play with the OS on, > so it is likely to not have >2015 CPU features (RDRAND). I totaly agree with both of this, but "just work" is not a clear target, especially when a simple step makes a difference in security (whether manually typing in random things *does* make a difference is probably for another debate). The description pointing at copying output from another machine is just an option (and it actually helps a lot when you do installs via serial console or similar). So: happy to make it more userfriendly, simpler, rephrase messages, whatever needed - but we should not end up with insecure installs. Martin
Re: recent sysinst UX changes
fwiw, i think the default options should be as close to Just Work as possible. i have installed NetBSD irl with people who have only a little bit of unix knowledge, and watched them wince every time something doesn't go as planned. often this is on older, spare hardware, that's just to play with the OS on, so it is likely to not have >2015 CPU features (RDRAND). On Mon, Nov 09, 2020 at 06:51:47AM +0100, Martin Husemann wrote: > On Sun, Nov 08, 2020 at 05:32:16PM +, nia wrote: > > after several changes in 9.1 and -current, it's strange to me that the > > option > > that I expect is the most popular for installing NetBSD (start over, fresh > > partitions, use the whole disk) is no longer the default option: > > It never was and I am not sure it should be. This option actually > is brand new and never was offered before this explicitly. > > I don't have a strong opinion on order of options and defaults though, > at this stage in an installer that offers to destroy all of your disk > you should be thinking twice what you select. thing is, "Want to install NetBSD? This might damage your disk and you should make a backup and think twice..." is already a dialog that appear prior to this one (with the default being no). the default option may be broken for a preexisting Linux/Windows GPT table, and the current wording makes it sound like you should only pick the "delete everything" option if you want to change the partitioning system to a different one (not GPT). it's also not clear, to a new user, what the difference between "use default partition sizes" and "delete everything" is. it's not clear to me :/ > > > while inputting entropy by hand isn't something i would consider > > acceptable to expose to everyday users of a modern operating system > > in the first place, the suggestion that they might use coin tosses > > makes the entire thing feel like a big joke (and in general the dialog > > is overly complicated). > > I am open to concrete suggestions how to improve things here. > Note that most users on real machines never should see this dialog > and that manual input is only one of a few options available. > > I feel the whole thing is a bad pain, but either something like this > or we will end up with insecure/incomplete installations. > > Martin i run into it on real hardware, thinkpad t60. my preference is: - when booting in a VM, if there is no RNG device attached, the system should print a warning with instructions on how to attach the device. - "Continue with possibly insecure RNG state" should be an available option that writes 32 bytes from urandom to random. The act of performing an installation should involve user input that is difficult for an adversary to predict, if not scientifically provably secure... the thinkpad has onboard devices that generate data that might not be provably random, but is near practically unpredictable, including various fan sensors and an audio DAC with inputs (hey, the installer could even set these to max gain...) is a typical new user, such as described above, likely to have another NetBSD machine to serve an entropy file over ftp with? no, they're going to spam on the keyboard. whose security is this helping?
Re: benchmark results on ryzen 3950x with netbsd-9, -current, and -current (no DIAGNOSTIC)
On Sat, Nov 07, 2020 at 06:12:34PM +1100, matthew green wrote: > this is an update on my previous testing. i've excluded > amd64 release builds from this set, takes too long ;) Indeed remarkable! I assume you build the same source tree on the various versions? Did you use the benchmarking stuff that was done on the SoC or did you do it `manually' ;) I am curious as to what is AMD64 specific ie how the speeds are comparing on say a big Sparc64 or an beefy AArch64 system in the cloud. My guess is that less memory is going to haunt them since harddiscs and the like are going to hinder good performance more than code enhancements. Thanks a lot for testing! Reinoud
Re: Automated report: NetBSD-current/i386 build failure
The NetBSD Test Fixture wrote: > nbmake[7]: nbmake[7]: don't know how to make -ltermlib. Stop The build is still failing. The problems started with this commit: 2020.11.08.21.56.47 nia src/external/bsd/kyua-cli/Makefile.inc,v 1.8 2020.11.08.21.56.47 nia src/external/ibm-public/postfix/Makefile.inc,v 1.25 2020.11.08.21.56.48 nia src/external/public-domain/sqlite/Makefile.inc,v 1.9 2020.11.08.21.56.48 nia src/external/public-domain/sqlite/bin/Makefile,v 1.7 2020.11.08.21.56.48 nia src/external/public-domain/sqlite/lib/Makefile,v 1.12 2020.11.08.21.56.48 nia src/external/public-domain/sqlite/lib/sqlite3.pc.in,v 1.3 2020.11.08.21.56.48 nia src/usr.sbin/makemandb/Makefile,v 1.10 -- Andreas Gustafsson, g...@gson.org
