A start job is running... & Secure Boot / MOK

English Install/Boot/Login
1

Hi,

upon boot I get a

A start job is running for dev-disk-by\x2duuid-9ca59c23\x2d4cd7\x2d592f\x2d50cb09a2669c.device

I’ve already checked fstab, but there is no mentioning of any of these numbers.
this has problably something to do with this: https://forums.opensuse.org/showthread.php/530999-Created-BTRFS-on-external-SSD-what-now, since it’s happening since I created a BTRFS partition on an external drive. This drive does appears in fstab, but is set to noauto and the UUID does not resemble any of the above mentioned numbers.

After every Kernel update I get a “blue screen” upon boot “SHIM Uefi key management” - I have enabled secure boot. I can just continue booting normally by pressing enter, but there are some options I can chose from “Press any key to perform MOK management” but I don’t want to mess up my system.
What do to? Simply disable secure boot?

Thanks.

2

Hello,

Simply enter your root password. (thank you Malcolm :slight_smile: ).

https://forums.opensuse.org/showthread.php/530925-What-is-the-message-of-quot-Enrol-MOK-quot-while-booting-from-UEFI?p=2864300#post2864300

3

I suggest you check “/etc/default/grub” to see if those numbers show up.

I had a similar situation with a recently installed Leap 15.0 Beta. Booting took a long time, with a 90 second pause with nothing appearing to happen. I managed to find that message. And I found the disk it was trying to access in “/etc/default/grub” (the “resume=” parameter on the default boot command). It had configured for “resume=” a swap partition that happened to be available during install, but is not available during normal running. Once I fixed that, and then regenerated the grub boot menu, it has been booting a lot faster.

  1. After every Kernel update I get a “blue screen” upon boot “SHIM Uefi key management” - I have enabled secure boot. I can just continue booting normally by pressing enter, but there are some options I can chose from “Press any key to perform MOK management” but I don’t want to mess up my system.
    What do to? Simply disable secure boot?

Select “Enroll key” (or is it “enroll MoK”), then enter root password when asked for a password. This will cause a new openSUSE key to be enrolled (for checking signatures on kernels). And you won’t see this prompt again unless they decide to enroll another key. Yes, it is a bit confusing.

4

Thanks, successfully enrolled the MOK key.

However the start job problem still persists. I can’t find any entry in fstab or grub that resembles

dev-disk-by\x2duuid-9ca59c23\x2d4cd7\x2d592f\x2d50cb09a2669c.device
5

The start job is unrelated to secure-boot.

I would suggest you grep for just the string “9ca59c23” to see if you can identify that disk.

6

If you do (as root in a console)

# dracut --print-cmdline

will the result contain the above mentioned UUID (9ca59c23…)?

If so, rebuilding your initrd-file with

# dracut -f

might help.

Regards

susejunky

7

Had this issue too. Fixed it by running “dracut -f”.

8

Unfortunately dracut -f did not help :frowning:

9

It’s easy to miss one step. That happened when I cleaned up the HDD by removing all system partitions and expanding the remaining one. Make sure to switch off secure boot and run all off the following:

  • grep UUID /etc/default/grub
  • grep UUID /boot/grub2/grub.cfg
  • dracut -f
  • grub2-install --target=x86_64-efi
  • grub2-mkconfig -o /boot/grub2/grub.cfg

Then shut down the machine and boot from ‘opensuse’

10

Start out by giving me the output of:

fdisk -l -o +uuid

Please post the above command and the resulting output here between code tags (the # icon/symbol in the menu above the forum editor window).

Also, (or?) in Yast->Boot Loader under Kernel Parameters make certain that “mysterious” UUID is not the one listed in the “resume=” line

11

It’s not under resume, and here is the output:

[sudo] password for root: 
Disk /dev/sda: 238.5 GiB, 256060514304 bytes, 500118192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: AE637BA7-AAD7-40CE-AB86-F4701C981D3F

Device         Start       End   Sectors   Size Type                         UUID
/dev/sda1       2048    616447    614400   300M Windows recovery environment D8542D8A-3351-4CF1-BE4F-35F962F14711
/dev/sda2     616448    821247    204800   100M EFI System                   74A2EC47-165F-413E-BF72-C20EE2923AF5
/dev/sda3     821248   1083391    262144   128M Microsoft reserved           CC8FEBD5-6EC1-41A8-B186-F18F88A036AF
/dev/sda4    1083392  90021887  88938496  42.4G Microsoft basic data         66BAD1FD-7DA3-4639-8F30-E64836C60176
/dev/sda5   90021888  91045887   1024000   500M EFI System                   30ED456C-6492-4FE4-B78B-DBFBA13FF362
/dev/sda6   91045888 174931967  83886080    40G Linux filesystem             2CA7345F-8A39-45AB-ADE4-93CF6BF8C579
/dev/sda7  174931968 495923199 320991232 153.1G Linux filesystem             1BCF47CB-A352-4BBA-94A7-9D2C700C9B04
/dev/sda8  495923200 500118158   4194959     2G Linux swap                   7B6BDA14-51DF-42B7-BBCC-27A00DFA5E37
12

I think that is not useful.

The “fdisk” output will have the partition UUID (or PARTUUID), and not the filesystem UUID. It is the filesystem UUID that we are looking for.

I’m alerted to this by the reply from SF6. The UUID it gives for the EFI partition is far too long to be the file system UUID of a vfat file system.

In any case, the startup message is almost certainly looking for a UUID which cannot be found by directly examining partitions (otherwise there would not be a startup delay).

The other places to look:

“resume=” in the grub configuration. Apparently it is not there.
A logical volume that is inside an LVM or encrypted LVM. It is presumably a file system that was accessible during the install but is not accessible now. If install was from a USB, it might also be a partition on that USB.

13

Right, thanks, Neil. Unless I stumble across something, I cannot help here.