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..

When you run graphical login it is *not* possible to Quit the X server. Quitting the X server has the same effect as "restarting" X server. If you want access to your console, press Ctrl-Alt-F2 - but the X server is still there, you can switch back to it by pressing Ctrl-Alt-F4 anytime. I have updated the terms to be clearer for future releases.

Regarding unprintable characters in filenames, I remember that you can also try editing /etc/codepage and replace that with 850 or 860.
This will change the codepage used to mount FAT filesystems, without changing the console keymap. If your problem happens with other filesystems - then the codepaget thingy won't fix it.

gcmartin wrote:

Maybe there is another way.

Such as?

bruno wrote:

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

Yes, if you have that problem. If you don't have any other Linuxes installed, then it is not necessary (=the problem won't affect you).

spandey wrote:

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

No idea. Lucid uses a totally different script to perform the mount/un-mounting. You should ask playdayz _________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

When you run graphical login it is *not* possible to Quit the X server. Quitting the X server has the same effect as "restarting" X server.

Oh, I thought it will quit X as same as in autologin or console mode. But it doesn't restart de X neither, from /usr/share/lxpanel/profile/default/panels/panel:

Code:

name=Quit X server
action=killall xinit
image=mini-x

and from command line:

Code:

# killall xinit
killall: xinit: no process killed

Quote:

Regarding unprintable characters in filenames, I remember that you can also try editing /etc/codepage and replace that with 850 or 860.

Thanks for remeber this!! I tried editing /etc/codepage but changes dissapeared after rebooting, and it doesn't seem to make any differrence. I can see the characters, but the filename appears in red with the legend "This filename is no valid UTF-8. You should rename it". By the way, I was playing a little with Xdialog boxes for a script the last days, and having problem with spanish characters too. If I edit script the from within the virtual terminal (with vi or mp) I get boxes where the special character goes in the Xdialog window. But if I edit it with geany I have no problem, the chars appeared as spected. And if I create a file with spanish chars in the terminal, then it shows in red in Rox's with the same "no valid" legend. It seems like X and terminal emulator uses different charmap, is it posible?

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

Sorry to @Anniekin and anyone else who saw the post that my quote was taken from. I should have been more clear.

That post is addressing issues seen when FATDOG boots on a PC that has other Operating Systems already installed, where rights on drive folders are changed in such a way as to incur problems when trying to boot those existing OS after FATDOG is shutdown.
This is what couple of us are drawing attention to.

Sorry for any confusion. The word "root" in Linux can refer several different things, in context. Sorry._________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engineor use DogPile

Barbol, that "killall xinit" is gone in the next release when you use the graphical login. Graphical login doesn't start the graphical desktop using "xinit", so there is nothing to kill. Instead of "killall xinit", it should be "wmexit logout".

Also, what is the filesystem you're having problem with? I always assume it is FAT (because ext2/3/4 works, I think NTFS works too), but is it? For the other problem, are you using UTF8 locale? I.e. in terminal, type "echo $LANG" and does the output ends with utf8? E.g. mine is en_AU.UTF-8.

I will look into that codepage stuff, it should not be overwritten at every reboot.

using "psubdir=Fatdog" tells the grub4dos (and I believe also grub) boot loader to look in /Fatdog for all files then there is no need to use the "savefile=..." option you have ^ especially as i boot from usb drive. and each computer will assign a different drive allocation. but either will work so it makes little difference.

using "psubdir=Fatdog" tells the grub4dos (and I believe also grub) boot loader to look in /Fatdog for all files then there is no need to use the "savefile=..." option you have ^ especially as i boot from usb drive. and each computer will assign a different drive allocation. but either will work so it makes little difference.

thanks for that.

ok i spoke to soon. with my grub4dos entry above ^ everything works ok. I can boot puppy, create the save file, but on a reboot fatdog ignores the save file.

Has fatdog now been tweaked, from the traditional puppy, needing special boot parameter(s) would be nice to know. I cant see anything about this in the fatdog info.
other than this things seem to work ok, but without a save file i cant test and setup things to really get a feel for this.

**Edit**
here is my setup I always use. as i boot several pupplets from one usb hdd.

i create a folder for each puppy os and put all the files needed for it there.

i have 2 partitions on this hdd a small one fat32 for the grub4dos bootloader and the 2nd, where i put all puppy os, is ext3.

I have a folder /Fatdog/ on the hdd (2nd partition) with the 2 fatdog files and the save file in it.

my assumption is that fatdog may only work properly if all files are in the / of the drive. which is not ideal at all. like other puplets it should be able to run from a folder one layer deep such as /Fatdog/ . Is there a workaround, a pet or boot entry that will correct this. generally "psubdir=Fatdog" in the menu.list file should tell the puppy os to look in /Fatdog/ for all the files needed. works for other puppy os on the drive

thanks for all the hard work gone into fatdog64 so far I hope these issues can be resolved and thus improve 64bit puppy._________________HiDeHo is an ideas man. loves to come up with ideas that others think are good and can use
if you are a sneeky computer geek check out sneekygeekers click here

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum