26 August 2004

Start with a vmware machine to test things on. Set it up on williams.cscf and give it a NAT address for now; install 5.2.1. We'll make it a client of torres if we can.

15GB disk, partition into 1024mb /, 4096mb /usr, 1024mb swap, and rest for /fsys1 (approx 9gb). Do a custom distribution, just base and crypto. Add user uid 1000 mpatters, homedir /fsys1/u/mpatters. Set root passwd and TZ, configure lnc0 to DHCP. Configure hostname to be bsd5. Set it to allow NFS client and run sshd.

Looks like we can't mount through the NAT, so let's bridge it instead, give it reasoner's IP for now.

That worked, we can pkg_add. pkg_delete -a for now.

Edit make.conf with some base stuff for now (KERNCONF, CFLAGS, and such, but no additions yet for relocating packages) and mount /usr/obj and /usr/src from torres, then upgrade to latest 5.2.1-RELEASE (p9) as built on torres.

Edit /etc/fstab to mount /usr/{obj,src,ports} from torres.

Create standard xhier directory structure:

reasoner# ls -ld vendor/ xhbin/ software/ .software/
drwxr-xr-x  2 root  wheel  512 Aug 26 13:20 .software/
lrwxr-xr-x  1 root  wheel   22 Aug 26 13:20 software/ -> /fsys1/.software/share
drwxr-xr-x  2 root  wheel  512 Aug 26 13:21 vendor/
drwxr-xr-x  2 root  wheel  512 Aug 26 13:21 xhbin/
reasoner# cd /fsys1/.software/
reasoner# ls -l
total 12
drwxr-xr-x  2 root  wheel  512 Aug 26 13:20 admin
drwxr-xr-x  2 root  wheel  512 Aug 26 13:20 arch
drwxr-xr-x  2 root  wheel  512 Aug 26 13:20 local
drwxr-xr-x  2 root  wheel  512 Aug 26 13:20 regional
drwxr-xr-x  2 root  wheel  512 Aug 26 13:20 share
drwxr-xr-x  2 root  wheel  512 Aug 26 13:20 spool
reasoner# cd /
reasoner# ls -ld u
lrwxr-xr-x  1 root  wheel  8 Aug 26 13:23 u -> /fsys1/u
reasoner# cd /fsys1
reasoner# ls -ld u
drwxr-xr-x  3 root  wheel  512 Aug 26 13:07 u
reasoner# 

Referring to the Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports-using.html section 4.5.2.3 I see that we can set PREFIX. But some packages that use imake, and some perl packages, don't respect this. Go figure that perl and imake would make our life difficult.

Oh, grumble. xhier expects this: /software/packagename/bin (which then gets linked to appropriate /.software location), but PREFIX does this: /software/bin (I think). That sucks. Furthermore, ports must be built on the machine that has PREFIX set already - ie, if the port is built on a machine lacking PREFIX, and pkg_add is used on the resulting package file, the client machine will install it to /usr/local, regardless of what its own make.conf says. This is not surprising.

01 September 2004

Install the OATES kernel on freebsd5 so we can have ipfilter working. Set up simple ipf.rules file to basically block almost everything, and allow r-tools in /etc/inetd.conf (and allow inetd to run by editing /etc/rc.conf appropriately). Now we can rsh in as root from cscf.cs and capo (with appropriate entries in .rhosts). ssh in passwordless doesn't work though. Fix that later. I'd registered freebsd5.cs by this point and told the vmware machine about it.

I asked about the PREFIX thing on freebsd-ports. Hopefully nobody thinks I'm insane. The thread is here http://lists.freebsd.org/pipermail/freebsd-ports/2004-September/015795.html .

2 September 2004

Make entry for freebsd5 on capo. Take a snapshot of the virtual machine. Change the hostname to freebsd5.cs. Fix the default gateway that I missed.

capo# cd /usr/source
capo# xh-sdist -h freebsd5.cs xhier,dev
>>>>>
>>>>> Distributing /usr/source/xhier,dev
>>>>>
xh-sdist FYI: Skipping the following unreachable hosts:
                                freebsd5.cs
xh-sdist warning: no distribution hosts for the "xhier,dev" package.
xh-sdist warning:   from this host (capo); Skipping "xhier,dev".
capo# 

Ah, have to edit /software/xhier/data/architecture_masters on capo. But that wasn't sufficient either. Not a Dependencies issue. Guess I'll have to RTFM closely.

RTFMing was near-useless, so I decided to try xh-first-time:

%xh-first-time -v freebsd5.cs
xh-first-time FYI: checking to see if "freebsd5.cs" is accessible.
xh-first-time: unable to execute on "freebsd5.cs" -- rshd: Login incorrect.
%

hm.

%rsh freebsd5.cs ls -l
rshd: Login incorrect.
%

google says http://lists.freebsd.org/pipermail/freebsd-current/2003-September/010507.html so fix /etc/pam.d/rsh to add allow_root to the pam_rhosts.so line.

Now we get:

rdist: freebsd5.cs: connection failed: remote system answers "rdist: not found"
updating host freebsd5.cs

Ah, rdist isn't part of base system in FreeBSD any more. /usr/ports/net/44bsd-rdist fixes that, after one does "cd /usr/local/bin && ln -s 44bsd-rdist rdist". sigh, hurray for ancient tools.

I got lots of spew about unknown groups, and then lots of this:

/usr/source/TEMP-CACHE/xhier,dev/./xh-targets-conversion: Warning: remote mode 755 != local mode 2755

so I need to find out what group(s) I need to create on freebsd5, if nothing else.

none:*:101:

Whee, now we get source! But of course it wants mfcf headers, which I think requires mfcf-basics. Can't just distribute it from capo either, doesn't get files of all types. How do we do this?

4 September 2004

Talked to Dawn and Jason briefly on Friday - they recommended just rdisting the /software/mfcf-basics/include tree down, so that's what I did. On capo and after making required directories:

cd /software/mfcf-basics/include
rdist -c -w mfcf freebsd5:/software/mfcf-basics/include

Looking some more, I see we also need param.h and config.h. param.h is generated by arch_param, which is a servers file from mfcf-basics. Hrm. It has an xh-imake file. So we're back to needing xhier,dev again.

OK:

freebsd5# pwd
/usr/source/TEMP-CACHE/xhier,dev/xh-make
freebsd5# cat Makefile
# $Header: /software/twiki/installation/data/CF/XhierOnFreeBSD.txt,v 1.10 2006/02/07 14:22:23 www Exp twiki $
#
# $Locker: twiki $

# Note:
#   On a new architecture, we can't "xh-make install" this program
#   since xh-make isn't there yet.  So one has to:
#
#       make -f Makefile.bootstrap install

NAME = xh-make

INCLUDE = /software/mfcf-basics/include

it\
all: ./$(NAME)

install: ./$(NAME)
        ./$(NAME) install

./$(NAME): ./$(NAME).c
        cc -I $(INCLUDE) -O -s $(NAME).c -o .tempfile-for-$(NAME) \
                &&  mv .tempfile-for-$(NAME) ./$(NAME) 

sigh, so we need param and config.h.

Now I'm really stuck: we can't get xh-make without that stuff, and how do we get anything else without xh-make?  And double yee-haw: libuw is from mfcf-misc, so that's another package.  And that one has a dependency on pattern_dev.

3 October 2004

Talking with Bill and Ray in September, they said building on a brand new architecture is difficult enough to be impossible (hurray for portability) and highly recommended I just copy binaries from an existing, working arch. FreeBSD can run Linux binaries, so maybe we can get away with that.  The idea would be copy as little of the binaries as I can get away with, and use those to build the rest of the tools.

Looking on debian31, I also see an xhier_building package.  Why do we have xhier,dev and xhier_building?

So, we need to add the stuff required for Linux emulation.

freebsd5# pkg_add linux_base-7.1_7.tbz 
make changes in /etc/rc.conf

Almost works:
> ./xh-make
sh: /bin/showpath: No such file or directory
./xh-make: Couldn't read from showpath pipe: Success
> 


Can copy showpath, but it raises exceptions, it's missing libraries.  So I wonder how well xh-make will work, since it seems to want to use showpath?

You know, I'm not really seeing what we gain from copying binaries from other locations.  Binaries are borked because of missing libraries.  Libraries are missing because we can't build them.  We can't build them because xh-make is missing.  xh-make will run, but it's missing libraries.

Am I missing something?

Oh.  Here's the actual error message:
Contact a software maintenance person for help.
          The "LIBMFCF" event "ER_OPEN"
          in file "/software/mfcf-basics/data/messages/libmfcf"
          was raised while processing "LIBMFCF" event "ER_NOSUCHNAME"
          in file "/software/mfcf-basics/data/messages/libmfcf".


Looking on debian31, that particular file is a C header file.  Copy those to appropriate place and change ownership to root:none.

Now watch:

> ./xh-make
showpath: "xhier" is not installed.
showpath: "mfcf-basics" is not installed.
showpath: Unknown software package name "mfcf-misc".
showpath: Unknown software package name "graveyard".
showpath: Unknown software package name "imake".
./xh-make: Couldn't read from showpath pipe: Success
> 


Does this matter?

Make appropriate place for xh-make to live (/software/.admin/etc) and create links by hand.  Now look:

