You are not logged in.

#51 2004-12-22 16:33:34

IceRAM
Member
From: Bucharest, Romania
Registered: 2004-03-04
Posts: 772
Website

Re: Fastboot Initscript Patches

z4ziggy wrote:

actually, ldconfig is already running after each pacman package install... im guessing they'd put ldconfig in the rc.sysinit to avoid the initial ldconfig execution delay on pacman execution... this makes pacman looks faster tongue
i myself removed it toally from rc.sysinit, since pacman will execute it anyway once its needed... who needs the 20 second delay at each startup..  8)

Oh.. so that's not really needed there... why didn't anyone say that?
I saw it as a critical thing. Is this "pacman thing" the only why reason updating shared libraries stays there?

Offline

#52 2004-12-22 16:41:51

dp
Member
From: Zürich, Switzerland
Registered: 2003-05-27
Posts: 3,378
Website

Re: Fastboot Initscript Patches

z4ziggy wrote:

actually, ldconfig is already running after each pacman package install... im guessing they'd put ldconfig in the rc.sysinit to avoid the initial ldconfig execution delay on pacman execution... this makes pacman looks faster tongue
i myself removed it toally from rc.sysinit, since pacman will execute it anyway once its needed... who needs the 20 second delay at each startup..  8)

i did the same long time ago

