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.
allow bypassing Xwindows start
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
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
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
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.
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.
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)?
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)?
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
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