check_finished() syntax weirdness

check_finished() syntax weirdness

[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 ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

Re: check_finished() syntax weirdness

[Harald Hoyer]

On 13.05.2014 11:44, Hannes Reinecke wrote:
> 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

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.

Re: check_finished() syntax weirdness

[Hannes Reinecke]

On 05/13/2014 11:48 AM, Harald Hoyer wrote:
> On 13.05.2014 11:44, Hannes Reinecke wrote:
>> 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
>
> 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
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

Re: check_finished() syntax weirdness

[Harald Hoyer]

On 13.05.2014 11:55, Hannes Reinecke wrote:
> On 05/13/2014 11:48 AM, Harald Hoyer wrote:
>> On 13.05.2014 11:44, Hannes Reinecke wrote:
>>> 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
>>
>> 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

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.

Re: check_finished() syntax weirdness

[Hannes Reinecke]

On 05/13/2014 12:22 PM, Harald Hoyer wrote:
> On 13.05.2014 11:55, Hannes Reinecke wrote:
[ .. ]
>>
>> 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.
>
Not in my case.
Which module should install them?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

Re: check_finished() syntax weirdness

[Harald Hoyer]

On 13.05.2014 12:30, Hannes Reinecke wrote:
> On 05/13/2014 12:22 PM, Harald Hoyer wrote:
>> On 13.05.2014 11:55, Hannes Reinecke wrote:
> [ .. ]
>>>
>>> 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.
>>
> 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?

Re: check_finished() syntax weirdness

[Hannes Reinecke]

On 05/13/2014 12:39 PM, Harald Hoyer wrote:
> On 13.05.2014 12:30, Hannes Reinecke wrote:
>> On 05/13/2014 12:22 PM, Harald Hoyer wrote:
>>> On 13.05.2014 11:55, Hannes Reinecke wrote:
>> [ .. ]
>>>>
>>>> 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.
>>>
>> 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?
>
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
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

Re: check_finished() syntax weirdness

[Harald Hoyer]

On 13.05.2014 12:42, Hannes Reinecke wrote:
> On 05/13/2014 12:39 PM, Harald Hoyer wrote:
>> On 13.05.2014 12:30, Hannes Reinecke wrote:
>>> On 05/13/2014 12:22 PM, Harald Hoyer wrote:
>>>> On 13.05.2014 11:55, Hannes Reinecke wrote:
>>> [ .. ]
>>>>>
>>>>> 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.
>>>>
>>> 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?
>>
> 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

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

Re: check_finished() syntax weirdness

[Hannes Reinecke]

On 05/13/2014 02:10 PM, Harald Hoyer wrote:
> On 13.05.2014 12:42, Hannes Reinecke wrote:
>> On 05/13/2014 12:39 PM, Harald Hoyer wrote:
>>> On 13.05.2014 12:30, Hannes Reinecke wrote:
>>>> On 05/13/2014 12:22 PM, Harald Hoyer wrote:
>>>>> On 13.05.2014 11:55, Hannes Reinecke wrote:
>>>> [ .. ]
>>>>>>
>>>>>> 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.
>>>>>
>>>> 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?
>>>
>> 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
>
> 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

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
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

Re: check_finished() syntax weirdness

[Harald Hoyer]

On 13.05.2014 16:21, Hannes Reinecke wrote:
> On 05/13/2014 02:10 PM, Harald Hoyer wrote:
>> On 13.05.2014 12:42, Hannes Reinecke wrote:
>>> On 05/13/2014 12:39 PM, Harald Hoyer wrote:
>>>> On 13.05.2014 12:30, Hannes Reinecke wrote:
>>>>> On 05/13/2014 12:22 PM, Harald Hoyer wrote:
>>>>>> On 13.05.2014 11:55, Hannes Reinecke wrote:
>>>>> [ .. ]
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>> 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?
>>>>
>>> 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
>>
>> 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
> 
> 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

Does it have the executable bits set?

Re: check_finished() syntax weirdness

[Hannes Reinecke]

On 05/13/2014 04:32 PM, Harald Hoyer wrote:
> On 13.05.2014 16:21, Hannes Reinecke wrote:
>> On 05/13/2014 02:10 PM, Harald Hoyer wrote:
>>> On 13.05.2014 12:42, Hannes Reinecke wrote:
>>>> On 05/13/2014 12:39 PM, Harald Hoyer wrote:
>>>>>
>>>>> 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?
>>>>>
>>>> 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
>>>
>>> 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
>>
>> 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.
>>
>
> 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.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

Re: check_finished() syntax weirdness

[Hannes Reinecke]

On 05/20/2014 10:46 AM, Hannes Reinecke wrote:
> On 05/13/2014 04:32 PM, Harald Hoyer wrote:
>> On 13.05.2014 16:21, Hannes Reinecke wrote:
>>> On 05/13/2014 02:10 PM, Harald Hoyer wrote:
>>>> On 13.05.2014 12:42, Hannes Reinecke wrote:
>>>>> On 05/13/2014 12:39 PM, Harald Hoyer wrote:
>>>>>>
>>>>>> 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?
>>>>>>
>>>>> 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
>>>>
>>>> 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
>>>
>>> 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.
>>>
>>
>> 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.
>
Which is actually wrong.

However, the _real_ issue is even more stupid.
At one point systemd switched over to /usr/lib instead of /lib,
and all scripts got moved to the new location.

Well, nearly all:

diff --git a/modules.d/98systemd/module-setup.sh 
b/modules.d/98systemd/module-setup.sh
index e14ce39..4516b9a 100755
--- a/modules.d/98systemd/module-setup.sh
+++ b/modules.d/98systemd/module-setup.sh
@@ -192,7 +192,7 @@ install() {
      inst_script "$moddir/dracut-mount.sh" /bin/dracut-mount
      inst_script "$moddir/dracut-pre-pivot.sh" /bin/dracut-pre-pivot

-    inst_script "$moddir/rootfs-generator.sh" 
/lib/systemd/system-generators/dracut-rootfs-generator
+    inst_script "$moddir/rootfs-generator.sh" 
$systemdutildir/system-generators/dracut-rootfs-generator

      inst_binary true
      ln_r $(type -P true) "/usr/bin/loginctl"

and surprisingly the system boots.
I'll be sending a proper patch.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare-l3A5Bk7waGM@public.gmane.org			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)