Booster fails to load sd_mod.ko #185
Comments
|
If Could you please run |
Is there any way to specifically debug loading of modules by the init? With
Not sure if this information is important, but both modules are definitely included in the image (even without Also: Do you mean Config: |
|
Your I assume you use up-to-date Alpine Linux. So I ran so far, things look good on my side. A few more things to try on your side:
If nothing helps, then I need your boot debug log to understand what is going on with the module loading. Enable the debug log with But before |
|
Thanks for looking it it. I am indeed using Alpine Linux Edge. I will try the |
|
I finally found some time to look into this again. This is definitely not a dependency resolution problem (as I originally assumed). If I only force load moduledependencies:
# …
sd_mod:
- scsi_mod
- t10_pi
# …So the problem seems to be that |
|
The module loading happens at Line 121 in 2b49c7c Note that each module is loaded in a separate goroutine and if loading has failed it does not stop the boot process. |
The easiest ay would be to enable this flag, then boot to emergency shell, then check output of |
I am aware of that I was just wondering where
Right. Unfortunately, I don't see any errors or warnings in the |
|
This does not seem to be specific to a certain hardware. On older ThinkPads of mine, Booster is also unable to load I still don't fully understand how Booster is expected to load
booster/generator/generator.go Line 346 in e17e9e0 and Lines 918 to 926 in e17e9e0 Should |
|
Any kernel module can be loaded by booster as a result of udev event alias matching or as a dependency of another loading module, or as a force load via config. Here are the modules aliases for alpine kernel So in this case, any matched alias will trigger In your logs I see following entry that should match the Could you please share content of your image's |
|
Also, my guess is that using |
|
Finally found some time to look into this again. tl;dr There seems to be a mismatch between
Ah! So Thanks for pointing this out!
I also have an alias for
This file does not contain an alias for
I don't have an alias for The following patch fixes this problem for me: diff --git a/generator/kmod.go b/generator/kmod.go
index 9723d32..1ae1989 100644
--- a/generator/kmod.go
+++ b/generator/kmod.go
@@ -596,6 +596,10 @@ func (k *Kmod) filterAliasesForRequiredModules(conf *generatorConfig) ([]alias,
var filteredAliases []alias
for _, a := range k.aliases {
+ if strings.HasPrefix(a.pattern, "scsi:t_") {
+ a.pattern = strings.Replace(a.pattern, "scsi:t_", "scsi:t-", 1)
+ }
+
if k.requiredModules[a.module] {
filteredAliases = append(filteredAliases, a)
}With this patch applied: 🎉 Booster boots fine with this patch without force loading any additional modules. 🎉 Do you have any clue why the module names in |
nmeum
added a commit
to nmeum/booster
that referenced
this issue
Nov 29, 2022
From modprobe.d(5): Note that module and alias names (like other module names) can have - or _ in them: both are interchangeable throughout all the module commands as underscore conversion happens automatically. For this reason, we need to make sure that everywhere where module or pattern names are compared that this comparison is always performed on a normalized string. Fixes anatol#185
nmeum
added a commit
to nmeum/booster
that referenced
this issue
Nov 29, 2022
From modprobe.d(5): Note that module and alias names (like other module names) can have - or _ in them: both are interchangeable throughout all the module commands as underscore conversion happens automatically. For this reason, we need to make sure that everywhere where module or pattern names are compared that this comparison is always performed on a normalized string. This commit adds several normalizations for module and pattern names that were previously not performed. Fixes anatol#185
|
As it turns out, Fix in #197 |
anatol
pushed a commit
that referenced
this issue
Nov 29, 2022
From modprobe.d(5): Note that module and alias names (like other module names) can have - or _ in them: both are interchangeable throughout all the module commands as underscore conversion happens automatically. For this reason, we need to make sure that everywhere where module or pattern names are compared that this comparison is always performed on a normalized string. This commit adds several normalizations for module and pattern names that were previously not performed. Fixes #185
anatol
added a commit
that referenced
this issue
Nov 29, 2022
It is needed to account for the recent changes to the alias names handling. Related #185
anatol
added a commit
that referenced
this issue
Nov 29, 2022
It is needed to account for the recent changes to the alias names handling. Related #185
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After a recent system upgrade, Booster failed to prompt for my FDE password. I investigated this further and noticed that the device files for my SATA devices are not present in the BusyBox emergency environment. Hence, Booster does not find my encrypted LUKS partition and thus doesn't prompt for a password. The device drivers for my SATA device require the
sd_modkernel module to be loaded by Booster, which it doesn't seem to do automatically anymore for some reason.Manually loading
sd_modin the BusyBox emergency shell results in the following error:As it turns out, these symbols are provided by
t10_pi.koand indeed loadingt10_pi.kofirst and then loadingsd_mod.koworks as expected:According to
modinfo, thesd_modmodule also has a direct dependency ont10_pi.koon my system:As such, maybe this issue is similar to #133 in the sense that dependencies are not correctly taken into account and therefore
sd_mod.kois not loaded by Booster and hence it doesn't prompt for the LUKS password? This hypothesis seems to be confirmed by the fact that using the followingmodules_force_loaddeclaration in/etc/booster.yamlmakes Booster work again:As I mentioned above, I encountered this after a system upgrade. The system booted fine with Booster in the past without the
modules_force_loaddeclaration. However, I am not sure if this is a regression introduced in Booster 0.9 or if this is due to a recent Kernel upgrade.The text was updated successfully, but these errors were encountered: