[SOLVED] The "old" save.dat problem

Post here if you are a new Porteus member and you're looking for some help.
User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: The "old" save.dat problem

Post#16 by Ahau » 30 Jul 2012, 06:11

Did you start running with 'copy2ram', by chance? The default behavior for copy2ram is to eject the storage media once the porteus data is copied into memory, so that you can remove the device and boot another machine with it. In this case, your drive was mounted in the initrd ('linuxrc') phase, which is reflected in /mnt/live, but cannot be unmounted because your save.dat is still mounted there. To remedy this, use the 'noeject' cheatcode and your flashdrive will remain mounted (in /mnt/live/mnt and /mnt).

I've also had this issue (drive showing up in /mnt/live/mnt but not /mnt) in earlier versions of Porteus, and it was remedied with the "delay=" cheatcode, e.g. delay=4. The kernel just needed some time to settle in with my hardware for whatever reason; that issue has gone away with fanthom's more recent linuxrc.

It's normal to have your drives mounted in both places. When the kernel loads the initrd, it mounts everything and builds the live filesystem in those first few seconds; then it runs pivot_root to change the root directory to what was formerly /union (now your acting /). Unlike systems that use initramfs, this information remains available and visible in /mnt/live and, in fact, when Porteus shuts down, it pivot_root's back into /mnt/live (putting / back to /union) so everything can be cleanly disassembled and umounted before shutdown.
Please take a look at our online documentation, here. Suggestions are welcome!

User avatar
fanthom
Site Admin
Site Admin
Posts: 4613
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: The "old" save.dat problem

Post#17 by fanthom » 30 Jul 2012, 12:03

@Ahau
yes - seems that steve123 was running with 'copy2ram' cheatcode:

Code: Select all

/dev/loop1: [000f]:405 (/memory/copy2ram/base/000-kernel.xzm)
and 'noeject' cheatcode should sort out this issue.

i know some people may be not aware of 'noeject' cheat so i have decided to add another check to linuxrc which compares booting device and device where changes are stored and if they match then booting device will be still mounted after boot in /mnt/sdXY even if removable.

to be introduced in next porteus release.
Please add [Solved] to your thread title if the solution was found.

steve123
White ninja
White ninja
Posts: 17
Joined: 28 Jul 2012, 17:24
Location: Europe

Re: The "old" save.dat problem

Post#18 by steve123 » 30 Jul 2012, 15:39

Hello,

I give you the boot labels code of porteus.cfg so you can see what happens. I did some changes in there...

Code: Select all

LABEL xfce
MENU LABEL Graphics mode (XFCE)
KERNEL /boot/vmlinuz
APPEND initrd=/boot/initrd.xz vga=791 xfce changes=/mnt/sdb1/savef/porteussave-lap1.dat
TEXT HELP
    Run Porteus the best way we can.
    Try to autoconfigure graphics
    card and use the maximum
    allowed resolution
ENDTEXT

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 kmap=fr copy2ram

TEXT HELP
    Run Porteus the same as above.
    compositing will be turned off
    which will disable transparency
    and shadow effects.
ENDTEXT

LABEL fresh
MENU LABEL Always Fresh
KERNEL /boot/vmlinuz
APPEND initrd=/boot/initrd.xz xfce nomagic base_only norootcopy 
TEXT HELP
    Normally Porteus saves all changes
    to the /porteus/changes/ directory
    on the boot media (if writable)
    and restores them next boot.
    Use this option to start a fresh
    system, changes are not read from
    or written to any device
ENDTEXT

LABEL copy2ram (with last session file)
MENU LABEL Copy To RAM
KERNEL /boot/vmlinuz
APPEND initrd=/boot/initrd.xz vga=791 xfce copy2ram autoexec=xf-compositing~off changes=/mnt/sdb1/savef/porteussave-lap1.dat 
TEXT HELP
    Run Porteus the same as above,
    but first copy all data to RAM
    to get a huge speed increase
    (needs >768MB)
ENDTEXT

LABEL vesa
MENU LABEL Graphics VESA mode
KERNEL /boot/vmlinuz
APPEND initrd=/boot/initrd.xz nomodeset autoexec=vesa-mode xfce changes=/mnt/sdb1/savef/porteussave-lap1.dat 
TEXT HELP
    Run Porteus with XFCE, but skip
    the graphics card autoconfig.
    This forces 1024x768 resolution
    using a standard VESA driver
ENDTEXT

LABEL text
MENU LABEL Text mode
KERNEL /boot/vmlinuz
APPEND initrd=/boot/initrd.xz autoexec=telinit~3 
TEXT HELP
    Run Porteus in text mode and
    start the command prompt only
ENDTEXT

LABEL pxe
MENU LABEL Porteus as PXE server
KERNEL /boot/vmlinuz
APPEND initrd=/boot/initrd.xz xfce autoexec=pxe-boot~& 
TEXT HELP
    Run Porteus as usual, but also
    initialize a PXE server.
    This will allow you to boot Porteus
    on other computers over a network
ENDTEXT
The options I like most is number 2 (= XFCE--no compositing) and 4 (= copy2ram),
I choose 2 to have no shadows (less cpu activity) or 4 (all is in ram) so the computer is fast.
To have both, as you can see, I added copy2ram in option 2.

Sometimes it may have happend that my laptop has booted with option 1 because I waited too long to choose the boot-option and the computer starts automatically with option 1. My impression is that I get trouble when I start with changing options, once with 1, other time with 2...

If I understand you well, I should add "noeject" in the APPEND line of option 2, that is to say
APPEND initrd=/boot/initrd.xz vga=791 xfce autoexec=xf-compositing~off changes=/mnt/sdb1/savef/porteussave-lap1.dat kmap=fr copy2ram noeject
By the way : is the order of the cheatcodes important ?

