Some rookie questions

[tmsg]

(I've googled for most of my questions but so far have not found answers to all of them. I am not a PC newbie as such but my exposure to Linux has been rather modest. So here goes.)

The plan is to use Porteus 64bit (p64) as a thin OS shell to run a Win7 guest in VirtualBox. In the long run I will switch more and more stuff to Linux but for the time being most of my activities will still be in Win7. To that end and as a first tentative step,I want to test p64 in my current Win7 install, to get a feel how it all hangs together. So I've installed p64 in a vbox VM, have compiled the vbox GAs and this all works OK: so far, so good.

Now I'd like to add a few Win7 directories as shared folders; the mounting itself works fine but I am at a loss to find out how to have these folders automount (the vbox Auto-mount option seems to have no effect) . There are some hints as to editing /etc/rc.d/rc.local but I am not sure that this is the best/correct place.

Second, I've read through the way the Porteus filesystem is constructed and I am not totally clear as to why there is a /mnt/sda1/porteus/changes/ directory *and* a /mnt/sda1/porteus/rootcopy/ directory (sda1 being the vbox .vdi). If I want to change something I can directly do so in /.../changes/, right? So why would I want to add another layer, multiplying the possible places where stuff can be changed and possibly adding to the confusion?

Three, once I have a (more or less) stable system, my understanding is that I can then construct new base .xzms and copy them to /.../base/. Is there a tutorial as to how to do that?

Any hints welcome!

[francois]

1.0 Sixth post in the following thread for permanent shared folder instructions for vbox between porteus guest and host :
viewtopic.php?f=81&t=4852&p=35413#p35413

I hope this is what you are looking for.

2.0 changes= cheatcode is what is called persistance mode. When you enter the X environment and modify the structure of your porteus installation, or simply modify some aspects of your desktop as in kde or xfce (opening file manager window, or applications). At power down the information will be automatically saved into a file, the /porteus/changes folder. It might be a little hard to find exactly what did finally changed with accumulation of changes from one shutdown to another.

Fakeroot is more for manual changes they are specific. These changes in rootcopy are more easily removed independently if it suits the user needs. Personally, I never use fakeroot. It depends on your needs.

[tmsg]

Thanks for looking into that.

1.0 Sixth post in the following thread for permanent shared folder instructions for vbox between porteus guest and host :
viewtopic.php?f=81&t=4852&p=35413#p35413

I currently do that to mount my shared folders, though I do not mount them in /mnt/ but in my home directory:

Code: Select all

mount -t vboxsf Documents WinDocuments

with Documents being a vbox share name and WinDocuments an empty folder in /home/tmsg. However, these mounts are not permanent. That is why I was asking for the best way to automount these folders.

2.0 changes= cheatcode is what is called persistance mode. When you enter the X environment and modify the structure of your porteus installation, or simply modify some aspects of your desktop as in kde or xfce (opening file manager window, or applications). At power down the information will be automatically saved into a file, the /porteus/changes folder. It might be a little hard to find exactly what did finally changed with accumulation of changes from one shutdown to another.

Fakeroot is more for manual changes they are specific. These changes in rootcopy are more easily removed independently if it suits the user needs. Personally, I never use fakeroot. It depends on your needs.

(I take it that fakeroot is an "old" name for rootcopy?)
Let me try to get that straight: changes happen to the live filesystem and they are copied to the /.../changes/ folder upon shutdown. So if I edit any file in the filesystem, this change will be automatically transferred to the changes folder when I shut down. This means that editing a file directly in the /.../changes/ folder is actually counterproductive as this edit may be overwritten upon shutdown if the same file has been changed in the running session. Whereas /.../rootcopy is completely under my control, right?

This also triggers a second question. If I accumulate many changes in a session, all these changes sit in the live filesystem, ie in RAM. If there's a power failure or some such problem then these changes are presumably gone. There is something in the Tips and Tricks section called changes-time:

changes-time - copies all files that have been added or modified on your system over a specified period of time.

Is this the job to call to save changes in the live filesystem to /.../changes/ w/o having to shut down? If not, how can I do that?

[Bogomips]

I do not mount them in /mnt/ but in my home directory:

Code: Select all

mount -t vboxsf Documents WinDocuments

with Documents being a vbox share name and WinDocuments an empty folder in /home/tmsg. However, these mounts are not permanent. That is why I was asking for the best way to automount these folders.

Don't know anything about vboxsf. Normally 'automount' to mount points on my home directory by using rootcopy. Given a more detailed explanation, I could elaborate.

[brokenman]

Whereas /.../rootcopy is completely under my control, right?

All files are under your control. Rootcopy was really intended just for testing a few small files during boot. Do a test with your changes. Update a file in the changes folder and then check if it was also updated in the live file system. Then reverse the test and see if the same is true.

[tmsg]

Whereas /.../rootcopy is completely under my control, right?

All files are under your control. Rootcopy was really intended just for testing a few small files during boot. Do a test with your changes. Update a file in the changes folder and then check if it was also updated in the live file system. Then reverse the test and see if the same is true.

I did so and I see that changes seem to be "mirrored" the moment they happen. However, that observation/fact clashes with what francois wrote in his above post about changes being saved to /.../changed/ upon shutdown.

In effect I am now quite confused as to what happens when I change a file... a) in that very moment and b) when I shut down.

