RE: An (flamebait ?) idea to preserve debian on sparc32...
Hi Jurij et all, Is this using the link to initrd.img in /boot? I had to change my symlink to read the full path for both vmlinuz and intrd, otherwise it hangs on bootup as it couldn't find them ... I think. i.e. These symlinks hang: - lrwxrwxrwx 1 root root 33 Jul 19 20:02 initrd.img - boot/initrd.img-2.6.12-1-sparc32 lrwxrwxrwx 1 root root 30 Jul 19 20:01 vmlinuz - boot/vmlinuz-2.6.12-1-sparc32 And these work fine: - lrwxrwxrwx 1 root root 33 Jul 19 20:02 initrd.img - /boot/initrd.img-2.6.12-1-sparc32 lrwxrwxrwx 1 root root 30 Jul 19 20:01 vmlinuz - /boot/vmlinuz-2.6.12-1-sparc32 On boot, I see it creating the RAM disk and then releasing the memory later on. Shall I post you a copy of a my kern.log from a bootup? Cheers, Steve -Original Message- From: Jurij Smakov [mailto:[EMAIL PROTECTED] Sent: 31 July 2005 15:39 To: Steve Cc: debian-sparc@lists.debian.org Subject: RE: An (flamebait ?) idea to preserve debian on sparc32... On Sat, 30 Jul 2005, Steve wrote: Well, I have mailed to this list before and said ... I have a SPARC 4 sun4m working quite happily with the 2.6.12-1-sparc32 kernel running a fully upgraded sarge installation. Perhaps the reason for it being so happy is because this box is just being used a DNS/Syslog server with no monitor attached. Anyway, I shall continue to drop this bit of info into the list until someone explains why there seem to be so many issues when it would appear this box will run quite happily for quite some time before problems arise regarding new kernels or OS releases. Always willing to learn :-) Hi Steve, Unfortunately, the good old QA standard it works for me does not apply in this case :-). I am aware of multiple problems with this kernel. To mention a few: * The kernel you tested does not have initrd support, unlike other Debian kernels. I could not boot it with initrd (panic on boot), so I disabled it. 2.4.27 boots fine with initrd. * Debugging of the initrd problem indicated that occasionally (not every time, so you can be just lucky) the basic memory-copying routine corrupts the data it copies. That's a very serious problem, and I don't know an easy way to fix it. I suspect that this is responsible for the filesystem corruption under heavy load, I can reliably trigger it by dist-upgrade, and in this case it corrupts dpkg status files, which usually requires a reinstallation. * I have an independent confirmation, that the success/failure of 2.6.12 kernel to boot is correlated to the locations of the memory chips in the slots. I don't think it is acceptable to release a kernel with problems like these to our users. 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: An (flamebait ?) idea to preserve debian on sparc32...
On Sat, 30 Jul 2005, Steve wrote: Well, I have mailed to this list before and said ... I have a SPARC 4 sun4m working quite happily with the 2.6.12-1-sparc32 kernel running a fully upgraded sarge installation. Perhaps the reason for it being so happy is because this box is just being used a DNS/Syslog server with no monitor attached. Anyway, I shall continue to drop this bit of info into the list until someone explains why there seem to be so many issues when it would appear this box will run quite happily for quite some time before problems arise regarding new kernels or OS releases. Always willing to learn :-) Hi Steve, Unfortunately, the good old QA standard it works for me does not apply in this case :-). I am aware of multiple problems with this kernel. To mention a few: * The kernel you tested does not have initrd support, unlike other Debian kernels. I could not boot it with initrd (panic on boot), so I disabled it. 2.4.27 boots fine with initrd. * Debugging of the initrd problem indicated that occasionally (not every time, so you can be just lucky) the basic memory-copying routine corrupts the data it copies. That's a very serious problem, and I don't know an easy way to fix it. I suspect that this is responsible for the filesystem corruption under heavy load, I can reliably trigger it by dist-upgrade, and in this case it corrupts dpkg status files, which usually requires a reinstallation. * I have an independent confirmation, that the success/failure of 2.6.12 kernel to boot is correlated to the locations of the memory chips in the slots. I don't think it is acceptable to release a kernel with problems like these to our users. 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: An (flamebait ?) idea to preserve debian on sparc32...
Well, I have mailed to this list before and said ... I have a SPARC 4 sun4m working quite happily with the 2.6.12-1-sparc32 kernel running a fully upgraded sarge installation. Perhaps the reason for it being so happy is because this box is just being used a DNS/Syslog server with no monitor attached. Anyway, I shall continue to drop this bit of info into the list until someone explains why there seem to be so many issues when it would appear this box will run quite happily for quite some time before problems arise regarding new kernels or OS releases. Always willing to learn :-) Cheers all, Steve -Original Message- From: Romain Dolbeau [mailto:[EMAIL PROTECTED] Sent: 27 July 2005 10:23 To: debian-sparc@lists.debian.org Subject: An (flamebait ?) idea to preserve debian on sparc32... Hello all, I know I'm going to get flamed but here I go anyway... Right now it seems the sparc32 port is in trouble, due primarily to the kernel having support problem. It can be summed up by : 1) The 2.4 kernel has trouble on some 4m hardware, and 2.6 is almost non-working ; 2) userland (mostly glibc) doesn't work on v7 hardware (all sun4 and sun4c arch, plus the SM100 modules on sun4m). So my idea is: why not go over to a kernel and libc that actually support all of the above ? Namely, the NetBSD kernel... Debian already has started support for NetBSD on i386 and alpha ; why not try and add both sparc32/v7 and sparc32/v8 (the second being able to re-use most of the first userland) to that list ? The regular sparc port would become a pure v9 port, w/o the need to support legacy HW, and people running Debian on sparc32 would be able to continue to do so. Of course some will say why don't you run NetBSD then ?, which I do on my sun4 / sun4c (and even sun3 and sun3x :-) hardware, but I prefer apt-get and friends for my userland, as I'm sure others do. So, what do the sparc32 people think ? -- Romain Dolbeau [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: An (flamebait ?) idea to preserve debian on sparc32...
[EMAIL PROTECTED] (Romain Dolbeau) writes: Splitting the port between sparc32-v7, sparc32-v8 and sparc-v9 would permit multiple libc, with or without a kernel change, and with backward availability of packages if the kernel is similar enough. Since there's already a v9 libc package, I assume there's no problem in principle of providing a v7 one, which can surely be built. However, the right one doesn't necessarily get picked up correctly. I made a relevant bug report long ago, to which I had no response as far as I remember. I don't recall the details, but it's basically that the dynamic loader doesn't check the right capability (?) for whether the relevant instructions are available. A question on the Debian dependency system: can it handle inter-archs dependency ? i.e. is it already feasible (in theory) to split an arch in two or more, and have dependency fall back from say v8 to v7 if a package is not in v8, like it does with unstable/testing/stable ? There's a discussion document, at least: URL:http://raw.no/debian/amd64-multiarch-2. The bit about using `gcc -dumpmachine' seems to be wrong, though, for sparc and, I guess, MIPS. [I assume Linux could emulate the missing instructions in principle.] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: An (flamebait ?) idea to preserve debian on sparc32...
On Thu, 28 Jul 2005, Dave Love wrote: [EMAIL PROTECTED] (Romain Dolbeau) writes: Splitting the port between sparc32-v7, sparc32-v8 and sparc-v9 would permit multiple libc, with or without a kernel change, and with backward availability of packages if the kernel is similar enough. Since there's already a v9 libc package, I assume there's no problem in principle of providing a v7 one, which can surely be built. I have been providing the glibc debs built without v8 optimizations and thus usable on v7 for a while now. Check out the wiki page at http://wiki.debian.net/?SparcSun4c If someone is willing to invest serious effort into supporting sparc32 machines (including sparc4c), I suggest to create a project on alioth for that purpose. 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: An (flamebait ?) idea to preserve debian on sparc32...
Am Mittwoch, 27. Juli 2005 10:23 schrieb Romain Dolbeau: So my idea is: why not go over to a kernel and libc that actually support all of the above ? Namely, the NetBSD kernel... Debian already has started support for NetBSD on i386 and alpha ; why not try and add both sparc32/v7 and sparc32/v8 (the second being able to re-use most of the first userland) to that list ? The regular sparc port would become a pure v9 port, w/o the need to support legacy HW, and people running Debian on sparc32 would be able to continue to do so. Of course some will say why don't you run NetBSD then ?, which I do on my sun4 / sun4c (and even sun3 and sun3x :-) hardware, but I prefer apt-get and friends for my userland, as I'm sure others do. So, what do the sparc32 people think ? Would be fine with me, I have already a dual-boot (Solaris8, Debian-3.1) an that SS20 clone, never tried NetBSD, though. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: An (flamebait ?) idea to preserve debian on sparc32...
Hendrik Sattler [EMAIL PROTECTED] wrote: As a side-note: does NetBSD support SMP on sun4m? This is the main issue for me. It's supposed to, on both SuperSPARC and HyperSPARC; I haven't tried it myself, as I don't have a SMP sun4m. -- Romain Dolbeau [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: An (flamebait ?) idea to preserve debian on sparc32...
2005-07-27, sze keltezéssel 10.23-kor Romain Dolbeau ezt írta: So my idea is: why not go over to a kernel and libc that actually support all of the above ? Namely, the NetBSD kernel... I am free software fundamentalist, so using BSD licenced code is only marginally acceptable for me. Also, I think this solution have greater support burden than the linux kernel way, where only some packages need special attention, one of them is the kernel which I am used to custom-build anyway. You would need to maintain buildd, cope with bugs in the all the user space related to bsdisms, maintain special packages, etc. I guess having a special repository with only the packages where upstream debian is not acceptable is the Debian way to go, if there are enough resources even for that. I hope the above did not flame;)
Re: An (flamebait ?) idea to preserve debian on sparc32...
Am Mittwoch, 27. Juli 2005 14:18 schrieb mag: Also, I think this solution have greater support burden than the linux kernel way, where only some packages need special attention, one of them is the kernel which I am used to custom-build anyway. You would need to maintain buildd, cope with bugs in the all the user space related to bsdisms, maintain special packages, etc. And BSD kernel with GNU userland? For building most applications, this should not make any difference except the cases where kernel headers of kernel features are use directly. HS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: An (flamebait ?) idea to preserve debian on sparc32...
mag [EMAIL PROTECTED] wrote: I am free software fundamentalist, so using BSD licenced code is only marginally acceptable for me. And some will argue that the GPL, by prohibiting some forms of use, is more restrictive and therefore less free than the BSD. Which would turn this discussion into a genuine flamefest we all already have seen a thousand times, so let's stop it before it get out of hands, shall we ? :-) Also, I think this solution have greater support burden than the linux kernel way, where only some packages need special attention, one of them is the kernel which I am used to custom-build anyway. You would need to maintain buildd, cope with bugs in the all the user space related to bsdisms, maintain special packages, etc. The point is, most of the work is already under way in the Debian NetBSD port on i386 and alpha. They're far from finished yet, but they probably have encountered (ans hopefully solved) most of the problems in packages closely related to the kernel. Also, if no one is able to keep the linux kernel running on sparc32, the manpower to port to a different kernel may still be available, as it requires a different set of skills. Anyway, it was just an idea to provoque discussion ; It'd probably better for everyone if the sparc32 port could be made to last for the next fifty years or so :-) I hope the above did not flame;) The flicker of a lighter in the first paragraph, maybe ;-) -- Romain Dolbeau [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: An (flamebait ?) idea to preserve debian on sparc32...
2005-07-27, sze keltezéssel 15.28-kor Romain Dolbeau ezt írta: mag [EMAIL PROTECTED] wrote: I am free software fundamentalist, so using BSD licenced code is only marginally acceptable for me. And some will argue that the GPL, by prohibiting some forms of use, is more restrictive and therefore less free than the BSD. Which would turn this discussion into a genuine flamefest we all already have seen a thousand times, so let's stop it before it get out of hands, shall we ? :-) I give the end of discussion here for referential purposes:) -- no incorrect idiot !%^@#*! fsck du of=/dev/null vi .procmailrc --- Also, I think this solution have greater support burden than the linux kernel way, The point is, most of the work is already under way in the Debian NetBSD port on i386 and alpha. Also, if no one is able to keep the linux kernel running on sparc32, the manpower to port to a different kernel may still be available, as it requires a different set of skills. Two points might worth considering. But I would rather keep applying the essential security patches to the one or two important packages, and keep running in an aged, unupgreadable pile of dust than use NetBSD,by religional motives. And anyway, using an appropriately old distrib in an old machine comes with the benefit of lesser resource usage.
Re: An (flamebait ?) idea to preserve debian on sparc32...
So you don't use apache, Xfree, or anything else with a similar license? That's a rediculous argument. Did you submit any code to libc or the linux kernel that really makes this a valid point? I can only see this as being a problem with people that do development for such software. Using it, has no bearing on GPL/BSD licensed code, since your use will not change (you get the source, and it's free to all). Just because someone else can reuse the code that you had nothing to do with, in a way that is closed source, is irrelevant to your use of it. On Wed, Jul 27, 2005 at 02:18:35PM +0200, mag wrote: 2005-07-27, sze keltez?ssel 10.23-kor Romain Dolbeau ezt ?rta: So my idea is: why not go over to a kernel and libc that actually support all of the above ? Namely, the NetBSD kernel... I am free software fundamentalist, so using BSD licenced code is only marginally acceptable for me. Also, I think this solution have greater support burden than the linux kernel way, where only some packages need special attention, one of them is the kernel which I am used to custom-build anyway. You would need to maintain buildd, cope with bugs in the all the user space related to bsdisms, maintain special packages, etc. I guess having a special repository with only the packages where upstream debian is not acceptable is the Debian way to go, if there are enough resources even for that. I hope the above did not flame;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: An (flamebait ?) idea to preserve debian on sparc32...
On Wed, Jul 27, 2005 at 01:50:58PM +0200, Hendrik Sattler wrote: As a side-note: does NetBSD support SMP on sun4m? This is the main issue for me. Indeed it does - NetBSD 2.0 and later support SMP on pretty much all Super/HyperSPARC CPUs. You can even mix speeds, but not CPUs with cache with CPUs without cache. I've had very good results with it. -mj -- Michael-John Turner | http://weblogs.turner.org.za/mj/ [EMAIL PROTECTED]| Open Source in WC ZA - http://www.clug.org.za/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: An (flamebait ?) idea to preserve debian on sparc32...
On Wed, Jul 27, 2005 at 10:23:05AM +0200, Romain Dolbeau wrote: 2) userland (mostly glibc) doesn't work on v7 hardware (all sun4 and sun4c arch, plus the SM100 modules on sun4m). So my idea is: why not go over to a kernel and libc that actually support all of the above ? Namely, the NetBSD kernel... But the Debian NetBSD project is using GNU usersland, which should include glibc, unless I'm greatly confused (which is certainly not out of the question). So if glibc is a problem There's also the Debian FreeBSD project, which isn't (from all reports) quite as far advanced, but still might be worth a shot if (and, I suppose, only if) glibc does indeed turn out to be a showstopper for the Debian NetBSD/Sparc32 idea. But heck, me and my SS5 are definitely in, whichever way we decide to go. I just got this thing. Don't mind that it's obsolete, since it was free, but it would be nice if it could end up helping Debian somehow, since that's kinda why I got it for free. :) -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: An (flamebait ?) idea to preserve debian on sparc32...
On Wed, Jul 27, 2005 at 10:23:05AM +0200, Romain Dolbeau wrote: So my idea is: why not go over to a kernel and libc that actually support all of the above ? Namely, the NetBSD kernel... It'd be easier just to install netbsd. It doesn't have all the features of linux, but it's not bad. It has tons of apps in pkgsrc and you can get binaries, too. -- Tom Vier [EMAIL PROTECTED] DSA Key ID 0x15741ECE -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: An (flamebait ?) idea to preserve debian on sparc32...
On Wed, Jul 27, 2005 at 03:03:17PM -0400, Tom Vier wrote: On Wed, Jul 27, 2005 at 10:23:05AM +0200, Romain Dolbeau wrote: So my idea is: why not go over to a kernel and libc that actually support all of the above ? Namely, the NetBSD kernel... It'd be easier just to install netbsd. It'd be even easier just to stick with the Solaris system that came with the box. But I don't want to. I want to run a GNU system. I don't really care what the kernel is, but I *much* prefer the GNU userspace. And _as a Debian Developer_, I'd rather use a Debian-based system of some sort. -- Chris Waters | Pneumonoultra-osis is too long [EMAIL PROTECTED] | microscopicsilico-to fit into a single or [EMAIL PROTECTED] | volcaniconi- standalone haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
