On Thu, Dec 29, 2016 at 09:20:41PM +0000, Rusty Bird wrote: > Rusty Bird: [...] > > Has there been any progress in upstreaming the hypervisor patch, now > > that you have a rock solid use case?
I haven't revistied that particular patch; they said they were interested in supporting "legacy free" systems, although my patch was really hackish. The right way to do it is to move early command line parsing to before the EBDA is examined. The Chromebook with a VBT works with fewer patches, so I also need to revisit what is different between it and the thinkpads. > > Trammell Hudson: > > [...] > > > I'd really like to figure > > > out how to pass the secret key from the Heads bootloader to Qubes' > > > initrd in a supported fashion. > > > > If I understand it right, [rd.]luks.key= isn't working as it should? > > I've played around with that a tiny bit and systemd-cryptsetup-generator > > was indeed behaving weirdly, some "out of memory" nonsense. I don't think that I get that error; it seems to just be ignored and Qube's initrd prompts for a disk password. > Which might be fixed by > https://github.com/systemd/systemd/commit/c802a7306bdc3e82378a87acd9402bbabe9f6b28 Hmm. Yeah, that would make a difference... The one drawback to the rd.luks.key approach is that only a single key can be passed in. For some use cases separate /, /boot and /home keys are worth having, which involve editing the /etc/crypttab file in the initrd before starting Xen. -- Trammell -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20161230130102.GA30182%40chishio.swcp.com. For more options, visit https://groups.google.com/d/optout.
