Welcome to the Slackware Documentation Project

Very useful and timely page addition. Thanks Eric.

I am wondering whether there needs to be discussion of the case where the previous release was using the generic kernel with an initrd. Following this guide would cause the old initrd.gz to be overwritten, leaving the user possibly unable to boot with the old kernel.

I would also like to see some discussion of how to handle the .new files. Slackpkg helps with this, but I also use vimdiff when dealing with configuration files with customised local settings (e.g.sshd_config, cupsd.conf) — David Allen 2012/09/20 17:52

In my humble sysadmin experience, it would be useful to add a side note that it's generally much less hassle to do a fresh clean install of a new release. On production servers, changing the hardware is a fine occasion to install a fresh release. On production desktops, it's really no big deal to backup files and configuration to a local server and/or external hard disk and do a fresh install. Niki Kovacs Fri Sep 21 09:48:19 CEST 2012

Hi Niki. A fresh install is usually better if your upgrade would span multiple releases (for instance, 10.1 → 13.37). But those cases are not supported by slackpkg anyway. I will add a note about this. Also I will stress that a new name should be used for a new initrd in order not to overwrite an existing initrd…
David, I will also expand a little about .new files.
Eric Hameleers 2012/09/21 04:48

Just saw the changes you made regarding initrd and .new files (I must have missed the updates in the recent changes list). Thankyou for addressing those little concerns. — David Allen 2012/09/26 08:05

I used a somewhat different method when I upgraded a couple months back. However, I like your method and may try it next year when Pat officially sets Current to Beta again for 15. :-)V. T. Eric Layton 2012/09/21 18:13


Hi Eric. Very nice job. Just a question here: shouldn't slackpkg be updated using the slackware media before its first usage? My reasoning is that at the first usage the mirrors file won't have 14.0 mirrors for example if I'm upgrading from 13.37 to 14.0. — escaflown 2012/09/28 21:18


I believe, its worth to mention that, the user must change the file in /etc/slackpkg/mirrors ,to make sure that the version link, they are trying is in the list. I just blanked for some minutes, when I did the upgrade process, since every thing for 13.37 is up-to-date. After changing a mirror link to 14.0, things started to progress… - crond

Hi crond, I hope I addressed your concerns properly in my update.
Eric Hameleers 2012/10/01 13:23

——

TommyC, please respect the policy rule and suggest your changes in the discussion page instead of recklessly editing an article which is not yours. I have issues with these additions:
You can also blacklist packages that you don't want to upgrade.

hal                     # hald is no longer in Slackware 14.0 and above, but some may still want it.
kde/*                   # This will blacklist all the packages in the kde directory of the slackware tree.
kdei/*                  # Although you can use wildcards as shown above and on this line, it is NOT recommended.
xfce/*                  # The xfce directory is new in Slackware 14.0. In 13.37 and below, xfce is its own package.

First, not removing hal is an advice I do not want to see in an upgrade guide. Instead, it should be listed as a suggestion in this article's discussion page.
Second, the use of asterisks in the slackpkg blacklist does not work reliably (for instance it will not have the desired effect on the slackpkg install-new command). Therefore it does not belong in article which promises the reader a “painless” upgrade.
Also, why would you want to blacklist KDE and XFCE? If you did not have it installed, it will not be upgraded anyway, you don't have to blacklist it. And anyway, with a blacklist in place the slackpkg install-new command will still list all the new KDE and XFCE packages, which will lead to confusion.
Eric Hameleers 2012/10/01 13:23

A very useful page, thank you Eric. Just a small suggestion I would like to make: maybe you could add a note to the section where you suggest that the user keeps a working kernel listed in lilo.conf, just in case, to say that it is advisable to list it first before any other entries. That way, if there is a problem with the new kernel this working kernel will boot as the default. In my case I had listed the new kernel first and as the keyboard not responding was one of the issues I had, I was unable to select the old kernel at the prompt. — Robert Frost-Bridges 2018/04/23 21:38 (UTC)


In Other Languages
Translations of this page?:
QR Code
QR Code talk:howtos:slackware_admin:systemupgrade (generated for current page)