Page 1 of 2

[SOLVED] The "old" save.dat problem

Posted: 28 Jul 2012, 18:28
by steve123
Hi porteus community,

let me present to you, I'm not a newbie on Linux (openSuse on desktop since 4 years and happy to be on Linux) but newbie on porteus. I discover the possibility to have an OS on a mini usb-stick and I am enthusiastic about that!

I like the porteus distrib for its capability to run in the RAM memory, its very fast on my laptop (and more rich than puppy).

On my laptop runs windows 7 and I would like to be able to read & write the usb-stick on windows and linux, so I prefer to stay with the FAT32 formatation. Problem: in this constellation the porteus stick does not keep the changements, although I followed striktly the documentation, saved the .dat file in /dev/sdb1/something/save-steve.dat and updated the lines in the /boot/porteus.cfg file, but it doesn't work. All changes are lost after every new boot.

By the way, I installed porteus with the windows utility Universal USB Installer.

Now I'll try the following steps: Reformat the usb-stick on win 7, burn the porteus.iso file on a CD and make the usb-install from the live-CD, so with the "original" porteus utility, perhaps this works better ? In the first time I'll try to stay with Fat32 on the stick. Perhaps you can help me in the case of persisting problem.

In a second time I would like to be able to save the changes also in the copy2ram case, I'm not sure what to write (and where) in the porteus.cfg file, but one step at a time... :)

Thank you.

Re: The "old" save.dat problem

Posted: 28 Jul 2012, 19:19
by fanthom
hello steve123,

1) please open terminal and run following command:

Code: Select all

realpath /mnt/sdXY/path_to/save.dat
please show me what you get.

2) pls also show me:

Code: Select all

cat /proc/cmdline
3) and:

Code: Select all

grep -A1 Changes /var/log/porteus-livedbg
thanks

Re: The "old" save.dat problem

Posted: 28 Jul 2012, 22:03
by steve123
Hello fanthom,

thank you for your answer.

I get the following outputs:

Code: Select all

realpath /mnt/sdb1/savef/porteussave-lap1.dat
/mnt/sdb1/savef/porteussave-lap1.dat

cat /proc/cmdline
root=/dev/ram0 rootfstype=ext4 rw initrd=/boot/initrd.xz vga=791 xfce autoexec=xf-compositing~off changes=/mnt/sdb1/savef/porteussave-lap1.dat BOOT_IMAGE=/boot/vmlinuz 

grep -A1 Changes /var/log/porteus-livedbg
Changes are stored in 
/mnt/sdb1/savef/porteussave-lap1.dat
I run the commands as "guest", was that ok ?

When booting I read on the screen something like
"testing save-file....
porteussave-lap1.dat ok"
...
Here's the code for the second boot choice in porteus.cfg :

Code: Select all

LABEL no-compositing 
MENU LABEL XFCE--no compositing 
KERNEL /boot/vmlinuz
APPEND initrd=/boot/initrd.xz vga=791 xfce autoexec=xf-compositing~off changes=/mnt/sdb1/savef/porteussave-lap1.dat
TEXT HELP
    Run Porteus the same as above.
    compositing will be turned off
    which will disable transparency
    and shadow effects.
ENDTEXT
P.S.

I can add something. What kind of changes do I do ?
  • The keyboard country. I have a french keyboard and after boot it comes back as US-keyboard, so it is hard to write. I have to reconfigure to french keyboard.
  • I install some add-ons in Firefox, but after new boot they are gone.
  • I replace the background image on desktop with a unified color and desktop comes back with its original background image.
  • I create a test file I store on desktop. The testfile is gone after new boot.
But there are some things which stay :
  • The connection to my (wpa-key protected) wlan.
    After every boot I have wlan connection to internet.
  • I installed gimp and gimp stays installed.
Hope the informations help you to help me.

Re: The "old" save.dat problem

Posted: 29 Jul 2012, 02:04
by Ahau
Short on time, so I haven't tested, will post more tonight.

Gimp and wifi settings stay because they are modules, not installed to your save.dat. Try cheatcode 'kmap=fr' for french keyboard, and (on a hunch here) if you are running copy2ram, try also adding 'noeject'. Please run fanthom's command to grep livedbg, this will show us for sure whether your save.dat was mounted during startup.

Re: The "old" save.dat problem

Posted: 29 Jul 2012, 05:11
by steve123
Hello Ahau,
Please run fanthom's command to grep livedbg, this will show us for sure whether your save.dat was mounted during startup.
I did it, its in the first 'Code window'.
Thank you for the hints.

