[SOLVED] Slackware-Current upgrade procedure that I use safe enough?

deNiro · 02-06-2021, 05:17 AM

Two days ago I finally moved my main PC to Slackware-current. Honestly, it runs better then ever.

Anyway, I was a bit worried about the update procedure, which was always the main reason to stay on stable. And yesterday there was a batch of updates, including kernel, so the right moment to test it. It went quick and painless. no problems at all.

But since I never really ran Current, except in a vm to quickly check it out, I wanted to be sure if I left some important thing out of the update procedure that could break my system.

Perhaps a bit too extensive, and I am using multilib, nvidia970gtx and generic kernel, but here is what I use, from my notes:

Code:

###### Old! SW-current upgrade procedure ###### ## 1. check slackware-current changelog ## 2. (ONLY with kernel upgrade or possible systembreaking stuff) drop to init:id:3, which I start at anyway ## 3. update packages cache slackpkg update ## 4. check if there is a update to slackpkg slackpkg upgrade slackpkg ## 5. make sure new packages from blacklist ## are not installed. So,blacklist again ## in my case kde/plasma and emacs slackpkg blacklist kde emacs ## 6. (ONLY with kernel upgrade) remove nvidia driver sh NVIDIA-Linux-x86_64-xxx.run --uninstall (answer no to restoring original xorg config) ## 7. install new packages slackpkg install-new ## 8. upgrade all packages slackpkg upgrade-all ## 9. (ONLY) with kernel upgrade) ## generate mkinitrd and update bootloader go to /boot directory and generate initrd with: mkinitrd -c -k 5.10.xx -m ext4 (my root is ext4) and then update bootloader: lilo -v ## 10. (ONLY with kernelupgrade) ## install the nvidia driver again first, reboot, and then sh NVIDIA-Linux-x86_64-xxx.run (answer NO to configure xorg config, mine is still there) reboot again ## 11. Check if multilib is still up-to-date and resolve if needed

btw, I have these in my blacklist [0-9]+_SBo , [0-9]+alien , [0-9]+compat32, [0-9]+ponce and kde/plasmastuff and emacs

Is this 99.9% safe? or did I leave something important out?

##############################################################
##############################################################

EDIT:
So, after some remarks, with the corrections incorporated (updated 14 febr 2021, since slackpkg blacklisting has changed)

The notes I now use to upgrade: Slackware-current, with multilib, nvidia 970gtx , and kde/plasma and emacs disabled. And using generic kernel instead of huge.

/etc/slackpkg/blacklist contains:
# all kernel packages, unless I planned kernel upgrade
# This one will blacklist all SBo packages:
[0-9]+_SBo
sbopkg
# This one will blacklist all alienbob packages:
[0-9]+alien
# This one will blacklist all Multilib packages:
[0-9]+compat32
# This one will blacklist all current-ponce packages:
[0-9]+ponce
# This one will block kde/plasma and emacs
kde/
e/

Code:

###### Slackware-current upgrade procedure ######

## 1. check slackware-current changelog

## 2. update packages cache
slackpkg update

## 3. install new packages
slackpkg install-new

## 4. upgrade all packages
slackpkg upgrade-all

## 5. (ONLY with kernel upgrade)
## generate mkinitrd and update bootloader
go to /boot directory and generate initrd with:
mkinitrd -c -k 5.10.xx -m ext4 (my root is ext4)

and then update bootloader:
lilo -v

## 6. (ONLY with kernelupgrade NVIDIA driver install)
!!in case you are running your own or multiple kernels!!
!!or if it is the same nvidia driver version, just compile kernel module!!
for example:
sh NVIDIA-Linux-x86_64-460.39.run -s -K -k 5.4.97

OR
When using a new nvidia driver version
just reboot after lilo -v and
sh NVIDIA-Linux-x86_64-460.39.run

## 7. Check if multilib is still up-to-date and resolve if needed

## 8. Clean system
## generates a list of all packages that are obsolete and can be safely removed
## non-official packages will be listed here unless blacklisted - check changelog
slackpkg clean-system

chrisretusn · 02-06-2021, 06:27 AM

Quote:

Originally Posted by deNiro

Two days ago I finally moved my main PC to Slackware-current. Honestly, it runs better then ever.

Anyway, I was a bit worried about the update procedure, which was always the main reason to stay on stable. And yesterday there was a batch of updates, including kernel, so the right moment to test it. It went quick and painless. no problems at all.

Based on this I will assume you have already migrated to slackware-current and is working well as far as you can tell.

Quote:

But since I never really ran Current, except in a vm to quickly check it out, I wanted to be sure if I left some important thing out of the update procedure that could break my system.

Perhaps a bit too extensive, and I am using multilib, nvidia970gtx and generic kernel...
btw, I have these in my blacklist [0-9]+_SBo , [0-9]+alien , [0-9]+compat32, [0-9]+ponce and kde/plasmastuff and emacs

The upgrade procedure with slackpkg would be exaclty the same as with slackware-14.2

Code:

## 1. check slackware-current changelog

