Tried update 15.5 → 15.6 both online update and booting from thumb drive, but each time the root partition corrupted - had to rollback to last 15.5 snapshot.
This system was actually rebuilt last year, with a fresh install of 15.5.
How can the actual problem be isolated?
TIA!!
How are you actually performing the upgrade in each case? What specific steps are you following?
Most recently, zypper up; resulting in a non-bootable root partition, requiring rollback:
Please read these instructions – <SDB:System upgrade>
BTW, the commands are –
# zypper --releasever=15.6 refresh
# zypper --releasever=15.6 dup
That is a very, very short description which many steps missing. But in any case there should be some form of zypper dup somewhere in the whole process.
Rather logical as dup is short for “distribution upgrade” and that is what this 15.5 → 15.6 is about.
Yet another question or two –
UEFI, never had Legacy on this system.
BTW - I gave up trying to upgrade to 15.6, … the last update tests were the final 15.5. Since the last successful update, there are now 400 pending, but still resulting in an unbootable root partition.
When you do that and also do not seem willing to provide detailed information on what you did, I guess this thread is useless and can be closed.
Can only provide the keystrokes used, … is there something else that might be useful?
Is there any way to find out what, exactly, is broken in that snapshot? Grub2 just refuses to boot it, but no other info available.
Next test - install 15.5 package updates without the OS upgrade (i.e. zypper in , …
Re-read post #4 where I explained that doing zypper up is NOT the way to go. And post #3 where the most crucial commands for an on-line upgrade are shown. But when you do not really answer things, others can not really help.
Here seems to be some missunderstanding. The TO rolled back to an old snapshot and wants to update to the latest 15.5 versions now to see if it also causes a corruption.
But nevertheless a fully updated Leap 15.5 is a requirement before starting the upgrade to 15.6. That means, when the upgrade process to Leap 15.6 was started without properly updating the old 15.5 beforehand, this could lead to issues. That is why @dcurtisfra linked the SDB where this is explicitely mentioned and @hendersj asked how the upgrade was performed.
zypper up isn’t used for a distrubition upgrade, as others noted. zypper dup is, but you have to make some changes.
We don’t know anything about your system - what the hardware is, what the command input/output was. How you tried the upgrade from a USB drive (for example, if you used Ventoy, that might well be the cause of problems because of how it works). We don’t know the repos you used. We don’t know where you downloaded the ISO from, what verification steps you took to ensure it was not corrupted…
We only know what you tell us about what you did, and if you can show us (ie, cut/paste commands and output from an attempt that then fails), we can help you.
Literally thousands of people have run this upgrade without issue. I ran it myself on my wife’s laptop late last year.
So it’s either:
Without more info, we really can’t help much.
As I said earlier, after the 15.6 dup failed, I rolled back to the last 15.5 snapshot; the attempts today have been to update the current 15.5 snapshot, which also failed, so the current booted snapshot is the previous 15.5.
Have done at least 50 15.6 upgrades, but all servers; whereas this is workstation w/Gnome.
So, what is the sane path forward?
TIA!
The initial 15.6 upgrade WAS with an updated 15.5. Now, months later, the goal is to update the 15.5 to attempt the 15.6 upgrade again.
The current booted snapshot is that last 15.5 version, … which was taken before the original 15.6 upgrade attempt.
Well, earlier you said you used ‘up’ rather than ‘dup’, so that was part of the confusion.
For the path forward, we need to understand more about how you did the upgrade (not just the command you ran, but the configuration of the system and such, as well as the hardware in use).
When you say it “failed”, in what way did it fail? You said it corrupted the root filesystem, but if you can restore from a snapshot, that doesn’t sound like a corrupted filesystem.
I would be inclined to run the upgrade again, copy all the relevant log files and command output (including the command run) to a text file on a data volume or external drive. Include the output of zypper lr -d as well, and share that info with us. Maybe there’s a repo that’s not taking the releasever variable or just not 15.6 compatible, and that’s causing issues.
We can guess all day, and that’s all we can do without specific information.
The more you can help us see what exactly happens when you run the upgrade, rather than describing it to us in what are pretty vague terms, the more we’ll be able to help.
At this point, upgrade is not an issue - an update 15.5 TO update
Failed = non bootable root partition, requiring rollback
For exmaple, which snapshot might be a better starting point?
Well, a good starting point would be to provide a list of the repos on the system (zypper lr -d, as I mentioned before) so folks here can provide some specific update. There are really specific bits of information you’ve been asked for but haven’t provided.
I would go to the last bootable, probably. Start with a zypper up to be on the latest version of packages available for 15.5, reboot (if necessary), and then do all the preflight checks for an upgrade from 15.5 to 15.6. Things like making sure the repos that are enabled are all either (a) able to use $releasever, or (b) have been changed to the correct URLs for 15.6.
Then, personally, I would run a zypper ref && zypper dup -d --allow-vendor-change --releasever=15.6 to download all the update packages. That lets you make sure everything downloaded without error (it’s out of an abundance of caution; a failed download in a normal upgrade will let you know if there was a download error and stop).
Next, I would switch to text mode and log in as root (again, largely out of an abundance of caution because you’ve had issue with the upgrade previously).
Then run zypper dup -d --allow-vendor-change --releasever=15.6.
After that, I would copy the zypper log files from /var/log/zypper to an external drive in the event that the issue repeats itself. That way, you have them and they’re not buried in a snapshot somewhere that you can’t boot - and then you can share them here for further diagnosis.
That’s an extremely generic answer, because, again, you’ve not provided the details that you’ve been asked for multiple times, which would help with being able to provide advice more specific to the issue you’re experiencing.
The more actual data we have, the better.