On the other hand, imagine I'd like to be able to remove the storage media and so I not add "noeject".
In that case, for the boot and shutdown happens properly, should I change the changes path in

changes=/mnt/live/mnt/sdb1/savef/porteussave-lap1.dat ?

The last question is more theoretically, to understand. I think I'll let the storage media in because I'd like to write data on it i can read on windows.

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: The "old" save.dat problem

Post#19 by Ahau » 30 Jul 2012, 16:56

Yes, how you are showing the 'noeject' cheatcode is correct, and is only needed in this case when used with 'copy2ram'. The order of cheatcodes is not important, the linuxrc script searches for them in any order out of /proc/cmdline. My only piece of advice is that if you like to change your cheatcodes from the bootloader menu (by pressing 'tab'), it's easier if you place the cheats that you swap the most towards the end of the line, so it's faster and easier to move over and delete or modify them. One of my boot entries has 'toroot' towards the middle of the line, and it's always a pain when I want to boot into 'guest' user and I have to hold the arrow key a long time to get over to it :).

What kind of issues have you run into when switching between option 1 and 2? This should be pretty stable as there's only one line in one config file that is being modified to toggle compositing. If you're having issues, then I've messed up here and would like to know more so I can fix it.

If you want to remove your flash drive from the computer after you boot up, then you cannot run with your saved changes on this device at the same time -- the drive must stay mounted (in /mnt/live/mnt/* at least, which is keeping the loop device associated with the save.dat file mounted as the writeable branch in aufs). You can either run copy2ram with no saved changes, or you can convert your saved changes from save.dat into a module, place that module in /porteus/modules, and then boot copy2ram with no saved changes. This will apply your customizations to the system on startup (as saved in the new module), but any additional changes you make while the system is running will not be saved anywhere.

Finally, you could also save your changes to a different device on the computer. For example, you could have porteus booting from your flash drive, and keep a save.dat on your hard drive somewhere (changes=/mnt/sda1/path/to/save.dat), load with copy2ram, and then pull your flash drive -- your hard drive will remain mounted to save your changes.

Fanthom is capable of a great many things, but I'm afraid saving files to (and reading them from) a device that is not connected to the computer isn't one of them ;)
Please take a look at our online documentation, here. Suggestions are welcome!

steve123
White ninja
White ninja
Posts: 17
Joined: 28 Jul 2012, 17:24
Location: Europe

Re: The "old" save.dat problem

Post#20 by steve123 » 30 Jul 2012, 18:10

Thank you, good to know the order of cheatcodes doesn't matter.
Ahau wrote:...My only piece of advice is that if you like to change your cheatcodes from the bootloader menu (by pressing 'tab'), it's easier if you place the cheats that you swap the most towards the end of the line...
Great! I didn't know that one can change the cheatcode from the bootloader menu, I'll try the tab just to see how it works. I only switched between the choices with arrow keys up/down.
Ahau wrote:What kind of issues have you run into when switching between option 1 and 2?
Perhaps I missunderstand something. In option 2 I read
TEXT HELP
Run Porteus the same as above. (above = option 1)
compositing will be turned off
which will disable transparency
and shadow effects.
ENDTEXT
I concluded from this text that transparency and shadow effects happen in option 1 and I know that these effects cost additional cpu effort.I like to be economic with that because my laptop is not so fast and I also want to economise rechargeable battery.
In fact I don't know what "compositing" means.
If you want to remove your flash drive from the computer after you boot up, then you cannot run with your saved changes on this device at the same time ...
Good grief, you are right !! I remove the storage media and then want to store a file on it. :fool: lol

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: The "old" save.dat problem

Post#21 by Ahau » 30 Jul 2012, 18:57

lol, no worries. Porteus has a rather unique way of bringing files together from various locations to form the live filesystem. It's easy to install and use, but when you get deeper into the structure of the beast, it can sometimes be difficult to keep a finger on how everything ties together. A good place to start is here: http://porteus.org/component/content/ar ... cture.html

Regarding compositing: the 'compositor' in question is the built in compositing engine for xfce, which allows true transparency, shadowing, and other effects inside xfce. Your system will use fewer resources with compositing disabled. I only asked because it sounded like maybe you were having unexpected behaviour or problems associated with switching between the two, and I wanted to make sure it was working fine.

Also, regarding system resources/battery life: take a look inside Porteus Settings Centre (PSC). There's an option there to throttle down your CPU speed (doesn't work on all CPU's), and also an option to turn on "laptop-mode-tools" which can be quite effective at prolonging battery life.
Please take a look at our online documentation, here. Suggestions are welcome!

steve123
White ninja
White ninja
Posts: 17
Joined: 28 Jul 2012, 17:24
Location: Europe

[solved] Re: The "old" save.dat problem

Post#22 by steve123 » 08 Aug 2012, 19:03

I just write some words to say that the problem is solved. With the label 2 it copies to the Ram, with the cheatcode "noeject" my storage media stays mounted, it works fine. Thank you.

Is it correct to write "solved" in the title field?

Well, I have the answer, this changes only the title of this post. Shoud I edit the first post, or does an admin mark the thred as "solved" ?

User avatar
Ahau
King of Docs
King of Docs
Posts: 1331
Joined: 28 Dec 2010, 15:18
Distribution: LXDE & Xfce 32/64-bit
Location: USA

Re: [SOLVED] The "old" save.dat problem

Post#23 by Ahau » 08 Aug 2012, 19:13

Glad it's working for you!

Yes, marking the thread as [solved] is much appreciated -- I have done this for this thread; for future/other reference, normal users can click to edit the first post in the thread and change the title to include [SOLVED] there to accomplish this. Thanks!
Please take a look at our online documentation, here. Suggestions are welcome!

Post Reply