Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 15 Nov 2019, 12:42
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Derivatives
TazPup64 (pre-alpha17) - getting close to alpha quality
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 6 of 7 [92 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7 Next
Author Message
s243a

Joined: 02 Sep 2014
Posts: 2147

PostPosted: Fri 26 Apr 2019, 01:34    Post subject:  

I've been working a bit on the lxde desktop to make it more usable. I'm getting GDBus related errors (I'll try to reproduce the contexts).

Here's an example:
Code:

error creating proxy, Error calling StartServiceByName for org.freedesktop.ConsoleKit: GDBus.Error:org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute program org.freedesktop.ConsoleKit: Permission denied

and also
Code:

#Not sure if this is the command
$ gdbus monitor --system --dest org.freedesktop.ConsoleKit
#that produces the following error if consolekit isn't started
GDBus.Error:org.freedesktop.ConsoleKit.Manager.Error.General: Unable to lookup session information for process '1775'
#alternatively perhaps if consolkit isn't started this is the error you get:
gdbus The name org.freedesktop.ConsoleKit does not have an owner

[/quote]
When I boot with screen=text and start consolekit before calling startlxde, I get the error:
Code:

GDBus.Error:org.freedesktop.ConsoleKit.Manager.Error.General: Unable to lookup session information for process '18715'

then If I look up this process I see:
Code:

sh-4.4# ps -aux | grep 18715
root     18715  1.5  0.8 310888 17844 tty2     Sl+  06:45   0:00 lxpolkit
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2147

PostPosted: Fri 26 Apr 2019, 02:52    Post subject:  

s243a wrote:

When I boot with screen=text and start consolekit before calling startlxde, I get the error:
Code:

GDBus.Error:org.freedesktop.ConsoleKit.Manager.Error.General: Unable to lookup session information for process '18715'

then If I look up this process I see:
Code:

sh-4.4# ps -aux | grep 18715
root     18715  1.5  0.8 310888 17844 tty2     Sl+  06:45   0:00 lxpolkit


I'm actually wondering why ConsoleKit is being envoked here. Reading another thread:

Quote:

If you start LXDE (or any other WM) through KDM, GDM or Slim a DBus/ConsoleKit session is automatically created before the WM is started. However, if you use startx you need to start this session yourself. This is what the ck-launch-session dbus-launch --exit-with-session {...} does, it starts a proper DBus/ConsoleKit session.

https://forums.freebsd.org/threads/gdbus-error-org-freedesktop-consolekit-manager-generalerror.61540/#post-354460

but if I start the desktop with the startlxde command (note 1), the session is created via the code:
Code:

# Launch DBus if needed
if which dbus-launch >/dev/null && test -z "$DBUS_SESSION_BUS_ADDRESS"; then
   if test -z "$XDG_RUNTIME_DIR" -o ! -S "$XDG_RUNTIME_DIR/bus" -o ! -O "$XDG_RUNTIME_DIR/bus"; then
      eval "$(dbus-launch --sh-syntax --exit-with-session)"
   fi
fi

Example output to eval statment:
Code:

DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-Hh0jxyWhpV,guid=3d65acd28bd229aef86c35295cc2a4d3
export DBUS_SESSION_BUS_ADDRESS
DBUS_SESSION_BUS_PID=12636

so if I don't need ck-lanuch-session to create a session do I need it. Also why is consolekit being used at all if I don't call ck-launch-session.

On another note I verified that it is lxde that is invoking lxpolkit. At the end of startlxde there is the following command to start lxde:
Code:

exec /usr/bin/lxsession -s LXDE -e LXDE

Prior to starting lxde there is not process called lxpolkit.


As a final note I added a "Xorg &" in the start lxde command just before the dbus session is created. I probably should name the script something else if I modify it because this is a well known script to start lxde.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2147

PostPosted: Fri 26 Apr 2019, 19:58    Post subject: Re: TazPup64 (pre-alpha12) - Looks Promising but I've done very
Subject description: little testing since I'm trying to figure out a GDbus error.
 

s243a wrote:
25 Aprl 19
TazPup64-PreAlpha-12.iso is looking promising but I've done very little testing on it (see (post)), since the GDbus error has been bothering me.


While troubleshooting the GDBus error I was using the following virtual-machine:
TazPup64-PreAlpha11.vdi

I think that darry beat me to the answer:

darry19662018 wrote:
Have found out! lxde now uses lxpolkit instead of polkit which needs to be disabled.

http://murga-linux.com/puppy/viewtopic.php?p=1026393#1026393

but I don't know all the details yet of how to implement it. Anyway some notes on this virtual machine:

1. In the lxde desktop I added various luanch items to the tint2 panel.
2. The poweroff and "exit Xorg" buttons in the shutdown script have been modified to work with the graphical version of slim. (see post)
3. From "PuppEX Bionic 64 bit", I added the following files:
Code:

/bin/xdg_autostart
/usr/bin/xdg_open #This is a symlink
/usr/local/bin/xdg_open

the result is now desktop files are autostarting applicaitons from the folders:
Code:

$HOME/.config/autostart/*.desktop
/etc/xdg/autostart/*.desktop

however, some of these desktop files are causing errors so I have some troubleshooting to do here.
4. Related to Item#3, I modified the pcmanfm.desktop file so that the pcmanfm desktop won't start if rox has already started.
5. In the save file I broke users spot and tux but root still works password=root. I don't think this is an issue with a fresh save file.


Edit 1 I've replaced the .vdi file so that one doesn't have to make the following fix:

Small Edit: For item#4 to work the file /usr/bin/pcmanfm_desktop should look like:
Code:

#!/bin/sh
if [ $(ps aux | grep -c 'rox-filler') -lt 1 ]; then
  pcmanfm --desktop
fi


before making the change you can see the rox desktop in jwm by killing pcmanfm --desktop. After you fix the above noted file, jwm should boot with only the rox desktop.

Edit 2 I've also got rid of the GDBus error message at startup using the fix mentioned at:
http://murga-linux.com/puppy/viewtopic.php?p=1026424#1026424
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2147

PostPosted: Sun 28 Apr 2019, 02:58    Post subject:  

I figured out how I broke users tux and spot. All users (i.e. user group and world) need both read and execute permissions for the lib folders. I found that out from the following post:
https://askubuntu.com/questions/307534/unable-to-su-with-root-bin-bash-permission-denied

not sure how I broke this and whether or not re-running the build script would have fixed this issue. However, for some reason this doesn't fix the whoami command for non-root users. This command needs to read the /etc/passwd file but I have it setup so all users can read this file. Therefore I don't know what the issue is.

Edit 1 I found out that you need execute permission on the directory to either cd into the directory or read a file within a directory. Sources:
https://community.oracle.com/thread/4178408

After adding execute permission to the /etc, the "whoami" command worked for user tux.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2147

PostPosted: Sun 28 Apr 2019, 05:09    Post subject:  

In the following virtualbox disk image you can now start jwm with users tux and spot.
TazPup64-PreAlpha-14.vdi

This is not the case for the ISOs which aren't as up to date as the virtualbox immage. I present them for refence but recommend waiting for the next ISO or two.
TazPup64-PreAlpha-14.iso
azPup64-PreAlpha-13.iso

However, if you wish to test with the latest iso then I recommend disabling some of the desktop files in :
/etc/xdg/autostart

and fixing the user permissions by making sure all lib folders, executable path folders and the etc folder have read and execute permissions for all users (i.e. user, group and world).

These fixes should already be made in the virtual machine save file.

Edit 1: I'm not sure where the permissions are getting set wrong. The permissions in the base_sfs look correct. I wonder if it might be an issue with the initrd or a weird quirk of virtualbox.

Edit 2: The premissions also look correct in initrd. Here is the section of initrd where it copies files:
https://github.com/puppylinux-woof-CE/woof-CE/blob/testing/initrd-progs/0initrd/init#L643

the -a option preserves permissions.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2147

PostPosted: Mon 29 Apr 2019, 14:51    Post subject: Re: TazPup64 (pre-alpha12) - Looks Promising but I've done very
Subject description: little testing since I'm trying to figure out a GDbus error.
 

The first post in this thread will be revamped. This post is for record purposes.

s243a wrote:
25 Aprl 19
TazPup64-PreAlpha-12.iso is looking promising but I've done very little testing on it (see (post)), since the GDbus error has been bothering me.


New ISO available[b] (23 Mar 2019):
TazPup64-PreAlpha-7.iso (338M)

I'm still not booting directly from the ISO. Instead I'm copying the files to the hard drive, booting with the screen=text option and starting the desktop with a script I made called "startx_jwm"

I added VLC in this ISO and the xine plugin for firefox. Some videos play on youtube but not all.

More info in post:
p=1022875#1022875

Edit: 25-Mar-19: a temparary link to the build-kit:
BuildKit(TazPup64)-PreAlpha7-un…lean.tar.gz but this is 1.7Gig because:
1. I didn't run the clean scripts
2. There are more packages in the archive then needed to build the ISO
3. I think I also accidently packed an iso or two into the archive.

Anyway, I'll make a much smaller versions of the build kit for easier sharing.

New ISO available (17 Mar 2019) :
TazPup64-PreAlpha-6.iso (324.5MB)

The ISO works for me and my computer is running much faster with this ISO than with Slack64-6.9.9.9. However, it is still very raw so I will likely be aware of most reported issues.

However, there are two things that I need help with (although I'll try to figure them out on my own). The big one is fixing the XDG field code issue. My work around was to modify the desktop file of pcmanfm and change "%U" to "~" in the execute command. pcmanfm isn't really needed at this point though because I am working with jwm and rox

However, I'm also trying to get lxde to work since I think that is what mistfire's TazPup uses. When the system is more mature, I will create one or more slimmer versions that only have one of these two window manager installed.

The other issue, which I need help with, is that for some reason the menus are double nested (e.g. utilities->utilities. I would like to put the most important applications in the first level of nesting and the other applications nested deeper in the menus. I think I have to dig into the menu templates to figure this out. Once I get this sorted out I can use PupMenu-6.2
(installed) to move applications around within the menu.

Changes since last release outlined at p=1022230#1022230

Previous 1st Post: (Info still applies but links are out dated)
=============================================

I have a semi working iso
https://www.dropbox.com/s/sywi28v38esbxsd/TazPup64-PreAlpha-5.iso?dl=0
323.4 MiB (There is a lot that I can trim out)

I tested booting from the files in the iso (not the iso its-self). I booted with boot option screen=text

To start jwm type:
Code:

startx_jwm


To start lxde type:
Code:

root/.xsession_lxde


Within jwm:
1. The file manager and terminal emulator work in the top panel (but the file manager does not work in the "bottom panel" (or desktop menu) `due to field code issues.
2. Firefox works in the bottom panel

To configure internet in the menu go to:
system -> system -> SliTaz Panel

and then go to the network tab. You can manually type in the information here. The process is a bit awkward. There is an easier tool to get it to work that I haven't tested yet.

So anyway, it's a start. I still recommend that people wait before trying it though.

The default file manager in jwm is rox but if you are in a terminal you can type "pcmanfm" to start pcmanfm"/

There is a build kit also available:
https://www.dropbox.com/s/cfhewxce26ak54n/BuildKit%28TazPup64%29-PreAlpha5.tar.gz?dl=0

I did make some (untested) code changes to the build kit though since this current ISO was made.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2147

PostPosted: Mon 29 Apr 2019, 15:13    Post subject:  

I think we're getting close to alpha quality with TazPup64-PreAlpha-15

Some notes, the ISO will automatically log you into tux in the lxde desktop. On the bottom left (in the panel) there is a red logout/shutdown/reboot button that looks like the power symbol. If you click on it you can log out and then log in as root in the jwm desktop. The password for root is "root".

To use gparted you must install gtkmm.
Code:

tazpkg get-install gtkmm


I recommend starting gparted from the command line. If for some reason you get an error try it one more time from the command line.

The puppy universal installer works. I verified after installing and creating a save file that tux still works but I think there is a catch. If you install any software (e.g. gtkmm) in the pfx=ram mode then creating a save file might mess up the permissions for non root users.

In puppy this is less of an issue because when running as root in puppy directors are created with user=root, group=spot. However, when running as root in TazPup64 new folders are created with user=root, group=root. In both cases new folders only have executable permissions for user and group (not world). If for instance you install a package which has a file in /etc then the default permissions will be assigned to /etc rather than the permissions given for the directories on the base sfs. However, if you first create the save file before installing any packages then the correct permissions are assigned to /etc as well as directories defined in the PATH variable and the folders in the LD_LIBRARY_PATH variable.

Well actually this is likely only also partly true. The only folders which will be assigned the correct permissions are those on the base sfs included in the ISO. The LD_LIBRARY_PATH variable in TazPup64 is designed to handle folder structures from a wide range of distributions but not all these LD_LIBRARY_PATH directors and also not all PATH directories are included int he base SFS. Therefore if you install an alien package, I cannot guarantee the permissions will be correct if the package installs files in a non standard folder.

One can either re-organize the package so that it installs in standard folders or verify the permissions are correct if files are installed in "alien" places.

Edit 1 The first post is updated with more concise instructions than this post.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2147

PostPosted: Mon 29 Apr 2019, 16:43    Post subject:  

Here's a ".vdi" file for virtualbox (with guest additions insalled):
TazPup64-PreAlpha-15.vdi
to use it add it you need to add it as one of the hard drives in a virtual machine.

I was wrong about having fixed the permission issues but hopfully I patched them in the ".vdi' file.

If you run as a user other than root, use the "su" command to make changes as root. Currently tazbox isn't working which allows a graphical version of su. I think this this is an issue with the yad package. I'll check to see if I'm missing any dependencies for yad. At this point running as root will be easier but users tux and spot should work.

I verified that you can log-in to lxde as tux and that the vbox guest services properly starts when doing so.

s243a wrote:
I think we're getting close to alpha quality with TazPup64-PreAlpha-15

Some notes, the ISO will automatically log you into tux in the lxde desktop. On the bottom left (in the panel) there is a red logout/shutdown/reboot button that looks like the power symbol. If you click on it you can log out and then log in as root in the jwm desktop. The password for root is "root".

To use gparted you must install gtkmm.
Code:

tazpkg get-install gtkmm


I recommend starting gparted from the command line. If for some reason you get an error try it one more time from the command line.

The puppy universal installer works. I verified after installing and creating a save file that tux still works but I think there is a catch. If you install any software (e.g. gtkmm) in the pfx=ram mode then creating a save file might mess up the permissions for non root users.

In puppy this is less of an issue because when running as root in puppy directors are created with user=root, group=spot. However, when running as root in TazPup64 new folders are created with user=root, group=root. In both cases new folders only have executable permissions for user and group (not world). If for instance you install a package which has a file in /etc then the default permissions will be assigned to /etc rather than the permissions given for the directories on the base sfs. However, if you first create the save file before installing any packages then the correct permissions are assigned to /etc as well as directories defined in the PATH variable and the folders in the LD_LIBRARY_PATH variable.

Well actually this is likely only also partly true. The only folders which will be assigned the correct permissions are those on the base sfs included in the ISO. The LD_LIBRARY_PATH variable in TazPup64 is designed to handle folder structures from a wide range of distributions but not all these LD_LIBRARY_PATH directors and also not all PATH directories are included int he base SFS. Therefore if you install an alien package, I cannot guarantee the permissions will be correct if the package installs files in a non standard folder.

One can either re-organize the package so that it installs in standard folders or verify the permissions are correct if files are installed in "alien" places.

Edit 1 The first post is updated with more concise instructions than this post.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2147

PostPosted: Tue 30 Apr 2019, 03:19    Post subject:  

I was having an issue where yad dialogs (e.g. those used in tazbox); were the yad dialog was closing on me when I started to type. Installing yad-html seemed to fix have fixed this (further testing needed). Prior to installing this I had yad-gtk3 installed. Both yad-html and yad-gtk3 seem to have a file called /usr/bin/yad. I don't know if these two files are different or not.

I do know that the yad dialog that was causing problems did have html in it (see below).

----------------

On another note based on the way I have permissions set up /usr/local/bin/default_packagemanager needs executable permissions for user, group and world. Previously, I had not set executable permissions for world because I didn't know I needed it. The alternative would be to have all users a member of some command group that had executable permissions.


------------------

Just for reference, here is the yad dialog that was caussing me problems:
Code:

    yad --fixed --title="$(_n 'SliTaz admin password')" --window-icon=$icon \
      --width=520 --on-top --center \
      --image=$icon --image-on-top \
      --text="$(_n 'Please enter root password (default root) to execute:')\n
<span foreground=\"red\"><tt><b>$(basename "$CMD1")</b></tt></span>\n" \
      --form \
      --field="$(_n 'Password:'):H" $PASSWD \
      --field="$(_n 'Autosave password'):CHK" $CHECKED \
      --button="gtk-ok:0" \
      --button="gtk-cancel:1"

which is found on line 85 to 94 of /usr/bin/tazbox.

Edit 1:
Now that I got tazbox working. The script "/usr/local/bin/default_packagemanager" sould be:
Code:

#!/bin/sh
if [ "`id -u`" -eq 0 ]; then
   exec tazpanel pkgs
else
  exec tazbox su tazpanel pkgs
fi


as a side-note, the virtuabox shared clipboard seems to work for root but not tux. Perhaps there are good reasons for it to be this way or maybe there is a way around it?

Edit 2 I also need to add executable permission for "world" on /usr/bin/wmexit.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2147

PostPosted: Wed 01 May 2019, 01:09    Post subject:  

s243a wrote:
Here's a ".vdi" file for virtualbox (with guest additions insalled):
TazPup64-PreAlpha-15.vdi
to use it add it you need to add it as one of the hard drives in a virtual machine.

this file has been updated (see notes below):

Quote:
If you run as a user other than root, use the "su" command to make changes as root. Currently tazbox isn't working which allows a graphical version of su. I think this this is an issue with the yad package. I'll check to see if I'm missing any dependencies for yad. At this point running as root will be easier but users tux and spot should work.

This issue has been fixed in the savefile within the virtual machine by installing yad-htlm with the command:
Code:

tazpkg get-install yad-html --forced


I've also for (the save file only):
1. populated items in the lxde desktop folder for spot, root and tux and called "tazbox su" in the run command where appropariate:
2. changed the desktop for user spot to jwm
3. made changes to the logout script called on the tint2 panel (running in lxde) so that it exits the window if and only if it was started from the console; whereas if the desktop was started from the graphical version of slim then it logs the user out instead of exiting the windows manager.
4. Fixed logout/wmexit issues with non root users.
Back to top
View user's profile Send private message Visit poster's website 
Lobster
Official Crustacean


Joined: 04 May 2005
Posts: 15544
Location: Paradox Realm

PostPosted: Wed 01 May 2019, 02:57    Post subject:  

Bravo Cool
Lobster interlude
I am using and getting used to LXDE on Raspberrian, which runs on the Raspberry Pi and x86 processors

Rolling Eyes
Normal pre-alpha service is now resumed Embarassed

_________________
Puppy on Raspberry Pi Release Candidate Cool
Ye Olde History, Barry Kauler Interview https://distrowatch.com/weekly.php?issue=20051114#interview Very Happy
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2147

PostPosted: Wed 01 May 2019, 15:07    Post subject:  

Lobster wrote:
Bravo Cool
Lobster interlude
I am using and getting used to LXDE on Raspberrian, which runs on the Raspberry Pi and x86 processors

Rolling Eyes
Normal pre-alpha service is now resumed Embarassed


I actually don't know much about the differences between lxde and jwm. I just included lxde because that is what is used in mistfire's version of tazpup and I incuded jwm because that is what puppy usually uses.

I find that I interact much more with the desktop than the window manager with the exception that jwm provides a panel by default whereas I'm not sure if lxde provides a default panel so I installed tint2 as the panel because I had problems with lxpanel.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2147

PostPosted: Wed 01 May 2019, 15:10    Post subject:  

s243a wrote:
s243a wrote:
Here's a ".vdi" file for virtualbox (with guest additions insalled):
TazPup64-PreAlpha-15.vdi
to use it add it you need to add it as one of the hard drives in a virtual machine.

this file has been updated (see notes below):

Quote:
If you run as a user other than root, use the "su" command to make changes as root. Currently tazbox isn't working which allows a graphical version of su. I think this this is an issue with the yad package. I'll check to see if I'm missing any dependencies for yad. At this point running as root will be easier but users tux and spot should work.

This issue has been fixed in the savefile within the virtual machine by installing yad-htlm with the command:
Code:

tazpkg get-install yad-html --forced


I've also for (the save file only):
1. populated items in the lxde desktop folder for spot, root and tux and called "tazbox su" in the run command where appropariate:
2. changed the desktop for user spot to jwm
3. made changes to the logout script called on the tint2 panel (running in lxde) so that it exits the window if and only if it was started from the console; whereas if the desktop was started from the graphical version of slim then it logs the user out instead of exiting the windows manager.
4. Fixed logout/wmexit issues with non root users.


I've updated the ".vdi" save file again to fix issues with rox-pinboard not starting for users root and spot when started via the graphical version of slim. See post.
http://murga-linux.com/puppy/viewtopic.php?p=1026847#1026847

I also made it so that on the rox pinboard, non root users could use the "package manager" and "puppy universal installer". This was done by making sure that "tazbox su" was called if the user wasn't root.

These changes will eventually be incorporated into a new ISO release.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2147

PostPosted: Fri 03 May 2019, 17:25    Post subject:  

Here are some more releases:
TazPup64-PreAlpha-16.iso
TazPup64-PreAlpha-17.iso

And .vdi files for Virtualbox (and other virtual machines/emulators):
TazPup64-PreAlpha16.vdi

PreAlpha17, is untested and I was exprerminting with the premissions in the .vdi for preALpha16. I recommend that people wait until I test PreAlpha17 and creat a .vdi file for PreAlpha17.

I added urxvt to PreAlpha17 because some people think it's essential. See thread:
http://murga-linux.com/puppy/viewtopic.php?t=116050

I also added vim because nano doesn't seem to work well for TazPup64.
Back to top
View user's profile Send private message Visit poster's website 
s243a

Joined: 02 Sep 2014
Posts: 2147

PostPosted: Tue 07 May 2019, 03:09    Post subject:  

Here are two .vdi (for virtualbox and other virtualizaiton/emulation tools):
TazPup64-PreAlpha-17-spot.vdi - auto logs into spot (jwm window manager)

TazPup64-PreAlpha-17.vdi (newer) - auto logs into tux (lxde window manager)

The one above that ends in "-spot" is older and it auto logs into spot because I broke the lxde desktop for tux in this version. My workaround was to log in as root and start tux's desktop using the su command. See thread:
http://murga-linux.com/puppy/viewtopic.php?t=116065

Somehow this seems to have fixed the issues with logging into tux (using the lxde desktop). I'm not sure why this fixed the issue but I might compare each .vdi file and see if I can identify the issue.

note: While I did some stuff to make things smoother for non-root users, it is probably still easy to run as root. For instance the virtualbox shared clipboard is currently only working as root.

Other Notes:
Also there are no passwords for tux and spot (just press enter for the password). The password for root is "root".

If you boot with the screen=text option (as root) you can type startlxde to start lxde or startx_jwm to start jwm. These commands may or maynot work with other users.

If you want to boot into text mode (i.e. boot parameter screen=text) and switch to another users destktop/WM, then follow the scrips in the thread:
http://murga-linux.com/puppy/viewtopic.php?t=116065
Back to top
View user's profile Send private message Visit poster's website 
Display posts from previous:   Sort by:   
Page 6 of 7 [92 Posts]   Goto page: Previous 1, 2, 3, 4, 5, 6, 7 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Derivatives
Jump to:  

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


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.2705s ][ Queries: 11 (0.0189s) ][ GZIP on ]