Hi, I'm looking for info about installing centos 4.4 on an embedded platform, like wrap's pcengines or similar. Anyone has done that? Any links?
Thanks Oliver
On Tue, December 5, 2006 2:57 pm, Oliver Schulze L. wrote:
I'm looking for info about installing centos 4.4 on an embedded platform, like wrap's pcengines or similar.
You will definitely need a modified kernel, because the WRAP seems to have a 486 CPU. Besides that it depends a lot on the size of the CompactFlash cards that you are planning to use. It is possible to make a fairly minimal CentOS installation by picking packages by hand, though IIRC a minimal system is around 100MB compressed.
With lower-end hardware it is usually easier to go with a custom Busybox setup. Busybox is small, and quite easy to set up.
-- Daniel
On Tuesday 05 December 2006 07:10, Daniel de Kok wrote:
On Tue, December 5, 2006 2:57 pm, Oliver Schulze L. wrote:
I'm looking for info about installing centos 4.4 on an embedded platform, like wrap's pcengines or similar.
You will definitely need a modified kernel, because the WRAP seems to have a 486 CPU. Besides that it depends a lot on the size of the CompactFlash cards that you are planning to use. It is possible to make a fairly minimal CentOS installation by picking packages by hand, though IIRC a minimal system is around 100MB compressed.
The higher end (48xx) Soekris box is a 586, and CentOS installs fine (PXE booting is the easy route). I can't comment on the WRAP boxes, I haven't actually worked with one.
I think to actually get CentOS down that small there's a few RPMs you have to force remove. It makes upgrading anything a pain because you have to manually add and force packages for install as well.
With lower-end hardware it is usually easier to go with a custom Busybox setup. Busybox is small, and quite easy to set up.
I would second this. CentOS' dependencies are pretty complex and intermingled when you get to a small set of installed RPMs.
Kevan Benson wrote:
On Tuesday 05 December 2006 07:10, Daniel de Kok wrote:
The higher end (48xx) Soekris box is a 586, and CentOS installs fine (PXE booting is the easy route). I can't comment on the WRAP boxes, I haven't actually worked with one.
Thats correct, I'm planing buying an AMD Geode that is i586
I think to actually get CentOS down that small there's a few RPMs you have to force remove. It makes upgrading anything a pain because you have to manually add and force packages for install as well.
Will take this in mind, I was thinking upgrading with yum.
With lower-end hardware it is usually easier to go with a custom Busybox setup. Busybox is small, and quite easy to set up.
I would second this. CentOS' dependencies are pretty complex and intermingled when you get to a small set of installed RPMs.
I think I should get a 512MB flash memory, they are cheap these days and will help having more .rpm installed. I'm planning using it as a router, so I need: - yum - iptables - ssh - apache + php - maybe mysql
Thanks Daniel and Kevan for the info Oliver
Oliver Schulze L. spake the following on 12/5/2006 2:11 PM:
Kevan Benson wrote:
On Tuesday 05 December 2006 07:10, Daniel de Kok wrote: The higher end (48xx) Soekris box is a 586, and CentOS installs fine (PXE booting is the easy route). I can't comment on the WRAP boxes, I haven't actually worked with one.
Thats correct, I'm planing buying an AMD Geode that is i586
I think to actually get CentOS down that small there's a few RPMs you have to force remove. It makes upgrading anything a pain because you have to manually add and force packages for install as well.
Will take this in mind, I was thinking upgrading with yum.
With lower-end hardware it is usually easier to go with a custom Busybox setup. Busybox is small, and quite easy to set up.
I would second this. CentOS' dependencies are pretty complex and intermingled when you get to a small set of installed RPMs.
I think I should get a 512MB flash memory, they are cheap these days and will help having more .rpm installed. I'm planning using it as a router, so I need:
- yum
- iptables
- ssh
- apache + php
- maybe mysql
Thanks Daniel and Kevan for the info Oliver
I know this is a CentOS list, but did you look at monowall? It is great on those small boards, and runs in less memory.
Please don't flame me. I just like to have more options when I do a project. I assume that others will too!
monowall and pfsenses are just great software. But I'm looking for migrating an already customized firewall+scripts to an embedded platform.
Also, all of our server runs centos, so having a new centos server will be more easy to maintain for our team.
Tks Oliver
John R Pierce wrote:
Scott Silva wrote:
I know this is a CentOS list, but did you look at monowall? It is great on those small boards, and runs in less memory.
also, pfSense ...
On Wed, 06 Dec 2006 08:37:50 -0300 "Oliver Schulze L." oliver@samera.com.py wrote:
Also, all of our server runs centos, so having a new centos server will be more easy to maintain for our team.
Then CentOS would be great with enough flash storage and a 586 CPU.
Maybe VIA nano-ITX or mini-ITX boards are also an interesting "platform"? Besides that these boards have more power than Geode boards, their Padlock stuff is interesting if you are going to use it for anything that involves crypto. E.g. the latest generation of Padlock has dedicated logic for AES encryption, hashing, and Montgomery multiplication. Though, I don't know if anyone has backported the kernel modules, and the OpenSSL patches, to support Padlock to the CentOS kernel.
-- Daniel
Daniel de Kok napsal(a):
Maybe VIA nano-ITX or mini-ITX boards are also an interesting "platform"? Besides that these boards have more power than Geode boards, their Padlock stuff is interesting if you are going to use it for anything that involves crypto. E.g. the latest generation of Padlock has dedicated logic for AES encryption, hashing, and Montgomery multiplication. Though, I don't know if anyone has backported the kernel modules, and the OpenSSL patches, to support Padlock to the CentOS kernel.
Daniel, Padlock support is not backported into Centos, nor upstream. Since 2.6.11 kernel it has been accepted into the source tree (only AES), so we can expect it in RHEL/Centos5?!? For SHA1 and SHA256 every kernel must be patched. Interesting reading http://www.logix.cz/michal/doc/article.xp/padlock-en David
On Wed, 06 Dec 2006 14:15:49 +0100 David Hrbác( hrbac.conf@seznam.cz wrote:
Padlock support is not backported into Centos, nor upstream.
Thanks for the heads-up!
2.6.11 kernel it has been accepted into the source tree (only AES), so we can expect it in RHEL/Centos5?!? For SHA1 and SHA256 every kernel must be patched.
$ rpm2cpio kernel-2.6.18-1.2747.el5.i686.rpm | cpio -t | grep 'padlock' ./lib/modules/2.6.18-1.2747.el5/kernel/drivers/crypto/padlock.ko
Looking at the symbols this seems to implement AES offloading.
Interesting reading http://www.logix.cz/michal/doc/article.xp/padlock-en
Very interesting indeed.
-- Daniel
On Wednesday 06 December 2006 16:01, Daniel de Kok wrote:
$ rpm2cpio kernel-2.6.18-1.2747.el5.i686.rpm | cpio -t | grep 'padlock' ./lib/modules/2.6.18-1.2747.el5/kernel/drivers/crypto/padlock.ko
or more efficiently: $ rpm -qlp kernel-2.6.18-1.2747.el5.i686.rpm | grep 'padlock'
/Peter
Oliver Schulze L. spake the following on 12/6/2006 3:37 AM:
monowall and pfsenses are just great software. But I'm looking for migrating an already customized firewall+scripts to an embedded platform.
Also, all of our server runs centos, so having a new centos server will be more easy to maintain for our team.
Tks Oliver
John R Pierce wrote:
Scott Silva wrote:
I know this is a CentOS list, but did you look at monowall? It is great on those small boards, and runs in less memory.
also, pfSense ...
It might just be easier to get a small 1u rackmount and put it on that. The hardest part will be getting the system to not hammer the CF to death with writes. Most of the embedded systems hold writes to a minimum, and do them in batches so the CF lasts longer.
Scott Silva wrote:
It might just be easier to get a small 1u rackmount and put it on that. The hardest part will be getting the system to not hammer the CF to death with writes. Most of the embedded systems hold writes to a minimum, and do them in batches so the CF lasts longer.
Thats a good point, I should look into the constant write problem. I was thinking in an embedded platform for its costs, low space, low power consumption and disk less operation.
Oliver
Oliver Schulze L. wrote:
Scott Silva wrote:
It might just be easier to get a small 1u rackmount and put it on that. The hardest part will be getting the system to not hammer the CF to death with writes. Most of the embedded systems hold writes to a minimum, and do them in batches so the CF lasts longer.
Thats a good point, I should look into the constant write problem. I was thinking in an embedded platform for its costs, low space, low power consumption and disk less operation.
I suspect that most folks would probably wind up using the system as a paperweight long before the CF has degraded unless you were doing extremely write intensive tasks with it. The newer flash parts claim to have an "endurance" of millions of writes and and MTBF of millions of hours. Granted, I wouldn't use them to store index files for my usenet feed, but that's a LOT of writes. :) And given how the prices of CF are dropping like a stone, you could always pre-emptively rotate new parts in and use old ones in your digital camera/etc.
Cheers,
On Wednesday 06 December 2006 11:01, chrism@imntv.com wrote:
I suspect that most folks would probably wind up using the system as a paperweight long before the CF has degraded unless you were doing extremely write intensive tasks with it. The newer flash parts claim to have an "endurance" of millions of writes and and MTBF of millions of hours. Granted, I wouldn't use them to store index files for my usenet feed, but that's a LOT of writes. :) And given how the prices of CF are dropping like a stone, you could always pre-emptively rotate new parts in and use old ones in your digital camera/etc.
One write a minute to the same sector gives you a failure time of under two years (ignoring write-remapping) on a flash device verified for 1,000,000 erase-write cycles. Given this, it's at least prudent to make sure that it logs to a remote host only, or sparsely. Making /tmp (and possibly /var/tmp) ramdisks is also useful.
It might not be common to get that many writes to the same sector consistently, but considering a few easy steps can greatly extend te life of the device, it might be worth it.
Oliver Schulze L. napsal(a):
Thats a good point, I should look into the constant write problem. I was thinking in an embedded platform for its costs, low space, low power consumption and disk less operation.
No, that's pretty good point. :o) Majority of systems running from CF|XD|etc. are mounting read only the media, keeping logs and other thins in RAM-disk and sending them to central authority. There's write attempt limit within CF. David
David Hrbác wrote:
Oliver Schulze L. napsal(a):
Thats a good point, I should look into the constant write problem. I was thinking in an embedded platform for its costs, low space, low power consumption and disk less operation.
No, that's pretty good point. :o) Majority of systems running from CF|XD|etc. are mounting read only the media, keeping logs and other thins in RAM-disk and sending them to central authority. There's write attempt limit within CF.
there's special file systems optimized for flash use, squashfs is readonly (its compressed at system build time) and jffs2 (aka jiffy) is a writeable FS designed to minimize block writes to the flash. Embedded Linux like used by OpenWRT on the WRT54GS and compatible routers uses both of these.
http://squashfs.sourceforge.net/ http://sourceware.org/jffs2/
the discussion of these two on the OpenWRT WIKI... http://wiki.openwrt.org/OpenWrtDocs/Installing#head-3d6480403b294d4c261f360a...
On Wed, 2006-12-06 at 17:07 -0800, John R Pierce wrote:
David Hrbác wrote:
Oliver Schulze L. napsal(a):
Thats a good point, I should look into the constant write problem. I was thinking in an embedded platform for its costs, low space, low power consumption and disk less operation.
No, that's pretty good point. :o) Majority of systems running from CF|XD|etc. are mounting read only the media, keeping logs and other thins in RAM-disk and sending them to central authority. There's write attempt limit within CF.
there's special file systems optimized for flash use, squashfs is readonly (its compressed at system build time) and jffs2 (aka jiffy) is a writeable FS designed to minimize block writes to the flash. Embedded Linux like used by OpenWRT on the WRT54GS and compatible routers uses both of these.
http://squashfs.sourceforge.net/ http://sourceware.org/jffs2/
the discussion of these two on the OpenWRT WIKI... http://wiki.openwrt.org/OpenWrtDocs/Installing#head-3d6480403b294d4c261f360a...
The CentOS Live CD uses squashfs and unionfs, writes to ramdisk, and writes to one location.
It (or something based on it) might be good for an embedded solution.
This site has newer versions of the technique used:
http://linux.web.psi.ch/livecd/build.html
The CentOS kernel used (with built in squashfs support) is here:
http://mirror.centos.org/centos/4/build/livecd/RPMS/
Thanks, Johnny Hughes
On Fri, 2006-12-08 at 03:37 -0600, Johnny Hughes wrote:
On Wed, 2006-12-06 at 17:07 -0800, John R Pierce wrote:
David Hrbác wrote:
Oliver Schulze L. napsal(a):
Thats a good point, I should look into the constant write problem. I was thinking in an embedded platform for its costs, low space, low power consumption and disk less operation.
No, that's pretty good point. :o) Majority of systems running from CF|XD|etc. are mounting read only the media, keeping logs and other thins in RAM-disk and sending them to central authority. There's write attempt limit within CF.
there's special file systems optimized for flash use, squashfs is readonly (its compressed at system build time) and jffs2 (aka jiffy) is a writeable FS designed to minimize block writes to the flash. Embedded Linux like used by OpenWRT on the WRT54GS and compatible routers uses both of these.
http://squashfs.sourceforge.net/ http://sourceware.org/jffs2/
the discussion of these two on the OpenWRT WIKI... http://wiki.openwrt.org/OpenWrtDocs/Installing#head-3d6480403b294d4c261f360a...
The CentOS Live CD uses squashfs and unionfs, writes to ramdisk, and writes to one location.
It (or something based on it) might be good for an embedded solution.
This site has newer versions of the technique used:
http://linux.web.psi.ch/livecd/build.html
The CentOS kernel used (with built in squashfs support) is here:
Even better than the CentOS kernel is the SRPMS to build all the required kernel modules here:
ftp://ftp.psi.ch/psi/livecd/SRPMS
Thanks, Johnny Hughes
Excellent links! I hope to get a wrap box from pcengines this January, maybe we can do a centos wrap edition? ;)
Thanks Oliver
John R Pierce wrote:
David Hrbác wrote:
Oliver Schulze L. napsal(a):
Thats a good point, I should look into the constant write problem. I was thinking in an embedded platform for its costs, low space, low power consumption and disk less operation.
No, that's pretty good point. :o) Majority of systems running from CF|XD|etc. are mounting read only the media, keeping logs and other thins in RAM-disk and sending them to central authority. There's write attempt limit within CF.
there's special file systems optimized for flash use, squashfs is readonly (its compressed at system build time) and jffs2 (aka jiffy) is a writeable FS designed to minimize block writes to the flash. Embedded Linux like used by OpenWRT on the WRT54GS and compatible routers uses both of these.
http://squashfs.sourceforge.net/ http://sourceware.org/jffs2/
the discussion of these two on the OpenWRT WIKI... http://wiki.openwrt.org/OpenWrtDocs/Installing#head-3d6480403b294d4c261f360a...
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
chrism＠imntv.com -
Daniel de Kok -
David Hrbác( -
John R Pierce -
Johnny Hughes -
Kevan Benson -
Oliver Schulze L. -
Peter Kjellstrom -
Scott Silva