Re: The "old" save.dat problem

Posted: 29 Jul 2012, 06:35
by Ahau
Very odd...

Sorry for asking you to repeat yourself. I was viewing on my phone earlier and the browser didn't render the page properly.

A couple more commands to gather information on this...please give us the output of:

Code: Select all

losetup -a
cat /proc/mounts
When I run those with a save.dat active, I get:
/dev/loop0: [0812]:9325 (/mnt/sdb2/IMG32/porteussave.dat)
(first entry in losetup -a)
/dev/loop0 /mnt/live/memory xfs rw,relatime,attr2,noquota 0 0
(first loop device in /proc/mounts)

Re: The "old" save.dat problem

Posted: 29 Jul 2012, 15:48
by steve123
Hello Ahau,
Sorry for asking you to repeat yourself.
no problem. When I'm in hurry sometimes I don't find my feets...

As "guest", I had to change to /sbin to execute losetup, in guest home the command was not found.

Code: Select all

guest@porteus:~$ losetup -a
/dev/loop0: [0811]:5 (/mnt/sdb1/savef/porteussave-lap1.dat)
... and further lines with modules I installed.
This seems ok for me because the porteussave-lap1.dat is there.

But after "cat /proc/mounts" there is no porteussave-lap1.dat !
Perhaps this is a problem ?

Code: Select all

guest@porteus:~$ cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root /mnt/live ext4 rw,relatime 0 0
proc /mnt/live/proc proc rw,relatime 0 0
none /mnt/live/dev devtmpfs rw,relatime,size=1508444k,nr_inodes=377111,mode=755 0 0
/dev/sdb1 /mnt/live/mnt/sdb1 vfat rw,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=utf8,shortname=mixed,check=s,quiet,errors=remount-ro 0 0
/dev/loop0 /mnt/live/memory ext4 rw,relatime,data=ordered 0 0
tmpfs /mnt/live/memory/xino tmpfs rw,relatime 0 0
aufs / aufs rw,relatime,si=e811c6d9761c615,nowarn_perm 0 0
/dev/loop1 /mnt/live/memory/images/000-kernel.xzm squashfs ro,relatime 0 0
/dev/loop2 /mnt/live/memory/images/001-core.xzm squashfs ro,relatime 0 0
/dev/loop3 /mnt/live/memory/images/002-xorg.xzm squashfs ro,relatime 0 0
/dev/loop4 /mnt/live/memory/images/005-devel.xzm squashfs ro,relatime 0 0
/dev/loop5 /mnt/live/memory/images/006-firefox.xzm squashfs ro,relatime 0 0
/dev/loop6 /mnt/live/memory/images/0090-xfce.xzm squashfs ro,relatime 0 0
/dev/loop7 /mnt/live/memory/images/0091-xfce-apps.xzm squashfs ro,relatime 0 0
/dev/loop8 /mnt/live/memory/images/aalib-1.4rc5-x86_64-3.xzm squashfs ro,relatime 0 0
/dev/loop9 /mnt/live/memory/images/babl-0.1.2-x86_64-1.xzm squashfs ro,relatime 0 0
/dev/loop10 /mnt/live/memory/images/gegl-0.1.2-x86_64-1.xzm squashfs ro,relatime 0 0
/dev/loop11 /mnt/live/memory/images/gimp-2.6.11-x86_64-3.xzm squashfs ro,relatime 0 0
/dev/loop12 /mnt/live/memory/images/hal-0.5.14-x86_64-3.xzm squashfs ro,relatime 0 0
/dev/loop13 /mnt/live/memory/images/ilmbase-1.0.2-x86_64-1.xzm squashfs ro,relatime 0 0
/dev/loop14 /mnt/live/memory/images/openexr-1.7.0-x86_64-1.xzm squashfs ro,relatime 0 0
/dev/loop15 /mnt/live/memory/images/pns-setup-config.xzm squashfs ro,relatime 0 0
/dev/loop16 /mnt/live/memory/images/ppm-debian-files-1.1-noarch-1.xzm squashfs ro,relatime 0 0
/dev/loop17 /mnt/live/memory/images/ppm-salix-index-1.1-noarch-1.xzm squashfs ro,relatime 0 0
/dev/loop18 /mnt/live/memory/images/psc-settings.xzm squashfs ro,relatime 0 0
/dev/sdb1 /boot vfat rw,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=utf8,shortname=mixed,check=s,quiet,errors=remount-ro 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
devtmpfs /dev devtmpfs rw,relatime,size=1508444k,nr_inodes=377111,mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
/dev/sda2 /mnt/sda2 fuseblk rw,noatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0
/dev/sda3 /mnt/sda3 fuseblk rw,noatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0
/dev/sda4 /mnt/sda4 fuseblk rw,noatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0
/dev/sda5 /mnt/sda5 fuseblk rw,noatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0
/dev/sdb1 /mnt/sdb1 vfat rw,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=utf8,shortname=mixed,check=s,quiet,errors=remount-ro 0 0
gvfs-fuse-daemon /home/guest/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0

