Puppylinux for the OLPC laptops: XOpup

[rrolsbe]

I almost always use a USB mouse. Would be nice if the screen came out of power save when I move the external mouse.

Love the wall paper!!! Thanks for all the hard work.

Regards, Ron

[mavrothal]

I almost always use a USB mouse. Would be nice if the screen came out of power save when I move the external mouse.

Hi Ron,
I was busy with other things (see below) thus the delayed response.

I'm afraid this is not going to happen soon . It requires the full HAL and freedesktop xkb compatibility and their inclusion will make the build several MB bigger, not to mention I'm not sure it will work .

I would guess for now, just change the dim timing to something less intrusive. Type "powerd-config" and after you change it type "powerd-config =restart" to take immediate effect.

[mavrothal]

The second release candidate build of XOpup-2 (xopup-201) has landed.



It has a number of under-the-hood, changes and updates (see the change log).
The new things for the user are:

The addition of Openbox/Fbpanel window manager as the default WM (01micko). Openbox is much more user friendly and feature-full than JWM (and thus a bit slower) and importantly, screen-rotation aware.
You can switch back and forth the 2 WM with the new switch desktop utility.

Implementation of screen rotation for both the XO-1 and XO-1.5, either with rotation button or with the new, rotate screen, menu entry. Rotation 90 or 270 degrees has a little bug in the touchpad rotation. The cursor freezes and to revive it you must have a(ny) keyboard key pressed. Even a dead key like the "journal" or the "double rectangle" key. An external USB mouse is OK though. I find it is still usable as a book reader since in this mode you do/can not use the touchpad anyway.

Inclusion of shinobar's "fsf_load on the fly" utility that I think is extremely useful, particularly for a limited resources machine like the XO-1.

Download and install XOpup-2.RC2.tar.gz (md5sum: a75e3c00dfbe3f4fb6cbed8143a6b577). If you already using xopup-200 should/will auto-update your installation so you can keep the same savefile.

Have fun and please report any issues so we can get to XOpup-2 "final"

PS: Hmm, looking at the picture, I should probably change home.html a bit...

[01micko]

I've come across a strange bug.

On my SD card in the XO-1 my savefile is said to be PUPMODE=12

I am not saving to a fast partition so the only possible pupmodes should be 6 or 13.

Code: Select all

# cat /etc/rc.d/PUPSTATE
PUPMODE=12
PDEV1='mmcblk0p1'
DEV1FS='vfat'
PUPSFS='mmcblk0p1,vfat,/xopup-201.sfs'
PUPSAVE='mmcblk0p1,vfat,/xopupsave-xotest.3fs'
PMEDIA=''
#v3.97: kernel with libata pata has both sata and pata drives in ATADRIVES...
ATADRIVES=''
#these directories are unionfs layers in /initrd...
SAVE_LAYER='/pup_rw'
PUP_LAYER='/pup_ro2'
#The partition that has the xopupsave file is mounted here...
PUP_HOME='/mnt/dev_save'
#(in /initrd) ...note, /mnt/home is a link to it.
#this file has extra kernel drivers and firmware...
ZDRV=''
#complete set of modules in the initrd (moved to main f.s.)...
ZDRVINIT='yes'
PSWAPFILE='mmcblk0p1,vfat,/pupswap.swp'
PSAVEMARK=''
FASTPARTS=''

On my usb drive it is ok:

Code: Select all

# cat /etc/rc.d/PUPSTATE
PUPMODE=13
PDEV1='sda1'
DEV1FS='ext2'
PUPSFS='sda1,ext2,/xopup-201.sfs'
PUPSAVE='sda1,ext2,/xopupsave-xousb.3fs'
PMEDIA=''
#v3.97: kernel with libata pata has both sata and pata drives in ATADRIVES...
ATADRIVES=''
#these directories are unionfs layers in /initrd...
SAVE_LAYER='/pup_ro1'
PUP_LAYER='/pup_ro2'
#The partition that has the xopupsave file is mounted here...
PUP_HOME='/mnt/dev_save'
#(in /initrd) ...note, /mnt/home is a link to it.
#this file has extra kernel drivers and firmware...
ZDRV=''
#complete set of modules in the initrd (moved to main f.s.)...
ZDRVINIT='yes'
PSWAPFILE='sda1,ext2,/pupswap.swp'
PSAVEMARK=''
FASTPARTS=''

Note that with both they are unmounted cleanly at shutdown. I wonder if some of these issues are medium specific? Or even filesystem specific. Note my SD card is formatted FAT32 and the usb drive ext2.

Cheers

[mavrothal]

I've come across a strange bug.

On my SD card in the XO-1 my savefile is said to be PUPMODE=12

I am not saving to a fast partition so the only possible pupmodes should be 6 or 13.
On my usb drive it is ok:

I'm not sure is a bug or intentional by BK.
The SDcard is correctly recognized as "slowparts" in the init, however when it looks for "removable", it only looks into "/sys/block/sda". For cards the script points "/sys/block/mmc" and the cards are "mmcblk0" ,1 ,2 etc so does not see them as removable. This is actually nice since you avoid the long shutdown times (though jamesbond's latest -s16 - snapmergepuppy does wonders on that) and everything is saved on the card immediately.

You can easily change that by adding "pmedia=usbflash" in the command line arguments of /boot/olpc.fth and then SDcards are showing as "7" and "13"

However this does not change the lasy (non-clean) umount of the save layer.

Note that with both they are unmounted cleanly at shutdown. I wonder if some of these issues are medium specific? Or even filesystem specific. Note my SD card is formatted FAT32 and the usb drive ext2.
Cheers

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

[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)