Re: Between a rock a hard place, need monolithic 2.4.2x kernel for sun4m
On Tue, 26 Jul 2005 01:53:14 +0200 Frans Pop [EMAIL PROTECTED] wrote: On Tuesday 26 July 2005 01:45, Eric Jorgensen wrote: This means that an extremely small number of machines are affected. Those are not particularly common boxes. It should be possible to detect via /proc/cpuinfo if the 601 is installed. Nope. You skipped a para: Technically only some sun4m chips are affected, but as glibc can't reliably detect whether a system is affected it will refuse to be upgraded on any 32bit SPARC system before a fixed kernel is installed. The RT601 they're referring to is actually a Sparc v7 chip, and as such is not supported by Sarge in the first place. It's the same chip they used in the SS2. I have sincere doubts whether there are more than a handfull of supported configurations that actually need this fix, if any at all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Between a rock a hard place, need monolithic 2.4.2x kernel for sun4m
On Wed, 27 Jul 2005 18:13:30 +0200 [EMAIL PROTECTED] (Romain Dolbeau) wrote: I have sincere doubts whether there are more than a handfull of supported configurations that actually need this fix, if any at all. I don't think support for SM100 should be any concern to aynone, except for historical interest - in which case SunOS 4.1.4 will do SMP reasonably well on them. Anyone else should scrounge better, faster, more reliable SMBus modules (except maybe the SM20 or SM30, which are nearly as crappy as the SM100, but *are* v8 compliant). All other sun4m machines have v8 compliant CPUs, AFAICR. Right, so, what I'm wondering is if we're requiring a backported kernel upgrade before upgrading a sun4m machine to sarge because there's an outside chance they might be using a cpu that we don't support in sarge but incidentally needs a kernel fix for current libc. The real question is whether there are any sparc v8 cpus that don't support umul. If there aren't, we should fix the libc6 deb and alter the documentation. I also question the wisdom of requiring an initrd to boot with the sun4cdm kernel image. I am not aware of any sun4cdm machines (other than the javastations) that have a storage medium other than scsi that are supported by linux, and very few that have a scsi controller other than esp. And even then, there's only the pti scsi driver available. Above and beyond that, between sunlance and hme i don't think it would make the kernel much bigger at all to cover the vast majority of built-in ethernet devices. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Mopping up issues on an old sparc - need advice
I've got an ss10 that's running woody, was dist-upgraded from potato. It is in a remote facility running headless. Over time, it's grown some interesting warts. I'm wondering how best to resolve them. First, for some reason dpkg thinks that dialog and whiptail both conflict with debconf. Baffled here. I've never had to force an issue wrt dependencies and conflicts on debian, how do i just beat it in there? Also, libc6-sparc64 conflicts with libgcc1 and gcc-3.0. What gives? Best course of action? I'm also wondering how advisable it is to try a dist-upgrade to Sarge on a remote, headless system. If anything goes wrong to where i can't ssh into it, that means i have to schedule a time that's convenient for the guy hosting my machine and drive a half an hour and put a serial console on it. When it needs attention every 3 or 4 years, downtime tends to stretch to a week or more before i can get out there and get it running again. I have looked through a bit of the mailing list archives and have no concerns about kernel package issues, since I always run custom kernel builds. Might be nice to know if the dist-upgrade is going to change the silo configuration so i can change it back. Any advice? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sarge may be last Debian release for 32 bit sparc systems
On Mon, 25 Jul 2005 14:06:46 -0700 Blars Blarson [EMAIL PROTECTED] wrote: Support of sun4c and sun4d was effectivly dropped from Sarge. The only reports trying d-i on this hardware that I remember seeing were failures, and noone bother to try to fix it. Upgrades from Woody may work, but were not well tested either. Not if the binaries are compiled for sparc v8, as has been indicated elsewhere. I loathe my old sun4c gear and will be shortly converting my last IPC - which hasn't been turned on in 7 years - into a functional lunchbox. Anybody who really wants to play with sun4c can come by my place for a free SS2 w/ full complement of ram. Note that lack of hardware is not the problem, if anyone wants some sun4m systems (located in Los Angeles) let me know before they wind up in the recycle pile. (If you don't have the skills/time for doing supporting the hardware yourself, you could substitue money. However, it would be much cheaper just to replace your outdated hardware.) I have a hard time disagreeing. I had an SS10 die and replaced it with a spare, and found myself believing that i would have been much better off finding a big wad of dimms for an idle ultra5 rather than putting another ss10 in (free) coloc. If anybody needs a great big pile of ss10 dimms, drop me an email. I think some of them may be fast enough to run in an ss20 but i have no real idea. I have at least 768 megs of them. Also willing to give you my pile of SS10's and two SM51 modules if you pick them up and never speak to me of them again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mopping up issues on an old sparc - need advice
On Mon, 25 Jul 2005 14:24:04 -0700 Andrew Sharp [EMAIL PROTECTED] wrote: On Mon, Jul 25, 2005 at 02:26:51PM -0600, Eric Jorgensen wrote: I've got an ss10 that's running woody, was dist-upgraded from potato. It is in a remote facility running headless. woody is obsolete It's a 10 year old machine. Woody is the least of it's obsolescence. OK, I just wanted to say that to someone once. Things like potato, hamm, etc. '... is obsolete' have been slapped on my forehead so many times, I wanted to join wow-i'm superior club for 1 second. Oh, I agree. No offense taken. It's just a reliable, lightly used machine that requires very little attention. When a lightning hit to the coloc facility took it out, it'd been so long since i'd seen OBP that I was totally baffled as to how to get the drives to boot in another machine. Since it's not ia32, the scriptkiddies never seem to root it. At this point that's the only reason i haven't shoved a spare pentium4 into the same space. And it's a pretty flimsy reason. First, for some reason dpkg thinks that dialog and whiptail both conflict with debconf. Baffled here. I've never had to force an issue wrt dependencies and conflicts on debian, how do i just beat it in there? Can't help you there. Are you sure they are all the woody versions? Have you tried --fix-broken? Hmm, unfamiliar with the command. No, I'm not sure they're all woody versions. The whole deal has been running in one form or another since the late 90's so it may actually have been upgraded from hamm originally. I'll give it a try. Also, libc6-sparc64 conflicts with libgcc1 and gcc-3.0. What gives? Best course of action? I think I remember this one. Remove gcc-3.0 and libc6-sparc64 and re-install gcc-3.0. I don't think you need gcc-3 libgcc1, quite frankly, and you certainly don't need libc6-spark64. Woody is built with 2.95.4 and 3.0 doesn't build much useful. Sarge is gcc-3.3. I seem to remember that gcc-3.0 had a lot of bugs. Kernels are built with egcs but you must know that. I know that some people were trying to build kernels with 3.0, but with little success. That was my general thinking. I'm not as sharp on compilers (especially old ones) to remember if libgcc1 was relivant to 2.95.4. libc6-sparc64 is 'required' for libc6. I'll have to look up the relivant dpkg command to make it forget about it. I'm also wondering how advisable it is to try a dist-upgrade to Sarge on a remote, headless system. If anything goes wrong to where i can't ssh Snip! I did it recently on my U2 without any problems. Haven't powered up the now ancient SS20 to try it, quite frankly. Let us know how it goes. Sarge is probably worth it now, as woody has been taken off the boards. I had some nasty upgrade problems with an x86 desktop that also runs apt-proxy, but I didn't have any problems with the sun. I will probably wait for a few more success reports before going further, but thanks. Having upgraded from 2xSM51 to a 180mhz hypersparc module, I'm compiling my first kernel since 2.2.19 on that machine. the config options seem to have changed somewhat - things that are always true are no longer optional, which disturbs me somewhat, even though logic demands that it be so. No sense in disabling zilog serial support, but it's reassuring to see it there with an asterisk next to it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mopping up issues on an old sparc - need advice
On Mon, 25 Jul 2005 14:24:04 -0700 Andrew Sharp [EMAIL PROTECTED] wrote: First, for some reason dpkg thinks that dialog and whiptail both conflict with debconf. Baffled here. I've never had to force an issue wrt dependencies and conflicts on debian, how do i just beat it in there? Can't help you there. Are you sure they are all the woody versions? Have you tried --fix-broken? Does nothing. debconf was v1.2.42. $diety knows why or how because packages.debian.org seems to imply 1.0.32 for oldstable - any ideas how this happened? I've also got a nag with autoconf depending on missing automaken. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Between a rock a hard place, need monolithic 2.4.2x kernel for sun4m
On Tue, 26 Jul 2005 01:23:40 +0200 Frans Pop [EMAIL PROTECTED] wrote: On Tuesday 26 July 2005 01:21, Eric Jorgensen wrote: After uncovering just how interestingly munged up this system is, i decided to attempt a dist-upgrade to sarge. In case there was some confusion, dist-upgrade to woody was years ago. All seemed to be going well until aptitude flatly refused to install the new libc until i had a kernel newer than 2.4.21. You could of course have tried reading the Release Notes which contain extensive instructions for dealing with that... Yes, since i have an RT626 i don't really meet the if and only if clause on needing to upgrade the kernel first. Be nice if there was an elif after that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
