Hi,

I have a remote machine with Slackware 13.37 installed on it. I do have remote access (SSH) to it and was wondering if it is possible to upgrade it to the 14.1 version over SSH only? If it is possible, any tips and tricks that I should know will be greatly helpful.

If you could guide me through the best way to upgrade my system (if the above is not possible), that will be helpful too.

Thanks!

I can't think of anything off the top of my head that would prevent this (although, I'd make sure to see what others say since they probably have more knowledge with this), however, make sure you upgrade from 13.37 to 14.0 and then from 14.0 to 14.1. Slackware is not designed to be upgraded directly from 13.37 to 14.1. Also, make sure you read the UPGRADE.TXT within every release to find out exactly what you need to do and it would probably be beneficial to read CHANGES_AND_HINTS.TXT for each release so you can see what things have changed and what you might need to take into account with various aspects of the system (like conf files, driver loading, etc).

1 members found this post helpful.

Some good tips already in the post above.

I did this a few days ago. was pretty straight forward, I used slackpkg.

## Make sure that /etc/slackpkg/blacklist is empty / allows kernel updates
vim /etc/slackpkg/blacklist
## make sure system is fully updated:
slackpkg update
slackpkg upgrade-all
## remove old stuff and non slackware packages
slackpkg clean-system


## edit /etc/slackpkg/mirrors
## change 13.37 in your mirror to 14.0 (make sure that you do NOT mix up 64bit / 32bit!)
vim /etc/slackpkg/mirrors

## update to 14.0
slackpkg update
slackpkg upgrade-all
## install new packages added in 14.0
slackpkg install-new
## remove packages removed between releases
slackpkg clean-system

## this runs after upgrade-all, but do it again to be sure
slackpkg new-config

## I choose to use huge kernel for now because it does not need initrd
## so make sure symlink /boot/vmlinuz points to huge kernel
ls -l /boot
## also make sure kernel modules and so on got upgraded in earlier step
## kernel-modules needs to match version number from kernel-huge
ls -l /var/adm/packages/kernel-*
## edit lilo.conf, remove old entries, make sure default boot entry
## points to /boot/vmlinuz and make sure timeout is not set to high
## else it can take a long time for the box to come up again
vim /etc/lilo.conf
## run lilo
lilo

reboot and pray, now you are on slackware 14.0, repeat above steps for 14.1

Good luck, if this is an important system you better try it first in virtualbox or so,
because I wrote this from memory I hope I did not forget something

2 members found this post helpful.

Here's how I'm doing it.

https://github.com/kikinovak/slackwa...rade-HOWTO.txt

Cheers,

Niki

Be aware that You are about to Start a Very Dangerous Process. If you have only SSH access, without ability to remote reboot and select the bootloader entry, any loss of connection to remote machine into process will be equivalent with a nice remote brick.

First of all, I suggest you to use a local backup to populate a virtual machine and to test, test and test again the process, before to do it on-line. Being beyond of two versions, I suggest you to do a "clean install".

In theory, create a little partition, about 10G, if you do not already have, eventually temporary sacrifice the SWAP partition (you have one, right?) and format it with ext4, and install there the 14.1 version. Configure it with great attention, to be ensure that it will go on-line. then, install the new&fresh system into bootloader, as some secondary system.

Finally, do an 'lilo -R {NEW_ENTRY}', where {NEW_ENTRY} is the name of your new bootloader config entry, to activate "one-hit" boot for this entry. When you reboot, the new entry will be active as default for one time. If something is wrong, an eventually reboot will make active again the original default entry.

If everything is fine, after reboot, you'll be in the new partition, from where you start the real re-installation. If the system fail to go on-line from the new partition, you will have to hard reboot the server or, if you do not have this option, to ask a locally present person to do it, and you'll be again in the old/original 13.37 system.

In principle, this is the idea. BUT, again, you should know well the Slackware to start something like that. And a last suggestion: stay away from automated upgrading systems. Slackware really do not have something like this. You should do it manually, if you known what you do.

PS. Doing an "slackpkg clean-system" in a functional remote server is right on the perfect solution to nuke all nice thingies, like email servers and anti-spam systems, LDAP integrations, custom daemons, IPMI integrations, etc, etc, etc... There can be even the custom drivers for that cute SATA RAID5 hardware card who cost like a 180 inch 3D TV... Just don't do things like that, in a remote server, man!

BTW, you are very sure that your system do not depend to a old kernel version and you do not need special drivers and kernel builds?

1 members found this post helpful.

Thank you all for the very helpful replies.

@bassmadrigal, @hotchili, @kikinovak: Thanks! That gives me some confidence that there is hope.

@Darth Vader: I understand that what I want to attempt is very risky. But the situation is not that I have no local person over at the machine who can do something for me. However, that person will likely just do a simple power on/off or enter a couple of commands at the terminal and nothing more. So, if I am able to get to most of it but just need a simple couple of things at the end, I have some hope! I will certainly try what you suggested first and also like the other suggestion - I have another Slackware 14.0 installation on my current laptop, which I will try to update over SSH locally so I know what issues could arise.

Sounds daunting, but also should be fun. Will keep everybody posted.

Please let me know if there is anything else I should be aware of (if something has been missed, though it looks like it is not - the replies have been very detailed indeed!)

Yes. That machine is a fairly good one - should have no issues with newer kernel versions. The drivers have always worked by default without any trouble on that one - so I am assuming (and hoping) it would :-)