freebsd5# setenv PATH `showpath standard u=m`
freebsd5# rehash
freebsd5# which xh-make
/software/.admin/bins/bin/xh-make
freebsd5# xh-make
showpath: "xhier" is not installed.
showpath: "mfcf-basics" is not installed.
showpath: Unknown software package name "mfcf-misc".
showpath: Unknown software package name "graveyard".
showpath: Unknown software package name "imake".
xh-make: Couldn't read from showpath pipe: Success
freebsd5# 


so maybe we're getting somewhere.

We're back to needing the mfcflib stuff:

freebsd5# make -f Makefile.bootstrap
cc -O -s xh-make.c -o .tempfile-for-xh-make  &&  mv .tempfile-for-xh-make ./xh-make 

freebsd5# ln -s /fsys1/.software/share/mfcf-basics/include/mfcf/*.h .
freebsd5# ls -l
total 0
lrwxr-xr-x  1 root  wheel  55 Oct  3 14:32 _cfix.h -> /fsys1/.software/share/mfcf-basics/include/mfcf/_cfix.h
lrwxr-xr-x  1 root  wheel  54 Oct  3 14:32 cfix.h -> /fsys1/.software/share/mfcf-basics/include/mfcf/cfix.h
lrwxr-xr-x  1 root  wheel  56 Oct  3 14:32 config.h -> /fsys1/.software/share/mfcf-basics/include/mfcf/config.h
lrwxr-xr-x  1 root  wheel  54 Oct  3 14:32 mail.h -> /fsys1/.software/share/mfcf-basics/include/mfcf/mail.h
lrwxr-xr-x  1 root  wheel  55 Oct  3 14:32 param.h -> /fsys1/.software/share/mfcf-basics/include/mfcf/param.h
lrwxr-xr-x  1 root  wheel  55 Oct  3 14:32 paths.h -> /fsys1/.software/share/mfcf-basics/include/mfcf/paths.h
lrwxr-xr-x  1 root  wheel  56 Oct  3 14:32 userid.h -> /fsys1/.software/share/mfcf-basics/include/mfcf/userid.h
freebsd5# pwd
/usr/include/mfcf
freebsd5# 


So that leaves us missing libuw, which is linked in /usr/include/mfcf on debian31 but goes to mfcf-misc instead.

rdist mfcf-misc/include from debian31 to freebsd5.

Make that link in /usr/include/mfcf and the one I missed for libc.

Now the following file: /fsys1/.software/share/mfcf-basics/include/mfcf/config.h (which links to /.software/arch/mfcf-basics/include/mfcf/config.h) doesn't exist so the make in xh-make gets angry still.

Now that I think of it, I'm kind of wasting my time: I might as well just rdist over entire directories.

So clean out /fsys1/.software/arch on freebsd5, and:

debian31:/fsys1/.software/arch# rdist -c -w mfcf-basics freebsd5:/fsys1/.software/arch
debian31:/fsys1/.software/arch# rdist -c -w xhier,dev freebsd5:/fsys1/.software/arch
debian31:/fsys1/.software/arch# rdist -c -w xhier freebsd5:/fsys1/.software/arch


Do the same thing with xhier,dev, mfcf-basics, and xhier from /software on debian31 to /software on freebsd5.

Argh, doing it with mfcf-basics broke the rdist on freebsd5.  Ah, because the mfcf-basics package includes its own rdist, which was built on debian31 (presumably) and is therefore linked incorrectly.  Remove that binary.  Now I can rdist over xhier itself too.

Let's make some links by hand:

freebsd5# pwd
/fsys1/.software/share/.admin/bins/maintenance
freebsd5# ln -s /fsys1/.software/arch/xhier/maintenance/* .


now maintenance binaries work too.

Just on a whim, I tried xh-install xhier - it complains because xhier isn't installed (and neither is mfcf-basics) - go figure.

Apparently not everything is happy anyway:

freebsd5# ldd `which decomment`
/software/.admin/bins/bin/decomment:
/software/.admin/bins/bin/decomment: /lib/libc.so.6: version `GLIBC_2.3' not found (required by /software/.admin/bins/bin/decomment)
        libc.so.6 => /lib/libc.so.6 (0x28062000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x28049000)
freebsd5# 


hrm.

Let's try a different linux_base package out - there's a linux_base-debian which seems like a good candidate.

It's 3.0, hopefully that won't mess up that we've been using debian31 binaries all along...  it did.  So we'll switch from using debian31 as the source of binaries to using debian30.  And now decomment runs!

... but xh-make doesn't any more:
freebsd5# xh-make
ELF binary type "0" not known.
/software/.admin/bins/bin/xh-make: Exec format error. Binary file not executable.
freebsd5# 


grrr.

Oh, nice - debian31's xh-make works (albeit with the same whinges as previously seen).  WTF?