upgrade

All posts tagged upgrade

Upgrading Fedora to newer release

Posted by phatdee on January 19, 2018
Posted in: Dnf, Package Manager, RPM. Tagged: , , , . Leave a Comment

 

 

This will refresh the repodata with version 26 and then install/upgrade 1000+ RPMS to proceed.  Once it’s done, reboot and pray your system comes back up.  But if you’re like me and running Nvidia graphics card than when you reboot your system will probably hang after the grub menu.  It is advisable that you go grab the latest Nvidia driver ahead of time, unless of course, you like running out of run-level 3 or single user mode.

Here’s a good guide to follow on updating the Nvidia drivers for your new kernel.   https://www.if-not-true-then-false.com/2015/fedora-nvidia-guide/

On this note, I usually exclude any new kernels from downloading when updating just to avoid the nvidia mess.  To exclude using dnf.

Add to /etc/dnf/dnf.conf under [main] section:

 

Crashplan on headless QNAP installation starts failing after auto-update.

Posted by phatdee on January 27, 2015
Posted in: Backups. Tagged: , , , , , , . 13 comments

Crashplan has an auto-update feature built into it’s software, which is a good thing except that Crashplan on a headless QNAP box will start failing when this happens.   If the package maintainer would update the QNAP package when this happens this wouldn’t become a problem.  But I’ve yet to see this ever happen.

Here’s the fix.

You will notice an upgrade directory in your root Crashplan directory, my default directory is /share/MD0_DATA/.qpkg/CrashPlan/upgrade.  If your directory is anything like mine, you will have a bunch of directories with #s on them…these are all the failed automatic upgrades the Crashplan attempted to perform and has failed.  I didn’t even noticed it was failing until my weekly email came out from Code42 and noticed my backups have been failing for about a week due to this.

First stop crashplan on your Qnap,

Find the last failed attempt..

cd into the last one listed.

In this directory you will find two jar files, c42_protolib.jar and com.backup42.desktop.jar .

(make note of this directory as we will be needing this in a second..)

Now jump over to the main default CrashPlan lib directory, mine is in

/share/MD0_DATA/.qpkg/CrashPlan/lib/

Need to copy the two jar files listed above into this lib directory, but first make backups of these files..

Once these are copied, now restart crashplan.

Now re-open your Crashplan client that runs over the SSH tunnel and viola.. you should be good to go..  It should be scanning for changed files to back up.

Once you have verfied this is working again, then remember to clean up the upgrade directory .. you can remove all those numbered directories.

 

Continue Reading

Updating SLES SP1 to SP2 via zypper

Posted by phatdee on July 9, 2012
Posted in: SLES/Suse. Tagged: , , , . 3 comments

Here’s an easier way without needing to go through lame ass yast.

 

Online Migration with zypper¶

  1. When all requirements are met (see Section 7.5.1.1, “Requirements”), the “products” needed for the online migration have been added to /etc/products.d. Get a list of these products by running the following command:

    This command should at least return SUSE_SLES-SP2-migration. Depending on the scope of your installation, more products may be listed.
  2. Install the migration products retrieved on the previous step with the command zypper in -t product LIST_OF_PRODUCTS, for example
  3. Register the products installed in the previous step in order to get the respective update channels:
  4. Refresh repositories and services again:
  5. Check the list of repositories you can retrieve with zypper lr. At least the following repositories need to be Enabled:
    • SLES11-SP1-Pool
    • SLES11-SP1-Updates
    • SLES11-SP2-Core
    • SLES11-SP2-Updates

    Depending on the scope of your installation, further repositories for add-on products or extensions need to be enabled.

    If one of these repositories is not enabled (the SP2 ones are not enabled by default when following this workflow), enable them with zypper modifyrepo –enable REPOSITORY ALIAS, for example:

    If your setup contains 3rd party repositories that may not be compatible with SP2, disable them with zypper modifyrepo –disable REPOSITORY ALIAS.

  6. Now everything is in place to perform the distribution upgrade with zypper dup –from REPO 1 –from REPO 2 .... Make sure to list all needed repositories with --from, for example:

    Confirm with y to start the upgrade.

  7. Upon completion of the distribution upgrade from the previous step, a Minimal Migration has been performed (a minimal set of packages has been updated to the latest SP2 level). Skip this step if you do not intend to do a Full Migration.

    In order to do a Full Migration (updates all packages to the latest SP2 level), run the following command:

  8. Now that the upgrade to SP2 has been completed, you need to re-register your product:

  9. Last, reboot your system.
  10. Your system has been successfully updated to Service Pack 2.