Re: The "old" save.dat problem

Posted: 29 Jul 2012, 17:28
by fanthom
hi steve123,
grep -A1 Changes /var/log/porteus-livedbg
Changes are stored in
/mnt/sdb1/savef/porteussave-lap1.dat
if porteus-livedbg says that you are saving changes than more than likely you are :wink:
But after "cat /proc/mounts" there is no porteussave-lap1.dat !
yes it's there.
porteussave-lap1.dat is attached on loop0 and loop0 is mounted on /mnt/live/memory. this is where aufs writable branch sits.

Code: Select all

/dev/loop0 /mnt/live/memory ext4 rw,relatime,data=ordered 0 0
that line tells me that your porteussave-lap1.dat is formatted with ext4 filesystem. is that correct?

please do a short test and run following command:

Code: Select all

touch /home/guest/Desktop/savedat-test
if that file survives the reboot then everything is ok.

Re: The "old" save.dat problem

Posted: 29 Jul 2012, 17:47
by steve123
Hi fanthom,
that line tells me that your porteussave-lap1.dat is formatted with ext4 filesystem. is that correct?
I don't remember exactly, I formatet either ext3 or ext4, one of the both, so I suppose that I formated ext4.

I'm not shure if I understand well what you asking me.
please do a short test and run following command:
  • touch /home/guest/Desktop/savedat-test
Do you ask me to create a testfile named savedat-test and store it on the desktop ?
"touch" makes the timestamp update to "now".

After reboot, do you want to know if the file savedat-test is still there, or do you presume it will be there and you want to know if the timestamp has changed ? I'm somehow confused.

I can tell you right now that a every file created and stored on the desktop has vanished after reboot.

Re: The "old" save.dat problem

Posted: 29 Jul 2012, 18:26
by fanthom
"touch" makes the timestamp update to "now".
yes - but it also creates a new file if one does not exist.
do you want to know if the file savedat-test is still there
yes
I can tell you right now that a every file created and stored on the desktop has vanished after reboot.
this is pretty weird as i have just tested save.dat on Xfce edition and all is ok here.

any chance you could zip your porteussave-lap1.dat (should be few KB only after zipping) and upload somewhere so i could check it on my PC?
if not then please connect to the internet and then run:

Code: Select all

wgetpaste -s ca /var/log/messages
and post the result here.

thanks

Re: The "old" save.dat problem

Posted: 29 Jul 2012, 19:06
by steve123
Thanks for your offer.

My file has 400Mo, after zipping it has only 2,6Mo. The save.dat file seems to store only the diff from the first install (only the changes ?).

Here it is :

http://205.196.123.187/95ab7cnikizg/tfi ... eve123.zip

(directlink to the file on mediafire)

If all is allright, could "the error" be myself, that is to say a user manipulation error ?
When I log out I mark with a x to save the session. Should be ok. Really strange.

Re: The "old" save.dat problem

Posted: 29 Jul 2012, 20:12
by fanthom
i have unpacked your zip archive then mounted your save.dat in /mnt/loop folder using 'mloop' utility:

Code: Select all

mloop porteussave-lap1.dat
all files were listed correctly:

Code: Select all

root@porteus:/# ls -1 /mnt/loop/
changes/
copy2ram/
images/
lost+found/
xino/
root@porteus:/#
which means you were saving changes at least during last boot.

here is a proof:

Code: Select all

root@porteus:/# grep shutdown /mnt/loop/changes/var/log/messages 
Jul 28 06:01:50 (none) shutdown[4076]: shutting down for system halt
Jul 28 06:03:34 (none) shutdown[4031]: shutting down for system halt
Jul 28 23:43:29 (none) shutdown[4939]: shutting down for system halt
Jul 29 00:07:29 porteus shutdown[4503]: shutting down for system halt
Jul 29 17:32:21 porteus shutdown[4486]: shutting down for system halt
root@porteus:/#

as you can see you have shutdown porteus 3 times yesterday and twice today.

