To be on the safe side, I’ve been trying to upgrade to 15.3 using the DVD. I receive a series of Ruby errors when the upgrade program attempts to load the software updater – Yast2 I assume. A typical error message is
/mounts/mp 0001/YaSt2/modules/RootPart.rb:137:in fstab_entry_matches
undefined method ' ' for nil:Nil Class
There are several others that are similar. I’d upload a log, but since I’m running from the DVD, I assume it is not stored. I’m wondering if this has to do with the fact that I installed an SSD in my computer, and transferred the system to that, while keeping the original disk. If it helps, all my file systems are ext4. Perhaps something didn’t properly identify the system location? I hesitate to try to upgrade by any method until I get to the root of the problem (no pun intended).
I used an actual DVD. I booted it as legacy as that is how my system is configured and chose the upgrade option. The boot completes, the graphic interface loads, it does the initial system checks, gives me the license which I approve and then moves on to the second set of checks. The last item on that list is loading the software updater which is when I get the Ruby errors. I used the same procedure when I updated from 15.1 to 15.2 with no problems.
I don’t think the issue is with the software downloads, but with my system. How would download in advance help me?
So does your existing 15.2 installation boot OK, and is the system fully updated, ie you performed a “zypper up”, before you attempted the distribution upgrade.
Transferred how exactly? If you cloned without eliminating duplicate UUIDs and volume labels, then rebooted with both disks accessible to BIOS and OS(es) without somehow making those crucial changes, you’ve set the stage for mass destruction. YaST/Ruby would be confused by duplicate UUIDs and/or volume labels, very likely without any error handling for the situation.
A pure clone disk, followed by removal of either original or clone before a restart, should pose zero problem for upgrades, or anything else, unless possibly the SSD was NVME form factor making rebuilt initrds needed.
then log out from the GUI, drop to a virtual terminal and perform a “zypper dup”
If you specifically want to use a physical medium for the update then you may be better off using a USB stick if you’re able. Either write the image using DD or “Imagewriter” (you may need to install that first, it’s in the standard 15.2 repositories).
I did check the sha256 checksum when I downloaded the image and used write verify when I loaded it on to the DVD, so I’d expect no problem there. I’m gravitating toward the idea of doing the zypper dup method. I’m curious about the USB stick. Can it be booted as legacy?
Problem solved. I had left the original system files on the old hard disk. Even though the volume label and UUID of the old hard disk was changed, and 15.2 had no problems recognizing that the system was on the new SSD, the DVD installation program saw the old HDD system files before the system files on the SSD despite the fact that the SSD is sda and the HDD is sdd. As an experiment, I formatted the former root partiton of the old HDD to get rid of the old system files (should have done this long ago). Rebooting to the DVD, the installation program recognized the system on the SSD with no problem.
All UUIDs and all relevant volume labels must be unique to avoid trouble like you encountered. From your language is sounds like you missed at least one needed edit. UUIDs aren’t just used in /etc/fstab/ and root= in kernel command lines, but also many other places in Grub’s files, and UEFI firmware memory.
I’ve been cloning as a part of backup strategy on multiple machines for decades. I rely exclusively on volume labels for native filesystems in /etc/fstabs, and as much as practical everywhere else, including in particular /boot/grub2/custom.cfg, the primary provider of Grub’s menus here on UEFI systems, and /boot/grub/menu.lst on DOS/MBR PCs. UUIDs are for machines, scripts and eidetic minds, LABELS for other human admins.
sdd suggests an old PC that was only using PATA before adding the SSD. SATA + PATA in the same PC has often been a recipe for inconsistency in storage device enumeration that the default use of UUIDs was largely intended to avoid. LABELs, selected wisely, serve the same purpose well.
