I’ve moved. Also, firstname.lastname@example.org is a valid XMPP handle.
The script operates under a few assumptions (yes I know, assume makes an ass out of you and me), but what can you do, except calling them prerequisites:
- Your system has all the latest updates applied according to your current repository setup (run “zypper patch; zypper dup” until there is nothing left to install)
- All enabled repositories have priorities set that make it crystal clear which of them are preferred over which in case a package appears in more than one repo
- All enabled repositories also exist for the target version, and use a repository URL that has that version number in it, and where the version number is the only difference between versions (this should usually be true for repositories from OBS and/or packman, buy YMMV)
If all this is true, running the script will create a backup of your current repository structure under /etc/zypp/repos.d_(current_version), and a repo setup for the target version under /etc/zypp/repos.d_(target_version), and then link the new structure to /etc/zypp/repos.d, and after that it will clean zyppers cache, refresh all repositories, and tell you the commands to execute to actually run the upgrade.
You might want to do those commands inside a screen session. You have been warned.
This script is provided with no warranty at all. Use it at your own risk. If you break things you get to keep the pieces.
If by any chance your root filesystem is on either LVM or btrfs, do a snapshot before you start upgrading your system.
Download the script here: leapup.tar.xz
So far I have used this script on two desktop systems which each use 20++ different repositories from OBS and packman, and no problems (aside from a few glitches in 42.3 that are connected to the nvidia drivers, but not to this upgrade process).
Update: in the last 4 days I updated five different machines using my script: my desktop computer which runs with 23 different repositories from OBS, my laptop and my work laptop which both run with 25 repos, my cloud host which runs with 10 repositories and my internal server/firewall which also runs with 10 repositories… no problems so far.
…or is it maybe being broken by people who think it is broken?
I’m pretty sure a lot of people here in Germany have heard the common complaint about end user internet connections being slow in the afternoon and evening because “everybody is watching netflix now” and similar stuff.
I was voicing the same complaint, over and over. My 400MBit cable link at home would drop down to under 80MBit in the evenings, and in downspikes go as low as TEN megabit/second. So I started measuring regularly with speedtest-cli which measures against the closest speedtest..net server, and the graphs in munin were pretty awful. Every day at around noon the performance would start to drop, and go down to around 50mbit by 11pm, and then after midnight would normalize again.
but, here’s the thought: What if it is not actually my internet connection?
What if it’s because everybody thinks their internet connection is bad, and starts hitting the speedtest.net servers so hard that they start to slow down?
… So I switched to measuring against a speedtest.net mini server that I’m hosting myself, and no-one else uses… and guess what. My internet performance still drops in the afternoon and evening, but nowhere as dramatic as before.
Makes you think about self-fulfilling prophecies, or maybe internet speed is related to Schrödingers Cat.
Edit: Here are two bandwidth graphs from my connection. The first one’s from when I was measuring against the official speedtest.net servers:
The second one was created the same way, but instead of using a random speedtest.net server for every data point I have been measuring against my own speedtest mini server on my cloud host:
I just hope that that new test site run by the Bundesnetzagentur has enough power to handle the load without drooping.
this time I went directly from 13.2 to Leap 42.2, skipping the intermediate step of Leap 42.1…. and no problems. I like that.
For your convenience here is the link to how I do this.
Oops I Did It Again…
Live Upgrade, with my tried and trusted method. By now that method is so polished that I had no issue whatsoever, so I did all three computers at the same time. I’m just glad to have a decent internet connection… I think the total downloads added up to somewhere near 15 gigabyte.
I upgraded my laptop to Leap 42.1 the other day, using the good old method that I’ve been talking about a few times. Worked without major issues, I just had to manually fix the repository URL in a couple of the repositories I’m using.
Now I’m on 42.1 using Plasma 5, and so far I mostly like it. A few features and settings have gone from parts of the kdepim suite, and there is one weird glitch-error where starting kopete gets me a weird “file: ioslave has been terminated” error, that I’m sure is somehow related to kopete styles. Maybe when I’ll do my desktop I’ll do the upgrade to Leap first, and then the upgrade to the latest plasma5, and not the other way around like on this laptop.
On the whole I’m happy with what I have here.
One little thought just keeps nagging me:
How come that Plasma 5 with the breeze style looks a LOT like Windows 10? …, wait, Windows 10 came after Plasma 5, right?
Edit, 2016-09-14: Turns out I should have done the upgrade to Leap 42.1 first, and THEN the KF5 update. I had some repositories enabled that should not be mixed. Disabled the bad ones, zypper dup -l, all is well.
To whom it might concern:
My regular email address now works as a jabber/XMPP address as well.
If you do not know my regular email address this information does not concern you 😉
I just finished a major heart surgery on my laptop. Many thanks to the guys who made some youtube tutorials about taking that laptop apart! The Acer E5-571G is definitely NOT built to be taken (apart) lightly (Here is the german tutorial that I was following, and here is an english one).
After swapping out the 2x 4G memory modules for 2x 8G ones, and the 1TB laptop hard disk drive for a 1TB SSD disk, and putting everything back together, the real fun began. First I just went to the store on my unu, the faster scooter ever, to get all the parts I needed. You can go to your local electronics store to get your parts.
- install the old harddisk in an external USB3.0 harddisk enclosure (the drive was still good after all)
- boot from a Windows 10 installer
- partition the disk and install Windows 10 in about half of the available space
- the usual windows installation hijinx: install a driver, reboot, repeat ad nauseam
- when windows is about done with the initial installation stuff, plug in the old harddisk on USB3.0 and copy the data from your old user account to your new
Then the linux fun begins, but be aware that this method will only work if the existing linux installation on the old disk was based on a LVM setup!
- boot from openSUSE 13.2 installer DVD, but boot into rescue mode!
- partition the unused space on the new disk as follows:
- 250MB /boot
- one LVM physical volume from the remaining space, but do not create the actual PV yet
- plug in the old disk again
- mount the /boot partition from the old system somewhere
- create ext4 filesystem on the new /boot partition, and mount it somewhere
- rsync the content of the old /boot to the new one
- unmount the old and new /boot partitions
- check that you can see and access your old logical volumes via the usb3 connection to your old disk (lvs, lvdisplay, vgs, vgdisplay, pvs, pvdisplay)
- now create a PV on the new partition that you created a few steps ago
- add that PV to the volumegroup on your old disk
- move all used extents away from the old disk with pvmove
- once this is done you can remove the pv that is located on the old disk, unplug the disk and use it for something else.
- make sure the /boot partition on the new disk is not mounted
- mount your root volume to /mnt
- prepare your mounted root for chroot
mount -o bind /dev /mnt/dev mount -o bind /sys /mnt/sys mount -o bind /proc /mnt/proc
- Change into your installed system with chroot
chroot /mnt /bin/bash --login
- Edit /etc/fstab, make sure all references to mounted filesystems are correct (partition label/identifer for the EFI partition, UUID for /boot, etc)
- regenerate the initrd with mkinitrd
- recreate the grub2 configuration with grub2-mkconfig
- reboot, enter the BIOS setup, go to the UEFI boot settings and make sure the boot order is correct and secure boot is OFF.
- the next reboot should get you into a working GRUB2 that lets you boot linux but not windows, so boot linux, start yast2 and reinstall the grub bootloader again from there.
That’s it folks!
Here is a little poll that I came across on a mailinglist just now:
I finally updated my last machine from openSUSE 12.3 to 13.1 (in the usual way), and with that one I had a bit more fun than the other few times I’ve done this by now.
First mysql refused to start, then quite a few services that were enabled on 12.3 decided to be disabled on 13.1, but nothing during the update “told me so”… but now all seems to work fine.