Intend of hostonly-cmdline?

DISCUSSION Thomas Renninger 3 participants 10 messages May 7, 2014 – May 13, 2014 6 messages not in the archive

lore

Share & tools

lore

Thomas Renninger

author

2014-05-07 11:12 UTC #0 lore raw

Hi,

I wonder for what this one is exactly for?

commit ab9457efd78ff74c654b4123956cdbd131935066

Author: Harald Hoyer <[email protected]>
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

Harald Hoyer

2014-05-07 11:32 UTC #1 lore raw

Quoted 25 lines · Thomas Renninger

Hi,
I wonder for what this one is exactly for?
commit ab9457efd78ff74c654b4123956cdbd131935066
Author: Harald Hoyer <[email protected]>
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:
(quoted diff) +4 -0
+    if [[ $hostonly == "yes" ]]; then
+        cmdline  >> "${initdir}/etc/cmdline.d/90mdraid.conf"
+        echo  >> "${initdir}/etc/cmdline.d/90mdraid.conf"
+    fi

Quoted 6 lines

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?

A message that is not in the archive (sent off-list or not yet received): [email protected]

Alexander Tsoy

2014-05-07 11:47 UTC #3 lore raw

В Wed, 07 May 2014 13:32:39 +0200
Harald Hoyer <[email protected]> пишет:

Quoted 57 lines · Thomas Renninger

Quoted 25 lines
Hi,
I wonder for what this one is exactly for?
commit ab9457efd78ff74c654b4123956cdbd131935066
Author: Harald Hoyer <[email protected]>
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:
(quoted diff) +4 -0
+    if [[ $hostonly == "yes" ]]; then
+        cmdline  >> "${initdir}/etc/cmdline.d/90mdraid.conf"
+        echo  >> "${initdir}/etc/cmdline.d/90mdraid.conf"
+    fi
Quoted 6 lines
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.

Quoted 4 lines

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.

Signature · 1 line

Alexander Tsoy

A message that is not in the archive (sent off-list or not yet received): 20140507154733.386369cd-d/[email protected]

Harald Hoyer

2014-05-07 12:08 UTC #5 lore raw

Quoted 5 lines · Alexander Tsoy

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.

A message that is not in the archive (sent off-list or not yet received): [email protected]

Harald Hoyer

2014-05-07 12:10 UTC #7 lore raw

Quoted 10 lines · Harald Hoyer

Quoted 5 lines · Alexander Tsoy
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.

A message that is not in the archive (sent off-list or not yet received): [email protected]

Alexander Tsoy

2014-05-07 13:15 UTC #9 lore raw

В Wed, 07 May 2014 14:10:49 +0200
Harald Hoyer <[email protected]> пишет:

Quoted 8 lines · Harald Hoyer

Quoted 7 lines · Alexander Tsoy
Quoted 5 lines
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.

Quoted 7 lines

Quoted 3 lines
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

Signature · 1 line

Alexander Tsoy

A message that is not in the archive (sent off-list or not yet received): 20140507171527.2d826560-d/[email protected]

Alexander Tsoy

2014-05-08 13:54 UTC #11 lore raw

В Wed, 7 May 2014 17:15:27 +0400
Alexander Tsoy <alexander-EP/[email protected]> пишет:

Quoted 19 lines

В Wed, 07 May 2014 14:10:49 +0200
Harald Hoyer <[email protected]> пишет:
Quoted 8 lines · Harald Hoyer
Quoted 7 lines · Alexander Tsoy
Quoted 5 lines
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.
Quoted 7 lines
Quoted 3 lines
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.

Quoted 5 lines

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.

Quoted 7 lines

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

modules.d/90crypt/parse-crypt.sh +2 -2

index a6b5252..8bb1328 100755
@@ -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

Signature · 1 line

Alexander Tsoy

A message that is not in the archive (sent off-list or not yet received): 20140508175412.2386aa29-d/[email protected]

Alexander Tsoy

2014-05-13 19:26 UTC #13 lore raw

В Thu, 8 May 2014 17:54:12 +0400
Alexander Tsoy <alexander-EP/[email protected]> пишет:

Quoted 10 lines

Here is a possible fix that works fine on my system (hostonly + hostonly-cmdline + empty /etc/crypttab + no rd.luks* in kernel cmdline).
modules.d/90crypt/parse-crypt.sh +0 -0
index a6b5252..8bb1328 100755

modules.d/90crypt/parse-crypt.sh else · line 42

Quoted 10 lines

modules.d/90crypt/parse-crypt.sh +2 -2

@@ -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?

Signature · 1 line

Alexander Tsoy

Thomas Renninger

author

2014-05-07 13:40 UTC #14 lore raw

In reply to a message not in the archive

Quoted 1 line · Harald Hoyer

On 07.05.2014 13:12, Thomas Renninger wrote:

...

Quoted 7 lines

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?

Quoted 17 lines

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.

Quoted 4 lines

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

Harald Hoyer

2014-05-07 13:48 UTC #15 lore raw

Quoted 12 lines · Thomas Renninger

Quoted 1 line · Harald Hoyer
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.