Bootscripts clean up

[gerard@…]

Clean up the bootscripts, rename directories that don't make sense (network-scripts), etc.

[gerard@…]

renamed network-scripts into nic-config (for now). More work needs to be done such as implementing ifup/ifdown script (see lfs-discuss, may 12th and thereabouts for the thread about it called "Network scripts").

[gerard@…]

Suggestions for enhancing the functions bootscript

[gerard@…]

Reassigning to lfs-book (aka NEW, but since you can't select NEW in bugzilla this'll have to do. I'm taking distance from this bug for now, I'll work on it again later or whoever gets to it first)

[gerard@…]

Hmm it did change to NEW status. When was that fixed in bugzilla?

[gerard@…]

Added [ ATTN ] (instead of [WARNING] - attn ligns up better with OK and FAILED).

When you attemp to start a service that's arleady running or stop a service that's not running, it'll not print FAILED anymore but [ ATTN ] along with "Already running" or "Not running".

Remaining clean-up is adding the ifup and ifdown scripts

[gerard@…]

example what the new ethnet script will look like, plus sample ifup/ifdown scripts

[gerard@…]

Check&consider new boot concept ​http://www.winterdrache.de/linux/index.html

[gerard@…]

New code for rc and rcS script to do better sorting. This will take away from the requirement of having a fixed number of priority digits:

One extra requirement: we'll have to move /usr/bin/sort to /bin (textutils package). Good thing is that this it is not forbidden to do so by the FHS.

for i in ls bah/* | sed 's/^.*\/[S|K]\(.*[0-9]\)\(.*\)/\1-\2/' | sort -g do

eval `echo $i | sed

's/^{\(.*[0-9]\)-\(.*\)/stop=K\1\2;previous_start=S\1\2/'`}

echo $stop $previous_start

done :(03:58pm ~): ls bah/

[gerard@…]

Saving for after the release of lfs-3.0

[gerard@…]

Before I forgot: add lil script to remove things like /tmp/* /var/run/*

[gerard@…]

don't use any stdout and stderr redirection. Use this to move a line up to dump the OK and FAILED messages.

move up a line: echo -en "\033[<number>A" (number is optional)

[gerard@…]

perhaps add a short delay of 2 or 3 seconds in sendsignals script between sending TERM and KILL

[gerard@…]

that delay should be longer if you're on a heavily loaded system. Add a comment perhaps "the heavier your system is used, the longer you let is pause here"

[gerard@…]

gosh this one is starting to look like a real scrap book...

this one disappeared on me: rc script should not silently ignore broken symlinks. Print out warning instead

[gerard@…]

%PPID is superfluous in pidof because it is the same as $$ with the only difference that $$ is inserted by the shell while %PPID is interpreted by pidof.

Why is the test if [ -d /proc/$apid ] being done? Seems rather pointless. Aren't those directories where pidof gets its information in the first place?

Why are absolute paths being used everywhere (except for the grep command in ethnet)? Even /bin/kill is being used rather than bash's kill builtin.

[gerard@…]

why localnet before checkfs/mountfs ?

[gerard@…]

why seperate rcS script, we can just call "rc S" and treat it like the run level it is

[gerard@…]

From Jeff Neitzel:

I noticed the statusproc function has a couple errors making it not work correctly when checking for stale PID files. I fixed it. Changes are marked below. The complete function, with comments, is attached here as statusproc.gz . # redirect usage message to stderr echo "Usage: status {program}" >&2 # need basename of executable to find PID in /var/run base=${1##*/}

# need use $base here instead of $1 . $1 doesn't work for getting

# proper PID file from /var/run .

if [ -f /var/run/$base.pid ]; then

# changed /usr/bin/head -1 to cat

pid=$(cat /var/run/$base.pid);

if [ -n "$pid" ]; then

echo "$1 is not running, but /var/run/$base.pid exists.";

return 1;

fi;

else

echo "$1 is not running.";

fi

[gerard@…]

about statusproc: how about just check for the file's existance

[gerard@…]

in kbd bootscript, check if LAYOUT is set in the sysconfig/keyboard file, then error if it's empty (else loadkeys will just wait indefinitely if LAYOUT isn't set)

[gerard@…]

from matthias:

