>> > 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