my suggestion (as now it's more than only me doing this) is, that there is an option in rc.conf that let's you disable ldconfig at boottime


The impossible missions are the only ones which succeed.

Offline

#53 2004-12-22 17:52:08

IceRAM
Member
From: Bucharest, Romania
Registered: 2004-03-04
Posts: 772
Website

Re: Fastboot Initscript Patches

dp wrote:

my suggestion [...] is, that there is an option in rc.conf that let's you disable ldconfig at boottime

There IS an option in rc.conf? Hmm..

Offline

#54 2004-12-22 18:33:18

phrakture
Arch Overlord
From: behind you
Registered: 2003-10-29
Posts: 7,879
Website

Re: Fastboot Initscript Patches

IceRAM wrote:
dp wrote:

my suggestion [...] is, that there is an option in rc.conf that let's you disable ldconfig at boottime

There IS an option in rc.conf? Hmm..

I think he meant there *should be* an option....

Offline

#55 2004-12-22 21:38:58

dp
Member
From: Zürich, Switzerland
Registered: 2003-05-27
Posts: 3,378
Website

Re: Fastboot Initscript Patches

phrakture wrote:
IceRAM wrote:
dp wrote:

my suggestion [...] is, that there is an option in rc.conf that let's you disable ldconfig at boottime

There IS an option in rc.conf? Hmm..

I think he meant there *should be* an option....

very sorry because of my bad english --- yes: there should be one


The impossible missions are the only ones which succeed.

Offline

#56 2004-12-23 07:01:07

dtw
Forum Fellow
From: UK
Registered: 2004-08-03
Posts: 4,439
Website

Re: Fastboot Initscript Patches

yes there should

Offline

#57 2004-12-23 16:13:22

dp
Member
From: Zürich, Switzerland
Registered: 2003-05-27
Posts: 3,378
Website

Re: Fastboot Initscript Patches


The impossible missions are the only ones which succeed.

Offline

#58 2004-12-23 18:51:08

LavaPunk
Member
Registered: 2004-03-05
Posts: 129

Re: Fastboot Initscript Patches

There has been quite a bit of talk of removing an update to ones shared library links at bootup, to decrease boot time.  I reboot my box plenty so this sounds great to me, but I am nervous about just removing something that deals with the boot cycle.  I love the fact that I haven't needed a "reinstall" of Arch in over 6 months and prefer to keep it that way.  So for me and anybody else who may not have the exact no how I ask:

In /etc/rc.sysinit can I comment out or delete these lines?

if [ "$FASTBOOT" != "yes" -a "$FASTBOOT" != "YES" ]; then
        status "Updating Shared Library Links" /sbin/ldconfig
fi

I assume this is all that needs to be played with, but I wanted to make sure that I wasn't touching anything else.

And if this is done it is enough to just allow pacman to do it after updates correct?  I should I be running it using cron more often?

Offline

#59 2004-12-25 06:02:16

kryo
Member
Registered: 2004-04-13
Posts: 40

Re: Fastboot Initscript Patches

actually, ldconfig is already running after each pacman package install... im guessing they'd put ldconfig in the rc.sysinit to avoid the initial ldconfig execution delay on pacman execution... this makes pacman looks faster tongue
i myself removed it toally from rc.sysinit, since pacman will execute it anyway once its needed... who needs the 20 second delay at each startup.. Cool

I tried to comment out ldconfig from rc.sysinit, but whenever I do so, the alsamixer script from /etc/rc.d claims to not find any soundcards during boot and fails to restore my soundcard volumes.

I can manually alsamixer the volumes up when I log in.

This problem only happens when I comment out "Updating Shared Library Links" from rc.sysinit. Anyone know why this happens?

Btw, it's an sblive and modules are loaded via rc.conf

Offline

#60 2004-12-26 07:52:10

dtw
Forum Fellow
From: UK
Registered: 2004-08-03
Posts: 4,439
Website

Re: Fastboot Initscript Patches

ah, dude! that's what the problem is then!  i have the same issue suddenly but i thought it was because I had switched to udev.  however, if i run the alsamixer daemon after i login it works fine.  i also i have exactly the same problem with the splash daemon posted else where on the boards, which sets all your vc to fbsplash bakgrounds.  if i run it after i log in it works fine.

my theory is the /dev has not been fully populated when alsamixer and splash run, which means it can't find the devs, a few seconds later they are there and the daemons work fine - the reason why the ldconfig maybe affecting it is because ldconfig gives /dev longer to be populated before the other daemons run.  possibly udev takes longer to populate /dev also?

how does that sounds guru?  how can we fix it?

Offline

#61 2004-12-31 19:12:33

Dusty
Schwag Merchant
From: Medicine Hat, Alberta, Canada
Registered: 2004-01-18
Posts: 5,986
Website

Re: Fastboot Initscript Patches

dibblethewrecker wrote:

my theory is the /dev has not been fully populated when alsamixer and splash run, which means it can't find the devs, a few seconds later they are there and the daemons work fine - the reason why the ldconfig maybe affecting it is because ldconfig gives /dev longer to be populated before the other daemons run.  possibly udev takes longer to populate /dev also?

how does that sounds guru?  how can we fix it?

I'm having the same problem, and support your theory. I tried adding a sleep call to the alsamixer script and it fixes the problem.  This indicates that there is indeed a race condition here.

I thought that perhaps running hotplug before alsamixer would solve it, but it doesn't. Not running hotplug at all, and allowing udev to take care of it internally also does not solve the problem.

I don't know much about udev; it may be possible to force it to load the sound devices statically, instead of waiting for the module to load (but this is kind of dumb), or the alsamixer script may need to be modified to wait until the dev tree is populated... a simple loop that repeats the action if there is an error might suffice, or you could just use a sleep call and background the alsamixer daemon...

but these are all very ugly hacks. I'm certain there must be a better way to do it; alsamixer musn't be the only daemon that requires udev to have devices set up...
Dusty

Offline

#62 2005-01-01 10:33:26

dtw
Forum Fellow
From: UK
Registered: 2004-08-03
Posts: 4,439
Website

Re: Fastboot Initscript Patches

well, i think that gensplash background setting script I mention may also be one, of course big_smile

Offline

#63 2005-01-01 15:58:55

Dusty
Schwag Merchant
From: Medicine Hat, Alberta, Canada
Registered: 2004-01-18
Posts: 5,986
Website

Offline

#64 2005-01-02 06:41:54

dtw
Forum Fellow
From: UK
Registered: 2004-08-03
Posts: 4,439
Website

Re: Fastboot Initscript Patches

http://bbs.archlinux.org/viewtopic.php? … highlight=

sorry dusty, you might also like to check the syntax of the splash.d script - it maybe flawed...

would it also just be possible for the script to check for the existence of the particular /dev/device and sleep if it cannot find it before trying again?

i know that is essentially just what you suggested dusty i was just making my understanding explicit

Offline

#65 2005-01-02 17:11:22

Dusty
Schwag Merchant
From: Medicine Hat, Alberta, Canada
Registered: 2004-01-18
Posts: 5,986
Website

Re: Fastboot Initscript Patches

dibblethewrecker wrote:

would it also just be possible for the script to check for the existence of the particular /dev/device and sleep if it cannot find it before trying again?

Yeah, that seems to work fine, as long as you background the daemon in question (otherwise you'll get annoyed waiting for the devices to be created).

I'm sure there must be some way to tell udev to create the specific devices on startup, instead of waiting for the modules to load and creating them dynamically. I don't have much knowledge of udev though, so I'm not sure. I may be wrong, because the devices are theoretically not much use unless they have kernel modules attached anyway, right???

I wonder if compiling the sound devices into the kernel instead of using a module would make a difference.

Anyway, I'm just sleeping in my alsamixer script for now. It works for me, I just don't like how ugly it is as a general purpose fix.

Dusty

Offline

#66 2005-01-03 01:26:39

punkrockguy318
Member
From: New Jersey
Registered: 2004-02-15
Posts: 711
Website

Re: Fastboot Initscript Patches

Hmm... In ubuntu, there is a unit of startup that says "Creating udev Device nodes"... Hmm i'll take a look into that and post what I find


If I have the gift of prophecy and can fathom all mysteries and all knowledge, and if I have a faith that can move mountains, but have not love, I am nothing.   1 Corinthians 13:2

Offline

#67 2005-01-03 01:30:41

punkrockguy318
Member
From: New Jersey
Registered: 2004-02-15
Posts: 711
Website

Re: Fastboot Initscript Patches

Here's the udev init.d/script from ubuntu.. I didn't do too much research on it, but I figured it'd be a good resource:

#!/bin/sh -e

PATH="/sbin:/bin"

# defaults
tmpfs_size="5M"
udev_root="/dev/"

[ -x /sbin/udevstart ] || exit 0

. /etc/udev/udev.conf
. /lib/lsb/init-functions

case "$(uname -r)" in
  2.[012345].*|2.6.[0-7]|2.6.[0-7][!0-9]*)
    log_failure_msg "udev requires a kernel >= 2.6.8, not started."
    exit 0
    ;;
esac

if ! grep -q '[[:space:]]tmpfs$' /proc/filesystems; then
  log_failure_msg "udev requires tmpfs support, not started."
  exit 0
fi

if [ ! -e /proc/sys/kernel/hotplug ]; then
  log_failure_msg "udev requires hotplug support, not started."
  exit 0
fi

##############################################################################

# we need to unmount /dev/pts/ and remount it later over the tmpfs
unmount_devpts() {
  if mountpoint -q /dev/pts/; then
    umount -l /dev/pts/
  fi

  if mountpoint -q /dev/shm/; then
    umount -l /dev/shm/
  fi
}

# mount a tmpfs over /dev, if somebody did not already do it
mount_tmpfs() {
  if grep -E -q "^[^[:space:]]+ /dev tmpfs" /proc/mounts; then
    return 0
  fi

  # /.dev is used by /sbin/MAKEDEV to access the real /dev directory.
  # if you don't like this, remove /.dev/.
  [ -d /.dev ] && mount -n --bind /dev /.dev

  log_begin_msg "Mounting a tmpfs over /dev..."
  mount -n -o size=$tmpfs_size,mode=0755 -t tmpfs none /dev
  log_end_msg $?
}

# I hate this hack.  -- Md
make_extra_nodes() {
  grep '^[^#]' /etc/udev/links.conf | 
  while read type name arg1; do
    [ "$type" -a "$name" -a ! -e "/dev/$name" -a ! -L "/dev/$name" ] ||continue
    case "$type" in
      L) ln -s $arg1 /dev/$name ;;
      D) mkdir -p /dev/$name ;;
      M) mknod --mode=600 /dev/$name $arg1 ;;
      *) log_warning_msg "links.conf: unparseable line ($type $name $arg1)" ;;
    esac
  done
}

