Cannot boot anymore after motherboard change

English Install/Boot/Login
1

Hello all,

I’m stuck with an annoying issue and I thought I’d check with you guys before reinstalling everything. I got a brand new Dell Precision 7730 and installed OpenSuse Leap 15.0 on it. It worked fine and I had a functional system, until we discovered there was an issue with the processor (one of the MemTest86 tests failing on one of the cores). So I had my motherboard replaced, and now my CPU runs fine, MemTest86 doesn’t detect any error.

Except now, I can’t boot to OpenSuse anymore: it does boot to grub, but after selecting the OpenSuse entry, it writes down a few messages (which were displayed also with the former motherboard), then gets stuck with a message “A start job is running on dev-disk-<UUID>”.

So I searched a bit and found out the usual cause is that UUIDs for the disks/partitions have changed. But I double-checked: they haven’t. The internal SSD has not been changed, and if I boot to a live distribution and display the UUIDs with the blkid command, they are the same as before. I also saw that there might be a problem with initramfs, so I regenerated it, again using a live distro, mounting everything and running dracut in a chroot. I tried to regenerate the grub.cfg file, but I end up with a file that is identical to the previous one. I also tried to change my /etc/fstab file to use the devices in place of the UUIDs for the partitions to mount. But after all that, no change: I still can’t boot, I get the same issue.

My next move would have been to save the root and home partitions to an external drive, reinstall everything, then restore the partitions. But I’ve never done that, I’m not too sure how safe it is. And it sounds a bit overkill: it seems that it’s just grub that’s broken, the disk is fine (I can access all contents when I use a live distro, so everything’s still there).

Any idea about what else I can try before wiping everything out?

Thanks!

  • Eric
2

Some kind of UEFI nightmare?

I would not waste any time and simply install Leap again to the / partition and mount the existing /home partition in the partition setup while installing. Import the user(s) from this partition during installation (very easy to find when asked for new users besides “root”). Afterwards you only have to install your software again (if you don’t do it in the usual setup during install) and your personal settings are there.

3

Thanks for your answer.

Highly likely indeed. I miss the good ol’ BIOS days…

That was what I was considering in last resort, the problem being I have a pretty crappy Internet connection and a lot of things to install and upgrade, so that would take hours. So I’m still hoping someone can find a brilliant idea that would fix my system as it is.

Thanks again!

4

I use lots of Dell (older Precisions also) and had to mess around with the BIOS setting for UEFI (in three different menus inside BIOS) for some stuff after moving the SSD with an installed OS (BSD) to another machine. Went to BIOS, UEFI boot options and had to do a fresh link to the efi.xxx file on the SSD (yeah, there is some kind of file browser inside the BIOS…).

I think your solution is inside the BIOS… (if there is any) :slight_smile:

5

Already did that I fear, and I indeed had to add an entry for OpenSuse pointing to \EFI\opensuse\grubx64.efi. I tried to add entries for all others *.efi files, whether in \EFI\opensuse or \EFI\boot, but they all behave the same: they show the grub menu, and as soon as I try to actually boot, I end up with the dreaded “A start job is running for dev-disk-by-uuid-<UUID>”…

There is something strange though: in this message, some of the dashes appear “normally”, i.e as “-”, and others appear as “\x2d” for some reason… I doubt this is significant at all, but I thought I’d mention it.

I also tweaked other options in the BIOS, like turning Secure Boot off, and probably other things I don’t remember. But I’m still stuck.

6

Check the “resume=” parameter. Some Leap 15.0 installs got that wrong.

A simple way to check:

  • Hit ‘e’ on the grub menu line;
  • scroll down to the line that starts “linux” or “linuxefi”
  • scroll right to find the “resume=”
  • just delete that whole parameter (up to the space)

If it then boots, you have identified the problem. If you still cannot boot, then that’s not the problem.

7

That resume= is an override of initrd content. To find out if the problem has anything to do with the swap’s UUID, change it to read noresume.

What does

efibootmgr -v

report from rescue boot?

8

You can try launch yast from cli or chroot and go to partitioner and specify mount points for / and /home again and let it finish and then try reinstall grub also.

9

Also, what partition is that? root, home, swap, or some other? (the entries in /etc/fstab should tell you.)

What, if anything, happens if you allow the start job to time out? (If it’s the swap partition boot should continue after the time-out).

10

Well, thanks everybody for your answers, but too late: I had spent way too much time on this issue already, I decided to reinstall from scratch. Which showed me that the new motherboard is actually not exactly the same as the previous one, since the UEFI on it does not behave the same way: some things I did during my first install weren’t needed anymore, and some other things weren’t working. So I guess a reinstall was actually inevitable.

Thanks again!