[SOLVED] Upgrading Slackware 13.37 to 14.1 over SSH

bassmadrigal · 08-07-2015, 08:24 AM

Quote:

Originally Posted by Drakeo

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.

Code:

    #!/bin/sh
    for dir in a ap d e f k kde l n t tcl x xap xfce y ; do
      ( cd $dir ; upgradepkg --install-new *.t?z )
    done

Is there a benefit in doing a for loop versus just using wildcards for the folders? (Genuine question, I'm trying to expand my scripting knowledge)

Code:

upgradepkg --install-new */*.t?z

mralk3 · 08-07-2015, 08:41 AM

Quote:

Originally Posted by bassmadrigal

Is there a benefit in doing a for loop versus just using wildcards for the folders? (Genuine question, I'm trying to expand my scripting knowledge)

Code:

upgradepkg --install-new */*.t?z

It allows you to select only the specific folders you wish to install. As an example, when I do my upgrades, I skip KDE, KDEI.

55020 · 08-07-2015, 09:04 AM

Quote:

Originally Posted by bassmadrigal

Is there a benefit in doing a for loop versus just using wildcards for the folders?

There's one corner case: if there are lots of files, a wildcard can cause the shell's maximum allowable command line length to be exceeded (2097152 on slackware64-current, e.g. ~20,000 100-byte pathnames -- say, ten times more than all Slackware's packages) so a divide and conquer approach is sometimes necessary.

Going back to Drakeo's suggestion, there are many advantages of using slackpkg, including (but not limited to) checking md5sums and signatures, and doing glibc first. But for many years upgradepkg was all we had, and it's still good enough to form the basis of Pat's documented procedure in UPGRADE.TXT -- just make sure that you follow Pat's *entire* procedure from step 0 to step 9.

bassmadrigal · 08-07-2015, 10:11 AM

Thanks to both of you for the info!

saulgoode · 08-07-2015, 01:15 PM

Quote:

Originally Posted by max_arbit

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?

My script modifies the /etc/shadow file of the installer's initrd image to set the password. This appears in the following line:

Code:

sed -i 's?^root:.*?root:joFWnPF2bJhPc:0:0:::::?g' etc/shadow

The hash value in the above is for an empty password. You can supply a different hash value for a different password. For example, the following specifies a hash for a password of "123456":

Code:

sed -i 's?^root:.*?root:EuRG8Jp8OHb/.:0:0:::::?g' etc/shadow

I do not know of a simple way to generate the hash for a particular password; Slackware's installer is based on Busybox and password encryption for Busybox is different than that of Slackware proper (I believe Busybox uses DES and Slackware uses MD5, but I am not certain).

In order to create the hash for "123456" above, I booted into Slackware's installer (on my local desktop machine), changed root's password, and then copied the hash from /etc/shadow into the sed line of my make-headless-installer.sh script.

Quote:

Originally Posted by max_arbit

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?

I expect you wouldn't have any problems. Unfortunately for me, my network uses an AT&T router (running Microsoft software) and doesn't seem to take MAC addresses into account when assigning IPs. I often have to use nmap to identify the remote server after it boots into the installer.

max_arbit · 08-13-2015, 06:09 AM

Quote:

Originally Posted by 55020

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.
...
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.

That observation was spot on. @hotchili did mention that the instructions were from memory, so it was likely that some step was missed and this was it! I corrected that, and re-did the testing successfully and then did the actual upgrade of my remote system too - everything went perfectly!

Thanks everybody for their useful comments, tips and suggestions - very helpful indeed!