##############################################################################

if [ "$udev_root" != "/dev/" ]; then
  log_warning_msg "WARNING: udev_root != /dev/"

case "$1" in
  start)
    if [ -e "$udev_root/.udevdb" ]; then
      if mountpoint -q /dev/; then
        log_failure_msg "FATAL: udev is already active on $udev_root."
        exit 1
      else
        log_warning_msg "WARNING: .udevdb already exists on the old $udev_root!"
      fi
    fi
    mount -n -o size=$tmpfs_size,mode=0755 -t tmpfs none $udev_root
    log_begin_msg "Creating initial device nodes..."
    udevstart
    log_end_msg $?
    ;;
  stop)
    start-stop-daemon --stop --exec /sbin/udevd --oknodo --quiet
    log_begin_msg "Unmounting $udev_root..."
    # unmounting with -l should never fail
    if umount -l $udev_root; then
      log_end_msg 0
    else
      log_end_msg 1
    fi
    ;;
  restart|force-reload)
    $0 stop
    $0 start
    ;;
  *)
    log_success_msg "Usage: /etc/init.d/udev {start|stop|restart|force-reload}"
    exit 1
    ;;
esac

  exit 0
fi # udev_root != /dev/

##############################################################################
# When modifying this script, do not forget that between the time that
# the new /dev has been mounted and udevstart has been run there will be
# no /dev/null. This also means that you cannot use the "&" shell command.