Is this step necessary? I have several non-slackpkg packages installed...

Well it's not strictly necessary, but it's good practice. You do this to get rid of old Slackware packages that have been abolished in the new version of Slackware.

Obviously you want to keep non-Slackware packages, like (for example) built from SlackBuilds.org, there is absolutely no need to remove them. To keep them you should edit the file /etc/slackpkg/blacklist. (To understand the format, read the comments in that file.)

When you run 'slackpkg clean-system', before it actually does anything, it will show you a list of packages that it thinks should be removed. These should be the same as the list in CHANGES_AND_HINTS.TXT. You can review the list and uncheck any packages that you want to keep. But it's best if that list is a small list, which is why you should add your other packages to /etc/slackpkg/blacklist.

Other random points:

(1) Before you reboot, *always* make sure you have reviewed and merged all the .new files in /etc, especially the files in /etc/rc.d.

(2) After upgrading, you might need to rebuild all your SlackBuilds.org packages, in the correct order.

(3) If you use java, you're in for a bad surprise: Oracle decided to stop Linux distributions from including it, so it was removed from Slackware-14.0. You might want to blacklist 'jre' until you have upgraded everything else.

I haven't yet had the opportunity to remotely upgrade Slackware. I have however done such an upgrade with many Debian and CentOS servers. I must have done it thousands of times though- too many to count. I worked for a software company that produced a CRM software for car dealer ships in the US, Mexico, Canada, and South Africa. I've had my fair share of, lets call them, "mistakes."

I like to make heavy use of GNU screen throughout the process. I hate it when I am in the middle of upgrading and I lose a connection in the middle of it all for whatever reason.

I also like to have SSH listen on the default port and have iptables expect port 22 prior to upgrading. Imagine a successful upgrade but now you have lost remote access to the system due to a misconfiguration of SSH/iptables port listening. There are countless ways to lose remote access and I won't go into all of them.

Make sure that all services, except SSH of course, are not running. I've seen problems with some services clobbering the system during an upgrade (eating RAM, eating CPU cycles, customers accessing the network services). I am not saying this will happen every time, or even that it happens in Slackware. I don't know what your environment is; this is more specific to 3rd party services or home grown services.

Those three suggestions have always prevented most of the bigger binds I've ran into when upgrading systems remotely.

Good luck!

Though it's not for inplace upgrading of an existing version, I've written a script that simplifies the process of booting a remote server into a Slackware installer which allows a fresh installation to a new partition.

Be aware of the following caveats:

For Slackware 13.37 and earlier, LILO needs to be upgraded to a more recent version that can handle larger kernels.

As long as the installer is running, passwordless root access is available to anybody on the network that SSHes into the remote server.

The installer (as written) assumes that 'eth0' is used for SSH access, that the NIC card can be automatically configured, and that DHCP is used. The script can be modified for other setups (though I've never tested this).

You may need to use NMAP or somesuch to find the IP address that gets assigned to the installer.

If you fail to gain access to the installer, someone will need to physically reboot the remote server (it will reboot into its original system).

2 members found this post helpful.

Have been trying out the suggestions on a virtualmachine - so I freshly installed Slackware 13.37 on my virtualbox, then followed the above steps to the book. Everything worked out great (seemingly) - I did everything when I was connected to the guest OS (13.37) via SSH on my host OS. After I rebooted however, I realized that network is not coming back up for some reason and then this is what I see:
Any ideas about what might have gone wrong? I do realize that probably, when I do this on my actual remote machine, it may not go through the same problem (or maybe it will?), but it's good to know what's the fix so I can be prepared for it when I do the actual thing...

Thanks!

That is so useful! I haven't used it yet though - have a couple of concerns. Like you state, password less root access to anybody on the network is probably not a good thing (because I am not on the local network and if i open root access, can lead to attacks). Is there a get around this, meaning I can make it have a password access or a key or something?

Secondly, why do you say the IP address might change? The machine I am talking about uses DHCP server to get its IP and it's fixed for my MAC add. In this case, can I expect the IP to remain unchanged?

That is now a very broken system :-(

/sbin/modprobe should be a symlink to /sbin/kmod, which was a new package added in 14.0

If you don't have /sbin/kmod, either you didn't run "slackpkg install-new" or something went wrong and you didn't see it.

If you do have /sbin/kmod but you don't have the /sbin/modprobe symlink, something went wrong with the kmod install script, which shouldn't happen.

The extensive notes you quoted from hotchili are "abnormal". I hesitate to call them wrong, but normally, people should do "slackpkg install-new" *before* "slackpkg upgrade-all". This may be what went wrong.

It would also be a very good idea to sort out your 14.0 kernel and run lilo and reboot when the upgrade to 14.0 is finished, before you try to upgrade to 14.1. Keep it as two separate upgrades. If things have gone bad at the 14.0 stage, upgrading a broken 14.0 system to 14.1 is probably going to make the problems worse.

1 members found this post helpful.

Make this simple if you are not going to upgrade version by version then do not use slackpkg. Why it is not made to do that. Second there is default parts of slackpkg that may cause issues.
if you want to skip versions use the kiss method Pat has laid out to you. and after you clean up you may want to re run the script kept here. http://carroll.cac.psu.edu/pub/linux....1/UPGRADE.TXT and look at the changes from http://carroll.cac.psu.edu/pub/linux....0/UPGRADE.TXT
those things will need to be done. write a script and KISS your way through it.