Good. Always read ChangeLog.txt

Code:

## 2. (ONLY with kernel upgrade or possible systembreaking stuff)
      drop to init:id:3, which I start at anyway

Good plan.

Code:

## 3. update packages cache
slackpkg update

Good.

Code:

## 4. check if there is a update to slackpkg
slackpkg upgrade slackpkg

Not necessary. Slackpkg checks for this, if there is an update to slackpkg, it will be updated, then then the process will quit and you will have to start over with:
"slackpkg update" and answer 'y' to the "Do you really want to download all other files (y/N)? to rebuild the database.

Code:

## 5. make sure new packages from blacklist
##    are not installed. So,blacklist again
##    in my case kde/plasma and emacs
slackpkg blacklist kde emacs

Since you already have kde and emacs in your blacklist this is not needed.
Note: You don't mention that the kernel is blacklisted. I would recommend this since you are using the generic kernel that you blacklist the kernel packages. The default kernel after a kernel upgrade is kernel-huge. This may not be an issue if your lilo.conf points the generic kernel.
FYI the correct entries in blacklist for kde and emacs (e series) would be:

Code:

kde/
e/

Code:

## 6. (ONLY with kernel upgrade) remove nvidia driver
sh NVIDIA-Linux-x86_64-xxx.run --uninstall 
(answer no to restoring original xorg config)

You don't have to do this with a kernel upgrade, you can though. Just upgrade the kernel, then run the NVIDIA driver install again.
You can run it before rebooting using "bash NVIDIA-Linux-x86_64-xxx.run -k 5.10.xx

Code:

## 7. install new packages
slackpkg install-new

Good.

Code:

## 8. upgrade all packages 
slackpkg upgrade-all

Good

Code:

## 9. (ONLY) with kernel upgrade)
##    generate mkinitrd and update bootloader
go to /boot directory and generate initrd with:

mkinitrd -c -k 5.10.xx -m ext4   (my root is ext4)
and then update bootloader:
lilo -v

Looks good to me.

Code:

## 10. (ONLY with kernelupgrade)
##     install the nvidia driver again
first, reboot, and then
sh NVIDIA-Linux-x86_64-xxx.run
(answer NO to configure xorg config, mine is still there)
reboot again

No need to reboot twice. You can reboot after lilo if you reinstalled the NVIDIA driver as I comments in ##6.

Code:

## 11. Check if multilib is still up-to-date and resolve if needed

Good.

Since it looks like you have the correct things blacklisted, it is also a good idea to run "slackpkg clean-system" if there are packages "Removed." in ChangeLog.txt

One thing to note with using the NVIDIA driver, it is a good idea to reinstall the driver after any update to mesa or xorg-server* because both upgrades will replace the NVIDIA libraries.

Quote:

Is this 99.9% safe? or did I leave something important out?

All in all the procedure looks good to me and close to how I do it.

deNiro · 02-06-2021, 07:17 AM

@chrisretusn

Thanks for your remarks. Very useful for me. So I can adapt my notes and Blacklist.
btw, the reboot before the nvidia driver install was indeed not meant as an extra reboot, but belonged after "lilo -v". I do blacklist the kernel stuff normally, except for when I have time, and I want to do the kernel upgrade. Then I normally just open a tmux session, with the notes at the right, and console at the left, so I don't do leave out anything important.

I think I'll just edit my topic start post to adjust it based in the remarks, for anyone else that searched for this info later. Thanks again!

deNiro · 02-06-2021, 08:15 AM

Quote:

Originally Posted by chrisretusn

<snip>
FYI the correct entries in blacklist for kde and emacs (e series) would be:

Code:

kde/
e/

Maybe I misunderstood, but these entries do nothing in the blacklist config file.

I normally do:
# slackpkg blacklist kde e

Which will result in a huge list in my /etc/slackpkg/blacklist with the packages from kde/plasma and emacs

if I only have

Code:

kde/
e/

in my blacklist, and I do "slackpkg install-new", it wants to install all those packages from kde/plasma and emacs.

So, currently I stick to doing a "slackpkg blacklist kde e",after a "slackpkg update" to ensure I don't get any packages of those sections.

ctrlaltca · 02-06-2021, 08:24 AM

Quote:

Originally Posted by deNiro

## 9. (ONLY) with kernel upgrade)
## generate mkinitrd and update bootloader
go to /boot directory and generate initrd with:

mkinitrd -c -k 5.10.xx -m ext4 (my root is ext4)

I would run this instead to ensure every needed piece is included in the initrd:

Code:

/usr/share/mkinitrd/mkinitrd_command_generator.sh -k 5.10.xx

Even if you don't need support for any special feature (like raid, lvm, luks, etc..), you may still want to have eg. usb keyboard support available at boot, and a few kernel modules needs to be included in the initrd for that.

garpu · 02-06-2021, 08:32 AM

With current I also give here a perusal before updating, because sometimes (rarely, in my experience) a package will break something, and I'd like to be prepared for it.

deNiro · 02-06-2021, 10:17 AM

