Project Laptop, pt. 3 -- NetBSD

[BigBison]

Trying to install NetBSD on the laptop to get a feel for a pkgsrc installation running on its native OS, has been kicking my ass. If I can, I'll walk through it step-by-step because, while well documented, NetBSD is a bit unfriendly even if you've installed plenty of OSs in your time. It basically took me a day to figure out how to format the HD:

http://www.netbsd.org/docs/guide/en/chap-misc.html#chap-misc-adding-new-disk

In searching for some help with that, I found this, and have added it to my list of bizarre mixtures of kernel/packaging system accordingly:

http://www.gentoo.org/proj/en/gentoo-alt/bsd/nbsd/doc/gentoo-netbsd.xml?style=printable

Actually, the two links combined gave me just enough insight, plus my learning Solaris (which has BSD roots), to figure it out. The 4.2BSD filesystem is similar to the UFS filesystem in Solaris, in that each use slices within partitions to lay out the disk. But even Solaris (since about Solaris 10) these days doesn't require this much effort to format a disk, talk about having a flashback experience to my first HD in 1989 or so...

For the uninitiated (including myself, before yesterday), NetBSD has no "installer". However, there are several LiveCD distros of NetBSD out there, I used BitTorrent to grab one from netbsd.org. It's pretty slick, I'm not used to seeing an entire KDE installation in a 700MB .iso image -- by way of comparison, Kubuntu's .iso takes up most of a DVD.

Once you are running NetBSD on your system, from the LiveCD, you can partition and format its HD (good luck :thumbsup: ). I recommend erasing the HD before booting the LiveCD, I had to abort my first attempt. Once you get there, the way forward gets confusing. Basically, you are running NetBSD already, so you can build and install the bootstrap version of gcc after transferring the source, then build cvs, then you cvs check-out, build and install the kernel...

http://www.netbsd.org/docs/current/

...or something like that. I'll be interested to see, as I progress, where the NetBSD kernel-build process (which is not pkgsrc-based) hands off to pkgsrc -- or portage, presumably, if the above Gentoo hybrid option is pursued. Not today, for me, even though I'm using GCC for this project the idea is to learn pkgsrc because it allows the use of any compiler whereas most source-build systems are tied to GCC, like portage. One thing's for sure, there's no "installer" to be found on the LiveCD to do any of this for you!

Don't get me wrong, I appreciate the difference between using a free-as-in-beer compiler like Sun Studio (for my OpenSolaris project) and a free-as-in-speech compiler like GCC. If I didn't have a specific reason, it wouldn't make sense to use a closed-source compiler with a (gentoo-ish || NetBSD-ish) source-build system. So no toying with gentoo, at least not at first, this is about exploring the NetBSD source-build system and its source-build packaging system, pkgsrc.

I'm sure I could pursue easier alternatives to installing NetBSD, like precompiled binaries, but this project is about doing it the hard way, i.e. build-from-source. So off I go, to learn what a "supfile" is.

[BigBison]

Another day gone by, a tiny bit more progress! I now have the sources downloaded and upgraded, and am ready to figure out why cpp fails the sanity check so I can build NetBSD. After figuring out how to format the HD (in my case, wd0 slice a is active) you need to mount it on /mnt:

# mount /dev/wd0a /mnt
# cd /mnt
# mkdir usr
# cd usr

Now you need to download and then update the source code, I tried various methods but this is what worked for me in the end:

# ftp ftp.netbsd.org
(anonymouse login)
ftp> cd pub/NetBSD/NetBSD-current/tar_files/src
ftp> mget *.gz
(answer 'a' for 'yes to all')
ftp> quit

I don't know how to untarball multiple files in UNIX, so laugh if you want but this is what I did next:

# ls |tee temp.sh
# kate temp.sh
(add 'tar -zxvf ' at the beginning of each line)
# chmod +x temp.sh
# ./temp.sh
# mkdir tools
# mkdir obj

This unzips all the tarballs into /mnt/usr/src, and creates a couple of needed directories. Now, create the $CVSROOT environment variable and a .cvspass file by logging into the anonymous CVS server manually:

