check_finished() syntax weirdness

Hi all,

I'm trying to figure out why my initqueue scripts are never called. Eg 95fcoe is just installing an initqueue job, which should call 'fcoe-up' on the interface.
However, this script is never called, irrespective of any 'fcoe=' parameters.

Looking a dracut-initqueue.sh, we have this:

while :; do

    check_finished && break

    udevadm settle --exit-if-exists=$hookdir/initqueue/work

    check_finished && break

    if [ -f $hookdir/initqueue/work ]; then
        rm -f -- "$hookdir/initqueue/work"
    fi

    for job in $hookdir/initqueue/*.sh; do
        [ -e "$job" ] || break
        job=$job . $job
        check_finished && break 2
    done

    udevadm settle --timeout=0 >/dev/null 2>&1 || continue

...

and check_finished is:

check_finished() {
    local f
    for f in $hookdir/initqueue/finished/*.sh; do
        [ "$f" = "$hookdir/initqueue/finished/*.sh" ] && return 0
        { [ -e "$f" ] && ( . "$f" ) ; } || return 1
    done
    return 0
}

IE if no scripts are present in the 'finished' queue, 'check_finished' will return '0', causing the main initqueue to short-circuit and the actual initqueue jobs will never be executed.

Is this the intended outcome?
IE are all jobs for the initqueue are _required_ to supply a 'finished' job?

I would have thought it to be a bit more permissive, ie do a 'return 1' if no finish j0bs have been found ...

Cheers,

Hannes

Quoted 51 lines · Hannes Reinecke

Hi all,

I'm trying to figure out why my initqueue scripts are never called. Eg 95fcoe is just installing an initqueue job, which should call 'fcoe-up' on the interface.
However, this script is never called, irrespective of any 'fcoe=' parameters.

Looking a dracut-initqueue.sh, we have this:

while :; do

     check_finished && break

     udevadm settle --exit-if-exists=$hookdir/initqueue/work

     check_finished && break

     if [ -f $hookdir/initqueue/work ]; then
         rm -f -- "$hookdir/initqueue/work"
     fi

     for job in $hookdir/initqueue/*.sh; do
         [ -e "$job" ] || break
         job=$job . $job
         check_finished && break 2
     done

     udevadm settle --timeout=0 >/dev/null 2>&1 || continue

...

and check_finished is:

check_finished() {
     local f
     for f in $hookdir/initqueue/finished/*.sh; do
         [ "$f" = "$hookdir/initqueue/finished/*.sh" ] && return 0
         { [ -e "$f" ] && ( . "$f" ) ; } || return 1
     done
     return 0
}

IE if no scripts are present in the 'finished' queue, 'check_finished' will return '0', causing the main initqueue to short-circuit and the actual initqueue jobs will never be executed.

Is this the intended outcome?
IE are all jobs for the initqueue are _required_ to supply a 'finished' job?

I would have thought it to be a bit more permissive, ie do a 'return 1' if no finish j0bs have been found ...

Quoted 3 lines

Cheers,

Hannes

Yes, the finished queue defines when to end the main loop. If you want to hang around in the main loop, you have to define the "break" condition, or in this case the negative-continue condition.

Quoted 52 lines · Harald Hoyer

Quoted 51 lines · Hannes Reinecke

Hi all,

I'm trying to figure out why my initqueue scripts are never called. Eg 95fcoe is just installing an initqueue job, which should call 'fcoe-up' on the interface.
However, this script is never called, irrespective of any 'fcoe=' parameters.

Looking a dracut-initqueue.sh, we have this:

while :; do

     check_finished && break

     udevadm settle --exit-if-exists=$hookdir/initqueue/work

     check_finished && break

     if [ -f $hookdir/initqueue/work ]; then
         rm -f -- "$hookdir/initqueue/work"
     fi

     for job in $hookdir/initqueue/*.sh; do
         [ -e "$job" ] || break
         job=$job . $job
         check_finished && break 2
     done

     udevadm settle --timeout=0 >/dev/null 2>&1 || continue

...

and check_finished is:

check_finished() {
     local f
     for f in $hookdir/initqueue/finished/*.sh; do
         [ "$f" = "$hookdir/initqueue/finished/*.sh" ] && return 0
         { [ -e "$f" ] && ( . "$f" ) ; } || return 1
     done
     return 0
}

IE if no scripts are present in the 'finished' queue, 'check_finished' will return '0', causing the main initqueue to short-circuit and the actual initqueue jobs will never be executed.

Is this the intended outcome?
IE are all jobs for the initqueue are _required_ to supply a 'finished' job?

I would have thought it to be a bit more permissive, ie do a 'return 1' if no finish j0bs have been found ...

Quoted 7 lines

Quoted 3 lines

Cheers,

Hannes

Yes, the finished queue defines when to end the main loop. If you want to hang around in the main loop, you have to define the "break" condition, or in this case the negative-continue condition.

Ah. So fcoe never worked?
(As it doesn't supply an 'finished' script)

Cheers,

Hannes

On 13.05.2014 11:55, Hannes Reinecke wrote:

Quoted 7 lines

Ah. So fcoe never worked?
(As it doesn't supply an 'finished' script)

Cheers,

Hannes

What do you mean? Normally there are "finished" scripts installed, which wait for the root device to appear. So the loop continues until the fcoe device appears.

Quoted 1 line · Harald Hoyer

On 13.05.2014 11:55, Hannes Reinecke wrote:

[ .. ]

Quoted 4 lines

Quoted 4 lines

Ah. So fcoe never worked?
(As it doesn't supply an 'finished' script)

Quoted 8 lines

Quoted 3 lines

Cheers,

Hannes

What do you mean? Normally there are "finished" scripts installed, which wait for the root device to appear. So the loop continues until the fcoe device appears.

Not in my case.
Which module should install them?

Cheers,

Hannes

Quoted 15 lines · Hannes Reinecke

Quoted 1 line · Harald Hoyer

On 13.05.2014 11:55, Hannes Reinecke wrote:

[ .. ]

Quoted 4 lines

Quoted 4 lines

Ah. So fcoe never worked?
(As it doesn't supply an 'finished' script)

Quoted 8 lines

Quoted 3 lines

Cheers,

Hannes

What do you mean? Normally there are "finished" scripts installed, which wait for the root device to appear. So the loop continues until the fcoe device appears.

Quoted 6 lines

Not in my case.
Which module should install them?

Cheers,

Hannes

for systemd:
modules.d/98systemd/rootfs-generator.sh:
[ "${root%%:*}" = "block" ] && generator_wait_for_dev "${root#block:}"

for non-systemd:
modules.d/95rootfs-block/parse-block.sh:
[ "${root%%:*}" = "block" ] && wait_for_dev "${root#block:}"

What is your kernel command line?

Quoted 27 lines · Harald Hoyer

Quoted 15 lines · Hannes Reinecke

Quoted 1 line · Harald Hoyer

On 13.05.2014 11:55, Hannes Reinecke wrote:

[ .. ]

Quoted 4 lines

Quoted 4 lines

Ah. So fcoe never worked?
(As it doesn't supply an 'finished' script)

Quoted 8 lines

Quoted 3 lines

Cheers,

Hannes

What do you mean? Normally there are "finished" scripts installed, which wait for the root device to appear. So the loop continues until the fcoe device appears.

Quoted 6 lines

Not in my case.
Which module should install them?

Cheers,

Hannes

for systemd:
modules.d/98systemd/rootfs-generator.sh:
[ "${root%%:*}" = "block" ] && generator_wait_for_dev "${root#block:}"

Quoted 7 lines

for non-systemd:
modules.d/95rootfs-block/parse-block.sh:
[ "${root%%:*}" = "block" ] && wait_for_dev "${root#block:}"

What is your kernel command line?

BOOT_IMAGE=/boot/vmlinuz-3.12.18-4-default \
root=UUID=7b90aa11-62ba-4260-81c6-bcf43914e97e \
console=tty0 console=ttyS1,57600 sysrq_always_enabled \
panic=100 ignore_loglevel unknown_nmi_panic \
resume=/dev/disk/by-uuid/7be10c24-f0fe-4ecd-b04f-c307b0370c48 \
splash=silent quiet showopts crashkernel=166M-:83M \
rd.break=pre-mount

(The pre-mount thingie is inserted by me so that I have a chance to debug & fix things)

Cheers,

Hannes

Quoted 43 lines · Hannes Reinecke

Quoted 27 lines · Harald Hoyer

Quoted 15 lines · Hannes Reinecke

Quoted 1 line · Harald Hoyer

On 13.05.2014 11:55, Hannes Reinecke wrote:

[ .. ]

Quoted 4 lines

Quoted 4 lines

Ah. So fcoe never worked?
(As it doesn't supply an 'finished' script)

Quoted 8 lines

Quoted 3 lines

Cheers,

Hannes

What do you mean? Normally there are "finished" scripts installed, which wait for the root device to appear. So the loop continues until the fcoe device appears.

Quoted 6 lines

Not in my case.
Which module should install them?

Cheers,

Hannes

for systemd:
modules.d/98systemd/rootfs-generator.sh:
[ "${root%%:*}" = "block" ] && generator_wait_for_dev "${root#block:}"

Quoted 7 lines

for non-systemd:
modules.d/95rootfs-block/parse-block.sh:
[ "${root%%:*}" = "block" ] && wait_for_dev "${root#block:}"

What is your kernel command line?

BOOT_IMAGE=/boot/vmlinuz-3.12.18-4-default \
root=UUID=7b90aa11-62ba-4260-81c6-bcf43914e97e \
console=tty0 console=ttyS1,57600 sysrq_always_enabled \
panic=100 ignore_loglevel unknown_nmi_panic \
resume=/dev/disk/by-uuid/7be10c24-f0fe-4ecd-b04f-c307b0370c48 \
splash=silent quiet showopts crashkernel=166M-:83M \
rd.break=pre-mount

Quoted 6 lines

(The pre-mount thingie is inserted by me so that I have a chance to debug & fix things)

Cheers,

Hannes

do a rd.break=initqueue and look in the
/lib/dracut/hooks/initqueue/finished
directory.

If you use systemd in the initramfs, you should have:

/usr/lib/systemd/system-generators/dracut-rootfs-generator

in the initramfs, which transforms root=UUID=... into the finished hook.

You should be able to test it in the dracut shell with:

# bash -x /usr/lib/systemd/system-generators/dracut-rootfs-generator

Quoted 58 lines · Harald Hoyer

Quoted 44 lines · Hannes Reinecke

Quoted 28 lines · Harald Hoyer

Quoted 16 lines · Hannes Reinecke

Quoted 1 line · Harald Hoyer

On 13.05.2014 11:55, Hannes Reinecke wrote:

[ .. ]

Quoted 4 lines

Quoted 4 lines

Ah. So fcoe never worked?
(As it doesn't supply an 'finished' script)

Quoted 9 lines

Quoted 3 lines

Cheers,

Hannes

What do you mean? Normally there are "finished" scripts installed, which wait
for the root device to appear. So the loop continues until the fcoe device appears.

Quoted 6 lines

Not in my case.
Which module should install them?

Cheers,

Hannes

for systemd:
modules.d/98systemd/rootfs-generator.sh:
[ "${root%%:*}" = "block" ] && generator_wait_for_dev "${root#block:}"

Quoted 7 lines

for non-systemd:
modules.d/95rootfs-block/parse-block.sh:
[ "${root%%:*}" = "block" ] && wait_for_dev "${root#block:}"

What is your kernel command line?

BOOT_IMAGE=/boot/vmlinuz-3.12.18-4-default \
root=UUID=7b90aa11-62ba-4260-81c6-bcf43914e97e \
console=tty0 console=ttyS1,57600 sysrq_always_enabled \
panic=100 ignore_loglevel unknown_nmi_panic \
resume=/dev/disk/by-uuid/7be10c24-f0fe-4ecd-b04f-c307b0370c48 \
splash=silent quiet showopts crashkernel=166M-:83M \
rd.break=pre-mount

Quoted 6 lines

(The pre-mount thingie is inserted by me so that I have a chance to debug & fix things)

Cheers,

Hannes

do a rd.break=initqueue and look in the
/lib/dracut/hooks/initqueue/finished
directory.

If you use systemd in the initramfs, you should have:

Quoted 7 lines

/usr/lib/systemd/system-generators/dracut-rootfs-generator

in the initramfs, which transforms root=UUID=... into the finished hook.

You should be able to test it in the dracut shell with:

# bash -x /usr/lib/systemd/system-generators/dracut-rootfs-generator

Which seems to be the problem; the generator is present, but apparently not called.
Once I execute the above line the 'finished' entry for the root fs is there. From which I surmise that the generator hasn't been called.

Hmm.

Cheers,

Hannes

Quoted 49 lines · Hannes Reinecke

Quoted 35 lines · Harald Hoyer

Quoted 21 lines · Hannes Reinecke

Quoted 5 lines · Harald Hoyer

for systemd:
modules.d/98systemd/rootfs-generator.sh:
[ "${root%%:*}" = "block" ] && generator_wait_for_dev "${root#block:}"

Quoted 7 lines

for non-systemd:
modules.d/95rootfs-block/parse-block.sh:
[ "${root%%:*}" = "block" ] && wait_for_dev "${root#block:}"

What is your kernel command line?

BOOT_IMAGE=/boot/vmlinuz-3.12.18-4-default \
root=UUID=7b90aa11-62ba-4260-81c6-bcf43914e97e \
console=tty0 console=ttyS1,57600 sysrq_always_enabled \
panic=100 ignore_loglevel unknown_nmi_panic \
resume=/dev/disk/by-uuid/7be10c24-f0fe-4ecd-b04f-c307b0370c48 \
splash=silent quiet showopts crashkernel=166M-:83M \
rd.break=pre-mount

Quoted 6 lines

(The pre-mount thingie is inserted by me so that I have a chance to debug & fix things)

Cheers,

Hannes

do a rd.break=initqueue and look in the
/lib/dracut/hooks/initqueue/finished
directory.

If you use systemd in the initramfs, you should have:

Quoted 7 lines

/usr/lib/systemd/system-generators/dracut-rootfs-generator

in the initramfs, which transforms root=UUID=... into the finished hook.

You should be able to test it in the dracut shell with:

# bash -x /usr/lib/systemd/system-generators/dracut-rootfs-generator

Which seems to be the problem; the generator is present, but apparently not called.
Once I execute the above line the 'finished' entry for the root fs is there.
From which I surmise that the generator hasn't been called.

Quoted 2 lines

Hmm.

Does it have the executable bits set?

Quoted 56 lines · Harald Hoyer

Quoted 55 lines · Hannes Reinecke

Quoted 39 lines · Harald Hoyer

Quoted 22 lines · Hannes Reinecke

Quoted 6 lines · Harald Hoyer

for systemd:
modules.d/98systemd/rootfs-generator.sh:
[ "${root%%:*}" = "block" ] && generator_wait_for_dev "${root#block:}"

Quoted 7 lines

for non-systemd:
modules.d/95rootfs-block/parse-block.sh:
[ "${root%%:*}" = "block" ] && wait_for_dev "${root#block:}"

What is your kernel command line?

BOOT_IMAGE=/boot/vmlinuz-3.12.18-4-default \
root=UUID=7b90aa11-62ba-4260-81c6-bcf43914e97e \
console=tty0 console=ttyS1,57600 sysrq_always_enabled \
panic=100 ignore_loglevel unknown_nmi_panic \
resume=/dev/disk/by-uuid/7be10c24-f0fe-4ecd-b04f-c307b0370c48 \
splash=silent quiet showopts crashkernel=166M-:83M \
rd.break=pre-mount

Quoted 7 lines

(The pre-mount thingie is inserted by me so that I have a chance to debug & fix
things)

Cheers,

Hannes

do a rd.break=initqueue and look in the
/lib/dracut/hooks/initqueue/finished
directory.

If you use systemd in the initramfs, you should have:

/usr/lib/systemd/system-generators/dracut-rootfs-generator

Quoted 7 lines

in the initramfs, which transforms root=UUID=... into the finished hook.

You should be able to test it in the dracut shell with:

# bash -x
/usr/lib/systemd/system-generators/dracut-rootfs-generator

Which seems to be the problem; the generator is present, but apparently not
called.
Once I execute the above line the 'finished' entry for the root fs is there.
From which I surmise that the generator hasn't been called.

Quoted 4 lines

Quoted 2 lines

Hmm.

Does it have the executable bits set?

Argl. Totally stupid.

Look at modules.d/99base/module_setup.sh:

     ## save host_devs which we need bring up
     if [[ $hostonly_cmdline == "yes" ]]; then
         if [[ -f "$initdir/lib/dracut/need-initqueue" ]] || !
dracut_module_included "systemd"; then
             (
                 if dracut_module_included "systemd"; then
                     DRACUT_SYSTEMD=1
                 fi
                 PREFIX="$initdir"

                 . "$moddir/dracut-lib.sh"

                 for _dev in ${host_devs[@]}; do
                     [[ "$_dev" == "$root_dev" ]] && continue
                     _pdev=$(get_persistent_dev $_dev)

                     case "$_pdev" in
                         /dev/?*) wait_for_dev $_pdev;;
                         *) ;;
                     esac
                 done
             )
         fi
     fi

So if /etc/fstab contains just the root device (or if the swap device resides on a different device which is initialized earlier) the initqueue will _never_ run, and the worker scripts will never be executed.
Once I remove the '[[ "$_dev" == "$root_dev" ]] && continue' line the system boots.