A while ago I proposed that we should use either COLUMNS=$(stty) or if that does not work COLUMNS=$(stty 0>&1) . I want to correct myself. The 2nd variant does not work. While typing stty 0>&1 on the console works because stdout is the console, it does not work inside $(...) because here stdout is not the console but a pipe that the shell uses to catch the messages. Using 0>&2 would work, though because stderr is not redirected bt $(...).

[gerard@…]

From Matthias:

0>&1 makes stdin become a copy of stdout. It's not really useful for programs that actually read from stdin (because you can't normally read from stdout). But stty reads the terminal settings which is a different matter. What we want to achieve in the boot script is to find out the width of our terminal and store it in COLUMNS. There are 3 possible ways COLUMNS=$(stty size) #analyses stdin COLUMNS=$(stty size 0>&1) #analyses stdout COLUMNS=$(stty size 0>&2) #analyses stderr The second is what we want to do but it doesn't work because the stdout we want to analyse is the stdout of the boot script (our console) that contains the command. However as I already mentioned, the $(...) redirects stdout, so that it no longer connects to the console. The first variant is the simplest of course and should be used if it works. Whether it works depends on whether sysvinit opens the console as stdin for the scripts it starts. It should certainly do so. The 3rd variant is like the 2nd variant only that it works on stderr. The $(...) construct does not redirect stderr, so this is the stderr of the script, which should be connected to the console.

[gerard@…]

From matthias:

If you would look at the LFS boot scripts you would see that they already take this into account. They do use an intermediate variable SIZE, though, but I'm no fan of intermediate variables, so I do COLUMNS=$(stty size) COLUMNS=${COLUMNS##* } (No, the space does not need to be escaped) But as the second line is not relevant to this discussion, I omitted it.

[gerard@…]

matthias's version of bootscripts using simpleinit

[gerard@…]

Here is what happened to me with the lfs checkfs script:

One partition could not be checked because of superblock problems,

manually running this did also not work.

Exit caused a reboot -f as given in the script.

And the same procedure began again ...

I understand lfs is not for newbies who don't know what to do in

this case and I had no problems with it, but should this maybe

be considered to be changed? Just a thought.

A valid point. Personally I use halt if checkfs fails without calling sulogin before it. I think it is the best way. As someone else has reported, sulogin will grant root access without asking for password if the password database is broken which is a security issue if your system boots up unattended. And by calling halt, when the sysadmin finally comes to check on the system, the message (could be something like: "Hard disk broken badly. If you don't know what to do, go find someone who does.") will still be there. The admin can then reboot manually with init=/bin/sh and fix stuff. Someone who doesn't have the necessary knowledge will be prevented from logging in and doing more harm to the system. And the confusion factor should be lower.

[gerard@…]

if reiserfs only system, modify checkfs script (e2fsprogs may not be installed)

[gerard@…]

perhaps split up sysklogd in two scripts (syslogd and klogd)

[gerard@…]

perhaps add USER variable so daemons and the like can be run as non-root

[gerard@…]

* Bug 182 has been marked as a duplicate of this bug. *

[gerard@…]

in the ethnet script add a comment that network based mounts should be unmounted in the ethnet script, since it will freeze the mountfs script (network gone, nfs umount will not work, or take a very long time to timeout, etc)

[gerard@…]

make sure 'halt' just halts the system, but 'poweroff' turns power off. Sometimes halting the system without powering down is preferable (say when fsck fails, user hits enter, the system halts but the message is still there for a sysadmin to read)

[gerard@…]

New bootscripts (no ethnet included)

[gerard@…]

* Bug 182 has been marked as a duplicate of this bug. *

[gerard@…]

Beast has finally been slain. New bootscripts included in the book now. There's still some work left to be done on it and the tarball needs a README file which explains how the script works, what to change where and when, all the features that are available but may not be obvious from the one sysklogd example script, etc. This actually belong to bug #34 so we don't need to work on it here anymore.

This bug should be closed. I know there will be changes made to the scripts, don't reopen this bug though when they come in. Let's start a fresh bug number to take care of future stuff.

[markh@…]

as is said in the above comment; the new bootscripts are in the book - if/when bugs come in, we'll open a new bug as opposed to reopening this (now very messy) one. closing this bug.