Problem: plugin directory name “microkid-related-posts.svn”, since I check them out directly and like to know the scm type used

Solution: remove “.svn” from directory name

Should anyone know why that helps, I’d welcome some hints.

This mostly makes sense, because compiling software can be a lengthy process. Even more so when you’re possibly emerging tens of packages at a time. It makes no sense for the user to guard the terminal and stare at the Matrix, waiting to answer the occasional, usually trivial Yes/No prompt.

But in this particular use case I have, I’ve discovered I’d like to run an interactive command etc-update after every package finishes installing (ebuild postinst phase). My goal is to have a firm grip on a vserver bootstrap template configuration with the help of git. Portage’s configuration protection litters /etc with ._cfg* files and I would rather not spread the litter to the git repo by just blindly committing everything in postinst. Also, maintaining the bootstrap template is usually a rare and short operation (few packages at a time) where I can monitor the build and act on request.

Your ${ROOT}/etc/portage/bashrc could have something like this:

echo Phase: $EBUILD_PHASE
ETC="${ROOT}etc"
GITCMD="GIT_DIR=$ETC/.git GIT_WORK_TREE=$ETC git"

case "$EBUILD_PHASE" in
    "setup")
        STATUS=$(eval $GITCMD status -uno -s)
        [ -n "${STATUS}" ] && die "Error: $ETC is not clean"
    ;;
    "postinst")
        etc-update
        eval $GITCMD add $ETC
        eval $GITCMD commit -q -a -m \"emerge $CATEGORY/$P\"
    ;;
esac

Problem is that emerge pipes everything to its logfiles and won’t let etc-update get any input from you. Some googling revealed a solution by redirecting stdin and stdout. /dev/tty is magic that always has the right answer, google it yourself for details.

${ROOT}/etc/portage/bashrc:

...
    "postinst")
        etc-update 0</dev/tty 1>/dev/tty
...

jflatt at the invaluable tmo forum published an approach to install the N9 version of Real Golf 2011 on N950. It is a mind-numbingly simple task of just adding the N9 apt source repo to your lists.

$ devel-su
Password: rootme
# cd /etc/apt/sources.list.d
# echo "deb https://qa9recEP:Pat2UGuP@downloads.maemo.nokia.com/harmattan/001 ./" > n9.list

“001″ is the device code that replaces “rm680″ for N950. Real Golf requires some additional hacking (see link above), but that is not what I wanted to talk about. First question on my mind was: can I finally get Skype UI installed on the N950 the same way?

Continuing from before:

# apt-get update
# apt-cache search skype
l10n-app-skype - Translation File for application skype
telepathy-spirit - Skype connection manager for Telepathy
account-plugin-skype - Skype plugin for accounts-ui
# apt-get install account-plugin-skype
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed
  account-plugin-skype
0 upgraded, 1 newly installed, 0 to remove and 14 not upgraded.
Need to get 390kB of archives.
After this operation, 1,528kB of additional disk space will be used.
Get: 1 https://downloads.maemo.nokia.com ./ account-plugin-skype 0.85+0m6 [390kB]
Fetched 390kB in 2s (193kB/s)
Selecting previously deselected package account-plugin-skype.
(Reading database ... 44172 files and directories currently installed.)
Unpacking account-plugin-skype (from .../account-plugin-skype_0.85+0m6_armel.deb) ...
aegis-installing account-plugin-skype (from 'com.nokia.maemo')
Processing triggers for desktop-file-utils ...
Setting up account-plugin-skype (0.85+0m6) ...
Updating desktop entries... Done
#

My existing mc-tool’d Skype account did not show up after this procedure. So I removed it.

$ mc-tool list
$ mc-tool remove account-name-here

Then I launched Skype from the fresh new app launcher icon that appeared, entered my account info again, logged in and everything seems fine so far.

I believe it was Jamie Oliver who said: Happy Days!

Once you’ve accepted this reality (it will take a certain amount of time :>), it starts to make sense to prioritize tags in the display list. This is useful for quickly glancing over key categories without scrolling through your whole list, which helps keep in-app time spent lower and simultaneously keep the mind at ease. “Phew, I did not miss that massively important blog post, another crisis averted!” type thing.

I have found using the format of “+tag” accomplishes this goal when alphabetic sorting is used and is pleasing to the eye, no doubt thanks to Google recently rewiring my brain according to their plus-sized masterplan.

Note that I have everything sorted alphabetically, because the overhead accompanying manual drag-n-drop sorting probably doesn’t assist with the original goal of spending less time with the app.

4GB of RAM started to feel cramped and adding another 4GB 1333MHz DDR3 for 20€ sounded reasonable for a 4x2GB configuration.

So I types

shutdown -h now

off comes Antec Remote Fusion top cover, in go the new memory modules, finger hits Power button.. only to see BIOS showing I still have 4GB of total memory.

Great.

After one or two CMOS resets, power cycles and a bit of BIOS-exploration, I noticed Gigabyte BIOS M.I.T. Status screen show something strange: all memory sticks were listed for 2048MB, but only two of them were shown as being “Enabled”.

OK, foreseeing some more power cycles here, so disconnecting HDD power cables for a bit seemed reasonable. Let the memory slot testing bonanza begin! Couple of interesting behaviors surfaced.

GA-P55M-UD2 has the following memory slot layout:

|-----------------------------------------| DIMM2
|-----------------------------------------| DIMM1

|-----------------------------------------| DIMM4
|-----------------------------------------| DIMM3

Motherboard manual says two-stick Dual Channel is achieved by placing DIMMs into slot 1 and 3. Yet mine were sitting in slots 1 and 2 instead. At that point I seemed to vaguely recall some issues getting slots 1 and 3 to work together and since 1 and 2 Just Worked(tm), I left them there at the time.

