Install gentoo on a CF card

[schorsch_76]

Hi,

currently i'm installing gentoo on my amd geode lx mini itx board which has a CF card as hard disk. The build are supported by distcc from my workstation.

The CF card has the disadvantage of limited write cycles [1] . What directories should i mount to a tmpfs or on an external drive, too prevent destruction of the CF card by write cycles?

Following points came to my mind:
- /var/log external
- /var/tmp/portage external
- Use noatime/nodiratime as mount options

Should the rootfs be ext4 or an other FS?
What options or directories did i miss?
Should be whole /var be external?

Thank you!

[1] http://en.wikipedia.org/wiki/CF_(memory_card)

[NeddySeagoon]

schorsch_76,

That list looks good. Do you actually need logs ?

You should use ext2 on the CF card, or ext4 with the journal option turned off.
That saves journal writes and makes things a little faster.
This costs you time if you ever need to run fsck in the face of an unclean shutdown.

If you wish to have a read only root, except for updates, look at the gentoo-embedded project.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[schorsch_76]

Is it that one? http://www.gentoo.org/proj/en/base/embedded/

Looks interesting. uclibc is new to me. Will read the book.

The first device is a logger for some data which connects via openvpn to a server. The logs could be sent to this server.

Thank you for your input

[Simba7]

If you can, find a Microdrive. I have one in a modified MSNTV2 box.

Also, if it has a USB port, connect an external HDD to it and utilize that for swap and /var/tmp.

[Ant P.]

Definitely don't keep the portage tree on the CF card. You may also want to move /var/db/pkg off of it since that's only needed when using portage.

As far as normal directories go, /tmp and /run should be tmpfs already, symlink /var/run -> /run and /var/lock -> /run/lock if they aren't already (as long as your system's up to date, openrc will take care of the details automatically and everything will just work).

If you don't urgently need local logs, put all of /var/log in a tmpfs and use rsync or untar to recreate the directory tree on startup. Programs write there often even if you don't have a local syslog.

If you want to go to extreme lengths, then putting all of /usr in a squashfs is also an option. That should free up space so the CF card's internal wear levelling can work better.

The best option for a root FS is ext4 without journal. ext2 with the ext4 driver is also a reasonable option if you need compatibility with really old systems, but you lose performance that way.

[schorsch_76]

@simba: That was an option, but i could not find a microdrive. This would have been my favorite choice.

@Ant. P.: Thank you for your input!

Yesterday i did read the embedded book an saw the experimental uclibc stages, but my cpu is a gedode which is i586 or better i486 (performance wise). So i did try to build from the experimental i686-uclibc stage a new stage3 tarball with catlyst, but the documentation is not very extensive.

As far as i understood:
For stage 1:
- chost needs to be the chost from inside the seed
- no optimizations for special cpus. In my case subarch=x86

For stage2:
- subarch and chost needs to be adjusted. In my case i486.

My problems so far:
- Could only build a uclibc stage with a uclibc seed.
- Could not change the chost from i686 to i486 because it did not build and failed at emerging zlib (directly at the beginning of stage2)

I did this on an amd64 host.

My questions:
Can the seed be recreated if i untar the glibc seed, create a crossdev for i486-pc-linux-uclibc and tar it again?
Is there an explanation of the thre stages, to understand better what stage1/stage2 is inteddend to do? What is the target of each stage? stage 3 is clear
I use gentoo since nearly a year, so i did never install a pc from stage1 and i miss that knowledge. So i need that documentation to understand what is happening there.

If i understand the documentation right, i can only build for "lower or equal cpus", but how are the stages/seed build for new cpus or new architecures?

[1] http://www.gentoo.org/proj/en/releng/catalyst/
[2] https://forums.gentoo.org/viewtopic-t-680609-highlight-chost+catalyst+stage1.html
[3] https://forums.gentoo.org/viewtopic-p-5071293.html

[NeddySeagoon]

schorsch_76,

Its unlikely you can run the i686 code on a less then i686 class CPU.

It been a while since I did a stage1 install but it goes like this.

Stage1 provides sufficient for you to build a toolchain. You get to set your CHOST if you do a stage1 but you need to start from a lesser CHOST.
You do a stage1 with the commands

[schorsch_76]

Thank you Neddy four your information!

I did start from the i686 uclibc stage3 because in the experimental mirror for x86, there is no lower chost than i686. [1]

