linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Janne Karhunen <Janne.Karhunen@gmail.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: 2.6.12 + devices on initrd
Date: Sun, 19 Jun 2005 14:37:50 +0000	[thread overview]
Message-ID: <200506191737.50459.Janne.Karhunen@gmail.com> (raw)
In-Reply-To: <200506191420.39355.Janne.Karhunen@gmail.com>

On Sunday 19 June 2005 16:48, Alexander E. Patrakov wrote:

> > There are plenty. After dropping to shell, it looks like everything
> > necessary is in place. I'm even able to mount root etc.
> >
> > So this is some form of a timing issue - it just doesn't wait long
> > enough before giving up. Can i tune this somehow?
>
> It's a bug in mkinitrd / mkinitramfs / whatever tool you used to create
> this initrd. BTW how long does it wait?

Looks like less than a second - but this is perfectly ok with
2.6.11 series.


> As a workaround, you can manually recreate the initrd using the existing
> one as a base and adding a "sleep 15" before mounting root.

Most interesting thing just happened while looking for the mount
command (for root) with grep. Whole box became unusable as all
terminals + applications running at the time started to be fed 
with newlines. Even GUI apps. So, for some reason it started to
have a constant keyboard interrupt. Ah well, 10 years since the 
introduction of USB, and it still doesn't work :/

Anyway, it seems to mount root from script called 'init'. This
very same script seems to later on start the real init. It seems
to be doing following at the time it fails;
..
echo "Loading kernel/fs/reiserfs/reiserfs.ko"
insmod /lib/modules/2.6.12-default/kernel/fs/reiserfs/reiserfs.ko

if ! udev_discover_root ; then
    echo "not found -- exiting to /bin/sh"
    cd /
    PATH=$PATH PS1='$ ' /bin/sh -i
fi
..

Function looks like:

udev_discover_root() {
    local root
    case "$rootdev" in
        *:*) root= ;;
        /dev/nfs) root= ;;
        /dev/*) root=${rootdev#/dev/} ;;
    esac
    if [ -z "$root" ]; then
        return 0
    fi
    if udev_wait_for_device $root $vg_root; then
        path=$(udevinfo -q path -n $root)
        if [ $? -eq 0 -a -n "$path" ]; then
            set -- $(udev_read_devn $path)
            if [ -n "$1" ]; then
                devn=$1
                major=$2
                minor=$3
            fi
        else
            # Try major:minor number of the device node
            devn=$(devnumber $rootdev)
            major=$(devmajor $devn)
            minor=$(devminor $devn)
        fi
    fi
    if [ -n "$devn" ]; then
        echo "rootfs: $entry major=$major minor=$minor" \
            "devn=$devn"
        echo $devn > /proc/sys/kernel/real-root-dev
        return 0
    else
        return 1
    fi
}

.. 

udev_wait_for_device() {
    local root
    local vg
    local retval=1
    local timeout=$udev_timeout
    root=$1
    vg=$2
    if [ -n "$root" ]; then
        echo -n "Waiting for device /dev/$root to appear: "
        while [ $timeout -gt 0 ]; do
            if [ -e /dev/$root ]; then
                if [ $? -eq 0 ]; then
                    echo " ok"
                    retval=0
                    break;
                fi
            fi
            sleep 1
            echo -n "."
            [ -n "$vg" ] && vgchange -a y $vg
            timeout=$(( $timeout - 1 ))
        done
    fi
    # Rescan for LVM1
    if [ -n "$vg" -a $retval -eq 1 ]; then
        vgscan
        vgchange -a y $vg
    fi
    return $retval;
}

..

# Default timeout is 5 seconds
udev_timeout=5
# Override timeout from commandline
for o in $(cat /proc/cmdline); do
    case $o in
    udev_timeout=*)
        set -- $(IFS= ; echo $o)
        udev_timeout=$2
        ;;
    esac
done

So it defaults to 5 second wait, but it really doesn't wait that
long. It waits less than a second prior to giving up. Umm .. what
could cause 'sleep' not to sleep .. umm, a signal. But where could
it get that? ARGH. So i'm guessing adding additional sleeps or 
even using that 'udev_timeout' switch doesn't help.


-- 
// Janne


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id\x16492&op=click
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  parent reply	other threads:[~2005-06-19 14:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-19 11:20 2.6.12 + devices on initrd Janne Karhunen
2005-06-19 11:37 ` Alexander E. Patrakov
2005-06-19 12:07 ` Janne Karhunen
2005-06-19 12:42 ` Alexander E. Patrakov
2005-06-19 12:48 ` Jasper Huijsmans
2005-06-19 13:10 ` Janne Karhunen
2005-06-19 13:48 ` Alexander E. Patrakov
2005-06-19 14:37 ` Janne Karhunen [this message]
2005-06-19 15:07 ` Janne Karhunen
2005-06-19 15:14 ` Alexander E. Patrakov
2005-06-19 15:53 ` Janne Karhunen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200506191737.50459.Janne.Karhunen@gmail.com \
    --to=janne.karhunen@gmail.com \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).