Tag / install

What to do when /boot is full?

One thing to do is to remove old kernels:

Do the following to keep just the last 2 kernels on your system, to keep /boot clean:

    1. Edit /etc/yum.conf and set the following parameter 
      installonly_limit=2

      This will make your package manager keep just the 2 last kernels on your system (including the one that is running)

    2. Install yum-utils: 
      yum install yum-utils
    3. Make an oldkernel cleanup: 
      package-cleanup --oldkernels --count=2

      This will erase in a good fashion the old kernels, and, keep just the last 2 of them for the next upgrades.

How to upgrade from ownCloud 10.0 to nextCloud 15

Intro

Debian does not support nextCloud out of the box. Therefore there is no way to migrate from ownCloud to nextCloud with Debian’s on board tools. But there is a user maintained repository providing debian backages for the latest version of nextCloud.
At the time of writing, the latest version of ownCloud is 10.0.10.  For nextCloud version 15.0.2 is the latest.  There is no direct way to get from ownCloud 10 to nextCloud 15.  Instead we have to migrate from ownCloud 10 to nextCloud 12 first.  After that we will go from nextCloud 12 to nextCloud 15 version by version.  The last step is to replace the installation by the packages provided by the above mentioned user.

Backup

The first an most important step in the upgrade is to first create a backup of the database.  This can be done with

$ read PWD ; mysqldump --user=root --password=$PWD --databases owncloud > /tmp/owncloud-20190212.sql ; unset PWD

In case we need to go back to the current ownCloud setup, the backup can be played back with

$ mysql -u root -p owncloud < /tmp/owncloud-20190212.sql

Migrate from ownCloud to nextCloud

Basically there are two ways to migrate from owncloud 10 to nextCloud 12.

Using the Migration tool

The first way to migrate is to use nextCloud’s migration tool.  For this download the index.php to your server and save it into the folder updater in your ownCloud installation. Navigate to your onwCloud server and into the sub location

your.owncloudserver.com/updater/index.php

Now you should be able to start the upgrade process.  But this way the server ist not working properly after the upgrade.  Also since you need to replace one of the files on the server, the second migration method is the better way to do it.

Manual migration on the command line

The second way to do the migration is using the command line tools.  First let’s prepare the upgrade process.  We will need the following packages from the nextCloud download server:

Next we set the server into the maintenance mode:

sudo -u www-data php /var/www/owncloud/occ maintenance:mode --off

Now we can switch the site to the code of nextCloud 12.  Let’s assume, the web server is reading the files from /var/www/owncloud.

cd /var/www
mv owncloud owncloud.old
tar tfj /path/to/nextcloud-12.0.12.tar.bz2
mv nextcloud nextcloud-12.0.12
ln -s nextcloud-12.0.12 owncloud

Change into the source folder:

cd /var/www/owncloud

The first step in the migration itself is to setup the page source. The files are unpacked with the wrong user and group, so let’s give them to the web user:

chown -R www-data:www-data .

Next we need to point the new installation to the old config files.  Let’s again assume, the config files are hosted in /etc/owncloud. So we need to remove the old config and link to the existing config:

rm -r config
ln -s /etc/owncloud config

Now we are ready to do the upgrade with:

sudo -u www-data php /var/www/owncloud/occ upgrade
sudo -u www-data php /var/www/owncloud/occ maintenance:mode --off

Check Config

Before moving on, we need to check, if all apps and data are still there.  And actually the upgrade has disabled the apps Calendar, Contacts and Tasks.  They need to be reinstalled in the web interface.  All the user data should still be there, even the contacts, calendar entries and tasks.

Upgrade to version 14

Basically the upgrade from nextCloud 12 to 14 involves the same steps as for the migration. So basically we do:

cd /var/www
tar xfj /path/to/nextcloud-<version>.tar.bz2
mv nextcloud nextcloud-<version>
rm owncloud
ln -s nextcloud-<version> owncloud
cd owncloud
chown -R www-data:www-data .
rm -r config
ln -s /etc/owncloud
sudo -u www-data php /var/www/owncloud/occ upgrade

After every step we need to check, if all apps and data are still there. And again, Calendar, Contacts and Tasks need to be resintalled again after the upgrade to nextCloud 14.

Final Step — Upgrade to 15

The final upgrade to version 15 is not done manually, but by pulling in the Jurisic Debian Repository.

We start by adding the source to apt:

echo "deb http://apt.jurisic.org/debian/ stretch main contrib non-free" >> /etc/apt/sources.list.d/nextcloud.list
wget -q http://apt.jurisic.org/Release.key -O- | apt-key add -

Now we can install nextCloud 15 using the apt-tool chain:

apt-get install nextcloud

This will install nextCloud in /var/www/nextcloud. Now we can go to the known procedure for a last time:

cd /var/www
rm owncloud
ln -s nextcloud owncloud
cd owncloud
rm -r config
ln -s /etc/owncloud
sudo -u www-data php /var/www/owncloud/occ upgrade

For a last time we need to check, if all the data and apps are there, and if so, the migration is finished.

pacman error: FILENAME exists in filesystem

error: failed to commit transaction (conflicting files)
libname: /insert/file/name/here exists in filesystem
Errors occurred, no packages were upgraded.

Why this is happening:

pacman has detected a file conflict, and by design, will not overwrite files for you. This is a design feature, not a flaw.
It is the user’s responsibility to maintain their system, not the package manager’s. (pacman -Qo may be invoked to query which package owns the file, if any.)

What can be done to solve this:

The issue is usually trivial to solve. A safe way is to firstly check if another package owns the file (pacman -Qo <full file path>). If the file is owned by another package file a bug report If the file is not owned by another package rename (or remove) the the file which ‘exists in filesystem’, and reissue the pacman -Syu command. If all goes well, the file may then be removed.

See also: ArchLinux Forum.