Upgrade from 15.2 to 15.3 will not boot default boot entry, only boots recovery boot entry

English Install/Boot/Login
1

I originally posted this thread, but I think I solved the original issue as I updated a restored image via the online update and that worked without conflicts (though an update from DVD after following the suggestions in that thread exhibited the same symptoms I am seeing now).

The problem now is that on reboot from the online upgrade when booting

15.3 default

the splash screen shows the spinner for what seems like a long time and then finally goes away without giving me a graphical log-in prompt, or properly starting all of my services like Network, DNS, Samba, and so on.

So I tried booting the entry for

15.3 default (recovery mode)

and that boots correctly with everything functioning like my DNS and Samba server. I then went into YaST boot configuration and removed splash=silent from the kernel options so I could see what is happening when I boot the default.

What I see is that the system is trying to mount a partition that no longer exists in my system. I checked the partitioner in recovery mode, and the disk ID that the system is trying to mount does not match what is referenced in the partitioner or the fstab file for my system. I think that what the upgraded system is trying to mount was a swap partition.

A little context might help: Before the upgrade, I made an image backup of the system drive I had in my system and restored that to a new, larger drive using “Image For Linux”](https://www.terabyteunlimited.com/image-for-linux.htm) In order to get that to boot, I had to manually edit /etc/fstab and put in the partition/device names. After the system successfully booted, I then went into the partitioner and changed the options for that drive to mount them by drive ID because my initial attempt at updating to 15.3 from DVD complained about having device names in the fstab file instead of device/drive IDs.

So, with the system booting from the new drive and the partitions being mounted by drive ID, I upgraded to 15.3 online. And now, I am at a point as I described above where the system is trying to mount a file system from a partition of a drive that no longer exists in the system. BTW - there appears to be no timeout for this operation and this, obviously, explains why it takes so long for the spinner to go away and leave my system without a login prompt.

How do I correct this? The fstab file is correct, however, it seems that the system, when booted “default,” is using something else to try to mount the file system, and I do not know what that is or how to correct it. My original thought was that since it is a swap partition, I would just reformat the partition; however, since the system is trying to mount a partition from a drive with a completely different Drive ID, I thought that the problem might lie elsewhere.

Would someone please let me know how to fix this?

Thanks in advance!

2

I have seen this before - you might have a non-existent entry for a drive in the /etc/fstab or a typo - use blkid to see what the OS sees and compare it to /etc/fstab. If that is it you have your fix. If not then I suspect you have inconsistent UUID’s - you should have saved the uuid’s that were in the /etc/fstab and used tune2fs to rename the current uuid’s to the old ones and if you have swap mkswap to change it to the old one. The exception is if you have UEFI boot partition - you have to change the UUID in the /etc/fstab to match what blkid shows for the msdos partition. I have not found a way to change the MSDOS partition UUID.

I think if it does boot up - a mkinitrd might change all the uuids in the boot up logic. if you are booting from a recovery disk you will have to mount the file system and mount -B the sys dev run and proc directories onto the mounted drive and chroot to it to run the mkinitrd.

3

I have just had a very similar situation where I cloned a partition and then had to change it’s UUID to keep it unique. I simply edited fstab with the new UUID having booted from a USB drive. Then manually booted from the GRUB prompt defining the route as a /dev/sda1 type format as opposed to UUID. Then a quick reinstall of GRUB via YaST got everything working. This was in an legacy boot environment not UEFI.

4

I think if you look at /boot/grub2/grub.cfg and compare the default entry to a recovery entry you’ll see one difference is the presence or absence of a resume= parameter. Next boot, strike the E key at the default entry, find and remove the resume= parameter, replacing it with noresume. That should give you a normal boot from which you can repair the UUID problem you seem to have with your swap partition.

Check /etc/default/grub for the presence of a resume=UUID parameter, and make sure if you have one that it matches the UUID of the current swap partition. Alternatively, instead of UUID, recreate the swap partition giving it a LABEL with the -L option, and then change /etc/fstab and /etc/default/grub to use the LABEL instead of a UUID. By LABEL is much easier for most human brains to cope with.

Once these edits are made, run grub2-mkconfig -o /boot/grub2/grub.cfg.

You can make the edits with YaST if you find it easier, and it will update grub.cfg on exit.

5

Thank you so much for this post. I found it a simple solution that was easy to employ. :good:

I had a look at /boot/grub2/grub.cfg and there was a resume=parameter on the default entry but not on the recovery parameter. I booted and highlighted the default entry, hit the E key and replaced the first of the resume= entries with noresume, then removed the second resume= entry. The system then booted into the OS properly.

I then looked at the partitioner in YaST and got the current id of the swap partition. From there, it was off to /etc/default/grub. ;)I found that there were two resume= parameters and both matching the ID of the device that the default boot hung on, which was the id of the swap partition from the old disk. Given that my linux drive is hardware raided (RAID 1), most of the ID contains the name of the raid controller, and there were only eight digits that needed to be changed from both resume= entries so that they matched the ID of the current swap partition (I was able to copy them from the partitioner dialog and past them into the file to replace the old digits). Easy, IMO, for an ordinary human brain to handle. lol!

Then I ran

**grub2-mkconfig -o /boot/grub2/grub.cfg**

rebooted, selected the default entry, and the system booted normally. I then went into the bootloader in YaST, made the default entry the default again, restored the splash=silent parameter, saved the changes, and rebooted. Everything is back to normal, and life is good again.

If I find myself in a similar situation again, migrating to a new drive, that is, I kept detailed notes and stapled a printed copy of your post to the page in my notebook.

The other posts were excellent, too, and I still have the old system drives, so it would have been relatively easy for me to get the old /etc/fstab file, however, your post seemed like much less work for me and it enabled me to solve the problem without too much fussing around.

BTW - the system is configured to boot UEFI, however, it seems that was not that much of a consideration in this situation. I had changed the /etc/fstab file to use the IDs from the new drive (through the YaST partitioner); however, it seems that the one extra thing that needed to be done was to change the /etc/default/grub file so the resume= parameters matched the ID of the new swap partition. This was a simple solution, and it makes me wonder if there is something that can be done with the grub configuration process to automatically make such a change if needed. :dont-know: IMO, that would be a helpful improvement.

Thanks for the opportunity to learn!

6

Thanks for being a good student! :good:

7

Short procedure, which fixes all issues, on my systems of course.:wink:

3400G:~ # grub2-install 
Installing for x86_64-efi platform.
Installation finished. No error reported.
3400G:~ # update-bootloader 
3400G:~ #