The Life of a Sysadmin

Carousel is a lie!

Entries from July 2005.

Blast from the past
2005-07-01 10:52:57

(Note: this was actually written back in May.)

Top Tip: Filenames with a tilde in them can confuse Samba.

Case in point: last week a user was having problems loading his profile: W2K kept choking and saying that the file Local Data\Applications\foo\backup\~AvariciousMonkeys.c was in use. Naturally, lsof on the Samba server turned up nothing, and I couldn't see any obvious problem. On a hunch, I tried renaming the file to AvariciousMonkeys.c~, and hey presto! goodness all over.

This week I'm trying to get FAI going in seriousness. I've worked on it before, but now I've got three developers who want to switch to Linux. The last thing I want is another series of one-offs, so I'm taking the time to do it right. Now there's a CD version in beta, and so far it's working well. Cf. the usual way of doing it, which is to do PXE booting and grab everything off the network. I'm not opposed to that, but one of the things I wanted out of FAI before was the ability to do CD-based, kickstart-like Debian installs; looks like it's finally going to work.

Looks like we're having a problem with a Maxtor PCI IDE controller and the Intel mobo in our backup server. It's been mysteriously crashing in the middle of the night w/no log messages. Some checking in the BIOS turned up another problem: going to the hardware monitoring page to look at the CPU temperature made the damn thing freeze. WTF? Sure seems like the symptom we were seeing, and backups running at night make big use of the Vinum array that uses drives attached to the IDE adapter...long story short, taking out the card stopped the BIOS freezing. It remains to be seen if it'll work for the random midnight freezes, but it's good to have something to try. I'm hopeful that FreeBSD will be able to handle SATA drives attached to this thing...we'll have to see.

Which brings me to the next bit: fleshing out plans for server upgrades. As I mentioned, last week we had a power supply fail on our Very Important Server, and I want to try and keep that from happening again. Of course, adding umpty thousand dollars worth of hardware to your budget four months before the end of fiscal doesn't really work too well, so as much as possible I need to do this w/o new hardware. Ha! But I'll give it a try.

First off is setting up OpenLDAP and importing Samba's information into it. That'll be neat, since I've never worked w/LDAP before. Second is to set up some BDCs using OpenLDAP to query the master. (Or do they just suck over the whole database? Hm. Either way.) Third is to set up some Linux machines. Why? Two reasons:

LinuxHA and DRBD seem fantastic, and there just doesn't seem to be anything comparable on the FreeBSD side. As for the hardware...well, my first impression of server hardware from IBM, HP and the like (no, don't talk to me about Dell) is that I'm going to need a newer version of FreeBSD than we currently use in order to run SATA drives. (I know SCSI is the way to go, but I was quoted two thousand dollars for two IBM 73GB 15k drives! I know: 15k, IBM, etc, but even halving that means two -- two! -- 73GB drives for a thousand bucks, a/o/t two 200GB drives for, what, four hundred. Heh.)

We're using an older version of the 4-series FreeBSD here. I've already set up one server using a newer 4-series release, and it's a pain: too many differences, one more thing to keep in mind when making changes, and so on. I haven't worked with the 5-series yet, and I don't want to start now...not entirely sure that it'd work for us. Plus, we'll probably migrate to Linux anyway, so I don't mind doing it for a server.

Anyhow! Get a Real Server and throw Linux on it. Hook it up to our drive array and start migrating home directories to ReiserFS from UFS/FreeBSD. Not trivial, but doable. Add more Linux servers as budget allows.

Tags: bsd, hardware, installation, linux, samba, upgrades.
NWR04B: Progress!
2005-07-01 11:03:55
EMXIFFIXMUncompressing Linux...FIXME

                                   FIXMran out of input data
                                                            FIXME

                                                                 -- System haltedFIXM

I set ZTEXTADDR in arch/armnommu/boot/Makefile to 0x1000, and now I get this. Sweet!

00000000:00304C0C;0000106C=00000000
00303A68-00304C0C>00000000
EMXIFàUncompressing Linux...à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à.à done, booting the kernel.
                                                                                                                     à
