(old)Puppy Linux Discussion Forum

I installed fatdog 611 to my acer revo with the fatdog installer.

Computer
Processor 4x Intel(R) Atom(TM) CPU 330 @ 1.60GHz
Memory 1791MB (157MB used)
Machine Type Physical machine
Operating System Fatdog64 [442447e63b]
User Name root (root)
Date/Time Thu 03 Jan 2013 05:25:55 PM GMT
Display
Resolution 1440x900 pixels
OpenGL Renderer ION/integrated/SSE2
X11 Vendor The X.Org Foundation
Audio Devices
Audio Adapter HDA-Intel - HDA NVidia
OpenGL
Vendor NVIDIA Corporation
Renderer ION/integrated/SSE2
Version 3.3.0 NVIDIA 310.19
Direct Rendering Yes
Network controller Ralink corp. RT3090 Wireless 802.11n 1T/1R PCIe

Runs smoothly on this pc.

EDIT:It's been running very well for about a day now, I made a pet of
htop 1.0.2 if anyone wants it.

When trying to get 32bit apps running on Fatdog64 it is useful to check whether libraries are class ELF64 or ELF32. The tool readelf will tell you. Errors occur when the 32bit app finds the 64bit library instead of the 32bit library.

This is also included in the devx sfs.

cat /etc/clock

does not work in FD64 so maybe the clock is in another place?

If you're trying to get the time from a terminal, type date.

jamesbond wrote:

mini-jaguar wrote:1. I am afraid there is a bug. I noticed it in 6.1.0 too, but now I'm sure something's not working right. When shutting down, it gets stuck on the "Spin down disks ..." line and doesn't shut off. I've waited more that 10 minutes.

It always does it after making the save file, but at other times too. Please note I don't save directly to home, but to a folder in home.

I can turn the computer off with the switch, and the file is indeed saved, but it shouldn't get stuck like that.

This can happen for a number of reasons, most likely driver conflict with your hardware. Try booting with parameter "showerr" and it should let you see what is happening when you shutdown.

2. On an unrelated note, what program do I need to add to make the lives .sfs work? I do not connect to the internet on that computer. The dependency checker seems to work (?) in a weird way in Fatdog64 (yes, I also tried with the .pet).

Yes, lives no longer work in 610 because it depends on certain libraries which got removed when we removed kino. I have re-uploaded the libraries as "lives_support", you need to install when you install lives in 610. (You need to select it manually as it is not indicated in the dependency check). For convenience, I'm also uploading lives.sfs which has all the needed libraries.

I have enclosed some photos, sorry that they are kind of hard to read, it's not easy to take pics of the screen. By the way, if I make the save file directly to the partition it doesn't always bug, neither does it always bug if I load an older file, it just always bugs when I set a path for the save file when making it.


And the new lives .sfs and added libs .pet (with old .sfs) work, I didn't test the program functions, but now it runs.

This is a pet for Grsync to backup and sync directories.
Here are a couple of links that explain how to use Grsync.

http://www.techrepublic.com/blog/openso ... in;content

http://www.howtogeek.com/66348/how-to-s ... -easy-way/

I am running the FireFox version of FatDog64. The menu still contains entries for Sea Monkey Compozer, Sea Monkey Mail & News and Sea Monkey web browser. However, the Sea Monkey components are not available and the entries do not work. This is not a major bug. The menu needs to be updated.

I haven't used sandbox in Fatdog64-611 before today and it didn't seem to work as I expected.

I tried both sandbox.sh and rw-sandbox.sh. I selected all of the sfs as they were all selected as default.

I then ran xwin and got a new desktop.

When I mounted my home drive it displayed an empty rox window.

It wouldn't let me run seamonkey because my profile is outside of my savefile.

I'm pretty sure I didn't have this problem with fd64-600.

Is this a problem or am I doing something wrong?

mini-jaguar wrote:I have enclosed some photos, sorry that they are kind of hard to read, it's not easy to take pics of the screen

The errors before the "spinning down" are harmless. I don't see any error after "spinning down" disk, so I would suspect it can't shutdown due to incompatibility between your hardware and the kernel.

WillM wrote:This is a pet for Grsync to backup and sync directories.

Thank you.

JustGreg wrote:I am running the FireFox version of FatDog64. The menu still contains entries for Sea Monkey Compozer, Sea Monkey Mail & News and Sea Monkey web browser. However, the Sea Monkey components are not available and the entries do not work. This is not a major bug. The menu needs to be updated.

Yes, this is a known problem in 611

I haven't used sandbox in Fatdog64-611 before today and it didn't seem to work as I expected.
I tried both sandbox.sh and rw-sandbox.sh. I selected all of the sfs as they were all selected as default.
I then ran xwin and got a new desktop.
When I mounted my home drive it displayed an empty rox window.
It wouldn't let me run seamonkey because my profile is outside of my savefile.
I'm pretty sure I didn't have this problem with fd64-600.
Is this a problem or am I doing something wrong?

No, you have done everything right. It works as expected. By default, when the sandbox starts, only the SFS-es and savefile are accessible. Any external partitions, including the home partition (where the savefile is located) is NOT accessible. This is because only those parts are protected by the layered filesystem.

