Puppylinux for the OLPC laptops: XOpup

[01micko]

Well, you don't expect to see any "journal recovery" in vfat and ext2

Yes but my savefiles are ext3 on both.. I'll format an ext3 stick and see what happens

I notice that BK has done some work with cardreaders in January, I'll wait til he brings out the next woof to see what the exact changes are. In Puppeee my cards are always PUPMODE=13, same with spup on my EEE-701SD, so I'm not too sure about what is the intended behaviour!

Of course there is an advantage of the system writing to disk all changes immediately at the cost of drive life I guess.

Jemimah's and jamesbond's work with the snapmerge is intriguing, and does indeed improve the shutdown speed of the usb stick.

Cheers

[mavrothal]

Yes but my savefiles are ext3 on both... I'll format an ext3 stick and see what happens

The savefile is OK. Is the save layer eg the actual device being SDcard or USB, that reports the "journal recovery"

In Puppeee my cards are always PUPMODE=13, same with spup on my EEE-701SD

Please check with puppeee and an ext3 formatted card. Just look after the "looking for puppy files". It may be too fast even to notice though

I'm not too sure about what is the intended behaviour!

Of course there is an advantage of the system writing to disk all changes immediately at the cost of drive life I guess.

Well, I actually like it like that! Is like a full install
And if you want you can speed up things a bit by adding "pfix=copy" in the command line arguments so the main sfs is loaded in the RAM.
Is good in the XO-1.5 but I'm not so sure about the XO-1

[jemimah]

After seeing your post I checked Fluppy and indeed it was not shutting down clean anymore either.

Here's how I fixed it.

First make sure that every process that is started from rc.services is killed before shutdown. You may need to add a long sleep in the shutdown script before the lazy unmount so you can log in on the other console and run ps. Particularly I had trouble with pup_event_backend_modprobe_protect not being shutdown.

Then be aware that /dev/null may actually exist in the save file. So the command

Code: Select all

exec 1> /dev/null 2>&1

may prevent clean shutdown. I changed it to

Code: Select all

exec 1> /tmp/shutdownlog 2>&1

Then I modifed the xino code, which apparently wasn't working either. This version is simpler anyway, Note that you must not redirect the remount command to /dev/null.

Code: Select all

if [ "$SAVE_LAYER" ];then
 sync
 SAVEDEV="`mount | grep "/initrd${SAVE_LAYER}" | cut -f 1 -d ' '`"
 SAVEFS="`mount | grep "/initrd${SAVE_LAYER}" | cut -f 5 -d ' '`"
 #100615 Patriot: suggested this code to enable save-layer to remount ro...
 uniFS=$(awk '/unionfs/ {print $3}' /proc/mounts) #ex: aufs
 if [ "$uniFS" == "aufs" -a "$SAVE_LAYER" == "/pup_rw" ]; then
  if [ "`mount | grep '^tmpfs on /tmp '`" != "" ];then #created in initrd.
   busybox mount -o remount,noxino -t $uniFS / /
   sync
  fi
 fi
 busybox mount -t $SAVEFS -o remount,ro $SAVEDEV /initrd${SAVE_LAYER} 
 umount-FULL -i -n -l /initrd${SAVE_LAYER} 2>/dev/null #-l is lazy unmount.
fi

[mavrothal]

Thank you jemimah,
indeed pup_event_backend_modprobe_protect, dhcpcd and the lo interface where not coming down so I had killed them already. Also added some sleep time and tried to umount the loop devices first, none of which had any effect.
Unfortunately adding your xino code did not solve the issue in XOpup either. I was wondering if the other 2>/dev/null commands scattered throughout rc.shutdown should also be changed...
Well, I guess I'll try...

PS: Is "/bin/busybox init" suppose to run at shutdown

[jemimah]

You can check the location of the xino file with

Code: Select all

cat /sys/fs/aufs/si_*/xi_path

If you get a path back that's inside the save file - then it's the xino file that's keeping you from remounting the save file read-only.

You can move the xino file with

Code: Select all

busybox mount -o remount,xino=/tmp/xino -t aufs / /