please dont change anything in your setup and boot porteus once again, then run:

Code: Select all

touch /home/guest/Desktop/savedat-test
if that file wont survive next reboot then i owe you a bottle of whiskey :wink:

Re: The "old" save.dat problem

Posted: 29 Jul 2012, 21:54
by steve123
if that file wont survive next reboot then i owe you a bottle of whiskey
Unlucky man I am, do not get a bottle of wisky. :lol:

Yeah, you are right, the file survived. I installed an add-on in Firefox (NoScript) and it stays too. Bookmarked a page and I found it next boot. Made the panel above little smaller - it stays small.
Only the keyboard change didn't stay. So I added, as Ahau told me (thank you Ahau), a cheatcode kmap=fr in the porteus.cfg file and now my keyboard stays french. Phew.

It's not obvious for a beginner to guess that some system changes have to be done in the porteus.cfg file (the keyboard layout for ex.) and other changes like changing the color of the desktop, size of the icons etc. stays without writing by hand into the porteus.cfg file.

I think what happend at the beginning was that I didn't know very well what I was doing and how it works.

Thanks a lot for your help.

Re: The "old" save.dat problem

Posted: 30 Jul 2012, 00:18
by Ahau
Glad you got it sorted out :)

In the case of keymapping, I'm afraid this is a quirk of the xfce configs. The keyboard map can be set in two places - the main xfce "keyboard settings" and also in the xkb panel plugin. The way things work, the xkb plugin takes precedence over the main "keyboard settings", so it's likely that you set the keyboard to french on one login, but that setting was overwritten by the xkb plugin, which was still set to us. Porteus Language Setting Tool and the cheatcode both manipulate the xkb plugin, which is why they'll work more reliably.

I'm not sure why the background wasn't staying for you -- is that working now? If not, I'll grab your save.dat as well and sort that issue out.

Re: The "old" save.dat problem

Posted: 30 Jul 2012, 02:09
by steve123
I'm not sure why the background wasn't staying for you -- is that working now?
Just tested background color, the changed color stays.

Nevertheless I'm lost. Now my usb-stick, usually sdb1, is not mounted.
In the /mnt directory there is no sdb1. Why's that? :%)

Code: Select all

guest@porteus:/mnt$ cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root /mnt/live ext4 rw,relatime 0 0
proc /mnt/live/proc proc rw,relatime 0 0
none /mnt/live/dev devtmpfs rw,relatime,size=1508444k,nr_inodes=377111,mode=755 0 0
/dev/sdb1 /mnt/live/mnt/sdb1 vfat rw,noatime,nodiratime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=utf8,shortname=mixed,check=s,quiet,errors=remount-ro 0 0
/dev/loop0 /mnt/live/memory ext4 rw,relatime,data=ordered 0 0
tmpfs /mnt/live/memory/xino tmpfs rw,relatime 0 0
aufs / aufs rw,relatime,si=e811c6d9769c615,nowarn_perm 0 0
tmpfs /mnt/live/memory/copy2ram tmpfs rw,relatime,size=1810860k 0 0
/dev/loop1 /mnt/live/memory/images/000-kernel.xzm squashfs ro,relatime 0 0
/dev/loop2 /mnt/live/memory/images/001-core.xzm squashfs ro,relatime 0 0
/dev/loop3 /mnt/live/memory/images/002-xorg.xzm squashfs ro,relatime 0 0
/dev/loop4 /mnt/live/memory/images/005-devel.xzm squashfs ro,relatime 0 0
/dev/loop5 /mnt/live/memory/images/006-firefox.xzm squashfs ro,relatime 0 0
/dev/loop6 /mnt/live/memory/images/0090-xfce.xzm squashfs ro,relatime 0 0
/dev/loop7 /mnt/live/memory/images/0091-xfce-apps.xzm squashfs ro,relatime 0 0
/dev/loop8 /mnt/live/memory/images/aalib-1.4rc5-x86_64-3.xzm squashfs ro,relatime 0 0
/dev/loop9 /mnt/live/memory/images/babl-0.1.2-x86_64-1.xzm squashfs ro,relatime 0 0
/dev/loop10 /mnt/live/memory/images/gegl-0.1.2-x86_64-1.xzm squashfs ro,relatime 0 0
/dev/loop11 /mnt/live/memory/images/gimp-2.6.11-x86_64-3.xzm squashfs ro,relatime 0 0
/dev/loop12 /mnt/live/memory/images/hal-0.5.14-x86_64-3.xzm squashfs ro,relatime 0 0
/dev/loop13 /mnt/live/memory/images/ilmbase-1.0.2-x86_64-1.xzm squashfs ro,relatime 0 0
/dev/loop14 /mnt/live/memory/images/openexr-1.7.0-x86_64-1.xzm squashfs ro,relatime 0 0
/dev/loop15 /mnt/live/memory/images/pns-setup-config.xzm squashfs ro,relatime 0 0
/dev/loop16 /mnt/live/memory/images/ppm-debian-files-1.1-noarch-1.xzm squashfs ro,relatime 0 0
/dev/loop17 /mnt/live/memory/images/ppm-salix-index-1.1-noarch-1.xzm squashfs ro,relatime 0 0
/dev/loop18 /mnt/live/memory/images/psc-settings.xzm squashfs ro,relatime 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
devtmpfs /dev devtmpfs rw,relatime,size=1508444k,nr_inodes=377111,mode=755 0 0
devpts /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0
fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0
/dev/sda2 /mnt/sda2 fuseblk rw,noatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0
/dev/sda3 /mnt/sda3 fuseblk rw,noatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0
/dev/sda4 /mnt/sda4 fuseblk rw,noatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0
/dev/sda5 /mnt/sda5 fuseblk rw,noatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0
gvfs-fuse-daemon /home/guest/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
and

