Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dracut-install: default --firmwaredirs #1512

Closed
marcosfrm opened this issue May 21, 2021 · 2 comments
Closed

dracut-install: default --firmwaredirs #1512

marcosfrm opened this issue May 21, 2021 · 2 comments
Labels
bug Our bugs

Comments

@marcosfrm
Copy link
Contributor

Since dracut-install has a default value for --kerneldir (see #1505), --firmwaredirs should follow it. What do you think?

diff --git a/src/install/dracut-install.c b/src/install/dracut-install.c
index 3fd70fc8..4798fc6d 100644
--- a/src/install/dracut-install.c
+++ b/src/install/dracut-install.c
@@ -1183,14 +1183,12 @@ static int parse_argv(int argc, char *argv[])

                         path = getenv("DRACUT_FIRMWARE_PATH");

-                        if (path == NULL) {
-                                log_error("Environment variable DRACUT_FIRMWARE_PATH is not set");
-                                exit(EXIT_FAILURE);
+                        if (path) {
+                                log_debug("DRACUT_FIRMWARE_PATH=%s", path);
+                                firmwaredirs = strv_split(path, ":");
+                        } else {
+                                firmwaredirs = strv_new("/lib/firmware", NULL);
                         }
-
-                        log_debug("DRACUT_FIRMWARE_PATH=%s", path);
-
-                        firmwaredirs = strv_split(path, ":");
                 }
         }
@marcosfrm marcosfrm added the bug Our bugs label May 21, 2021
@johannbg
Copy link
Collaborator

@marcosfrm I think it's great and a bit of a side note since it's a bit redundant to create an issue and a PR.
If the scope of your change is small ( like this one and your previous one ) then there is no need for you to make an issue to discuss some potential PR's that come out of it.

It's better and more efficient if you just make a PR for your fixes/enhancements submit it and we will discuss and review the PR and ack/nack it there.

@marcosfrm
Copy link
Contributor Author

Right. Let's continue in #1516.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Our bugs
Projects
None yet
Development

No branches or pull requests

2 participants