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.
[SOLVED] The "old" save.dat problem
- Ahau
- 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
Please take a look at our online documentation, here. Suggestions are welcome!
- fanthom
- Moderator Team
- Posts: 5588
- Joined: 28 Dec 2010, 02:42
- Distribution: Porteus Kiosk
- Location: Poland
- Contact:
Re: The "old" save.dat problem
@Ahau
yes - seems that steve123 was running with 'copy2ram' cheatcode:
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.
yes - seems that steve123 was running with 'copy2ram' cheatcode:
Code: Select all
/dev/loop1: [000f]:405 (/memory/copy2ram/base/000-kernel.xzm)
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.
Re: The "old" save.dat problem
Hello,
I give you the boot labels code of porteus.cfg so you can see what happens. I did some changes in there...
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
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.
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
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
By the way : is the order of the cheatcodes important ?APPEND initrd=/boot/initrd.xz vga=791 xfce autoexec=xf-compositing~off changes=/mnt/sdb1/savef/porteussave-lap1.dat kmap=fr copy2ram noeject
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.
- Ahau
- 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
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

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!
Re: The "old" save.dat problem
Thank you, good to know the order of cheatcodes doesn't matter.
In fact I don't know what "compositing" means.
lol
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:...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...
Perhaps I missunderstand something. In option 2 I readAhau wrote:What kind of issues have you run into when switching between option 1 and 2?
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.TEXT HELP
Run Porteus the same as above. (above = option 1)
compositing will be turned off
which will disable transparency
and shadow effects.
ENDTEXT
In fact I don't know what "compositing" means.
Good grief, you are right !! I remove the storage media and then want to store a file on 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 ...

- Ahau
- 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
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.
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!
[solved] Re: The "old" save.dat problem
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" ?
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" ?
- Ahau
- 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
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!
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!