> I did what you suggested. First, my Blade 2000 has mostly a standard > configuration. > The only non-Sun part is a Logitech MX-1000 mouse. It has 2*900MHz US-III Cu, > 2GB RAM, 72GB disk, DVD, Type 6 keyboard, and an XVR-500.
Looks more like a Sun Blade 1000. > Running /usr/lib/hal/hald --daemon=no --verbose=yes 2>hald2.log > gives a 34kb log file and hald-runner core dumps (signal 11 - segmentation > fault > in strlen()). I cannot attach the log file because attaching doesn't work for > me. > So, here is an extract of two suspicious entries and the last lines of the > log: hald-runner dumping is not a h/w probing issue. I can't reproduce this behavior on a similarly configured Sun Blade 1000 in our lab with snv_50 and vermillion 51. Did you install earlier HAL packages on this machine? Did you run install-jds with --force --ignore options? Did you see package install failures? What makes it harder for me to diagnose is that vermillion 51 contains an early development version HAL packages, dated 9/12. HAL was integrated in snv_51 on 10/12 - I cannot be sure if you're seeing a new bug or one that's been fixed since then. I would recommend to wait until build 52, when (I hope) HAL packages will be removed from the vermillion tarball. Then you can upgrade to snv_52 and install vermillion 52 on top of it and get all the right bits. Same trick won't fly with 51, because if you first upgrade to snv_51, then the vermillion packages will overwrite the new HAL with the old HAL. OTOH, if you first install vermillion packages and then upgrade to snv_51, it will overwrite the new GNOME with the old GNOME. To work around this, you would either need to BFU over vermillion or reinstall HAL-related packages after upgrading to snv_51 and installing vermillion 51 - but I don't know if you're into this particular kind of s&m :) -Artem.