But the change from glibc to uclibc seems harder than i thought. So i might use glibc, until i fully understand that staging process. The only chost which is available for i486 is i486-pc-linux-gnu and not i486-gentoo-linux-uclibc. There is only i686-gentoo-linux-uclibc.

I read the crossdev guide [2] and i think i will use this approach to create a stage3 for my geode. It seems very nice. Emerge all stuff on the host, regardless of the target architecure and copy the whole thing to the target. Get the list of needed packages for a stage3 and cross emerge them to the SYSROOT.



[1] http://de-mirror.org/gentoo/experimental/x86/uclibc/
[2] http://www.gentoo.org/proj/en/base/embedded/cross-development.xml

[schorsch_76]

Yesterday i did my crossdev and cross build of i486-gentoo-linux-uclib.

I followed the (deprecated) crossdev guide, because the embedded guide is as far not as detailed as the crossdev guide.

Cross chain was absolutly no problem. Following steps did i do:
- create partition /dev/laptop/uclib and mounted it on /mnt/uclib. This is the target for SYSROOT and keep it absolutly seperated between code for the host and the target. Reason follows later.
- Setup SYSROOT and xmerge (see crossdev guide)
- for the target /mnt/uclib i copied /etc/portage from the stage3-i686-uclib to /mnt/uclib/etc/portage and setup the link of the profile the same as the i686-uclib stage. Ofcourse change chost and CFLAGS to i486.

Now i tried to setup a stage1. The bare buildchain and portage in /mnt/uclib

[NeddySeagoon]

schorsch_76,

The python build system is very cross build hostile. It builds some code to execute on the target, then later during the build, tries to execute the code on the host to continue the build.

The gentoo ebuilds try to apply patches to fix this but the patches are very python version specific. Patches are not available for all versions.

Perl has another build system like this.

My crossdev experience is limited to arm for iPaq and arm for Raspberry Pi, neither of which used ulibc.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[schorsch_76]

Hello Neddy,

thanks for your repeated and useful input It's not really a problem that i cant get it build, because i can use glibc. It's a case for me to understand the cross builds, emerge and the stuff from the foundation of gentoo. Currently i have a CF card installed with glibc and a second one for my experiments with uclibc.

I did not get the whole stage1 compiled with uclibc. portage did not compile. Now i will try the "ugly" way. Unset my CHOST in make.conf on a i686-gentoo-linux-uclibc stage3 and rebuild all. As far as i understand the Wiki [1] the CHOST from the make.default will take control and set it to i386-gentoo-linux-uclibc. It will fail if it starts the compiler via $CHOST-(gcc|g++|etc). Then i might provide some symlinks. I know, that is all not supported ....

I hope that app-emulation/qemu will complain about i686 code if i set the cpu to i486. My build system is an amd64 system on an i7.

Bye
schorsch

[1] http://wiki.gentoo.org/wiki/Profile

[NeddySeagoon]

schorsch_76,

The problem with starting with a i686-gentoo-linux-uclibc stage3 is that the toolchain and probably other code, is likely to use i686 instructions.
Thats OK if your build host supports that.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[depontius]

Somewhere once upon a time there used to be a "Stage 1 on Stage 3" thread here. One good use was changing CHOST, and I used it when reinstalling my K6-III machine, since I don't believe it had the CMOV instruction needed by the i686 stages.

However you needed to start with a generic x86 or i386 stage on a pre-i686 processor, since the toolchain won't even run there in order to rebuild itself.
_________________
.sigs waste space and bandwidth

[Simba7]

[depontius]

[schorsch_76]

Very nice Simba! Will try that

[schorsch_76]

Thank you very much Simba!

With some adjustments (like partitions and glibc/uclibc) i got my i486-gentoo-linuc-uclibc stage build!

Just one question: You seem to use gcc 4.7.3. Should the end of the script not be

[Simba7]

[Wallsandfences]

hi,
i'm facing the same issue -- want to have i486-uclib based gentoo for my alix.

Schorsch, if you still there, would you mind to elaborate a bit more, what exactly you did to emanate your uclib-based i486 on your alix?

Or probably care to share your stage?

Rüdiger

[slis]

Maybe you want to check this thread also: https://forums.gentoo.org/viewtopic-t-963320-highlight-.html
I've put there some info about solution for problem similar to yours.