FAQ
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

Search Discussions

  • Timothy Lee at Jun 3, 2011 at 5:26 am

    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
  • Leon Fauster at Jun 3, 2011 at 5:44 am

    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
  • Karanbir Singh at Jun 3, 2011 at 7:08 am

    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.
    http://wiki.centos.org/Projects/CentOS5PentiumSupport
    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
  • Lamar Owen at Jun 3, 2011 at 9:11 am

    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....
  • Karanbir Singh at Jun 3, 2011 at 9:31 am
    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
  • Lamar Owen at Jun 3, 2011 at 10:39 am

    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.
  • Karanbir Singh at Jun 3, 2011 at 11:02 am

    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
  • Lamar Owen at Jun 3, 2011 at 11:13 am

    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.
  • Yury V. Zaytsev at Jun 3, 2011 at 11:39 am
    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.

    --
    Sincerely yours,
    Yury V. Zaytsev
  • Jeff Johnson at Jun 3, 2011 at 11:44 am

    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
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: smime.p7s
    Type: application/pkcs7-signature
    Size: 4645 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos-devel/attachments/20110603/aa27f3ad/attachment.bin
  • Karanbir Singh at Jun 3, 2011 at 12:14 pm

    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
  • Cody Jackson at Jun 3, 2011 at 4:57 pm
    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
  • Lamar Owen at Jun 3, 2011 at 5:04 pm

    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.
  • Akemi Yagi at Jun 3, 2011 at 5:23 pm

    On Fri, Jun 3, 2011 at 2:04 PM, Lamar Owen 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
  • Yury V. Zaytsev at Jun 3, 2011 at 6:16 pm

    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.

    --
    Sincerely yours,
    Yury V. Zaytsev
  • R P Herrold at Jun 3, 2011 at 6:25 pm

    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
  • Yury V. Zaytsev at Jun 3, 2011 at 7:04 pm

    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.

    --
    Sincerely yours,
    Yury V. Zaytsev
  • Karanbir Singh at Jun 3, 2011 at 12:08 pm

    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
  • Morten Torstensen at Jun 5, 2011 at 8:48 am

    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?

    --

    //Morten Torstensen
    //Email: morten at mortent.org
    //IM: morten.torstensen at gmail.com

    I can't listen to that much Wagner. I start getting the urge to conquer
    Poland.
    -- Woody Allen
  • Karanbir Singh at Jun 5, 2011 at 3:38 pm

    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
  • Nick Bright at Jun 3, 2011 at 12:11 pm
    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 at centos.org
    http://lists.centos.org/mailman/listinfo/centos-devel
  • Les Mikesell at Jun 3, 2011 at 10:47 am

    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.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Karanbir Singh at Jun 3, 2011 at 11:03 am

    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
  • Les Mikesell at Jun 3, 2011 at 11:31 am

    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....


    --
    Les Mikesell
    lesmikesell at gmail.com
  • Leon Fauster at Jun 7, 2011 at 7:27 am

    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 at 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 at localhost ~]# head -4 /proc/meminfo
    MemTotal: 255140 kB
    MemFree: 174188 kB
    Buffers: 5224 kB
    Cached: 64996 kB


    Cheers
    Leon
  • Cody Jackson at Jun 7, 2011 at 5:15 pm
    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
  • Yury V. Zaytsev at Jun 7, 2011 at 5:23 pm

    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.

    --
    Sincerely yours,
    Yury V. Zaytsev
  • Cody Jackson at Jun 7, 2011 at 6:32 pm

    On 6/7/11, Yury V. Zaytsev 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 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?idE86

    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
  • Akemi Yagi at Jun 7, 2011 at 5:23 pm

    On Tue, Jun 7, 2011 at 2:15 PM, Cody Jackson 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?idE86

    The first 3 notes will help you with customization.

    Good luck,

    Akemi
  • Les Mikesell at Jun 7, 2011 at 5:57 pm

    On 6/7/2011 4:23 PM, Akemi Yagi wrote:
    On Tue, Jun 7, 2011 at 2:15 PM, Cody Jacksonwrote:
    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.

    --
    Les Mikesell
    lesmikesell at gmail.com
  • Leon Fauster at Jun 8, 2011 at 2:26 pm
    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. ...
    http://wiki.centos.org/Projects/CentOS5PentiumSupport

    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}
  • Dmitry E. Mikhailov at Jun 5, 2011 at 2:38 pm
    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.
  • Karanbir Singh at Jun 5, 2011 at 3:43 pm
    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
  • Cody Jackson at Jun 5, 2011 at 4:37 pm

    On 6/5/11, Dmitry E. Mikhailov 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 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
  • Dmitry E. Mikhailov at Jun 6, 2011 at 12:21 am
    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 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
  • Cody Jackson at Jun 6, 2011 at 1:13 am
    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 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
  • Dmitry E. Mikhailov at Jun 6, 2011 at 6:42 am

    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?
  • Yury V. Zaytsev at Jun 6, 2011 at 7:28 am

    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.

    --
    Sincerely yours,
    Yury V. Zaytsev
  • Leon Fauster at Jun 8, 2011 at 3:42 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos-devel @
categoriescentos
postedJun 3, '11 at 12:10a
activeJun 8, '11 at 3:42p
posts40
users13
websitecentos.org
irc#centos

People

Translate

site design / logo © 2021 Grokbase