Code: Select all

guest@porteus:/mnt$ ls -l
total 22
drwxr-xr-x 17 root root 1024 Jun 28 08:59 live/
drwxr-xr-x  2 root root 1024 Jul 30 03:40 loop/
drwxrwxrwx  1 root root 4096 Mar 25  2010 sda2/
drwxrwxrwx  1 root root 4096 Jun 29 03:41 sda3/
drwxrwxrwx  1 root root 8192 Jul  4 14:24 sda4/
drwxrwxrwx  1 root root 4096 Jul 27 14:15 sda5/
But

Code: Select all

guest@porteus:/mnt$ /sbin/losetup -a
/dev/loop0: [0811]:5 (/mnt/sdb1/savef/porteussave-lap1.dat)
/dev/loop1: [000f]:405 (/memory/copy2ram/base/000-kernel.xzm)
/dev/loop2: [000f]:406 (/memory/copy2ram/base/001-core.xzm)
/dev/loop3: [000f]:407 (/memory/copy2ram/base/002-xorg.xzm)
/dev/loop4: [000f]:408 (/memory/copy2ram/base/005-devel.xzm)
/dev/loop5: [000f]:409 (/memory/copy2ram/base/006-firefox.xzm)
/dev/loop6: [000f]:410 (/memory/copy2ram/base/0090-xfce.xzm)
/dev/loop7: [000f]:411 (/memory/copy2ram/base/0091-xfce-apps.xzm)
/dev/loop8: [000f]:413 (/memory/copy2ram/modules/aalib-1.4rc5-x86_64-3.xzm)
/dev/loop9: [000f]:414 (/memory/copy2ram/modules/babl-0.1.2-x86_64-1.xzm)
/dev/loop10: [000f]:415 (/memory/copy2ram/modules/gegl-0.1.2-x86_64-1.xzm)
/dev/loop11: [000f]:416 (/memory/copy2ram/modules/gimp-2.6.11-x86_64-3.xzm)
/dev/loop12: [000f]:417 (/memory/copy2ram/modules/hal-0.5.14-x86_64-3.xzm)
/dev/loop13: [000f]:418 (/memory/copy2ram/modules/ilmbase-1.0.2-x86_64-1.xzm)
/dev/loop14: [000f]:419 (/memory/copy2ram/modules/openexr-1.7.0-x86_64-1.xzm)
/dev/loop15: [000f]:420 (/memory/copy2ram/modules/pns-setup-config.xzm)
/dev/loop16: [000f]:421 (/memory/copy2ram/modules/ppm-debian-files-1.1-noarch-1.xzm)
/dev/loop17: [000f]:422 (/memory/copy2ram/modules/ppm-salix-index-1.1-noarch-1.xzm)
/dev/loop18: [000f]:423 (/memory/copy2ram/modules/psc-settings.xzm)
How can this be

/dev/loop0: [0811]:5 (/mnt/sdb1/savef/porteussave-lap1.dat)

when there is no /mnt/sdb1 ??

Re-edit:

I found the sdb1.

/mnt/sdb1 does not exist, but

/mnt/live/mnt/sdb1 exists, and this is really the usb-stick with its files.

So the path to porteussave-lap1.dat in porteus.cfg is not correct in this "constellation".
Strange...