allow bypassing Xwindows start

What features/apps/bugfixes needed in a future Puppy
Post Reply
Message
Author
kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

allow bypassing Xwindows start

#1 Post by kethd »

Experimenting with Puppy on low-end computers, I am thinking it would be nice if there were a standard sysinit ability to NOT start Xwin, just boot to a command line (with everything loaded and symlinked etc as usual). On old slow computers, starting Xwin can take quite a while -- and presumably requires more of various resources too.

One way to do this would be to add a boot parameter, like PXWIN. If it were set to "no" or "false", don't start. Or there could be PNOXWIN, which would bypass if it were defined to anything.

But it should also be possible to do this from future standard CDs, without remastering, in which case there is no way to pass parameters. Another reason to have sysinit do a no-wait read of the keyboard -- to allow taking manual control, and be able to choose whether to start Xwin.

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#2 Post by MU »

mv /usr/X11R6/bin/xwin /usr/X11R6/bin/xwin2

Then Puppy stops in console at next boot, and you must type "xwin2" to start X.
Mark

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#3 Post by kethd »

MU -- Thanks for pointing out that as soon as PUPXXX is mounted and unioned onto the filesystem, all kinds of things can be modified, like renaming XWIN to abort the autolaunch -- I would have never thought of that!

User avatar
MU
Posts: 13649
Joined: Wed 24 Aug 2005, 16:52
Location: Karlsruhe, Germany
Contact:

#4 Post by MU »

This method will not work, if X refuses to work, but does not fall back to a console (System freezes, you must Power off completely).

In that case:
When Puppy boots, hit CTRL-C when it says "copying usr_cram.fs to /".
Then you have a minimalistic console.

Now type:
mkdir /root/.usr
mkdir /root/.usr/X11R6
mkdir /root/.usr/X11R6/bin
echo empty >/root/.usr/X11R6/bin/xwin
reboot

This will create a "corrupted" xwin.
But you still can access the original file.
After reboot, Puppy will load usr_cram.fs, and stop when it wants to run X.
But from now on you have a "full" console with the completely mounted filesystem.

Now you can type:
cp /.usr_cram/X11R6/bin/xwin /usr/X11R6/bin/xwin2
reboot


After reboot, you still will get the console, but now you can (try to) start X with the command
xwin2

If this freezes your system, try the typical troubleshooting:
xorgconfig
or
mp /etc/X11/xorg.conf
or run the xorgwizard.

Mark

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#5 Post by BarryK »

1.0.7 is supposed to detect a forced reboot and stop at the commandline.

This was one of the requests for 1.0.7, that I implemented.

You should be able to test it by forcibly rebooting the PC while X is running, say by pressing the PC's reset button.

To make this the default behaviour, edit /usr/X11R6/bin/xwin,
comment-out line 375.

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#6 Post by kethd »

These are all very interesting experiments to play with...

And remind me of a related question:
By accident, I discovered that hitting CTRL-ALT-DEL one or two times was a very convenient way to reboot Puppy. And I was perfectly happy...
Until I noticed once that when I rebooted some msgs flashed by complaining that the filesystems had not unmounted cleanly, and were being checked. So then I thought the 3-fingered salute was not really copacetic, so I stopped doing it.

Is CTRL-ALT-DEL safe? If it endangers the filesystems, what exactly are the dangers, and are there work-arounds (like sync)?

kethd
Posts: 451
Joined: Thu 20 Oct 2005, 12:54
Location: Boston MA USA

#7 Post by kethd »

Exploring low-end pups, I did have to abort a start, and when I rebooted xwin did not auto-start -- that was good!

I did try to force this later, by renaming xwin to xwin2. This did work -- except that then sometimes the desktop background did not come up. Which would be fine -- except that it defaulted to a checkerboard hash. Which made the desktop icons illegible... I was able to set the desktop background to a light solid color. And the desktop seemed to start faster with no background graphics.

But it would be nice if the background defaulted to white or a solid light color, instead. And I do not understand why anything happened to the background.

I looked into editing the xwin script, but the reference to line 375 did not seem to make sense (maybe because I am still using 107b), and I couldn't easily see how to diddle the script to force xwin never to autostart. May I suggest that you invent a file name, like xwinmanual or xwinnostart or xwinnoauto, such that if such a file exists standard autostart behavior is inhibited?

Thanks for your help, my experiments currently are chronicled at:
http://www.murga.org/%7Epuppy/viewtopic.php?t=4930

Post Reply