00000000:00000000;0017F4C8=00000000
0008BC8C-0017F48C>00008000
0017F48C
00008000: E1A0C000 E3A0105B E28F5028 E8952360  E3A04000 E1550008 34854004 3AFFFFFC
00008020: E59F2024 E5862000 E3A0205B E5892000  E3A0B000 EA0000F9 001337E0 00134184
00008040: 00163A8C 00134180 00116000 84200001  E1A0C00D E92DD800 E24CB004 E24B1014
00008060: E24DD008 E50B0010 E24B0010 EB0309CF  E3500000 159F200C 151B3014 15823000
00008080: E3A00001 EA000000 0013B720 E91BA800  E1A0C00D E92DD870 E24CB004 E1A06000
000080A0: E59F5050 E5950000 EB030401 E1A04000  E1A00006 E5951000 E1A02004 EB0303E7
000080C0: E3500000 1A000005 E0860004 E1A0E00F  E595F004 E3500000 13A00001 191BA870
000080E0: E59F3014 E2855008 E1550003 3AFFFFEC  E3A00000 E91BA870 00048880 00048930

00136E70: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
00136E90: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
00136EB0: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
00136ED0: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
00136EF0: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
00136F10: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
00136F30: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
00136F50: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
EMXIFàUncompressing Linux...à
No tags
Noooo!
2005-07-01 20:37:31

Got an email from my ISP saying they've noticed that our bandwidth usage is "substantially more than the average Internet user", and asking (ie, telling) us to contact them ASAP. Not sure what this would be about. I mean, yes, I am hosting a bunch of websites here in strict contravention of their AUP...but a quick look at MRTG shows that we simply can't be doing that much traffic: 2.5GB or so last month for the web, and maybe another GB for email, DNS, and whatnot. We don't do filesharing, so that's out. I've downloaded some ISOs and such, but no more than usual -- less, in fact. So what the hell? As a result, I'm looking at virtual server hosting, just in case. If anyone has any recommendations or war stories, please drop a line. Update: I talked to the Shaw people, and was told I'd done 55 GB total over the month. This was 'way beyond what I expected, and I couldn't figure it out. I looked at the usage graphs, and found that it was nearly symmetrical: almost 1GB up and 1GB down every day. And it had started at the end of May. What the... Then I realized: I'd rebooted my desktop and server around that time, and the two addresses they'd got were on different subnets. I back up files from the server every night, and it's about 1GB or so. That meant that 1GB was going out from my server, hitting Shaw's router, then coming back to my desktop machine...making it about 2GB per day, very symmetrical. I've added another ethernet card to each machine, hooked up a crossover cable, put in a restrictive firewall, and it's much better: 300MB total for yesterday. This is well under Shaw's "guideline" (ie, rule) of 20GB total per month. (Shaw, in their wisdom, refuse to put these limits on their AUP page, but instead insist that you call in and spend 10 minutes on hold for tech support to find out.) Aside from this blip (and a similar one in December), the average traffic over the last 12 months has been between 3 GB and 9GB total; I rarely serve more than 3GB in a month. Good to know.

2 comments. No tags
NWR04B: KERNEL PANIC!
2005-07-04 20:00:01

HO yeah!

boot no options
Linux version 2.4.19-uc1-cx84200-4 (aardvark@rearden.saintaardvarkthecarpeted.com) (gcc version 2.95.3 20010315 (release)) #955
Processor: Conexant CX84200 revision 1
Architecture: cx84200
On node 0 totalpages: 2048
zone(0): 0 pages.
zone(1): 2048 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/mtdblock1 ro console=ttyS0
Calibrating delay loop... 32.15 BogoMIPS
Memory: 8MB = 8MB total
Memory: 6668KB available (806K code, 324K data, 36K init)
Dentry cache hash table entries: 1024 (order: 1, 8192 bytes)
Inode cache hash table entries: 512 (order: 0, 4096 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 2048 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.
eth0: a0:98:76:54:32:10 
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 512 bind 512)
*******
VFS: test name =  
VFS: fs_name = <jffs2>
VFS: root name <1f:01> 
*******
VFS: tried fs_name = <jffs2> err= -19
VFS: Cannot open root device "mtdblock1" or 1f:01
Please append a correct "root=" boot option
Kernel panic: VFS: Unable to mount root fs on 1f:01

I am currently giggling like an idiot and scaring my wife.

No tags
NWR04B: Further up the abstraction ladder
2005-07-10 19:36:09

Well, I'm getting further along. First off, I've managed to get the kernel mounting its root directory from my desktop machine. The trick to this was turning off the initrd option in the kernel config; if you don't, it doesn't matter what options you put in the kernel command line -- it'll try to read the ramdisk and then fail because it's not in JFFS2 format (though I'm sure that error could be got around somehow; I'm just not bothering right now 'cos NFS is more flexible). So now this kernel command line works: root=/dev/nfs nfsroot=192.168.23.254:/home/aardvark/nwr04b/nfsroot ip=192.168.23.12:192.168.23.254:::test:eth0:off ...and I can ping the thing, which is good. Now I just need to populate it, which means just compiling busybox. Easy, right? Ha! Another big-ass set of problems is what it is. First, I tried a copy of Busybox I had lying around that I think I'd compiled as part of a previous toolchain attempt. Yeah, I know -- "Let's throw in random binaries and they'll work!" -- but I figured it was worth a try. file seemed hopeful: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.0.0, statically linked but when I tried it I got this error: BINFMT_FLAT: Bad magic/rev (0x1010161, need 0x4) God bless Free software; here's the comment from fs/binfmt_flat.c:

because a lot of people do not manage to produce good
flat binaries,  we leave this printk to help them realise the problem.
We only print the rror if it's not a script file

Flat binary? Wha? And then came this FAQ from the excellent uCdot:

What causes 'BINFMT_FLAT: bad magic/rev (0xZZ, need 0xYY)' errors?

A lot of people encounter this error the first time they try to run a
program on a uClinux system. Usually this is caused by trying to run an
ELF or COFF executable rather than a "flat" executable. uClinux does not
support anything but the "flat" executable format.  ELF/COFF programs
are converted to "flat" format using elf2flt/coff2flt respectively.

To fix this problem with the ELF toolchain add -Wl,-elf2flt to the final
link line of your build and it will create a flat executable.

And why do we need that? Well, because this CPU has no MMU; the ELF format for executables won't work because (and I'm fuzzy on the details here) this means that the binary has to deal with being run from any memory address, rather than being lied to and told that it's at 0x0. Thus the special arguments to the compiler and linker, and the invocation of elf2flt afterward. So: to compile busybox I had to change the CFLAGS argument in make menuconfig to -D__PIC__ -fpic -msingle-pic-base, then run:

make dep
LDFLAGS=-Wl,-elf2flt make

I still got this error: arm-elf-strip --remove-section=.note --remove-section=.comment busybox arm-elf-strip: busybox: File format not recognized make: *** [busybox] Error 1 but the strip command is the very last one in compiling the binary, and file busybox gave "busybox: BFLT executable - version 4 gotpic". I copied it into place, booted and got:

IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
      device=eth0, addr=192.168.23.12, mask=255.255.255.0, gw=255.255.255.255,
     host=test, domain=, nis-domain=(none),
     bootserver=192.168.23.254, rootserver=192.168.23.254, rootpath=
