Puppylinux for the OLPC laptops: XOpup
RC looks great so far.
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
Love the wall paper!!! Thanks for all the hard work.
Regards, Ron
Re: RC looks great so far.
Hi Ron,rrolsbe wrote:I almost always use a USB mouse. Would be nice if the screen came out of power save when I move the external mouse.
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.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
XOpup-2.RC2 (xopup-201)
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...
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...
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
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:
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
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=''
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=''
Cheers
Puppy Linux Blog - contact me for access
I'm not sure is a bug or intentional by BK.01micko wrote: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:
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.
Well, you don't expect to see any "journal recovery" in vfat and ext201micko wrote: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
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
Yes but my savefiles are ext3 on both.. I'll format an ext3 stick and see what happensmavrothal wrote:
Well, you don't expect to see any "journal recovery" in vfat and ext2
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
Puppy Linux Blog - contact me for access
The savefile is OK. Is the save layer eg the actual device being SDcard or USB, that reports the "journal recovery"01micko wrote: Yes but my savefiles are ext3 on both... I'll format an ext3 stick and see what happens
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 though01micko wrote:In Puppeee my cards are always PUPMODE=13, same with spup on my EEE-701SD
Well, I actually like it like that! Is like a full install01micko wrote: 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.
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
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
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
may prevent clean shutdown. I changed it to
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.
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
Code: Select all
exec 1> /tmp/shutdownlog 2>&1
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
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
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
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
You can check the location of the xino file with
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
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.
Code: Select all
cat /sys/fs/aufs/si_*/xi_path
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.
No, xino is in temps (/initrd/pup_rw) and adding the code complains that xino "must be outside.." (and of console)jemimah wrote:You can check the location of the xino file withIf 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.Code: Select all
cat /sys/fs/aufs/si_*/xi_path
You can move the xino file withCode: Select all
busybox mount -o remount,xino=/tmp/xino -t aufs / /
This thing is driving nuts for a week now
Thanks for the suggestions.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
That's an OLPC-modified 2.6.35-kernel patched with Aufs 2.1-v20110110jemimah wrote:Hmm what kernel have you got? Mine will let me put the xino file whereever I want.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
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?...
`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?...
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
thanks for the info.jemimah wrote: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..
xino IS in pup_rw
However I remount it with
Code: Select all
busybox mount -o remount,xino=/tmp/xino -t aufs / /
In pupmode13 also the
Code: Select all
busybox mount -t $SAVEFS -o remount,ro $SAVEDEV /initrd${SAVE_LAYER}
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?
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
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).
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).
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.
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.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
XOpup-2.0 release
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==