Code: Alles auswählen
root@xx:/home/desputin# /etc/init.d/vboxdrv setup
bash: /etc/init.d/vboxdrv: Datei oder Verzeichnis nicht gefunden
Was geht genau einfach nicht? Bekommst du Fehlermeldungen? Wenn ja, wo, wann und welche?desputin hat geschrieben:aber es geht einfach nicht
Das heißt schon seit einigen Zeiten /sbin/vboxconfig. (Auch in Jessie? Bin überfragt, habe Jessie nur unter ARM.) Solltest du aber genausowenig manuell anwenden müssen./etc/init.d/vboxdrv setup
Schau Dir mal den Eintrag genau an, kann so gar nicht gehen. Ich schätze Du hast Jessie auf Deinem PC, und willst die entsprechende Quelle von Oracle dazulinken. Dazu muss der Eintrag aber 100% passen, danach brauchst Du ein apt-get update.desputin hat geschrieben:In die sources.list hinzugefügt: deb http://httpredir.debian.org/debian/ jessie main contrib
dkms dazuinstallieren.Seit VirtualBox 5.1 verwendet VirtualBox kein dkms mehr. Stattdessen wird beim Start von VirtualBox geprüft, ob die Kernel-Module noch passen. Wenn nicht, werden sie neu gebaut. (Klappt nicht unter Wayland, man bekommt dann eine Fehlermeldung, man möge die Module bitte manuell per /sbin/vboxconfig bauen. Was man dann auch tun muß.)rhHeini hat geschrieben:und
ist das Startskript (Modulladen) vom virtualbox von oracle./etc/init.d/vboxdrv
(Bei neuerem virtualbox) kann auchvboxconfig
Code: Alles auswählen
#deb http://download.virtualbox.org/virtualbox/debian/ jessie contrib
deb http://download.virtualbox.org/virtualbox/debian/ stretch contrib
Code: Alles auswählen
$ cat /lib/systemd/system/virtualbox-load-modules.service
[Unit]
Description=loading modules vboxdrv, vboxnetflt, vboxnetadp and vboxpci
BindsTo=virtualbox.target
[Service]
RemainAfterExit=true
ExecStartPre=/sbin/modprobe vboxdrv
ExecStartPre=/sbin/modprobe vboxnetflt
ExecStartPre=/sbin/modprobe vboxnetadp
ExecStartPre=/sbin/modprobe vboxpci
ExecStart=/bin/true
ExecStop=/bin/true
ExecStopPost=/sbin/modprobe -r vboxpci
ExecStopPost=/sbin/modprobe -r vboxnetadp
ExecStopPost=/sbin/modprobe -r vboxnetflt
ExecStopPost=/sbin/modprobe -r vboxdrv
Code: Alles auswählen
$ cat /lib/systemd/system/virtualbox@.service
[Unit]
Description=Virtualbox for user %i
Requires=virtualbox-load-modules.service
After=virtualbox-load-modules.service
BindsTo=virtualbox.target
[Service]
RemainAfterExit=true
Type=oneshot
Environment=SHUTDOWN=poweroff TIMEOUT=10
#Environment=SHUTDOWN=acpibutton TIMEOUT=30
#Environment=SHUTDOWN=savestate TIMEOUT=30
ExecStart=/bin/true
ExecStop=/usr/lib/systemd/scripts/stop_vms %i $SHUTDOWN $TIMEOUT
[Install]
WantedBy=virtualbox.target
Code: Alles auswählen
$ cat /lib/systemd/system/virtualbox.target
[Unit]
Description=Start virtualbox-services for users
[Install]
WantedBy=multi-user.target
Code: Alles auswählen
$ cat /usr/lib/systemd/scripts/stop_vms
#!/bin/bash
if [ -d /tmp/.vbox-$1-ipc ]; then
export VBOX_IPC_SOCKETID="$1"
VMS=`VBoxManage --nologo list runningvms 2>/dev/null`
if [ $? -eq 0 -a -n "$VMS" ]; then
VMS=`echo "$VMS" | sed -e 's/^".*".*{\(.*\)}/\1/'`
for v in $VMS; do
VBoxManage --nologo controlvm $v $2
sleep $3
done
fi
fi
Code: Alles auswählen
systemctl enable virtualbox.targetCode: Alles auswählen
systemctl enable virtualbox@$USER.serviceniemand hat geschrieben:Hinweis: Selbsterstellte Units gehören nach /etc/systemd/system/, nicht nach /lib/[…].
Wenn du meinstniemand hat geschrieben:Hinweis: Selbsterstellte Units gehören nach /etc/systemd/system/, nicht nach /lib/[…].
Ja, sicher, warum nicht. Das ist dann eben so, als würde man das palemoon.tar oder das xnview.tar nicht nach /opt entpacken, sondern nach /usr/bin. Oder auch beispielsweise das Doublecommander.tar nach /usr/sbin. Hättest Du da was dagegen oder wäre das für Dich auch ok?MSfree hat geschrieben:Und ich dachte, GNU/Linux wäre ein freies System, bei dem ich entscheide, wo was hingehört.niemand hat geschrieben:Hinweis: Selbsterstellte Units gehören nach /etc/systemd/system/, nicht nach /lib/[…].
Wenn ich eine Unit nach /lib/systemd/... kopiere, bleibt sie bei Updates auch erhalten. Eine Datei, die die Paketverwaltung nicht kennt, bleibt auch bei Updatzes völlig unberührt.scientific hat geschrieben:Units in /etc bleiben bei updates von Paketen erhalten. In /usr/lib oder /lib nicht.
Die Konsequenzen sind in diesem Fall gleich Null.Muss halt auch mit den Konsequenzen selber fertigwerden.
Es gibt allgemeine Standards, und dafür gibt es Gründe. Wenn du für dich entscheidest, davon abzuweichen – dein Ding. Es anderen unkommentiert zu empfehlen ist nicht nett. Es kann unter gewissen Umständen durchaus zu Kollisionen kommen, und selbst wenn virtualbox nie eine eigene virtualbox.service mitbringen wird: wenn der so Beratene fortan allen seinen eigenen Kram nach /lib/[…] schmeißt, steigt die Wahrscheinlichkeit, dass es bei ihm knallt, enorm.Und ich dachte, GNU/Linux wäre ein freies System, bei dem ich entscheide, wo was hingehört.
Nein.niemand hat geschrieben:Es kann unter gewissen Umständen durchaus zu Kollisionen kommen, und selbst wenn virtualbox nie eine eigene virtualbox.service mitbringen wird: wenn der so Beratene fortan allen seinen eigenen Kram nach /lib/[…] schmeißt, steigt die Wahrscheinlichkeit, dass es bei ihm knallt, enorm.
deren Funktion überschneidet sich mit scientifics selbsterstellten Units,# ll /lib/systemd/system/vbox*
-rw-r--r-- 1 root root 495 May 4 23:38 /lib/systemd/system/vboxautostart-service.service
-rw-r--r-- 1 root root 501 May 4 23:38 /lib/systemd/system/vboxballoonctrl-service.service
-rw-r--r-- 1 root root 467 May 4 23:38 /lib/systemd/system/vboxdrv.service
-rw-r--r-- 1 root root 477 May 4 23:38 /lib/systemd/system/vboxweb-service.service