case "$1" in
  start)
    if [ -e "$udev_root/.udevdb" ]; then
      if mountpoint -q /dev/; then
        log_failure_msg "FATAL: udev is already active on $udev_root."
        exit 1
      else
        log_warning_msg "WARNING: .udevdb already exists on the old $udev_root!"
      fi
    fi
    unmount_devpts
    mount_tmpfs
    [ -d /proc/1 ] || mount -n /proc
    log_begin_msg "Creating initial device nodes..."
    udevstart
    log_end_msg $?
    make_extra_nodes
    # some other packages depend on the presence of this file
    : > /dev/.udev.tdb
    ;;
  stop)
    start-stop-daemon --stop --exec /sbin/udevd --oknodo --quiet
    unmount_devpts
    log_begin_msg "Unmounting /dev..."
    # unmounting with -l should never fail
    if umount -l /dev; then
      log_end_msg 0
      umount -l /.dev || true
      /etc/init.d/mountvirtfs start
    else
      log_end_msg 1
    fi
    ;;
  restart|force-reload)
    start-stop-daemon --stop --exec /sbin/udevd --oknodo --quiet
    log_begin_msg "Recreating device nodes..."
    udevstart
    make_extra_nodes
    log_end_msg $?
    ;;
  *)
    echo "Usage: /etc/init.d/udev {start|stop|restart|force-reload}"
    exit 1
    ;;
esac

exit 0

I hope that will shed some light on the subject!


If I have the gift of prophecy and can fathom all mysteries and all knowledge, and if I have a faith that can move mountains, but have not love, I am nothing.   1 Corinthians 13:2

Offline

#68 2005-01-03 01:39:18

z4ziggy
Member
From: Israel
Registered: 2004-03-29
Posts: 573
Website

Re: Fastboot Initscript Patches

can u please add the contents of "/etc/udev/links.conf" ?

Offline

#69 2005-01-03 01:52:01

punkrockguy318
Member
From: New Jersey
Registered: 2004-02-15
Posts: 711
Website

Re: Fastboot Initscript Patches

z4ziggy wrote:

can u please add the contents of "/etc/udev/links.conf" ?

no problem...

# This file does not exist. Please do not ask the debian maintainer about it.
# You may use it to do strange and wonderful things, at your risk.

L fd        /proc/self/fd
L stdin        /proc/self/fd/0
L stdout    /proc/self/fd/1
L stderr    /proc/self/fd/2
L core        /proc/kcore
L sndstat    /proc/asound/oss/sndstat
L MAKEDEV    /sbin/MAKEDEV

D pts
D shm

# Hic sunt leones.
M ppp        c 108 0
D loop
M loop/0    b 7 0
D net
M net/tun    c 10 200

If I have the gift of prophecy and can fathom all mysteries and all knowledge, and if I have a faith that can move mountains, but have not love, I am nothing.   1 Corinthians 13:2

Offline

#70 2005-01-03 05:19:39

z4ziggy
Member
From: Israel
Registered: 2004-03-29
Posts: 573
Website

Re: Fastboot Initscript Patches

from a quick glance, it looks like make_extra_nodes() is creating the "extra udev nodes" upon links.conf - just in case, or for some other reason, to prevent error messages on "non existing device".
i guess we can do the same...

[EDIT]
ps.
it seems they dont like doing it either :

# I hate this hack.  -- Md

wink

Offline

#71 2005-01-08 11:11:22

dtw
Forum Fellow
From: UK
Registered: 2004-08-03
Posts: 4,439
Website

Re: Fastboot Initscript Patches

after i upgraded to 2.6.10 this prob fixed itself - i added a sleep in alsamixer script too but it never has to use it - v odd

also - i was playing today and came up with two new (better?) methods of building patched initscripts (i was mainly doing it for bootsplash but it should work for all patching). assuming patches are compatible you should be able to apply several and have a pkg that you can use in a local repo and easily update when new versions of initscripts are released.

i think the one that downloads the latest pkg first is more secure than the abs version - as there is no checksumming for abs?

anyway - the first gets the pkg from current, explodes it, patches it and rebuilds it - the second grabs the files that make the package from ABS (allows compile of minilogd)

