Re: Unable to boot to install 8.1 and 9.0 RC2 on amd64 Laptop
On Mon, 10 Feb 2020, John D. Baker wrote: > I've had a similar, but different experience booting -current on an HP > Pavilion dv2000 laptop. I think I posted about it quite some time ago. > I try again every so often but the situation has not improved. I should have mentioned that this machine has Linux Mint installed on it, which works very well. I'd heard rumors about machines built during a certain CEO's tenure at HP having all manner of bizarre issues like this. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | 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: Unable to boot to install 8.1 and 9.0 RC2 on amd64 Laptop
I've had a similar, but different experience booting -current on an HP Pavilion dv2000 laptop. I think I posted about it quite some time ago. I try again every so often but the situation has not improved. A normal boot of GENERIC hangs just after acpi detection. Booting w/o ACPI gets up to detecting the NVIDIA graphics card which isn't supported. It used to just panic later when attaching the console, but now at least skips it as unsupported and stays in VGA text mode. Following that, it gets as far as detecting the hard disk but then hangs while detecting the optical drive. Random fumbling on the keyboard, or a quick press of the power switch usually helps it over this bump. Booting w/o ACPI and w/o SMP lets it boot all the way to multiuser with no user intervention. At some point during the 9.0 release cycle, the default "/boot.cfg" file had the menu options to boot w/o ACPI and w/o ACPI, SMP removed. You can still do so by using the option to drop to the boot prompt and giving: boot: boot /netbsd -12 (-1 disables SMP and -2 disables ACPI) -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Unable to boot to install 8.1 and 9.0 RC2 on amd64 Laptop
Hi, I have an amd64 (genuine AMD) latop HP zv6000 with Athlon64 CPU I want to install NetBSD on (what else?). I extra got this machine to test "real" amd64 :-P and no luck. It has a big "desktop" CPU, not a mobile version. First I tried booting straight off the netboot iso of 8.1 It hangs after some kernel messages. I thus tried disabling ACPI and even ACPI+SMP. It still hangs and the last message seen is "AMD Cool'n' Quiet" I thus tried NetBSD 9.0 RC2 and it hangs too. Here I have no options to disable ACPI and SMP! Boot ends after a while. after having printed out: acpicpu0 at cpu0: ACPI CPU fwochi0: BUS reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER, mode ieee1394if0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) ieee1394if0: bus manager 0 Waiting does not help. The BIOS does not have many options, I cannot disable e.g. SMP, ACPI or such. Only WiFi & LAN. I disabled those... but it does not help- now what else can I try? I wonder also that the disable ACPI option disappeard, but especially, what the bug we have. Can I try something else? Some special option? Just for info: I tried booting a Devuan cd install I had around, and it booted up to graphical install, detected network hardware (except wifi which is detected but not enabled since it needs firmware) Help! Riccardo
Can't open /boot | biosboot via GPT on raidframe on GPT (NetBSD 9.0/amd64_RC2)
Hello everybody I'm currently in doubt about everything and need advice from someone who is familiar with NetBSD's boot processes. I am trying to set up a system with two hard drives as RAID 1. To do this, I create a GPT on both disks with a single partition of the type raid on each. I then mirror these partitions together into a RAID 1 using raidframe. I then create an embedded GPT with the netbsd partitions into the raidframe. the first partition carries the root filesystem from which I also want to boot. And this is what I don't succeed. The crazy thing is, a while ago I managed a similar setup on the same computer (but with different hard drives). At that time I wrote an installer script and it doesn't seem to work anymore either. I now doubt whether I still made some manual adjustments to make it work. So if someone has experience with the boot process, I would be very grateful if they could take a look at the script to see if it was correct at the critical points. I am thinking primarily of the places where installboot and gpt biosboot are called. The error pattern looks like this: when the installation is complete, i get the text of the primary bootstap when booting from hard disk: NetBSD/x86 ffsv2 Primary Bootstrap Boot failed (errno 2): Can't open /boot I attach the script directly to this email and remain with kind regards Matthias #!/bin/sh # Cleanup pre-existing partitioning ### gpt destroy -f raid0 raidctl -u raid0 dkctl wd0 delwedge dk0 dkctl wd1 delwedge dk1 gpt destroy -f wd0 gpt destroy -f wd1 # Create GPT partition tables on disks gpt create wd0 gpt create wd1 gpt add -l sys0 -a 2m -t raid wd0 gpt add -l sys1 -a 2m -t raid wd1 # Create RAID # cat
Kerberos client functionalities in NetBSD
Hi all! This is not a request or a question, but rather a collection of notes about Kerberos, for anyone who is interested. I was trying to configure (for the first time) a NetBSD 8.1 amd64 host as a Kerberos client. First, it is worth noting that there is more than one implementation of Kerberos: MIT and Heimdal are maybe the most common ones. They should be api-compatible, as I was suggested in the IRC channel #netbsd. The implementation of Kerberos natively used in NetBSD is Heimdal: the base system already includes an essential set of utilities like kinit(1), klist(1), kadmin(8), ktutil(8). If the MIT Kerberos is needed, several packages are available in the pkgsrc repository. Using only the base system, with just the creation of an appropriate /etc/krb5.conf file and the necessary lines in /etc/hosts, a NetBSD host is immediately able to obtain a Ticket-Granting-Ticket as a Kerberos client. I used it against a MIT Kerberos server and I found no compatibility issues. This has been quick and very, very useful. I found instead some issues when trying to create a keytable in the NetBSD client. For example, `kadmin -p admin_user' suddenly shows the admin_user admin prompt, which seems very odd; then, for some of the available commands, it asks for the password and does not return the prompt after entering the correct password. The same happens with `ktutil get -p admin_user host/fqdn.of.the.client'. Note that I can not exclude that this is due to something I forgot (or did not know) to configure. However, a keytab created with MIT Kerberos utilites and then copied into NetBSD is correctly read with `ktutil -k keytab_file list' and is perfectly suitable, for example to receive ssh connections. If ssh authentication through a Kerberos user must be provided in a NetBSD client, the /etc/pam.d/ files already include a line for the pam_krb5.so module: so, no configuration for PAM is needed. I installed from pkgsrc the package pam-krb5, which includes pam_krb5.so, but this file is already in the base system in /usr/lib/security/ and maybe there is no need for the package. It is instead necessary cy2-gssapi, which depends on cyrus-sasl (needed as well), for GSSAPI authentication, in addition to the correct configuration lines both in /etc/ssh/sshd_config (for the server) and /etc/ssh/ssh_config (for the client). In conclusion, the NetBSD 8.1 base system includes some executables and libraries which make a Kerberos client configuration almost immediate. Thanks to those who tailored the base system. Bye! Rocky
Re: USB device with no driver
On Fri, Feb 07, 2020 at 02:53:11PM +0100, Martin Husemann wrote: > Check umodeswitch and see if you can extend that for this device, it > is used for many things that later attach as u3g(4). I had two USB keys, one got recognized with this. While we are there, we could pull many mappings from this: https://www.draisberghof.de/usb_modeswitch/ -- Emmanuel Dreyfus m...@netbsd.org
Re: Problems with C++ compiler on 9.0_RC2
Martin Husemann écrit : > On Mon, Feb 10, 2020 at 01:17:31PM +0100, Marc Baudoin wrote: > > Strangely enough, it doesn't happen on another system that have > > been upgraded (always with a binary install image) from 8.1 to > > several 9.0_BETAs over time then 9.0_RC1 then 9.0_RC2... > > The difference is: > > lrwxr-xr-x 1 martin wheel 12 Jan 31 13:19 > ./9.0/usr/include/g++/bits/gthr-default.h@ -> gthr-posix.h > -rwxr-xr-x 1 martin wheel 0 Jan 31 13:19 > ./updated/usr/include/g++/bits/gthr-default.h* Indeed, I have an empty (executable) /usr/include/g++/bits/gthr-default.h regular file. Replacing it with a symbolic link to gthr-posix.h seems to work (at least your previous example compiles now). > Sounds like a bsdtar bug :-( which also explains why it did not happen > for your beta updates. Then it would be nice to have it fixed before 9.0. Thanks!
Re: Problems with C++ compiler on 9.0_RC2
On Mon, Feb 10, 2020 at 01:17:31PM +0100, Marc Baudoin wrote: > Strangely enough, it doesn't happen on another system that have > been upgraded (always with a binary install image) from 8.1 to > several 9.0_BETAs over time then 9.0_RC1 then 9.0_RC2... The difference is: lrwxr-xr-x 1 martin wheel 12 Jan 31 13:19 ./9.0/usr/include/g++/bits/gthr-default.h@ -> gthr-posix.h -rwxr-xr-x 1 martin wheel 0 Jan 31 13:19 ./updated/usr/include/g++/bits/gthr-default.h* Sounds like a bsdtar bug :-( which also explains why it did not happen for your beta updates. Martin
Re: Problems with C++ compiler on 9.0_RC2
Martin Husemann écrit :
> On Mon, Feb 10, 2020 at 11:01:37AM +0100, Marc Baudoin wrote:
> > I believe only C++ programs using pthread fail. I don't know how
> > to do a minimal example but the easiest way to see the problem is
> > to compile pkgsrc/multimedia/libvpx (which doesn't have too many
> > dependencies).
>
> Here is a trivial reproducer:
>
> --8<--
> #include
> #include
> using namespace std;
>
> int main(int argc, char **argv)
> {
> cout << "hello world\n";
> return 0;
> }
> -->8--
Thanks.
> Compile with c++ and watch it fail as you described.
>
> The original compilation was done with -std=c++11, but that does not seem
> to matter here.
It doesn't matter indeed, it always fail for me:
% c++ -std=c++11 toto.cxx
In file included from /usr/include/g++/memory:74:0,
from toto.cxx:1:
/usr/include/g++/ext/concurrence.h:124:5: error: ‘__gthread_mutex_t’ does not
name a type; did you mean ‘__pthread_volatile’?
__gthread_mutex_t _M_mutex;
^
__pthread_volatile
/usr/include/g++/ext/concurrence.h:169:5: error: ‘__gthread_mutex_t’ does not
name a type; did you mean ‘__pthread_volatile’?
__gthread_mutex_t* gthread_mutex(void)
^
__pthread_volatile
/usr/include/g++/ext/concurrence.h:179:5: error: ‘__gthread_recursive_mutex_t’
does not name a type; did you mean ‘__recursive_mutex’?
__gthread_recursive_mutex_t _M_mutex;
^~~
__recursive_mutex
/usr/include/g++/ext/concurrence.h:224:5: error: ‘__gthread_recursive_mutex_t’
does not name a type; did you mean ‘__recursive_mutex’?
__gthread_recursive_mutex_t* gthread_recursive_mutex(void)
^~~
__recursive_mutex
> The failure (at least with above test) does not happen in -current, nor
> when installing 9.0_RC2 from scratch.
But it happens for me on every system I have that have been
upgraded with an install ISO from 8.1 to 9.0_RC2.
Strangely enough, it doesn't happen on another system that have
been upgraded (always with a binary install image) from 8.1 to
several 9.0_BETAs over time then 9.0_RC1 then 9.0_RC2...
Re: Problems with C++ compiler on 9.0_RC2
On Mon, Feb 10, 2020 at 11:01:37AM +0100, Marc Baudoin wrote:
> I believe only C++ programs using pthread fail. I don't know how
> to do a minimal example but the easiest way to see the problem is
> to compile pkgsrc/multimedia/libvpx (which doesn't have too many
> dependencies).
Here is a trivial reproducer:
--8<--
#include
#include
using namespace std;
int main(int argc, char **argv)
{
cout << "hello world\n";
return 0;
}
-->8--
Compile with c++ and watch it fail as you described.
The original compilation was done with -std=c++11, but that does not seem
to matter here.
The failure (at least with above test) does not happen in -current, nor
when installing 9.0_RC2 from scratch.
Martin
Re: Problems with C++ compiler on 9.0_RC2
On Thu, Feb 6, 2020 at 11:10 AM Marc Baudoin wrote: [...] > Is it a problem with my setup, with pkgsrc or is there something > wrong with the C++ environment in 9.0_RC2? cmake compiled fine on my fresh install of rc2
Re: Problems with C++ compiler on 9.0_RC2
Martin Husemann écrit : > On Mon, Feb 10, 2020 at 08:07:07AM +0100, Marc Baudoin wrote: > > I just tried : > > > > - install NetBSD/amd64 8.1 from ISO > > - boot from 9.0_RC2 ISO and upgrade > > - reboot, get pkgsrc: any C++ build will fail > > Can you try a minimal C++ hello world program? > > I tried your recipe with i386 and at last hello world in c++ did work just > fine. I believe only C++ programs using pthread fail. I don't know how to do a minimal example but the easiest way to see the problem is to compile pkgsrc/multimedia/libvpx (which doesn't have too many dependencies).
Re: Problems with C++ compiler on 9.0_RC2
On Mon, Feb 10, 2020 at 08:07:07AM +0100, Marc Baudoin wrote: > I just tried : > > - install NetBSD/amd64 8.1 from ISO > - boot from 9.0_RC2 ISO and upgrade > - reboot, get pkgsrc: any C++ build will fail Can you try a minimal C++ hello world program? I tried your recipe with i386 and at last hello world in c++ did work just fine. The exact failure may depend on the version of the c++ standard that is requested on the command line or something. Martin