The purpose of sandbox is to allow "safe testing" - any changes you make inside the sandbox should not propagate into the real world and break your system (at least, not permanently). Any changes inside sandbox will be discarded (or undone) as soon as you exit the sandbox. External partitions are not protected by the layered filesystem, thus if they were mounted, changes to them *cannot* be undone. Hence, existing partition mounts are not carried over into sandbox.

Of course, within the sandbox-xwin, you can also mount currently-unmounted partitions yourself - nothing is stopping you doing that. There is also a way to bring mounted partitions into sandbox (mount -o bind --- see the sandbox code of how I bring the system's /tmp directory into sandbox's tmp). But you'd better beware that changes to them *cannot* be undone.

This is the first time ever I have heard comments about the sandbox

Barbol wrote:In a very very humble opinion, I think this permissions thing could be a serious trouble for a linux begginer (for example someone who has an ubuntu install and decides to gives fatdog a try. When he reboots he could be in front of a broken system, without elements to diagnose nor repair the damage - been there many times!! - Of course, he will never use fatdog again!). I hope this is constructive,

It is a trade-off between security and usability. Anyway, in the next version of Fatdog, I have added an option to Fatdog Event Manager to enable this ("allow read-only access for all other users - for compatibility with other distros e.g Ubuntu"). All you need to do is to tick the checkbox, no need to manually edit /etc/eventmanager.
On another note, I'm really surprised if you tell me that Ubuntu will fail to boot because of this (I haven't used Ubuntu for years now).

smokey01 wrote:I haven't used sandbox in Fatdog64-611 before today and it didn't seem to work as I expected.
I tried both sandbox.sh and rw-sandbox.sh. I selected all of the sfs as they were all selected as default.
I then ran xwin and got a new desktop.
When I mounted my home drive it displayed an empty rox window.
It wouldn't let me run seamonkey because my profile is outside of my savefile.
I'm pretty sure I didn't have this problem with fd64-600.
Is this a problem or am I doing something wrong?

jamesbond wrote:No, you have done everything right. It works as expected. By default, when the sandbox starts, only the SFS-es and savefile are accessible. Any external partitions, including the home partition (where the savefile is located) is NOT accessible. This is because only those parts are protected by the layered filesystem.

The purpose of sandbox is to allow "safe testing" - any changes you make inside the sandbox should not propagate into the real world and break your system (at least, not permanently). Any changes inside sandbox will be discarded (or undone) as soon as you exit the sandbox. External partitions are not protected by the layered filesystem, thus if they were mounted, changes to them *cannot* be undone. Hence, existing partition mounts are not carried over into sandbox.

Of course, within the sandbox-xwin, you can also mount currently-unmounted partitions yourself - nothing is stopping you doing that. There is also a way to bring mounted partitions into sandbox (mount -o bind --- see the sandbox code of how I bring the system's /tmp directory into sandbox's tmp). But you'd better beware that changes to them *cannot* be undone.

This is the first time ever I have heard comments about the sandbox

How do I do any testing if I can't get the pet file I want to test inside the sandbox. Seamonkey won't let me download it as it doesn't work.
I even tried gFTP and it wouldn't connect.

When I went back and tried FD-600 I could see all of the contents of the /root directory. this means I can simply put the pet file in root then run sandbox and it will be seen. This is not the case with 611. In 611 you only see the pristine /root.

I understand the sandbox needs to be isolated from the outside world to protect it's integrity but how is it possible to test anything if we can't include apps form the outside world.

Does everything in the temp layer get destroyed in both sandbox.sh and rw-sandbox.sh?

Thanks

A very nice little Database.

smokey01 wrote:How do I do any testing if I can't get the pet file I want to test inside the sandbox.

Ah, but you can. The union root filesystem of the sandbox (the "/") is located at /mnt/fakeroot. Copy stuff to there and it will appear in sandbox; and vice versa. The "savefile" of the sandbox is located in /mnt/sandbox - you can copy files there too as long as you are aware of aufs rules.

Seamonkey won't let me download it as it doesn't work.
I even tried gFTP and it wouldn't connect.

Sure it will. For seamonkey, just remove the /root/spot/.mozilla symlink from within the sandbox. I'm not sure why gftp won't work - try running it from terminal, do you see any error messages?

When I went back and tried FD-600 I could see all of the contents of the /root directory. this means I can simply put the pet file in root then run sandbox and it will be seen. This is not the case with 611. In 611 you only see the pristine /root.

Oh, so that's what you mean. I thought you were referring to the content of /mnt/home - what was my previous answer for. Of course it still works in 611. You need to include your savefile layer when starting up sandbox, though. By default sandbox starts up in "/" not in "/root", so you need to "cd /root" to see your files.

Does everything in the temp layer get destroyed in both sandbox.sh and rw-sandbox.sh?

The "savefile" layer in sandbox.sh (mounted at /mnt/sandbox when sandbox is running) is a tmpfs, it will be destroyed when you exit. With rw-sandbox.sh, that "savefile" is really a file, all changes will be stored in that file and you load the changes again later by starting rw-sandbox and point it to the same file.