@ctrlaltca
I used the instructions for the initrd from the README.initrd at the current mirrors. But your suggestion is probably to ensure the right script is being used. Thanks for that.

@garpu
English is not my native language and I had to look up "perusal". :P You probably mean look at the changelog, right?

garpu · 02-06-2021, 08:06 PM

Quote:

Originally Posted by deNiro

@ctrlaltca
I used the instructions for the initrd from the README.initrd at the current mirrors. But your suggestion is probably to ensure the right script is being used. Thanks for that.

@garpu
English is not my native language and I had to look up "perusal". :P You probably mean look at the changelog, right?

Sorry! I look at the posts here, just in case something went wrong with a package, as happens from time to time. (Current is for testing, after all, and shouldn't be construed as stable, although every problem I've had has had a quick fix or was able to roll back.) Like when the alsa update broke pulse...not a huge problem, since you can roll back to alsa or use jack. Or there was a bugged version of cairo that broke a few other things.

With all the Europeans we've got hanging around on this forum, odds are good that they've already found the problem and fixed it before I've had my first cup of coffee for the day.

http://slackware.uk/cumulative/slackware64-current/ That's a good thing to bookmark, since they host older packages of things for current.

deNiro · 02-06-2021, 09:14 PM

Quote:

Originally Posted by garpu

Sorry! I look at the posts here, just in case something went wrong with a package, as happens from time to time. (Current is for testing, after all, and shouldn't be construed as stable, although every problem I've had has had a quick fix or was able to roll back.) Like when the alsa update broke pulse...not a huge problem, since you can roll back to alsa or use jack. Or there was a bugged version of cairo that broke a few other things.

With all the Europeans we've got hanging around on this forum, odds are good that they've already found the problem and fixed it before I've had my first cup of coffee for the day.

http://slackware.uk/cumulative/slackware64-current/ That's a good thing to bookmark, since they host older packages of things for current.

Ah yeah i got it now. tx, that last link is very handy.

andrew.46 · 02-06-2021, 10:43 PM

I have a few extra suggestions:

Keep a backup kernel. I compile a known, safe kernel and keep this as a backup for any misadventures with newer kernels. In my case it is set as the default kernel.
Keep an emergency USB disk. In my case this is a USB disk with Slackware Live on it, useful if the system becomes unbootable for any reason.
Have a solid backup plan. I have a routine of making a daily backup of $HOME, /etc and a few other bits and pieces after every days work to an external USB HDD.
Sometimes hold back. There a few upgrades to -current that mean I will delay updating for a few days or so with a close monitoring of these forums for flagged problems. Such as: upgrade to a new version xx.0 kernel, a major xorg update, glibc update etc.

I have become a little more careful with -current updates after I bricked my system with a fine combination of haste and ignorance

.

chrisretusn · 02-07-2021, 03:00 AM

Quote:

Originally Posted by deNiro

@chrisretusn

Thanks for your remarks. Very useful for me. So I can adapt my notes and Blacklist.
btw, the reboot before the nvidia driver install was indeed not meant as an extra reboot, but belonged after "lilo -v". I do blacklist the kernel stuff normally, except for when I have time, and I want to do the kernel upgrade. Then I normally just open a tmux session, with the notes at the right, and console at the left, so I don't do leave out anything important.

I think I'll just edit my topic start post to adjust it based in the remarks, for anyone else that searched for this info later. Thanks again!

I need to make a correction to what I said about the blacklist above.

Quote:

Originally Posted by chrisretusn

FYI the correct entries in blacklist for kde and emacs (e series) would be:

Code:

kde/
e/

As you pointed out in your next post:

Quote:

Originally Posted by deNiro

Maybe I misunderstood, but these entries do nothing in the blacklist config file.

Yes, that style of entry does not work in slackpkg by it self. I sometime forget that I am using slackpkg with slackpkg+. That will work with slackpg w/slackpkg+ but not slackpkg only.

deNiro · 02-07-2021, 05:35 AM

Quote:

Originally Posted by andrew.46

I have a few extra suggestions:

Keep a backup kernel. I compile a known, safe kernel and keep this as a backup for any misadventures with newer kernels. In my case it is set as the default kernel.
Keep an emergency USB disk. In my case this is a USB disk with Slackware Live on it, useful if the system becomes unbootable for any reason.
Have a solid backup plan. I have a routine of making a daily backup of $HOME, /etc and a few other bits and pieces after every days work to an external USB HDD.
Sometimes hold back. There a few upgrades to -current that mean I will delay updating for a few days or so with a close monitoring of these forums for flagged problems. Such as: upgrade to a new version xx.0 kernel, a major xorg update, glibc update etc.

I have become a little more careful with -current updates after I bricked my system with a fine combination of haste and ignorance

.

good list. I have an usb stick with puppy linux, and my home data is synced to that, and also to a laptop running salix 14.2. Delaying a full upgrade by syncing the current tree locally weekly, might be a good option to avoid trouble.

@chrisretusn
no problem. I had to test the complete list anyway, since I want to automate this whole procedure. I might have a look at slackpkg+ anyway.