Hi all;
What's the status of the CentOS 5 for the i586 project?
http://wiki.centos.org/Projects/CentOS5PentiumSupport
I was experimenting with my AMD K6-II machine today. By following the notes at http://wiki.centos.org/TimothyLee/centos5_i586_patch and the link above, I managed to compile an i586 kernel and deploy it on the K6 machine, which is now running C5 happily behind me with about 76MB of RAM. I wrote down the steps I took and the problems I encountered, which I need to organize a bit.
Is this information useful in any way? I know the K6 is *practically* dead, but I'm sure there's a few diehards using it still. (Maybe three or four?)
I'll be playing around with this machine a little more and experimenting. It was a great learning experience.
Cheers, Cody Jackson
On 3/6/2011 12:10, Cody Jackson wrote:
Hi all;
What's the status of the CentOS 5 for the i586 project?
Umm. No one is officially working on it, as far as I know.
I was experimenting with my AMD K6-II machine today. By following the notes at http://wiki.centos.org/TimothyLee/centos5_i586_patch and the link above, I managed to compile an i586 kernel and deploy it on the K6 machine, which is now running C5 happily behind me with about 76MB of RAM. I wrote down the steps I took and the problems I encountered, which I need to organize a bit.
I'm glad that my notes helped you. I was hoping to migrate some i586 machines from Fedora 7 to CentOS 5, but never quite got around to that. Perhaps you could organize your steps into a wiki page -- even though there is no official support, at least the steps will be there if someone else is interested in trying them out.
Regards, Timothy
Am 03.06.2011 um 11:26 schrieb Timothy Lee:
On 3/6/2011 12:10, Cody Jackson wrote:
Hi all;
What's the status of the CentOS 5 for the i586 project?
Umm. No one is officially working on it, as far as I know.
I was experimenting with my AMD K6-II machine today. By following the notes at http://wiki.centos.org/TimothyLee/centos5_i586_patch and the link above, I managed to compile an i586 kernel and deploy it on the K6 machine, which is now running C5 happily behind me with about 76MB of RAM. I wrote down the steps I took and the problems I encountered, which I need to organize a bit.
I'm glad that my notes helped you. I was hoping to migrate some i586 machines from Fedora 7 to CentOS 5, but never quite got around to that. Perhaps you could organize your steps into a wiki page -- even though there is no official support, at least the steps will be there if someone else is interested in trying them out.
Thats quite interesting - i am starting playing with an ALIX.2D13 system now and was looking into centos 5 support. The cpu is a 500 MHz AMD Geode LX800. So far my informations, they do not support the i686 instruction set. They are some hardware encryption support but corresponding kernel patches must be applied.
Your informations will for sure be very helpful.
Cheers Leon
On 06/03/2011 05:10 AM, Cody Jackson wrote:
What's the status of the CentOS 5 for the i586 project?
off the top of my head - its not been going anywhere. People have on and off expressed interest, but never really had the traction to keep up with it.
That seems to be a good place to start the project off from
link above, I managed to compile an i586 kernel and deploy it on the K6 machine, which is now running C5 happily behind me with about 76MB
If you guys want, we can get the project going ( c5-i586 support ) and get it into a regular / more official channel. The 'challenges' are going to be :
- Making sure the patchset is sane
- Making sure that we can sync updates between the main centos repos and the i586 specific one.
- Working out a mechanism that does not need us to reproduce the entire packageset from the main repo's into the i586 specific ones.
- KB
On Friday, June 03, 2011 12:10:23 AM Cody Jackson wrote:
Is this information useful in any way? I know the K6 is *practically* dead, but I'm sure there's a few diehards using it still. (Maybe three or four?)
Yes, it's useful. i586, as mentioned already in the thread, is needed for Geode support, as well as VIA C3 support. I have a number of Chompers and Sharptooth boxes lying around that make good embedded systems, with decent amounts of RAM and disk. I also have a few C3 systems, and getting CentOS 5 on them would be nice. Not critical, but nice. Expecially the Nomadix hotspot gateway box, which has multiple 10/100 ports and a very low power setup with decent RAM....
hi,
On 06/03/2011 02:11 PM, Lamar Owen wrote:
Yes, it's useful. i586, as mentioned already in the thread, is needed for Geode support, as well as VIA C3 support. I have a number of Chompers and Sharptooth boxes lying around that make good embedded systems, with decent amounts of RAM and disk. I also have a few C3 systems, and getting CentOS 5 on them would be nice. Not critical, but nice. Expecially the Nomadix hotspot gateway box, which has multiple 10/100 ports and a very low power setup with decent RAM....
looks like a case is building to start considering next-steps in getting a i586 repo/ in place !
- KB
On Friday, June 03, 2011 09:31:55 AM Karanbir Singh wrote:
looks like a case is building to start considering next-steps in getting a i586 repo/ in place !
How might such a repo be handled, in terms of development?
Also, there are other 'secondary' architectures that have somewhat languished, including SPARC and IA64. I have interest, and hardware, for both of those.
While I am going to work towards getting the IA64 build done here privately regardless, and may try to do something SPARC as well (that one is harder), having some more information (which could be out there already for all I know) on bootstrapping an architecture would be useful and make the first, biggest, step a tad easier. The Fedora project has info for doing this with Fedora; perhaps a base to work from.
And while I further know that the project wouldn't sign packages that I built here, I would still build packages here for my own purposes anyway.
So having somewhat of a really high-level overview of handling of secondary arches would be useful, to more than just me I'm sure.
In any case, having an i586-bootable setup (even though I'll have to respin the ISO to use serial console on the hardware I have) will be a nice thing indeed.
On 06/03/2011 03:39 PM, Lamar Owen wrote:
On Friday, June 03, 2011 09:31:55 AM Karanbir Singh wrote:
looks like a case is building to start considering next-steps in getting a i586 repo/ in place !
How might such a repo be handled, in terms of development?
Let me get a potential plan/proposal together. It would need to be something that can stay in sync with the main os/ and updates/ builds as a minimum. Although we can perhaps run with a more relaxed test/release process.
Also, there are other 'secondary' architectures that have somewhat languished, including SPARC and IA64. I have interest, and hardware, for both of those.
there is actually an ia64 build that runs in parallel with the x86_64 C5 stream.... And there has been a fair bit of work done on Sparc for c6. Lets work on getting a plan together for these 'extra' archs using the i586 target as a model - we can then expand that to include other arch's as well.
I'm also working on bringing in more resources towards the build/test/release infrastructure over the next few months. Lets see how that goes.
And while I further know that the project wouldn't sign packages that I built here, I would still build packages here for my own purposes anyway.
If the development process can churn via patches that get some sort of peer review, I dont see why the build+sign cant happen inside a centos builder instance. There is hardware for ia64/i586/sparc available. Keys are still something to look at further down the road.
So having somewhat of a really high-level overview of handling of secondary arches would be useful, to more than just me I'm sure.
cool, let me get something together. It will, ofcourse, be a lot easier in C6 than C4/C5; unless we can migrate the whole c4/c5 buildservices over to use the event driven stuff in C6
- KB
On Friday, June 03, 2011 11:02:06 AM Karanbir Singh wrote:
there is actually an ia64 build that runs in parallel with the x86_64 C5 stream.... And there has been a fair bit of work done on Sparc for c6.
[snip good info]
Hmm, is this ia64 build available publicly? The last I saw was fairly old. But it's been a month or more since I looked last. We've just acquired a second box (which is more than one machine) to augment the one SGI Altix 3000 we have; this one is a melange of a small Altix 3000 and a stack of Altix 350's in one tall cabinet; at least part of that one will be operational fairly soon.
So having somewhat of a really high-level overview of handling of secondary arches would be useful, to more than just me I'm sure.
cool, let me get something together. It will, ofcourse, be a lot easier in C6 than C4/C5; unless we can migrate the whole c4/c5 buildservices over to use the event driven stuff in C6
This sounds very cool.
Hi Karanbir,
On Fri, 2011-06-03 at 16:02 +0100, Karanbir Singh wrote:
And while I further know that the project wouldn't sign packages that I built here, I would still build packages here for my own purposes anyway.
If the development process can churn via patches that get some sort of peer review, I dont see why the build+sign cant happen inside a centos builder instance. There is hardware for ia64/i586/sparc available. Keys are still something to look at further down the road.
I had exactly this in mind when I was advocating for keeping SPEC files and patches in git repositories ala git-buildpackage earlier on this list.
Johnny might not find this kind of development workflow acceptable for himself, but I think that this could be quite an interesting option at least for the development efforts for the extra arches.
For instance, you can have a stack of git repositories for packages needing a change, and those could be connected to some review board software, there are herds of those available for git.
Finally, someone might flag packages as reviewed and build / sign them on CentOS hardware, or alternatively leads behind such efforts could be given access to some secondary signing keys which would be dedicated to signing packages for extra arches.
This would also enable for easy import / backport of the updates to stay in sync with the main CentOS distribution.
On Jun 3, 2011, at 11:39 AM, Yury V. Zaytsev wrote:
Hi Karanbir,
On Fri, 2011-06-03 at 16:02 +0100, Karanbir Singh wrote:
And while I further know that the project wouldn't sign packages that I built here, I would still build packages here for my own purposes anyway.
If the development process can churn via patches that get some sort of peer review, I dont see why the build+sign cant happen inside a centos builder instance. There is hardware for ia64/i586/sparc available. Keys are still something to look at further down the road.
I had exactly this in mind when I was advocating for keeping SPEC files and patches in git repositories ala git-buildpackage earlier on this list.
So grab the SRPM's and import spec/patches into git.
Its easier to do than to advocate imho.
73 de Jeff
On 06/03/2011 04:44 PM, Jeff Johnson wrote:
So grab the SRPM's and import spec/patches into git.
Its easier to do than to advocate imho.
I have something at https://nazar.karan.org/cgit/, am hoping to keep that updated with c6 releases - if there is an interest, I can pull in the c4/c5 tree's as well :)
- KB
Wow, I'm glad there's some interest in this.
To go into a bit more detail, I didn't need to patch anything (although I'm looking into an unrelated issue for a soundblaster16 isa driver that might need a patch--but one step at a time) and the spec file had minimal changes. Which, come to think of it, would be a great use for a patch. Sorry, haven't had my caffeine yet.
I did, as suggested by the Wiki page, copy the i686 config over the i586 config and modify it for the i586, since apparently the i586 config that comes with the .src.rpm is not up to date and does not build. At the moment I am rebuilding the kernel--it's still going, as I can hear by the angry CPU fan on my build server--and writing down a step-by-step outline of what I did, which I'll put on the Wiki after my errands today.
It turns out I have another machine that can be used for testing: a laptop with an AMD K6-II @ 400Mhz with 128MB RAM. In addition to this, I also have about eight or nine various i586 CPUs I can plug into the desktop--several Pentiums (90-133Mhz, if I recall right), a few more AMD K6's, at least one IBM/Cryrix oddball. Unfortunately, I don't have any Alpha machines on hand, but at least Nick does. :)
This is exciting! Unfortunately, I don't have the slightest clue what needs to be done next, so I'm hoping that you guys will be willing to point me in the next direction after I am sure these steps are reproducible. Building the kernel in and of itself was a learning exercise, so I'm hoping that I'll be able to learn more as I go along, especially in the realm of rpm building; my sources/ directory is already getting a bit messy. ;)
Also, when C6 comes out, I'll happily grab the .src.rpm and see if it has a liking for the i586 arch as well.
Cheers, Cody Jackson
On Friday, June 03, 2011 04:57:13 PM Cody Jackson wrote:
Wow, I'm glad there's some interest in this.
[snip]
I can hear by the angry CPU fan on my build server--and writing down a step-by-step outline of what I did, which I'll put on the Wiki after my errands today.
It turns out I have another machine that can be used for testing:
[snip]
reproducible. Building the kernel in and of itself was a learning exercise, so I'm hoping that I'll be able to learn more as I go along, especially in the realm of rpm building; my sources/ directory is already getting a bit messy. ;)
Sounds like progress, Cody. Glad to see you getting in there and getting your hands dirty with doing the work.... and then being willing to take the time and effort to document that work. Kudos.
Also, when C6 comes out, I'll happily grab the .src.rpm and see if it has a liking for the i586 arch as well.
That one may be much harder, since it currently requires PAE on 32 bit x86, and due to the elimination of the separation between the distributed source tarball and patch bundles. To the best of my knowledge PAE has never been available on i586, so that issue will have to be addressed (pardon the pun) as well.
Perhaps rebuilding a Fedora kernel that is close to the EL6 kernel could be a useful exercise to see what may need to be patched around, since the whole distribution tarball/patch segregation was tossed out with the EL6 kernels.
On Fri, Jun 3, 2011 at 2:04 PM, Lamar Owen lowen@pari.edu wrote:
On Friday, June 03, 2011 04:57:13 PM Cody Jackson wrote:
Also, when C6 comes out, I'll happily grab the .src.rpm and see if it has a liking for the i586 arch as well.
That one may be much harder, since it currently requires PAE on 32 bit x86, and due to the elimination of the separation between the distributed source tarball and patch bundles. Â To the best of my knowledge PAE has never been available on i586, so that issue will have to be addressed (pardon the pun) as well.
If anyone is serious about providing the i586 support for CentOS-6, it's worth trying by starting with the "expected" modifications to the spec and config files. The distro config of the el6 kernel has:
CONFIG_X86_PAE=y # CONFIG_M586 is not set
Whether the kernel builds without a problem or, if it is indeed built, whether it actually runs is another story :-)
_Assuming_ there is no need to patch the code itself, the single source tarball should not be an issue just like it is not for the centosplus kernels (so far).
Akemi
On Fri, 2011-06-03 at 11:44 -0400, Jeff Johnson wrote:
So grab the SRPM's and import spec/patches into git. Its easier to do than to advocate imho.
What makes you think that I am not doing it?
I believe that it's not hard to see where I'm going: I am not exactly in the RHEL rebuilding business as my primarily occupation, so it would be highly beneficial for me to have access to the CentOS repos.
Ok maybe this discussion has to be postponed again for an indefinite amount of time.
On Fri, 2011-06-03 at 17:08 +0100, Karanbir Singh wrote:
We have had spec files and content in a version control setup for about 6 years now :)
Ok, that's really new, but great to hear! There were contrary claims to that on the mailing list which might have resulted into (my?) confusion.
version control does not solve anything really, its just a storage mechanism. It might make things easier for some people, harder for others, but its just a storage format for some parts of the metadata.
Exactly, but it's not *just* a storage mechanism, but rather a storage mechanism which also allows for easy sharing and collaboration.
Also, using git is definitely the way to go these days. Specially now that it can work with depth extraction from remote repos.
+1. You know that I am with you on this one.
On Sat, 4 Jun 2011, Yury V. Zaytsev wrote:
so it would be highly beneficial for me to have access to the CentOS repos
and so??
Install lftp, build a minimal mirroring config file, and drop it into cron. For daily diff's, post process each result tree daily with 'find' into well-named result files, and diff today's and yesterday's (or whatever interval you feel is needed) copies. Hand off the diff fruit to autobuilders, to taste; review the builder logs and supplement to taste
This is not rocket science, folks, just a matter of 'lather, rinse, and repeat' in the usual minimal case
-- Russ herrold
On Fri, 2011-06-03 at 18:25 -0400, R P Herrold wrote:
On Sat, 4 Jun 2011, Yury V. Zaytsev wrote:
so it would be highly beneficial for me to have access to the CentOS repos
and so??
And so I'm doing it (for select packages), but it would be easier for me if I wouldn't, and I might be not alone. That's all that I'm saying.
On 06/03/2011 04:39 PM, Yury V. Zaytsev wrote:
If the development process can churn via patches that get some sort of peer review, I dont see why the build+sign cant happen inside a centos builder instance. There is hardware for ia64/i586/sparc available. Keys are still something to look at further down the road.
I had exactly this in mind when I was advocating for keeping SPEC files and patches in git repositories ala git-buildpackage earlier on this list.
We have had spec files and content in a version control setup for about 6 years now :) we just need to find a working mechanism around it that allows for external stuff to sync in. Eg, using callbacks from within the buildsystem - I spoke about this briefly at my loadays talk earlier this year.
For instance, you can have a stack of git repositories for packages needing a change, and those could be connected to some review board software, there are herds of those available for git.
...
This would also enable for easy import / backport of the updates to stay in sync with the main CentOS distribution.
version control does not solve anything really, its just a storage mechanism. It might make things easier for some people, harder for others, but its just a storage format for some parts of the metadata. Also, using git is definitely the way to go these days. Specially now that it can work with depth extraction from remote repos.
- KB
On 03.06.2011 17:02, Karanbir Singh wrote:
there is actually an ia64 build that runs in parallel with the x86_64 C5 stream.... And there has been a fair bit of work done on Sparc for c6. Lets work on getting a plan together for these 'extra' archs using the i586 target as a model - we can then expand that to include other arch's as well.
Anyone tinkering with C6 for Power?
On 06/05/2011 01:48 PM, Morten Torstensen wrote:
On 03.06.2011 17:02, Karanbir Singh wrote:
there is actually an ia64 build that runs in parallel with the x86_64 C5 stream.... And there has been a fair bit of work done on Sparc for c6. Lets work on getting a plan together for these 'extra' archs using the i586 target as a model - we can then expand that to include other arch's as well.
Anyone tinkering with C6 for Power?
Yes, Fabian and I have been looking at that - semi blocker is the need for a power7+ machine
- KB
If any traction shows up for Alpha, I have a DEC PWS 500 I'll gladly set up in whatever way is necessary, hook up to the network, and give whomever wants to work on the project access to the box.
Personally I don't have a great desire to work on it, but I do have some hardware I can make available if it's helpful.
Thanks for all of your hard work on CentOS guys!
----------------------------------------------- - Nick Bright - - Network Administrator - - Valnet Telecommunications - - Tel 888-332-1616 x 315 / Fax 620-331-0789 - - Web http://www.valnet.net/ - ----------------------------------------------- - Are your files safe? - - Valnet Vault - Secure Cloud Backup - - More information & 30 day free trial at - - http://www.valnet.net/services/valnet-vault - -----------------------------------------------
On 6/3/2011 9:39 AM, Lamar Owen wrote:
On Friday, June 03, 2011 09:31:55 AM Karanbir Singh wrote:
looks like a case is building to start considering next-steps in getting a i586 repo/ in place !
How might such a repo be handled, in terms of development?
Also, there are other 'secondary' architectures that have somewhat languished, including SPARC and IA64. I have interest, and hardware, for both of those.
While I am going to work towards getting the IA64 build done here privately regardless, and may try to do something SPARC as well (that one is harder), having some more information (which could be out there already for all I know) on bootstrapping an architecture would be useful and make the first, biggest, step a tad easier. The Fedora project has info for doing this with Fedora; perhaps a base to work from.
And while I further know that the project wouldn't sign packages that I built here, I would still build packages here for my own purposes anyway.
So having somewhat of a really high-level overview of handling of secondary arches would be useful, to more than just me I'm sure.
In any case, having an i586-bootable setup (even though I'll have to respin the ISO to use serial console on the hardware I have) will be a nice thing indeed. _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 6/3/2011 8:31 AM, Karanbir Singh wrote:
hi,
On 06/03/2011 02:11 PM, Lamar Owen wrote:
Yes, it's useful. i586, as mentioned already in the thread, is needed for Geode support, as well as VIA C3 support. I have a number of Chompers and Sharptooth boxes lying around that make good embedded systems, with decent amounts of RAM and disk. I also have a few C3 systems, and getting CentOS 5 on them would be nice. Not critical, but nice. Expecially the Nomadix hotspot gateway box, which has multiple 10/100 ports and a very low power setup with decent RAM....
looks like a case is building to start considering next-steps in getting a i586 repo/ in place !
Is there any chance this will happen for 6.x as well? There is an attempt to revive what was once the k12ltsp disto (with ltsp4 for thin-client booting) that was sidetracked into fedora packages based on ltsp5, then effectively killed by changes in fedora that were propagated into RHEL6. At this point the bottom line seems to be that ltsp5 can mostly be made to work, but since many thin clients are i586 and ltsp5 runs more than just a kernel and X on the client, it will either need a rebuilt distro that supports i586 or a completely different distribution in the chroot client space.
On 06/03/2011 03:47 PM, Les Mikesell wrote:
looks like a case is building to start considering next-steps in getting a i586 repo/ in place !
Is there any chance this will happen for 6.x as well? There is an
Thats really the wrong attitude and question. Let me flip it around : rather than asking if someone else is going to do this - what are you willing to do for the i586 in C6 thing to happen ?
- KB
On 6/3/2011 10:03 AM, Karanbir Singh wrote:
On 06/03/2011 03:47 PM, Les Mikesell wrote:
looks like a case is building to start considering next-steps in getting a i586 repo/ in place !
Is there any chance this will happen for 6.x as well? There is an
Thats really the wrong attitude and question. Let me flip it around : rather than asking if someone else is going to do this - what are you willing to do for the i586 in C6 thing to happen ?
Probably nothing, since I don't have any need for it myself and was more interested in the k12ltsp distro because it included several other 'usability' additions like a working, rpm packaged java back when everyone else made that as difficult as they possibly could than the thin-client handling aspect. And if I did need it, I'd probably try to boot something like puppy linux to clients under drbl instead.
But maybe someone could think of the children....
Am 03.06.2011 um 15:11 schrieb Lamar Owen:
On Friday, June 03, 2011 12:10:23 AM Cody Jackson wrote:
Is this information useful in any way? I know the K6 is *practically* dead, but I'm sure there's a few diehards using it still. (Maybe three or four?)
Yes, it's useful. i586, as mentioned already in the thread, is needed for Geode support, as well as VIA C3 support.
I am running c5 on geode now and saw that the cmov instruction is provided by this cpu despite being in the i586 cpu family.
Right now only i386 and i586 rpms are installed. I will try later to upgrade the corresponding rpms to i686 versions.
[root@localhost ~]# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 10 model name : Geode(TM) Integrated Processor by AMD PCS stepping : 2 cpu MHz : 498.097 cache size : 128 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de pse tsc msr cx8 pge cmov clflush mmx mmxext 3dnowext 3dnow up bogomips : 996.19
[root@localhost ~]# head -4 /proc/meminfo MemTotal: 255140 kB MemFree: 174188 kB Buffers: 5224 kB Cached: 64996 kB
Cheers Leon
I just had a look at the rhel6 kernel source, and it looks like this is going to be troublesome for i586 support. It generates configuration files on the fly (?) and doesn't include an i586 config file by default--defunct or not. I imagine, but don't know for certain, that the preapplied patches may make things difficult too. I hope someone more familiar with the kernel than I can look into this and tell me I'm wrong, but until then, I'll be focusing my efforts on C5.
So far, the C5 kernel builds (and runs) and I made a "shotgun patch" to remove -ffast-math from the mesa packages, which builds fine. Before I play around more with Mesa I hope to test and see if the i586 actually dislikes -ffast-math or not, which might mean popping out the AMD K6 and testing with a genuine Pentium. The other possibly troublesome package is procps, which also uses -ffast-math. It'd be great if we could verify that -ffast-math actually plays nice on i586 equipment.
After getting the packages playing nice, I'll see about getting a build script together. It'd be nice to be able to automate these builds this without messing with the original srpm, although to pass things to mock it looks like the srpm has to be extracted, two files munged, the srpm repacked and then handed to mock.
Again, for those of you wondering why I'm scratching my head over -ffast-math, I'm going by information on this wiki page, which I haven't been able to test yet: http://wiki.centos.org/Projects/CentOS5PentiumSupport
Cheers, Cody Jackson
On Tue, 2011-06-07 at 14:15 -0700, Cody Jackson wrote:
After getting the packages playing nice, I'll see about getting a build script together. It'd be nice to be able to automate these builds this without messing with the original srpm, although to pass things to mock it looks like the srpm has to be extracted, two files munged, the srpm repacked and then handed to mock.
Might seem inconvenient at first, but there is a whole ideology behind it. SRPMs are autonomous building blocks and you should in theory be able to rebuild the whole distribution from SRPMs with only minimal bootstrapping. So it's how it should be.
On 6/7/11, Yury V. Zaytsev yury@shurup.com wrote:
Might seem inconvenient at first, but there is a whole ideology behind it. SRPMs are autonomous building blocks and you should in theory be able to rebuild the whole distribution from SRPMs with only minimal bootstrapping. So it's how it should be.
Oh, believe me, I see the advantages of the building-block nature of SRPMs, which is why I want to try to preserve it :)
On 6/7/11, Akemi Yagi amyagi@gmail.com wrote:
Cody,
If you really want to play with c6, grab one of the centosplus kernels for c6 from here:
http://centos.toracat.org/kernel/centos6/centosplus-testing/SRPMS/
These kernels have familiar kernel config files. :)
Also, you can find a "howto" on the c6 kernel here:
http://bugs.centos.org/view.php?id=4586
The first 3 notes will help you with customization.
Thanks, Akemi; I'll have these bookmarked for the next time I have access to a better connection. The customisation notes, in particular, look to be *very* helpful! What I'd like to do is make it in the build script to where these changes can be applied near automagically and without messing up the original srpm if I mess with the c6 kernel.
Cheers, Cody Jackson
On Tue, Jun 7, 2011 at 2:15 PM, Cody Jackson supertanker13@gmail.com wrote:
I just had a look at the rhel6 kernel source, and it looks like this is going to be troublesome for i586 support. It generates configuration files on the fly (?) and doesn't include an i586 config file by default--defunct or not. I imagine, but don't know for certain, that the preapplied patches may make things difficult too. I hope someone more familiar with the kernel than I can look into this and tell me I'm wrong, but until then, I'll be focusing my efforts on C5.
Cody,
If you really want to play with c6, grab one of the centosplus kernels for c6 from here:
http://centos.toracat.org/kernel/centos6/centosplus-testing/SRPMS/
These kernels have familiar kernel config files. :)
Also, you can find a "howto" on the c6 kernel here:
http://bugs.centos.org/view.php?id=4586
The first 3 notes will help you with customization.
Good luck,
Akemi
On 6/7/2011 4:23 PM, Akemi Yagi wrote:
On Tue, Jun 7, 2011 at 2:15 PM, Cody Jacksonsupertanker13@gmail.com wrote:
I just had a look at the rhel6 kernel source, and it looks like this is going to be troublesome for i586 support. It generates configuration files on the fly (?) and doesn't include an i586 config file by default--defunct or not. I imagine, but don't know for certain, that the preapplied patches may make things difficult too. I hope someone more familiar with the kernel than I can look into this and tell me I'm wrong, but until then, I'll be focusing my efforts on C5.
Cody,
If you really want to play with c6, grab one of the centosplus kernels for c6 from here:
http://centos.toracat.org/kernel/centos6/centosplus-testing/SRPMS/
Is more than just the kernel 686-specific in 6.x? I got the idea from this: https://fedorahosted.org/k12linux/wiki/EL6Status (last thing under 'low priority todo') that to get a 586 thin-client working with ltsp most/all of the system would have to be recompiled.
Hi Cody,
Am 07.06.2011 um 23:15 schrieb Cody Jackson:
After getting the packages playing nice, I'll see about getting a build script together. It'd be nice to be able to automate these builds this without messing with the original srpm, although to pass things to mock it looks like the srpm has to be extracted, two files munged, the srpm repacked and then handed to mock.
...
i consolidated the steps mentioned on the wiki. Here a patch file against the rpmbuild tree. Following will help you to automate the process:
rpm -iv k.src.rpm patch < file.diff rpmbuild -bs k.spec
this builds a k.src.rpm for e.g. mock ...
Cheers Leon
--
diff -u -r rpmbuild.dist/SOURCES/kernel-2.6.18-i586.config rpmbuild.i586/SOURCES/kernel-2.6.18-i586.config --- rpmbuild.dist/SOURCES/kernel-2.6.18-i586.config 2011-05-08 02:06:22.000000000 +0200 +++ rpmbuild.i586/SOURCES/kernel-2.6.18-i586.config 2011-06-06 17:32:17.000000000 +0200 @@ -67,7 +67,7 @@ CONFIG_PCI_STUB=y CONFIG_PCIEPORTBUS=y # FIXME: Was borked in .17git11 for non-acpi machines. -# CONFIG_HOTPLUG_PCI_PCIE is not set +CONFIG_HOTPLUG_PCI_PCIE=m CONFIG_HOTPLUG_PCI_FAKE=m # CONFIG_HOTPLUG_PCI_PCIE_POLL_EVENT_MODE is not set CONFIG_ISA=y @@ -96,7 +96,7 @@ CONFIG_MMC_WBSD=y CONFIG_MMC_SDHCI=m
-# CONFIG_INFINIBAND is not set +CONFIG_INFINIBAND=m CONFIG_INFINIBAND_USER_MAD=m CONFIG_INFINIBAND_USER_ACCESS=m CONFIG_INFINIBAND_ADDR_TRANS=y @@ -1001,7 +1001,7 @@ # # Network testing # -# CONFIG_NET_PKTGEN is not set +CONFIG_NET_PKTGEN=m # CONFIG_NET_TCPPROBE is not set CONFIG_NET_DROP_MONITOR=y CONFIG_NETDEVICES=y @@ -1619,7 +1619,7 @@ CONFIG_N_HDLC=m # CONFIG_STALDRV is not set # CONFIG_FTAPE is not set -# CONFIG_IBM_ASM is not set +CONFIG_IBM_ASM=m CONFIG_TCG_TPM=m CONFIG_TCG_TIS=m CONFIG_TCG_NSC=m @@ -1737,7 +1737,7 @@ CONFIG_SENSORS_F71805F=m CONFIG_SENSORS_GL518SM=m CONFIG_SENSORS_GL520SM=m -# CONFIG_SENSORS_HDAPS is not set +CONFIG_SENSORS_HDAPS=m CONFIG_SENSORS_IT87=m CONFIG_SENSORS_LM63=m CONFIG_SENSORS_LM75=m @@ -1810,7 +1810,7 @@ # # IPMI # -# CONFIG_IPMI_HANDLER is not set +CONFIG_IPMI_HANDLER=m CONFIG_IPMI_PANIC_EVENT=y CONFIG_IPMI_DEVICE_INTERFACE=m CONFIG_IPMI_WATCHDOG=m @@ -1878,23 +1878,23 @@ CONFIG_RTC_DRV_PCF8583=m CONFIG_RTC_DRV_V3020=m
-# CONFIG_DTLK is not set -# CONFIG_R3964 is not set +CONFIG_DTLK=m +CONFIG_R3964=m # CONFIG_APPLICOM is not set -# CONFIG_SONYPI is not set +CONFIG_SONYPI=m
# # Ftape, the floppy tape device driver # CONFIG_AGP=y CONFIG_AGP_ALI=y -# CONFIG_AGP_ATI is not set -# CONFIG_AGP_AMD is not set -# CONFIG_AGP_AMD64 is not set +CONFIG_AGP_ATI=y +CONFIG_AGP_AMD=y +CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=y -# CONFIG_AGP_NVIDIA is not set +CONFIG_AGP_NVIDIA=y CONFIG_AGP_SIS=y -# CONFIG_AGP_SWORKS is not set +CONFIG_AGP_SWORKS=y CONFIG_AGP_VIA=y CONFIG_AGP_EFFICEON=y CONFIG_DRM=m @@ -2874,11 +2874,11 @@ CONFIG_INITRAMFS_SOURCE="" CONFIG_KEYS=y CONFIG_KEYS_DEBUG_PROC_KEYS=y -# CONFIG_CDROM_PKTCDVD is not set +CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=8 # CONFIG_CDROM_PKTCDVD_WCACHE is not set
-# CONFIG_ATA_OVER_ETH is not set +CONFIG_ATA_OVER_ETH=m CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_BACKLIGHT_CLASS_DEVICE=m CONFIG_BACKLIGHT_DEVICE=y @@ -3091,7 +3091,7 @@ CONFIG_LEDS_TRIGGER_IDE_DISK=y CONFIG_LEDS_TRIGGER_HEARTBEAT=m
-CONFIG_DMA_ENGINE=y +CONFIG_DMA_ENGINE=m CONFIG_NET_DMA=y CONFIG_INTEL_IOATDMA=m
@@ -3201,10 +3201,10 @@ CONFIG_X86_TSC=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_NONFATAL is not set -# CONFIG_X86_MCE_P4THERMAL is not set -# CONFIG_TOSHIBA is not set -# CONFIG_I8K is not set -# CONFIG_MICROCODE is not set +CONFIG_X86_MCE_P4THERMAL=y +CONFIG_TOSHIBA=m +CONFIG_I8K=m +CONFIG_MICROCODE=m CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_EDD=m @@ -3250,8 +3250,8 @@ CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y -# CONFIG_ACPI_ASUS is not set -# CONFIG_ACPI_TOSHIBA is not set +CONFIG_ACPI_ASUS=m +CONFIG_ACPI_TOSHIBA=m # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y @@ -3286,18 +3286,18 @@ CONFIG_CPU_FREQ_STAT_DETAILS=y CONFIG_X86_ACPI_CPUFREQ=m # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set -CONFIG_X86_POWERNOW_K6=m -# CONFIG_X86_POWERNOW_K7 is not set -# CONFIG_X86_POWERNOW_K8 is not set +# CONFIG_X86_POWERNOW_K6 is not set +CONFIG_X86_POWERNOW_K7=y +CONFIG_X86_POWERNOW_K8=m # CONFIG_X86_GX_SUSPMOD is not set -# CONFIG_X86_SPEEDSTEP_CENTRINO is not set -# CONFIG_X86_SPEEDSTEP_ICH is not set -# CONFIG_X86_SPEEDSTEP_SMI is not set +CONFIG_X86_SPEEDSTEP_CENTRINO=m +CONFIG_X86_SPEEDSTEP_ICH=y +CONFIG_X86_SPEEDSTEP_SMI=y CONFIG_X86_SPEEDSTEP_LIB=y CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y # CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set -# CONFIG_X86_P4_CLOCKMOD is not set +CONFIG_X86_P4_CLOCKMOD=m CONFIG_X86_LONGRUN=y # CONFIG_X86_LONGHAUL is not set # CONFIG_X86_CPUFREQ_NFORCE2 is not set @@ -3321,7 +3321,7 @@ CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_BIOS=y -# CONFIG_HOTPLUG_PCI is not set +CONFIG_HOTPLUG_PCI=y CONFIG_HOTPLUG_PCI_COMPAQ=m # CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM is not set CONFIG_HOTPLUG_PCI_IBM=m @@ -3336,8 +3336,8 @@ CONFIG_IPW2200_QOS=y CONFIG_I2C_ISA=m # CONFIG_X86_REBOOTFIXUPS is not set -# CONFIG_DELL_RBU is not set -# CONFIG_DCDBAS is not set +CONFIG_DELL_RBU=m +CONFIG_DCDBAS=m CONFIG_PC8736x_GPIO=m # CONFIG_NSC_GPIO is not set CONFIG_CS5535_GPIO=m @@ -3377,3 +3377,6 @@ # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set +CONFIG_DCA=m +CONFIG_INTEL_IOATDMA_V3=m +CONFIG_DMA_ENGINE_V3=y diff -u -r rpmbuild.dist/SPECS/kernel-2.6.spec rpmbuild.i586/SPECS/kernel-2.6.spec --- rpmbuild.dist/SPECS/kernel-2.6.spec 2011-05-31 18:46:14.000000000 +0200 +++ rpmbuild.i586/SPECS/kernel-2.6.spec 2011-06-06 19:33:50.000000000 +0200 @@ -70,7 +70,7 @@ # that the kernel isn't the stock distribution kernel, for example, # by setting the define to ".local" or ".bz123456" # -#% define buildid +%define buildid .EL # %define sublevel 18 %define kversion 2.6.%{sublevel} @@ -147,9 +147,9 @@ %endif # Don't build 586 kernels for RHEL builds. %if 0%{?rhel} -%define all_x86 i386 i686 +%define all_x86 i386 i586 i686 # we differ here b/c of the reloc patches -%ifarch i686 x86_64 +%ifarch i586 i686 x86_64 %define with_kdump 0 %endif %else @@ -12536,7 +12536,7 @@ # don't need these for relocatable kernels rm -f kernel-%{kversion}-{i686,x86_64}-kdump.config # don't need these in general -rm -f kernel-%{kversion}-i586.config +#rm -f kernel-%{kversion}-i586.config %endif
%if 0%{?olpc}
Hi all,
A year ago I read instructions on centos.org. About ten original Pentium boxes were converted from CentOS 4.* and are used for small businesses as an el-cheapo router/fileserver/etc
AFAIR you need to rebuild only the kernel for a basic firewall/router (No GUI) machine. I was succesful and there's even a semi-automated kernel get-patch-build-post-makerepo script hanging somewhere. And there is a half-dead repo at my server http://infocs.ru/rpmrepo/
Index of /rpmrepo/i586 ... [ ] kernel-2.6.18-164.15.1.el5.infocs.i586.rpm 13-Apr-2010 01:48 16M [ ] kernel-devel-2.6.18-164.15.1.el5.infocs.i586.rpm 13-Apr-2010 01:48 5.3M ...
The repo is a year old (CentOS 5.4 AFAIR) and not maintained. I was the original maintainer, abandoned due to the lack of time/interest.
By the way, the system can't be installed straight on i586 because of i686 installer and it's memory requirements which (even for text mode) are hard to be fulfilled on original-Pentium boxes. And it also would take a hell lot of time. So for me it looks like: 0)pull HDD from old box 1)put that harddrive to modern box 2)install OS to it 3)boot it (on modern box) 4)copy and install an i586 kernel 5)remove i686 kernel 6)downgrade glibc* and openssl from i686 to i386 version 7)put that HDD to old box and be happy.
It's hard to use yum also because it needs 64+ MB of RAM just to start doing something.
Can't imagine to use i586 boxes as a desktop with GUI. Thin client maybe, but there are better distros for that. The memory is the primary limitation. But a router with PPTP server and a Samba can work pretty well at Pentium-200/32MB/6.4GB.
Best regards, Dmitry Mikhailov
P.S. For happy owners for IBM/Cyrix CPUs. They carry the necessary instructions for an i686 kernel to boot successfully AFAIR. I was surprised. It's a pity they run too hot to be reasonably used.
Hi,
On 06/05/2011 07:38 PM, Dmitry E. Mikhailov wrote:
By the way, the system can't be installed straight on i586 because of i686 installer and it's memory requirements which (even for text mode) are hard to
Cody and I are going to try and solve that problem. The hard part is just identifying where the resources are being used and what is the minimum we want to deliver for. I don't think 128 or even 256M of ram is an unreasonable minimum. Atleast for step-1.
It's hard to use yum also because it needs 64+ MB of RAM just to start doing something.
yum's ram usage dependency is on the repo size to quite an extent, so it might be possible to regulate that by reducing the packages in the install repo down to something sensible for a minimal install. maybe 300 or so, and then let yum work post-instal against the main distro repos ( where it can use the sqlite dbs etc )
Also, given that you have been working on this already in the past - would be great to have you get onboard with this effort!
- KB
On 6/5/11, Dmitry E. Mikhailov d.mikhailov@infocommunications.ru wrote:
A year ago I read instructions on centos.org. About ten original Pentium boxes were converted from CentOS 4.* and are used for small businesses as an el-cheapo router/fileserver/etc
Bravo for not throwing out usable old hardware! (Sorry, just had to go there--I collect old computers like candy. Except I don't eat them. But I digress. Moving on!)
And there is a half-dead repo at my server http://infocs.ru/rpmrepo/
I notice mesa is in there--according to the wiki page, the mesa package contains cmov instructions, so it'll have to be rebuilt too. I'll play around with that later today in mock and see what happens.
0)pull HDD from old box 1)put that harddrive to modern box 2)install OS to it 3)boot it (on modern box) 4)copy and install an i586 kernel 5)remove i686 kernel 6)downgrade glibc* and openssl from i686 to i386 version 7)put that HDD to old box and be happy.
Yep! That's exactly what I've been doing. I set up a lightweight "base" system kickstart that I can use over PXE to quickly install a thin system (while the hard drive is in the i686 system) in about five minutes. Then I install the kernel, downgrade packages, and slap it in the test box. It takes about 20 minutes to set up, maybe 30 if I'm having a bad day. I'll probably need to trim the kickstart down a little more, but it works like a charm.
Building the i586 kernel is probably the most time consuming bit of the whole process, but once you get it to build once you don't need to do it again, baring security updates. Even then, it seems it's a fairly simple process.
It's hard to use yum also because it needs 64+ MB of RAM just to start doing something.
Yep--yum loooooves to eat memory like popcorn at the theatre. I'll keep a closer eye on memory usage next time--hard to tell what's swapping and what's reading the RPM database or doing things with packages.
Can't imagine to use i586 boxes as a desktop with GUI. Thin client maybe, but there are better distros for that. The memory is the primary limitation. But a router with PPTP server and a Samba can work pretty well at Pentium-200/32MB/6.4GB.
Memory is a problem, definitely. My test machine has 76MB of free RAM. (If I were unlazy enough to put in a discrete video card, that would go up to 80MB). It will run X. It will run XFCE with a lot of swapping. Forget Firefox. ;) The laptop might perform better--it has a whopping 192MB (!) of RAM for an AMD K6 400Mhz. IIRC, it's running Debian with XFCE right now, so it's usable.
P.S. For happy owners for IBM/Cyrix CPUs. They carry the necessary instructions for an i686 kernel to boot successfully AFAIR. I was surprised. It's a pity they run too hot to be reasonably used.
Really? That's interesting. I have an IBM 6x86 (PR 150) I can plug into my test box. I'll have to play around with that. I'm also going to see, just for giggles, if I can scrounge up another Super-7 motherboard or two to expand the testing equipment museum. I have a lot more CPUs than motherboards.
On 6/5/11, Karanbir Singh mail-lists@karan.org wrote:
[snip] The hard part is just identifying where the resources are being used and what is the minimum we want to deliver for. I don't think 128 or even 256M of ram is an unreasonable minimum. Atleast for step-1.
I don't know what "modern" i586 systems have (VIA, etc), but I do know that a lot of the old systems have trouble breaching the 64MB barrier. My test box came with 16MB of RAM; by some miracle, I had a few SIMMs in the big tub of parts under the bed (memory from my *486sx* I think) and I bumped it up to 80MB total. As Dmitry mentioned, it's great for a filesever/router. Even a simple static web server if you wanted to go there--but don't use Apache, use something like Lighttpd instead.
Iirc, the memory minimum for the text-mode installer is 64MB. I think that's a sane requirement, although if it could go lower, I see no reason why not to bump it down...if people are crazy enough (like me) to try this on machines with <64MB of RAM, let them find out what happens. It'll be educational for them!
Cheers, Cody Jackson
Bravo for not throwing out usable old hardware!
Looks like some D-Link DIR320 router box outperforms them, but it's just too much trouble to use that die-hard-shinked distros built for them, run through hassle of reflashing etc. Aha, and not being able to seamlessly upgrade them to a decent box if needed.
(Sorry, just had to go there--I collect old computers like candy. Except I don't eat them. But I digress.
Offtopic: dual Socket8 PentiumPro box with 8 SIMM slots populated to get 128MB RAM, running CentOS 5 right here. Had to retire a dual Pentium(Original) just because of the troubles we're talking here about.
On topic: It's usually too much trouble to run an old box. Too much to remember, find an old manual online or play with jumpers. SIMMs of more than 4MB per stick (to get 32MB with 4 slots, you need 8M per stick) are 'rare' (and all SIMMs are rare), the DIMM requirements are hard to satisfy (single bank - otherwise seeing half capacity, sometimes extra rare 5V DIMMs needed). SIMMs ABSOLUTELY DO NEED a memtest before the machine goes to production. Usually a HDD header is really 40pin (not 39pin like modern) - key pin is to be cut out. Or you need an old 40wire IDE cable. The machine has problems even with 40GB HDD's (32GB limit). Old HDD that came with the box also does need a night of MHDD or Victoria.
And finally - you spent two to three hours plus a night of memory and disk testing. And you get what? Reliability is low even with a night of testing. Worn out bearings on CPU cooler require a new cooler which costs (may be) more than the box (especially if the box is free). 32MB SIMM memory leaves nearly nothing for the disk cache - the box is slow. You can't upgrade it easily via yum - it needs 64MB+. Et cetera.
Once we had lots of them, but I won't seek for one If needed. For me a Pentium-II box with ATX PSU in ATX case (thus semi-easily upgradeable), DIMM slots is a minimum now.
What usage scenarios left? 1)Hardware hackers loving old hardware and willing to spend their time to run it; 2)Some countries having no money or access to new hardware; 3)Embedded, industrial and similar specials;
Do we really need it after all? There are doubts.
I notice mesa is in there--according to the wiki page, the mesa package contains cmov instructions, so it'll have to be rebuilt too. I'll play around with that later today in mock and see what happens.
I don't remember why it was rebuilt, but according to: http://mirror.centos.org/centos-5/5.6/os/i386/CentOS/ ... mesa-libGL-6.5.1-7.8.el5.i386.rpm 26-Apr-2010 19:59 9.6M ... It's built with i386 arch tag so it shouldn't need rebuild.
Yep! That's exactly what I've been doing. I set up a lightweight "base" system kickstart that I can use over PXE to quickly install a thin system (while the hard drive is in the i686 system) in about five minutes.
Even less if a script does a: 1)fdisk on a target drive 2)mkfs.ext3 3)mount 4)cp -aR /installed/and/ready/filesystem/converted/to/i586/already /on/a/formatted/hdd/mount 5)grub-install
Then I install the kernel, downgrade packages, and slap it in the test box. It takes about 20 minutes to set up, maybe 30 if I'm having a bad day.
If hardware is alive and in a box already ;-)
I'll probably need to trim the kickstart down a little more, but it works like a charm.
I was doing 'rpm -e' until I got something like 730MB. Was hard to go further. Minimal install gives you various crap like irda-tools for example. Kudzu depends on a haldaemon. The haldaemon depends on dbus. The latter two bring about 50MB of unneeded libs with them AFAIR. But I like kudzu. There's a lvm2-monitor from lvm2 package. I don't need one, but mkinitrd depends on it and we need mkinitrd to update kernels. You could rip sendmail, but you'd lose LSB compliance. And remember, it's a wrong way.
This way we'd end up building our own, another Linux distro for firewalls. But we're here because of upstream compliance and upgradeability to a more decent box if need arises WITHOUT ANY MIGRATION/REINSTALL.
Building the i586 kernel is probably the most time consuming bit of the whole process, but once you get it to build once you don't need to do it again, baring security updates. Even then, it seems it's a fairly simple process.
Buildscript exists somewhere, but I couldn't find it yesterday. Write a patch for a rpm SPEC file to do necessary things to kernel tree like copying i686 .config to .i586, changing target CPU to -M586 etc.
1)wget a_new_kernel_src.rpm 2)rpm -i 3)patch -pX /on/a/rpm/SPEC/file </to/include/our/patch 4)rpmbuild wait until a gazillion of individual patches are applied (offtopic - this time I won't be against RHEL6 prepared-and-intergrated kernel source tree) 5)copy a built RPMs where needed 6)rebuild repo metadata
On a lightly loaded server (4-core Q6600, SCSI disk subsystem) it doesn't take enormous time.
Memory is a problem, definitely. My test machine has 76MB of free RAM.
Not really. Try to get s 'Super7' motherboard with VIA chipset. AT and ATX supply, can run AMD K6-2 and (some of them) K6-3, can take more or less standard DIMMs (2 slots!), UDMA33, AGP, USB1.1 header.
(If I were unlazy enough to put in a discrete video card, that would go up to 80MB).
Integrated video is a bad idea IMHO. That time a memory bandwidth was very limited. And an intergated video card uses it a lot.
It will run X.
Jornada 720 will run X :-) Funny project by the way. It's a pity I don't like cross-compiling.
Forget Firefox. ;)
It takes 650MB on my current desktop. Why so much? But (to compare) I've seen (on a windoze machine) a Google Chrome with 11 tabs open taking 1100MB. Nobody seems to care. They install 4GB just because it's cool. Then run 32bit OS while asking stupid questions like 'why it doesn't see my full 4gig of ram' but NOT asking 'why I need 4gig of ram' in the first time.
The laptop might perform better--it has a whopping 192MB (!) of RAM for an AMD K6 400Mhz. IIRC, it's running Debian with XFCE right now, so it's usable.
No Firefox anyway.
P.S. For happy owners for IBM/Cyrix CPUs. They carry the necessary instructions for an i686 kernel to boot successfully AFAIR. I was surprised. It's a pity they run too hot to be reasonably used.
Really? That's interesting. I have an IBM 6x86 (PR 150) I can plug into my test box. I'll have to play around with that.
I had a box with one. I've downgraded the kernel and OpenSSL, set it up and it was running for half a year. Then the fan failed and the CPU overheated - the system hanged. I decided to replace the one with Pentium-166 - the could run hot but *passive*. The box would boot kernel and hang somewhere after 'mounting root'. I almost broke my head seeking for a problem and found UNdowngraded glibc*.i686. Later I set up a test box for that CPU. It booted a stock i686 kernel.
I have a lot more CPUs than motherboards.
I gave them away to children. Couldn't find a better use for a bugged P-75's
On 6/5/11, Karanbir Singh mail-lists@karan.org wrote:
[snip] The hard part is just identifying where the resources are being used and what is the minimum we want to deliver for. I don't think 128 or even 256M of ram is an unreasonable minimum. Atleast for step-1.
It would take ages to install anyway. So no one would use it anyway. Then why fixing?
I don't know what "modern" i586 systems have (VIA, etc), but I do know that a lot of the old systems have trouble breaching the 64MB barrier.
32MB SIMMs are very rare. And with (rare) 16MB SIMMs you can get 64MB. Right.
My test box came with 16MB of RAM; by some miracle, I had a few SIMMs in the big tub of parts under the bed (memory from my *486sx* I think) and I bumped it up to 80MB total.
2 sticks of 32MB each from 486sx? Can't believe it! 4MB it much more plausible.
As Dmitry mentioned, it's great for a filesever/router. Even a simple static web server if you wanted to go there--but don't use Apache, use something like Lighttpd instead.
Typical setup is: 1)Firewall,NAT 2)Squid with very small RAM cache for www filtering 3)dnsmasq for DHCP server and DNS relay (could do TFTP too!) 4)Samba for WINS server and to solve 'master browser' issues. 5)ejabberd jabber server for an internal chat and remote support 6)openvpn for remote support 7)quagga also for remote support 32MB, 2 NICs, about 16MB swapped. Everyone's happy.
Iirc, the memory minimum for the text-mode installer is 64MB.
On a CentOS 5? AFAIR it's 128MB. Anyway I won't install directly on an old box.
Best regards, Dmitry Mikhailov
Tomorrow if there's time in town I'll see about fetching the rhel6 kernel and playing with it. It'd be nice to know ahead of time if it compiles cleanly for i586. I'll also play with build scripts in the upcoming week.
On 6/5/11, Dmitry E. Mikhailov d.mikhailov@infocommunications.ru wrote:
Do we really need it after all? There are doubts.
From what I gather from the wiki page, it's not just for ancient
things like the i586, but older VIA CPUs. I wouldn't know for sure because I don't have any of these :( In addition, it's kick-starting alt-arch support for things like ALPHA, SPARC, I64, etc. (Maybe.)
mesa-libGL-6.5.1-7.8.el5.i386.rpm 26-Apr-2010 19:59 9.6M ... It's built with i386 arch tag so it shouldn't need rebuild.
The C5 on the Pentium project page notes that Mesa was built with -ffast-math, which apparently (?) doesn't play nice with i586. If this is incorrect, that's great, because it means less headache for the package builders.
http://wiki.centos.org/Projects/CentOS5PentiumSupport
Even less if a script does a: 1)fdisk on a target drive 2)mkfs.ext3 3)mount 4)cp -aR /installed/and/ready/filesystem/converted/to/i586/already /on/a/formatted/hdd/mount 5)grub-install
This looks like it might save some time; I'll give it a whirl when I get my USB hard drive adapter tomorrow.
If hardware is alive and in a box already ;-)
I think that if it's not alive then people aren't going to go looking for it. Then again, being a computer necromancer has its moments.
I was doing 'rpm -e' until I got something like 730MB. Was hard to go further. Minimal install gives you various crap like irda-tools for example. Kudzu depends on a haldaemon. The haldaemon depends on dbus. The latter two bring about 50MB of unneeded libs with them AFAIR. But I like kudzu. There's a lvm2-monitor from lvm2 package. I don't need one, but mkinitrd depends on it and we need mkinitrd to update kernels. You could rip sendmail, but you'd lose LSB compliance. And remember, it's a wrong way.
This way we'd end up building our own, another Linux distro for firewalls. But we're here because of upstream compliance and upgradeability to a more decent box if need arises WITHOUT ANY MIGRATION/REINSTALL.
I dunno; when I get this thing to boot natively into an installer I'll let you know how much it takes to do a minimal install. I think the way I have it now it's about 500MB (?) of packages, which is still excessive to me but works. (Of course, keeping in mind this machine came with a 480MB hard drive before I swapped it for a 30GB drive...)
1)wget a_new_kernel_src.rpm 2)rpm -i 3)patch -pX /on/a/rpm/SPEC/file </to/include/our/patch 4)rpmbuild wait until a gazillion of individual patches are applied (offtopic - this time I won't be against RHEL6 prepared-and-intergrated kernel source tree) 5)copy a built RPMs where needed 6)rebuild repo metadata
Exactly! That's what I hope to have set up soon. As it is, I already have the .patch for the spec, so wrapping it in a script shouldn't be too bad. The only thing I add is running it through Mock--I like things being separated into little compartments. The end result is the same.
On a lightly loaded server (4-core Q6600, SCSI disk subsystem) it doesn't take enormous time.
Remember, I'm the guy with the i586s. No quad-cores for me. :P But you're right, it doesn't take too long, and updates--and hence rebuilds--are few and far between.
It takes 650MB on my current desktop. Why so much? But (to compare) I've seen (on a windoze machine) a Google Chrome with 11 tabs open taking 1100MB. Nobody seems to care. They install 4GB just because it's cool. Then run 32bit OS while asking stupid questions like 'why it doesn't see my full 4gig of ram' but NOT asking 'why I need 4gig of ram' in the first time.
Minor offtopic: this is something that disappoints me. It used to be that folks went to college to learn how to write programs leaner and meaner and make them fit into less RAM, because we had less RAM then. Now with RAM so cheap, we have a ridiculous amount of it in desktops--my new LAPTOP has more memory than any desktop I've owned to date, and it's fairly low-end--so here come the programs *COUGH*WINDOWS*COUGH* that eats up ridiculous amounts of memory just because we have it. Ahh, progress.
It would take ages to install anyway. So no one would use it anyway. Then why fixing?
I'm the person that believes an operating system should allow a person to shoot themselves in the foot if they try something dumb (like installing on 64MB of RAM). If someone thinks they're smarter than the OS--which, usually, they're not--let them try it. If they're the learning type, they'll learn not to do it again, unless they're like me, in which case they're utterly hopeless and will continue to do dumb things just for the heck of it.
2 sticks of 32MB each from 486sx? Can't believe it! 4MB it much more plausible.
Might've been the P133 then--it's been a few years...it was either the 486sx, the 386, or the P133. Those were the only SIMM boxes I remember.
Cheers, Cody Jackson
On Monday 06 June 2011 11:13, Cody Jackson wrote:
Tomorrow if there's time in town I'll see about fetching the rhel6 kernel and playing with it. It'd be nice to know ahead of time if it compiles cleanly for i586.
RHEL6 makes less sence than RHEL5 due to memory requirements again, doesn't it?
I'll also play with build scripts in the upcoming week.
I'm really sorry I can't find a buildscript. It should be somewhere on a machine.
In addition, it's kick-starting alt-arch support for things like ALPHA, SPARC, I64, etc. (Maybe.)
A lot harder to test, hardware is rare/expensive, what kernel options to use... Lots of questions.
Even less if a script does a: 1)fdisk on a target drive 2)mkfs.ext3 3)mount 4)cp -aR /installed/and/ready/filesystem/converted/to/i586/already /on/a/formatted/hdd/mount 5)grub-install
This looks like it might save some time; I'll give it a whirl when I get my USB hard drive adapter tomorrow.
Had problems with grub-install. You'd better chroot before grub-install, don't forget to bind-mount /dev, /proc and /sys. And if the target machine uses a disk controller not compiled in kernel or other than new machine you're doing it at, you'd need to rebuild initrd. No problems with VIA, Intel. But certainly problems with old SCSI cards are guaranteed.
I was doing 'rpm -e' until I got something like 730MB. Was hard to go further. Minimal install gives you various crap like irda-tools for example. Kudzu depends on a haldaemon. The haldaemon depends on dbus. The latter two bring about 50MB of unneeded libs with them AFAIR. But I like kudzu. There's a lvm2-monitor from lvm2 package. I don't need one, but mkinitrd depends on it and we need mkinitrd to update kernels. You could rip sendmail, but you'd lose LSB compliance. And remember, it's a wrong way.
This way we'd end up building our own, another Linux distro for firewalls. But we're here because of upstream compliance and upgradeability to a more decent box if need arises WITHOUT ANY MIGRATION/REINSTALL.
I dunno; when I get this thing to boot natively into an installer I'll let you know how much it takes to do a minimal install. I think the way I have it now it's about 500MB (?) of packages, which is still excessive to me but works. (Of course, keeping in mind this machine came with a 480MB hard drive before I swapped it for a 30GB drive...)
You could use rpm to force-remove certain components like the aforementioned lvm2 but you're calling for problems with yum later. And if you use yum, it'll bring dependencies back. I wasn't able to cleanly push the root dir below 700M. Add 300MB free space just in case, 100MB for /boot and 100MB (at least) for swap and you get a 1200MB HDD needed @ absolute minimum. I preferred 1700MB.
BTW, removing rpm/yum metadata saves about 100mb, removing YUM itself with dependencies saves about 50+MB, but it's just like back to the stone age. I won't recomment anyone dealing with RPM hell by hand.
1)wget a_new_kernel_src.rpm 2)rpm -i 3)patch -pX /on/a/rpm/SPEC/file </to/include/our/patch 4)rpmbuild wait until a gazillion of individual patches are applied (offtopic - this time I won't be against RHEL6 prepared-and-intergrated kernel source tree) 5)copy a built RPMs where needed 6)rebuild repo metadata
Exactly! That's what I hope to have set up soon. As it is, I already have the .patch for the spec, so wrapping it in a script shouldn't be too bad. The only thing I add is running it through Mock--I like things being separated into little compartments. The end result is the same.
Is it silly to ask 'what the Mock is?' Don't lmgtfy.com me, Ok?
On a lightly loaded server (4-core Q6600, SCSI disk subsystem) it doesn't take enormous time.
Remember, I'm the guy with the i586s. No quad-cores for me. :P But you're right, it doesn't take too long, and updates--and hence rebuilds--are few and far between.
I'm willing to provide a diskspace, bandwith and CPU time on my server for the project and it's repo if needed. I hope the traffic wouldn't be enormous because I'm paying $0.1 per gigabyte of traffic. The full bandwidth is 100mbit but I'm cautious to provide more that 10mbit to single instance/VPS.
my new LAPTOP has more memory than any desktop I've owned to date, and it's fairly low-end--so here come the programs *COUGH*WINDOWS*COUGH* that eats up ridiculous amounts of memory just because we have it. Ahh, progress.
I don't like KDE4 either ;-) I was quite happy with Fedora on my 1.5GHz single-core Centrino laptop before KDE4 arrived. Then I switched to CentOS.
It would take ages to install anyway. So no one would use it anyway. Then why fixing?
I'm the person that believes an operating system should allow a person to shoot themselves in the foot if they try something dumb (like installing on 64MB of RAM). If someone thinks they're smarter than the OS--which, usually, they're not--let them try it. If they're the learning type, they'll learn not to do it again, unless they're like me, in which case they're utterly hopeless and will continue to do dumb things just for the heck of it.
Does it really worth the precious minutes of developer's time?
On Mon, 2011-06-06 at 16:42 +0600, Dmitry E. Mikhailov wrote:
In addition, it's kick-starting alt-arch support for things like ALPHA, SPARC, I64, etc. (Maybe.)
A lot harder to test, hardware is rare/expensive, what kernel options to use... Lots of questions.
I have some double-headed UltraSPARC III blades with 1 or 2 Gigs of RAM doing nothing in the basement that I could in theory contribute to a good cause.
The only thing I'm not sure of is how I could get them hooked up to the network. We are very strictly firewalled and I'll very certainly get into trouble for providing a reverse ssh or a login server.
I used to play with OpenSolaris on those, but now basically their are just heating the air because of the catastrophic lack of time...
In what concerns the unobtainium, I'm not sure how it makes sense at all since it's discontinued anyways.
Is it silly to ask 'what the Mock is?' Don't lmgtfy.com me, Ok?
Not it's not. Mock is basically just a frontend to rpmbuild ala pbuilder, which takes care of setting up clean chroots and resolving dependencies for predictable and reproducible package rebuilds.
Am 05.06.2011 um 20:38 schrieb Dmitry E. Mikhailov:
It's hard to use yum also because it needs 64+ MB of RAM just to start doing something.
Just to confirm: I'm using following setup
http://article.gmane.org/gmane.linux.centos.devel/8190
with 256MB RAM and a "yum update" consumed all memory and finally the process was killed. It was possible to do it selectively but at least for "yum update glibc" the execution led to an unresponsive yum.
So far Leon
-
Akemi Yagi -
Cody Jackson -
Dmitry E. Mikhailov -
Jeff Johnson -
Karanbir Singh -
Lamar Owen -
Leon Fauster -
Les Mikesell -
Morten Torstensen -
Nick Bright -
R P Herrold -
Timothy Lee -
Yury V. Zaytsev