(old)Puppy Linux Discussion Forum

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.

@rcrsn51

Looking = Mounted the partitions & looked at the partition contents with Rox. That's all. Didn't open a single file. On the other machine I ran gparted and looked at the disk layout. Did not make any changes.

Basically all I was doing was making sure Fatdog would boot to a desktop on these brand new machines.

EDIT: I am building 3 more of these Ubuntu systems & I have the basic disk backed up with clonezilla ( a life saver BTW ) so if any changes are made to Fatdog in the next week or so to address this I would be happy to test it.

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

Agreed.

It may have been a coincidence but I also found Linux Mint

Bug confirmed. It is not a co-incidence. My UbuntuStudio 8.04 and 64Studio installation both refused to start graphical login after Fatdog touched their partition. They did boot into console, however "gdm" (the graphical login manager) refused to start.

For those affected, the quick fix is to mount the partition (e.g /dev/sda2 on /mnt/sda2) and then issue "chmod 755 /mnt/sda2" and then unmount, and don't mount again until you apply the following pet.

EDIT: The previous fix isn't working. This one will.
The attached pet should fix this: permission will not be changed when running as root (this is the default when running live). If one runs as non-root, however, permission will still be changed (out of necessity to grant access to them) - I will assume that one who runs as non-root knows what one is doing.

Second post updated.

@jamesbond

The bugfix pet works here at home. Will test it further on the new machines at work but I don't expect any problems.

I appreciate the instant fix. A person couldn't ask for anything better.

Are the isos going to be updated? Fatdog64 should not be allowed out in its current state.

jamesbond wrote:.
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.

Well, it shuts down properly much more often than 610 or 611, not all the time, and sometimes even shuts down properly after making the save file (which 610 or 611 never seem to do). So improper shutdowns happen maybe only 40% of them time.

It also does not allow me to open the menu.lst file, which is on an NTFS+ partition, and never, ever, loads up the save file if I put the save file in a folder.

So it's even less usable than 610 and 611.

Edited for clarity: This post refers to issue seen n filesystem rights.
Hi @Jamesbond. Thanks for looking into what we share on the permissions bug.

The root & non-root decision process may not necessarily be a good one. I do understand what your efforts intend, But that circumvention would allow someone who, coming from 32bit Puppy/Windows/Apple/Linux distro, to miss this understanding.

Maybe there is another way.

And, in the meantime, should the older method be put back into play, as consideration. Up until now, this issue did not exist. Now, it does, and potentially, non-aware and unsuspecting users can accidentally lose out. Further, even those who may have used FATDOG610+ for months could accidentally bomb the system unexpectedly should they not remember or know.

Just an idea for consideration in this positive and revolutionary distro in Puppyland.

I may have found a minor bug in the fatdog's menu. I have an install with grafical login and Openbox WM, where the main menu option "Quit X server" doesn't do anything. It works correctly with console login..

Barbol

gcmartin wrote:The root & non-root decision process may not necessarily be a good one.

its the easiest way for a puppy distro author to set up restrictions on internet activity. if there's an older method i do not know of it. the multi user .pet? its easy to manage users with terminal commands like adduser or useradd

Is the mount-helper-fix pet also needed for 601?

Has anyone tried browsing Linuxmint files from Lucid 5.2.8 ? I get the same problem.