[Ed_P]

I did so and I see that changes seem to be "mirrored" the moment they happen. However, that observation/fact clashes with what francois wrote in his above post about changes being saved to /.../changed/ upon shutdown.

In effect I am now quite confused as to what happens when I change a file... a) in that very moment and b) when I shut down.

The changes=EXIT cheatcode saves changes at shutdown, the plain changes= cheatcode saves changes as they occur, ttbomk. I should also note that the changes=EXIT option saves specific folders, whereas the changes= saves everything, ttbomk.

[francois]

1.0 vbox:
these mounts are not permanent.
Just make them permanent and they will automount. Then remove the permanent mounting if you want them unmounted and create a temporary mount if you want it for this only session that you are having. This is a question of definition: permanent means automount. If you do not start vbox the targetted folder won't be mounted. What exactly are you looking for?

[tmsg]

The changes=EXIT cheatcode saves changes at shutdown, the plain changes= cheatcode saves changes as they occur, ttbomk. I should also note that the changes=EXIT option saves specific folders, whereas the changes= saves everything, ttbomk.

Thanks for that. I struggle to find a coherent and complete explanation for this area.

I am software developer myself (though for the Win32 API) and I know what a RPITA documentation can be when writing code is so much more stimulating. But there are some people out there who actually read this stuff:-)

Is there a wiki where I could post some stuff I might write up about these things?

Just make them permanent and they will automount.

No, they don't. That's my whole point. I've set all shared folders to automount in the vbox settings for the VM but they are not automatically mounted. I can mount them manually but they are not mounted anymore after rebooting.
But never mind.I have now written a small shell script that mounts all those folders which is executed once after login.

[Ed_P]

I struggle to find a coherent and complete explanation for this area.

Item 15 on this page should help answer that: http://forum.porteus.org/faq.php

I am software developer myself (though for the Win32 API) and I know what a RPITA documentation can be when writing code is so much more stimulating. But there are some people out there who actually read this stuff :-)

Oh so true, so true.

But never mind.I have now written a small shell script that mounts all those folders which is executed once after login.

[brokenman]

I struggle to find a coherent and complete explanation for this area.

In the init script (found at /mnt/live/linuxrc)

LINE: 216

Code: Select all

mount -o bind /mnt/$DEV/$LPTH/changes /memory/changes

This line is run when using: changes=/path/to/my/changes/folder as a cheatcode or made permanent in the file /mnt/sdaxY/boot/syslinux/porteus.cfg
Essentially this means any changes you make to the live file system are 'mirrored' in your chosen changes folder (real writable file system) immediately. When you next boot up, the changes recorded in this changes folder are bound to the live file system.

Using the changes=EXIT cheatcode means the same as above except the changes are committed only during shutdown.

Code: Select all

mount -nt tmpfs -o size=$RAMSIZE tmpfs /memory/changes

This is accomplished by creating a ram file temp file system and putting all the changes into /memory/changes first. If you decide to save them on shutdown then they are copied into the changes folder.

Hope this helps.
I think you have chosen the easiest way to have your custom directories mounted at boot.

[francois]

Sorry, you are right :
viewtopic.php?f=81&t=4852

In my case for a sda5 permanent share, you need to do within the guest:

Code: Select all

root@porteus:~# mkdir /mnt/shares
root@porteus:~# mount -t vboxsf sda5 /mnt/shares
root@porteus:~# 

Depending on your desktop version of porteus: kde, xfce, ... . You could put a script in the autostart folder. For kde the autostart is located in:
/root/.kde4/autostart

[tmsg]

@brokenman: Thanks for that. I have found more bits and pieces about the changes= cheatcode and the way EXIT: works in the docs. It is all a bit over the place but at least it is there!

@francois: I am using XFCE and I have already found the way to do it. Thanks.

@everybody: Porteus is so far pretty convincing for my needs. My ideal distro would be much along the lines of Porteus (for instance, I like the way the .iso is clicked together). There's still too much stuff in the system as installed for my liking but I admit that my needs a wee bit peculiar. I work mostly from the command line, don't need any fancy multimedia stuff and am happy when I have SciTE as my editor.
Ideally, the perfect distro would come with a minimal base, a minimal DE (for instance, in the case of XFCE no xfce goodies), a full set of development tools and a reliable, efficient package management to get exactly the stuff I want but not more.
From what I've seen so far Porteus comes pretty close.

[brokenman]

If you post a question someone will show you how to remove the unwanted packages from a module. Essentially it is like this:

Code: Select all

mkdir /tmp/un
xzm2dir /path/to/002-module.xzm /tmp/un
root=/tmp/un removepkg isomaster
dir2xzm /tmp/un /tmp/002-module.xzm