Hello,
I am curious if I can do a direct upgrade from 13.2 to 42.2 without first upgrading to 42.1?
I plan to follow the same procedure 13.2->42.1, but with 42.2.
Is it possible?
Thanks.
you can but it’s not recommended, personally I’d jump the 42.1 but that’s me, if you jump a release don’t forget to backup your data and be prepared for unseen consonances, the way I understand it is zypper dup replaces installed packages with ones from a new repo, the more versions you jump the bigger the chance of a missing or a new package and borking your system but seeing how leap will be leap from 42.1 up to 42.4 there shouldn’t be any major differences
It is being tested in openQA though, so it should work. 
Of course your success (or failure) may depend on what additional packages you installed, and from where, as always with upgrades.
OTOH, 13.2 is in some parts (that come from SLE in Leap) actually newer than 42.1, so one may argue that the jump from 42.1 is actually bigger than from 13.2…
I am still using 13.2 myself (for several reasons, mainly due to lack of time to upgrade though), and will definitely upgrade to 42.2 directly with zypper dup. I cannot report experience with that yet though.
A backup is definitely a good idea anyway, not only in this case.
I grew impatient and have done a direct upgrade 13.2 -> 42.2(beta 3) on one of my VirtualBoxes(5.0.26) 13.2 guests.
The upgrade was 99% flawless!
What went 1% wrong is the failure to start the Xorg as a user, and works currently only for the root.
Xorg 1.16.1->1.18.3 upgrade issue?
78.336] (WW) xf86OpenConsole: VT_ACTIVATE failed: Operation not permitted
78.336] (EE)
Fatal server error:
78.337] (EE) xf86OpenConsole: Switching VT failed
On the other hand I was surprised to register downgrades, despite the 2 year difference of 42.2 compared to 13.2 ??
1401 packages to upgrade, 181 to downgrade, 332 new, 106 to remove, 1 to change vendor, 1 to change arch.
Overall download size: 1.13 GiB. Already cached: 0 B After the operation, additional 362.7 MiB will be used.
13.2 was entirely “openSUSE code base”, where 42.1 was based on SLE12 + SP1. SLE tends to be more conservative than openSUSE. To make an honest comparison, it would be interesting to see how many of these downgrades are actually about minor versions.
I haven’t checked 42.2, but Tumbleweed’s kernel had a config change that makes VirtualBox’s UMS driver fail.
Adding “iomem=relaxed” to the kernel boot options should fix it.
There is a new KMS vboxvideo driver that should work out of the box, but that one requires VirtualBox 5.1.x on the host.
So upgrading your VirtualBox should fix it too…
Actually the problem is not in the VirtualBox, as the Leap 42.2 guest runs perfectly as a root.
The problem is within the lightdm, both 1.19.0 & 1.19.5 don’t work for me in this VirtualBox guest scenario - when I login as a normal user the display-manager.service fails, pointing finger at the lightdm that crashes.
I use Xfce and as a workaround I’ve have substituted the ‘lightdm’ with the good old ‘xdm’ at the /etc/sysconfig/displaymanager, and now my VBox Leep 42.2 is 100% functional 
No upgrade of VirtualBox is needed.
The proof of concept is complete for the 13.2->42.2 upgrade.
I will wait though with other upgrades until the final release of 42.2.
Ok, fine that you found the reason.
And I think there’s already a bug report about that, may be even fixed in RC1 IIRC.
I just wanted to mention that other problem as I experienced it shortly before with a Tumbleweed guest, (and indeed upgrading virtualbox to 5.1.6 today made the KMS driver work).
As you are using VirtualBox 5.0, it may have been the case with 42.2 too.
But as I said, I’m not sure whether that kernel config change is in Leap as well, apparently not then.
PS: maybe it was 1002061 – LightDM crash…
wolfi323 wrote:
>
> I_A;2795503 Wrote:
>> you can but it’s not recommended
> It is being tested in openQA though, so it should work. 
>
> Of course your success (or failure) may depend on what additional
> packages you installed, and from where, as always with upgrades.
>
> OTOH, 13.2 is in some parts (that come from SLE in Leap) actually newer
> than 42.1, so one may argue that the jump from 42.1 is actually bigger
> than from 13.2…
> I am still using 13.2 myself (for several reasons, mainly due to lack of
> time to upgrade though), and will definitely upgrade to 42.2 directly
> with zypper dup. I cannot report experience with that yet though.
>
> A backup is definitely a good idea anyway, not only in this case.
>
After the 42.2 beta 3 came out, I had some time to play. I had 13.1, 13.2,
and 42.1 on one box and a new drive to play with. I have been hanging on to
the 13.1 (Evergreen) and updating waiting for Leap to finally fill out to
support everything I was using. Just for reference, that machine is HP
Envoy core I7, 16 GB memory, Nvidia GT630 video, and (now) 2 1TB drives so I
hit pretty much all the hardware-related problem areas.
In summary, all three versions updated directly to 42.2 using the DVD image
with the existing /home data (copies). KDE PIM data correctly updated from
all three versions. I started to run one test of 13.1 -> 13.2 -> 42.1 ->
42.2 but gave up as the step to 42.1 became a quagmire so I can’t speak to
any advantage of the 1 version at a time process but I was certainly pleased
with the ease of the updates from 13.x -> 42.2. Even the Wine and
Virtualbox stuff migrated just fine. Updating to 42.1 from 13.x on this
machine was an all day job so the ease of the updates to 42.2 was a pleasant
surprise indeed. I didn’t find any orphan files other than ones belonging
to what requires outside repos so even the cleanup seems to actually work.
That’s just one machine but on hardware that has given me the most problems
in the past so I’d say backup-and-try-it is a reasonable approach for 42.2.