The roadmap is here: <https://en.opensuse.org/openSUSE:Roadmap>.*Development schedule:
*
[INDENT=2]*February 2019: Beta phase
April 16th: RC phase, package freeze
May 12th: translation deadline for packages
May 13th: final package submission deadline
May 20th: translation deadline for infrastructure
May: Release
*[/INDENT]
Feel free to use this thread for any initial comments.
Hi, installed the Gnome version on an ASUS “Optimus” laptop using the net-install media and reusing existing partitions without a glitch.
Some wmi keys not working have been promptly fixed by the fantastic kernel maintainers at SUSE, fix not yet available in the current kernel as of today.
RF_KILL not working promptly fixed, the fix has trickled down also to Leap 15.0 yesterday with a patch to xkeyboard-config.
“Hibernate” does not work, the Nvidia GPU with Nouveau does not wake up from sleep; not important to me, will join for testing if somebody else files a bug report.
Annoying delay of 1m 30s (a timeout?) at shutdown or reboot, often but not always, no clues in journal or other logs I have seen; mrmazda suggests a systemd quirk, waiting for a not running process to shutdown.
Everything else in my daily use case seems OK so far, a pretty good result at this stage.
I’ve been following 15.1 since early alpha stage, mostly in a VM. But I do have it on one physical machine. I’ll add a second toward the end of March. I’m using “zypper dup” to keep them up to date. And occasionally, I do a full reinstall (in the VM) to test the installer.
Bug 1127584 - seahorse ssh-agent emulation is failing
This one I reported very recently. I’m not sure how long it has been there, since I only recently did some Gnome testing (I mostly use KDE). Since this works correctly in Leap 15.0 and in Tumbleweed, I’m expecting that it will be fixed soon enough.
Otherwise – mostly a good experience with 15.1 thus far.
Did a default Network installation (CD-ROM) into a UEFI VirtualBox – thought that, the installation procedure wanted to use Wicked for the network management but, it used Network Manager for the actual installation – will check again at the next re-install …
Kernel is still the Leap 15.0 version 4.12 – this is, IMHO, bad news for the folks who’ve bought AMD Ryzen CPUs …
Somehow, I have the feeling that, a Bug Report against the Release Notes is needed to help those who’ve been caught out by this issue …
I’m pretty sure that NetworkManager is the default for new installs.
Yes, the NET installer gathers information for “wicked” to use during the install itself.
I have only one system with a recent install that started out with “wicked”. And that because I did a minimal install (gave me only Icewm), and NetworkManager was not even installed.
Kernel is still the Leap 15.0 version 4.12 – this is, IMHO, bad news for the folks who’ve bought AMD Ryzen CPUs …
Somehow, I have the feeling that, a Bug Report against the Release Notes is needed to help those who’ve been caught out by this issue …
It is my expectation, perhaps mistaken, that it is intended to keep this kernel throughout the 15.x series. Presumably the “drm” kernel module is suppose to backport support for newer processors such as Ryzen. And, of course, it is possible to use the latest kernel from the kernels repo.
+1
The 4.12 kernel in Leap 15.1 will not be the “plain” 4.12 kernel; for instance the fix to a bug I reported brought the asus_wmi module basically in line with the 5.0 kernel ( see https://bugzilla.opensuse.org/show_bug.cgi?id=1126285#c12 ).
I don’t know how that will fare for Ryzen owners though, maybe testing the 15.1 beta on Ryzen processors and filing a few bug reports might change something…
I had this exact problem with Leap 42.3 and its kernel 4.4 and Ryzen 1st gen. CPU was supported from 4.10 up, sound chip from 4.9 up, wifi full speed from 4.11 up. I was forced to compile kernels myself, as it turned out that Factory kernels were unreliable and fast changing. The situation was complicated by the presence of a NVidia card. Now I am hardware compatible with 4.12, but I think 2nd & 3d generations Ryzen will experience the same I had. Somehow the policy of providing old ‘enterprise’ kernels for desktop users will alienate many of the desktop users from the Leap distro flavor, and at the same time they will not switch to rolling Tumbleweed as the company false expectations are - simply because users mostly prefer the stable release version. Expect leak out of true desktop users in migration to other distros.
What I have tried recently in relation with Leap 15.1: Migration from Tumbleweed install to Leap 15.1 - I’ve experienced unrecoverable failure and I think the mission is maybe impossible, as the difference gap between Tumbleweed and Leap 15.1 is too wide now.
Looking at a system installed from Build416.2 (and updated since then).
I see that “.cache” is empty. And “.gnupg” contains what is probably a skeleton keyring with no keys (it is too small to have keys).
I think “.gnupg” is created when the “gpg” command is run. And probably something is creating “.cache” as needed. Both of those directories have time stamps around 30 minutes after the install began. I date the install with the timestamp on “/lost+found”.
It is likely that “.cache” and “.gnupg” were created by commands run toward the end of the install (run in “chroot” mode).
In your case, they may have been updated by software run after the install (such as Yast).
Quite a bunch of patches landed in build 425.1, many in the kernel, so at the moment most hiccups I experienced seem gone.
Not noticed any annoying delay in the couple of reboots after the upgrade, but maybe it’s too soon to speak…
A few questions: which version of plasma would it be intended to apply firstly 5.12.7 or 5.12.8? Will these be compiled upon the latest Qt LTS version (5.9.7, I think)?
I did a 15.0/TDE to 15.1/TDE upgrade on 14 year old Intel Lakeport 945G, which is not supported by the modesetting DDX. Only icewm/icewm-lite/icewm-config-upstream were installed, so trying an IceWM session produced only a mouse pointer on black background. Installing icewm-default fixed it. Both IceWM and TDE sessions from startx are ignoring xrandr in /etc/X11/xinit/xinitrc.d/05-setup, which if I boot instead of multi-user to graphical to start them from greeter, run as expected before either session starts.
I just did a zypper dup on ASUS UEFI multiboot host ab250. Since dup completed, attempting to boot anything fails. Instead the screen goes directly and instantly into BIOS setup, where none of the efibootmgr entries are present, only generic items such as UEFI CDROM, UEFI HDD, UEFI USB, LEGACY HDD, etc. The boot override item is not allowing access.
It isn’t clear what you did there. Were you going from an earlier version of Leap 15.1 to the latest? Or were you going from Leap 15.0 to Leap 15.1? Or something else?
1-TW is #1 in custom.cfg, whose entries are before/above those from grub.cfg (/etc/grub.d/06-yada IIRC) on each installation.
2-Installed are TW, 15.0, 15.1, Buster, Bionic, Mint 19. Last boot before today’s 15.1 boot was yesterday’s dup of TW.
3-Without a CD/DVD, no boot, just BIOS setup.
4-It booted a TW20180612(?) netinst CD.
5-Booting CD both NVME and SDA were found with expected content by fdisk.
6-Next I booted to TW20190310 netinst in “Rescue” mode, with NVME physically removed. It ignored my cmdline option to make text big enough to see. efibootmgr listed only 0001, the DVD drive. fdisk -l returned nothing. gdisk reported damaged GPT.
It looks as if the last grub2 update was at around March 08 (going by dates of boot files here).
I have not experienced any problems with booting. But my UEFI test system is a virtual machine, so perhaps not a perfect indicator. My bare metal install is on an older system without UEFI.
The updates that I have seen to grub2 have pretty much reflected similar updates to Tumbleweed. And those updates have not caused any problems for me on UEFI boxes (except for bug 1127544 which has not hit 15.1 and was not due to a grub2 update).
That 15.1 installation should have had Grub locked, as it is never supposed to be used, especially for booting anything. The EFI partition on the SSD doesn’t get mounted except when TW is booted. Until and unless the partitioning can be recovered, there won’t be any way to figure out what happened. The pre-recovery script is currently running, but might not be needed. I have the partition structure logged, so I could recreate from scratch if necessary.
The disk’s MBR lacks 55 AA signature, has a lot of content that looks nothing like the mostly empty content of a GPT protective MBR for a UEFI system. I am hopeful of successful recovery to get a log at the logs and report a bug if necessary.