Re: Sarge may be last Debian release for 32 bit sparc systems
Hi, On Mon, 25 Jul 2005, Steve Langasek wrote: On Mon, Jul 25, 2005 at 02:06:46PM -0700, Blars Blarson wrote: In my opinion, we should drop support of all 32-bit sparc systems from Etch due to lack of people willing to spend the time to support them. This doesn't mean that we should delibaratly break things for them, but that the interest in continuing to support them is below what is needed to keep them as a viable part of Debian. 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. Were there actually install reports on sun4c and sun4d? I don't remember seeing any. Anyway, AIUI BenC killed these off years ago by changes to how gilbc was compiled. I have built an unoptimized glibc and made it available. A couple of people have attempted the woody -> sarge upgrades on sun4c machines using it and instructions at http://wiki.debian.net/?SparcSun4c with results which I would describe as "mostly successful" :-). Sun4m is the last supported 32-bit sparc architecture. Reportedly, the 2.6 kernel does not work in multi-processor mode on them, and dropping support of 2.4 from Etch is being discussed. Reportedly, current 2.6 kernels do not work *at all* on sun4m. This according to Jurij Smakov, who appears to currently be the sparc kernel maintainer in Debian. Yes, indeed I could not make it work with neither 2.6.11 or 2.6.12 kernels. It would not boot with initrd, debugging showed that basic memory copying routines are broken. Removing initrd support (initial plan for 2.6.12) actually made it possible to boot, but it did not eliminate the problems, so I was still occasionally triggering a filesystem corruption in my tests. In the end we decided not to build the sparc32 kernel images for 2.6.12 release, so the first step towards dropping it has already been done. It also appears that the success or failure to boot is correlated with positions of memory chips in the slots, not really an acceptable situation. 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. Blars, if you can keep one machine (fastest/most memory) until at least the end of September, I should be able to pick it up. I have one here; works fine under sarge with a 2.4 kernel. I have no intention of spending large amounts of my own time to keep 2.6 viable on this architecture, though, when as it stands the box I have is only powered up for use as a porting machine and it can't even be used to build Debian kernels because depmod bombs out. I am willing to fiddle with kernel options and available patches, but I'm really not hardcore enough to keep the sparc32 afloat. So unless someone upstream will start actively working on it again, I see dropping support for it as inevitable. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- 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, Jul 25, 2005 at 02:06:46PM -0700, Blars Blarson wrote: > In my opinion, we should drop support of all 32-bit sparc systems from > Etch due to lack of people willing to spend the time to support them. > This doesn't mean that we should delibaratly break things for them, > but that the interest in continuing to support them is below what is > needed to keep them as a viable part of Debian. > 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. Were there actually install reports on sun4c and sun4d? I don't remember seeing any. Anyway, AIUI BenC killed these off years ago by changes to how gilbc was compiled. > Sun4m is the last supported 32-bit sparc architecture. Reportedly, > the 2.6 kernel does not work in multi-processor mode on them, and > dropping support of 2.4 from Etch is being discussed. Reportedly, current 2.6 kernels do not work *at all* on sun4m. This according to Jurij Smakov, who appears to currently be the sparc kernel maintainer in Debian. > 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. I have one here; works fine under sarge with a 2.4 kernel. I have no intention of spending large amounts of my own time to keep 2.6 viable on this architecture, though, when as it stands the box I have is only powered up for use as a porting machine and it can't even be used to build Debian kernels because depmod bombs out. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Mopping up issues on an old sparc - need advice
On Tuesday 26 July 2005 02:12, Jon Biddell wrote: > All I'm saying, for what its worth, is that there are some people for > whom their old sparc32 is perfectly functional... Yes, but without people putting in the time and effort to get the (2.6) kernel properly supported on sparc32, it's still a no-go. You might want to read this bug report (ignore the flames) [1] for reference. [1] http://bugs.debian.org/319878 pgpejPtSOlCvN.pgp Description: PGP signature
Re: Mopping up issues on an old sparc - need advice
>>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. > > > Don't forget guys (and this argument for continued support may be a bit on the anorexic side) that some of the old sparc32 stuff is all some of us can afford. I was lucky in that I have a very understanding wife who indulges my gadget fetish and let me buy a SunBlade 1000, but before that I was working on an old SparcStation (not even an Ultra !!). Still perfectly servicable, especially as a learning tool, firewall, router, small mailserver, etc. > 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. > > > Flimsy, possibly, but valid. something as old and veneragle as a sparc32 machine is still more secure than anything ia32. All I'm saying, for what its worth, is that there are some people for whom their old sparc32 is perfectly functional... Jon -- 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 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." So, the choice was made _not_ to try to detect between different sun4m processors and the kernel upgrade section _does_ apply to you. pgpIepCaUbXTF.pgp Description: PGP signature
Re: Between a rock & a hard place, need monolithic 2.4.2x kernel for sun4m
On Tue, 26 Jul 2005 01:40:48 +0200 Frans Pop <[EMAIL PROTECTED]> wrote: > On Tuesday 26 July 2005 01:31, Eric Jorgensen wrote: > >Yes, since i have an RT626 i don't really meet the "if and only if" > > clause on needing to upgrade the kernel first. > > Hmmm? > > RT626 = SS20 = sun4m ? > (/me is not very familiar with Sparc models...) > > "sun4m CPUs are still supported but you need to install a newer kernel > version first before upgrading the system. This is necessary because > newer versions of glibc use assembler instructions not available on > certain machines, so you need a updated kernel first that emulates the > missing instructions." > > That means you qualify for the "if and only if" in 4.3.1, right? Nope, keep reading. "For those interested in the gory details: some of the sun4m chips, produced by Cypress/ROSS, don't implement the umul instruction (RT601/CY7C601, same chip, only different names). They were used in the early SPARCserver 6xxMP models. Later models used chips manufactured by TI. Currently we don't know if these are also affected." 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. -- 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 Tuesday 26 July 2005 01:31, Eric Jorgensen wrote: >Yes, since i have an RT626 i don't really meet the "if and only if" > clause on needing to upgrade the kernel first. Hmmm? RT626 = SS20 = sun4m ? (/me is not very familiar with Sparc models...) "sun4m CPUs are still supported but you need to install a newer kernel version first before upgrading the system. This is necessary because newer versions of glibc use assembler instructions not available on certain machines, so you need a updated kernel first that emulates the missing instructions." That means you qualify for the "if and only if" in 4.3.1, right? pgpJIG5ztQQZW.pgp Description: PGP signature
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]
Re: Between a rock & a hard place, need monolithic 2.4.2x kernel for sun4m
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... pgpvS0qXJV2DO.pgp Description: PGP signature
Between a rock & a hard place, need monolithic 2.4.2x kernel for sun4m
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. I cannot find any such beast compiled for woody. I also cannot install the sarge kernel image owing to not having sarge's initrd-tools, and not being able to install initrd-tools to it's liking. When i attempt to build 2.4.31, the build dies in conmakehash.c which appears to be pretty much required core kernel stuff. Something about getunicode having an undefined reference. I have no other linux/sparc machine installed anywhere anymore. Does anybody have a monolithic kernel or kernel + initrd that should boot and work on a bog-standard Sparcstation 10 with a single Hypersparc module, that i could, um, borrow for a few hours? -- 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
Am Dienstag, 26. Juli 2005 00:34 schrieb Martín Marqués: > El Lun 25 Jul 2005 18:19, Hendrik Sattler escribió: > > > 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. > > > > > > Sun4m is the last supported 32-bit sparc architecture. Reportedly, > > > the 2.6 kernel does not work in multi-processor mode on them, and > > > dropping support of 2.4 from Etch is being discussed. > > > > Ok, kernel development is not that easy, especially when it comes to SMP > > support. Additionally, I do not understand how such support can break > > during development... > > Please tell me if there is something else in debian with 64bit support. > AFAIK the kernel is the only 64bit binary. Not even gcc is 64 bit. > > The question I have now is: If everything, except the kernel is 32 bit, > what is it that's going to be dropped? Sparc32-SMP (like an SS20 with two MBUS-Modules) can only use one CPU with linux-2.6, dropping linux-2.4 (e.g. from installer) will make it a hard time installing Debian on it (well, still possible, though). Other could again argue on compiling with v9 instead of v8 (like currently done). This would definitely kill sun4m. HS
Re: Sarge may be last Debian release for 32 bit sparc systems
El Lun 25 Jul 2005 18:19, Hendrik Sattler escribió: > > > 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. > > > > Sun4m is the last supported 32-bit sparc architecture. Reportedly, > > the 2.6 kernel does not work in multi-processor mode on them, and > > dropping support of 2.4 from Etch is being discussed. > > Ok, kernel development is not that easy, especially when it comes to SMP > support. Additionally, I do not understand how such support can break during > development... Please tell me if there is something else in debian with 64bit support. AFAIK the kernel is the only 64bit binary. Not even gcc is 64 bit. The question I have now is: If everything, except the kernel is 32 bit, what is it that's going to be dropped? -- select 'mmarques' || '@' || 'unl.edu.ar' AS email; - Martín Marqués | Programador, DBA Centro de Telemática| Administrador Universidad Nacional del Litoral -
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: 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 > 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: 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, 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 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. >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? >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. >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. 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. Cheers, a -- 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
Am Montag, 25. Juli 2005 23:06 schrieb Blars Blarson: > In my opinion, we should drop support of all 32-bit sparc systems from > Etch due to lack of people willing to spend the time to support them. > This doesn't mean that we should delibaratly break things for them, > but that the interest in continuing to support them is below what is > needed to keep them as a viable part of Debian. Hmm, what's needed to support sparc32? Debian is one of the last to support sparc32 and I'd be really sorry to see it abandon that support. Any alternatives? > 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. > > Sun4m is the last supported 32-bit sparc architecture. Reportedly, > the 2.6 kernel does not work in multi-processor mode on them, and > dropping support of 2.4 from Etch is being discussed. Ok, kernel development is not that easy, especially when it comes to SMP support. Additionally, I do not understand how such support can break during development... HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sarge may be last Debian release for 32 bit sparc systems
In my opinion, we should drop support of all 32-bit sparc systems from Etch due to lack of people willing to spend the time to support them. This doesn't mean that we should delibaratly break things for them, but that the interest in continuing to support them is below what is needed to keep them as a viable part of Debian. 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. Sun4m is the last supported 32-bit sparc architecture. Reportedly, the 2.6 kernel does not work in multi-processor mode on them, and dropping support of 2.4 from Etch is being discussed. 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.) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- 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: 2.6.12 testers wanted
I've had it running on a v210 for a few days, but the box isn't doing much currently and I'm not using the tg3 interfaces. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.12 testers wanted
Jean Robertson <[EMAIL PROTECTED]> writes: >> What do you need to change in the setup? > > The mouse has to be set to /dev/input/mice and > the keyboard has to be xfree86 and "pc104" > > Everything else is the same. The same as for a 2.4 kernel? The above is what you'd use for previous 2.6 kernels as far as I know. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Your Message To scoug-general
Your message to the list scoug-general has been rejected. You are not a member of the list. For help on subscribing to the list, please send a message to [EMAIL PROTECTED] with the word "help" in the body of the message. Your humble mailing list software, Steward -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
