create-virtualbox-repo-0.0.1 (IPS support)

[stes]

I've created a script to load the SVR4 VBoxSolarisAdditions.pkg into a Solaris IPS repository.

This method can co-exist with the "old" pkgadd method.

The new method provides "pkg install"

See http://users.telenet.be/stes/ or more exactly
http://users.telenet.be/stes/create-vir ... 0.1.tar.gz

Currently the base (non X11) drivers can be loaded:

Code: Select all

stes@mix:~$ pkgrepo -s /var/pkgrepo list -p local
PUBLISHER NAME                                          O VERSION
local     virtualbox/guest/filesystem                     6.0.0-2.126642:20181126T105724Z
local     virtualbox/guest/module                         6.0.0-2.126642:20181126T105644Z
local     virtualbox/guest/mouse                          6.0.0-2.126642:20181126T105704Z
local     virtualbox/guest/vboxguest                      6.0.0-2.126642:20181126T105621Z

[stes]

The script is now at:

https://sourceforge.net/p/create-virtualbox-repo

It can be used to load the virtualbox packages in a Solaris "repo" as explained on the "Wiki" at that website.

[socratis]

I'm not into Solaris, but why wouldn't the official method with mounting the "VBoxGuestAdditions.iso" in the guest, and then running the "VBoxSolarisAdditions.pkg" work?

[stes]

The script from
https://sourceforge.net/p/create-virtualbox-repo
loads the .pkg into a repository, which is a database of all versions of the software.

The repository can be used to automatically update and install operating system images.

You can always do individual installations of packages but with a repository you can easily deal with dependencies and revert (rollback) changes.

After a while, if you load with the script the pkg into a local repository, you get a database like this:

Code: Select all

pkgrepo -s /var/pkgrepo list pkg://local/virtualbox/guest/vboxguest

PUBLISHER NAME O VERSION
local virtualbox/guest/vboxguest 6.0.12-133076:20191011T164535Z
local virtualbox/guest/vboxguest 6.0.10-132072:20190721T140831Z
local virtualbox/guest/vboxguest 6.0.8-130520:20190515T113535Z
local virtualbox/guest/vboxguest 6.0.6-130049:20190417T151021Z
local virtualbox/guest/vboxguest 6.0.5-128870:20190215T172606Z
local virtualbox/guest/vboxguest 6.0.4-128413:20190129T145928Z
local virtualbox/guest/vboxguest 6.0.2-128162:20190119T183637Z
local virtualbox/guest/vboxguest 6.0.0-127566:20181219T130909Z
local virtualbox/guest/vboxguest 6.0.0-127566:20181219T130755Z
local virtualbox/guest/vboxguest 6.0.0-127378:20181211T084747Z
local virtualbox/guest/vboxguest 6.0.0-3.127054:20181210T095011Z
local virtualbox/guest/vboxguest 5.2.29-130064:20190418T145609Z

[socratis]

And why would you want to have GAs that do not match your main program? Unless you know what you're doing, unless you're hunting for a specific bug regression, I can only see this as a confusing situation for the end-user, don't you think?

[stes]

The database runs on a "repository server" (package server). The individual guests can update from the repository server to the latest version ...

The script is used to load new guest addition packages (as they are released) into the repository server.

[fth0]

To illustrate socratis thoughts with a real-world example:

How do you ensure that a user, using deliberately VirtualBox 5.2.34, doesn't accidentally install the VirtualBox 6.0.14 Guest Additions?

[stes]

I'd be using (assuming that I am that user and assuming that 5.2.34 is loaded by the "create-virtualbox-repo" script into the repo and assuming that 5.2.34 is the latest verion in that repository (database)) something like:

Code: Select all

pkg install -v vboxguest

Anyway, I've just updated the script to load 6.0.14 guest additions, and then I use :

Code: Select all

pkg update

to update the guests to 6.0.14 because the host software is now at 6.0.14.

Frankly if you prefer to use "pkgadd" there is not a problem, it's fine to use pkgadd as that method can coexist and it's a perfectly fine method , certainly for older versions of Solaris, which also must be supported by VirtualBox.

Also on Solaris 11 that method still works (the method of pkgadd still works).

The script just loads the package into a repository.

[socratis]

I still see it as an unnecessary and dangerous approach. There's a pretty standard way that needs no repositories or anything like that, and it's as rock-solid, user-error-free, universal and timeless, as it gets:

With the VM window having the focus, go to the host's menu "Devices" » "Insert Guest Additions CD Image...". If not prompted by auto-run, run "VBoxSolarisAdditions.pkg" from the CD.

Done!

[stes]

That approach is not without its own issues ...

For example, I reported a while ago that I couldn't "pkgadd" the guest additions on Solaris 8.

The reason is that it has SMF scripts and those scripts are not valid for Solaris 8 and Solaris 9.

So whatever approach is used, there's always some issues ...

I'm in favor of "pkgadd" (SVR4) for the distribution of the binaries. That's a good approach for Solaris 10 and 11 as well.

However with the script you can load the SVR4 packages into a repository which for some users (like myself) is useful.
It is useful because it is fast to update from a central repository and as I've indicated in some other threads, there's bugs in the SVR4 script for example it doesn't support the -R relocation option, while I can "pkg install" with relocation without problems (which is required for AI automated unattended installations).

[fth0]

I've read in your other thread that you created separate repositories for the VirtualBox 5.2 and 6.0 major versions, which hopefully prevents a potential major version mismatch. But a minor version mismatch can also provide problems to the VirtualBox user (note that in VirtualBox 6.0.14, the major version is 6.0 and the minor version is 14):

Let's assume the user has VirtualBox 6.0.12 installed on the host, and the matching Guest Additions 6.0.12 installed in the guest. Now the newer VirtualBox minor version 6.0.14 is released. First, the user updates VirtualBox on the host to VirtualBox 6.0.14, and then starts the guest. The older Guest Additions 6.0.12 in the guest typically can be expected to not crash the guest, so that the user can update them now (without having had to deinstall them before updating VirtualBox on the host). But the user in general can not expect the older Guest Additions to work reliably with the newer VirtualBox version on the host. The same holds true for the opposite combination, which can occur when updating the Guest Additions first.

The reason behind that is that the combination of different minor versions between VirtualBox and the Guest Additions is probably not tested in development, with the exception of the suggested upgrade path (and even that will probably only be tested with successive minor versions). Additionally, there is no mechanism in place to guarantee a version match between the host and guest components of VirtualBox discussed here (add the VirtualBox Extension Pack for even greater complexity ). These are the reasons why the forum regulars typically suggest to install the Guest Additions accompanying the VirtualBox host software (by using the Insert Guest Additions CD image... menu item of the VirtualBoxVM window).

I'd suggest to inform the user of your script to ensure using the Guest Additions minor version matching his VirtualBox installation on the host.

[socratis]

For example, I reported a while ago that I couldn't "pkgadd" the guest additions on Solaris 8.

Then this should be treated as a bug and you should head to the bug tracker. Either search for an appropriate bug, or open a new bug report where you'll attach your logs and other vital information.

[stes]

The depot (repository) is just a database, a useful tool exactly to make sure that the guest operating system is running or can run the right (same) version of the guest addition, so that minor and major version matches with the host software.

For example now with the new 6.1 BETA1 this can be added to the repository and then the guest can install with:

Code: Select all

pkg install

the correct version (6.1 BETA1) which we agree should be the same version as the host.

This can be done with automatic installations with a manifest

Code: Select all

      <software_data action="install">
        <name>pkg://local/virtualbox/guest/vboxguest</name>
      </software_data>

This helps to automatically deploy the right version of the guest additions immediately on the host.