Welcome to ivories.org blog
No fancy comments/login/autospambot nonsense has been created here. You can email your thoughts to fauxmight@i.o (see host in your browser, friend). If I like your comments, I'll post them after the appropriate article. If I don't, I won't. You can think of it like un-automated moderation.
Sat Dec 13 16:49:15 CST 2008
Okay, for anyone that lands here looking for INSTRUCTIONS FOR BUILDING GENTOO ON THE NOKIA N810, the entries here are merely for historical amusement. Please go to Gentoo on N810 for functional instructions.Fri Nov 14 05:50:11 CST 2008
Ok, back to Gentoo on the n810. Vapier has graciously provided UP TO DATE arm stages. These will help a great deal to bypass the ass pain of getting 2005 stages up to date. I tried the armv4l stage and .config segfaulted on the first thing I built. I'm assuming v4l is the problem and I'm going to try the armv4 stage. (I also had the "find [randomCrap]" bug showing up again, from the get-go. I still don't really know what does that. Let's see if armv4 helps.Here's the roadmap of what's planned:
Use external SD card as swap space.
Get armv4 stage untarred with perms.
Get a portage snapshot
Update portage
build updated gcc with this toolchain
(This may involve adding "ACCEPT_KEYWORDS="~arm" before JUST this compile.)
rebuild toolchain
change make.conf (See below)
rebuild toolchain
The new planned make.conf will look a bit like this:
# These settings were set by the catalyst build script that automatically
# built this stage.
# Please consult /etc/make.conf.example for a more detailed example.
CFLAGS="-O2 -pipe -march=armv6j -mtune=arm1136jf-s -mfpu=vfp -mfloat-abi=softfp"
CXXFLAGS="${CFLAGS}"
# WARNING: Changing your CHOST is not something that should be done lightly.
# Please consult http://www.gentoo.org/doc/en/change-chost.xml before changing.
CHOST="armv6j-unknown-linux-gnu"
I'm looking into exactly what the difference between using "-mfpu=vfp" and using armv6j-unknown-linux-gnueabi is and if they are mutually exclusive.
Thu Oct 30 22:22:26 CDT 2008
Ok, so here's how to keep a nice clean off-site backup and several synchronized machines without loosing your mind:Central server on site: This box has an NFS share that holds everything you want synchronized. The NFS share is properly protected, shares ONLY to local IPs, and IS BEHIND A FIREWALL!
All other boxes that wish to synchronize have the NFS share in /etc/fstab. If a particular box is always on the same network as the server, it may automount the NFS share and have a cron job that runs unison (discussed shortly). If a particular box is NOT always on the local network, it still has the NFS share in /etc/fstab, but does not automount it at boot or otherwise, and it, too, has unison installed. Each of these client boxes has a mount point for the NFS share, but also keeps a separate directory for the "local" copy of everything on the NFS share.
Unison is used by all the client boxes and is either cron jobbed (not ideal ... but could work), or run manually to synchronize individual clients with the server BI-DIRECTIONALLY! This is the awesome part. Rsync is great for one-way sync, and may substitute for unison on any box that will not modify the shared files. Unison, however is ideal for, say, a laptop that is used and often modifies it's local copy of the shared files. At any convenient time when the laptop is on the local network, unison (most likely a script that calls unison with a particular set of directories included/excluded) is run to synchronize the NFS share and the local copy. If necessary, a VPN back to the local server could be set up so that NFS/unison synchronization may take place safely while the client box is off-site.
Now for the off-site backup aspect: the server box does run a cron job that tars up the shared directory, pipes the tar output to an ssl encrypted temp file and scp that file to an off-site. Bandwidth is an issue, as is disk quota on the off-site point, but security is pretty nice, because a denizen that gains access to the off-site box has only an SSL encypted tarball of uselessness (+9 against absurdism). Here's an example line of how to do the above (backslash line breaks for clarity):
tar cfz - /NFS-SHARE-DIRECOTRY| \
openssl des3 -salt -k SUPER-SECRET-PASSWORD| \
dd of=/tmp/BACKUP-OF-STUFF.des3 \
&& scp -l 10 /tmp/BACKUP-OF-STUFF.des3 LOGIN@OFFSITE-BOX:
Thu Oct 16 10:57:53 CDT 2008
Ok, finally getting around to the eventual purpose: Reminders of junk that breaks every time I try it.ROUNDCUBE: I always turn OFF "automatically generate user blah blah blah," thinking this will try to create users on the mail server. That's just stupid, and not even close to what this means. It's auto-creating users on the sql database for RC. That IS what we're trying for. We don't want to make RC users manually. Remember this. It'll save some serious time with each RC install.
Mon Sep 1 14:53:30 CDT 2008
Ok, I think I'm done with the gentoo on n810 attempt.Here's my reasons for abandoning the project:
1) eabi support on gentoo is more complicated than I'm willing to deal with
1a) gcc will build, but I cannot seem to build an eabi gcc.
this makes the gentoo-ness of gentoo on an n810 not so gentoo --
that is to say, it's not very ricer-tuned if debian has eabi binaries and gentoo does not.
2) The deblet project is getting much more mature at a remarkable rate.
3) Debian in eabi friendly.
4) The inconvenience of regular use while cross-compiling and not gaining in performance is an unacceptable combo.
Sat Aug 23 16:41:41 CDT 2008
This entry is the reason that this blog was created in the first place. The date above is the actual posting date, but this log was started 14 August, 2008.!!WARNING BLOG PURISTS!! This entry will be modified until it's done. (It's not gonna be added entries like a real blog.) I might start putting modification dates in ... like a blog in a blog ... or I might not. If you don't like that, make your own blog-generating scripts, and your own blog, and your own creative-commons-licensed duck-on-a-cd image (which I didn't make), and get gentoo working on the Nokia N810 yourself ... and if you do, could you tell me how?
So, without further ado,
HOWTO [try to] INSTALL GENTOO ON THE NOKIA N810
Diablo flashed to n810 currently.
Internal mmc formatted ext2 (cfdisk used - compiled for arm using scratchbox previously)
External mmc formatted to 2 partitions: 1st is small (256MiB?) vfat, second is ext2
Used this page:
http://maemo.org/maemo_release_documentation/maemo4.1.x/node12.html
to build a kernel in scratchbox that has IN KERNEL ext2 support
(I suppose running the os on ext2 could be accomplished by initfs w/ the kernel module there
but thought this would be the more suitable way to go.)
The arm stages are very, very, very, very, VERY old. (2004-5). There's a arm and an armv4l stage. I'm not sure what the difference is. I'm working with the armv4l stage. n810 is an armv6l according to uname. Backward compatibility between arm revisions is not entirely clear. Perhaps a grand master of embeddedness could enlighten me here. It appears that binaries compiled for armv4l DO work on n810, so I'm gonna run with that.
I've run into an interesting snag. I've got the internal 2GiB card, and an external 2GiB mmc card. I've gotten a kernel build with ext2 support (built in). This works fine. I flashed the maemo side of the device with the new kernel and am using it while trying to set up my chroot environment.
Snag is when I ext2 format either card, there's a file count cap (somewhere near 128k files). Untarring portage barfs with errors that vaguely resemble running out of space. I got lost on that red herring for a while before finding the file-count cap with e2fsck.static (built thankfully not by me for maemo). I have a feeling the only way around this will be a larger mmc card.
homey1337 fixed this with a clever bit of file-system creation management. I didn't know enough about file systems to realize that changing my bytes-per-inode count would allow a higher file count on the partition. I put bytes-per-inode (mke2fs -i) count as low as possible (4096, if I recall -- lowest possible is the block-size for the partition), and quintupled my potential file count.
At this point, I made a gentoo subdir inside my maemo scratchbox environment. I know, I know, homey1337 says I should let scratchbox make my chroot environment for me instead of chrooting in a chroot, but I'm dumb. I couldn't make it do that, so, I'm gonna chroot inside a chroot. Anyhoo, I'm now updating portage on the n810 (chrooted inside my gentoo dir -- which is now on the mmcblk0 device instead of an mmcblk0p1 partition -- interesting that sd will let you do that), and I'm unpacking portage tarball in the scratchbox maemo chroot (1st level, not second -- yeah, this gets a bit confusing) on my T40 (PIII 1.5Ghz .75g ram). If the chrooted chroot on the laptop catches up with the process going on directly on the n810, I'll quit there, and just push on here. Right now, I'm just not sure which is faster a native arm 400, or an emulated arm on x86 1.5ghz.
Ok, new problem, scratchbox won't LET me chroot while inside a chroot. I've got to figure out how to do something more sane here.
Can't emerge --sync out of the box. I run into ebuild can't resolve to package error. Emerge portage gives similar. ebuild .../../../././/portage.#.#.#.ebuild digest followed by emerge portage looks like it worked. There's some freaky errors, but it plows on in spite of them. I DID re-softlink /etc/make.profile to an actually existing profile (2007). The softlink from the stage3 links to 2005. /usr/portage/profiles/default-linux/arm has a 2004 and a 2007.
Ok, after the emerge portage, I'm very, very broken. Need to reboot. I accidentally deleted a handful of my /dev files when I forgot to unmount a -o bound /dev.
Ok, trying a different approach with regard to emulated environment: got qemu emerged with gcc 3.4, and
using this site:
http://www.aurel32.net/info/debian_arm_qemu.php
I'm working on getting an emulated arm environment in which I will chroot and install gentoo. I'll let you
know how it progresses.
Here: this saved my ass!
http://www.nas-2000.org/download/build-root/readme.txt
I'm still in progress with this one, but it looks like this will unburry my burried shovel. (Fix portage
on the stage 3 install from 2005). Ok. The first several steps of this worked. When I got to emerge -av sandbox,
it griped about the /etc/make.profile symlink not pointing anywhere valid. I'm gonna go out on a limb and
link it to the 2007 profile. I'll let you know. Ok. I survived. sandbox is emerging as we speak ... so to
speak. Done. Moving on to updating python with quickpkg old python for later slot install.
Still doing well. Got another speed-bump. While trying to emerge python-updater according to the site mentioned above, I've got two package conflicts. The portage version is too old for bash, and this becomes a circular one. Also, util-linux is too old for coreutils. This seems fixable by one-shot emergeing util-linux. We'll get around to the fix for portage/bash ... this one is odd, because it comes up while trying to get python-updater.
Got a glitch in emerging util-linux. lncursesw issue. Vague report is that I need ncurses emerged with unicode. Trying that, and the trying to re-emerge util-linux. (This fixes a smaller problem than the portage/bash issue. I still don't know how I'll resolve that.)
Ncurses with unicode emerged alright. Trying util-linux again. This worked. Both are installed. Looks like I've
got a work-around for the bash/portage blockage. This came from
http://bugs.gentoo.org/show_bug.cgi?id=217479
emerge '<app-shells/bash-3.2_p33' ; emerge portage
was suggested. I'm doing the first part, but not necessarily updating portage until I've got a functional
python-updater. (I believe that the python-updater emerge will pull in the new portage.) We'll see once
the new-but-not-newest bash is emerged.
Ok, that fixed all the blocking issues. The python-updater emerge is in progress now with no blocks or forced 'nodeps' installs. This is a rather large set of packages, however, and includes python-updater and portage among the to-be-installed packages. I'm going to sleep. I'll let you know how well things have progressed and any new road blocks discovered in the morning. (Ideally, when I wake up, this will be done, with no fail-outs during compilation. Barring that ideal, the emerge will still be in progress, but not interrupted by failure.)
Well, surprisingly, that worked. No complications, so far as I can tell. Looks like we're on to updating portage. Had the old shadow/pam blockage. Unmerge pam-login emerge update shadow. This one is almost common knowledge... Wait, I just checked, and Yes, my grandmother _does_ know how to get around this.
Having some trouble (after all that hubris above) gettin pam updated (needs update before shadow can install).
The update says I'm using modules that won't be supported in the update, and the fixit page for gentoo
http://www.gentoo.org/proj/en/base/pam/upgrade-0.99.xml#pam_stack
tells me what needs to change in the files, but NOT WHICH FILES to change... Ok, I think I got that worked out
ok. I modified everything in the /etc/pam.d directory. It looks like it worked. I've got an update world going
now. I know I've left the handbook instructions far behind, but we'll pick back up with those.
Ok, it's been a few days since my last update, but here's what's flying: I quit the world update, because I just could NOT get gentoo to boot on the 810, and my thought was, it should boot up from fanoush's modified bootloader even without the world update. When it wouldn't (no visible errors, just hang and then reboot), I started tinkering with two major pieces: 1) Why won't it boot :) 2) Can I get a frame-buffer console going to SEE kernel/init errors during boot.
On the 1) topic, I've solved some potential pitfalls, but still haven't gotten there. For the sake of record, I tarred up the /dev from the stage3 distro and put it aside, then tarred up the /dev from a maemo install and dropped that into the gentoo chroot /dev. Udev should take care of this, I know. The only things that NEED to be in /dev are console and null, but what the hell. The /etc/runlevel/[boot,default] initscripts from the arm stage3 were dangling symlinks to /tmp stuff. I fixed these to point to /etc/init.d. I found that even using fanoush's bootloader, I can NOT boot johnx's debian if the tablet's flashed os is debian. I flashed back to chinook, reflashed the initfs with fanoush's, and debian booted ok. Gentoo still a no. More on where we're going from here in a moment, but first
On the 2) topic, I wrote to johnx (creator of the native debian-on-n810 port) on internettablettalk to ask about the framebuffer console issue. He had some helpful points. The framebuffer console is not in the default chinook kernel (I think it is in diabo ... not sure). Must compile this module or rebuild kernel (scratchbox). I usually choose the latter. Then, I also needed the fb_update_mode utility to turn update mode to auto. This worked to get to a framebuffer console in maemo. I put the fb_update_mode in /root and called it in init scripts. I made no progress doing the same in gentoo. This implies a problem before the gentoo init scripts get going. Well, actually, that's not true, because even in maemo, the console doesn't come up until a chvt 1. (Maemo X is on vt2).
Here's johnx's message to me. I worry it won't stay put on ITT: 3 message limit to inbox/outbox/everything over there. Only the <p>s and <br>s have been added to protect the innocent blank lines.
-------- begin quoted message -------------
Sorry for not getting back to you earlier.
I've been working way too much lately. Anyways, the framebuffer issue you're seeing is two things.
First of all the kernel Nokia ships doesn't have framebuffer console support compiled in.
Only way to make it work is with an additional module. Even after that you need to grab the
fb_update_mode utility from here:
http://www.internettablettalk.com/forums/showthread.php?t=18948&highlight=fbcon
Hack up an initscript to load the modules and run fb_update_mode somewhere early in the boot process.
In the end, I found it easier to just load g_ether.ko, setup USB networking and run a telnet daemon
in an initscript. In your case fb console will help you troubleshoot why it's rebooting. If you have
any more questions please feel free to PM me or start a new thread in the debian section of the forum.
Just say that I told you to and you.
Also, you might want to check out some of the debian-on-n8x0 wiki pages up:
http://www.internettablettalk.com/wiki/index.php?title=Debian-old
might be something here too:
http://trac.tspre.org/projects/deblet/wiki
Anyways, it's really nice to see someone that wants Gentoo on the tablets finally stepping up to challenge. Good luck!
-John
-------- end quoted message -------------
While struggling w/ the frame-buffer issue, I came upon another interesting and possibly helpful point. The fb_update_mode utility comes w/ source and executable. The executable runs fine on maemo, but pops an obscure file-not-found bash error when I run it in the gentoo chroot. I gcc'd the source inside the gentoo chroot, and the new binary worked fine. Oddly, back in maemo, the newly gentoo-built binary did NOT work, delivering the same bash i-can't-find-this-file message. Spoke w/ glucnac on this. He suspected library linker issues. I noted that the arm stage being as old as it is has ancient gcc/glibc. I don't KNOW what the problem is, but this brought me back to the notion that updating the system/world metabuilds on 810 might not be such a bad idea. In the interest of time, I set up distcc between the 810 and my server (athlon XP 3200 1gRAM). I set up a crossdev toolchain on the athlon, and sample compiled a handful of things successfully and a few not-so-successfully. I then remembered that I have different tool-chain versions on the host and client build team. (crossdev builds the latest ~ARCH toolchain.) So, I'm now rebuilding the toolchain natively (no distcc) on the 810.
Looking at qlop values for known compiles on the two systems, it appears that build time for the n810 is approximately 10x build time for the same package on my T40. This is helpful in anticipating durations for build times of as-yet-un-emerged packages on the 810 natively. Anticipated gcc build time: 20 hours.
Oh, I also mounted two separate 256M swap partitions inside the gentoo chroot. I've had spontaneous reboots during large compilations in the past that I suspect are due to the watchdog recognizing an out-of-ram state. Hope this helps. binutils compiled natively with the swap partitions in place, and failed to (rebooted) without them.
EDIT 2008.08.23 17:23 CDT: Just realized that I reference both homey1337 and glucnac in here. He's the same guy.
He'll have to decide which psuedonym he likes. Then again, somebody would actually have to give a crap about reading
this giant tome of bullshit for it to matter.
EDIT 2008.08.23 21:35 CDT: Ok, homeyGlucnac says he likes his split personality. So, if you get to this bit, consider
it an easteregg.
EDIT 2008.08.24 09:32 CDT: gcc native recompile completed successfully in around 10 hours. Nice compared to the 20 hours expected. glibc rebuild is failing with "this gcc version doesn't support __threads." Trying some work-arounds. Already attempted a crossdev build on the Athlon server, quickpkg, and install from tbz. I can't get the 810 to accept installing anything at all from .tbz. Attempted the same methods just to check binpkg installation seemed to work the obvious ways on x86 machines, so perhaps a python update/portage rebuild is in order? Ok, dunno why that seemed to work, but it did. I need to finish a python-updater also, but it's 53 packages, and I'd prefer to let the server do most of that once we're running the same glibc on both sides.
EDIT 2008.08.24 22:10: gcc, glibc, binutils are all now up to date. I updated python as well, rebuilt portage with the
new python 2.5, and ran an "emerge --depclean" (which got rid of the old python). I'm getting "110" error on distcc on the
server for many builds. I tried putting "CC=armv4l-unknown-linux-gnu-gcc-4.2.4" into make.conf (and the complementary CXX
line), but this just prevented distcc from being used at all. Ok, armv4l-unkown-linux-gnu-g++ doesn't exist on the cross-
compiled arm gcc. It does exist when the same package is natively built. I tried symlinking armv4l-unkown-linux-gnu-cpp
to armv4l-unkown-linux-gnu-g++, but the 110 error still comes up when using crossdev with the athlon system reporting that
it doesn't have armv4l-unkown-linux-gnu-g++. Ok, looks like I've got the fix for this one. I cleared out the entire crossdev
tool chain and rebuilt with this command:
"crossdev --ex-gcc --target armv4l-unknown-linux-gnu".
The "--ex-gcc" tells it to build "extra" gcc targets, and I now have an armv4l-unknown-linux-gnu-g++. I ... rock.
Revdep-rebuild went off without a hitch. Python-updater somewhat disturbingly reports no previous version of python. This
is true; I unmerged it with a --distclean, but I'm not confident that the list of packages which it used to want
to rebuild don't still need it. It'll come out in the wash, because I'm proceeding to clean up my /var/lib/portage/world
(and world-sets) files and on to an empty-tree @system rebuild followed by an attempt to boot followed by an @world rebuild.
Somewhere in there, likely more than once, I'll also be retarballing the gentoo chroot.
2008.08.27: Got a new and very odd hurdle: Every emerge has find [gobledygook] : No such file ... (total freaky random character strings).
I thought this was a unicode issue. I think it started after updating util-linux, but I'm not sure. I've had it in
every emerge for quite some time. I stopped the @system rebuild because gcc had a hang up spot on one of its patches. (It also
has the find [randomcrap] thing going on, but that isn't stopping all builds, just some (pam-syntax and a few other
inconsequentials but mostly deps for other things).
Ok, moving back a step. I'm untarring the last tarball I had, and going to try to do two things: figure out where the find
problem comes from, and change my CHOST/use flags to make an ideal OMAP 2420 optimized build of all things. Also, in case
I forget, the reason I can't unmount /mnt/gentoo/dev is that I swapon'd the /dev/mmcblk[01]p1 partitions. Lose them inside
the chroot before attempting unmount for better happiness. Also, take CFLAGS from Mamona site:
http://dev.openbossa.org/trac/mamona/wiki/InternetTablets.
For reference, they are "-march=armv6j -mtune=arm1136jf-s -mfpu=vfp -mfloat-abi=softfp".
2008.08.30 Ok, nailed the find issue culprit, but not sure why the problem occurs. I untarred my updtodate-gcc/glib tarball, and
emerge ONLY findutils, and by the end of building itself, "find [random bullshit]" showed back up. Working on it ...
OK, abandoning that aspect for the moment. Going back to trying to build a more optimized gentoo. We're going to try
the a CHOST slightly modified from http://gentoo-wiki.com/HARDWARE_PDA.
They used armv5te-softfloat-linux-gnueabi. We'll use armv6j-softfloat-linux-gnueabi and take their advice to switch off the
fortran use flag on gcc. (Actually, I'm killing the fortran mudflap and openmp use flags.) I'll let you know how it goes.