Puppylinux for the OLPC laptops: XOpup

For talk and support relating specifically to Puppy derivatives
Post Reply
Message
Author
User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

XOpup-2.v3

#91 Post by mavrothal »

Just before the Holidays (you all have a happy one :D ) another development release of XOpup-2, XOpup-2.v3 (md5sum: 8faa52841fd596d1b266e2c8bd494863).
This one addresses an issue in XO-1 and ext2/3 formatted media (backwards compatibility of ext4 is not so good in puppy). Improves power management and networking and has some more cleanup and moving things to "extra_pets". See the change log for more.

Assuming that this gets some testing ( :roll: ) the next one could be the final.
The only thing I would like to improve is to get power management to work seamlessly in "aggressive" conditions, eg powering off CPU after 10-15 secs of inactivity. This should seriously improve battery life in normal use. Is almost there for the XO-1.5 but not the XO-1 yet.

As always any other input/suggestion is appreciated.
== [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] ==

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

XOpup-2 Release Candidate

#92 Post by mavrothal »

Image

The new version of XOpup-2 (xopup-200) has reached Release Candidate status :D

Download: XOpup-2.RC.tar.gz
md5sum: 2ea3773984a0dafd1736e13f0666e52d

The main changes compared to XOpup-1.0 are:
  • Moved to "xopup" SFS names instead of "lupu"
    Comparable support for XO-1 and XO-1.5
    New olpc-2.6.35-based kernels for both the XO-1 and the XO-1.5 (a new 2.6.31 kernel for the XO-1 is also provided)
    New XO-1.5 video driver
    XO camera support through the wxCam application
    Moving (not very much used) apps and functions out of the main SFS file to make room for "kids" apps. The main SFS is now only 92MB.
    Removed apps are now provided as pets in the "extra_pets" folder included in the download.
    External monitor/projector, firewall and bluetooth support
    Improvements in savefile handling
    Better power management
    Updated XO-version-specific Quickpet and PPM repo data
    New background (to distinguish the builds :-) )
See the build announcement and change log for more info.
== [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] ==

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#93 Post by 01micko »

Downloading now, more or less for a sanity check :wink:

Cheers :D
Puppy Linux Blog - contact me for access

rrolsbe
Posts: 185
Joined: Wed 15 Nov 2006, 21:53

Thanks, I will give the RC a go

#94 Post by rrolsbe »

Since very few people participate in this thread, I hope lots of people are at least downloading the Puppy for XO iso and trying it out. I have been recently browsing using a WPA2 wireless encrypted connection on my XO-1.0. Maybe it's just me but it seems a lot slower than connecting directly via a wired connection? I have been reading about the new XO-1.75 OLPC's based on an ARM processor and discussions about porting Puppy to the ARM processor camp. Since Redhat has ported some portion of Linux code base to the ARM based XO, how hard would it be to port Puppy to the new ARM based XO-1.75? Since it appears the the mother board in the new XO-1.75 is the only big change, maybe they will sell the motherboard using the ARM to allow upgrading existing XO-1.0/1.5 owners (YEAH RIGHT!!!!).

Keep up the great work and I thank the both of you for your efforts.

Regards, Ron

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#95 Post by mavrothal »

Hi Ron,
Unfortunately, my hosting server does not provide download stats so I do not really know if 10s, 100s or 1000s have downloaded XOpup :cry: .
Forum wisdom says that about 1% provides feed back so we have to hope for that in this case too...

Regarding ARM, Debian/Ubuntu already run on it and the Fedora12/13 port is almost finished. So (last famous words...) should not be too difficult to get puppy going as soon as the XO-spesific kernels are out.

The real problem is, if the machines will be available outside deployments. At least with the XO-1.5 that is only available to deployments and developers, I have the sense that I'm the only one that uses puppy on this hardware... :roll:
So unless XO-1.75s become freely available, I hardly see the need/opportunity for puppy (or any other distro) on this hardware.
== [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] ==

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

xopup-200 update-1

#96 Post by mavrothal »

This a small xopup-200 update with a couple of additions and fixes.
xopup_200_update-1.pet has zigbert's resizable PPM UI and fixes the PPM-configure layout (01micko). Also includes an addition to quickpet to directly download the xopup_devx_200.sfs (01micko). Finally fixes the time-change-after-reboots issue on the XO-1 (pls report on this one).
== [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] ==

User avatar
l2ulinux
Posts: 140
Joined: Tue 25 Jan 2011, 13:40
Location: Blountstown, Fl.

LiveCD

#97 Post by l2ulinux »

Can you build a livecd to try with other systems. Please Help

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

Re: LiveCD

#98 Post by mavrothal »

l2ulinux wrote:Can you build a livecd to try with other systems. Please Help
XOpup runs olny on the OLPC XO-1 and XO-1.5 hardware (that do not have a CD drive).

For other hardware just use one of the official puppies and/or pupplets
== [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] ==

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

Any help on using the OpenMESH idea in other hardware

#99 Post by Ted Dog »

I would love to get my hands on one of those to play with, but I really would like to use puppylinux to setup a network like the normal OLPC hardware does.

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

Re: Any help on using the OpenMESH idea in other hardware

#100 Post by mavrothal »

Ted Dog wrote:I would love to get my hands on one of those to play with
For an XO-1, try eBay or the Contributors program
Ted Dog wrote: but I really would like to use puppylinux to setup a network like the normal OLPC hardware does.
??? :?
You mean "mesh" or "ad-hoc", other?
== [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] ==

rrolsbe
Posts: 185
Joined: Wed 15 Nov 2006, 21:53

RC looks great so far.

#101 Post by 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

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

Re: RC looks great so far.

#102 Post by mavrothal »

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.
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 :oops: .

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] ==

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

XOpup-2.RC2 (xopup-201)

#103 Post by mavrothal »

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

Image

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... :D
== [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] ==

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#104 Post by 01micko »

I've come across a strange bug.

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

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
Puppy Linux Blog - contact me for access

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#105 Post by mavrothal »

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 :shock:

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. :?

01micko 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
Well, you don't expect to see any "journal recovery" in vfat and ext2 :wink:
== [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] ==

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#106 Post by 01micko »

mavrothal wrote:
Well, you don't expect to see any "journal recovery" in vfat and ext2 :wink:
Yes but my savefiles are ext3 on both.. I'll format an ext3 stick and see what happens :wink:

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

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#107 Post by mavrothal »

01micko wrote: Yes but my savefiles are ext3 on both... I'll format an ext3 stick and see what happens :wink:
The savefile is OK. Is the save layer eg the actual device being SDcard or USB, that reports the "journal recovery"
01micko wrote: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 :D
01micko 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.
Well, I actually like it like that! Is like a full install :D
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] ==

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#108 Post by 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

User avatar
mavrothal
Posts: 3096
Joined: Mon 24 Aug 2009, 18:23

#109 Post by 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 :?:
== [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] ==

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#110 Post by 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.

Post Reply