(OLD) (ARCHIVED) Puppy Linux Discussion Forum Forum Index (OLD) (ARCHIVED) Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info

This forum can also be accessed as http://oldforum.puppylinux.com
It is now read-only and serves only as archives.

Please register over the NEW forum
and continue your work there. Thank you.

 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups    
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 29 Sep 2020, 05:02
All times are UTC - 4
 Forum index » House Training » HOWTO ( Solutions )
How to debug rc.sysinit (puppy boot problems)
Moderators: Flash, Ian, JohnMurga
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
Page 1 of 1 [1 Post]  
Author Message

Joined: 20 Oct 2005
Posts: 451
Location: Boston MA USA

PostPosted: Fri 23 Dec 2005, 19:13    Post subject:  How to debug rc.sysinit (puppy boot problems)  

How to debug Puppy boot

What are you going to do if your new Puppy installation won't boot? Start by having some success; use the LiveCD version on good working computers, do some easy/simple Puppies first!

But when you decide to dig in and do hard advanced installs:
You probably want to start by searching the Forum for other people with the same problems. Make sure what you are trying should work, and that you are following all relevant instructions.

Try to figure out which phase of the boot process is failing, and concentrate on learning more about that aspect. You may have to learn as much as possible about how Puppy works; use the Wiki.

The messages that scroll by on the screen might help, but there is no easy way to study them. If your pup gets far enough, the command line that is passed from the bootloader should be in /proc/cmdline, and the log from the kernel/init process in /var/log/messages.

It might be possible to set the boot to serial console and capture the startup messages on another computer.

If you decide that the core kernel/init is starting OK and suspect the problem is in the Puppy-specific part of the boot process, you are facing quite a challenge. You must get comfortable with the Linux command line interface and learn general ash/bash shell troubleshooting:
How to debug ash/bash shell scripts

You will have to learn how to modify the rc.sysinit script, the first part of Puppy proper that is run. To make changes in this and try them, you will have to remaster image.gz. This is one way to do that:
# cd /
# mkdir mountdir
# cp /mnt/home/image.gz ./
# gunzip image.gz
# mount -o loop image mountdir
### edit rc.sysinit here ###
# umount mountdir
# gzip image
### copy image.gz back to where it belongs, with the name you want to give it

You have to learn to walk before you can run; you will need to work with the Linux CLI a while before you are likely to succeed at this.

But debugging requires trying many many things. Often you have to make hundreds of tests. You don't want to have to go through the whole image.gz remastering hundreds of times -- what to do?

The answer is to make powerful general purpose modifications in sysinit. Ideally they would not interfere with normal operation, and could be included in future standard versions of Puppy.

This is what I added onto the front of sysinit:
echo "22dec05 rc.sysinit kd"
ln -s /bin/busybox /bin/tee
ln -s /bin/busybox /bin/mkfifo
ln -s /bin/busybox /bin/hexdump

#if [[ -n "$1" ]]; then $1 = "="; fi #prevent problems with null string

SBUG=${SBUG}= #prevent problems with null string
echo $SBUG
if ( expr index $SBUG v ); then set -v ; fi
if ( expr index $SBUG x ); then set -x ; fi
if ( expr index $SBUG 1 ); then exec 1>sysinit.log ; fi
if ( expr index $SBUG 2 ); then exec 2>sysinit2.log ; fi
if ( expr index $SBUG 3 ); then exec 1>sysinit.log 2>&1 ; fi

if ( expr index $SBUG D ); then
while [ "$xxcc" ]; do
 echo -n $LINENO "DEBUG: ENTER or type a command: "
 read xxcc
 eval $xxcc

echo $SBUG processed

Under normal conditions this added code has no effect. But you can now add SBUG=vx123D parameter flags to your bootloader command line. The -vx flags let you see what the shell is doing step by step. The 123 switches would let you create log files, but the D switch is by far the most important, and far overshadows the rest. This lets you use the shell interactively right at the start of sysinit, and you can do almost anything at that point. When you are finished, just enter a blank line and the standard Puppy sysinit will continue.

Using this tool, you can easily dump all the current variables with the set command, and manually enter/change any Puppy parameters, such as PHOME=hda1. You can turn the flags on and off with set -vx. And you can try to redirect output into log files with exec 2>logfile2. But attempts to redirect both stdout and stderr into files at the same time seems to malfunction, presumably because of the primitive/delicate state of Puppy at this point. And whatever you redirect will not show up on the screen, leaving you blind. But turning on -sx and sending it to a logfile is very powerful, gives you reams of detailed info to study. And if you can get a similar dump of a successful boot, and then run a diff comparison, you can quickly spot key differences.

It would be great if someone could figure out how to have sysint debug always available and invokable without requiring any changes in the bootloader parameters, some kind of live check on the keyboard for a special key combination at the start of sysinit, that quickly continues automatically under normal conditions. And wonderful if there were some way to automatically add/overlay code to sysinit dynamically at boot time, or even replace sysinit entirely if certain files were present/provided in certain places, without ever having to remaster image.gz.

My hope is to someday understand Puppy sysinit well enough to be able to add options to completely manually control the boot process, if that is appropriate.

*** See also: ***

What are the possible Puppy boot parameters (to be passed from the Gujin/tiny command line, or GRUB or LILO)?

Gujin command line length problems

How to give birth to puppy by hand -- doing things the hard way

Change Gujin from CONFIG.SYS to AUTOEXEC.BAT

How to pass named variables to ash/bash shell scripts

Kernel panic

How to force mount usr_cram.fs

How to force load alternate text editor mp - Minimum Profit

BusyBox Suggestions

How to capture command line screen text output in a logfile and still have it show on the screen

ash/bash shells: which does Puppy use?

What is the best general purpose Linux wiki?

Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [1 Post]  
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic
 Forum index » House Training » HOWTO ( Solutions )
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.1060s ][ Queries: 11 (0.0793s) ][ GZIP on ]