AFAIK the loop device for the save file can not be unmounted - you probably shouldn't waste much time trying to mess with the AUFS union.

The other redirects shouldn't matter because they will have closed /dev/null by the time you get to the remount.

[mavrothal]

You can check the location of the xino file with

Code: Select all

cat /sys/fs/aufs/si_*/xi_path

If you get a path back that's inside the save file - then it's the xino file that's keeping you from remounting the save file read-only.

You can move the xino file with

Code: Select all

busybox mount -o remount,xino=/tmp/xino -t aufs / /

No, xino is in temps (/initrd/pup_rw) and adding the code complains that xino "must be outside.." (and of console)

This thing is driving nuts for a week now

Thanks for the suggestions.

[jemimah]

Hmm what kernel have you got? Mine will let me put the xino file whereever I want.

[mavrothal]

Hmm what kernel have you got? Mine will let me put the xino file whereever I want.

That's an OLPC-modified 2.6.35-kernel patched with Aufs 2.1-v20110110

[jemimah]

Yeah that's recent enough. It should work pretty much the same as my kernel.

[mavrothal]

Still trying with this harmless but annoying bug.
`ps' shows no applications using files in the save layer
`lsof' the same.
As extra test `lsof -x +D /<save_layer>' also sees no files used.
Yet the bug is there.

One thing is that is not doing it if you are in PUPMODE=5 eg at the first reboot. So looks like either the savefile or the pupmode is important. I would think the pupmode since it has the same problem if you save to the entire partition.
Any clues anyone?...

[jemimah]

The xino file is an invisible file that lsof and ps won't find. You need to check /sys/fs/aufs/si_*/xi_path to see where it is. If it's in the pup_rw, that's your culprit.

In pupmode=5 the save file is not part of the union, it's quite easy to umount then.

[mavrothal]

The xino file is an invisible file that lsof and ps won't find. You need to check /sys/fs/aufs/si_*/xi_path to see where it is. If it's in the pup_rw, that's your culprit..

thanks for the info.
xino IS in pup_rw
However I remount it with

Code: Select all

busybox mount -o remount,xino=/tmp/xino -t aufs / /

as you suggested and remounts without errors (now that I remove a stale file)
In pupmode13 also the

Code: Select all

busybox mount -t $SAVEFS -o remount,ro $SAVEDEV /initrd${SAVE_LAYER}

goes without errors but that's the save file. The boot device mounted in /initrd/mnt/dev_save still has errors.
In pupmode 6 where the savelayer is also the boot device mounted in /initrd/pup_rw this step still fails with "device is busy" even if the xino remount reports no problems.

You mentioned before that you can have the `.aufs.xino' mounted elsewhere. How do you do that?

[jemimah]

Yes you won't be able to unmount the boot partition unless you can get the save file out of the union. The shutdown script fixes won't fix that. They will only get the save file clean.

Patriot's thread explains how he got the boot partition to unmount, but it didn't work for me,