# cvs -d :pserver:anoncvs@anoncvs3.us.netbsd.org:/cvsroot login

The password is 'anoncvs'. Now the source code can be updated, the syntax for a first update is as follows:

# cd src
# cvs -q -d $CVSROOT update -dP

The source code is now updated to the latest release (4.99.30), and ready to build. I was kinda hoping gcc would be all configured and ready to go on the LiveCD. The instructions make it seem simple enough, I should just have to go...

# ./build.sh -O ../obj -T ../tools -u release

...and NetBSD will build, except I get the CPP sanity-check error, like I'm missing headers or something...

[BigBison]

All the help I can find on this, tells me to check config.log. But there is no config.log...

[inimino]

I don't know how to untarball multiple files in UNIX, so laugh if you want but this is what I did next:

# ls |tee temp.sh
# kate temp.sh
(add 'tar -zxvf ' at the beginning of each line)
# chmod +x temp.sh
# ./temp.sh

Actually, that's a fairly well-established technique for creating quick scripts. It's one of the perks of an environment where everything is text, and you have a nice, powerful text editor (um, or kate ;)).

When you run it it's often more convenient to use the '.' or 'source' shell builtin, which simply interprets the contents of a file as commands, one per line. This doesn't require you to add #!/bin/sh or set the exec bit, and doesn't create a new process, so it uses the current environment:

$ ls >tmp
... edit file 'tmp' ...
$ . tmp


Alternatively:

$ for F in *.gz; do tar xzf $F; done

All the help I can find on this, tells me to check config.log. But there is no config.log...

It might be in a different directory than the one you run build.sh from (try 'find . -name config.log' from the top-level directory of the source distribution) or it could be that that build.sh script is cleaning up after itself, in which case you might try to run ./configure directly.

Edit: before you look for config.log, make sure you can run cpp from the shell, though. It's less likely to be missing headers than a missing /usr/bin/cpp.

[BigBison]

No, really, there's no config.log, there's also no 'configure' file. Only a 'build.sh' script.

Edit: before you look for config.log, make sure you can run cpp from the shell, though. It's less likely to be missing headers than a missing /usr/bin/cpp.

A little more slowly, please? Yes, I can run 'cpp --version' if that's what you mean...

I even tried adding the path to the headers, in CPPFLAGS.

[inimino]

I don't know anything about the NetBSD build process specifically, so this could be a different "cpp sanity check" than the one I'm familiar with, in which case what follows is a red herring...

The cpp sanity check I'm familiar with is from autoconf, and the autoconf-generated scripts write out a simple C file, runs it through cpp, and tests the output to verify the preprocessor is installed and working. This test doesn't look for or require any external header files.

Every time I've seen this test fail it's been when a usable cpp wasn't available to the build process at all, e.g. because the $PATH that the build script is using isn't the one you have when you run 'cpp --version' from the command line.

If it was me I'd start reading build.sh and see what it's actually doing...

[BigBison]

It looks like removal of all configure scripts, in favor of build.sh, is a fairly recent NetBSD phenomenon. In Solaris, if you do a raw install, then install Sun Studio compilers, you'll get the cpp sanity check error because the package 'SUNWhea' is not automatically added, for some reason, so the compiler has no headers. Or the PATH doesn't include the right /lib, or point to /opt/SUNWspro/bin or lib. IOW, I've been getting this one a lot lately...

Meanwhile, it turns out that you can download a NetBSD installer .iso, which is a bootable (binary package) installer called 'sysinstall' which is not on the LiveCD I had been using. I now have a NetBSD system which boots on the laptop (formatting the HD is even simplified, but not much).

You wind up with a populated /usr/src, but it's a completely different version (3) than what I was using yesterday (4), so I decided to wipe it and repeat yesterday's steps, just after I did this it occurred to me I had a chance to run build.sh and see if it bitched about CPP again, 'which cpp' returns /usr/bin/cpp, but the sanity-check error says /usr/lib/cpp, setting CPP=/usr/bin/cpp still resulted in the sanity check error though.

There's also a source-code .iso, which has all the sources for the base OS, I think except they're packaged differently than on the FTP site so I'm not sure what to do with 'em. Full-speed downloads with BitTorrent, on these .iso's too. The distro tarballs, downloaded directly, take no time at all either.