cheers!

kirk wrote:This is also included in the devx sfs.

so if we have devx, we dont need slacko 32 sfs?

jamesbond wrote:It is a trade-off between security and usability.

I was wondering about that.. how does allowing read-only access for all other users impacts security in fatdog? have any effect on the spot user?

On another note, I'm really surprised if you tell me that Ubuntu will fail to boot because of this (I haven't used Ubuntu for years now).

Somehow it affects the greeter, so the X session cannot be started. I was only able to login as root in the console (but the root account is disable by default in ubuntu).

I love Fatdog64. It is fairly easy to configure. I posted a minor bug about the lxpanel menu having SeaMonkey entries for items not present in the FireFox version. It is very easy to remove them. One has to go to the directory /usr/share/applications using the Rox Filer. Find the SeaMonkey-function_name.desktop files and rename them as SeaMonkey-function_name.deskold. One just restarts the X server using the Menu. After the X server starts up, the SeaMonkey menu entries are no longer present. This is the easy way to correct the lxpanel menu. There is no editing of configuration files. I hope this helps.

jamesbond wrote:

mini-jaguar wrote:I have enclosed some photos, sorry that they are kind of hard to read, it's not easy to take pics of the screen

The errors before the "spinning down" are harmless. I don't see any error after "spinning down" disk, so I would suspect it can't shutdown due to incompatibility between your hardware and the kernel.

I had the exact same problem with 6.1.0 too, not only 6.1.1.

But I just "downgraded" to 6.0.1 and now it works like a charm, boots up and shuts down lightning fast.

I've been using a Dell Inspiron 1501, by the way.

Anniekin wrote:

kirk wrote:This is also included in the devx sfs.

so if we have devx, we dont need slacko 32 sfs?

kirk was referring to the "readelf" utility. devx doesn't have 32-bit libs, you still need 32-bit sfs for that.

Barbol wrote:

jamesbond wrote:It is a trade-off between security and usability.

I was wondering about that.. how does allowing read-only access for all other users impacts security in fatdog? have any effect on the spot user?

The whole point of running network programs as "spot" is so that if these programs are broken and get controlled by someone else, they can only see what "spot" can see - which isn't hopefully not much (mostly the Downloads folder and at most the boot partition). If you allow "all other users" to read off your other partitions, there isn't much security in that anymore - a malware running as "spot" can now uploads anything in your other partition too

On another note, I'm really surprised if you tell me that Ubuntu will fail to boot because of this (I haven't used Ubuntu for years now).

Somehow it affects the greeter, so the X session cannot be started. I was only able to login as root in the console (but the root account is disable by default in ubuntu).

I am speechless

mini-jaguar wrote:But I just "downgraded" to 6.0.1 and now it works like a charm, boots up and shuts down lightning fast.

610 and 611 has the same kernel so yeah going back to 610 is unlikely to help. 601 on the other hand has a different kernel.
You can also try the Fatdog UEFI iso I posted in another thread - it has another 3.4.24 kernel, and see if it can shutdown properly.
610/611 shutdown is slower, because I added "spindown disk" and wait 2-seconds after that before it really shuts down. I reckon it is worth the wait to ensure that any disks (=of the spinning platter type) will save their internal caches to the disk and shutdown gracefully before power is removed. Before that, every time I shutdown with USB disks connected, I heard a very alarming noise and I always worried whether it didn't get the chance to save its internal cache.

prozgui is a pretty nice download accelerator.

I wish I could work out how to make it use multiple servers to get the same file.

EDIT: Wow, this bug is fixed within hours!

Over the weekend I installed Fatdog on a usb stick to have as an emergency repair system for our new office computers which run Ubuntu 12.04. This morning, simply booting Fatdog and looking at the HD contents ruined two fresh, fully configured installations before I realized the problem was Fatdog itself. I wish I had seen the previous posts about this before hand, it would have saved a lot of grief.

This is not good, it’s bad, very bad. A live system should never alter the HD contents except through user action.

2byte wrote:This morning, simply booting Fatdog and looking at the HD contents ruined two fresh, fully configured installations. ...A live system should never alter the HD contents except through user action.

To help fix this problem, you need to specify exactly what "looking" meant.

Did you just browse the Ubuntu filesystem?

Did you open any files? With what program did you open them?

2byte wrote:Over the weekend I installed Fatdog on a usb stick to have as an emergency repair system for our new office computers which run Ubuntu 12.04. This morning, simply booting Fatdog and looking at the HD contents ruined two fresh, fully configured installations before I realized the problem was Fatdog itself. I wish I had seen the previous posts about this before hand, it would have saved a lot of grief.

This is not good, it’s bad, very bad. A live system should never alter the HD contents except through user action.

It may have been a coincidence but I also found Linux Mint was unbootable after perusing files in it using Fatdog and copying one file from Mint to Fatdog. All repair methods failed and I had to reformat the partition and do a new installation of Linux Mint. My Fatdog installation was conventional frugal, not on a usb stick.