Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 23 Feb 2020, 10:29
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Derivatives
Puppylinux for the OLPC laptops: XOpup
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 8 of 21 [313 Posts]   Goto page: Previous 1, 2, 3, ..., 6, 7, 8, 9, 10, ..., 19, 20, 21 Next
Author Message
01micko


Joined: 11 Oct 2008
Posts: 8745
Location: qld

PostPosted: Sun 13 Feb 2011, 03:04    Post subject:  

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
Back to top
View user's profile Send private message Visit poster's website 
mavrothal


Joined: 24 Aug 2009
Posts: 3107

PostPosted: Sun 13 Feb 2011, 03:20    Post subject:  

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 Very Happy

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 Very Happy
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

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Tue 15 Feb 2011, 14:33    Post subject:  

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:
exec 1> /dev/null 2>&1


may prevent clean shutdown. I changed it to

Code:
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:
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
Back to top
View user's profile Send private message Visit poster's website 
mavrothal


Joined: 24 Aug 2009
Posts: 3107

PostPosted: Tue 15 Feb 2011, 15:28    Post subject:  

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 Question

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Tue 15 Feb 2011, 17:03    Post subject:  

You can check the location of the xino file with
Code:
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:
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.
Back to top
View user's profile Send private message Visit poster's website 
mavrothal


Joined: 24 Aug 2009
Posts: 3107

PostPosted: Tue 15 Feb 2011, 17:29    Post subject:  

jemimah wrote:
You can check the location of the xino file with
Code:
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:
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 Twisted Evil

Thanks for the suggestions.

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Tue 15 Feb 2011, 18:00    Post subject:  

Hmm what kernel have you got? Mine will let me put the xino file whereever I want.
Back to top
View user's profile Send private message Visit poster's website 
mavrothal


Joined: 24 Aug 2009
Posts: 3107

PostPosted: Tue 15 Feb 2011, 18:09    Post subject:  

jemimah wrote:
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

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Tue 15 Feb 2011, 18:42    Post subject:  

Yeah that's recent enough. It should work pretty much the same as my kernel.
Back to top
View user's profile Send private message Visit poster's website 
mavrothal


Joined: 24 Aug 2009
Posts: 3107

PostPosted: Thu 17 Feb 2011, 13:34    Post subject:  

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. Evil or Very Mad

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

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Thu 17 Feb 2011, 14:01    Post subject:  

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.
Back to top
View user's profile Send private message Visit poster's website 
mavrothal


Joined: 24 Aug 2009
Posts: 3107

PostPosted: Thu 17 Feb 2011, 16:11    Post subject:  

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


thanks for the info.
xino IS in pup_rw
However I remount it with
Code:
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:
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. Question

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

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Thu 17 Feb 2011, 20:25    Post subject:  

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).
Back to top
View user's profile Send private message Visit poster's website 
mavrothal


Joined: 24 Aug 2009
Posts: 3107

PostPosted: Fri 18 Feb 2011, 02:36    Post subject:  

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.

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
mavrothal


Joined: 24 Aug 2009
Posts: 3107

PostPosted: Sat 19 Feb 2011, 04:41    Post subject: XOpup-2.0 release  

That's it puppians Laughing

XOpup-2.0 is released




(also checkout the top post of this thread)

_________________
== Here is how to solve your Linux problems fast ==
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 8 of 21 [313 Posts]   Goto page: Previous 1, 2, 3, ..., 6, 7, 8, 9, 10, ..., 19, 20, 21 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Derivatives
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0732s ][ Queries: 12 (0.0225s) ][ GZIP on ]