Looking up port of RPC 100003/2 on 192.168.23.254
Looking up port of RPC 100005/1 on 192.168.23.254
VFS: Mounted root (nfs filesystem).
Freeing init memory: 52K
Unhandled fault: external abort on linefetch (F4) at 0x00000001
fault-common.c(97): start_code=0x700040, start_stack=0x67ffbc)
[1] sh: bad data abort: code 33554432 instr 0x32005500
Code: 495f5fdf 0e97f38e (c9a303b1) 3ea3a3ad b294aa7c 
fault-common.c(97): start_code=0x700040, start_stack=0x67ffbc)
Internal error: unknown data abort code: 32005500
CPU: 0
pc : [&lt;0000ffff&gt;]    lr : [&lt;0000ffff&gt;]    Not tainted
sp : 0000ffff  ip : 0000ffff  fp : 0000ffff
r10: 0004d04c  r9 : 00050e40  r8 : 001fa000
r7 : 00000000  r6 : 0000005b  r5 : 00169884  r4 : 0019a904
r3 : 001722c0  r2 : ffffffff  r1 : 20000010  r0 : 20010016
Flags: nzcv  IRQs off  FIQs off  Mode SYS_32  Segment kernel
Control: 0
Process sh (pid: 1, stackpage=001f9000)
Stack:
Backtrace: frame pointer underflow
Function entered at [] from [&lt;8e0e97f3&gt;]
Unhandled fault: alignment exception (93) at 0x00000001
fault-common.c(97): start_code=0x700040, start_stack=0x67ffbc)
Internal error: Oops: 0
CPU: 0
pc : [&lt;0012cccc&gt;]    lr : [&lt;00058850&gt;]    Not tainted
sp : 001f9e94  ip : 001f9e40  fp : 001f9ec8
r10: 00640004  r9 : 00000000  r8 : 00000010
r7 : 00000000  r6 : b1c9a2f3  r5 : 9c63fdbd  r4 : 0000ffff
r3 : 0014b478  r2 : 00000001  r1 : 00000001  r0 : 0000ffef
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  Segment kernel
Control: 0
Process sh (pid: 1, stackpage=001f9000)
Stack:
001f9e80:          00058850 0012cccc 60000093  ffffffff 0000ffff 001f8000 00000001 
001f9ea0: 001f9fd4 0067ffc8 00053a08 001f8000  001f9fd4 0000ffff 32005500 001f9ee0 
001f9ec0: 001f9ecc 00053b00 00053984 001f8000  001f9fd4 001f9ef0 001f9ee4 00053b50 
001f9ee0: 00053a60 001f9f94 001f9ef4 00054080  00053b44 32005500 00000004 00000000 
001f9f00: 00030001 0000ffff 00050cc8 001f9f2c  001f9f1c 000567a8 000551b4 00000000 
001f9f20: 001f9f7c 001f9f30 000576f8 0005675c  0068a000 001f9f98 00000000 001f9f98 
001f9f40: 0067ff78 20000013 000480a0 001f8000  0068a000 0014b1f8 00148000 0014a040 
001f9f60: 00170a40 001f9f94 00055710 00000000  00000000 0067ffd0 32005500 00000000 
001f9f80: 0067ffd0 00000001 00000000 001f9f98  00054ed8 00053ff8 00000009 00000000 
001f9fa0: 00000009 0004d03c 00000000 00000000  0067ffd0 00000001 0067ffc8 00000000 
001f9fc0: 00640004 00000000 00000000 0067ff88  0004d020 20010016 20000010 ffffffff 
001f9fe0: 001722c0 0019a904 00169884 0000005b  00000000 001fa000 00050e40 0004d04c 
Backtrace: 
Function entered at [&lt;00053974&gt;] from [&lt;00053b00&gt;]
 r7 = 32005500  r6 = 0000FFFF  r5 = 001F9FD4  r4 = 001F8000
Function entered at [&lt;00053a50&gt;] from [&lt;00053b50&gt;]
 r5 = 001F9FD4  r4 = 001F8000 
Function entered at [&lt;00053b34&gt;] from [&lt;00054080&gt;]
Function entered at [&lt;00053fe8&gt;] from [&lt;00054ed8&gt;]
 r7 = 00000001  r6 = 0067FFD0  r5 = 00000000  r4 = 32005500
Code: ebfcae37 e2440010 (e5961004) e1a03521 e59f20cc 
Kernel panic: Attempted to kill init!

The punchline is that that's the best result I've got in a lot of experimentation I'm not writing down here. The one common thread, once I got the binary format figured out, is this:

Unhandled fault: external abort on linefetch (F4) at 0x00000001
fault-common.c(97): start_code=0x700040, start_stack=0x67ffbc)

The 0x00000001 is the same throughout. I tried this suggestion and ran flthdr -s 65535 busybox to increase the stack size from 0x1000 to 0xffff -- same result. Then I came across this message, which says that there's something wrong, F4 is the message from the CPU's fault register, and I need to figure out what it is. However, I've also come across (and lost the links to) another post which suggested it was a paroblem with a particular version of uClibc. So that means paying proper attention to a toolchain, which I'd skipped over earlier. I'm currently trying to get the HRI toolchain going, so we'll see how that turns out.

No tags
Compiling NDISwrapper on Mandrake 9.1
2005-07-21 20:29:00

While compiling NDISwrapper on Mandrake 9.1, I ran into this error:

