Of course, you can feel free to use this thread for any initial comments …
The roadmap is here: <https://en.opensuse.org/openSUSE:Roadmap>.*February 20th, 2020: Beta phase
*
[INDENT=2]April 16th, 2020: RC phase, package freeze (8 weeks after Beta)
May 3rd, 2020: translation deadline for packages
May 4th, 2020: final package submission deadline
May 4th, 2020: translation deadline for infrastructure
May 7th, 2020: Release (3 weeks after RC)
[/INDENT]
Kernel is version 5.3 – therefore no exFAT driver in the Kernel – ran it in a VirtualBox VM – couldn’t mount a SDXC card which was mounted OK on the Leap 15.1 host (Fuse exFAT is installed) – Leap 15.2 also needs the Fuse exFAT package to be installed …
I have doubts about that – it’s not a Bug, it’s a feature …
exFAT support comes with the Linux kernel version 5.4.
If we’re to have exFAT with a version 5.3 kernel then, someone will have to backport the version 5.4 kernel code – or whatever kernel version with the “better exFAT driver” …
Whether or not the effort needed to backport the exFAT driver to the version 5.3 kernel is worth it, or not, is a moot point …
The DVD image installation or upgrade does not appear to add the local media as a repository. This means that packages on the media have to be downloaded. On-line update was much slower than off-line followed by on-line, or manually adding the local media repository during upgrade configuration.
It was added here, but disabled. That has been the openSUSE install practice for some time (probably started with Leap 42.1).
In my earliest installs (with the Alpha release), I enabled after install before adding other software. And I later disabled again, because keeping it enabled would interfere with updating to newer releases.
With my latest installs for the Beta release, I did not enable. But I use a shared package cache on my NFS server. So I configured that for the newly installed systems. That greatly speeds up installing software, if you have more than one system. The first downloads the packages to the package cache, and subsequent installs get it from the cache.
The spread sheet says that with high priority the upgrading from 15.1 should be tested, iirc. I have 1-2 installs I could try this, what is the recommended path?
Change repo names to 15.2, init3 in the console and then zypper dup --allow vendor change?
I did that for my initial install and saw nothing to report about, but everybody else reporting to the spreadsheet so far apparently used “zypper dup”, so other entries may be appreciated…
I have an USB-stick with the 15.2 netinstaller. Inserted and booted the machine with Leap 15.1 x64 install. Chose the /dev/ with the install to update. Next I saw the old repos page
I went back, had a look a the page with custom repos (the other page, availabe only if online connection is enabled!), but didn’w change anything and this time 2523 packages were scheduled for upgrading, but with “Cannot solve conflicts”, as I had not enabled the old custom repos:
When I wanted to switch back to the page for editing the old custom repos (change name from 15.1 to 15.2 and toggle to “enabled”), the Back button is grayed out, no way back.
I think I will start over again when it is confirmed that the repos for 15.2 are online (KDEextra, etc, see above…)
I personally used the Packman repo and all went well, but I only use the Essentials. The others appear to be online already, but I couldn’t find the Lidvdcss yet (but this should not be a problem, that single library didn’t change in years…)
Note that I did this in a KVM virtual machine, where I already had Leap 15.1.
I disabled the “libdvdcss” repo. For all enabled repos (openSUSE and packman) I changed the “15.1” to “15.2” in both the URL and repo name. I did this with Yast Software Repositories.
I then logged out from the desktop, and used CTRL-ALT-F1 to get a virtual console. There, I ran:
telinit 3
to shutdown the GUI.
And then
screen -L
zypper --terse dup
The “screen -L” is mostly so that I would have a transcript of the update.
It all went smoothly. I then did
shutdown -r now
to reboot. And the system is up and running.
I did make one mistake. I use a local package cache on my NFS server. When I changed the repos, Yast SW Repositories emptied out the package cache. So I lost my Leap 15.1 cache. I should have disconnected from the package cache before changing the repos.
An additional comment. I already had configured “/etc/zypp/zypp.conf” to the equivalent of “–allow-vendor-change”. If I had not done that, there probably would have been a few prompts. There were a few packages moved from the packman repo to the opensuse repo. So if you try this, you might need “–allow-vendor-change” on the “zypper dup” command.
Checking after the update, I see:
# rpmconfigcheck
Searching for unresolved configuration files
Please check the following files (see /var/adm/rpmconfigcheck):
/etc/postfix/main.cf.rpmnew
/etc/postfix/master.cf.rpmnew
/etc/pulse/client.conf.d/50-system.conf.rpmsave
/etc/ssh/ssh_config.rpmnew
So I will need to check those. I will probably ignore the “postfix” and “pulse” changes. And the change for ssh_config should be minor (probably just comment lines).
I have this file on VM where I do not have (emulated) sound hardware and never touched anything sound related. Yet another proof that current configuration management in SUSE is insufficient - there is no connection between high level system tools making changes under the hood and package management that assumes if file is changed it was intentionally changed by user and user must be aware of it.
In this case – the “pulse” file, it is not so bad. The update did replace the original file, and then left an “rpmsave” file so that we could check whether anything needs adjusting. Since I had never touched the original configuration, it at least seemed safe to go with the new configuration.
The “postfix” case is far worse. Here, there clearly were changes to the original files, that are not in the “.rpmnew” replacement. But they are changes that I never made. Any changes were done by the initial install. So it seems to me that whatever configuration is done for the initial install ought to also be done to the “.rpmnew”. It ought to be that if I never touched the file, then moving in the new version is the correct step. But it sure looks as if that would be a bad step for “postfix”.
I have installed it on a spare p/c (not with a nvidia graphic card) a few weeks ago and have had no issues at all. All the packman multimedia rpm’s are available, already at such an early pre-release point - which is really impressive.
I did a net install on a new partition and it seems ok. The only problem I have is with Mythtv. It’s not important because I’m not really using it but it keeps going wrong. I’ve installed Myth many times now so it’s usually pretty slick but, obviously at this early stage it’s not a deal-breaker.
I did a quick check installing and firing up VBox 6.1.2 (Leap 15.2 host) and starting a couple of existing VMs I found hiccups in mouse capture/mouse integration and possibly also keyboard capture/integration.
Tried to update guest additions on the VMs to no avail.
Sure I have to check better and maybe it is too soon to report on that, but still an area worth testing IMHO.