But as we need to know whether Slot 3 actually works at all, I set the layout up again. All I got was a pre-POST reboot loop, which was a pretty good indication of some deeper problem. It’s Google-time for “ga-p55m-ud2 8gb memory” and themsuch queries.

Surprise surprise, turns out this behavior has been seen before and one of the first recommended debugging operations seemed to always be “reseat CPU, check for bent pins”. First I had ever heard of this, you (read: I) would think that if a pin was non-functional, you wouldn’t even get to POST. But this box has been rolling along for a few years now, although with memory sticks possibly being in “wrong” non-Dual-Channel slots.

http://www.tomshardware.co.uk/forum/270289-12-another-gigabyte-ud3r-memory-problem
http://www.tomshardware.co.uk/forum/267749-12-windows-usable
http://www.tomshardware.co.uk/forum/270808-12-continuous-short-beeps-p55m
http://www.tomshardware.co.uk/forum/266861-12-p55m-post-reboot-cycle

It was clear now, there was no way to avoid disconnecting the bazillion cables sticking out from the back of the server and digging through desk drawers for that Arctic Silver MX-2 tube. Yawn.

Intel’s instructions for checking sockets:
http://www.intel.com/support/processors/sb/CS-030850.htm

Looking carefully at the socket pin grid, there indeed seemed to be a spot in upper left corner where a pin seemed to reflect light at a different angle being slightly out of the straight line everybody else was standing in. So I augmented it to the best of my ability with the smallest flathead screwdriver I could find in the house (1mm) and using my girl’s reading glasses as magnifying help. While the pin looked somewhat more in line post-op than before, I am still not entirely sure it’s exactly factory-precision.

In the lower right part there seemed to be something that looked like a small part of a fingernail stuck between pins. So for good measures and while I was at it anyway, I patted myself on the shoulder for job obviously well done on the previous CPU installation and dug the unidentified object out of the socket. Was kinda disappointed the cooking heat of the CPU didn’t turn it into a precious jewel of some kind. Would’ve felt nice to get profit out of gcc and kernel compilations.

After some cursing at S1156 HSF mounting mechanism when putting Scythe Shuriken back on top of the CPU, machine was ready to be tested again.

• #1 Slot 1 and 3 Dual Channel test: machine now booted instead of reboot-loop, PASSED
• #2 Slot 2 and 4 Dual Channel test: pre-POST reboot-loop, although I’m not entirely sure this is even supposed to work, FAILED
• #3 Install all four 2GB sticks: BIOS shows 8GB of memory, BIOS M.I.T. Status screen shows all four sticks as enabled, PASSED

So all in all, happy days.

Based on the above, I’d say bent pins inside the CPU socket causing your memory problems is a real good possibility. Definitely check socket, adjust pins and reseat CPU before you convert the motherboard into being a part of your frisbee equipment.

What I’m wondering now is what happens when different pins are out of alignment. Is it always memory issues, or different bad things happen or to what extent the CPU is capable of functioning in general?

With aegis watching over us like a true eye in the sky, getting N950 to let you ssh in as unprivileged user with public key authentication took a bit of effort. Sure, you could ssh root@n950 and then su – user, but doesn’t the sane world do it the other way around?

Anyway, get your authorized_keys file on the device as root with sftp, or manually typing it. No, just sftp it, dude. Now aegis won’t let root see ~user/.ssh and also won’t let user see /root/.ssh contents.

# cp /root/.ssh/authorized_keys /tmp
# chmod 644 /tmp/authorized_keys
# su - user
$ cp /tmp/authorized_keys .ssh
$ exit

At this point ssh user@n950 still shouldn’t be letting you in, because apparently the account is locked by default. syslogd doesn’t by default log sshd stuff, so if you want to see this for yourself do this as root:

# echo "auth.* -/var/log/secure.log" >> /etc/syslog.conf
# stop syslogd
# start syslogd
# tail -f /var/log/syslog /var/log/secure.log

Now try ssh user@n950, this is what you should see:

==> secure.log <==
Jul 25 01:09:11 RM680 sshd[2838]: User user not allowed because account is locked
Jul 25 01:09:11 RM680 sshd[2838]: Failed none for invalid user user from 192.168.1.111 port 354
83 ssh2

Solution is to unlock the account.

EDIT Originally I thought usermod -U user would do the trick. It turns out it doesn't work out so well. aegis-loader (and possibly other parts) started puking when doing dpkg -i etc.

/home/developer $ dpkg -i conboy_0_0_1_armel.deb
aegis-loader: Failed parsing '/etc/passwd
...hanging forever

After a bunch of folks on #harmattan helped me get to the bottom of this, mgedim pointed out passwd seemed to work for him:

# passwd -u user

I have no idea what usermod and passwd are doing different aegis-wise. Hints welcome!

Find address for latest tgz-ball. Unpack.

$ devel-su
Password: rootme
# cd hut-ranger-<hash>

We can’t execute scripts directly because of aegis, so just run the script into python.

# python ./setup.py install --optimize=1 --record=install_log.txt
# exit

This will install ranger into /usr/local and exit root shell. Now we also can’t run ranger directly because of aegis. Let’s set up an alias for this. Busybox needs $ENV to specify a startup script for it’s built-in ash.

$ vi .profile

Append “export ENV=$HOME/.bashrc” somewhere. Sure, why not “.bashrc”, we’ll be ready as soon as a working bash package gets finally built.

$ echo "alias ranger='python /usr/local/bin/ranger'" > .bashrc

Here’s a screenshot of ranger on N950. Just delicious, surely tastier than mangos.

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

One command to reveal such Skype lockfile-hogging processes is:

$ lsof .Skype/your-username-here/main.lock

If there is no way to cleanly shut them down, kill them and Skype should be able to login again.

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools