SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I want to create a Slackware package with the VirtualBox guest additions in it. The latest official ones, not the old 5.0.40 version on Slackbuilds. I don't need anything in this package other than the ability to execute programs in the guest, but a complete package would of course be nice.
Creating a Slack build script to compile the kernel modules and package up the binaries seems prohibitively complicated, so I'm left with (I think) two options:
1) Look for recently changed files and so capture the files/symlinks that got installed when I ran the installer
2) Watch the file system using some software that will give me callbacks on changes.
I'm just wondering how other people are solving/have solved this problem. I know I can google all sorts of possible solutions to this but I'm looking for real-life experiences, ideally giving me a generated package, or enough bits that I don't have too much coding to do to finish the job.
Why? It all gets installed under /opt. There's no need to package it. I don't package VirtualBox or LibreOffice for the same reason.
For my own personal VM? Yes, but it's not for that. I need the package, and I'd very much appreciate not having to argue about that here, even if you are just trying to be helpful.
I'm just wondering how other people are solving/have solved this problem.
I'm using VirtualBox 5.2.28 on 14.2 64-bit. I've been using that branch for a long time. I modified the 5.0.40 SBo built script. Look here for a discussion about modifying the build script.
For my host systems I much prefer packages. For my VMs I use the main and kernel module build scripts. The kernel module package gets rebuilt occasionally. For example, today I updated to 4.4.199 and rebuilt the kernel module package.
Mostly because VMs are "disposable," for VirtualBox guest systems I never use a package, regardless of the OS in the VM. Instead I insert the GA ISO and install from there with the guest system OS prompts/dialogs. While not a hard requirement, if a VM remains on my system for a while and I update the main VirtualBox package, I repeat the GA ISO process to keep the two versions in sync.
Loosely related, at work we use Proxmox (free/libre software). Mostly for servers with no GUI, but we have three Windows VMs using the virtio drivers, which is somewhat the equivalent of VirtualBox GA.
Been this route use VB . Just use KISS and let VB do what they do Slackware is built for what they do.
Slackware HISS And VB run is made to go together. PKG will break.
Why? It all gets installed under /opt. There's no need to package it. I don't package VirtualBox or LibreOffice for the same reason.
Why? It fits the package management system of Slackware and allows adding. upgrading and removing using slackpkg. I have a package for installation of a single file. Overkill perhaps, but I don't have to remember I put it on my system. I have a package that takes care of that.
Been this route use VB . Just use KISS and let VB do what they do Slackware is built for what they do.
Slackware HISS And VB run is made to go together. PKG will break.
You presume to know what my project is, what its requirements are and then proceed to tell me to not try to do what I'm doing. I really hate this about public forums, you see it on stackoverflow all the time. I suppose I could have kept it simple and not work on any of my open-source projects, spent time in the garden clearing up leaves and that would 'keep it simple', as you say. But the point is I came here looking for help. I didn't want to get drawn into a protracted discussion on this, but how would you make the additions available in initrd? Put the entire kernel sources and compiler into RAM? I suppose you're now going to tell me I don't need to do that either, and on it goes.
Please can people stop filling this thread with cruft that doesn't answer the question. If you don't know the answer, then please don't post.
But the point is I came here looking for help. I didn't want to get drawn into a protracted discussion on this, but how would you make the additions available in initrd? Put the entire kernel sources and compiler into RAM?
The problem is: the VB guest additions are dependant on BOTH the VB version and the kernel version (as it installs kernel modules for the guest O/S), so your package would have to be updated about every week (for Slackware-current).
It would be more usefull to just create a SlackBuild script, that REcompiles the kernel modules every time you update the kernel in your VM, so:
fetch the additions in the VM and use its install script to build the stuff.
It would be more usefull to just create a SlackBuild script
This is correct, it would be more universally useful and I'm sure a lot of people would want to use it, however I have a hunch it would be harder than tracking the install process, and the process would change if the VB code changed. That said, I'm unsure how often they do that. But I suppose unless I actually do it both ways, I'll never know! One spin-off is that if I wrote (or figured out how to adapt) a utility to track the install it could be useful for the generation of other packages.
I don't need to do this every two weeks, when a new current comes out, I only need to do it from time-to-time. But I think that doesn't matter too much, I do still need a way to automate the generation of such a package using some kind of networked service, and that's another challenge to be solved, probably using vagaslack as a starting point. Plenty of challenges ahead that's for sure.
So how do you know what files were installed where and
even if you did, how do you pull all these files together in order
to run makepkg over them ?
That's the purpose of slacktrack! :-)
slacktrack only works with 'official' Slackware directory locations
and /usr/local.
For example, if your make install installs binaries in /opt/packagename/bin
and the man pages in anywhere other than /usr/man or /usr/local/man, then
slacktrack's relevant options (eg stripping libs, bins, gzman) will
not detect them.
Although I'm unsure how much of a problem that is.
For info, slacktrack was able to get me *something*, even with just default parameters. I need to remove the /etc/* files that it picked up and change those into doinst.sh commands to create the relevant users/groups, figure out how to remove the /dev/vbox* files. There seem to be a few different ways to approach this but the simplest seems to be a post build script. I don't think I need to create a .build file because I can run the perl installer direct from slacktrack.
Once I've done that it will be interesting to see if the created package installs and runs.
It would be more usefull to just create a SlackBuild script, that REcompiles the kernel modules every time you update the kernel in your VM
It is already created by the VirtualBox VM scripts itself; when you update the kernel in VM /sbin/rcvboxadd updates vbox* kernel modules for your VM and after you initiate VM reboot or shutdown.
All you need -- remove vboxguest.ko module (and maybe vboxvideo.ko module) installed from the kernel-modules package:
/lib/modules/<kernel-version>/kernel/drivers/virt/vboxguest/vboxguest.ko
/lib/modules/<kernel-version>/kernel/drivers/staging/vboxvideo/vboxvideo.ko
For my own personal VM? Yes, but it's not for that. I need the package, and I'd very much appreciate not having to argue about that here, even if you are just trying to be helpful.
I believe that I owe you an apology. I completely mis-read the question and thought that you were trying to package the VirtualBox Extensions.
The best starting point for you is going to be the Slackbuild for the old version. Download the files, look at what it does and replicate that with the new version. That will simplify things and most likely will answer your questions. There is one qualification to this: I'd make the suggestion that you use sysv-style scripts (which Slackware supports) instead of physically adding commands to the rc.local file (IMO, manually adding things to rc.local ruins the "portability" of the package).
I use a Slackware VM to run & maintain the mission-critical backups for my business and haven't bothered packaging the guest additions, although that's running on a bare metal hypervisor (not VBox) and it's a very basic installation without X.
Unfortunately now my issue is makepkg, or lack of understanding thereof. I can't get my setup script executed. According to the manual it's supposed to be put in
/var/lib/pkgtools/setup/setup.*
Although I've also tried:
/var/log/setup/setup.* as well.
installpkg doesn't seem to execute it regardless of which I use. If I execute the setup script manually everything seems to work, so that's the good news.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.