Ha rákeresünk a "building"
stringre, akkor az a setup
függvényben van, az buildeli le a modulokat. Meghívása a start
függvényben történik, abban van egy olyan rész, hogy
if ! running vboxdrv; then
# Check if system already has matching modules installed.
[ "$(setup_complete)" = "1" ] || setup
A setup_complete
függvény
setup_complete()
{
[ "$(module_available vboxdrv)" = "1" ] || return
[ "$(module_available vboxnetflt)" = "1" ] || return
[ "$(module_available vboxnetadp)" = "1" ] || return
# All modules are in place.
echo "1"
}
csak az ellenőrzéseket végzi el. A module_available
már érdekesebb volt. Először is szerepel benne ez a komment:
# We have a convention that only modules from /lib/modules/*/misc
# belong to us. Modules from other locations are treated as
# externally built.
Oké, tehát akkor a moduloknak nálam speciel a /lib/modules/4.9.0-16-amd64/misc/
könyvtárban van a helye és ott is vannak. Viszont ezután szerepel benne ez:
# Extract last component of module path and check whether it is located
# outside of /lib/modules/*/misc.
mod_dir="$(dirname "$mod_path" | sed 's;^.*/;;')"
[ "$mod_dir" != "misc" ] || return
Namármost, ha csak a misc
könyvtárban lévőek tartoznak a VBox-hoz, akkor a $mod_dir
éppenhogy misc
kell, hogy legyen, nem pedig bármi más, tehát a
[ "$mod_dir" != "misc" ] || return
sor hibás és
[ "$mod_dir" = "misc" ] || return
lenne helyes. Na, erre a sorra rákeresvén már feljön ez a topic, ahol egy sorstársam már megreklamálta a dolgot és ahonnan tovább is irányították egy másik topicba, ahol megerősítették, hogy ez biza egy bug.
Szóval aki belefut ebbe, az ne a rendszerében/konfigjaiban keresse a problémát, mert az a VirtualBox vadiúj scriptjében van.
- TCH blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Szép találat!
- A hozzászóláshoz be kell jelentkezni