I am writing an application which makes an exe from set of msi.
If an msi is getting upgraded, application will uninstall previous version and installs latest.
My question is, If uninstall and install require reboots do I need to reboot twice or one reboot is sufficient? Because I need to reduce reboots as much as possible.
Related
so I have installed some python nltk libraries (pip3 install) and c++ libraries (via apt-get install package_name_xxxx) on two different VMS instances.
Python packages for nltk would disappear and require a reinstall after reboot or change of the vms instance (e.g., add memory, cpu core),
C++ libraries disappeared without rebooting or any change of the machine. I do not find anything in the systemlog, a reinstall with apt-get works fine. But I am trying to figure out why it happens.
Is your GCE instance a preemptible instance? this option restarts the instance once every 24 hours and could be the reason why you are missing some packages.
After about an hour of inactivity, modifications not within the $HOME directory are lost. This includes installed packages.
See Custom installed software packages and persistence and usage limits.
I've spent all week trying to find an answer to this issue through google
I have installed VirutalBox 6.0.0 on a Windows 10 64-bit host, and I have created a VM and installed the latest CentOS 7 iso (CentOS-7-x86_64-DVD-1810). I have installed VirutalBox Guest Additions in the guest; there were no errors during the installation, and I'm enjoying some of the VirtualBox features that require Guest Additions (e.g. shared clipboard, shared folders, drag-and-drop, etc).
My only problem is that my resolution is limited to sizes no greater than 1024x768 and the "auto-resize guest display" option in VirutalBox is greyed out. I've tried setting up new VMs. I've tried reinstalling guest additions. I've tried reinstalling guest additions after updating the kernel to the latest version, and without updating the kernel at all. I've verified that I have all of the necessary packages to build against my current version of the kernel (e.g. kernel-headers, kernel-devel, etc). I've verified that systemctl shows the guest additions services as starting successfully. I've tried modifying my grub configuration to use vga=ask and selecting one of the alternative resolutions available there, but CentOS never finishes booting if I do that.
I am at wit's end. Does anyone have any other ideas?
Versions:
Windows 10 64-bit host
VirtualBox 6.0.0
CentOS 7 guest using CentOS-7-x86_64-DVD-1810.iso
After trying an insane number of combinations, I was able to get this working with the following procedure
1) Install clean CentOS7
2) Update to latest kernel
3) Remove all kernel packages for the old kernel version
4) Build VBoxLinuxAdditions
What was weird was that this procedure didn't work for the older kernel (e.g. the one that came with my fresh CentOS7 install, prior to updating it with yum); the CentOS7 installer was installing the headers for the newer kernel even if I hadn't installed the newer kernel yet. So there was some sort of version mismatch between what VirtualBox thought it was building against vs what it was actually building against, resulting in nothing working until I had removed all traces of the old kernel.
I'm using cloud-init to configure my EC2 instances at launch time, currently just on CentOS 7. I need to upgrade to the latest kernel, etc so first I have:
package_upgrade: true
Then I add a bunch of repos and install some packages with yum that ultimately compile some kernel modules with DKMS (Nvidia drivers)
Finally I reboot the system with:
power_state:
mode: reboot
timeout: 30
This all works great! However, when the system comes back up, DKMS reports that the nvidia driver is "added" but not installed and the Nvidia driver doesn't work. If I yum reinstall nvidia-kmod everything works. So obviously what's happening is the kernel module is being compiled and installed for the previous kernel and not the new kernel.
So what is the suggested way to solve this? Is there a way to reboot after the package_upgrade but before any of the other steps? Is there a way to force nvidia-kmod to compile for the new kernel and not the current kernel? Any other ideas?
Looks like the only real option is to create a cloud-init per-boot script that runs dkms-autoinstall. This attempts to compile any "added" kernel module that aren't yet installed on every boot.
I have a build system, it makes me the build of my c# software, and then runs a build to make my setup and deploys it into a repository.
Now, what I need is, after this deployment, I need this setup installed on a virtual machine or sandbox.
How can I do that? Is there any software that does this for me?
For example, after the build of setup is done, this software with my own configuration, takes my setup and install in silent mode in this VM/ sandbox, and then if I want I can run also tests.
The main idea is, whenever a build is deployed, it's automatically installed in a machine for me, to quickly see the result/ run tests, otherwise I need always, after build, open machine, install and test.
You can look into the use of Vagrant with VirtualBox for such a setup.
Once you finish the build and have the installer ready, you can mount/copy it into a new VM you provision with Vagrant.
You then add the installation command to your Vagrantfile (file describing your VM configuration and setup).
This is a very common setup for automated build, install and test scenarios.
I hope this helps.
I am trying to upgrade a Couchbase Community server that is currently running 3.0 to 4.0. I am using the 'Amazon Linux' on AWS, and have used the CentOS 6 build to upgrade from 2.5 to 3.0 - that upgrade was super smooth. According to the documentation, I should be able to go from 3.x to 4.x just fine as well.
http://developer.couchbase.com/documentation/server/4.0/install/upgrade-matrix.html:
Upgrade from the latest version 3.x directly to version 4.x using any supported upgrade strategy.
But I get the message
couchbase-server conflicts with couchbase-server-community-4.0.0-4051.x86_64
I have found that the couchbase-server name is now reserved for the enterprise edition, and couchbase-server-community is now used in 4.0 for the community edition, which would explain the conflict. https://issues.couchbase.com/browse/MB-15716
Is this really an upgrade-breaking change? I cannot find any documentation on how to resolve this change short of uninstalling and reinstalling.
If it were me and since you are on AWS, just spin up new instances, install Couchbase on them and do rebalances where you add one in and remove an old one (1 in, 1 out or 2 in, 2 out, etc.). With the same amount going in and out of the cluster, the cluster will do a swap rebalance which is the most efficient. All of this can be done while up and serving traffic. This is a very standard upgrade path and the recommended approach when in the cloud.
Once upgraded, discard the old instances. Yes you are running more instances at the same time during the upgrade, but for the cost of a few lattes you are upgraded smoothly.
I have experienced the same conflict when trying to upgrade from Community version 3.0.1 to Community 4.0.0.
It is worth mentioning that if you uninstall the 3.0.1 version and then install 4.0.0, all your buckets and their data are kept. Maybe there are some cases where this would fail, always good to take a backup first, but in my case the transformation was smooth.
This was on my developer machine, for a cloud installation I really like the swap in/out which means you can do the upgrade without interruption of the service.