Rather than further clutter the Requests for -current thread, this thread is for Slackers who want to help test updating 14.2 to 15.0. This thread is not for those who choose to perform a fresh install.

This was a preliminary first run test only. Updating was successful.

On my 4-core system with SATA III spinners the full update and package removals took about one hour.

I used a familiar stanza of past releases:

Then removepkg old packages listed in UPGRADE.TXT.

Please notice I did not install any KDE packages.

The first observation is I use a custom partition layout and my system partition size of 20 GB no longer is sufficient. Even without KDE packages I have only about 2.3 GB free space. I will need to remedy that before testing further or testing KDE packages.

Second observation was launching Xfce. The wallpaper background changed to the default.

Third observation is fonts look rough in Xfce.

I haven't dug further. I did not further test the system, did not look at dot new files, did not test anything for breakage, and did not compile new SBo packages. The good news is updating 14.2 to 15.0 does succeed.

Please contribute and feel free to add suggestions.

Did you just accept all the changes or you're still running with 14.2 configs?

1 members found this post helpful.

14.2 configs. I did not dig further. My first pass was proof-of-concept that updating 14.2 to 15.0 is doable despite the many changes. I'll evaluate the *.new files in a subsequent test session.

I plan to write some kind of testing check list. So much has changed.

I am hoping others will test and participate in bugs and quirks found.

How to get the moderator to make this a sticky, even if only until 15 is officially released?

1 members found this post helpful.

Did you switch to single-user mode for the upgrade?

Not for this test.

Can you elaborate on this? I'm of the many partition school [/, /boot, /var, /usr, /usr/src, /usr/local]. Currently I use about 80% of a 14 GB /usr with full system + multiple SBo builds. (/ is 50% of 2 GB)

I'm guessing this will not be sufficient -- would like to start with about ~70%.

I long have gotten by with 20 GB system partitions. I also have not used KDE since the KDE3 days. Thus my partition size has always been adequate even after installing many SBo packages and MATE.

I have a test partition that is a near clone of my daily system partition. The partition is 20 GB. In my first test as described in my OP I did not install any KDE packages. I was left with an almost full partition. There is no way I could install the KDE packages. I want to test KDE because many people have shared that Plasma is a good desktop environment these days.

I knew increasing the partition size was needed because I found the same issue with my Current VM. In the VM I have the KDE packages installed but not MATE or any SBo packages. I had to increase the VM system partition from 20 GB to 30 GB.

Thus I'll need to resize my system and test partitions. I looked at that today. I am going to double the size to 40 GB. I have to do some shuffling because the affected disk is full, but nothing I haven't done before. Just nominally annoying and time consuming.

I hope that helps.

1 members found this post helpful.

I think in settings Manager / Fonts / Rendering
you have to disable and enable anti-aliasing once to have proper fonts.
and set hinting to slight, RGB. At least I use slight, and that's just right for my taste.

1 members found this post helpful.

I installed all the -current packages into a directory and then got the disk usage for that directory. Below is the output:

/usr is divided up to:

2 members found this post helpful.

So slap Xfce upside the head?

3 members found this post helpful.

This might be a little over the top but here mine considerations (I've ran -current up to the big re-compile and am on a clean installed 14.2 as of writing this):

Recommended root partition sizes (by silly me):

1. Basic office on Slackware: 40G /
2. Home Computer ("has all does all") 75 G /
3. Future Proofing Enthusiast PC (that's me) 120G /

Some 2.5 GB for swap (we long since buy (or download for that matter ) more RAM and use swap to only hibernate nowdays anyhow)

and the rest is for /home

Rationale:

a) We want some (and some more) leeway for building and possibly keeping build packages in permanent /tmp (if we want that at all)
b) There seems to be a motion in leaving tight and peaceful partitions behind in favor of more simple layout (have only /, swap and /home)
c) Ever more essential tools move to /usr/*bin and ever more systems boot from some sort of initial packed file system - the /bin concept seems to grow inherently ever more obsolete anyway
d) it seems that running parallel installs is competing with root-jailed and virtualized installs and it seems to be loosing the race (except in rare occasions when the main install borks - but that's what live thumb-drives are for)

TL;DR:

I - Get a live thumb-drive and keep it updated and handy (I promise you'll need it once in a while (make that two thumb-drives))
II - Fuze the space for system partitions and install a stable Slackware there
III - Get going on virtual/containerized options to track -current - some options AFAIK even offer access to video acceleration nowdays

Yeah kinda :P

But that's probably a standard issue with an upgrade of Desktop Managers, the little inconsistencies here and there.

My root partition in on a SSD, and 40% of the partition is used.
During the massive update, I also run 'fstrim' in the middle of the process, and in the end.
I don't know if it is really necessary, but it does not hurt.

It isn't really necessary during the install. NAND memory is different than a mechanical platter in harddrives. The memory needs to be reset before it can be written (compared to magnetic storage like regular harddrives which can just overwrite the previous data without resetting). When an item is deleted, it is simply marked as deleted by the controller, but the data remains on the harddrive. Trimming an SSD will reset those blocks so they're ready to be rewritten. You can either trim it manually using fstrim or have the system do it automatically by setting the discard option in your fstab (or mount options if you're mounting manually). There are still some sites that recommend against using the discard option, but I think they're outdated and were tied to issues when discard was first introduced. I've kept discard in my fstab for years without any known issues.

If you don't trim the drive, then if it needs to be written to, the system needs to then reset the block manually before it can write data to it (although, the controller will typically try and find open spots that are already reset to maximize speed), which will cause a slowdown in data operations. This is why it's ideal to trim the drive periodically so it is ready for data when the system wants to write it.

When you're in the middle of data intensive operations (like upgrading the system), running fstrim will reset all blocks that were marked for deletion, but all those blocks might not need to be reset to finish the data operations, which could increase your overall time.

It definitely didn't cause any problems, but it likely added a small amount of time to the total duration of your upgrade.

3 members found this post helpful.