Re: NetBSD installer failure

[Al Zick]

Hello,

On Mar 3, 2017, at 5:13 PM, Swift Griggs wrote:


On Fri, 3 Mar 2017, Al Zick wrote:
http://datazap.net/sites/14/hang.jpg Does anyone have any ideas as  
to why?


It's hard to say, but it looks like it's failing right before the  
real root file system is mounted. Did you have them try without SMP  
and ACPI ? You can disable those from the bootloader.


Sometimes it's useful to setup NetBSD on a USB drive (ie.. do a  
full installation etc..). Then I put some alternate kernels on the  
file system and one of them I'll have a full debug kernel built  
that I can boot up on and (hopefully) get an idea of why/where- 
exactly the failure is occurring. You could probably do that and  
create a 2G or 4G image for your data center hands & eyes folks to  
rawrite to a USB drive and boot up the server on. Then FTP /  
dropbox it to them etc...


I ended up going to the data center where these servers are at and  
trying a thumb drive, but no matter what I did it locked up at the  
same place. Not really sure why. We ended up moving the SSDs to the  
old servers that we had a few months ago. I plugged in the thumb  
drive and NetBSD booted up. All the servers have SuperMicro  
motherboards, although the ones we moved back to are a different  
revision. Still, it leaves a lot of unanswered questions.


Kind Regards,
Al

Re: x86_64 hardware recommendations/warnings?

[Aaron B.]

On Mon, 13 Mar 2017 16:27:13 -0600 (MDT)
Swift Griggs  wrote:

> BeOS used to have this site (way way back in the day) called BeOS Hardware 
> Compatilibity Matrix. Folks would contribute short reviews for working 
> hardware. I found it invaluable.

I've often considering building something like this, as it wouldn't be
much more than a set of basic CRUD pages.

Never got around to even starting it, though, as I'm both short on time
and uncertain if anyone would make use of it.

-- 
Aaron B. 

Re: x86_64 hardware recommendations/warnings?

[Swift Griggs]

On Mon, 13 Mar 2017, John D. Baker wrote:
I find myself in the position of recommending components for a friend to 
build a more up-to-date machine on which to run NetBSD.


I wish you luck. I've been using NetBSD since 1996 and, though I'm a huge 
fan, I have never found a great method to find "known good" *systems* with 
NetBSD. You can easily find known-good components by looking at various 
man pages for the drivers. Ie.. I look up the mobo then look at each 
problematic chipset and go digging to see if drivers are there. When I say 
problematic, I mean network, usb, and sound chipsets.


The other method I use is component based. I'll check pcidevs, usbdevs, 
etc... and then lookup the PCI IDs and find out if they are supported that 
way. This is sometimes tough because you don't always know what a given 
bit of kit will show up as (PCI ID). It's also easy to get it wrong when 
they release a "v2" of the same card.


BeOS used to have this site (way way back in the day) called BeOS Hardware 
Compatilibity Matrix. Folks would contribute short reviews for working 
hardware. I found it invaluable.


It's wierd, you get *great* hardware info from all the non-x86 ports, but 
then again, they have a lot smaller surface area to cover. So, it's no 
surprise.



 Intel or AMD Radeon graphics


Lately my experience has been that if your Intel graphics are supported in 
Linux KMS 1.3 code they will work great in NetBSD 7.x. I have a number of 
Radeon cards (newest is R9 Nano) and most do work, also. However, I care 
mostly about 2D performance and they can't beat my onboard video in 
gtkperf, so I only use those in gaming machines now. My i7 with built-in 
Intel graphics does all tests in 1.8 seconds. Drop the Radeon R9 Nano in 
and it goes up to 4.5 seconds.


At this stage Intel vs. AMD is not so important as knowing what is 
supported and will work.


I avoid motherboards with AMD chipsets. It's mostly just superstition, 
though. I had a helluva time with USB on those under NetBSD 6. They 
basically never worked well enough for everyday on my AMD hardware. After 
having the same experience on every other AMD mobo after that point, I 
basically gave up since the Intel boards would "just work".



In the back of my mind always is the problem:  "new but not TOO new".


That's spot on.

As UEFI support is only now taking shape in -current, is anyone aware of 
boards which don't support "Legacy Boot" or "Compatibility Support 
Mode"?


Well, once they do it on HP DL & Dell servers, you can bet it'll start 
happening everywhere. So far, they still support "Legacy" mode in their 
latest generations (G9 etc..).