# ./configure -auto
checking for running kernel version...2.4.21
checking for ptserial...ptserial-2.4.7.c
checking for gcc...3.2.2
searching for kernel includes...found at /usr/src/linux/include
checking for modversions.h.../usr/src/linux/include/linux/modversions.h
checking for kernel_version...In file included from t.c:2:
/usr/src/linux/include/linux/version.h:1:28: linux/rhconfig.h: No such file or directory
./configure: line 1: ./t: No such file or directory
rm: cannot remove `./t': No such file or directory
** error
could not determine a proper UTS_RELEASE

This is how I got around it:

[root@localhost src]# ln -s /usr/src/linux/include/linux/rhconfig.h /usr/include/linux/
[root@localhost src]# ./configure -auto
checking for running kernel version...2.4.21
checking for ptserial...ptserial-2.4.7.c
checking for gcc...3.2.2
searching for kernel includes...found at /usr/src/linux/include
checking for modversions.h.../usr/src/linux/include/linux/modversions.h
checking for kernel_version...UTS_RELEASE is 2.4.21-0.13mdk
detecting your modem...found. Your modem is a i8xx type modem.
No tags
New version of QEMU
2005-07-26 04:19:09

Woohoo! There's a new version of QEMU out, and look what's there:

* Windows 2000 install disk full hack (original idea from Vladimir N. Oleynik)

Just trying it out now. With any luck, this'll let me run W2K at work w/o needing VMWare. (People have claimed they can get W2K installed on QEMU, but I've never been able to make it run.) I'll let all y'all know how it turns out.

1 comments. No tags
Upgrade and be damned!
2005-07-26 19:47:25

An hour playing around with Xine and MythTV, and what do I get? A DVD player that exits without any visible error at the menu screen two times out of three. And if that wasn't enough, pressing the menu button once will get you the Xine menu -- pressing it twice will get the MythTV splash screen, but the movie is still playing: the sound is there, but the video isn't. Holy crap. The last time this was happening, I'd rented Hero. All was going well, when I accidentally hit the Back button on the XBox remote; this dumped me back into MythTV. Annoying but no problem, right? Just start up Xine again, and...it crapped out after all the warnings about how copying DVDs makes Baby Jesus cry. Well, I was skipping those, so how about if I try sitting through them? Same thing. My memories are clouded by the red cloud of rage, but I believe I tried running Xine on my desktop machine with X forwarding on. I managed to get an error message about how this was an encrypted DVD, and I should look at getting libdvdcss (assuming it's legal in my jurisdiction). I already had this, of course. I tried removing the .libdvdcss files with the cached keys -- that took a while to track down -- but nope, same thing. I tried other players, too. gxine did the same thing, natch. mplayer dumped core (this was the Debian package, which I'd never tried using before; I didn't want to bother compiling it from source). Ogle was the only damned thing that worked, but I couldn't figure out how to make it do fullscreen. I didn't have these problems with the older version of Xine that was installed before I upgraded Xebian. Teach me to upgrade... On the plus side, though, I've figured out that (for Napoleon Dynamite at least) it does work with some persistance. It's a damned good thing I love Linux so much.

1 comments. No tags
Arghh, Billy!
2005-07-28 18:04:18

Somebody PLEASE explain to me why the W2K shell does not include a Windows equivalent of chmod by default, and why its closes equivalent, cacls, only comes with the $x00 resource kit. Here's what happened:

  1. Need to install OpenOffice as regular user...
  2. but the user had no permission to write in Program Files...
  3. so runas /user:Administrator explorer didn't work...
  4. so runas /user:Administrator cmd did work...
  5. but no cacls...
  6. so as Administrator, run cygwin.bat...
  7. and do mkdir /cygdrive/c/Program Files/OpenOffice.org...
  8. and do chmod 777 !$...
  9. and install and then set the permissions back.

Thank God for Cygwin.

Tags: windows.
Let's try and help Google a bit...
2005-07-29 17:39:20

If your W2K Pro computer hangs during boot with the message "Applying security policy..." but eventually (5-25 minutes later) boots, you may want to look at this link...worked for me today. One little bit of clarification: I found no .chk file in the Security folder. This doesn't appear to have hurt anything.

No tags
NWR04B: Toolchain problems
2005-07-30 06:38:28

I thought I'd give PTXDist (latest version: 0.7.5) a try in my continuing attempts to get a proper toolchain going. I'm running into problems, though, when it comes time to compile uClibc:

make[5]: Entering directory
`/home/aardvark/bin/ptxdist-0.7.5/build/crosstool-0.32/build/arm-uclibc-linux-gnu/gcc-3.4.2-uClibc-0.9.27/build-libc/libc/sysdeps/linux/arm'
arm-uclibc-linux-gnu-gcc  -Wall -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing  -fstrict-aliasing -Os -funit-at-a-time
-mlittle-endian  -fno-builtin -nostdinc -D_LIBC -I../../../../include
-I. -isystem
/home/aardvark/bin/ptxdist-0.7.5/local/arm-uclibc-linux-gnu/gcc-3.4.2-uClibc-0.9.27/lib/gcc/arm-uclibc-linux-gnu/3.4.2/include
-DNDEBUG -fPIC -c __longjmp.S -o __longjmp.o
__longjmp.S: Assembler messages:
__longjmp.S:36: Error: selected processor does not support `lfmfd
f4,4,[ip]!'
make[5]: *** [__longjmp.o] Error 1
make[5]: Leaving directory
`/home/aardvark/bin/ptxdist-0.7.5/build/crosstool-0.32/build/arm-uclibc-linux-gnu/gcc-3.4.2-uClibc-0.9.27/build-libc/libc/sysdeps/linux/arm'
make[4]: *** [arm] Error 2
make[4]: Leaving directory
`/home/aardvark/bin/ptxdist-0.7.5/build/crosstool-0.32/build/arm-uclibc-linux-gnu/gcc-3.4.2-uClibc-0.9.27/build-libc/libc/sysdeps/linux'
make[3]: *** [_dir_linux] Error 2
make[3]: Leaving directory
`/home/aardvark/bin/ptxdist-0.7.5/build/crosstool-0.32/build/arm-uclibc-linux-gnu/gcc-3.4.2-uClibc-0.9.27/build-libc/libc/sysdeps'
make[2]: *** [_dir_sysdeps] Error 2
make[2]: Leaving directory
`/home/aardvark/bin/ptxdist-0.7.5/build/crosstool-0.32/build/arm-uclibc-linux-gnu/gcc-3.4.2-uClibc-0.9.27/build-libc/libc'
make[1]: *** [_dir_libc] Error 2
make[1]: Leaving directory
`/home/aardvark/bin/ptxdist-0.7.5/build/crosstool-0.32/build/arm-uclibc-linux-gnu/gcc-3.4.2-uClibc-0.9.27/build-libc'
make: *** [/home/aardvark/bin/ptxdist-0.7.5/state/crosstool.install]
Error 2