# Contributor: dibblethewrecker <dibblethewrecker@jiwe.org>
# This package is only a modified version of the arch initscripts package
# It allows you to easily checkout the latest initscripts and patch them
# (based on a pkg by Brice Carpentier <brice@daknet.org>)
# (incorporated a patch by Truls Becken <becken@stud.ntnu.no>)

pkgname=initscripts-custom
pkgver=0.1
pkgrel=1
pkgdesc="System initialization/bootup scripts with bootsplash support"
backup=(etc/inittab etc/rc.conf etc/rc.local)
depends=('bash' 'mawk' 'grep' 'coreutils' 'sed' 'bootsplash')
provides=('initscripts')
conflicts=('initscripts')
source=(initscripts-bootsplash.diff)
md5sums=('53a00c6e85aa520673f5ce9a99eb0655')

build() {
  # check the latest version of initscripts, grab it, copy and extract it to src
  latestver=`pacman -Ss initscripts | grep current | sed "s|current/initscripts ||g"`
  echo
  echo "  : Latest version in current repo is initscripts-$latestver"
  echo -n "  : Press any key to continue "
  read anykey
  pacman -Sw --noconfirm initscripts
  cp /var/cache/pacman/pkg/initscripts-$latestver.pkg.tar.gz $startdir/src

  cd $startdir/src
  gunzip -cd initscripts-$latestver.pkg.tar.gz | tar xf -

  # create the pkg - no compile required
  mkdir -p $startdir/pkg/etc/{rc.d,conf.d}

  cd $startdir/src/etc
  install -D -m644 inittab $startdir/pkg/etc/inittab
  install -D -m644 rc.conf $startdir/pkg/etc/rc.conf
  for i in rc.local rc.multi rc.shutdown rc.single rc.sysinit; do
    install -D -m755 $i $startdir/pkg/etc/$i
  done

  cd $startdir/src/etc/rc.d
  install -D -m755 network $startdir/pkg/etc/rc.d/network
  install -D -m755 netfs $startdir/pkg/etc/rc.d/netfs
  install -D -m644 functions $startdir/pkg/etc/rc.d/functions

  cd $startdir/src/sbin
  install -D -m755 minilogd $startdir/pkg/sbin/minilogd

  # apply your patches
  cd $startdir/pkg/etc
  patch -Np1 -i $startdir/src/initscripts-bootsplash.diff
}

download

# Maintainer: Brice Carpentier <brice@daknet.org>
# Contributor: Brice Carpentier <brice@daknet.org>
# This package is only a modified version of the arch initscripts package
# (incorporated a patch by Truls Becken <becken@stud.ntnu.no>)

pkgname=initscripts-custom
pkgver=0.1
pkgrel=1
pkgdesc="System initialization/bootup scripts with bootsplash support"
backup=(etc/inittab etc/rc.conf etc/rc.local)
depends=('bash' 'mawk' 'grep' 'coreutils' 'sed' 'bootsplash')
#makedepends=('cvs' 'openssh')
provides=('initscripts')
conflicts=('initscripts')
source=(initscripts-bootsplash.diff)
md5sums=('53a00c6e85aa520673f5ce9a99eb0655')

build() {
  # alternative method - grab and build the source files from abs
  #abs
  cp /var/abs/base/initscripts/{inittab,netfs,rc.conf,rc.multi,rc.single,functions,minilogd.c,network,rc.local,rc.shutdown,rc.sysinit} $startdir/src

  # use the normal build
  cd $startdir/src

  mkdir -p $startdir/pkg/etc/{rc.d,conf.d}
  install -D -m644 functions $startdir/pkg/etc/rc.d/functions
  install -D -m644 inittab $startdir/pkg/etc/inittab
  install -D -m644 rc.conf $startdir/pkg/etc/rc.conf
  for i in rc.local rc.multi rc.shutdown rc.single rc.sysinit; do
    install -D -m755 $i $startdir/pkg/etc/$i
  done
  install -D -m755 network $startdir/pkg/etc/rc.d/network
  install -D -m755 netfs $startdir/pkg/etc/rc.d/netfs
  gcc -o minilogd minilogd.c || return 1
  install -D -m755 minilogd $startdir/pkg/sbin/minilogd

  # apply your patches
  cd $startdir/pkg/etc
  patch -Np1 -i $startdir/src/initscripts-bootsplash.diff
}

download

Offline

#72 2005-01-11 10:38:30

dtw
Forum Fellow
From: UK
Registered: 2004-08-03
Posts: 4,439
Website

Re: Fastboot Initscript Patches

what if a BKGD damon fails... see me

Offline

Board footer

Powered by FluxBB