System:
Motherboard: ASUS STRIX B-350 F.
Processor: AMD Ryzen 7 1800X.
System disk: Samsung 960 Pro 512 GB M.2 PCIe SSD
On upgrading from Leap 42.3 to Leap 15, after choice of language, keyboard etc, the install software presents a suggested partition to upgrade: /dev/nvme0n1p1. This is correct. On confirmation, the install software reports an error:
Storage::Exception
and says it’s important to report it as a bug. Then everything freezes, and it is necessary to press the hardware reboot button.
The error is 100 % reproducible.
I did two upgrades on different hardware with no problem.
The earlier upgrade to Leap 42.3 from 42.2 on the same hardware went without problems.
Hi,
Thanks.
I tried to register a bug report with bugzilla, but it failed. With Firefox it said:
“Secure Connection Failed. The connection to the server was reset while the page was loading.
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.”
With Chromium it said I wasn’t allowed to post it.
Any idea what information I could get out of the system? There is (I think) a possible window before I accept the choice (but than it hasn’t yet happened).
I mentioned 42.3 in case the information could be used.
Thank you for the Tumbleweed tip.
However, it seems he had done some changes to the boot loader before upgrading, and then got problems with booting. In my case, the upgrade system freezes on choosing the partition to upgrade, and nothing happens to my computer, which afterwards boots to 42.3 without any problems (except not being upgraded).
I thought the problem might have to do with the system partition being on the new, ultra fast Samsung SSD.
What is the opinion on changing all the software repositories to Leap 15.0 versions and then doing zypper dup?
Is it the same as running the DVD and doing upgrade?
Any other suggestions?
IMO it is even better because you have then all packages available during upgrading, while when using the DVD there will be less and thus an extra update to replace those might be needed. Also, while you then have the Update repos also available, you will get what is updated (security and recommended) directly.
But take care. During that zypper dup disable all non-official repos and add the new 15.0 of those later do update to them so you can decide which comes from where (e.g. when using Packman).
In any case, may here (including me) did that with success.
There’s a banner at the top of the forum page about down time. It is my impression that they have been having some technical problems causing slowness and connection issues for the forum and perhaps also for bugzilla. Maybe those problems are related to why you have that failure.
Internal error. Details: Storage::Exception
Caller: /mounts/mp_0001/usr/share/YaST2/lib/y2storage/storage_class_wrapper. rb:260:in ‘find_by_any_name’
Calling YaST module ‘inst_update_partition’ has failed.
More info near end of /var/log/YaST2/y2log
I could open a terminal after the error message came (ctrl-alt-F2), and found that the partition to be upgraded was mounted.
Thank you for the advice.
Is there any difference between doing the upgrade by ‘zypper dup’ and through Yast (by clicking the option of ‘changing the system to this packet repository’, sorry, don’t quite remember the wording)?
Also, as I use the Nvidia proprietary graphics driver, it would probably be ok to enable that repo in addition to the official repos?
I assume you can do the same using YaST, but I am not sure what is best then. First do two switches to new OSS and new non-OSS, then do YaST online update to get the ones from the Update repos. I think doing it with zypper dup is much easier, all in one go.
Thank you for the help!
I did upgrade with zypper dup with the new OSS, and it work well.
However, I did find out that it probably needs more space on the system drive compared to a DVD based upgrade, as all the files are downloaded before being installed, and therefore coexist with the old packages. I ended up with a full disk, but managed to find about 6GB worth of old ext4 journal files, that could be removed, so in the end it was a success.