Intend of hostonly-cmdline?

Intend of hostonly-cmdline?

[Thomas Renninger]

Hi,

I wonder for what this one is exactly for?

commit ab9457efd78ff74c654b4123956cdbd131935066
Author: Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Date:   Tue Feb 25 12:35:32 2014 +0100

    Add flag to toggle hostonly cmdline storing in the initramfs
    
    --hostonly-cmdline:
        Store kernel command line arguments needed in the initramfs
    
    --no-hostonly-cmdline:
        Do not store kernel command line arguments needed in the initramfs



Wouldn't it be enough to simply add hostonly command line parameters
only in hostonly case like:
+    if [[ $hostonly == "yes" ]]; then
+        cmdline  >> "${initdir}/etc/cmdline.d/90mdraid.conf"
+        echo  >> "${initdir}/etc/cmdline.d/90mdraid.conf"
+    fi

why is a hostonly-cmdline extra parameter needed?

Thanks,

  Thomas

Re: Intend of hostonly-cmdline?

[Harald Hoyer]

On 07.05.2014 13:12, Thomas Renninger wrote:
> Hi,
> 
> I wonder for what this one is exactly for?
> 
> commit ab9457efd78ff74c654b4123956cdbd131935066
> Author: Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Date:   Tue Feb 25 12:35:32 2014 +0100
> 
>     Add flag to toggle hostonly cmdline storing in the initramfs
>     
>     --hostonly-cmdline:
>         Store kernel command line arguments needed in the initramfs
>     
>     --no-hostonly-cmdline:
>         Do not store kernel command line arguments needed in the initramfs
> 
> 
> 
> Wouldn't it be enough to simply add hostonly command line parameters
> only in hostonly case like:
> +    if [[ $hostonly == "yes" ]]; then
> +        cmdline  >> "${initdir}/etc/cmdline.d/90mdraid.conf"
> +        echo  >> "${initdir}/etc/cmdline.d/90mdraid.conf"
> +    fi
> 
> why is a hostonly-cmdline extra parameter needed?
> 
> Thanks,
> 
>   Thomas
> 

hostonly stores config files like mdadm.conf and only installs those kernel
modules, which are specific to the machine.

hostonly-cmdline also stores dracut specific kernel cmdline parameters to boot
the system in the initramfs, so that basically you could boot the system by
only specifying "root=" on the kernel cmdline.

The advantage of hostonly-cmdline is that the kernel cmdline does not need
complex rd.md.uuid=... or rd.luks.uuid=... parameters.

The disadvantage is that in case of uuid or disk changes, you cannot alter the
parameters which are in the initramfs.

I suggest to use the output of:

# dracut --print-cmdline

and add it to the kernel command line.

hostonly-cmdline should only be used, when e.g. the maximum char limit of the
kernel command line would be reached or when the user has a generic rescue
image, to be used when the disk layout changed and the user has not generated a
new initramfs with it.

