>>
> Sorry meant to answer earlier. Yes, apparently it was work in progress
> that probably never compiled. Somebody would need to clean it up. If
> you manage it, send a patch so branch can be updated.
I now have a version that builds. There were very few changes necessary.
I can supply a patch. However...

I can load the module successfully and use its "devmap" command but it
doesn't work for me.

I am not sure how much of the solution is in place and I don't know
enough about how it should work to be able to progress it without help.

I don't think it correctly sets up the cipher. The default value
"aes-cbc" doesn't work. I have compared with the luks code and I believe
that the cipher needs to be just the cipher name (e.g. "aes") and I have
verified that I don't get an error if I explicitly supply this with
"devmap -c aes...". What it doesn't do is set up the cipher mode in the
way that the luks code does - there needs to be a way to pass it the
mode and have it set that up (e.g. "xts-plain64").

Unless anyone can help who is more knowledgeable about this I am going
to have to leave it and accept that it doesn't work. But, if there is
someone else (perhaps the person who wrote the devmapper.c as it is now)
then I am more than happy to help test it.

> You realize that hd1 is not guaranteed to always remain hd1 after
> reboot?
Yes. but in a simple scenario where there is only one device I don't
think it'll be an issue.


_______________________________________________
Help-grub mailing list
Help-grub@gnu.org
https://lists.gnu.org/mailman/listinfo/help-grub

Reply via email to