sedutil not rebooting after unlocking drive

[zapling]

Hey! I'm having a bit of trouble when trying to unlock and boot. The setup went smooth and I followed all the steps outlined in the wiki. But after inputting my password to unlock the drive it gets stuck at Starting OS image. I think it's supposed to restart here but nothing happens even after waiting a couple of minutes. The cursor blinks for a few seconds and then stops.

I also tried to reboot directly from my rescue USB, and it seems to hang there as well image 2

I have disabled secure boot. I had a look in the bios but I did not recognize any other settings that would help me solve this.

Any pointers on how I would debug this further?

I'm using a lenovo x1 carbon gen7 with an nvme drive

Edit:

I gave up on this since I couldn't get it to work, ended up doing a full reinstall with LUKS and have not had any issues so far.

[alfaix]

Uhhmm... Is anyone looking into this?

I have the same issue, though I'm on a desktop PC. I tried playing around with CSM settings, made sure fast/secure boot is disabled and am kind of stuck on this.

Once the "Starting OS" line shows up, I can manually reboot the computer (by pressing the reset button), then it properly boots, and the drive is unlocked, which probably means the issue is just that it can't reboot - unlocking went fine.

I tried the same with 1.20.0, 1.15.1, 1.15.0 with no success. The issue is somewhat similar to (the very last comment of) this thread, but that one sort of trails off at the end with no solution.

Looking at the relevant code, it's really puzzling how it could fail since after the "Starting OS" print there's just sync(), sleep() and reboot(). I also noticed that the cursor stops blinking after about 5 seconds, which probably means that the sync and sleep went fine, and the issue happens after the wake up from the sleep, inside the reboot call. My first guesses would be "the kernel gets stuck trying to clean up" or "something something kernel version" (my ubuntu runs on 5.11, and the one in the RESCUE64 image seems to be 4.11), but I have no idea how to investigate this further and would greatly appreciate any hints.

Also the relevant man page says that the call should print "Restarting system", which it doesn't.

Looking at kernel logs would probably help, but I'm not sure how to find them on the rescue system/on the PBA installed by the rescue system.

---

A bit about my system: I have 2 NVMEs (Samsung EVO 970 Plus 1TB) and 1 SATA3 Samsung SSD (Samsung EVO 860 1TB). I have Windows and Ubuntu on the 2 NVMEs and I'm trying to encrypt the 3rd SSD (after which I'd like to encrypt the rest). I boot from UEFI, the motherboard is ASRock Z490 Taichi.

[r0m30]

It's pretty much impossible to debug this remotely. You say you disabled fastboot and that's the only thing I usually have to contribute. Your "normal" Linux system isn't really helpful in debugging because the PBA/RESCUE uses busybox.

[andrei-datcu]

I'm having the same problem as @alfaix: issuing a reboot command inside the rescue system will freeze my machine and the PBA will hang after unlocking the drive. I'm on a laptop (so no reset button for me), but the systems are otherwise similar: booting UEFI with an Intel TongFang QC7 laptop. I'm happy to help if you provide any hints to debug this further. Thanks!

[alfaix]

I "solved" this by using ChubbyAnt's fork. However, that one doesn't seem to work with NVMEs and I'm still in the fun process of debugging that new issue.

[andrei-datcu]

@alfaix, are you sure it's not compatible with nvme drives? @ChubbyAnt seems to suggest otherwise here: https://github.com/ChubbyAnt/sedutil/issues/18#issuecomment-670661159

I'll give it a try myself and will let you know the results.

[ChubbyAnt]

@andrei-datcu @alfaix this fork definitely support NVME as a PBA boot device: https://github.com/ChubbyAnt/sedutil

Secure boot must be disabled.

[alfaix]

@ChubbyAnt @andrei-datcu yes, apologies, I phrased it poorly. I'm just running into an issue when setting up the NVMEs.

It's something along the lines of takeOwnership failed: NOT_AUTHORIZED, which should mean "wrong password", but I never set up the password, and furthermore, I successfully boot from the device without entering any.

There's an issue with a similar description, which recommends sedutil-cli --PSIDrevert /dev/nvme0, however, that one complains about INVALID_PARAMETER - which is where I gave up last time.

The plan from here was to factory reset stuff from UEFI and try like that, which isn't really something I want to do, so if anyone has a better suggestion that'd be great.

[andrei-datcu]

@alfaix You need to pass the PSID as argument. You get the PSID from the actual physical drive. It's a long string. So:

sedutil-cli --PSIDrevert <long PSID string> /dev/nvmeX

[r0m30]

Is the driver Samsung? If it is, they started shipping their drives with the admin SP active. I think it was to prevent a hacker from using the MSID to encrypt your drive without any knowledge about it. The PSID won't erase your data because the locking SP is not active.

[alfaix]

Using ChubbyAnt's fork fixed the thread's issue for me, and PSID reset helped with the second issue. Sorry for the late reply and thanks for the help :)

[JJones780]

I may have stumbled on another hint to this behavior. For me plugging in a sata drive that had been present during installation fixed things.

Another odd thing: If I unplugged my vga monitor ( and just used the HDMI monitor) it would successfully reboot after unlock ( this was before I found plugging back in the old sata drive worked ). Without either of these two fixes it would simply shutdown.

The question would be: What does the opal unlock boot know about machine config? If it cares about changes, for security, shouldn't it warn the user? I'll try reinstalling the opal boot unlock when the sata drive isn't present and hopefully that fixes things.

[gohrner]

This problem may be related to https://github.com/Drive-Trust-Alliance/sedutil/issues/404#issuecomment-1179582795 :

After 12+hour fight I fixed it. Finally I've recreated UEFI64.img with syslinux.cfg without acpi=off noapic part. I loaded this new img with --loadPBAimage

[jantman]

Yeah, I'm pretty sure that #404 is a dupe of this.