What is known about whether the intel DRM/KMS support in Netbsd-7.1 will 
work with these?  The associated driver for Xorg?


The KMS driver version is what you are looking for. NetBSD 7 uses KMS 1.3, 
unless I'm mistaken.



 If they work at all, how do they fare when playing video?


Fantastic. XVideo support seems fully baked and works quite well. On the 
flipside getting things like vdpau to work may be more challenging. I 
dunno.


What is known about the radeondrmkms support for these parts?  The 
associated driver for Xorg?


It's the same. It's all tied to the KMS version.

If it turns out that the on-board video options are not suitable, the 
obvious solution is some sort of Radeon-based add-in video card.


That or an nVidia card. Some of those work with the Nouveau driver. I have 
an old GT9800 I got used that works with that driver even under NetBSD 
6.x. The Radeon 9800 is also another can't miss card but it's old, has 
slow 3D, fairly low memory, etc... However, that card works with the 
regular old X11 drivers we've had for eons. It really depends on if you 
want to get good 3D performance.


Given the above, are there recommendations for things that are new 
(available) but not TOO new (unsupported)?


Man, it really depends on the type of things they will be doing with the 
machine. What I do before I buy a new rig is to load NetBSD onto a USB 
drive (as in, do a full install with X11). Then I go to my local computer 
store (Microcenter is the best in my area, unfortunately) and I tell the 
sales guy exactly what I want to do and why and explain it won't hurt his 
machines. Then I start testing all the machines I'm interested. I just 
boot them up, check the sound device (make sure it's not one of those 
PoS's that want to route all the sound down the HDMI interface by default) 
then make sure it plays clean. Then check the NIC, wifi, and finally give 
the graphics a try with an intrepid "startx" to see what happens. Then 
you'll know for sure the hardware works before you even go through the 
trouble of buying & returning gear.



Or conversely, warnings of what to avoid?


I avoid Ralink wifi (they always die/offline on me), Realtek NICs (due to 
crap iperf performance and occasional hardware flaws), and anything as you 
put it "too new" on the graphics front.


YMMV.

-Swift

x86_64 hardware recommendations/warnings?

[John D. Baker]

I find myself in the position of recommending components for a friend
to build a more up-to-date machine on which to run NetBSD.  Having only
been seriously interested in non-PC hardware and otherwise being a
technological bottom-feeder in the PC-type hardware arena, I'm feeling
a bit overwhelmed at the options available and the things one must know
to wade through them.

Background:  Currently using a Dell PowerEdge SC430 as a workstation.
Primary tasks are photographic scanning and digital post-processing,
some audio processing, personal accounting/recordkeeping, and web
browsing, likely with light video usage.  Using NetBSD/amd64-7.1_RC2
and packages from pkgsrc-2016Q4.

The bare-bones graphics on the above machine is the primary problem.
User has a desire to use a large flat-panel TV as the computer display,
but the machine cannot accept an add-in video card with HDMI outputs
and VGA->HDMI adapters are considered unacceptably expensive.

I proposed the following recommendations for a more modern machine:

  PS/2 keyboard port required
  3.0+GHz Quad-core processor
  8+GB RAM
  Intel or AMD Radeon graphics
at least with DVI
DisplayPort if possible
HDMI nice but not required
  associated storage/media devices and other accessories.

Browsing a major online vendor of such components, there are a great
many mainboards from which to choose.  At this stage Intel vs. AMD
is not so important as knowing what is supported and will work.

In the back of my mind always is the problem:  "new but not TOO new".

As UEFI support is only now taking shape in -current, is anyone aware
of boards which don't support "Legacy Boot" or "Compatibility Support
Mode"?  The system needs to be able to boot a stock NetBSD/amd64-7.1
installation.

The Intel-based mainboards I've seen all have on-board graphics, typically
with all of VGA/DVI/HDMI (and sometimes DisplayPort) outputs, but are
dependent on the CPU die also bearing the GPU/graphics engine.  Such
processors seem to be 6th/7th-generation Core i3/5/7.  What is known
about whether the intel DRM/KMS support in Netbsd-7.1 will work with
these?  The associated driver for Xorg?  If they work at all, how do
they fare when playing video?

I see similar things with boards for AMD processors.  I think boards
for Socket AM3+ processors actually have an independent graphics chip
on them (most commonly Radeon HD 3000), while boards for Socket FM2+
processors use the GPU on the CPU die.  What is known about the
radeondrmkms support for these parts?  The associated driver for Xorg?

If it turns out that the on-board video options are not suitable,
the obvious solution is some sort of Radeon-based add-in video card.

Given the above, are there recommendations for things that are
new (available) but not TOO new (unsupported)?

Or conversely, warnings of what to avoid?  Note that there is no
real budget for this machine other than to cost the least possible
while meeting the above requirements.

Thanks.

-- 
|/"\ John D. Baker, KN5UKS   NetBSD Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]comOpenBSDFreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

Re: Installing FF 52 from pkgsrc: "stable" version instead of nightly

[Cág]

Marco Beishuizen wrote:

> I'm experiencing the same problems on the ESR versions. So I'm guessing 
> it's a specific i386 problem and not a version problem. It's also not a 
> recent problem but happening for several months now.

I recall the same thing on the first day after building FF45 (on amd64); it
doesn't appear anymore for some reason. No data corruption, just core
dumps.

--
Cág

Re: Installing FF 52 from pkgsrc: "stable" version instead of nightly

[Robert Elz]

A Vague memory from the distant past suggests that the thing to try
is to move aside the .mozilla directory, and allow the new firefox
to start in a completely clean environment.

I kind of recall that continuous startup problems, which only affect some
users, tend to be related to data somewhere in there (I have no idea which
data) something isn't the way the new version expects it, and all kinds
of problems ensue.

If your old version is still working, you should probably have it export
everything possible that you can first (bookmarks, etc) so that if the
new one works in a clean environment you can import as much of what
you'd hope to retain as possibble.

Of course, this might all be a red herring, so don't destroy the old
.mozilla directory, just move it, so it coudl be replaced if this turns
out not to be the problem (also so that it can be replaced if you decide
to revert to the old version.)

kre

Re: Installing FF 52 from pkgsrc: "stable" version instead of nightly

[scole_mail]

"J. Lewis Muir"  writes:
>
> Do you actually use that version for everyday use?  According to [1],
> there are many security vulnerabilities that have been fixed since
> Firefox 47, and I would bet many of those vulnerabilities exist in
> Firefox 47.  That's OK to you?
>

Yes, I use it everyday.  It's not ok to me, but I realize the security
risk and feel there aren't other good browser options.

I also realize NetBSD is a volunteer project, and I'm not trying to
denigrate anyone, but there are lots of other vulnerabilities in stable
pkgsrc now.

At the moment, I've got about ~270 packages installed with about 100
different vulnerabilities, so having a few for a working firefox doesn't
seem like a big deal.

Kind Regards


>lintpkgsrc  -i 
Scan Makefiles: ..
Bogus: ${DISTNAME:tl:S/_pl//}-0.1 (from 
/usr/pkgsrc/devel/calltree-perl/Makefile)

Bogus: ${KBUILDNAME:tl}-0.1.9998.8.2814.25 (from 
/usr/pkgsrc/devel/kbuild/Makefile)
14960 packages
Version mismatch: 'firefox' 47.0.1 vs 50.1.0


Installed vulnerable packages:
Package jpeg-9b has a multiple-vulnerabilities vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-3616
Package jasper-1.900.29nb1 has a unspecified vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9560
Package jasper-1.900.29nb1 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5498
Package jasper-1.900.29nb1 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5499
Package jasper-1.900.29nb1 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5500
Package jasper-1.900.29nb1 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5501
Package jasper-1.900.29nb1 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5502
Package jasper-1.900.29nb1 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5503
Package jasper-1.900.29nb1 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5504
Package openjpeg-2.1.2 has a null-pointer-bug vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9114
Package openjpeg-2.1.2 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9117
Package openjpeg-2.1.2 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9115
Package openjpeg-2.1.2 has a buffer-overflow vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9118
Package openjpeg-2.1.2 has a null-pointer-bug vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9113
Package openjpeg-2.1.2 has a null-pointer-bug vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9116
Package openjpeg-2.1.2 has a floating-point-exception vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-9112
Package libarchive-3.2.1nb2 has a denial-of-service vulnerability, see 
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-5601
Package libarchive-3.2.1nb2 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-8689
Package libarchive-3.2.1nb2 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-8687
Package libarchive-3.2.1nb2 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-8688
Package pcre-8.39 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-6004
Package policykit-0.9nb20 has a integer-overflow vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-4625
Package policykit-0.9nb20 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3218
Package policykit-0.9nb20 has a privilege-escalation vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3255
Package policykit-0.9nb20 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3256
Package zziplib-0.13.59 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5974
Package zziplib-0.13.59 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5975
Package zziplib-0.13.59 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5976
Package zziplib-0.13.59 has a denial-of-service vulnerability, see 
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2017-5977
Package zziplib-0.13.59 has a denial-of-service 

Re: Installing FF 52 from pkgsrc: "stable" version instead of nightly

[Onno van der Linden]

On Mon, Mar 13, 2017 at 05:11:59PM +0100, Marco Beishuizen wrote:
> On Mon, 13 Mar 2017, the wise co...@sdf.org wrote:
> 
> > Mozilla maintains an 'Extended Support Release' which has security fixes
> > backported to it, so it will be a better choice for such cases.
> > Currently, it is www/firefox45 - it is updated whenever www/firefox is,
> > containing fixes for the same vulnerabilities. Soon firefox52 (current
> > non-ESR version) will become ESR.
> 
> I'm experiencing the same problems on the ESR versions. So I'm guessing it's
> a specific i386 problem and not a version problem. It's also not a recent
> problem but happening for several months now.

FWIW, I'm running current on a pretty old (Asus P4B533, P4 2.26GHz 2Gb mem)
machine. Had one (known) problem with FF 51 that created coredumps
at exit time. That bug is fixed in FF 52. Another problem with
certain recent FF versions (the ones after FF 45 where gfx.xrender.enabled
changed to false by default) was that when visiting a site with huge
images the xorg process suddenly got to (and stayed at) 80% CPU or so.

At the moment both FF 45 (compiled with GTK2) and FF 52 (compiled with GTK3)
work fine for me on everything I throw at it.

Onno

Re: Installing FF 52 from pkgsrc: "stable" version instead of nightly

[Marco Beishuizen]

On Mon, 13 Mar 2017, the wise co...@sdf.org wrote:

Mozilla maintains an 'Extended Support Release' which has security fixes 
backported to it, so it will be a better choice for such cases. 
Currently, it is www/firefox45 - it is updated whenever www/firefox is, 
containing fixes for the same vulnerabilities. Soon firefox52 (current 
non-ESR version) will become ESR.


I'm experiencing the same problems on the ESR versions. So I'm guessing 
it's a specific i386 problem and not a version problem. It's also not a 
recent problem but happening for several months now.


Regards,
Marco

--
... a thing called Ethics, whose nature was confusing but if you had it you
were a High-Class Realtor and if you hadn't you were a shyster, a piker and
a fly-by-night.  These virtues awakened Confidence and enabled you to handle
Bigger Propositions.  But they didn't imply that you were to be impractical
and refuse to take twice the value for a house if a buyer was such an idiot
that he didn't force you down on the asking price.
-- Sinclair Lewis, "Babbitt"

Re: Installing FF 52 from pkgsrc: "stable" version instead of nightly

[Marco Beishuizen]

On Mon, 13 Mar 2017, the wise Martin Husemann wrote:

If anyone has receipes to easily make it crash, please send-pr! 
Debugging often is simple, if you can reproduce it.


I'll fire off an i386 build with debug info tonight...


I'm unable to pinpoint the problem because FF crashes on every site it 
opens and after a few seconds of use, even on the preferences and add-ons 
windows.


Regards,
Marco

--
TO THOSE OF YOU WHO DESIRE IT, I GRANT YOU MADRAK'S BLESSING:

Insofar as I may be heard by anything, which may or may not care
what I say, I ask, if it matters, that you be forgiven for anything you
may have done or failed to do which requires forgiveness.
Conversely, if not forgiveness but something else be required
to insure any possible benefit for which you may be eligible after the
destruction of your body, I ask that this, whatever it may be, be granted
or withheld, as the case may be, in such a manner as to insure your
receiving said benefit.
I ask this in my capacity as your elected intermediary between
yourself and that which may have an interest in the matter of your receiving
as much as it is possible for you to receive of this thing, and which may
in some way be influenced by this ceremony.
Amen.
-- Roger Zelazny, "Creatures of Light and Darkness", 1969

Re: Installing FF 52 from pkgsrc: "stable" version instead of nightly

[coypu]

On Mon, Mar 13, 2017 at 10:24:44AM -0500, J. Lewis Muir wrote:
> On 03/11, scole_mail wrote:
> > Marco Beishuizen  writes:
> > >
> > > It's on NetBSD/i386 7.0.2.
> > 
> > I guess I've also been having that same issue on i386 for awhile.  The
> > last stable version that worked for me was firefox-47.0.1 which was in
> > pkgsrc-2016Q2 I believe.  So I've been using that version.
> 
> Do you actually use that version for everyday use?  According to [1],
> there are many security vulnerabilities that have been fixed since
> Firefox 47, and I would bet many of those vulnerabilities exist in
> Firefox 47.  That's OK to you?

Mozilla maintains an 'Extended Support Release' which has security
fixes backported to it, so it will be a better choice for such cases.
Currently, it is www/firefox45 - it is updated whenever www/firefox is,
containing fixes for the same vulnerabilities.
Soon firefox52 (current non-ESR version) will become ESR.

Re: Installing FF 52 from pkgsrc: "stable" version instead of nightly

[Martin Husemann]

If anyone has receipes to easily make it crash, please send-pr!
Debugging often is simple, if you can reproduce it.

I'll fire off an i386 build with debug info tonight...

Martin

Re: rcorder (/etc/rc.d/openvpn)

[Robert Elz]

Date:Mon, 13 Mar 2017 09:15:51 +0100
From:=?UTF-8?Q?BERTRAND_Jo=c3=abl?= 
Message-ID:  <014dcf45-1e27-618c-4aa1-6f1651f76...@systella.fr>

  | I will check as soon as possible, but I have no time to investigate.

Look for other things that require openvpn, munin-node does not look
as if it should be a problem.

Try
grep '^REQUIRE:.*openvpn' /etc/rc.d/*

openvpn requires NETWORKING (not a surprise really, given it is layered
over the existing network, which therefore must be up and running first)

But something else that NETWORKING requires must require openvpn.

That is also perhaps not surprising, as in a fully configured setup, your
networking won't really be considered operational until openvpn is up,
you wouldn't want to be starting network consumers until after that.

This probably points out a defect in the rc.d/* scripts related to networking,
we really need two steps - one which does the basic configuration and is
available when all the interfaces, static routing (etc) are configired.
And another (which would be NETWORKING) which indicates the network is
(as far as configuration goes anyway) fully operational.

openvpn should be depending upon the first of those, rather than
NETWORKING.

You might be able to solve the immediate problem by changing the openvpn
rc.d script to "REQUIRE: network" (and not NETWORKING) - in many environments
that might be sufficient (partricularly hosts, that don't need routing
daemons, etc.) but I doubt that is a general enough solution for a pkgsrc
files/* change.

kre

Re: rcorder (/etc/rc.d/openvpn)

[BERTRAND Joël]

Manuel Bouyer a écrit :

On Tue, Mar 07, 2017 at 09:06:39PM +0100, BERTRAND Joël wrote:

Hello,

For several weeks, I have noticed that two rc.d scripts don't run as
expected. They worked before. My server runs 7.0.2.

First one is openvpn. I have copied rc.d script provided by pkgsrc
maintainers. Header contains :

# PROVIDE: openvpn
# REQUIRES: NETWORKING

Second one is munin-node. Munin starts but some plugins don't answer to
remote request.

If I restart both daemons after login with /etc/rc.d/openvpn start and
/etc/rc.d/munin-node restart, both (re)start and run as expected.

In a first time, I have to fix openvpn startup and I have seen that 
rcorder
returns an error on openvpn script wut I don't understand this issue :

legendre# rcorder *
...
dhcpcd
ldpd
rcorder: Circular dependency on provision `NETWORKING' in file `openvpn'.
openvpn
npf
pf
route6d
...
staticroute
NETWORKING
mountcritremote
sysdb
...

I suppose I have to fix this error but I have no idea for that.


Don't you have something requiring openvpn ?



In /etc/rc.d/munin-node, I see :
# PROVIDE: munin-node
# REQUIRE: DAEMON smartd openvpn
# KEYWORD: shutdown

What does mean KEYWORD ?


that /etc/rc.shutdown will call it too

do you have something requiring munin-node ?



Manuel,

Thanks for your answer.

I will check as soon as possible, but I have no time to investigate.

	munin requires openvpn. Anything requires munin-node, but munin-node 
requires smartd to monitor hdd temp.


Regards,

JKB