(You did successfully move the xino file; that's all I know so far about it).

[mavrothal]

Hmmm
The file system is clean in all cases, is the journal on the boot device that stays open in shutdown and is recovered in every boot.
I don't think that Patriot (or anybody else) looked at it.
If the loops for example are never umounted, even if they are read-only and do not have problems themselves, their "open" bit in the journal of the boot device will stay.
Maybe the Aufs mailing list is the place to ask.

[mavrothal]

That's it puppians

XOpup-2.0 is released




(also checkout the top post of this thread)

[mavrothal]

Has anybody tried XOpup is Spanish?
How bad is it?

Spanish is by far the dominant language among XO users so I would like to know what is needed to make it more Spanish-friendly.

If you can help with translations, even better .
Thx

[Mark S.]

My daughter has an XO 1 from the 2007 first batch. I just installed the firmware "fix" http://blog.laptop.org/2011/01/08/keybo ... e-and-fix/ apparently required starting in January 2011 that allows the keyboard and mouse to continue working. Now the firmware is given as

Q2D14

When I try to install the XOpup-2 linux, I get the following error(s):

<buffer@800000>:6: fw-version$ ?
<buffer@800000>:126: Undefined word encountered

So, is this a firmware version problem? The docs say that if there is a firmware mismatch, you'll get a message, but this seems more like an error.

Will installing q2e45 take care of this problem ... and will that firmware allow the keyboard/mouse to continue working?

Thanks!
Mark

[Mark S.]

Will installing q2e45 take care of this problem ... and will that firmware allow the keyboard/mouse to continue working?

In a burst of impatience we went ahead and upgraded the firmware -- making it twice in one day! Then we installed the XOpup.

My daughter is very pleased! She's impressed at how cool the opening page for puppy-xo looks -- says its better than the original pupplinux which I run on my netbook.

Sound, flash, club penguin, and Opera work, she reports. The screen "dims" too quickly for her taste, but I've read the post on the work around and hope to try a longer interval.

The biggest problem so far is that we get periodic "kill process" requests. Apparently the OLPC is in constant danger of running out of RAM. I'm thinking of putting a swapfile on the usb and see if that helps. Is there anything I should be aware of? Will this work? I see the OP says we won't be able to save on our vfat formatted boot stick. Does that mean I won't be able to put a swap file on there either?

Thanks for a great job putting puppy on the XO!

Mark

[mavrothal]

Q2D14

When I try to install the XOpup-2 linux, I get the following error(s):

<buffer@800000>:6: fw-version$ ?
<buffer@800000>:126: Undefined word encountered

XOpup's OFW will usually give a warning that you need to update your firmware to at least q2e45 but q2d14 is too old even for this warning to appear.
Is a good idea to update to the latest firmware in general. It only gets better with every new version and through 20-some updates that I can remember, only one had a regression problem that was quickly fixed.
But you know all these by now I guess

My daughter is very pleased! She's impressed at how cool the opening page for puppy-xo looks -- says its better than the original pupplinux which I run on my netbook.

It was a strong family battle among the 3 backgrounds but I'm partial to blue ones. My son preferred the mantis while his younger friend the trampoline. My wife cast the crucial vote, mostly as a better "fit for all"

The biggest problem so far is that we get periodic "kill process" requests. Apparently the OLPC is in constant danger of running out of RAM. I'm thinking of putting a swapfile on the usb and see if that helps. Is there anything I should be aware of? Will this work? I see the OP says we won't be able to save on our vfat formatted boot stick. Does that mean I won't be able to put a swap file on there either?

I believe that you can have a swap file on the vfat partition. You probably tried it already by now If not, just run "mkswap-file.sh" in the terminal. When it finishes either reboot or type "swapon -a /mnt/home/pupswap.swp"

You could have the warning removed by moving freeramdaemon.sh out of the /root/Startup folder, but I certainly do not recommend it since you are going to run into trouble fast without swap. Specially if you have more than a couple of apps open or browse "heavy" pages.

[mavrothal]

This is a first attempt for a Spanish language pack for XOpup-2
Is based on Shinobar's lang_pack_es-lupq-0.2.pet, don570's Espagnol-Right-click-4.5.pet, unambihuo's translations of several packages and ... Google translate

The file is not working as a pet yet ( ), so to install download the XOpup2_lang_pack_es-0.1.tar.gz file (md5sum:8337e11322f06767bd900dca3af2270d) in your XO and then

Code: Select all

cd /
tar xvzf /path_to_file/XOpup2_lang_pack_es-0.1.tar.gz

reboot your XO and you should be looking to something like this



The JWM window manager is also localized in a similar manner

If you want to see which are the files and hopefully improve them, just cd to an empty folder and extract the tarball in there.

I do not speak any Spanish so I can not really tell how bad is it Ideally a Spanish native speaker should take over this package and maybe open another thread in Spanish.

I intend to include a more "mature" version in the next XOpup's "extra_pets" folder and I would be happy to provide hosting to such a more "mature" version.

Edit: To make installation easier I made a new version (with the same data) that includes an install script. Just download the file click to extract it and click "Instalar" ( ) to install it.
Here it is http://www.datafilehost.com/download-db3b348d.html
(md5sum: 4a7ed094b948b8f8ffd6ea011880f867)