Maybe we could let hostonly-cmdline be the default and add a parameter
"rd.cmdline.conf=0", which turns of parsing $initrd/etc/cmdline.d/*.conf.

Thoughts?

Re: Intend of hostonly-cmdline?

[Alexander Tsoy]

В Wed, 07 May 2014 13:32:39 +0200
Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> пишет:

> On 07.05.2014 13:12, Thomas Renninger wrote:
> > Hi,
> > 
> > I wonder for what this one is exactly for?
> > 
> > commit ab9457efd78ff74c654b4123956cdbd131935066
> > Author: Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> > Date:   Tue Feb 25 12:35:32 2014 +0100
> > 
> >     Add flag to toggle hostonly cmdline storing in the initramfs
> >     
> >     --hostonly-cmdline:
> >         Store kernel command line arguments needed in the initramfs
> >     
> >     --no-hostonly-cmdline:
> >         Do not store kernel command line arguments needed in the initramfs
> > 
> > 
> > 
> > Wouldn't it be enough to simply add hostonly command line parameters
> > only in hostonly case like:
> > +    if [[ $hostonly == "yes" ]]; then
> > +        cmdline  >> "${initdir}/etc/cmdline.d/90mdraid.conf"
> > +        echo  >> "${initdir}/etc/cmdline.d/90mdraid.conf"
> > +    fi
> > 
> > why is a hostonly-cmdline extra parameter needed?
> > 
> > Thanks,
> > 
> >   Thomas
> > 
> 
> hostonly stores config files like mdadm.conf and only installs those kernel
> modules, which are specific to the machine.
> 
> hostonly-cmdline also stores dracut specific kernel cmdline parameters to boot
> the system in the initramfs, so that basically you could boot the system by
> only specifying "root=" on the kernel cmdline.
> 
> The advantage of hostonly-cmdline is that the kernel cmdline does not need
> complex rd.md.uuid=... or rd.luks.uuid=... parameters.
> 
> The disadvantage is that in case of uuid or disk changes, you cannot alter the
> parameters which are in the initramfs.
> 
> I suggest to use the output of:
> 
> # dracut --print-cmdline
> 
> and add it to the kernel command line.
> 
> hostonly-cmdline should only be used, when e.g. the maximum char limit of the
> kernel command line would be reached or when the user has a generic rescue
> image, to be used when the disk layout changed and the user has not generated a
> new initramfs with it.
> 
> Maybe we could let hostonly-cmdline be the default and add a parameter
> "rd.cmdline.conf=0", which turns of parsing $initrd/etc/cmdline.d/*.conf.
> 
> Thoughts?

Actually hostonly-cmdline is partially broken with systemd in
initramfs. For example systemd-cryptsetup-generator does not
read /etc/cmdline.d/*.conf files, so rd.luks* parameters must be
appended to kernel cmdline anyway.

-- 
Alexander Tsoy

Re: Intend of hostonly-cmdline?

[Harald Hoyer]

On 07.05.2014 13:47, Alexander Tsoy wrote:
> Actually hostonly-cmdline is partially broken with systemd in
> initramfs. For example systemd-cryptsetup-generator does not
> read /etc/cmdline.d/*.conf files, so rd.luks* parameters must be
> appended to kernel cmdline anyway.
> 

True! Good point!
Although /etc/crypttab is included with hostonly.

Re: Intend of hostonly-cmdline?

[Harald Hoyer]

On 07.05.2014 14:08, Harald Hoyer wrote:
> On 07.05.2014 13:47, Alexander Tsoy wrote:
>> Actually hostonly-cmdline is partially broken with systemd in
>> initramfs. For example systemd-cryptsetup-generator does not
>> read /etc/cmdline.d/*.conf files, so rd.luks* parameters must be
>> appended to kernel cmdline anyway.
>>
> 
> True! Good point!
> Although /etc/crypttab is included with hostonly.
> 

Ah, oh.. I forgot, dracut *does* use rd.luks.uuid from the kernel command line
and creates /etc/crypttab lines from it in the initramfs.
So basically it *should* work with systemd.

Re: Intend of hostonly-cmdline?

[Alexander Tsoy]

В Wed, 07 May 2014 14:10:49 +0200
Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> пишет:

> On 07.05.2014 14:08, Harald Hoyer wrote:
> > On 07.05.2014 13:47, Alexander Tsoy wrote:
> >> Actually hostonly-cmdline is partially broken with systemd in
> >> initramfs. For example systemd-cryptsetup-generator does not
> >> read /etc/cmdline.d/*.conf files, so rd.luks* parameters must be
> >> appended to kernel cmdline anyway.
> >>
> > 
> > True! Good point!
> > Although /etc/crypttab is included with hostonly.
> > 
> 
> Ah, oh.. I forgot, dracut *does* use rd.luks.uuid from the kernel command line
> and creates /etc/crypttab lines from it in the initramfs.
> So basically it *should* work with systemd.

This doesn't work with full disk encryption. Unit file does not get
generated and I see this message:

[    7.142993] testhost dracut-initqueue[202]: Failed to start systemd-cryptsetup@luks\x2d342d2414\x2d159c\x2d48d7\x2da0b7\x2d5b59fa6e27a5.service: Unit 
systemd-cryptsetup@luks\x2d342d2414\x2d159c\x2d48d7\x2da0b7\x2d5b59fa6e27a5.service failed to load: No such file or directory.

Probably this is because crypt-run-generator get executed from udev
rules only if *both* of the following conditions are true:
- there is no rd.luks.uuid parameter in both cmdline
and /etc/cmdline.d/*.conf
- rd.auto is enabled

-- 
Alexander Tsoy

Re: Intend of hostonly-cmdline?

[Alexander Tsoy]

В Wed, 7 May 2014 17:15:27 +0400
Alexander Tsoy <alexander-EP/B3+myoZc@public.gmane.org> пишет:

> В Wed, 07 May 2014 14:10:49 +0200
> Harald Hoyer <harald-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> пишет:
> 
> > On 07.05.2014 14:08, Harald Hoyer wrote:
> > > On 07.05.2014 13:47, Alexander Tsoy wrote:
> > >> Actually hostonly-cmdline is partially broken with systemd in
> > >> initramfs. For example systemd-cryptsetup-generator does not
> > >> read /etc/cmdline.d/*.conf files, so rd.luks* parameters must be
> > >> appended to kernel cmdline anyway.
> > >>
> > > 
> > > True! Good point!
> > > Although /etc/crypttab is included with hostonly.
> > > 
> > 
> > Ah, oh.. I forgot, dracut *does* use rd.luks.uuid from the kernel command line
> > and creates /etc/crypttab lines from it in the initramfs.
> > So basically it *should* work with systemd.
> 
> This doesn't work with full disk encryption. Unit file does not get
> generated and I see this message:
> 
> [    7.142993] testhost dracut-initqueue[202]: Failed to start systemd-cryptsetup@luks\x2d342d2414\x2d159c\x2d48d7\x2da0b7\x2d5b59fa6e27a5.service: Unit 
> systemd-cryptsetup@luks\x2d342d2414\x2d159c\x2d48d7\x2da0b7\x2d5b59fa6e27a5.service failed to load: No such file or directory.

Note that I don't have an entry for this luks device in /etc/crypttab. I
always thought that this is not necessary since all needed options
are in cmdline.

> 
> Probably this is because crypt-run-generator get executed from udev
> rules only if *both* of the following conditions are true:
> - there is no rd.luks.uuid parameter in both cmdline
> and /etc/cmdline.d/*.conf
> - rd.auto is enabled
> 

Here is a possible fix that works fine on my system (hostonly +
hostonly-cmdline + empty /etc/crypttab + no rd.luks* in kernel
cmdline).

diff --git a/modules.d/90crypt/parse-crypt.sh b/modules.d/90crypt/parse-crypt.sh
index a6b5252..8bb1328 100755
--- a/modules.d/90crypt/parse-crypt.sh
+++ b/modules.d/90crypt/parse-crypt.sh
@@ -35,8 +35,8 @@ else
                         printf -- 'ENV{ID_FS_TYPE}=="crypto_LUKS", '
                         printf -- 'ENV{ID_FS_UUID}=="*%s*", ' $luksid
                         printf -- 'RUN+="%s --settled --unique --onetime ' $(command -v initqueue)
-                        printf -- '--name systemd-cryptsetup-%%k %s start ' $(command -v systemctl)
-                        printf -- 'systemd-cryptsetup@luks$$(dev_unit_name -$env{ID_FS_UUID}).service"\n'
+                        printf -- '--name crypt-run-generator-%%k %s ' $(command -v crypt-run-generator)
+                        printf -- '$env{DEVNAME} luks-$env{ID_FS_UUID}"\n'
                     } >> /etc/udev/rules.d/70-luks.rules.new
                 fi
             fi

-- 
Alexander Tsoy

Re: Intend of hostonly-cmdline?

[Alexander Tsoy]

В Thu, 8 May 2014 17:54:12 +0400
Alexander Tsoy <alexander-EP/B3+myoZc@public.gmane.org> пишет:

> Here is a possible fix that works fine on my system (hostonly +
> hostonly-cmdline + empty /etc/crypttab + no rd.luks* in kernel
> cmdline).
> 
> diff --git a/modules.d/90crypt/parse-crypt.sh b/modules.d/90crypt/parse-crypt.sh
> index a6b5252..8bb1328 100755
> --- a/modules.d/90crypt/parse-crypt.sh
> +++ b/modules.d/90crypt/parse-crypt.sh
> @@ -35,8 +35,8 @@ else
>                          printf -- 'ENV{ID_FS_TYPE}=="crypto_LUKS", '
>                          printf -- 'ENV{ID_FS_UUID}=="*%s*", ' $luksid
>                          printf -- 'RUN+="%s --settled --unique --onetime ' $(command -v initqueue)
> -                        printf -- '--name systemd-cryptsetup-%%k %s start ' $(command -v systemctl)
> -                        printf -- 'systemd-cryptsetup@luks$$(dev_unit_name -$env{ID_FS_UUID}).service"\n'
> +                        printf -- '--name crypt-run-generator-%%k %s ' $(command -v crypt-run-generator)
> +                        printf -- '$env{DEVNAME} luks-$env{ID_FS_UUID}"\n'
>                      } >> /etc/udev/rules.d/70-luks.rules.new
>                  fi
>              fi
> 

Hmm.. I just walked through commit history and it turned out that my
patch almost reverts your following commits (with minor difference in
initqueue args):

ab9b04f55bb9917749e9ddb52ce8f5f1ef56af99
5ac8420abcfd5665f712f18f8678f3977e039969

What was the reason to replace crypt-run-generator with "systemctl
start systemd-cryptsetup@..." in udev rules?

-- 
Alexander Tsoy

Re: Intend of hostonly-cmdline?

[Thomas Renninger]

On Wednesday, May 07, 2014 01:32:39 PM Harald Hoyer wrote:
> On 07.05.2014 13:12, Thomas Renninger wrote:
...
> 
> hostonly stores config files like mdadm.conf and only installs those kernel
> modules, which are specific to the machine.
> 
> hostonly-cmdline also stores dracut specific kernel cmdline parameters to
> boot the system in the initramfs, so that basically you could boot the
> system by only specifying "root=" on the kernel cmdline.

Ok, so both: hostonly and hostonly-cmdline stores hostonly specific stuff into
the initrd.
That means this has nothing to do with a generic initrd and
hostonly-cmdline only makes sense together with hostonly option, right?

> The advantage of hostonly-cmdline is that the kernel cmdline does not need
> complex rd.md.uuid=... or rd.luks.uuid=... parameters.
> 
> The disadvantage is that in case of uuid or disk changes, you cannot alter
> the parameters which are in the initramfs.
> 
> I suggest to use the output of:
> 
> # dracut --print-cmdline
> 
> and add it to the kernel command line.
> 
> hostonly-cmdline should only be used, when e.g. the maximum char limit of
> the kernel command line would be reached or when the user has a generic
> rescue image, to be used when the disk layout changed and the user has not
> generated a new initramfs with it.
> 
> Maybe we could let hostonly-cmdline be the default and add a parameter
> "rd.cmdline.conf=0", which turns of parsing $initrd/etc/cmdline.d/*.conf.
> 
> Thoughts?

Most parameters are unique and if it is ensured that:
single getarg and friends calls prefer the (real)
kernel cmdline parameter over the faked one, it should more or less be safe
and things can still be overridden via kernel cmdline.

Don't know whether this is the case atm, though.

    Thomas

Re: Intend of hostonly-cmdline?

[Harald Hoyer]

On 07.05.2014 15:40, Thomas Renninger wrote:
> On Wednesday, May 07, 2014 01:32:39 PM Harald Hoyer wrote:
>> Thoughts?
> 
> Most parameters are unique and if it is ensured that:
> single getarg and friends calls prefer the (real)
> kernel cmdline parameter over the faked one, it should more or less be safe
> and things can still be overridden via kernel cmdline.
> 
> Don't know whether this is the case atm, though.
> 
>     Thomas
> 

Unique parameters are already handled that way...
The problem to solve are the parameters, which can be given multiple times

Hmm, maybe we should also log the parameters in /etc/cmdline.d to let the user
see, what dracut is parsing.