[BigBison]

Oh, I should mention that, unlike the slick KDE-desktop LiveCD the installer CD gives you a choice between sh, csh and ksh -- it's a minimal install, from there one could conceivably just 'pkg_add kde3' to achieve the same effect. But this project isn't about doing things the easy way...

[BigBison]

My NetBSD build is happily chugging away, with no complaints about insanity on my part. However, I have just made the mistake I'm seeking to avoid with Solaris -- an inconsistent toolchain.

The gcc version I'm using to build the NetBSD source, is older than the one included in the cvs-updated source. After the OS is done compiling and installing itself, pkgsrc can then be used to build packages, with the updated version of gcc. Resulting in a hybrid system which is built using two compilers (albeit both gcc). So I probably should have built the latest version of gcc, then started build.sh to do the whole build using the new compiler.

With OpenSolaris, Sun Studio 11 is required to build the OS (I couldn't get it to work with Sun Studio 12, but I did come close) but after that, Sun Studio 12 could be used with pkgsrc (once I get that figured out on Solaris). Better than one compiler being Sun Studio and the other, gcc, but I still want a thoroughly consistent toolchain. Luckily, this is not a dealbreaker for the NetBSD install so I'll just let it continue, keeping my fingers crossed of course...

[BigBison]

Eight hours later:

"Successful make release"

That's more like it.

[BigBison]

I still would have preferred to install from scratch, the path I took of installing followed by upgrading requires some firsthand knowledge of the process. The documentation gives no indication of what all is involved in 'etcupgrade' or what to do if the 'fix' procedure fails (although not by much). So I think the whole installation counts as a "dry run" at this point, and should be started over.

Well, that's a bit much effort to go through again... so instead I'm trying to set up pkgsrc in its native environment. I downloaded 'pkgsrc.tar.gz' which contains all the patches and makefiles and such, to be applied to the actual sources in the 'distfiles'. I'm now cvs-updating the pkgsrc tarball, in a few more hours that should be done, then I can see how pkgsrc really works, I think.

NetBSD splits the installation between 'distribution sets' and the 'package collection'. Here's where I get confused. You have to have installed the 'comp' and 'text' distribution sets to use pkgsrc -- basically, compilers. Then, you can use pkgsrc to install... the same compilers as a package, instead of as a distribution set. You have to have cvs from a 'distribution set' but you can also build and install it as a package... :?

One thing that it would have helped to know up front, is that you need the whole pkgsrc set (the patches and makefiles, etc. specific to pkgsrc) before the build system will go out and fetch the sources. So pkgsrc is starting to make more sense, can't wait for the cvs update to finish so I can try it out.

[BigBison]

Now pkgsrc is starting to make sense. The tarball and cvs update of /usr/pkgsrc contains no source files, just instructions for fetching the 'distfiles', patching and building them. Not quite as convenient as apt-get install, to use pkgsrc you have to browse the /usr/pkgsrc tree until you find what you want, cd into that directory and do 'make && make install', and everything works like magic.

I cd'd to the 'meta-pkgs' directory and then into 'xfce4', which is now happily downloading prerequisites -- building prerequisites -- downloading bits -- building bits and so on and so forth, alternating between compiling and downloading. It'll be interesting to see how long it takes to download the sources for, build and install XFCE4 and then see if it works. Stay tuned!

[BigBison]

So XFCE4 built and installed no problem, but it doesn't really work. You get the splash screen with the mouse logo, followed by that goshawful houndstooth X screen with X cursor. Then nothing. So this dry-run build counts as "close but no cigar".

I do have a notion to try again, using my two-laptops-ago Pentium II thinkpad with Win 98 installed, and restore my Nexenta setup on the primary laptop. I do have an appreciation for NetBSD (the laptop-mode kernel and other stuff works well, btw) now, though. I believe I could get it right if I tried, and therein lies the rub -- if you're a Windows guy looking to move into a UNIX of some sort NetBSD is probably not the way you want to go. If you are an experienced sysadmin, though, particularly if you're strong with cvs and compilers and such you'll probably really like NetBSD.