Googling didn't turn up much, but what I found suggested that uClibc was being compilied for the wrong processor, and/or for a processor that had an FPU -- which I don't believe the ADM5106 in this thing does. When configuring PTXDist at the beginning, I'd certainly told it to use softfloat, and GCC appeared to be compiled with that in mind (thus the error). Sure enough, when I took a look at the .config file in the uClibc build directory, it was pretty wrong:

ARCH_LITTLE_ENDIAN=y
# ARCH_BIG_ENDIAN is not set
# ARCH_HAS_NO_MMU is not set
ARCH_HAS_MMU=y
UCLIBC_HAS_FLOATS=y
HAS_FPU=y

I'm not sure why the configuration details make it to GCC and not uClibc; I imagine it's a bug, though it could also be that I'm pointing PTXDist at my uClinux source tree...I wouldn't think that'd be a problem, but it's not supported. I'm not sure I have the patience to follow this through, though, so I may just leave it rather than file a bug (I'm a bad person, I know). One annoying thing about PTXDist is that make world, the do-it-all command, cleans everything out before starting, and there does not appear to be a make continue target to just keep going; it makes debugging things very difficult. I've been looking around at other scripts, and it's hard to find one that supports uClinux explicitly. I'm probably being superstitious, but I've had enough problems with toolchains that I'm reluctant to assume it'll work if I just drop in the uClinux sources. I may end up compiling my own ('cos that'll be easier...).

No tags

RSS Feed