Re: Floppy on a Blade 100
On Wed, 2003-04-30 at 04:40, Ben Collins wrote: Bottom line: no floppy on ultralinux, no conversion :( For god sakes, man. Force these people into the 21st century. We have LAN's and email for file swapping. I can't think of one good reason to have floppies. Use CDR's instead if you need storage. Nostalgia? CDRs would be especially nice if there were some kind of file at a time mode. (Isn't something like packet writing and UDF supposed to handle that?) Another option is using a USB dongle. Much bigger than a floppy, much faster than a floppy, and fits in your pocket. (Unfortunately, only my work box has a USB connector in front.) I personally use the net and/or a laptop. Anything I'd hesitate before pushing over the net wouldn't fit on a floppy. I have used floppies in the last few years, but only for one of two things: debian boot floppies and grub - and that can easily be done with CD. Anyways, to answer Michael's other post: The floppy drive is hanging off the ISA bus, which I think makes it a little trickier to talk to, and I don't think anyone cares enough to make it work. Steve [EMAIL PROTECTED]
Re: Compiling Kernel 2.4.20
Jeff Pickell wrote: Sorry if I'm way off base on this one, but I've been paying around with different kernels (mostly the 2.4.18 stuff) on an Ultra I. When I've finished compiling the source, the resulting vmlinux file isn't compressed, just like you've stated. Just for grins, I used gzip to compress the file, then simply moved and renamed it to its proper place/name (/boot/vmlinux-011503). I recreate the symbolic link from /vmlinuz to my new kernel, check Silo.conf to make sure everything is pointing to where it should and I can then reboot without any problems. Since I've g'zipped the kernel, it's small enough, and the system knows to decompress it. Perhaps you might try the same thing with the 2.4.20 source. It doesn't matter if you compress it or not for the limit that I was hitting. (But it does help if you strip it.) There is a fixed size area of memory that second.b of silo/tilo uncompresses/loads into. If it hits the end of it before it's done, it fails. This isn't the problem I'm having though. I'm getting scheduling while atomic early in the boot process (right after the POSIX message) and dump_stack() isn't implemented on sparc64. -- Steve Dunham http://www.cse.msu.edu/~dunham
Re: Compiling Kernel 2.4.20
Steve Dunham wrote: Jeff Pickell wrote: Sorry if I'm way off base on this one, but I've been paying around with different kernels (mostly the 2.4.18 stuff) on an Ultra I. When I've finished compiling the source, the resulting vmlinux file isn't compressed, just like you've stated. Just for grins, I used gzip to compress the file, then simply moved and renamed it to its proper place/name (/boot/vmlinux-011503). I recreate the symbolic link from /vmlinuz to my new kernel, check Silo.conf to make sure everything is pointing to where it should and I can then reboot without any problems. Since I've g'zipped the kernel, it's small enough, and the system knows to decompress it. Perhaps you might try the same thing with the 2.4.20 source. It doesn't matter if you compress it or not for the limit that I was hitting. (But it does help if you strip it.) There is a fixed size area of memory that second.b of silo/tilo uncompresses/loads into. If it hits the end of it before it's done, it fails. This isn't the problem I'm having though. I'm getting scheduling while atomic early in the boot process (right after the POSIX message) and dump_stack() isn't implemented on sparc64. Fixed that one. (Managed to hack together a dump_stack()). It only happens if PREEMPT is set and SMP is not. (Now I'm getting a null pointer in bus_match() because it's being handed devices with bus set to null - I think I'll give up on running 2.5 on a Blade100 for now.) -- Steve Dunham http://www.cse.msu.edu/~dunham
Re: sparc64 and ipsec anyone?
Jean-Francois Dive wrote: I really thing it worth looking at the native linux implemetation in 2.5. I will upload openbsd isakmpd this week ported to linux. It does work on intel and i'll do some test on alpha and sun (well, i still cant install debian on my netra though). I bet the stack part'll be working on sparc64 as some of it have been written by David Miller. I decided to take a look at it today. I pulled down 2.5.59, but I'm still trying to get it to compile. Anyone know which 2.5 kernels compile on sparc64? -- Steve Dunham http://www.cse.msu.edu/~dunham
Re: Compiling Kernel 2.4.20
David Johnson wrote: unixed unixed wrote: 2) compile by hand. (make config) (make dep) (make modules) (make install_modules) (make vmlinux) It compiles fine, no errors, but the image is larger, and SILO complains that the image is too large (uncompressed image too large for space). I’ve seen hints from other users on this list to use bzImage to compress the file, but to me that looks like an x86 tool only because it is not in the sparc64 directory space… Hopefully someone out there can help me get passed this kernel build problem… I would be tickled to learn –any- way to get past it. As I understand it, compressing the image won't help at all since its the uncompressed image it needs to work with. You just need to include as little as possible in your kernel and as much as possible as modules to get it below the size limit. 2.4 kernels do tend to be a little bulky, you may well have to make do with a 2.2 kernel... Ten minutes ago I had the same issue. I went through and modularized everything I could (there wasn't much more I could modularize), rebuilt the kernel, and then realized I'd never tried stripping the one that was too big. :) (That said, the kernel didn't run .. I'd be interested to know if anyone has gotten 2.5.x to run on a Blade100. I'd like to debug/use the IPSec stuff.) Steve [EMAIL PROTECTED] -- Steve Dunham http://www.cse.msu.edu/~dunham
Re: sparc64 and ipsec anyone?
Ben Collins wrote: On Sun, Jan 26, 2003 at 09:35:03PM +0100, Daniel van Eeden wrote: Is it an sparc64 only problem or is ipsec also unusable on sparc32? The problem is specific to any arch where the userspace and kernel run different bitness. Like sparc64, where userland is 32bit (same for ppc64, mips64 and some other arch's atleast for a short time). Ioctl's from userspace have to be translated in this case from 32bit to 64bit. Those translations have to be done by someone, and no one has tried it yet. I actually did all of the changes about a year ago, but ran into other problems (I think DES was broken in some way, or the key wasn't making it in right). I didn't have time to debug it further, and I don't have the changes anymore. I may take a look again in the near future, because my firewall is sparc64 (the other option being to try to get 2.5 ipsec working on it), but I just moved, started a new job, and have way too much stress to work on it at the moment. Anyways, you have to write translators for the data structures passed in the ioctls. There are some examples in the kernel, it's not too tricky to do. Steve [EMAIL PROTECTED]
Re: Setiathome crashes Woody
Dan Koch wrote: Hi folks, I installed the most current setiathome package via apt-get also making sure I had all the upgrades for woody installed. I'm running it on a Sun UltraSparc2. Setiathome starts out ok and downloads the data files but as soon as it begins processing, the machine freezes up and I have to cycle power to regain control. Any ideas? Clearly a government consipracy to keep you from finding out about our visitors from other worlds. :) Nothing should freeze the machine like that. I assume Stop-A doesn't work either? Sounds like either a hardware or kernel problem. If you have another Ultra2, you might try putting the disk in the other machine to rule out hardware. Otherwise, you can try another kernel version to see if that helps out any. Steve [EMAIL PROTECTED]
The postgresql/libcrypto problem
I managed to narrow down the exact cause of the postgresql configure script failing to detect that long long is 64 bits on the Sparc. It seems that libcrypto.so is dynamically exporting __muldi3 and other symbols that it pulls in from libgcc.a, but v[89]/libcrypto.so do not contain these symbols. So the conftest.c compiles, but fails to load because of a missing symbol. My proposed solution (bug 167831) is to use a simple version script that makes symbols starting with __ local when linking libcrypto.so on the Sparc. This problem may occur with any other library that provides different versions for v8/v9. Steve [EMAIL PROTECTED]
Re: Postgresql and 64bit types...
On Fri, Oct 18, 2002 at 01:28:21PM -0400, Ben Collins wrote:
Weird. I compiled and ran the below program on my machine, and it worked
just fine. I'd call it a configure problems.
Ok, the problem is libcrypto.so, if you include that when you link and
run the program, you'll get:
./conftest: relocation error: ./conftest: undefined symbol: __muldi3
I'm guessing that openssl is linking libcrypto.so together by hand
(with ld), so it's not including the libgcc.a.
I'm thinking that a bug should be filed against openssl and
postgresql should be rebuilt after this bug is fixed.
Steve
[EMAIL PROTECTED]
On Fri, Oct 18, 2002 at 10:14:51AM -0700, Brian Macy wrote:
Yeah, thanks... I'm not very familiar with configure so I didn't know to
look there first.
checking whether long int is 64 bits... no
checking whether long long int is 64 bits... no
configure:7610: checking whether long long int is 64 bits
configure:7648: gcc -o conftest -O2 conftest.c -lssl -lcrypto -lz
-lcrypt -lresolv -lnsl -ldl -lm 15
configure: failed program was:
#line 7619 configure
#include confdefs.h
typedef long long int int64;
/*
* These are globals to discourage the compiler from folding all the
* arithmetic tests down to compile-time constants.
*/
int64 a = 2001;
int64 b = 4005;
int does_int64_work()
{
int64 c,d;
if (sizeof(int64) != 8)
return 0; /* definitely not the right size */
/* Do perfunctory checks to see if 64-bit arithmetic seems to work */
c = a * b;
d = (c + b) / b;
if (d != a+1)
return 0;
return 1;
}
main() {
exit(! does_int64_work());
}
--
Debian - http://www.debian.org/
Linux 1394 - http://www.linux1394.org/
Subversion - http://subversion.tigris.org/
Deqo - http://www.deqo.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Xsun, should fix non-root problems
Ben Collins [EMAIL PROTECTED] writes: Branden, Mike Renfro, and I worked on the Xsun problem (Branden and Mike mostly) and resolved the issue. Somehow an access() call crept in that incorrectly told the server that it did not have access to /dev/fb (man 2 access for why this is not good in this case). So, please try the 3.3.6-10 packages, they should resolve things. Actually, this bug crept up years ago, I had patched the server to fix it. Apparently the patch was lost somewhere between 3.3.4 and 3.3.6...
Re: Bootable sparc potato ??? help needed.
Jim Westveer wrote: Hurmph, In my zeal to update the debian-cd scripts for sparc, I first made changes to the debian-cd script tools/boot/potato/boot-sparc, so that it would write an El Torito bootable CD . Well duhh, that was stupid on my part! After recovering a bit (and taking a handfull of smart pills) I realized that if one wanted to make a bootable sparc CD image on an intel host, perhaps I should read up a bit on silo and intelsilo. Not being a 'sparc' guy, I'll admit that I am now only partially confuzed about how to do it. Therefore, I have put the file back to an original state, as I continue to mull over how to doit. So..i am looking for help If you could take a look at the file in the current CVS boot-disks that gets installed as: /usr/share/debian-cd/tools/boot/potato/boot-sparc Perhaps someone might have an idea on how to get it working with intelsilo. I think it is close. Actually, IIRC, intelsilo should work identically to silo (except that it refuses to do anything except CD's - won't do HD boot blocks). One thing to watch out for - the kernel and/or root.bin cannot be the last file on the disk. The prom can't read the last blocks from the disk. Steve [EMAIL PROTECTED]
Re: SS20 Default Color Depth
Weon-sun Lee [EMAIL PROTECTED] writes: [EMAIL PROTECTED] /root] cat /proc/fb 0 CGsix [EMAIL PROTECTED] /root] dmesg - skip here is fb0 infomation Console: switching to colour frame buffer device 128x54 fb0: cgsix at 2. TEC Rev 4 CPU sparc Rev b [TurboGX] --- skip - The Xserver use only 8 depth (eg, I'm use xsun and also xsun24) The cgsix is a 8-bit video card. To use the 24-bit video card, you need a special video module in the long memory slot. (There are two long memory slots, it goes in the one closest to the front of the machine.) Last time I checked, these video modules were expensive. Steve [EMAIL PROTECTED]
Re: XFree86 Problems
Michael Jean [EMAIL PROTECTED] writes: ok, heres two discrepencies i noted; i've never used X with an ultra, but.. Operating System: Linux 2.2.9 sparc64 [ELF] Configured drivers: Mach64: accelerated server for ATI Mach64 graphics adaptors (Patchlevel 0) (using VT number 7) Linux 2.2.9/64 Now, from your dmesg Linux version 2.2.1 ([EMAIL PROTECTED]) (gcc version egcs-2.92.11 19980921 (gcc2 ss-980609 experimental)) 2.2.1 v 2.2.9.. perhaps your X server is wrong? are you sure you're using the proper sparc ati server? just a thought Actually, the problem (rather obscure) is that he has a special add-on 24 bit card which is /dev/fb0 and XF86_Mach64 only looks at /dev/fb0. A few things to try: I think XSun24 from potato supports the other, better card, try it first. If not, try: rm /dev/fb0 mknod /dev/fb0 c 29 32 (Option #3 is to remove the special Creator graphics card, which another Debian user did a while ago, I like option #2 better, assuming it works.) Steve [EMAIL PROTECTED]
Re: How to do it? [Xserver]
Adam Di Carlo [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Artur Zaworski) writes: Sorry, I forgot something... last sec. of my Xsun ; + strace Xsun access(/dev/fb0, R_OK|W_OK) = 0 open(/dev/fb0, O_RDWR)= 6 ioctl(6, FBIOGATTR, 0x2cf4f0) = 0 ioctl(6, 0x80144604, 0x2c332c) = 0 This would make me think you perhaps are using the wrong X server? Which model of graphics card do you have (or Sun model if you don't know the card)? Which X server are you using? One of our binaries (I think the 3.3.3.x ones in potato, and an unofficial release of 3.3.2.3a) have the access() function call removed (by me) because it ignores suid status. You'll have to get a newer server, or chmod 666 /dev/fb0. Steve [EMAIL PROTECTED]
Re: uprgade from sparcstation 4 under redhat to debian
Carlos Barros [EMAIL PROTECTED] writes: [1 text/plain; us-ascii (quoted-printable)] I need some help as I dont know much about sun In my jobs there's a sun sparcstation 4 running redhat 4.* That sun only has 1 hard disk (scsi and not much space ~2GB) It has no CDrom, no floppy, but has ethernet. What you suggest to install debian 2.1 to that sparc You can install over the network, I do all of my sparc installs that way (except when I am testing CDs). There should be instructions in the sparc install manual (available online). Steve [EMAIL PROTECTED]
Re: netscape availability (where?)
[EMAIL PROTECTED] (Karan Bhatia) writes: hi, i have debian slink running on a sparcstation 2 (sun4m i think) and all is as it should be, except i can't find netscape 4.5 native for it. I have: 1. searched ftp.netscape.com extensively, it seems that last year they had a sparc-linux version in their unsupported directory, but they don't appear to have it there anymore. 2. tried installing the debian package netscape-base-45. This is just some utilities for netscape, not the actual binary for netscape. 3. looked at base/web for other netscape stuff and only found the help files and support files for java, _not_ the netscape executable. 4. found an rpm package netscape-common* and netscape-communicator*, converted it to debian using alien, and installed it. However, it seems the binaries are really for 64bit ultra's, not my little 32bit sparc. (when i run it, i get illegal instruction, maybe it is just corrupted, i don't know). I found it in the ultra subdirectory, i can't find a similar package in the sparc directory. There are no 64-bit sparc binaries for Linux. If you get illegal instruction, it's because netscape is buggy. If someone knows where i can get the binaries of netscape, could you let me know? thanks. I would be eternally greatfull. They are in the slink source packages. There are also binaries and source in RedHat 6.0. Steve [EMAIL PROTECTED]
Re: How to setup X?
Andreas Jaehnigen [EMAIL PROTECTED] writes: Hi everybody... How do I setup X correctly? :-O System is a Sun Sparcstation SLC with bwtwo graphics card. X definitely runs on it, because I managed to start X from a normal Debian installation. Now, I've to configure X by hand, and it doesn't work. The X server (XSunMono) is running, but the display stays black... Why is this? Can anybody explain some potential reasons (and maybe solutions)? Do you also have a white stripe down the left side of the display in console mode? I think bwtwo support is broken in 2.2.x kernels. Steve [EMAIL PROTECTED]
Re: Kernel questions...
Troy Tuttle [EMAIL PROTECTED] writes: I am having some trouble compiling a kernel (2.2.1)it gets to the point of compiling the actual kernel itself and then it dies with about 50 dereferenced pointer to an imcomplete type errorsI have tried using egcs and gcc with the same error both times I am running a SS1+ with 28 meg of ram..my installation is Slink...all the packages including src for 2.2.1 are from slink...and I am running 2.2.1 as my kernel.. If you are building from slink, you need the kernel-source-sparc-2.2.1 source package. Steve [EMAIL PROTECTED]
Re: Kernel questions...
Troy Tuttle [EMAIL PROTECTED] writes: I am using that src pkg...but still no luck... I'm not sure what's going wrong here. (Sounds like some include files are mixed up). You can try: make clean rm include/linux/modules/* make dep make Or, you could try the kernel-source-2.2.9 package from potato (and slink-updates). It fixes a denial of service problem in the network stack. Steve [EMAIL PROTECTED]
Re: Bug#40475: xserver-mach64 graphics view a bit funky
Branden Robinson [EMAIL PROTECTED] writes: On Tue, Jun 29, 1999 at 10:31:53PM -0700, Ivan E. Moore II wrote: With the latest update to my Ultra Sparc 5 system (binary-sparc) my graphics within X seemed to go astray. For the most part everything looks fine, except it seems that graphics aren't quite right. example: In netscape, hr tags show up as dotted lines...and when I quit out of my X session and the session manager pops up, I get bars across the screen. Is this problem present in all color depths? Please try as many different ones as you can. You might also jigger some of the more esoteric X server options for the mach64 (they're documented in the manpage). I'm guessing it's only 16-bit. The problem doesn't occur in Red Hat's server. I tried one possibly fix, but it didn't help. It will be a while before I can seriously look at (i.e. do a diff against Red Hat's code and carefully look at all of the differences). I suspect the problem is related to the fbdev patches. I have to pay some attention to starting my research, so it will be a while before I can take a look at the problem. Steve [EMAIL PROTECTED]
Re: Sparc problem - any answers???
Steve McIntyre [EMAIL PROTECTED] writes: I said earlier in the week: I've just started doing a new set of official sparc images on cdimage.debian.org and things are failing all over the place. I've checked up and the binary-sparc directories are full of sym-links to sid. Can somebody please explain this? At the moment this makes it impossible to make CDs... It shouldn't be impossible to make CDs, because it was in the same state when I made the official CDs, and everything turned out ok. (The slink-cd script flattened out all of the sid links.) The only time a problem should occur is if you haven't mirrored sid. As a clarification, this means that the _released_ sparc _slink_ distribution is unstable. I'd be very surprised to hear that this is the case deliberately, and if so I'd love to hear the reasoning for it. That aside, I believe we need to fix this and soon. Comments? The released slink distribution isn't unstable. sparc/slink is newer than sparc/sid, and sparc/potato is newer than sparc/slink. sid has been static since sparc was moved into stable. (And, yes, I do agree that slink shouldn't have symlinks into sid, just because it's difficult to mirror, and there is no reason for an extra, useless sparc tree, but it should still be possible to build CDs from a sid+slink mirror.) Steve [EMAIL PROTECTED]
Re: SPARC kernel questions
[EMAIL PROTECTED] writes: A couple of questions appeared in my mind while upgrading to 2.2.10: (1) This business of having to install /etc/init.d/devpts.sh from potato's libc6 to make a recent 2.2.x kernel work if CONFIG_UNIX98_PTYS is selected. It's not too hard to do by hand, but it doesn't seem right that people should have to do that sort of thing merely in order to use a more up-to-date kernel. You can't tell people to update their libc6 to unstable just in order to use a newer kernel; we've already seen how an unstable libc6 can make a system unusable in some unfortunate cases. So is there another solution, other than telling people how to extract and install /etc/init.d/devpts.sh by hand? Delete /dev/ptmx. libc6 only tries to use /dev/pts if /dev/ptmx exists, otherwise it falls back on the oldstyle ptys. I personally would just tell people to upgrade. This is not i386; slink for the sparc has a _beta_ version of the glibc-2.1 that is in unstable - there are very few problems, if any, in updating. If Debian did non-security updates, I would strongly advocate copying libc6 from potato to slink. (2) I built a kernel with CONFIG_SMP, which is the default, and was welcomed by this message (coming from linux/arch/sparc/mm/nosun4c.c): SILO boot: Uncompressing image... 32bit SMP kernel only supports sun4m and sun4d Program terminated Is there no way, at present, of building a kernel which does SMP on some suns but works on all suns? Apparently not. (SMP kernels are slower than non-smp kernels anyways.) Steve [EMAIL PROTECTED]
Re: continuing setserial problems
Adam Di Carlo [EMAIL PROTECTED] writes:
I've managed to get setserial 2.15-4 to compile (see the important bug
I filed with a patch), however, I get the following errors when
running it...
# setserial /dev/ttyS0
sys32_ioctl: Unknown cmd fd(3) cmd(541e) arg(ec20)
Cannot get serial info: Invalid argument
Is setserial's functionality just not supported in the Sparc Linux
kernel? Do we need to somehow disable it for sparc?
I always assumed it wasn't needed (and disabled it). The error
message that you included above will only come from the sparc64
kernel. (It is from the code in
arch/sparc64/kernel/{ioctl,sys_sparc32}.c which translates the
arguments of 32-bit system calls into 64-bit system calls.)
Since it is unhandled, either: it's not used on the sparc, or they
didn't get around to adding it. Since Red Hat 6.0 includes setserial,
I assume that it is useful on the sparc. They don't seem to have any
sparc-specific patches, though. (The sole patch removes the file:
#include linux/hayesesp.h
)
Steve
[EMAIL PROTECTED]
Re: MAJOR PROBLEM WITH SPARC CDS
Steve McIntyre [EMAIL PROTECTED] writes: I've just started doing a new set of official sparc images on cdimage.debian.org and things are failing all over the place. I've checked up and the binary-sparc directories are full of sym-links to sid. Can somebody please explain this? At the moment this makes it impossible to make CDs... Talk to the ftp guys. I complained about this weeks before the release of slink. Steve [EMAIL PROTECTED]
Re: Still errors in Ultra 5 installation
Adam Di Carlo [EMAIL PROTECTED] writes: Steve Dunham [EMAIL PROTECTED] writes: The egcs64 in potato is flakey, the one is slink might be flakey, and the one in Red Hat works (it's the one in slink with some additional patches, the one in potato is based on a much newer egcs). The kernel-image package mentioned above was compiled with the Red Hat egcs. (When I say flakey, I mean that the resulting kernel may slow down and eventually die when doing intensive stuff like compiles.) Yurgh. Oh well -- i have your stock 2.2.9 kernel working perfectly. Ok sure, I could probably save 200k of non-swappable RAM by compiling my own kernel. I must say, X11 performance on my Ultra 5 (Rage-64) is rather disappointing. Am I wrong in assuming that either a 64-bit X server, or other misc. optimizations in the linux kernel etc etc. should eventually lead to, um, I dunno, a 30% speed improvement? Or at least better interactive performance? I note in particular that the X server tends to really bog down under load... I doubt 64-bit code will do anything other than slow it down more. (Note that the kernel uses a special memory model, without this memory model it ran very slowly.) What kernel are you using? If you compiled it yourself, or didn't use the 2.2.9-2 kernel from potato, then the slowdowns/pauses in X are probably because of a bad code in the kernel due to a buggy egcs64. (The 2.2.9-1 kernel was compiled with the buggy egcs64.) Steve [EMAIL PROTECTED]
Re: Debian in Ultra 5
Marcelo E. Magallon [EMAIL PROTECTED] writes: On Tue, Jun 22, 1999 at 04:28:42PM -0400, Steve Dunham wrote: Try: rm /dev/fb0 mv /dev/fb1 /dev/fb0 *blink* why is that? we are going to be installing at least three sparcs in a couple of weeks (one Ultra 10, one Ultra 5, one Sparc 5, and _maybe_ one Ultra 20), and I'm gathering as much as information as I can :) Err, back off on that. I've only had one instance where this was needed. The UltraSparc (I think it was an Ultra10) had an additional special video card (some kind of super Creator 3d thing). It wouldn't work with the card in the machine because /dev/fb0 is hardcoded into the mach64 server and the extra card ended up being /dev/fb0. (The server needs /dev/fb0 to map the video memory.) Now that I think of it, the error message from that situation was something about not being able to do a sparse mmap(). The error message in this thread points to having an out of date kernel. (The newer ones export the memory map differently - allowing mapping of different endian aperatures, which the 3.3.3.1 X server needs.) Steve [EMAIL PROTECTED]
Re: Ultra and Linux usf readonly...
Steve Dunham [EMAIL PROTECTED] writes: Anders Hammarquist [EMAIL PROTECTED] writes: Neither one is answering my question! :) Oh, come now, it's only been 4 hours since your last mail... I installed Debian in a Ultra 5 and xserver-mach64 and the following error occurs: [snip] Fatal server error: xf86MapVidMem: Could not mmap framebuffer (Invalid argument) xinit: unexpected signal 2 My wild guess is that something is strange with your kernel (or possibly libc). What version are you using (and what if any patches have you applied to the kernel)? There are two possibilities: You don't have a 2.2.7 or newer kernel. You have extra video hardware that shows up as /dev/fb0 (the X server has /dev/fb0 hard coded into it - older versions had /dev/fb hardcoded.) As I mentioned in another message, this latter case gives a slightly different error message, something along the lines of not being able to do sparse mmap()'s. In Paulo's case, I'm quite sure the problem is an out of date kernel. (Paulo - I'm not sure why you can't compile a 2.2.9 kernel - Is it a clean source tree? Try the kernel-image-2.2.9 package from potato. It should fix the X problem. Then you can try downloading the kernel-source-2.2.9 package and building it, if you want.) Steve [EMAIL PROTECTED]
Re: Still errors in Ultra 5 installation
Paulo Henrique Baptista de Oliveira [EMAIL PROTECTED] writes: thanks for all the help yesterday, but I cant compile kernel yet. I tried with 2.2.9 and 2.2.10 from debian source package and it stops in the same point. And X still have error starting. I'm using 2.2.1 from slink install. Bellow is atached the output error from kernel 2.2.10 compile and X output error. Can anyone compile a kernel image 2.2.10 debian package from default config and send for me if the problem cannot be resolved? Thanks, Paulo Henrique test -f stamp-configure || make -f /usr/lib/kernel-package/rules configure make ARCH=sparc \ CROSS_COMPILE= vmlinux Do you realize that you are building a 32bit kernel, which won't run on your Ultra? You really should try the kernel-image-2.2.9-sun4u package to make sure that it fixes your X problem. To fix the kernel building, you can either build it yourself, or do: make clean rm include/linux/modules/* stamp-* make oldconfig make-kpkg --subarch=sun4u You also need egcs64 installed, I'd recommend the one from slink, or (even better) alien the egcs64 package from Red Hat 6.0. The egcs64 in potato is flakey, the one is slink might be flakey, and the one in Red Hat works (it's the one in slink with some additional patches, the one in potato is based on a much newer egcs). The kernel-image package mentioned above was compiled with the Red Hat egcs. (When I say flakey, I mean that the resulting kernel may slow down and eventually die when doing intensive stuff like compiles.) Steve [EMAIL PROTECTED]
Re: Debian in Ultra 5
Paulo Henrique Baptista de Oliveira [EMAIL PROTECTED] writes: Hi Steve, I installed Debian in a new Ultra 5 at school friday, but I'm a bit unhappy. I cant get X to work. I installed Debian in 2 Sparc 4, 1 Sparc 5 and 1 Sparc 20 before. All other machines I got X working. apt-get install xserver-mach64 Steve [EMAIL PROTECTED]
Re: Debian in Ultra 5
Try: rm /dev/fb0 mv /dev/fb1 /dev/fb0 Steve [EMAIL PROTECTED]
Re: Linux on IPCs and 1+s
Will Lowe [EMAIL PROTECTED] writes: client irc server on a 1+. Linux is faster than Solaris on these systems, but they are still only good for single service type applications, which sounds like what you want to do. They are very solid though (36 days uptime on the sparc 1 so far, the sparc 1+ last I looked had 82 days). Ok. Thanks. I'm also looking to use them in a mostly-solaris environment; my experience shows that the linux nfs implementation leaves some things to be desired. Are there problems with this? I use an Ultra 5 running Debian and a Sparc20 (currently running RedHat) without problems in a mostly Solaris environment (NFS home dirs, automount, NIS, etc.). Steve [EMAIL PROTECTED]
Re: Debian in a Ultra 5
Ivan E. Moore [EMAIL PROTECTED] writes: On Mon, Jun 14, 1999 at 04:57:25AM -0300, Paulo Henrique Baptista de Oliveira wrote: Hi all, 6 months ago or so, I pretend to install Debian in a Ultra 5 in my school, but I cant. No I can, but I think that slink was released and somethings changed. I tried a boot disk for sparc debian in Ultra 5 and didnt work. What is wrong? How to install? Thanks,Paulo Henrique I had issues installing from floppy on my ultra 5 as well...but I think it has something to do with how they have things setup here at work. I used the CD to install it and everything was happy. You can't boot floppies on an Ultra 5. (Rumor has it that it is possible on an Ultra1 with a PROM upgrade, but I haven't confirmed it.) Steve [EMAIL PROTECTED]
Re: Debian in a Ultra 5
Paulo Henrique Baptista de Oliveira [EMAIL PROTECTED] writes: So, how to install Debian in a Ultra5? Boot from the network or boot from CDROM.
Re: kernel patches and source
James Troup [EMAIL PROTECTED] writes: James Troup [EMAIL PROTECTED] writes: a) I have removed kernel-source-sparc-2.2.1 and the 2.0.35 and 2.2.0 patches on the basis that they're probably obsolete. If I'm wrong, now would be a good time to say so. I take that back, I see the latter two are new in potato, so I've leave them be. Are they really needed? The only UltraSparc kernel image in Debian is compiled from kernel-source-sparc-2.2.1 (a CVS kernel with some additional patches added). As soon as the i386 guys get around to uploading 2.2.9 (which needs no patches to run on all sparcs), I'll fix this. Steve [EMAIL PROTECTED]
Re: kernel patches and source
Ivan E. Moore II [EMAIL PROTECTED] writes: On Sun, May 30, 1999 at 11:15:25AM -0400, Steve Dunham wrote: The only UltraSparc kernel image in Debian is compiled from kernel-source-sparc-2.2.1 (a CVS kernel with some additional patches added). As soon as the i386 guys get around to uploading 2.2.9 (which needs no patches to run on all sparcs), I'll fix this. It's there now. :) (or at least it's in my package list) It wasn't there a couple of days ago. I've downloaded the source and I'm going to build the packages now. Steve [EMAIL PROTECTED]
Re: kernel patches and source
James Troup [EMAIL PROTECTED] writes:
Steve Dunham [EMAIL PROTECTED] writes:
The only UltraSparc kernel image in Debian is compiled from
kernel-source-sparc-2.2.1 (a CVS kernel with some additional patches
added).
This is serverly wrong. The kernel-patch mechanism works and exists
for a reason; we do not need or want to bloat the archive with
redundant copies of the none-too-small kernel-source*.{tar.gz,deb}.
I know this, but at the time I had not figured out how to get
kernel-package to generate both sun4u and sun4[cdm] kernels (hence I
needed my own rules file) - kernel-package was subsequently fixed (and
broken again - I'm not sure what the current state is).
I repeated asked for someone to take the kernel package off of my site
and do a correct kernel-package version, but I got no takers. Thus I
was forced to make the custom package, so we would have some source
for the kernels in slink. (There was no 2.2.1 source for other
architectures, so this wasn't that big of a deal.)
Note that since then I have gotten kernel-package to nicely generate
sun4u kernels, and the necessary sparc patches have been integrated
into Linus' source - but we haven't had a stock source tree that ran
well on all machines until 2.2.9.
As soon as the i386 guys get around to uploading 2.2.9 (which needs
no patches to run on all sparcs), I'll fix this.
It's already there.
Recently added to the archive - it wasn't there a couple of days
ago. (I was told by the maintainer that it would be uploaded two weeks
ago.) I'm building the kernels now. (sparc64 is done, I'm now doing
sparc and the headers.)
Steve
[EMAIL PROTECTED]
Re: pseudo tty ssh
Kumsup Lee [EMAIL PROTECTED] writes: Yes, I had same problem. I disable the UNIX98 ptys support in the 2.2.9 kernel. Now, it is working as it should be. Is there any better way to fix this problem ? If you have UNIX98 pty support in the kernel and /dev/ptmx exists, then you must mount the devpts filesystem on /dev/pts, and /dev/ptmx must have 0666 permissions. (World writable.) This is done by /etc/init.d/devpts.sh, but it might be missing from older revisions of the Debian glibc package. Steve [EMAIL PROTECTED]
Re: New Kernels (Was: new bootdisks available for testing)
Eric Delaunay [EMAIL PROTECTED] writes: Steve Dunham wrote: Eric Delaunay [EMAIL PROTECTED] writes: Hello Steve, I got your 2.2.8 kernel images. I will try to package another bootdisks set next week based on them. I already downloaded kernel-image-2.2.7*_cvs.19990507_sparc.deb last week. Are you updated them without changing their name ? No, I think they're there because of a cp kernel*deb. btw, there is a 2.2.7 kernel image in the parent directory but I can't access to it: too restrictive permissions. Is it this one I have to download ? I thought I had copied the updated kernel-image to the kernel directory, but it ended up in the parent directory, so I missed it when I chmod'd the files. It should be in the kernel directory, with correct permissions. I suspect that there are serious problems with the 2.2.8 kernel, so you might want to go with the 2.2.7 ones. (I will try 2.2.9 RSN - Herbert Xu promised to upload an x86 package last sunday, but hasn't done so.) Steve [EMAIL PROTECTED]
Re: New Kernels (Was: new bootdisks available for testing)
Anton Blanchard [EMAIL PROTECTED] writes: I suspect that there are serious problems with the 2.2.8 kernel, so you might want to go with the 2.2.7 ones. (I will try 2.2.9 RSN - Herbert Xu promised to upload an x86 package last sunday, but hasn't done so.) 2.2.7 hangs during booting on some sun4m machines. It would be a good idea to go with 2.2.9 if possible. The 2.2.7 that we are referring to has a patch to fix this. But I'd like to go with 2.2.9 so we can use pristine source. Steve [EMAIL PROTECTED]
Re: how to create a bootable CD
maxime baudin [EMAIL PROTECTED] writes: On Sun, Sep 04, 2022 at 05:40:18PM -0500, Chuque Berry wrote: I just D/L the iso image for one of the mirrors and then burnt that to cd .. worked like a charm. I did, but I like to make an special ISO CD image... Ok, let's ask in another way: does Sun boot prom support El torito ?? No. Sun was booting from CDs long before El Torito was invented, and El Torito is a rather silly way to do it. (Necessary on PC's because the BIOS is rather simple minded.) If not, how to make a bootable ISO image for Sun ? You need to use silo to make the CD image bootable. Get the slink-cd package from potato, and look at how it makes the CD. (There should be some info in /usr/doc/silo too.) Make sure that neither the kernel, nor the initial ramdisk is the last file on the CD, otherwise it won't boot. If you're using an x86 machine, you can get intelsilo from: http://www.cse.msu.edu/~dunham/debian/silo Steve [EMAIL PROTECTED]
Re: libc5...pro or con...
Ben Collins [EMAIL PROTECTED] writes: Currently I have an opinion on libc5 in sparc. 1) our current libc5 is pretty broken (I can't seem to get too many libc5 binaries to work with it), it makes xfree86-1 build fail when doing the libc5 compat xlib, 2) the latest libc5 wont compile for sparc (the build doesn't even support a sparc config). I'm building xfree86-1. There is an additional patch that is needed to fix a problem on the PCI UltraSparcs. There are binaries on my ftp site, I will upload them to master as soon as I get a compatible kernel uploaded. The libc5 stuff compiled without incident for me. Not to mention that _a lot_ of builds with libc5 compat builds are failing due to this fact. Are you using an UltraSparc? Our libc5 ld-linux.so is not compatible with Ultras. Steve [EMAIL PROTECTED]
Re: glibc2.1 and potato
Ben Collins [EMAIL PROTECTED] writes: On Fri, May 14, 1999 at 02:07:20PM +0530, Sanjeev Gupta wrote: On 13 May 1999, Steve Dunham wrote: Yeah, glibc should work fine on sparc32 machines with a recent kernel, there is a patched 2.2.7 kernel and a 2.2.8 kernel at: http://www.cse.msu.edu/debian/kernel It works!! It was nice to see the machine boot normally again ;-) Ben, could you release libc 2.1.1-6 now? Well it's going to be 2.1.1-5.1 since I can't raise major releases :) I also had success with 2.2.8 and glibc 2.1.1 on a sun4m. We need these in the distribution however and the bootdisks will need them aswell, but I'll get the glibc uploaded in the meantime. Herbert, I see that you are the maintainer for the kernel packages. I was wondering when you were going to upload the 2.2.8 kernel. This is desperately needed for the sparc, and I didn't want to upload the sparc specific stuff before you uploaded the source package. Steve [EMAIL PROTECTED]
Re: www.debian.org/ports/sparc updated
Adam Di Carlo [EMAIL PROTECTED] writes: I've updated URL:http://www.debian.org/ports/sparc/. My changes (WML) might take a few days to push out into the web mirrors. Could we put a link on the :http://www.debian.org/ports/sparc64/ page that points to the ports/sparc page? This is what the original problem was. (People with UltraSparc's not looking at the sparc page because the ports/ page points them to sparc64. Steve [EMAIL PROTECTED]
New Kernels (Was: new bootdisks available for testing)
Eric Delaunay [EMAIL PROTECTED] writes: This is because pci support is compiled into the kernel. I had some crash problems on my sc2000 involving loadkeys with a kernel like this, so I guess it isn't the best idea for the default kernel to contain pci. Anyway, what sparcs have pci buses ? Ultra/AX motherboard ? BTW, I added support for PS/2 style keyboards for this card, but if there is no PCI support in the default kernel, it seems to be useless. Am I wrong ? The I think the issue is only with sparc32 kernels - the only PCI sparc32 machines that I know of are the javastations. I've disabled the PCI PS/2 stuff in the sparc32 kernel. There is a new kernel at http://www.cse.msu.edu/debian/kernel I've included both an updated 2.2.7 cvs kernel and a 2.2.8 kernel (which has the nice advantage of being built from unaltered Linus source). Steve [EMAIL PROTECTED]
Re: glibc2.1 and potato
Samuel Tardieu [EMAIL PROTECTED] writes: On 12/05, Ben Collins wrote: | All the new packages will run with slink's glibc, they are perfectly | compatible. Please report any problems to the contrary as we are set on | having this compatability. Btw, I am running glibc2.1.1-2 on my Sparc10 (Sun4m) without any apparent problem (as long as I don't try to use nscd). I have a 2.2.7 with the break patch. Yeah, glibc should work fine on sparc32 machines with a recent kernel, there is a patched 2.2.7 kernel and a 2.2.8 kernel at: http://www.cse.msu.edu/debian/kernel Steve [EMAIL PROTECTED]
Re: [NOTICE] libc6 problems (Re: libc and other things)
Ben Collins [EMAIL PROTECTED] writes:
On Thu, May 06, 1999 at 01:19:41PM -0700, [EMAIL PROTECTED] wrote:
Yeah... it seems as though the LX is the un-4m... :)
I've heard of people having audio working on the LX (with DBRI,
same as the 10 and 20, but I don't hear a peep outa my SS10).
A coworker also told me that X runs nicely in RH 6.0 on his LX,
while it croaks within 5 minutes on my SS10. (I'm dual-booting
RH and Debian.)
But yeah... it remains that 2.2.7 does not work on my machine.
After SILO, maybe a line or two is printed out (I'm not near
my machine at the moment), and the machine locks up hard (no
Stop-A's to save me)...
I have an LX that will not boot 2.2.7, and it is not compiled with ay
audio support.
Can we get a break down of the compilers used? I've tried egcs 1.1.1
and gcc 2.7.2.3.
As is mentioned in another posting, a bug was just discovered in the
kernel which is causing this (a linked list is being screwed up). On
the vger mailing list people are suggesting that the problem is
dependent on memory configuration.
Hopefully this patch will soon make it into CVS and into a stock,
upstream kernel. I'd like to keep our kernels synchronized with the
other platforms. However, I will compile a patched kernel and put it
up on my local ftp/http site.
Steve
[EMAIL PROTECTED]
Index: arch/sparc/mm/iommu.c
--- arch/sparc/mm/iommu.c 1998/04/15 14:58:37 1.9
+++ arch/sparc/mm/iommu.c 1999/05/07 05:32:04
@@ -118,6 +119,7 @@
if (ia[i].addr = ia[l].addr) {
ia[i].next = l;
ia[m].next = i;
+ break;
}
if (l == -1)
ia[m].next = i;
Re: ypbind fix?
Max [EMAIL PROTECTED] writes: Has anyone been able to find a fix for the dreaded ypbind hang? From the mailing list archives, I understand that using either ypbind-3.3 or ypbind-mt-1.4 will solve the problem, but neither one is available in a Debian package. So, would the maintainer be willing to upgrade the nis package? If not, can someone supply me with a compiled version of ypbind? I have an old SPARCStation 2 with a tiny amount of disk space that prevents me from installing gcc and compiling it myself. I've never had any problem with ypbind and I've been using Debian/Sparc with a NIS setup since December. I'm currently using the nis_3.3.1-1 package from slink. Steve [EMAIL PROTECTED]
Re: ypbind fix?
Max [EMAIL PROTECTED] writes: [1 text/plain; us-ascii (quoted-printable)] * Steve Dunham [EMAIL PROTECTED] [05/04/99 11:30] wrote: Max [EMAIL PROTECTED] writes: Has anyone been able to find a fix for the dreaded ypbind hang? From the mailing list archives, I understand that using either ypbind-3.3 or ypbind-mt-1.4 will solve the problem, but neither one is available in a Debian package. So, would the maintainer be willing to upgrade the nis package? If not, can someone supply me with a compiled version of ypbind? I have an old SPARCStation 2 with a tiny amount of disk space that prevents me from installing gcc and compiling it myself. I've never had any problem with ypbind and I've been using Debian/Sparc with a NIS setup since December. I'm currently using the nis_3.3.1-1 package from slink. That's strange. Search through the debian-sparc archives for ypbind to see a description of the problem. To summarize, ypbind hangs if you don't specify the -debug -broadcast options. Apparently, this bug only exists in ypbind-mt-1.3 (the version in nis_3.3.1-1). I'm not sure how you were able to get around it. Dunno, is your /etc/defaultdomain set? Does your the /etc/yp.conf file contain any un-commented lines? Steve [EMAIL PROTECTED]
Re: KDE 1.1 on debian/sparc
[EMAIL PROTECTED] writes: [repost: original sent on 27th.April, but had problems getting through] It got through, I just didn't reply, we've had enough KDE flamewars. In a message dated 23/04/99 19:09:17, Steve Dunham wrote: Rick Tan [EMAIL PROTECTED] writes: Is KDE 1.1 available for debian/sparc? If so, where can one get the packages? I don't even think it's available for i386 at the moment. Aside from not being free, it's not entirely clear whether it is legal to distribute or not. My understanding is that it's completely legal to distribute, due to the Qt authors having announced an open style license (disagree ?). I think the issue is that the new license conditions don't quite tally with Debian's definition of free. One of the issues is that some of the KDE programs take GPL'd code from other sources (e.g. ghostview). And they can't just go and change the license on other people's code. The new open style license on Qt means nothing until they actually release a version of Qt that is covered by the license. (The old versions of Qt are not covered by the new license - I have no idea why Troll Tech made that choice.) Even if there were i386 packages, there probably wouldn't be any sparc packages because of lack of resources and interest. (The sparc people are busy compiling other things.) What - like X and Gnome ? I appreciate that the Sparc people are mucho busy, but I think there would be a *lot* of interest in KDE-for-Sparc. In particular, we'd be interested, as we run a Sparcstation 20 under Redhat-sparc 4.2 at work, and need to update to a more up-to-date Linux. I'm *really* hoping it will provide KDE for Sparc. The RH6.0 announcement does mention both KDE and Gnome. RH 6.0 does have KDE. I tried it out, saw nothing useful that I wanted, and deleted the KDE packages to reclaim disk space. I'm not wasting my time compiling it - the little spare time I have is better spent on things that I want and things that can actually go into the distribution. There obviously isn't much interest in KDE by the people who can actually build packages, or there would be some available by now. If the licensing issues are ever cleared up and KDE makes it into the dist, then the sparc autobuilders will take care of it. Of course, if Sparc Slink were production-ready, I'd rather go with that (that's why I read this list), but it doesn't seem to be. Am I wrong ? Slink has worked since december for me. If production ready means that it has KDE, then RedHat 6.0 is what you want. I don't have the skills to help out, so I'm afraid I'm just lurking here. There are, however, some gnome 1.0 packages, which took a bit of effort to compile. I encourage everyone .. [snip] Everyone seems to be saying Gnome 1.0 has been a bit premature ... Not being a tad partisan here are we ? I'm a volunteer, I package the software that I want. I occasionally do additional work, like merging the accelerated Creator support and LEO support into our X package, making the official CDs, or help fix glibc on old kernels, but it's my time, I can do what I want. It's rather annoying, after sinking 100's of hours into this project, to have someone come along and demand I compile software that I have no use for and is not even free. I have built package that were non-free or non-distributable (in fact, I'm the Debian maintainer for dungeon), but it has all been stuff that I wanted. Steve [EMAIL PROTECTED]
Re: [sparc] new bootdisks coming soon
Adam Di Carlo [EMAIL PROTECTED] writes: Eric Delaunay [EMAIL PROTECTED] writes: I just now need new 2.2 kernel images for sparc. Which one are available now ? 2.2.6 ? 2.2.7 ? Slink proposed-updates already has 2.2.5. Let's stick with that, it's known to be good. Do you need me to make an image? If so, I just gotta find the kernel config files used for 2.2.1 somewhere... They should be in /boot in the respective packages - they are also in the debian dir of the source package for those kernels. It might help to make sure LEO support is enabled in the sparc32 kernel. (If there is an option in 2.2.5. Build the ultra kernel with: make-kpkg --subarch=sun4u --arch_in_name kernel_image (If you build this after the 32-bit one, make sure you remove stamp-configure first - and it wouldn't hurt to make sure include/linux/modules is empty.) Oh, and the 2.2.5 kernel _might_ not work with the 3.3.3.1 X servers (when I release them) on some machines - I'm not sure when the appropriate patches were applied. (The trouble would be with Ultra's and maybe LEO machines.) Steve [EMAIL PROTECTED]
Re: glibc, X11 and the rest
Christian Meder [EMAIL PROTECTED] writes: Hi, finally I caught up with normal life again; maybe slightly more noisy than before ;-) Ben is putting a lot of work in the glibc update and I'm glad that he took over the package compilation. Thanks. I read the glibc thread with interest and I've got just some random remarks: It's ok that the old sparc patches were dropped because they were just compatibility hacks for the 2.0.x kernels. Potato will be pure 2.2.x on Sparc. But I'm slightly worried about the upgrade path. If we really depend on a kernel 2.2.7 we'll need a glibc preinst script on Sparc which bails out on older kernels (uname). Ben, do you know what's the init problem ? Maybe we can fix it instead ? I believe that the issue is that vfork is broken on some sparc32 machines (at the very least sun4m) in the earlier 2.2.x kernels. I suspect that a possible workaround would be to point vfork() at the fork system call, _and_ tweak any other functions that use NR_vfork internally (I think pipe() does). Steve is integrating the Creator patches in our new XFree source package which is great. The co-sysadmin at my university department here in Stuttgart compiled a patched Xsun24 for our own testing. It's definitly fast. In case somebody is interested in testing it on their Ultras I put the gzipped server at ftp://pc5.isr.uni-stuttgart.de/debian/Xsun24.gz This is only for the impatient otherwise wait for the _true_ packages by Steve ;-) I've already got real packages that need testing at: deb http://www.cse.msu.edu/debian slink x3331 They add LEO and accelerated creator support. And I've included Debian versions of the splashscreen images. Steve [EMAIL PROTECTED]
Re: glibc, X11 and the rest
Ben Collins [EMAIL PROTECTED] writes: On Fri, Apr 30, 1999 at 12:22:02AM +0200, Christian Meder wrote: Hi, finally I caught up with normal life again; maybe slightly more noisy than before ;-) Good to hear from you again :) It's ok that the old sparc patches were dropped because they were just compatibility hacks for the 2.0.x kernels. Potato will be pure 2.2.x on Sparc. But I'm slightly worried about the upgrade path. If we really depend on a kernel 2.2.7 we'll need a glibc preinst script on Sparc which bails out on older kernels (uname). Ben, do you know what's the init problem ? Maybe we can fix it instead ? Yes, the only thing we have is a glibc 2.1pre compatibility patch for the [EMAIL PROTECTED] symbol, new compiles will completely ignore this. As far as the kernel 2.2.7 issue, it's only pertinent to sun4m and I think sun4d (confirmation?). I have already setup a preinst addition that checks /proc/cpuinfo for this and then checks for uname -r and compares the version. It fails if requirements are not met. We did try a vfork patch, but it reportedly did not work. We have not seen any other patches that might fix this, but since I am not even close to uploading glibc 2.1.1 into the archive, we still have time to test, and I'm willing to try. Recompiling init does not work, btw. IIRC, somewhere in sysdep tree leading up to sparc32, there is a vfork.c that defines vfork to call fork. If you put this in the sparc32 directory and apply the NR_vfork patch for pipe() (or whatever that vfork patch was for), then the problems might go away. If I find time tomorrow (err, friday), I'll download your glibc source and take a look. Steve [EMAIL PROTECTED]
glibc 2.1.1 linking problems
It's your favorite debian developer again. :) Your glibc chown hack has one minor problem: Old libraries which reference chown@@GLIBC_2.1 won't link (compile time) with the new libc. (The load-time linking works fine.) This probably isn't too give us _too_ much trouble, but the following will have to be recompiled: libguile.so.3 libguile.so.4.0.0 libpwdb.so.0.54 librpm.so.1.0 libtck8.0.so.1 On the affected libraries, objdump -T will include: DF *UND* 00a4 GLIBC_2.1 chown Note that the current versions of the libraries will work with the new glibc, but you won't be able to build new programs using both the current versions of the above libraries and the new glibc. Steve [EMAIL PROTECTED]
Re: glibc 2.1.1 linking problems
Ben Collins [EMAIL PROTECTED] writes: On Mon, Apr 26, 1999 at 07:12:29PM -0400, Steve Dunham wrote: It's your favorite debian developer again. :) Your glibc chown hack has one minor problem: Old libraries which reference chown@@GLIBC_2.1 won't link (compile time) with the new libc. (The load-time linking works fine.) Interesting, I hadn't noticed it really. This probably isn't too give us _too_ much trouble, but the following will have to be recompiled: libguile.so.3 libguile.so.4.0.0 libpwdb.so.0.54 librpm.so.1.0 libtck8.0.so.1 Ok, this will not be too hard once I finish setting up the permanent wanna-build/buildd for sparc. So does compiling with this egcs/glibc still run on RedHat? I don't have a RH box to check this at the moment, but I doubt there is a problem. The problem that I referred to was the RH binaries wouldn't run on Debian, because of a missing register_frame_info symbol in our libc. But apparently our libc now has this symbol, so there shouldn't be a problem. Steve [EMAIL PROTECTED]
Re: LEO support and accelerated creator support
Ben Collins [EMAIL PROTECTED] writes: Well I now have a recompile of the glibc 2.1.1 libs using the egcs 1.1.2 where I modified 2 lines to remove the WEAK symbol of __register_frame_info. The symbol is still defined, but now I can compile apps on the new lib and they still run on a glibc 2.0.105 system so the shlibdeps are now =2.0.105. The egcs 1.1.2 and glibc 2.1.1 are at: http://master.debian.org/~bcollins/glibc/ I'm downloading the library and gcc now. (It should help with the 3.3.3.1 X build - one directory of code has to be built with egcc.) Steve [EMAIL PROTECTED]
Re: autobuilder...glibc 2.1...egcs 1.1.2
Ben Collins [EMAIL PROTECTED] writes: In case you haven't noticed, I've setup an autobuilder for sparc and have compiled some 500+ packages over the past few days. We were initially at onl 53% sync with potato, we are not slightly over 89%. There are a few more gnome packages I need to get out. I am going to post failed builds here for you people to take a look at if you desire. Send the relevant patches to the package maintainer and buildd will pick it up on the next upload. Now onto glibc. There is a new upload of 2.1.1-1 in unstable. I am going to try and build this. I'll need the usual fool hearty sun4m volunteer when it's done :) Question. Are we prepared to move to egcs 1.1.2 for potato? This means that egcs becomes the default gcc, although gcc 272 will still be available. I'm all for it, have it compiled. Unless some one can give me a reason not to, I'll upload it in the morning. Yes! I've been waiting a long time for this - gcc 2.7.2 should _never_ be used on the sparc, it can produce bad code in quite a few instances (I've already had to hack binutils to use egcc on the sparc.) I'm surprised the i386 (which has less of a problem) beat us to the punch. (I also need egcc to build the X source - because gcc can't generate some of the instructions for the newer sparc chips (32-bit even).) Steve [EMAIL PROTECTED]
Re: Sun prices
[EMAIL PROTECTED] writes: Sorry to be slightly off-topic, but does anyone have any recent experience of how much second-hand Sun computers are worth? If so I'd be grateful for any data points (model and price) as there's a whole lot coming up for auction here soon and I might try to get one. The machines to be sold include: SS LX, SS 4, SS 5, SS 20, Ultra Enterprise, Ultra Creator, Ultra 6262, Ultra 10 (according to the catalogue which does not seem to have been compiled very carefully). Look at www.gstek.com and www.compsyscon.com - they should give you a ballpark figure for some of these systems. Steve [EMAIL PROTECTED]
Re: Xserver with Debian
Alexander G. Carver \[Data\] [EMAIL PROTECTED] writes: I've been trying to install the 8bit xserver on my IPX for over a week now but it doesn't work. I'm trying to use version 3.3.2.3a-11. I've already tried to install it with dselect and with dpkg but both times it has a problem locating the /etc/X11/Xserver file. The file doesn't exist and, even if I use touch to avoid the error, more errors pop up. Can anyone recommend anything to help me install xserver-xsun? This file should be installed by the postinstall script of the xserver-common package. If this package is already installed, try doing: rm /etc/X11/Xserver /var/lib/dpkg/info/xserver-common.postinst configure /var/lib/dpkg/info/xserver-xsun.postinst configure Steve [EMAIL PROTECTED]
Re: LEO support and accelerated creator support
Ben Collins [EMAIL PROTECTED] writes: On Sun, Apr 25, 1999 at 02:02:04PM -0400, Steve Dunham wrote: XFree86_3.3.3.1-0pre1v3 with accelerated LEO support and accelerated FFB (Creator) support added. It needs a kernel with LEO support compiled in, and it was compiled against your libc-2.1.1, so sparc32 users will have to use the 2.2.7 kernel or build their own. OH NO! I am recompiling Glibc 2.1.1 and egcs 1.1.2. Seems that by using the standard egcs 1.1.2 we lock ourselves into binary incompatibility with slink for anything new compiled due to some odd egcs regsiter_frame_info thing. I am fixing this and going to have a new set of egcs and glibc 2.1.1 packages later today. This will keep everyone from being forced into a complete potato upgrade if they want packages from potato. We might just want to bite the bullet and do the register_frame_info thing. It has been done on intel, and it is necessary for compatibility with Red Hat 6.0 (and perhaps Red Hat 5.2). I suspect that if Netscape ever compiles against glibc 2.1 for the sparc, it will require this symbol from glibc. They may be forced to upgrade anyways - I just compiled XFree against the package and it picked up a libc6 (= 2.1) dependency. (Presumably from the libc6.shlibs file.) Steve [EMAIL PROTECTED]
Re: Boot from CD is a no-go
Christopher Reid Palmer [EMAIL PROTECTED] writes: Steve Dunham wrote: [snip death on loading the initrd from CD) Should be fine if it loaded the kernel without problem. (It hasn't actually started the kernel, has it?) This is what I get: 1. Welcome message and boot prompt 2. Loading kernel... [spinning cursor] 3. Loading initial RAM disk... [spinning cursor] 4. Data Access Exception 5. OK prompt So, I dunno. The only thing that would seem to make sense would be if my memory was bad (it checks out fine with the PROM's diagnostic tool), or if the kernel for some reason hates some part of my hardware. But I can't think of a way to figure out what piece of my hardware might be hate-able, besides using the PROM's diagnostics. Everything checks out fine there (SCSI bus, memory). Red Hat Linux 5.2/Sparc's HCL lists the ELC as 'Tier 2' supported. I don't see a reason for Debian to be any different; my thinking was, 'Okay, the ELC is supported by Sparc Linux; Debian is just one distribution'. I guess I could try Red Hat, but I don't really feel like spending $50 or trying to do an fTP install. I'm not sure what is going wrong here. I'd recommend trying both the linux and linux-2.2.1 kernels. Yes. I tried both, and got the same thing both times. If all else fails you could try booting from the network and then use the CD. But it would still need to load the RAM disk image from the CD-ROM, and that's what fails. Ultimately, this will be a net-booting machine that gets its / filesystem via NFS from my Linux/x86 system, but I need a way to get the distribution off the CD. No, the network boot image contains both a kernel and the initial ramdisk. The i386 box would provided the address to the sparc via RARP and the tftpboot image via tftp. Since the initial plan (boot from CD and install to an external HDD, serve the external HDD from the x86) seems doomed, I wonder if I can just extract the files I need by hand from the x86 to another disk on the x86? Has anyone done this before? The readmes on the CD didn't have anything to say about this. You could do this, but you have to make a sun disklabel on the disk (instead of a DOS partition table) with the hidden s command in fdisk, and you would need to use intelsilo to install the bootloader on the hard drive. (The intelsilo package isn't in the Debian distribution yet, and I've never tested it on a hard drive.) I'd recommend trying tftp booting first. There are some instructions at: http://www.cse.msu.edu/~dunham/debian/sparc/install.html You will need RARP support in your kernel on the intel machine - either compiled in or load the rarp module. You will also need the: dists/slink/main/disks-sparc/current/tftpboot.img file from the CDROM (which is a normal ISO9660 image). I am dunham on #debian at irc.debian.org most evenings (EST), and I can walk you through this if you have trouble. (Most of the installs I do are tftpboot installs.) Steve [EMAIL PROTECTED]
Re: How Stable for the Debian-SPARC?
Man H. Tam [EMAIL PROTECTED] writes: I am new to the Linux community and I am trying to find a stable Linux distribution to install on my Sparc5 station. I read your web site. You mentioned that Debian - Sparc is almost stable state. How stable comparing with the RedHat distribution? It is quite stable. It is just as stable as RedHat, except we have more stuff, and we have support for UltraSparc (but RedHat will add UltraSparc support when RedHat 6.0 is released tomorrow). Will it support RPM installation process? We use a different package format called .DEB, but we have similar features. Where I can get instructions on how to make a bootable Floppy/CDRom for your distribution? Making a bootable CDROM on the sparc is a little tricky, the best thing to do is to download the ISO image from on of our sites (start and http://cdimage.debian.org/ and choose a mirror near you.) Installation instructions are at: http://www.debian.org/releases/slink/ Where is the download sites for your distribution? A list of ftp sites is at: http://www.debian.org/distrib/ftplist The page with installation instructions have links to CD vendors. Steve [EMAIL PROTECTED]
Re: New XFree86 and (Re: autobuilder...glibc 2.1...egcs 1.1.2)
Ben Collins [EMAIL PROTECTED] writes: On Sat, Apr 24, 1999 at 12:42:30PM -0400, Steve Dunham wrote: I'll try the libc packages too. You were also working on an a sparc64 compiler, right? What's the status on that. If egcs 1.1.2 can correctly compile the sparc64 kernel I'd rather use it than the current egcs64 package (which gets internal errors on the 3com driver). I just tried the latest glibc packages. Works on the Ultra5 and SS20 with 2.2.5cvs kernel. Doesn't work with the slink 2.2.1 kernel on the SS20 (init wedges). I wonder if the sparc32 vfork patch is in the 2.2.6 kernel. I uploaded a newer one to unstable a bit ago. Presumably the egcs 1.1.2 does not compile sparc64 kernels. When the mainline egcs package can do this, we should just be able to compiled with --with-cpu=ultrasparc and get a dual target gcc right with a default of -m32 (-m64 must be specified) right? If I'm not mistaken, we'd essentially need a cross compiler named sparc64-linux-gcc. So, when the egcs package can handle compiling the kernel, we'd have to tell it to build a cross compiler for sparc64 binaries (much like the cross compiler for m68k works). --with-cpu=ultrasparc just does UltraSparc optimizations (code ordering, etc) - we need to produce code for 64-bit mode (so some of the type sizes are different - and some instrs are different) and dump them into ELF64 object files. Also, some people may have found this out already, the sparc64 platform does not run libc5 packages unless you use the ld.so from UltraPenguin. I will port the patches when I find some time. This problem is only relevent to people trying to build altgcc packages on UltraSparc systems. (We essentially need a different version of the dynamic loader on sun4u machines.) Yes yes yes! I really need to be able to run the libc5 java. Oh, I didn't know anybody noticed. I'll work on it remotely when I get home. (If TCI isn't down.) Steve [EMAIL PROTECTED]
Re: KDE 1.1 on debian/sparc
Rick Tan [EMAIL PROTECTED] writes: Is KDE 1.1 available for debian/sparc? If so, where can one get the packages? I don't even think it's available for i386 at the moment. Aside from not being free, it's not entirely clear whether it is legal to distribute or not. Even if there were i386 packages, there probably wouldn't be any sparc packages because of lack of resources and interest. (The sparc people are busy compiling other things.) There are, however, some gnome 1.0 packages, which took a bit of effort to compile. I encourage everyone to add: deb http://www.debian.org/~jules gnome-stage-2 unstable main to their /etc/apt/sources.list file and try the packages out. Steve [EMAIL PROTECTED]
Re: More glibc 2.1.1 stuff
Ben Collins [EMAIL PROTECTED] writes: On Sat, Apr 17, 1999 at 11:02:40PM -0700, Stephen Zander wrote: Steve == Steve Dunham [EMAIL PROTECTED] writes: Steve Also - I've never had the init locking syndrome on my SS20 Steve - I've had lock ups during the boot sequence, but never Steve init itself. What kernel is Stephen running? This is with a 2.2.0-pre7 kernel. I've got 2.2.5 on some boxes at work but haven't upgraded the SS5 at home. As soon as I work out which files to replace I'll build a new kernel. :) It does the same with the 2.2.5 kernel, which is what I am running. The stock 2.2.5 kernel or the cvs 2.2.5 kernel? I just tried your new glibc on the SS20 here, and it works fine (2.2.5-cvs kernel). I just installed it over a fresh slink base image. I've backed my sun4u to glibc 2.0.105 so I can compile some stuff for slink. (Update the gnome packages - I can't really do this on an xia machine without root since it involves build, install, build, install cycles.) Somebody also has to update the XFree86 3.3.2.3 packages (IIRC, Branden did a security update) for slink. Whoever does the 3.3.3.1 packages should merge in the latest patches from UltraPenguin. They have added accelleration to the Creator port, and added an accelerated Leo port. (I will probably end up doing this, but if time permits someone else to do it first...) Steve [EMAIL PROTECTED]
Re: More glibc 2.1.1 stuff
Ben Collins [EMAIL PROTECTED] writes: On Fri, Apr 16, 1999 at 11:51:28PM -0700, Stephen Zander wrote: Ben == Ben Collins [EMAIL PROTECTED] writes: Ben Ok, I've recompiled glibc 2.1.1 with a cvs checkout from Ben today. Seems to work pretty well on my ultra. The problems Ben that you and I experienced have gone away (apt-get works Ben again). Now I just need some kind and brave soul to test it Ben on a sun4m :) Well, that was special. Your package locks my SS5 170MHz solid on reboot. init loads but never gets off the ground. BTW, this was on a completely up-to-date unstable system. Scratch that. I did use the vfork patch on that last compile, which really sucks that it didn't work. Well vfork() is broken in many of the kernels (except for very recent CVS kernels). The 2.1 source that we had a while back had a file somewhere in sysdeps that short circuited vfork() to fork() on the sparc. I'm installing slink on my SS20, I have a 2.2.5 cvs kernel for sparc32 that I can try on it. (I've put the kernel in my web dir on master, in case you want to experiment with it.) I'm wondering if this is actually a problem with compiling on a sun4u. I don't see it as likely, but it's the only other thing I can think of (and yes, I am using sparc32 kernel headers and not sparc64). Shouldn't be a problem - the libraries in slink were compiled on an Ultra5. (As long as you make sure you tell it sparc-linux on the ./configure line, there should be no problems.) Also - I've never had the init locking syndrome on my SS20 - I've had lock ups during the boot sequence, but never init itself. What kernel is Stephen running? Steve [EMAIL PROTECTED]
Re: Problem in rescue disk for Sun Ultra 1
Adam Di Carlo [EMAIL PROTECTED] writes: Orion == Orion the Hunter [EMAIL PROTECTED] writes: Orion First, thanks a lot for all the replies. Yes, I had read Orion somewhere that Ultra's cannot be booted from floppy, I just Orion can't remember exactly where. Probably the Install Manual? Orion But the odd thing is, I have Orion already installed Debian/Linux in this same machine using Orion floppy disks with a set of images from the site Orion ftp.ecs.msu.edu, and it worked! It was pre-slink, though, and Orion I think the images were for testing. Unfortunately, I was Orion stupid enough to overwrite the disk a few weeks ago, and so had Orion to try the new images (without success). So I assume there is Orion a way since the hardware is exactly the same. Does anyone have Orion any idea how? Many thanks in advance. ftp.cse.msu.edu Hmm. My model, an ultra5, I know actually lacks the ability to boot from floppies in the firmware. I guess there is a bug here in that for sun4u machines which support it, floppy booting should work. According to Jakub, none of Sun's Ultras will boot from floppy. (The AXi machines should be able to boot from floppy, however.) That said, when I last checked, the Ultra floppies were being incorrectly made by the boot-floppies script. (If run in a sparc32 machine, if it is run on a sparc64 machine, then the sparc32 floppies will be broken.) The solution is to add the -U flag to silo when making the 32-bit floppies and the -u flag when making the 64-bit floppies. The floppies that were at my site were correctly made, but I never corrected Eric because I didn't any sun4u machines could boot from floppy. Steve [EMAIL PROTECTED]
Re: fixing slink boot-floppies for sparc
Adam Di Carlo [EMAIL PROTECTED] writes: Eric Delaunay [EMAIL PROTECTED] writes: Another point about X: I'm using a french keyboard (latin1 layout) and I cannot switch back to virtual consoles. CTRL-ALT + Fn are inoperant. Any advice ? Odd. How can one configure XKB at all on xsun-* servers, since they do not have configuration files? I had a problem on my Ultra5 with the alt key not working due to the fact that it was going thru a AT-Sun5 keyboard converted. I fixed it by hacking XKB support a bit. The Ultra5 server, xserver-mach64, uses /etc/X11/XF86Config... (The others need options passed on the command line.) Steve [EMAIL PROTECTED]
Re: fixing slink boot-floppies for sparc
Eric Delaunay [EMAIL PROTECTED] writes: About wrong /dev/fb0 permissions, could someone investigate why X does not find the device if not world writable ? I was not able to track it down to the point (strace is segfaulting early on X, Xsun, startx, ...). Even with Xsun running suid I get the following error: no screen found. The only explanation that I can think of is that X is dropping root privileges before it opens the framebuffer device. One way to test this would be to try giving ownership of /dev/fb* to the user running the suid X server. Steve [EMAIL PROTECTED]
Re: kernel-package rules file patch for UltraSparc
Adam Di Carlo [EMAIL PROTECTED] writes: Steve Dunham [EMAIL PROTECTED] writes: Did all that, but now I get: rm -f kernel.o ld -m elf64_sparc -r -o kernel.o signal.o ksyms.o sched.o dma.o fork.o exec_domain.o panic.o printk.o sys.o module.o exit.o itimer.o info.o time.o softirq.o resource.o sysctl.o acct.o capability.o kmod.o ld: cannot open linker script file ldscripts/elf64_sparc.xr: No such file or directory make[3]: *** [kernel.o] Error 1 Clue for me? Argh. Forgot about that. Bug in egcs64 package that I fixed locally with a symlink. I'll add this to the egcs64 package if I can't find a better solution. install -d /usr/sparc-linux ln -s ../lib /usr/sparc-linux/lib A bug report should be filed against egcs64, if it hasn't been filed already. Steve [EMAIL PROTECTED]
Re: kernel-package rules file patch for UltraSparc
Adam Di Carlo [EMAIL PROTECTED] writes: Steve Dunham [EMAIL PROTECTED] writes: Argh. Forgot about that. Bug in egcs64 package that I fixed locally with a symlink. I'll add this to the egcs64 package if I can't find a better solution. install -d /usr/sparc-linux ln -s ../lib /usr/sparc-linux/lib A bug report should be filed against egcs64, if it hasn't been filed already. Yes -- that fixed that problem -- bug submitted against egcs64. Now I have yet another problem: sparc64-linux-gcc -D__KERNEL__ -I/usr/local/src/linux-2.2.x/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -fcall-used-g5 -fcall-used-g7 -Wno-sign-compare -DMODULE -DMODVERSIONS -include /usr/local/src/linux-2.2.x/include/linux/modversions.h -c -o 3c59x.o 3c59x.c ../../gcc/config/sparc/sparc.c:1174: Internal compiler error in function sparc_emit_set_const32 cpp: output pipe has been closed make[3]: *** [3c59x.o] Error 1 make[3]: Leaving directory `/usr/local/src/linux-2.2.x/drivers/net' Yikes! I'm going to try to disable this enet device and see if I can overcome Yup. It did work at one point in time (2.1.1xx), but some recent change in the kernel source is triggering a compiler bug. Hopefully Ben's Compiler update will fix this. Steve [EMAIL PROTECTED]
Re: 24bits and colors
Joshua Uziel [EMAIL PROTECTED] writes: Well... then.. does it make sense to unsintall Xsun24 and set up Xsun8 instead? I've got only 32MB and it would be worth it if I save some memory with it. I've never tried it, but I'm surprised Xsun24 works at all for you. :) I doubt you'd save any memory... but I figure it would be a good idea to run the native driver for your card. Go for it... :) Xsun24 works with both. I've used it on a dual headed CG14/CG6 machine before (so one screen is 24 bit and the other is 8 bit, all on one Xserver). Steve [EMAIL PROTECTED]
Re: glibc 2.1 is now on master in my homedir
Ben Collins [EMAIL PROTECTED] writes: On Tue, Mar 30, 1999 at 10:36:58PM -0500, Steve Dunham wrote: I've installed this on an Ultra5. Seems to work fine. Survived a reboot. Some minor problems that need to be fixed in other apps (xterms end up using ttyp? instead of pts/?). BTW, the pts stuff is enabled for sparc in the 2.2.5 kernel. Glibc 2.1 has a problem with having the /dev/ptmx device present and devpts not being mounted. If /dev/ptmx is presend then create /dev/pts and mount devpts there or it wont work right. I know, I've been telling people this. But there are a few apps that manually acquire pty's instead of using the libc functions, so they end up with oldstyle one - it works, but isn't aesthetically pleasing. Do you have a non Ultra system to test this on? My ultra works fine, but my LX doesn't reboot (as reported by some one else aswell). My SS20 seems to have locked up. (After I installed the deb's I cd'd to /proc/openprom and typed ls.) This may just be a kernel issue, I'll have to wait till I get to work to find out what's wrong. (Ping works, tcp connections are established, but nothing comes back.) Steve [EMAIL PROTECTED]
Re: glibc 2.1 is now on master in my homedir
Ben Collins [EMAIL PROTECTED] writes: On Wed, Mar 31, 1999 at 12:21:05AM -0500, Steve Dunham wrote: I know, I've been telling people this. But there are a few apps that manually acquire pty's instead of using the libc functions, so they end up with oldstyle one - it works, but isn't aesthetically pleasing. Maybe we need to get a preinst script that checks for this? It's not an issue. I just mean that xterm eventually needs to be patched and recompiled for all platforms. (I've pretty much given up hope on X. It seems that Branden may have gone back to working on 3.3.2.3.) Can you try this new patch I have (sparc32-chown.dpatch) and build on the sparc 20? I've tries building this against 2.2.5 headers from vger cvs and still had the same problems, so this is either not a kernel issue or it's one that isn't fixed. This isn't the problem. modprobe is locking up. Whenever a module is autoloaded, the system locks up. The last thing modprobe does is: SYS_66( Which should be a 'vfork()'. I'm not entirely sure what is going wrong here. In the kernel vfork calls exactly the same code as fork (although the entry code is different in sparc64). I would suspect a kernel problem, but the older version of libc works. I'll add your patch to a fresh tree and try rebuilding. Steve [EMAIL PROTECTED]
Re: 24bits and colors
Chris Trainor [EMAIL PROTECTED] writes: I always wanted 24bit color for my sparc, till I found out the cheapest I could get a ZX framebuffer (or the one of the SS-5) was going to cost as much as my Sparc5 did... so, needles to say, I live with the ekky colors in X. :) The ZX is very slow in Linux. Steve [EMAIL PROTECTED]
Re: making egcs the primary compiler for sparc architecture?
Edmund GRIMLEY EVANS [EMAIL PROTECTED] writes: subject says all; I see that sparc uses glib-2.1 and kernel-2.2.1, so this should not be a problem. Is there some other reason not make egcs the primary compiler for sparc? Thanks, the Debian EGCS maintainers. None that I know of. In the 2.2.5 announcement Linus mentions that it is suspected that there are some problems with compiling the kernel with egcs: http://lwn.net/daily/2.2.5.html But using gcc-2.7.2.3 for the rest of eternity is probably not the best way of dealing with it ... IIRC, these problems are with Intel only. Using gcc on the sparc is a very bad idea. It produces bad code for anything involving long long integers. (Example, the binutils package has a hack in the rules file to compile with egcs on the sparc because it stops working when you compile it with gcc.) We need to ditch gcc ASAP. (I'm told by one of the libc developers, I forget which one, that gcc should _only_ be used to compile the intel kernel.) Steve [EMAIL PROTECTED]
kernel-package rules file patch for UltraSparc
Ok, here is a simple patch to the kernel-package rules file to add UltraSparc support: --- /usr/lib/kernel-package/rules.bak Tue Mar 30 12:50:20 1999 +++ /usr/lib/kernel-package/rules Tue Mar 30 12:55:24 1999 @@ -194,6 +194,9 @@ kimagesrc = vmlinux kimagedest = $(INT_IMAGE_DESTDIR)/vmlinuz-$(version) DEBCONFIG = $(CONFDIR)/config.sparc +ifeq ($(SUBARCH),sun4u) +KERNEL_ARCH=sparc64 +endif endif After applying the patch, you can do: fakeroot /usr/sbin/make-kpkg --subarch=sun4u --arch_in_name binary-arch to generate UltraSparc kernel packages. (This will work on any sparc, but you need the egcs64 package installed.) Eventually, we should add a check in the preinst script to keep people from installing the sun4u packages on 32-bit machines and vice-versa. Steve [EMAIL PROTECTED]
Re: xia01 is now Debianized for UltraLinux development!
Ward Deng [EMAIL PROTECTED] writes: I have spent some time this weekend to update our xia01, an UltraSPARC system, to Debian 2.1 (slink). It went very smoothly. Thumbs up to all who contributed. The TFTP image is identical to the one used to install 32-bit Debian 2.1 on xia02, a SPARCstation LX. We have enough space to host a near-complete Debian mirror for i386 and SPARC architectures including incoming/. The cron runs rsync every other day. Now three systems (xia01-3) have two (xia01-2) running natively with Debian. The remaining xia03 is still running UltraPenguin 1.09. I can either convert it to Debian or upgrade it to the latest UP 1.19 and take it as a reference system. Let me know what you think. If it has space, I'd say put Debian on one partition and UP 1.19 on another, so we can, if we need a reference system, run UP in a chrooted environment. (I've found it kinda handy to keep a RH partition around to check symbols in the libraries, etc.) If necessary, you could run sshd on a different port in the chrooted environment to give easy access to both trees to normal users. Again, these three systems are publically accessible to all Debian developers and anyone who are interested in Debian UltraLinux project. I will assign you account if you ask. I certainly hope every developer get involved. I will test this distribution with more hardware configurations and document it in HTML some time next week. Frankly it is easy and smooth to install. I've _very_ happy with how slink turned out. Back in January, I had pretty much written off ultra support in slink, but Eric showed some interest in adding support to boot floppies, so I went ahead an pushed the Ultra changes into the distribution and did the CD stuff. Here is the latest motd: Welcome to Debian-UltraLinux Project! -- xia01: UltraSPARC I-170, 64MB, 3.5GB(system+/home2), 13GB(/Debian) Debian 2.1 (slink) Kernel 2.2.1 (updated on 3/27/99) xia02: SPARCstation LX, 64MB, 1.08GB, Debian 2.1 (Slink) Kernel 2.2.1 (updated on 3/18/99) xia03: Sun Ultra30, UltraSPARC II-250, 128MB, 4.2GB(system and data) UltraPenguin-1.0.9, kernel 2.1.125 oh. We definitely want debian on xia03, then. It looks to be the best system to compile stuff on. Note: xia01 and xia02 are contributed by Kachina Technologies, Inc. and xia03 is a loan system contributed by Sun Microsystems, Inc. -- If anybody is looking for sparc stuff to do: Compile missing packages. 1.Go through the latest Ultrapenguin looking for egcs and binutils patches for lib64 stuff. I'm told that the support is already in some of the build tools in UltraPenguin, and some preliminary sparc64 stuff will be available this summer. 2.Make sure Branden's new X code compiles on the Sparc - then merge in all the changes from UltraPenguin, and the changes in the packages at: http://ultra.linux.cz/ftp/OS/Linux/Sparc/local/XFree86/ (These are huge speed improvements for Creator boards - they will be folded into UltraPenguin RSN.) I am going to take a break for a bit from the core system stuff. I have other work that I need to get done. I see that Ben Collins is working on glibc, and I hope someone can take a look at X. (If not, I'll do it eventually.) I will have another go at the gnome 1.0 stuff when it slows down (most of it is compiled and uploaded, but they keep incrementing the debian revision numbers due to miscompiles on x86). FWIW, I just uploaded apt 0.3.3 to Incoming on master, and gnome-apt to the gnome staging area. If you guys haven't checked it out already, do look at the sparc gnome stuff, the apt magic is: deb http://www.debian.org/~jules/gnome-stage-2 unstable main It runs fine on slink. Steve [EMAIL PROTECTED]
Re: sparc porting and wanna-build
Adam Di Carlo [EMAIL PROTECTED] writes: Can anyone brief my on how we're coordinating the sparc porting effort? What do people think of putting up a wanna-build buildd for Debian/sparc? Is there any other pointers I should know for porting pkgs to Sparc? Guidelines? Is it ok to compile for debian-sparc on a Sun4u (I assume so). Everything in the sparc distribution that was built by me was built on a sun4u (including libc-2.0.105, XFree86, and all of the gnome 1.0 stuff). Steve [EMAIL PROTECTED]
Re: glibc 2.1 in potato
Ben Collins [EMAIL PROTECTED] writes: Ok, I've gotten glibc 2.1.1-0.1 compiled. No real problems (atleast no C++ libs problems like i386 is having). Only thing I see wrong is tar broke: tar: error in loading shared libraries: tar: symbol chown, version GLIBC_2.1 not defined in file libc.so.6 with link time reference GLIBC_2.1 is defined (atleast it shows when I grep strings libc.so.6) in libc. The `chown' comand works fine, however, and nothing else seems to be affected. Could this be a bad compile of tar or was the previous glibc 2.1pre's compiled with some strange symbols? Hmm, it looks like 2.0.105 has a version 2.1 chown: # objdump -T /lib/libc-2.0.105.so | grep chown 000a88a8 gDF .text 00a4 GLIBC_2.1 chown 000a894c gDF .text 001c (GLIBC_2.0) chown 000a8968 w DF .text GLIBC_2.0 fchown 000a899c w DF .text GLIBC_2.0 lchown 000a88a8 gDF .text 00a4 GLIBC_2.1 __chown But the new one doesn't: # objdump -T libc.so |grep chown 00095008 w DF .text GLIBC_2.0 fchown 0009503c w DF .text GLIBC_2.0 lchown 00094fd4 w DF .text GLIBC_2.0 chown Looking at tar: # objdump -T /bin/tar |grep chown 0003f5a0 DF *UND* 00a4 GLIBC_2.1 chown 0003f9fc w DF *UND* GLIBC_2.0 lchown And chown: # objdump -T /bin/chown |grep chown /bin/chown: file format elf32-sparc 00022080 w DF *UND* GLIBC_2.0 chown This should explain the error that you are seeing, but it doesn't explain why I don't see the problem on my test machine. Wait - I am seeing the problem with other programs. Steve [EMAIL PROTECTED]
Re: glibc 2.1 in potato
Steve Dunham [EMAIL PROTECTED] writes: This should explain the error that you are seeing, but it doesn't explain why I don't see the problem on my test machine. I'm using tar 1.12-7, btw. Wait - I am seeing the problem with other programs. Sorry, typed C-c C-c in the wrong window. I can't telnet in (hostnames changed): Trying 10.0.0.1... Connected to foo.bar.domain. Escape character is '^]'. in.telnetd: fatneck.cse.msu.edu [xterm]: error in loading shared libraries: in.telnetd: fatneck.cse.msu.edu [xterm]: symbol chown, version GLIBC_2.1 not defined in file libc.so.6 with link time reference Debian GNU/Linux 2.1 jocoque.cse.msu.edu ssh doesn't work either. (I restarted it, and I can now connect and authenticate - it logs a completed RSA authentication - then it exits.) It also looks like man is broken too. We may have a big problem here. The following bash magic scans the current directories for possible problems: for i in *;do if objdump -T $i 2/dev/null|grep chown|grep -q GLIBC_2.1; then echo $i; fi; done In /usr/sbin I find: exim gdm in.rlogind in.telnetd rmail rsmtp runq sendfiled sendmail sshd sshd1 visudo In /bin: cpio gunzip gzip tar uncompress zcat In /sbin: getty slattach In /usr/bin: apropos bitchx catman checkpc dpkg editor elm ex fdlist fdmount fdmountd fdumount lockfile mailq man mandb manpath mc mcedit mcserv nex nvi nview objcopy perl perl5.00404 procmail rdistd rn slogin slrn sperl5.00404 ssh ssh1 strip sudo suidperl trn vi view whatis And example of the problem: # touch /tmp/foo # perl chown 0,0,/tmp/foo; perl: error in loading shared libraries: perl: symbol chown, version GLIBC_2.1 not defined in file libc.so.6 with link time reference I suspect that all of the above programs will have problems when they call chown(). (I think tar calls both chown() and lchown() depending on what it's trying to do.) So, it looks like we're going to have to recompile a lot of stuff... Steve [EMAIL PROTECTED]
Re: glibc 2.1 progress
Ben Collins [EMAIL PROTECTED] writes: (The big problems are at the end.) Well, after finding out that this new glibc 2.1 without the chown patch will also break X, I've changed my opinion slightly. Does it break X if you recompile X? (I would doubt it, since X works with 2.1.1 on Red Hat.) I'm going to apply the patch and see how it works with that. We could have a problem here: # objdump -T redhat/libc-2.1.1.so |grep chown 00098938 w DF .text GLIBC_2.0 fchown 0009896c w DF .text GLIBC_2.0 lchown 00098904 w DF .text GLIBC_2.0 chown # where redhat/libc-2.1.1.so is from Red Hat's 5.9 sparc distribution. If you apply the patch, binaries compiled on Debian systems will not run on Red Hat systems. (We will then have to tell people like netscape that they should compile on Red Hat systems.) For the sake of completeness, I did: # objdump -T redhat/libc-2.1.1.so | \ sed '/GLIBC/\!d;s/^.*\(GLIBC_.*\)$/\1/' RH.out # objdump -T debian/libc-2.1.1.so | \ sed '/GLIBC/\!d;s/^.*\(GLIBC_.*\)$/\1/' DEB.out # diff RH.out DEB.out without the chown patch, the two files were identical. With the patch, programs compiled on Debian will fail on Red Hat when they call chown(). (This is the status quo, btw.) (BTW, there are a _lot_ of differences between libc-2.0.105 and libc-2.1.1 on Debian, but they all involve __ symbols, so they shouldn't cause problems with real programs.) Well these are the issues - is there a consensus on what we should do? Recompile half of the distribution, or retain a one-way incompatiblity with Red Hat? (We can run RH stuff, but they can't run our stuff.) (A nice solution would be to find a way to force the linker to use the GLIBC_2.0 symbol while still making the GLIBC_2.1 symbol available to the loader, but I don't think that is possible.) Steve [EMAIL PROTECTED]
Re: glibc 2.1 in potato
Ben Collins [EMAIL PROTECTED] writes: On Mon, Mar 22, 1999 at 02:15:50PM -0500, Steve Dunham wrote: If you want, I can take care of compiling this. (I did it once about a month ago, but that was with an older, broken version of egcc, so crypt didn't work and, hence, I didn't upload anything.) It's fine, I'll get it uploaded tonight. What kernel headers are you compiling against? (2.1.125?) It needs to be compiled against 2.1.x or newer kernel headers. Steve [EMAIL PROTECTED]
Re: glibc 2.1 in potato
Ben Collins [EMAIL PROTECTED] writes: On Mon, Mar 22, 1999 at 05:45:07PM -0500, Steve Dunham wrote: Ben Collins [EMAIL PROTECTED] writes: On Mon, Mar 22, 1999 at 02:15:50PM -0500, Steve Dunham wrote: If you want, I can take care of compiling this. (I did it once about a month ago, but that was with an older, broken version of egcc, so crypt didn't work and, hence, I didn't upload anything.) It's fine, I'll get it uploaded tonight. What kernel headers are you compiling against? (2.1.125?) It needs to be compiled against 2.1.x or newer kernel headers. I'm using the 2.2.1 headers since that is the latest kernel in the system (and the same one that i386 was compiled against). Ok, just double checking. (If 2.0.x headers are used, then features are missing.) I had a couple of problems with the compile - I had to define __NR_vfork (I set it to 66) in sysdeps/unix/sysv/linux/sparc/sparc32/sysdeps.h to get it to compile (without an undefined __NR_vfork). Apparently, this constant is not defined in the 2.1.125 or 2.2.1 headers, even though the syscall is on the list. I also had to tweak the rules file to leave out lddlibc4 which wasn't built on my machine. (It is included by the rules file if HAVE_LIBC5 is defined, even though it seems to be intended for systems that have libc4.) Did you see these problems? Also, a completely unrelated question: ldbmcat segfaults on Sparc machines (works fine on i386). I don't have a debug build lying around, so I can't debug it more. (Do you see the same behaviour?) Steve [EMAIL PROTECTED]
Re: Need to make dhcpcd work
rmathis [EMAIL PROTECTED] writes: I have sucessfully installed debian sparc base from floppies and now need to get dhcpcd working in order to finish the install. I have installed the dhcpcd package recommended on the package list but it fails to run even though there were no errors with the install. When I run the command dhcpcd -d eth0 to run dhcpcd in the foregroud I get a Bus Error and dhcpcd does not start. I do not believe it starts from the init.d script either as it does not show in ps ax even though a pid is in the file that dhcpcd creates whwn it starts and when you do the command dhcpcd -k eth0 it says that there is no pid to kill. I am required to run dhcp by my provider and this is a cable modem system. My Solaris box works well with the modem. Any help with this would be greatly appreciated. Which kernel? If you are using a 2.2.x kernel, you should be able to get dhcpcd-sv from potato (or the dhcpcd-sv program in the dhcpcd package in potato) to run. I'm not completely surprised that you're getting bus errors, I don't think anybody has tested dhcpcd on the Sparc. I have to make a bunch of sparc specific patches to dhcpcd-sv to get it to run without bus errors. (Bus errors are caused by unaligned writes, they don't affect intel machine.) Steve [EMAIL PROTECTED]
Re: solaris binaries.
Daniel Brosemer [EMAIL PROTECTED] writes: Hi, thanks to people on this group, I have almost all my questions sorted out re: debian-sparc, however, I still have one question. I read somewhere that S/Linux could run solaris binaries, is this true? If it is, how do I do it? On my sparcstation IPC, if I try to run even the simplest brute-force prime number finder that I compiled under solaris on a sparc-20, I get [EMAIL PROTECTED]:[~/c]$ ./primesun bash: ./primesun: No such file or directory [EMAIL PROTECTED]:[~/c]$ ll primesun -rwxrwxr-x 1 dbroseme laa 22894 Mar 3 15:15 primesun* So the file is there, and quite executable, I even used TAB to complete the name. It runs fine on a solaris machine (in fact, any of the sparc-10s, sparc-20s, or ultras). Do I need to install any special libraries? Is there a module to insert into the S/Linux kernel that I haven't found? Thanks very much for your help. You need to populate /usr/gnemul/solaris. At the very least, you need usr/lib/ld.so and usr/lib/ld.so. You will probably also need a bunch of devices in the dev directory (/usr/gnemul/solaris/dev). I'll try to get around to making a real debian package of this, until then, grab: http://www.debian.org/~dunham/solemul_1.0-3_sparc.deb which is an alien'd version of the corresponding UltraPenguin package. (You will still need to legally obtain the shared libraries or statically link your application.) Also, note that anything using Solaris threads won't work. Steve [EMAIL PROTECTED]
Re: 2.1_r0 install experience
[EMAIL PROTECTED] (Mark W. Eichin) writes: So, I went through the install, and an old problem reappeared... When booting off of this disk (sd(0,2,0)), I get Bad magic number in disk label! S Bad magic number in disk label! IProgram terminated. ok I assume this is because (1) the disk was originally formatted on an x86 linux box, so it has a DOS partition table (2) fdisk isn't a big enough hammer to fix that... I did note that fdisk had a b option for edit bsd partition table but all it said was /dev/sdb has no BSD-style partition table... I did find (after rebooting with the rescue zip disk) the eXpert mode g option for create an IRIX partition table which is somewhat distressing... and in fact, that looks like what it *does* do. Very very strange. On the sparc, fdisk has: s create a new empty Sun disklabel which is what you want. (It appears that s is in the intel version too - although it doesn't appear in the menus, and I don't know for sure if all the endian issues are worked out.) Intelsilo is at: http://www.cse.msu.edu/~dunham/debian/silo/ as soon as the maintainer folds my changes into the package in potato, I'll generate a potato intelsilo. (May be done already, I'll have to check.) Steve [EMAIL PROTECTED]
Re: slink CDs
[EMAIL PROTECTED] (Mark W. Eichin) writes: The sparc images are now on cdimage.debian.org. yay. Will sunsite.org.uk just pick them up? and if so, what path? (rsync -v sunsite.org.uk:: just says pub which isn't helpful... using rsync -n to browse is really painful...) They should pick them up, I don't know if they are there yet. According to cdimage.debian.org, the path is: rsync://sunsite.org.uk::public/packages/debian-cd The disks are in 2.1_r0/sparc on cdimage, named MD5SUMS binary-sparc-1.iso binary-sparc-2.iso source-1.iso source-2.iso The source images are the same for all architectures. I managed to get through and verify that the images are there, the command: rsync sunsite.org.uk::public/packages/debian-cd/2.1_r0/sparc/binary-\* . should fetch the correct images. Steve [EMAIL PROTECTED]
Re: E450 supported?
Steve McIntyre [EMAIL PROTECTED] writes: I've just tried a newly-written 2.1 sparc boot CD on our twin-CPU Enterprise 450 at work, mainly as a test of the intelsilo stuff Steve Dunham gave me. It seemed to work quite well, then failed. Some of the boot messages below, ask if you need to see more. Is this a real problem with the CD, with Linux sparc support, or something else? The beginning of the boot messages would be nice. sdc: sdc1 sdc2 sdc3 sdc4 sdc6 sdc7 sdc8 You didn't specify the type of your ufs filesystem mount -t ufs -o ufstype=sun|44bsd|old|next|openstep WARNING Wrong ufstype may corrupt your filesystem, default is ufstype=old ufs_read_super: bad magic number Kernel panic: VFS: Unable to mount root fs on 01:00 Press L1-A to return to the boot prom This happens then the initrd is empty, either because of a problem with silo loading it, or a problem with the kernel overwriting it. If the kernel is overwriting the initrd, it will say at the beginning of the boot messages. If silo is having problems it should say before the kernel boots (before screen goes black, if you are using a graphical console.) Possible problems: * You didn't use the latest patches that I sent you, which moves install from slink1/ to boot1/ before creating the first CD image. (This will give an Read Error from the PROM, before the kernel starts booting.) * The ram disk is getting overwritten. (This would have to be because of a bug/oversight in silo's second stage loader - IIRC, you will see a message about this at the very beginning of the kernel messages.) Steve [EMAIL PROTECTED]
Re: floppyless, network installation -- possible?
Adam Di Carlo [EMAIL PROTECTED] writes: Running thru a tftp installation on my new sparc, I realized that either I'm confused (and the documentation too), or you can't install floppyless/cd-less. For instance, sure, you can boot from tftp, but when you try to install the operating system and modules, you'll still need a non-network installation mechanism, either floppy or CD. You can't NFS at this point, nor can you use TFTP to get the kernel and the modules, AFAIK. Is this true? If that's the case, there are really 4 discrete installation media that you can kinda mix-n-match (in a constrained way, based on architecture too, of course): * initial boot (rescue floppies, tftp, cdrom, OS loader) * install kernel and modules (floppies, CD, harddisk) + NFS * install base system (floppies, CD, harddisk, NFS) * install the rest (http, nfs, disk, etc etc etc) I'm not sure if this was answered yet, but: If you go down and do Configure Network before Install Kernel and Modules, then there will be an NFS option in the Install Kernel and Modules menu (and the Install Base System menu). Steve [EMAIL PROTECTED]
Re: silo, dual boot, cylinder 0 (was Re: booting at last!)
Adam Di Carlo [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED] you wrote: You can't put a swap partition there. ext2 and ufs have a couple of unused blocks at the beginning, so they coexist with the disk label. I've always used an ext2 partition at the beginning of the disk without problems. Cool; that's what I thought and what I had documented. Yet, I personally do have a problem which is confusing. Install solaris on my ultra5: /dev/hda1 == sunos-root (on cyl. 0) /dev/hda2 == swap (shared) /dev/hda3 == whole disk /dev/hda4 == linux root ... This all boots fine, into solaris. I can still manage to boot into linux via TFTP. Then run silo; after which I can boot into silo but the solaris options don't work (even specifying the full OpenPROM path, and every possible combination). It always returns the error 'Can't find executable kernel/unix', IIRC. IIRC, there is a bug in silo. It looks in: /platform/SUNW,Ultra-5_10/ which is empty, rather than in /platform/sun4u. I thought that Jakub had fixed this, but apparently, he didn't. Making SUNW,Ultra-5_10 into a symlink should fix it. Then add: image=1/kernel/unix label=solaris solaris to silo.conf. (Silo gets the architecture string from the OpenPROM.) You might also try installing silo on the linux partition: boot=/dev/hda4 and using boot disk:d to boot Linux (I think this will work.) Steve [EMAIL PROTECTED]
Re: Releasing Slink
Steve McIntyre [EMAIL PROTECTED] writes: Steve Dunham writes: So, when do you want a CD image. Assuming the other archs have stopped uploading new stuff, the last thing we _need_ for sparc is for console-tools to be installed from incoming into the distribution. Ick... It made it into the dist yesterday. Now depending on how rushed we are for time, I can merge this into my mirror manually and generate the CD images, or I can wait till it is installed on master and then rsync and generate the CD images. (Assuming that dinstall picks it up today, it will be 1800 EST or later - dinstall runs at 1500 EST and masterfiles, a long process, runs after dinstall is done.) Hmmm. That's probably a bit late. I'd like to have all the images done and on cdimage by the end of today (Sunday) GMT to give the mirrors Monday to get the images. If you can do it by hand, then I guess... Those times were on saturday. I'm running md5list right now, and just finished blanking the CDRW. The image I prepared last night didn't work because the silo stuff is broken in slink_cd 1.10 and 1.11, it mounted the old image and installed silo on the new one. I'll mail you a patch for all of the silo woe as soon as this new image is built and burned. I don't have a cdimage account. For the pre1 images I just gave Phil Hands a rsync address and password. Whoever transfers these new images to cdimage, should copy the old ones into the place for the new one and then do an rsync with a large block size. Steve [EMAIL PROTECTED]
Re: Releasing Slink
Steve McIntyre [EMAIL PROTECTED] writes: The slink release has been a mess, culminating in a last-minute sorry, we missed it again announcement. If we're going to release properly next Tuesday at 00:00 GMT, then we need a schedule like the following: 1. Fixes needed for each set allowed in Tue, Wed, Thu and then _no more uploads_ for any reason. At all. None. Sparc is slightly broken. A new console-tools was uploaded Wednesday, dinstall, as usual, deleted the old binary-all console-tools-data package, breaking console-tools on the sparc. I didn't notice this until I ran slink_cd late friday night. I've uploaded a sparc binary for the console-tools that is currently in slink (for all of the other architectures.) So, when do you want a CD image. Assuming the other archs have stopped uploading new stuff, the last thing we _need_ for sparc is for console-tools to be installed from incoming into the distribution. Now depending on how rushed we are for time, I can merge this into my mirror manually and generate the CD images, or I can wait till it is installed on master and then rsync and generate the CD images. (Assuming that dinstall picks it up today, it will be 1800 EST or later - dinstall runs at 1500 EST and masterfiles, a long process, runs after dinstall is done.) Steve [EMAIL PROTECTED]
Re: sparc hardware added to boot-floppies Installation Manual
Adam Di Carlo [EMAIL PROTECTED] writes: Steve == Steve Dunham [EMAIL PROTECTED] writes: Steve Eric, I've come up with the rules file magic to generate both Steve sparc32 and sparc64 kernels from the same source package. (It Steve generates kernel-image-2.2.x-sparc64_*, then generates a Steve complete set of packages for the sparc32 architecture.) Steve, this is a non-boot-floppies issue, but right now I'm left in the unenviable position of not being able to build a sparc64 kernel from sources in the Debian archive. There is no kernel-source-*.deb corresponding to the above packages, because it would have had the same name as an existing package. You need to get the Debian source package, kernel-source-sparc. (I will add this to the extras directory on the first sparc CD.) I probably should have made a kernel-source-sparc binary package, but it's too late for slink... The sources in kernel-source-2.2.1 are kinda useless. To get the kernel to compile from the kpkg package, you have to run something along the lines of make-kpkg configure (somehow managing to get the patch to magically apply from the patch package), then run the generated debian/rules file manually with KERNEL_ARCH=sparc64 added to the end of the command line. It isn't pretty. The kpkg rules file was such a tangled mess that I just gave up and wrote my own - but it does explicitely override the kernel Makefile's choice of architecture. Where can I get the sources or rather, I guess, the 2.2.1 patches which you used to build the sparc64 linux kernel? The patches are debian/*.patch in the linux-kernel-source Debian source package. They are applied by the rules file. (make patched-stamp will take you as far as the patching process.) One final thing: you need egcs64 installed to build sparc64 kernels. Steve [EMAIL PROTECTED]
Re: CDs
Steve McIntyre [EMAIL PROTECTED] writes: So, where are we up to for sparc/alpha. The m68k stuff is sorted now, as is the i386. Where have we got to on fixing the last few dependencies? I've added exclude support to slink_cd as a last-miute hack to allow us to simply lose any final problem packages, I'll be sending this out later. I'm going to be building the m68k, i386 and source CD images overnight on cdimage.debian.org ready for people to test them... How exactly does exclude work? Does it rebuild all of the Packages files or just the master ones for the CD? Steve [EMAIL PROTECTED]
Re: CDs
Steve McIntyre [EMAIL PROTECTED] writes: On Sat, 6 Mar 1999, Steve Dunham wrote: Steve McIntyre [EMAIL PROTECTED] writes: So, where are we up to for sparc/alpha. The m68k stuff is sorted now, as is the i386. Where have we got to on fixing the last few dependencies? I've added exclude support to slink_cd as a last-miute hack to allow us to simply lose any final problem packages, I'll be sending this out later. I'm going to be building the m68k, i386 and source CD images overnight on cdimage.debian.org ready for people to test them... How exactly does exclude work? Does it rebuild all of the Packages files or just the master ones for the CD? Just the ones for the CD. It works as a modifier in the genlist stage - where it used to check for which of the first 2 CDs a main package should go on, there's now a third option EXCLUDED where the package will simply be ignored. The syntax is simple - exclude-$ARCH should list package names. Ok. When does the CD need to be ready? There is one last binary sparc package in incoming, to sync up with the versions in other architectures. I can manually merge it into my local archive and generate the CDs now, or I can wait until dinstall and generate the CDs late tonight (circa 1800 EST). Steve [EMAIL PROTECTED]
slink/main/disks-sparc is screwed up.
Steve McIntyre [EMAIL PROTECTED] writes: So, where are we up to for sparc/alpha. The m68k stuff is sorted now, as is the i386. Where have we got to on fixing the last few dependencies? I've added exclude support to slink_cd as a last-miute hack to allow us to simply lose any final problem packages, I'll be sending this out later. I'm going to be building the m68k, i386 and source CD images overnight on cdimage.debian.org ready for people to test them... Ok, the disks-sparc stuff is screwed up on master. All of the filenames have .2.1.8.1-sparc appended to them. I will fix this locally, if necessary (for the official CD), but the ftp archive and all mirrors should be fixed in time for the release of slink. Steve [EMAIL PROTECTED]
Re: Documentation issues in disks-2.1.8.1
Adam Di Carlo [EMAIL PROTECTED] writes: Eric == Eric Delaunay [EMAIL PROTECTED] writes: Eric BTW, Adam, are you planning to upload new documentation for Eric bootdisks of each arch ? I don't want to (and don't have time Eric to) upload a new full set of bootdisks for sparc, so is there a Eric way to just replace the doc under ...disks-sparc/current ? Can't we just leave those along and point folks to the new documentation on the debian web sites? I provide PDFs, HTML, and ASCII there. In modern install manuals, section 1.1.1 points users to that location. I'd rather not mess around with boot-floppies area once they are installed, but I suppose it could be done. The reason not to is that: * md5sums won't match * maintenancne nightmare * users won't know to reget the area for new versions of the boot floppies Another (cleaner) alternative is to periodically release the point releases, i.e., 2.1.9.1. FYI, I've created an arch-specific README.1ST for the sparc, modeled after the i386 one: README for Debian 2.1 CD installation. == To boot the installation system from CD, you will need to insert either CD#1 in your CD-ROM drive, drop to the PROM prompt (Stop-A), and enter: boot cdrom (if you have an older PROM, you may have to use b sd(0,6,0) instead). This CD should boot on sun4c, sun4m, and sun4u systems. At the silo prompt you will be given a choice of linux or linux-2.2.1 (if you just press return, you get linux). The former provides the officially supported 2.0.35 kernel, and the latter provides a 2.2.1 kernel. Some sun4m systems have been known to not boot the 2.0.35 kernel, so if it locks up while the background is still white, try the 2.2.1 kernel. There is no 2.0.35 kernel for Ultras, so on those machines you will get the 2.2.1 kernel regardless of what you select. If your system will not boot from CD, there are other options: 1. Make boot floppies from the images on the first CD, in the directory /dists/stable/main/dists-sparc/current. The program rawrite2.exe in the /tools directory will write the floppy images under DOS. e.g. cd /dists/stable/main/disks-sparc/current rawrite2 -f resc1440.bin -d a: Under Unix, this can be done with dd or cat (see the documentation in the /install directory). 2. Use tftp booting (documented in the /install directory). The tftp boot images are also in /dists/stable/main/dists-sparc/current. The file tftpboot.img supports 32-bit sparc machines and uses a 2.0 kernel and the file tftpboot-2.2.1.img supports all sparc machines and uses a 2.2.1 kernel. See /install/install.txt for more information, and /README.multicd for last-minute information about the multi-cd installation method. The install documentation in /install was up to date when this CD image was created. The Debian web site has the most up-to-date information at http://www.debian.org/releases/slink/sparc which may document issues that were discovered after these CD images were created. Steve Dunham [EMAIL PROTECTED] March 6, 1999
Fixed: Re: slink/main/disks-sparc is screwed up.
Steve Dunham [EMAIL PROTECTED] writes: Steve McIntyre [EMAIL PROTECTED] writes: So, where are we up to for sparc/alpha. The m68k stuff is sorted now, as is the i386. Where have we got to on fixing the last few dependencies? I've added exclude support to slink_cd as a last-miute hack to allow us to simply lose any final problem packages, I'll be sending this out later. I'm going to be building the m68k, i386 and source CD images overnight on cdimage.debian.org ready for people to test them... Ok, the disks-sparc stuff is screwed up on master. All of the filenames have .2.1.8.1-sparc appended to them. I will fix this locally, if necessary (for the official CD), but the ftp archive and all mirrors should be fixed in time for the release of slink. James Troup took care of this. Steve [EMAIL PROTECTED]
Re: success with 990301 (was Re: new bootdisks to test)
Adam Di Carlo [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED] you wrote: Steve Dunham wrote: I also can't get anything to boot on an Ultra1 (neither floppies that I make nor the UltraPenguin floppies). I've heard reports to the contrary on this list, but I don't think they were using Eric's floppies. (Eric you have to do silo -u to make Ultra floppies - given my experience with floppies, I'm not sure if it's worth the trouble to fix it.) Argh :( I'm afraid it's too late for slink now to change anything but the doc in bootdisks. Not too big of a deal. I've never gotten a correctly made floppy to boot on the Ultra1's here (even the floppies from the UltraPenguin distribution). Ok, putting it in my todo queue. Hopefully one can install over the network at least :-)) Oh, yeah, I can personally confirm that works. And CD booting should work too, right? CD booting works. There are images in the 2.1-pre1 directory of the cdimage.debian.org mirrors. Steve [EMAIL PROTECTED]
Re: Stall on debian sparc installation with version 2.0.35
Lance [EMAIL PROTECTED] writes: Still looking for a response anyone? please? One addition, can anyone let me know the ftp full path to the version of Debian linux for SPARC that I should be attempting to use here? I don't mind trouble shooting and/or debugging on behalf of the group. Should be in dists/slink/main/disks-sparc/current on any Debian mirror. (It should be dated 1999-03-01). Eric has been working on serial console installs, so it should work. Something along the lines of boot floppy or boot net should do the trick, I believe we are automatically detecting serial consoles. Try with a newer install disk, I think it will work. Steve [EMAIL PROTECTED]
