Package Details: sedutil 1.49.7-1

Git Clone URL: https://aur.archlinux.org/sedutil.git (read-only, click to copy)
Package Base: sedutil
Description: TCG OPAL 2.00 SED Management Program
Upstream URL: https://github.com/Drive-Trust-Alliance/sedutil
Keywords: tcg
Licenses: GPL3
Submitter: R00KIE
Maintainer: 2bluesc (ozz)
Last Packager: 2bluesc
Votes: 45
Popularity: 0.113118
First Submitted: 2015-10-18 14:02 (UTC)
Last Updated: 2025-03-02 19:58 (UTC)

Dependencies (8)

Required by (0)

Sources (11)

Pinned Comments

R00KIE commented on 2016-08-27 21:39 (UTC)

To build this package you need to install one of the following: linux-headers: if you are using Arch's kernel linux-lts-headers: if you are using Arch's LTS kernel

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

ranran commented on 2018-11-26 21:41 (UTC)

Hi Rookie,

You said: "I forgot to mention before, there is a trick to creating the PBA entry when using efistub, the disk must be locked when you call efibootmgr, otherwise it will not know the uuid of the partition and obviously it will fail to start the PBA image using efistub. The trick here is to use a system on a usb drive to create the PBA uefi entry while the disk is locked. "

Can you please say how to use efistub/efibootmgr to add boot entry for mbr shadow ? I could not do it myself.

Thank you!!!!!!! ranran

Utini commented on 2018-10-31 08:26 (UTC)

Why on earth is this not in the official repos?!

R00KIE commented on 2017-05-21 18:58 (UTC)

Let's give it some time and see what happens. If the fork starts to get new code and stable releases then I suppose a change might be in order, until then lets wait and see.

darkbasic commented on 2017-05-21 17:27 (UTC)

Maybe it's time to change the git repo url? https://github.com/Drive-Trust-Alliance/sedutil/pull/56#issuecomment-302948612

mocambo commented on 2017-03-07 23:06 (UTC)

Unable to install on 32-bit system. Please fix. Error: can not find the makefile for configuration 'Release_i686' in project LinuxPBA See 'make help' for details. $ make help This makefile supports the following configurations: Debug Release Release_x86_64 Debug_x86_64

R00KIE commented on 2017-02-19 13:58 (UTC)

Works fine for me. You'll have to provide more context, otherwise with just that message it's not going to be easy to tell what the problem may be.

mh00h commented on 2017-02-19 00:14 (UTC)

This isn't installing with a DtaDevLinuxNvme.h error: linux/nvme.h no such file error

R00KIE commented on 2016-12-13 18:10 (UTC)

I forgot to mention before, there is a trick to creating the PBA entry when using efistub, the disk must be locked when you call efibootmgr, otherwise it will not know the uuid of the partition and obviously it will fail to start the PBA image using efistub. The trick here is to use a system on a usb drive to create the PBA uefi entry while the disk is locked. Regarding the bios changing the order of the entries or deleting entries, I believe that is bios/fw dependent, I don't have any problems with my laptop (Lenovo E560) but there are bug reports about that in the sedutil bug tracker, see [1-2]. [1] https://github.com/Drive-Trust-Alliance/sedutil/issues/66 [2] https://github.com/Drive-Trust-Alliance/sedutil/issues/27

darkbasic commented on 2016-12-13 17:36 (UTC) (edited on 2016-12-13 17:38 (UTC) by darkbasic)

Yes, it makes perfectly sense being able to move the device to an older machine, good point. Completely forgot about EFI stub, I will have a look at what I can achieve with secure boot. By the way, did you experience any issue with EFI entries? If I create an EFI entry and then I lock the SSD turning the power off, then the entry disappears, probably because the BIOS can't find the partition anymore (but the EFI entry still exists in efibootmgr). After unlocking the SSD through the shadow MBR I expected the BIOS to show the EFI entry once again, but it doesn't happen on my Dell XPS 13 9343 BIOS A09. Am I the only one with this issue? Currently I'm booting using the default entry only.

R00KIE commented on 2016-12-13 16:56 (UTC)

For me it makes sense to support both bios and uefi because I still have machines that are bios only and those can be used in case my main machine breaks down (this has been useful to me in a very recent past). There might also be interest for people with older machines that don't support aes-ni but still want to use encryption, by using a sed that comes without performance penalty. Regarding secure boot, I haven't looked much into it yet. You can use more than one method of whitelisting your bootloader, from what I've seen you can use either hashes or signatures so I'd like to give the alternatives a try myself before releasing anything half baked and can provide some pointers for other people. Cryptboot seems like a nice helper to deal with secure boot, I haven't taken too long looking at it but it seems a bit geared towards grub, I'd rather have the PBA image be as generic as possible, what people do/use after the disk is unlocked should not be my concern (less risk of bugs or borking things). There is also the fact that if you are using a uefi machine you don't need a bootloader, you can boot the kernel directly[1], which I have been doing and so far it works well. In this case I suppose you only need to sign your kernel image before you create the PBA image or include the hash in the whilelist, but like I said before I haven't tested it yet. [1] https://wiki.archlinux.org/index.php/EFISTUB

« First ‹ Previous 1 2 3 4 5 Next › Last »